|
近日BTC区块圹容问题搞得社区很混乱，表面上是Core和Classic这争，其实背后是用户和矿场这两大利益集团之争。我作为一个用户，每笔交易不但要交上不少的手续费，还要等上几个小时才能成交，我只想说“XXX”；还不如用LTC来得快。为了保障用户的利益，已有不少商户已停收BTC了。作为用户的我只想说：只要交易手续费低、快速，我才不管你们什么技术，还是快快圹容吧！
有人会说圹容会使矿场收更多的手续费，矿场为何会反对。其实没这样简单，我们来分析一下区块的生成过程。当一个区块生成时向外广播，矿场收到新区块后先进行验证区块内的交易，验证正确后把新区块中的交易从交易池只删除，再将交易池中的交易重新按优先级排序，再打包进行 挖矿。从中可知从新区块挖出到打完包开始挖矿的这段时间，矿机是在空运转，浪费算力。而这个过程中区块验证与重新打包这个过程只要电脑够强没有多少影响，并且在Core新版中验证算法已优化，验证时间大幅缩短了。
而只有区块广播这个环节用时最长，并且因网络因素有很大不确定性。当一个节点接收到新区块后也会再作一次验证后才会再进行广播，这也加长了区块的广播速度。区块越大广播延时越长，而使矿机空转的浪费也越大，并远大于手续费的增加；所以矿场大多反对区块圹容。而现在不少矿场，为了节省哪一点时间，连验证打包的工作也不做了，直接去挖空块（不含交易的区块）；我只能对他们说太无耻了。其实区块大小矿场根本不关心，他们关心的是自己的利益有没有受到损害。
解决这个问题，方法这之一是矿场间建立高速专网，使区块在矿场间快速广播，减少空转浪费。但这个是治标不治本的办法，如以后区块不断圹大，区块延时还是会不断增加的。所以在这次区块圹容的问题上，矿场主们在各方的压力下才勉强松口同意将区块容量增加到2M。
这个问题能否有一个更好的解决方法？DAC的宗旨就是道德问题技术解决。近日读了Gavin Andresen的《区块头优先挖矿将杜绝DoS攻击》的文章https://github.com/bitcoinclassic/bitcoinclassic/pull/152，我阔然开朗，区块头优先挖矿再加上一点改进，不就能解决区块广播延时的问题了吗！。
Gavin Andresen文章的意思是当挖到新区块时，先广播80字节的区块头，矿工收到区块头后先进行空区块的挖矿，等整个区块完成传送、验证、打包新区块数据后再转回挖有数据的区块。其主要作用是先验证区块头是否最长链的工作量证明，如果不是就不再进行广播，以防止拒绝服务攻击；也可在区块传送阶段挖空块，减少矿机空转。但挖空块不成功也是空转，这样会有无耻的矿场直接就挖空块，不转回挖有数据的块了。
其实只要将区块头优先挖矿再加上奇偶挖矿技术就能解决所有上术的问题。奇偶挖矿很简单，就是高度为奇数的区块内只含用TXID为奇数的交易，高度为偶数的区块内只含用TXID为偶数的交易。
其挖矿过程序如下：当前正挖一个高度为奇数区块，矿场同时把TXID为偶数的交易打包，作为下一个偶数区块。当奇数区块挖出来后，先广播80字节的区块头；矿场收到区块头并验证正确后，马上转挖已打包好的偶数区。同时等整个奇数区块传送完后再进行验证，如验证不正确，就返回原奇数区块挖矿；如正确在进行一系列处理后，再打包奇数交易数据等待挖奇数区块。
因奇数区块不含有偶数交易，所以当收到奇数区块头后，不需要接收整个区块数据及进行数据处理等工作，就能直接用已打包好的偶数交易进行挖矿。而奇数区块的接收处理是在偶数区块挖矿同时进行的。同样偶数区块的处理也是在奇数区块挖矿同时进行的。挖矿的转换只需进行80字节的区块头传送及验证，整个过程就毫秒级完成，速度极快。如再加上使用挖矿高速专网，其稳定性就能得到保证。就算以后再增加区块容量，只要保证区块数据能在10分钟内广播完成，就能保证区块的正常运行。
希望我这篇文章能被各大矿场、Core和Classic看到，认真研究奇偶挖矿这个方法的可行性；也许奇偶挖矿就是解决区块扩容的最好方法。
本人英语水平差，有哪位大神能翻译一下在各平台发表一下不胜感谢。
币家伙
2016-4-1 | 
发表于 2017-11-20 23:07:46
收藏