作者：Shinobi
来源：https://bitcoinmagazine.com/technical/drivechains-allow-sidechain-node-miners
这一次我准备分解和讨论 drivechain 是如何工作的；这是一个最早于 2015 年提出的想法。在我们迄今讨论过的所有提议中，drivechain 是最老的，从实现细节和设计上来说也是最具体的（已经由 BIP 300 和 301 文档化）。Paul Sztorc 是这个概念的发明者，他有几个主要目标，下面是一份不完整的归纳：
- 隔离每个侧链，这样任何侧链出问题都不会波及到不使用它的人。
- 允许自发实现侧链，不必为每个侧链发动一次新的分叉。
- 允许比特币使用双向锚定机制 转入/转出 侧链。
- 允许设计上的自由实验，他希望能取消使用另类币的意义。
整个设计有两个主要的方面，这也是为什么有两个专门的 BIP。第一个部分是锚定机制（BIP300），这是让双向锚定得以工作的机制。Sztorc 设计了一种叫做 “算力托管（hash rate escrow）” 的东西，用最简单的话来说，就是让矿工作为一个不定形的团体，集体托管存在所有侧链上的资金。第二个部分是 “盲化” 合并挖矿机制，目的是让比特币矿工成为侧链共识层的区块生产者，但又不必去验证侧链的区块。两个部分合在一起就成了一个双向锚定的机制，以及一种让比特币矿工可以参与侧链挖矿、同时尝试减轻由此引起的去中心化风险的方法。
BIP300 详细描述了提出一条新的侧链、激活新的侧链、提出一组取款请求、许可一组取款请求的逻辑，以及真正的取款交易和存款交易的验证逻辑。
在 drivechain 机制下，激活新的侧链的过程非常类似于通过矿工信号来激活软分叉的过程。当然，主要的区别在于这并不是一个软分叉 —— 只需要一个专门的分叉来激活 drivechain 共识规则，从此，矿工就可以在任何时间发信号激活一条 遵守 drivechain 共识规则的新侧链。为了提议激活一条新侧链，一个矿工要在自己的 coinbase 交易输出中放置一个 OP_RETURN 数据，包含这条侧链的唯一标识符、用于存款操作的一个公钥、版本数据、人类可读的描述、软件客户端的哈希值以及该软件的 GitHub 历史（没有共识规则来执行这些要求，只是为了让人们有所参考而已）。
当一个矿工提出激活一条新侧链并在 coinbase 交易中包含了所有必要的数据之后，就进入了一种 “矿工表态” 阶段，就是发信号表态要不要从主链共识的视角中创建这条新侧链。一个矿工可以在自己的 coinbase 输出中使用一种特殊的格式来包含一个提议，其他矿工可以创建另一个输出、使用第二种格式来表态支持激活。新的侧链需要在一个难度调整期内得到 90% 的区块支持才能激活。这就是 drivechain 下产生侧链的锚定机制，但其侧链和主链的交互比这还要更微妙。
激活侧链之后，任何人都可以向侧链存入资金。为了存入某条侧链，用户只需使用自己的输入和对应于侧链的 UTXO 创建一笔两个输入、一个输出的交易，将所有资金都分配给侧链。这保证了一个侧链只有一个 UTXO，包含所有锁入的资金。取款则是由矿工投票来处理的。主链对谁在侧链上拥有多少钱一无所知，而且主链会把任何由矿工在投票机制内认可的取款交易是有效的。因此，取款流程会很长。从某条侧链区块要经过两个节点：取款提议（成批汇集），然后是表决。矿工必须在自己的 coinbase 交易中创建一个 OP_RETURN 输出，带上取款交易的哈希值，来提出一笔取款交易。不过，这个哈希值，类似于 sighash 标签，只承诺了交易的一部分（而不是全部）。它并不承诺代表锁在某条 Drivechain 上的资金的输入，也不承诺将剩余的资金都返回到一个特殊的侧链 UTXO。若如此设计，则任何向该 Drivechain 存入资金的交易都会创建一个新的 UTXO ，从而作废掉处理中的取款交易。
取款提议出现后，矿工表决阶段就开始了。矿工可以支持或反对一笔取款交易。每个区块挖出时，挖出该块的矿工都可以推进一个表决计数器，可以投一个支持票，或者一个反对票，或者同时投支持和反对，就变成了保持中立。此外还有一些特殊的限制，因为一条侧链上可能有多个取款包 —— 要是某个矿工选择了为一个区块包投 “支持” 票（会让计数器增加 1），那就 必须 对同一侧链的所有其它取款包都投 “反对” 票（让计数器减少 1）。
这是为了保证用户不会 “重复取款”。如果某人在多个取款包中都有输出，则允许同时支持它们可能会让该用户在主链上获得超过 TA 本应获得的数量。
另一方面，矿工也被允许对每一个取款包投反对票。作者假设这个功能可以作为一种昭告天下的警报，某个矿工在验证这些取款包（确保他们在侧链上拥有大于等于被取出的数量）时发现了无效交易就可以使用。请记住，drivechain 设计的关键在于，矿工不必验证侧链上的任何东西，所以除非他们真的发现了，不然许多矿工都会选择给自己没有验证过的取款包投支持票。这个警报功能是为了警告他们，让他们自己验证取款包以保证没有发生欺诈。
一旦某个取款包获得了所需的阈值（13150 个区块，大概是 90 天），这个取款包就可以实际执行，取款会变成有效操作，可以得到主链的确认。那么，如果矿工们同意了一笔从侧链盗窃资金的欺诈取款呢？人们能怎么办？Sztorc 的提议是使用一个用户激活的软分叉（UASF）来作废这笔无效的取款交易。这给主链的共识带来了很大的风险。2017 年的用户激活软分叉是一个高危操作，好险成功了，而且那时候的比特币网络也比今天的小很多。比特币网络越大，这样的活动协作起来的难度也就越大。
如果你还记得我关于 spacechain 的文章（中文译本），你应该知道，spacechain 也是基于盲化合并挖矿（BMM）的。Ruben Somsen 的 BMM 设计实际是 BMM 的第二个变种，第一个是 Sztorc 在 BIP301 里提出的。Drivechain 的 BMM 规范由两种消息组成：Ruquest（“请求”）消息和 Accept（“接受”）消息。两种消息都通过主链上的一种特殊交易类型和矿工的 coinbase 交易的特殊输出来协调。
Request 消息可以由任何创建侧链区块的人构造。BMM 的全部目的就是让非比特币矿工也可以参与侧链出块，所以请求交易允许他们向矿工支付、以确认他们提出的侧链区块。提议侧链区块的交易会包含该侧链区块的哈希值、该侧链的 ID，以及前一个主链区块头的最后 4 个字节。这种交易还要遵循三个额外的共识规则。其一，请求交易所在区块的 coinbase 交易中必须有一个对应的 Accept 输出，否则这笔请求交易是无效的。这是为了保证矿工无法又拿钱又不办事。其次，每个侧链在每个主链区块中都只能提交一笔请求交易。这是为了保证每次主链出块，任一侧链上都只有一个区块被挖出。最后，前一个主链区块头的最后四个字节必须匹配。这是为了保证一个请求只有在（发出后的）下一个区块中挖出才有效，而且无法事后再挖，也不会让没有成功出块的提议者丢失资金。
Accept 输出是非常简单的：包含了消息头数据和侧链区块的哈希值。如果一个矿工运行了某条 Drivechain 的全节点，TA 可以直接忽视所有的 Request 消息，在 coinbase 交易中只包含自己的 Accept 输出，从而只挖自己提出的区块。两种消息的结合，使得矿工既可以自己运行侧链节点、自己挖矿，也可以挖掘其他人提出的区块并获得支付。巧妙之处在于，如果矿工自己并不运行侧链节点、承担额外的验证成本，那么其他人可以为矿工承担。只要尝试从侧链上赚取手续费的非矿工之间存在竞争，他们可能会不断抬高 Request 交易给矿工支付的报酬，直到这部分报酬占据他们收入的大部分，也就是非矿工仅获得一小部分利润，其余的收入都支付给了矿工。
以上就是 drivechain 背后的机理了。下一篇文章我们来聊聊联盟侧链，再然后，我们来比较以下所有这些设计的优缺点。
（完）