解决比特币海量数据问题的方案

比特币是无敌的存在,刚翻了一遍中本聪的论文(其实以前看过一次,那时不明觉厉),发现咱们一直在考虑的问题,基本都能在其论文上找到解决方案了。。

现在出现的这些问题,完全是因为bitcoin-qt、bitcoind的实现有问题,根据其设计思想,完全是可以解决的。 (比如可以二次开发一些轻量级的神器来辅助的。)

现阶段,主要发现的问题有:

1. 庞大的数据库问题。

2. 未来单位时间内,(上亿笔的)海量交易的可能性。(block 1MB大小限制与数据风暴的问题)

3. 支付确认长达10分钟的问题。

论文、白皮书 (中文):http://www.btc123.com/data/docs/bitcoin_cn.pdf

原英文论文、白皮书:http://bitcoin.org/bitcoin.pdf

 

首先说明第一个问题,逐渐庞大的数据库问题。

论文中第7点,明确提出了,可以通过删除所有交易数据(当然,最好要保留自己的数据),只保留blockheader,就够实际使用了。

每个blockheader由80字节组成,无论一年内多少惊人的交易数据,其blockheader大概只需要4.2MB左右即可。哪怕这一年,发生了几百万亿的交易!!

tree

左图,为完整的交易清单内容,右图,为压缩后的数据内容。

对于银行、储蓄等要求比较高的节点,可以保存完整数据,而对于要求不高的节点,则可以使用压缩数据。

其中,二叉树中,n层的tree中,可以存放(2^n)-1的数据,换句话,反向计算,本机只需要储存32个hash,即可代表42亿笔交易数据。完爆visa和master。 而且,不一定要使用二叉树,N叉树的话。。。

其中,对于已被删除数据的节点,论文第8点提出,通过反向索引tree,即右图的树节点(hash0-3),生成root hash对比,即可确认交易正确。

(下图是我的个人理解)

leight_check

(中文白皮书翻译的那位,请改下段落8第一段的最后一句,你理解错了,我阅读了英文原版才理解出他的处理方案)

缺点1:有存在hash攻击从而欺骗可能,但个人认为其sha256碰撞的计算难度挺大的,并且仅适用于轻量客户端,对于完整清单的数据节点是无效的。(在论文中也提到过一个警告的解决方案,我理解得不是很透彻。)

缺点2:需要接收、处理所有的交易请求,检测是否是自身需要的。

不知是否中本聪的失误或笔误,我个人认为这是一种比较蹩脚的做法。因为如果是轻量客户端的话,根本就不该接收0确认的交易数据,尤其是在未来,短时间内上百万交易数据的情况下。

尤其是现在的bitcoin,支持bloom filter,可以直接进行收款地址级的数据筛选,过滤掉不属于自身的数据。减少数据风暴的可能性。

但不管是中本聪的方案,还是现在bitcoin的bloom filter方案,都可以解决数据暴涨的问题。让非专业用户、甚至手机用户使用。

同时,对于1MB的大小限制问题也顺便解决一半了,另一半问题,便是数据风暴与blocksize的协调问题。

其实也不该担忧,对于理想轻量级的客户端,他是主动查询最新blockchain,并且网络传输也是被filter缩减掉的,并且不需要发送大量数据,所以没有数据风暴的问题存在的。

而剩下的数据风暴,仅存在完整节点上,对此没什么彻底解决的办法。

由于对于海量的数据,是难以十分钟内即时地传播给全部的节点。比如一千万条交易请求了,一分钟内要接受900MB的网络数据,尤其对于个人的p2p挖矿人来说,是个比较麻烦的问题。

但是,还是有个代替措施(个人想法)。首先,先列举出,完整节点都有谁,矿池,p2pool 节点,类银行或第三方数据库。

解决措施,是利用merkle tree。交易请求发送给矿池(也可以是矿工),组成个tree树。

miner_tree

需要注意的是,这些节点,底层是轻量级pool节点,而上层,是完整级节点。

这个其实就是中本聪之前提出的方案,不过这里,并不是用于轻量级客户端,而是用于矿池和支付网关,用于网络结构优化。

(可将现在的web pool由纯粹的miner pool,变成miner pool与service node结合起来的节点,并且是半轻量级的节点。)

注:比特币完整节点包括三个功能,miner, receive tx(Timestamp Server), query tx,其中,miner与receive可以不需要保存或传出交易内容,只需要hash即可,而query则需要完整数据库、完整的交易内容。

可以从图中看到,每LightWeight pool只需要处理自己旗下的交易记录,不需要管其他pool的交易记录。而且merkle tree的高度不只为三,那么所谓的数据风暴问题轻而易举的就可以解决了,每个轻量级pool上,只需要每隔单位时间就更新下其他节点的merkle hash,就可以变相"同步"到其他pool上的海量交易数据了。

只有Full Pool/Node才需要接受数据风暴的洗礼,这就让有实力的人承担吧。

