翻译Gavin 博文 升级到2MB版本的导游

RobertPep

把区块大小从1MB改到2MB听起来很容易：就把1改成2就完了，对么？

如果我们不关心一个平稳流畅的升级，那么确实可以是这么简单。就把下面这行代码
（在src/consensus/consensus.h里）
。。。 MAX_BLOCK_SIZE = 1000000
改为
。。。 MAX_BLOCK_SIZE = 2000000

如果你改动这一行，重新汇编并运行新生成的比特币核心，它将正常工作。你的计算机将会下载区块链并和网络上的其他节点协同工作，毫无问题

如果你的节点是挖矿节点(solo mine或者矿池管理者），那就要更复杂一些。接下来我就要陈述这些复杂的地方，希望能让你理解为了保证升级的安全需要做出多少努力

GITHUB有个功能可以比较代码，打开
https://github.com/bitcoin/bitcoin/compare/v0.11.2...gavinandresen:two_mb_bump
你就可以看到所有的有关升级到2MB的代码改变，你将看到

有五个commit, 一个commit是一组相关的代码改变，他们共同实现区块大小升级（请忽略David Harding的第一个commit，那只是core 0.11.2版本的最后一个commit）
22个文件被改变了，大约900行新代码，其中一半以上（500行）是新的测试程序，以便保证新代码正常工作

第一个commit是“为升级2MB所需最小共识/矿工变化”
这不大，少于20行。你可以看到有一行把MAX_BLOCK_SIZE从1000000字节改到2000000字节。其他的变化是矿工需要知道的，以便决定是否安全并开始产生大的区块。一个新的MaxBlockSize()方式被定义以便返回旧的或是新的区块上限，决定的依据是区块头中的时间戳
共识变化体现在main.cpp的第2816行里的CheckBlock()方式，并使用新的MaxBlockSize()方式而非MAX_BLOCK_SIZE来决定一个区块是否过大。一个类似的变化也发生在CreateNewBlock()函数以及'getblocktemplate'远程调用里，以便矿工能够产生更大的区块

下一个commit ("有关基础架构测试程序的修补")

在我们用于测试比特币代码变化的程序中加入了几个新功能和修复了一个漏洞
有两个级别的测试：单元测试(unit test) 是放在 src/test里，用C++些的，确保代码语句都正确。回归测试 (regression test) 在qa/rpc-tests里，用Python写的，用远程调用的接口和bitcoind 的 -regtest 模式对接，可测试所有的功能都正确运行

“矿工投票和缓冲期后的2MB分叉”是目前最多的commit - 几乎有700行代码。
这里实现了升级的规则：在75%算力通过在区块版本中设定一个特殊的位来表示支持升级，以及28天缓冲期到达后产生大于1MB的区块

75%和28天原则是人为的选择。我讨厌人为的选择，因为太容易产生意见的分歧而争论不休。我另有一篇博文解释为什么选择这些数字是好的
http://gavinandresen.ninja/seventyfive-twentyeight

“矿工投票和缓冲期”代码是从XT的BIP101里借用来的，有三层的测试
在block_size_tests.cpp里有一个新的单元测试。测试CheckBlock()调用，创建刚好够1MB和2MB的区块，以及各大出1个字节的区块，测试这些区块是否会分别按照规则在升级前和升级后被接受/拒绝
此外还有一个新的回归测试，bigblocks.py 在开发者的机器上运行4个比特币核心线程，创建一个区块链（回归测试中区块可随时创建），并测试分叉的激活代码，保证矿工的算力投票被正确计算，并保证在缓冲期结束之前不产生大区块。此外还要保证这个代码在2018年1月的限期到达之后无效

绝大多数我的开发时间都放在保证回归测试和单元测试彻底的测试了新代码。一旦回归测试和单元测试通过了，更多的其他测试可以在testnet上进行。写代码是简单的部分
最后，这套升级代码已经被Jonathan Toomim在测试XT的8MB方案的时候在testnet上反复测试过（也通过了中国的防火墙）

继续看代码变化。。。

main.cpp里的IsSuperMajority()函数以及block.h里的VersionKnown()函数有一些改变，用于统计矿工支持各类变化提议的区块数。因为要保证和 BIP009以及在区块升级过程中要实现的其他的一些BIP兼容

除了测试代码以外，最多数的代码变化发生在txdb.cpp上。当矿工投票成功后，触发的那个块的哈希值被写入区块链目录。这并不是绝对必要的，可以通过扫描所有块的办法同样得知投票是否成功。只是这个信息放在区块链目录里效率更高

天，写这些没准比写代码花的时间还长。还剩两个commit

“准确的计算和限制sigop/sighash”是重要的，因为如果没有限制，大区块会变得危险。你可以看看我11月在DevCore上的演讲。总的来说，Satoshi并没有仔细考虑交易是如何被签名的，结果就是可能构建一些极为消耗CPU时间来验证的交易。这个commit把这个问题解决了，通过一个新的ValidationCostTracker来持续追踪验证区块的工作量，并和一个新的限制MAX_BLOCK_SIGHASH一起保证没人可以通过发布一个极为耗时验证的区块来阻塞网络

通常人们不想产生这样极为耗时验证的区块，矿工希望尽快广播自己的区块减少被孤立的可能。但安全的编程实践是必要的

MAX_BLOCK_SIGHASH又是一个人为设定的值，它设在1.3GB，大到足够使目前已有的任何区块不会达到这个值，但也足够保证不会出现花好几分钟才能验证的区块

最后一个commit，“不转发和打包含有大量sighash的交易”是另一项安全措施。
目前已有一些防止大的、验证费时的规则，但这条加入了另外一个限制，以保证一个聪明的黑客不能诱骗矿工打包一笔验证极为耗时的交易

如果你有耐心一路看到这里，你能集中注意力的时间已经比我要长了。对非程序员来说，我希望你能因此而了解为了把1改成2所需要付出的努力
http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
---------------------------------------------------------------------------

译者注：


总结一下就5个commit:
第一个commit是“为升级2MB所需最小共识/矿工变化”
第二个commit是“有关基础架构测试程序的修补"
第三个commit是“矿工投票和缓冲期后的2MB分叉”
第四个commit是“准确的计算和限制sigop/sighash”
第五个commit是“不转发和打包含有大量sighash的交易”

第二个是测试相关，而第一个和第三个一起实现了扩容2MB，第四个和第五个一起实现了禁止验证极为费时的交易在网络中传播，这也是当初扩容2MB最大的一个担心，因为鱼池曾产生过一个花了30秒才验证的1MB区块