本文主要是介绍【加密社】比特币海量数据问题解决方案，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
加密社
比特币是无敌的存在，刚翻了一遍中本聪的论文（其实以前看过一次，那时不明觉厉），发现咱们一直在考虑的问题，基本都能在其论文上找到解决方案了。。
现在出现的这些问题，完全是因为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左右即可。哪怕这一年，发生了几百万亿的交易!!
左图，为完整的交易清单内容，右图，为压缩后的数据内容。
对于银行、储蓄等要求比较高的节点，可以保存完整数据，而对于要求不高的节点，则可以使用压缩数据。
其中，二叉树中，n层的tree中，可以存放(2^n)-1的数据，换句话，反向计算，本机只需要储存32个hash，即可代表42亿笔交易数据。完爆visa和master。 而且，不一定要使用二叉树，N叉树的话。。。
其中，对于已被删除数据的节点，论文第8点提出，通过反向索引tree，即右图的树节点(hash0-3)，生成root hash对比，即可确认交易正确。
（下图是我的个人理解）
（中文白皮书翻译的那位，请改下段落8第一段的最后一句，你理解错了，我阅读了英文原版才理解出他的处理方案）
缺点1：有存在hash攻击从而欺骗可能，但个人认为其sha256碰撞的计算难度挺大的，并且仅适用于轻量客户端，对于完整清单的数据节点是无效的。（在论文中也提到过一个警告的解决方案，我理解得不是很透彻。）
缺点2：需要接收、处理所有的交易请求，检测是否是自身需要的。
不知是否中本聪的失误或笔误，我个人认为这是一种比较蹩脚的做法。因为如果是轻量客户端的话，根本就不该接收0确认的交易数据，尤其是在未来，短时间内上百万交易数据的情况下。
尤其是现在的bitcoin，支持bloom filter，可以直接进行收款地址级的数据筛选，过滤掉不属于自身的数据。减少数据风暴的可能性。
但不管是中本聪的方案，还是现在bitcoin的bloom filter方案，都可以解决数据暴涨的问题。让非专业用户、甚至手机用户使用。
同时，对于1MB的大小限制问题也顺便解决一半了，另一半问题，便是数据风暴与blocksize的协调问题。
其实也不该担忧，对于理想轻量级的客户端，他是主动查询最新blockchain，并且网络传输也是被filter缩减掉的，并且不需要发送大量数据，所以没有数据风暴的问题存在的。
而剩下的数据风暴，仅存在完整节点上，对此没什么彻底解决的办法。
由于对于海量的数据，是难以十分钟内即时地传播给全部的节点。比如一千万条交易请求了，一分钟内要接受900MB的网络数据，尤其对于个人的p2p挖矿人来说，是个比较麻烦的问题。
但是，还是有个代替措施(个人想法)。首先，先列举出，完整节点都有谁，矿池，p2pool 节点，类银行或第三方数据库。
解决措施，是利用merkle tree。交易请求发送给矿池（也可以是矿工），组成个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%的在线节点，也是毫无用处的。
即，比特币交易，几秒确认是可行的。
这篇关于【加密社】比特币海量数据问题解决方案的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
