加文•安德烈森：”比大更大”的区块链展望

过去几周，我一直忙着用比特币主区块链的副本塞满硬盘。

我要证明：基于现有的比特币核心代码，把单个区块体积上限从1MB提高到20MB是安全的。（不用花俏的“可逆布隆过滤器”, 也没用“高级订制版比特币椭圆曲线验证代码”）。

如果现有代码就可以处理20MB的大区块，我会提议用硬分叉来提高区块体积的上限。理想情况下，我们将不会再碰到区块体积上限的问题——就像现在的状态，由矿工决定区块大小，而由比特币使用者决定在交易中付出多少矿工费激励矿工打包自己的交易。

所以，我一直用现有的核心代码测试比原先大的多的区块——20MB和200MB。

当然，我可以用随机生成的交易填充区块，不过用真实交易来包装大区块更好。我运行了几个完整的比特币节点，也就是说目前有20G左右的真实交易。

我得找办法把现有交易包装成更大的区块。经过令人沮丧的几天之后（如果我们的想法总能在第一次就完美地实现该多好？！），我想出了下面的方案：

首先，我修改了参考实现，然后改了几个与区块大小有关的常量(MAX_BLOCK_SIZE[译者：块的硬上限，目前是1MB], DEFAULT_BLOCK_MAX_SIZE[译者：块的软上限，也就是矿工挖块的默认大小，目前是0.75MB。], MAX_BLOCKFILE_SIZE[译者：存储区块文件分割大小，目前是128MB])。这部分还算简单。

比较棘手的问题是怎么把小于1MB的区块重新包装成更大的区块。对于大部分交易来说问题不大，因为普通交易并不关心自己在哪个区块里。

但有两个特例：

1. 使用了“locktime”[译者：锁定时间]功能的交易。这些交易只在特定的区块高度或时间才会生效。我直接把所有交易的状态都设为“final”[译者：生效]状态处理这种情况。

2. 对“coinbase”交易[译者：矿工挖出币的交易]有特别的规则：即每个区块只能有1个“coinbase”交易，而且必须是整块中第一个交易，等等。最开始的几次尝试走错了方向，我想通过放松规则来处理它。后来我放弃了这类方案，因为需要修改的代码越来越多。我想，如果我依旧是22岁，可能会继续搞下去，不愿意几天的努力付诸东流，因为“只要再改一段代码，它可能就正常工作了…”

不知道老程序员是不是比年轻程序员放弃的代码多的多。我打赌我们老程序员肯定是这么干的。

无论如何，在重新思考之后，我想出了更干净的方法来处理真实区块中的coinbase交易：把它们写进一个“coinbasetx.dat”文件。当修改过的Bitcoind[译者：比特币核心的另一种叫法，因为启动比特币核心命令是：bitcoind]开始运行的时候，会把这个文件读进内存（总共只有73MB）。随着交易不断写入大区块链，这些Coinbase交易会添加到“unspent transaction out put set[译者：未花的输出集合]”,这样就可以花掉它们了。（同时我把COINBASE_MATURITY常量[译者：刚挖出币的锁定时间]从100改设为0，这样它们就可以在大区块里直接花掉。）

我写了一个工具（“gen_megablocks”）来创造coinbasetx.dat文件和blk*.dat文件，他们是valid-but-oversized,-regtest-mode[译者：有效但超过标准大小]的区块。

然后把这些区块导入到能接受超大块的bitcoind中。我使用 -loadblock 命令行工具来导入这些区块，这样它们可以经历整个交易和区块验证和索引的过程。

最终，我获得了完整索引、使用真实交易的“大”区块链。然后，我将原主链上的私钥导入其中进行交易测试，这些交易在大区块链和原来的1MB区块链中都能正常工作（因为普通交易与区块相互独立）。

到目前为止结果很令人满意——处理大区块所需的时间和区块大小线性相关，没有出很多0（指数相关）给我捣乱。我的台式机（四核、16G内存、“2012年末”的iMac）可以很轻松地处理单块20MB的区块链，甚至200MB的区块也能正常工作，只需用更大的 -maxsigcachesize 和 -dbcache 参数。

今天我又做了一个区块链（我增加了一个选项，可以跳过某些交易和它们的后代）；我会重组出长链、短链来测量不同情况下的CPU占用时间和内存使用率。等这些工作都完成后，我会用因特网同步这些区块链，测量实际运行中的网络带宽占用和同步时间。然后我会引入一些功能让Bitcoin-Qt钱包能正常处理大区块链（理论上，它不应该包含任何与区块大小有关代码）。

一旦所有工作都结束后，我会写个测试报告，详细描述增加区块大小的技术细节。最后就是写补丁升级比特币系统（当然会经过多轮测试）。

然后呢？用无止境的各种争论刷新自己，总比枯燥、可预测的公式代码好，比如区块大小块与交易量和难度的关系、币价、总矿工费、甚至月相…