同时,lightweight pool 在收到交易请求时,向full pool 请求filter一下,是否有相同的未确认交易,防止多重支付。中本聪的论文中提出,需要确保在交易期间绝大多数的节点都认同该交易是首次出现.

另外个人建议,可以根据地域来选择 lightweight pool 支付网关 , 这样,通过地域性的加速,可以便捷的让你的交易请求进入全网。

缺点1:如果某个pool节点关闭了,可能因为时间差导致,旗下的部分未被确认交易数据未广播出来。不过这不是问题,现在的bitcoin本身就存在有时发出交易后,其他节点上看不到0确认的交易问题存在。

缺点2:pool节点本身,是第三方的,有可能不是加入pool's p2p pool,而是加入受监督的service node;或是直接联合恶意miner pool进行51%攻击。

当然,如果你对自己的网络能力有信心的话,也可以直接加入miner p2p pool,接受数据风暴的摧残。(如现在的p2pool.info所设计的程序体系)

缺点3:由于miner组成的完整节点逐渐变少,导致用户可以查询的完整数据节点也变少了。这点其实应该在之前就存在了,跟miner/pool无关,大家都用轻量级客户端了,完整客户端自然就变少了。

 

最后,关于确认时间的问题,其实如果深入理解就知道了,0确认本身并不危险。

首先,先了解下,比特币只要你签名了这次转账,如果生成的数据本身是合法能过检查的,那么,无论是谁来发送的这笔交易数据,它都是可以被全网确认的。(离线交易的原理)

其次,论文中提出,Timestamp Server / 完整节点 需要限定,需要确保在交易期间绝大多数的节点都认同该交易是首次出现。换句话说,在诚信节点上,每笔钱,在0交易时,这笔钱的来源,最多出现1次,当节点收到的第二次交易请求,因为是多重支付,哪怕之前的交易尚未被确认,也将会把新交易请求拒绝掉。

即论文中所提到的,实际上我们需要关注的只是于本交易之前发生的交易,而不需要关注这笔交易发生之后是否会有双重支付的尝试.

也就是说,若你在blockchain.info上,看到0确认交易的时候,你就可以知道,在blockchain.info网站所认定的分支里,没有双重交易的了。
若有,也仅仅是在其他算力分支里,但需要欺骗人能攻击掉网络才有可能。

并且,而所谓的0确认,实质上已经隐含的代表,交易已确认1次了,只不过,是部分网络节点的1确认而已。

简单的描述:
大于等于1的交易确认,是经过51%的全网算力半永久的保护了;
而若查询N个节点出现0确认,就可以认定,交易是至少被N个在线节点保护了,并且是效验通过的了。
而至于无效、错误交易,根本就不会进入0确认队列,因为在接收的时候就已经拒绝掉了。(除非是伪装节点)

两者无论攻击谁,都是有一定难度的。前者不必多说,后者需要攻击者占有全网51%算力的在线挖矿节点或矿池,这与51%算力攻击难度,可以说是近似于等价的(网络数据包劫持手法除外)。

个人认为,你只查询六七个网站(节点),是否都出现0确认了,其安全性几乎就是难以出现多重支付了!

若需要更加稳妥点,等新版客户端要增加的tx请求反馈指令出来了,只需要对全网的排名前几名的矿池,进行inv.MSG_TX查询,只需要总算力超过51%的几个矿池接受了你的0确认交易,就是可信的了。哪怕攻击者占有了全网51%的在线节点,也是毫无用处的。

即,比特币交易,几秒确认是可行的。

============

建议写个摘要,然后再链接到本站吧。因为可能会不定时修改,更加逻辑严谨的说明。

 

5 thoughts on “解决比特币海量数据问题的方案

  1. 就我比较浅的理解,提两点异议1、关于解决海量数据量存储的问题:采用轻客户端的方式将数据保留在所谓的上层或者核心节点(类似“云”的概念——重服务器端,轻客户端),这就必然导致参与交易确认的节点大幅减少,“去中心化”体系变弱,安全风险随着完整数据节点的减少而增加;2、海量数据的传输也存在问题:即便是安全问题能得到解决,但由于交易区块是线性排列(交易顺序是线性的),交易基本要让全网50%以上的节点确认才能最终被认可,如果是单位时间内交易数据量陡增,节点之间的数据传输速度将严重受限于带宽,进而导致确认时长暴增。所以我认为,至少目前来说,BTC不适宜用作日常交易。

    • 1.交易确认并不是你拥有数据就叫确认,核心安全只依托于3点,非对称算法+数据摘要+能量与概率的关系。文中早已提到,非完整数据也是能验证的。2.确认跟全网无关,只跟挖矿节点有关。无论你接受不接收,参与不参与,算力就在那儿,必然会确认。带宽问题请再次阅读文章,已经讲解过了,你依旧没理解

  2. 今年为了解决容量大问题,都分了好几次叉了.这脸打的.

回复 macwu 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注