比特币 2MB 分叉只是改了一行代码？

将比特币区块大小限制从 1 兆字节 (1MB) 扩大到 2 兆字节 (2MB) 乍一看可能很简单：只需将源代码中的数字“1”更改为“2”，然后就大功告成了，对吧？

如果我们不关心平滑升级，可能就这么简单。 只需放入以下代码行（在 src/consensus/consensus.h 下）：

...MAX_BLOCK_SIZE=1000000

改成：

...MAX_BLOCK_SIZE=2000000

如果你在做出更改后重新编译并运行 Bitcoin Core，它就会工作。 您的计算机将下载整个区块链，并将毫无问题地与网络上的其他计算机进行互操作。

如果你的计算机正在将交易组装成块（如果你是单独挖矿比特币源代码有多少行，或者如果你是矿池运营商），那么事情会变得更加复杂。 我将在本文的其余部分解释它的复杂性，希望能让您深入了解这个问题并确保对共识层的更改是安全的。

Github 有一个方便的功能，可以让你并行比较代码； 您可以访问 ...gavinandresen:two_mb_bump 以查看此 2MB 分支的代码更改。 你应该看到这个界面：

有五个“提交”（代码更改组）实现了区块缩放，请忽略第一个 David Harding 提交，这是 Bitcoin Core 0.11.2 的最后一次提交）。

更改了22个文件，大约900行新代码，其中大约一半（500行）是新测试，这些更改用于确保新代码正常工作。

第一个提交是“2MB 块大小增加的最小共识/矿工更改”，有 20 行新代码。 可以看到一行的变化是 MAX_BLOCK_SIZE 从 1,000,000 字节到 2,000,000 字节； 矿工需要进行其余更改，以查看生产更大的区块是否安全。 定义了一个新的 MaxBlockSize() 方法，以根据 80 字节块头中的时间戳返回旧的或新的最大块大小。 我可能会写一篇完整的博客文章来解释为什么使用时间戳而不是块高度或超过 11 个块的中值时间或其他任何东西……但不是今天。

共识变化写在main.cpp的2816行，使用了CheckBlock()方法，并使用新的MaxBlockSize()方法来判断一个块是否过大，而不是MAX_BLOCK_SIZE。 对 miner.cpp 中的 CreateNewBlock() 函数和“getblocktemplate”远程过程调用进行了类似的更改，以便矿工可以创建更大的块。

下一次提交（“测试基础设施修复”）添加了一些功能并修复了用于测试比特币源代码的代码中的错误。

本代码测试代码（code-testing-code）有两个级别； 单元测试放在src/test/中的树中，它是用C++写的，这个级别很低，它用来保证代码的每一部分都表现得恰当。 qa/rpc-tests/ 中的树也有回归测试。 它们是用 Python 编写的，并使用 RPC（远程过程调用）接口从命令行运行“-regtest 模式”以确保一切正常。

“Two Megabyte fork after miner vote and grace period, Two Megabyte fork after miner vote and grace period”是迄今为止最大的一次提交，新增了大约 700 行代码。 它实现了roll-out规则：当75%的算力产出的区块有一个带有特殊位的区块版本号，然后在28天后，允许产出更大的区块。

75% 和 28 天是相当随意的选择。 我讨厌武断的选择，主要是因为每个人对他们都有不同的看法（也被称为“bikeshedding”，意思是过分关注细节和边缘问题而忽略了主要问题），并花几天时间争论一个无用的问题。 我在另一篇博文中解释了为什么我们认为这些数字是不错的选择。

矿工投票和宽限期代码源自我为Bitcoin XT编写的BIP 101实现，已经过三个级别的测试。

block_size_tests.cpp 中有一个新的单元测试。 它测试 CheckBlock() 调用以创建确切的旧或新上限大小的块，或比旧或新块大小上限大 1 个字节的块，并根据它们的时间戳是在之前还是之后进行测试（或确切地）允许更大块的时刻决定了它们是否被接受。

还有一个新的回归测试，bigblocks.py。 它运行了 bitcoind 的四个备份，创建了一个区块链，只是为了在开发者的机器上进行测试（在 -regtest 模式下，可以动态创建块），然后测试 fork 激活码，确保矿工投票被正确计算，即区块链重建得到妥善处理，只有在过渡期结束后才允许创建更大的区块。 这也确保了如果 75% 的计算能力在 2018 年 1 月截止日期之前不接受更改，则整个代码将被报告为死亡。

我的大部分开发时间都花在确保回归测试和单元测试上。 然后，一旦回归测试和单元测试通过，就会在测试网络上进行更多测试。 编写代码是比较容易的部分。

最后，这部分推出代码由 Jonathan Toomim 验证，他在 8MB 区块和 Bitcoin XT 测试网络（包括中国防火墙）上进行了大量测试。

让我们继续探索代码更改......

main.cpp 中的 IsSuperMajority() 函数也有一些变化，block.h 中新增了一个 VersionKnown() 函数，该函数用于统计支持各种变化的块。 当块大小增加时，它可能与 BIP 009 的“版本位”和 BIP 的各种软分叉（68、112、113、141）同时发生。

（除了测试）比特币源代码有多少行，最新的代码在 txdb.cpp 中。 当矿工投票成功时，触发区块的哈希将被写入区块链索引。 这不是严格要求的，这部分代码每次发起都会扫描区块链中所有的区块头来判断是否投票成功。 它比将部分信息存储在区块链索引数据库中效率更高。

las，描述所有这些可能的代码更改比编写代码花费的时间要长得多。 还有 2 个提交要讨论。

“准确的 sigop/sighash 计算和限制”很重要，因为没有它，增加块大小限制可能是危险的。 大家可以看一下我去年11月在DevCore大会上展示的一些细节，基本上中本聪没有很仔细地考虑交易是如何签署的，这可能导致比特币创建一个非常大的交易，验证起来成本太高. 这个提交清理了一些“技术债务”，实现了一个新的验证成本跟踪器（ValidationCostTracker），它跟踪有多少工作在验证一个交易，然后将它与一个新的限制（MAX_BLOCK_SIGHASH）一起使用，确保没有人可以创建一个非常昂贵的验证块，试图搞砸整个网络。

将有强烈的动机不创建昂贵的验证块（矿工希望他们的块尽快通过网络，努力将他们的孤块率降到最低）。 但是，安全编码的原则之一是“安全带和吊带”（如果您想听起来很专业，或者不喜欢吊带这个术语，请将其替换为“纵深防御”一词）。

MAX_BLOCK_SIGHASH 是另一个烦人的任意限制。 它设置为 1.3 GB，这将足够大，目前没有块达到此限制，但也足够小，可以创建需要几分钟才能验证的毒块。

最后一个提交，“不要中继或挖掘过多的 sighash 交易”，是另一个“安全带和吊带”安全措施。 目前有一个拒绝非常大的、昂贵的交易来验证的限制，但这次提交增加了另一项检查，以绝对确保聪明的攻击者不能欺骗矿工将疯狂的昂贵交易放入他们的区块中。

如果你能坚持这个东西，你的注意力持续时间会比我长。 当非程序员在阅读本文时，希望你能明白从“1”到“2”需要注意什么。

原版的：