基于一个确定性小工具的计划将加强以太坊1.0链的安全性

编者注：本文原题为 The Finality Gadget，直译即为 “确定性小工具”，这个名字来源于一种 Casper 算法的代号 Friendly Finality Gadget（即 Casper FFG）。在一开始的时候，Casper FFG 意在成为一种可以提供最终确定性的组件，可以部署在任何 PoW 链上（所以叫 “Friendly”）。

这篇文章的主要内容是介绍一种让以太坊 1.0 和 2.0 链双向耦合的方案，让信标链为 1.0 链提供最终确定性。熟悉 FFG 的读者可以从中看出 FFG 的深深的影子。

随着以太坊 2.0 的上线时间越来越近，你可能会对现行以太坊区块链的命运感到好奇。在 “以太坊 1.x” 这个大概念下，人们已经提出了大量方案，旨在在短期内实现对现有网络的扩容。这些努力是为了确保现行区块链的持续平稳运行，从而促进当前生态系统发展的可持续性。

本文介绍了一种名为 “确定性小工具（finality gadget）” 的计划。它利用以太坊 2.0 在 Phase 0 （阶段 0）的共识来加强现有的以太坊 1.0 链的安全性。通过这个计划，以太坊 2.0 从它部署的第一天起就可以给以太坊社区带来一定的好处。我们先详细介绍一下“确定性小工具”这个概念，然后讨论它是如何运作的、会为社区带来什么好处以及具体的部署流程是什么样的。最后，我们会对一些突出风险和开放式问题进行思考。

介绍

“确定性小工具” 背后的想法利用了即将部署在以太坊 2.0 上的权益证明共识协议 Casper 的属性，即 最终确定性 。以太坊 2.0 的阶段 0 计划就是部署信标链，即分片后的以太坊系统的核心主链。参与信标链共识的验证者在满足 Casper 算法的某些条件之后就能为生成的数据提供最终确定性。之所以称之为最终确定性，是因为一旦某个区块被确定下来，将会一直存在于合法的那条链上；经证明，要想更改链上的数据，必须燃烧 ETH 总质押量的 1/3 以上。假设系统中质押了一千万个 ETH ，一次成功的攻击会导致大约 330 万个 ETH 被罚没，在写本文时，其成本已经超过了 6 亿美元。如果你想要了解更多细节，可以看看我写的另一篇有关最终确定性的文章，链接如下：https://medium.com/@ralexstokes/how-secure-is-ethereum-2-0-consensus-41523a59f270

确定性小工具旨在利用信标链中的这一流程来敲定（finalize）以太坊 1.0 的区块。如果我们可以将以太坊 1.0 的区块数据提供给 Casper 的 “确定性引擎” ，那么我们就可以利用权益证明协议来增强现行工作量证明网络的安全性。安全性增强之后就可以实行一些改进方案，例如减少挖矿补贴（从而减少发行量），以及将最终确定的区块数据提供给以太坊虚拟机（EVM），从而创建稳健度更强的用户级应用。利用阶段 0 的确定性小工具意味着以太坊 2.0 一旦上线，我们就能从中获得切实的利益，尽管以太坊 2.0 各个阶段的部署预计还需要更多时间才能全部完成。

利用 PoS 共识来最终确认基于 PoW 的区块链的这一构想已经在生态系统中酝酿了一段时间了（ 例如，请参考 EIP-1101 https://eips.ethereum.org/EIPS/eip-1011 或者 Casper FFG 的文档 https://arxiv.org/abs/1710.09437 ），另外 Alexey Akhunov 有一个很好的演示文档（ 就在这个幻灯片的开头：https://drive.google.com/file/d/16KLZKAutK79NxMh8L7B6hpNKuoOaAPZT/view ），讲的是在以太坊 2.0 背景下确定性小工具的一些发展情况。

确定性小工具如何运作？

现在让我们了解一下，在以太坊 2.0 的当前状态下，第一版确定性小工具（finality gadget）是如何运作的。注意，尽管我们信标链的最终规范即将完成，但是一些细节（特别是系统所用参数）仍在讨论之中，而且可能会有所变化。

构建确定性小工具需要两个东西：（i） 一个确定性引擎和 （ii） 一个给该引擎提供以太坊 1.0 区块数据的方案。事实证明，信标链在正常运行过程中是可以达成这两个需求的。信标链通过 Casper 协议达成共识，因此任何链上数据都能通过正常的操作得到最终确认。要实现第二个需求有点困难，因为这就意味着信标链需要成为以太坊 1.0 的一个轻客户端。幸运的是，以太坊 2.0 将从以太坊主网开始引导启动，而且在这个引导过程中，以太坊 1.0 的区块哈希最终会纳入以太坊 2.0 的信标链上。

追踪质押保证金的轻客户端

要成为新的以太坊 2.0 系统的一名验证者，你需要将自己的质押保证金和注册数据发送到现行主网上的智能合约中，之后会在主网上生成一个日志。这是一种单向质押行为，只有将注册证明提交到信标链上才能取回质押保证金。一旦这个质押事件得到处理，你就可以进入激活队列，最终成为以太坊 2.0 网络中一名活跃的验证者。

为了验证这些质押证明的有效性，信标链必须记录以太坊 1.0 上处理质押事件的智能合约的当前状态。在撰写本文时，需要记录的状态有 （i） 迄今为止所有质押保证金的默克尔树的根哈希 （ii） 迄今为止质押保证金的总量（参见当前规范中的 Eth1Data 结构 https://github.com/ethereum/eth2.0-specs/blob/dev/specs/core/0_beacon-chain.md ）。质押证明通常情况下是在这个默克尔树根哈希的基础上生成的，对质押保证金总量的记数则用来确保这个默克尔树根哈希中的所有质押保证金都得到了处理（如果一个区块内未注明最大质押量，那么这个区块就是无效的）。重要的是，对确定性小工具来说，还需要包括与该合约状态相对应的以太坊 1.0 区块的哈希。

信标链上每生成一个区块，验证者都必须提交他们对于质押合约的状态记录。如果在指定时间段内被提交的记录大多数都吻合的话，那么以太坊 2.0 协议即可视为对以太坊 1.0 的数据达成了共识，并将它记录在信标链的状态中。随着信标链上的区块最终确定下来，则每个区块相对应的状态也随之确定；一旦以太坊 1.0 上的某区块数据被包含在最终状态里，我们就可以说相应的以太坊 1.0 区块被最终确定了。这就是确定性小工具的基本构造。

确定性小工具的参数

在将以太坊 1.0 上的数据更新至信标链的过程中，时序（timing）和频率是两大重要参数。它们是用于保证确定性小工具质量的不可或缺的一部分。

第一个参数就是 SLOTS_PER_ETH1_VOTING_PERIOD（每段以太坊 1.0 投票周期内的时隙）数量，也就是将针对以太坊 1.0 数据更新的未决投票留存在状态中的时隙（slot）数量（一个时隙就是一个时间段，比如 6 秒）。在这段时间内，每个验证者需对以太坊 1.0 数据进行投票，而他们的投票都会保存在状态中。每经过一个 SLOTS_PER_ETH1_VOTING_PERIOD 整数倍大的时间周期（即 slot），未决投票的滚动集合就清理一次。只有大多数验证者在这段时间里达成共识的情况下，用作质押证明的以太坊 1.0 数据才能进行更新。反之则会清理未决投票，并重新进行投票，不会改变现有的 1.0 数据。

第二个重要的参数为 ETH1_FOLLOW_DISTANCE（跟随以太坊 1.0 链的距离）。这个数字限定了验证者可用于更新信标链状态的 1.0 区块范围：只有与 1.0 链末端距离大于该值的区块才能成为验证者的候选区块。验证者需要监听新的以太坊 1.0 链的候选数据，并选出其中得票数最多的候选数据。如果没有这样的候选数据（比如我们刚刚才经历过一个取得一致意见的 slot），那么验证者就应该跳回 1.0 链末端并找到与之相距 ETH1_FOLLOW_DISTANCE 的那个区块。例如，如果这个距离为 1024 ，且这条链的末端为区块 # 8，000，000，那我们就应该找到质押合约在区块 # 7，998，976 的状态，并将这个状态以及这个区块的哈希都整合进我们的信标链区块中。

该参数不包含在信标链的共识中，却是诚实的验证者所要遵循的守则。这个常数有助于验证者围绕不断生长的以太坊 1.0 区块形成协调（不断更新质押机制），同时存在的一个副作用是，会（在某一给定时间点）对以太坊 1.0 链可以最终确认的区块设定一个最大高度。

这么做不是会跳过很多区块吗？

要注意的是，鉴于以太坊 1.0 区块链的本质，只要我们能够最终确认位于高度 N 处的区块，就可以认为从创始块到位于高度 N 的区块之间的所有区块都得到了最终确认。这就意味着，以太坊 1.0 链上得到最终确认的区块集会根据前两个参数确定的周期性循环以及信标链上的最终确认时间突然跳过一定数量的区块。根据信标链目前设定的常数来看，这个时间段最好控制在 2 小时左右。根据下文的解释可知，在不利条件下，这一进展可能会放缓甚至停止。

周而复始

正如之前说的，现行的以太坊 1.0 链不需要了解新系统的任何信息。为了完全实现确定性小工具的所有功能，我们还得更进一步。最后这一步是修改以太坊 1.0 的分叉选择规则，使其满足最终确定性。具体地说，以太坊 1.0 仍然会使用 GHOST 协议来找到合法链，但是它会从最新确认的区块（由信标链验证者确认），而非像如今一样从创世块开始搜索。使确定性小工具可用的这一步更新，是对以太坊 1.0 影响最大的，因为以太坊 1.0 的客户端现在必须接收 2.0 的共识。但是，修改分叉选择规则可以将最终确定性带来的安全性延伸到 PoW 链上，从而实现这种额外的安全性带来的所有优点。

通过防回滚机制来改进确定性小工具

如果确定性小工具能按上述细则成功部署，客户端就可以借由它来大幅提高质量。这种质量上的提升是因为尽可能缩小了 2.0 链与 1.0 链的更新距离。最终确定性越接近以太坊 1.0 链的末端，带来的安全性就会越强，给用户提供的具有最终确定性的数据质量就越高。

考虑到区块广播总会有一定延迟，理想情况是使 “跟随距离” 只有几个区块。以太坊 2.0 一开始的跟随距离要大得多（目前是 1024 个区块），一部分原因是确定性小工具还不存在（已经在引入！）。另一个原因是质押机制。质押需要按照顺序依次处理，一旦被链知道了，就要提交至下一个可用的区块内。如果 PoW 链的重组发生在被信标链认为合法的区块上，那么以太坊 1.0 链该区块之后的质押将会视为无效（也就使 2.0 的验证者集无效），并且可能（会打破确保质押按序处理的机制，进而）破坏未来质押行为，甚至可能使 2.0 链停止运行（因为没有验证者可以提交有效的区块）。如果跟随距离较大（以目前的 1024 个区块来说），则不太可能出现这种情况，因为 1.0 链上达到最终确认性的区块之上还有 1024 个由 PoW 确定了的区块。如果 2.0 的客户端可以信赖 1.0 的客户端来保障最终确认性（避免超过某个深度的链重组），就可以缩短跟随距离。从抽象角度来看，我们可以想象，随着 “跟随距离” 的缩短，候选区块的 “最大高度” 可以按照 “可进不可退（ratchet）” 的方式不断逼近 1.0 链的末端，直到达到一个最小的安全距离。跟随距离能缩短到多少也是未来需要研究/讨论的主题。

为何我们想要 FG？

减少发行量

将 1.0 链最终确定下来有很多优点。其中一个较大的优点是，假设确定性小工具能够良好运行的话，是可以减少挖矿补贴的。通过将信标链的安全性与 PoW 链共享，PoW 链可以在降低对于矿工算力的依赖性的同时达到同等程度的安全性。由于我们不需要这么多哈希算力来保证链的安全性，完全可以降低挖矿补贴（这会降低对矿工的激励，并减少挖矿活动的总量）。最直接的一个副作用就是会降低 ETH 的发行率和相应的总供应量，这一目标似乎得到了社区的广泛支持。在主网上成功部署确定性小工具，并修改分叉选择规则后，可以通过另一个分叉逐步降低出块奖励来实现这个好处，就像在 EIP-1011 中描述的一样：http://eips.ethereum.org/EIPS/eip-1011#block-reward。

虽然确切的计划还有待商榷，但是通过确定性小工具减少发行量是将以太坊 1.0 链迁移到 2.0 系统的第一步。我们会平稳地转移，这个过程将从逐渐减少发行量开始。作为社区的一员，我们目前可以从支持这个举措开始，推进后续的迁移工作。

应用程序的最终确定性

一旦 1.0 的客户端接收到了最终确定下来的数据，这些数据就可以通过以太坊虚拟机暴露给智能合约和相关的应用程序。最终确定性是一个非常有用的属性，因为现阶段所能达到的最高水平的确定性需要等待 “足够多” 的 “确认” 数，并且 PoW 链只是 “不太可能”（但还是有可能）发生重组。想象一下，有这样一个交易所，用户进行提款操作后需要等待很多次确定才能收到取款。如果这个交易所只需等到最终确定，就可以大幅缩短提款时间，给用户更好的体验。

智能合约也可以利用最终确定性。预测市场就是一个例子，在确认一个事件的结果之前，等待某个高度实现最终确定性是有用的。实现这类好处似乎也要通过一个分叉（可能跟减少发行量的分叉同时进行）来部署，也就是增加一组操作码，以便以太坊虚拟机确定某个区块哈希或某个高度的区块是否已经得到最终确认。一个与此类似（添加新的操作码）的 EIP 案例是 EIP-145 （按位移动指令）（https://eips.ethereum.org/EIPS/eip-145）。

以太坊 2.0 的运作

确定性小工具意味着以太坊 2.0 的阶段 0 一启动时就能带来一定的好处。以太坊 2.0 目前正在分阶段进行部署：阶段 0 、阶段 1 和阶段 2 。每个阶段都为分片系统引入新的复杂性，而 2.0 团队目前正致力于在 2019 年底上线阶段 0 ，其余阶段预计需要更多的时间。由于类似于以太坊 1.0 中的用户层账户系统也要等到阶段 2 才可能实现，有必要让大家理解到，以太坊 2.0 的每个阶段都可以为我们带来一些好处。

随着阶段 0 的上线，我们可以将确定性小工具引入 1.0 链，获得本文提到的所有好处。在阶段 1 ，以太坊 2.0 就可以实现能够保存任意数据的分片链。确定性小工具的实现意味着以太坊 1.0 的客户端成了以太坊 2.0 的轻客户端。借助轻客户端的功能，可以通过以太坊 1.0 的智能合约为分片链中的数据生成证明。这个功能为 layer 2 扩容技术解锁了许多有趣的用例，比如高性能的 Plasma 链和能够提供隐私性的 zk-SNARKs 应用程序。我向你推荐 Vitalik 最近一篇关于 “作为数据层的可扩展区块链” 的演讲，详情：https://www.youtube.com/watch？v=mOm47gBMfg8。

如何部署？

确定性小工具的部署涉及到许多正在开发的部件，可能需要多次升级才能增强其效果；简而言之，这是一个复杂的方案，需要投入大量工作 ：）

第一步就是以概念证明原型和模拟的形式提炼出确定性小工具的思路，以便更好地理解通过这种方式实现两个系统耦合所产生的影响。比较理想的情况是在一个比较流行的主网客户端上部署确定性小工具。通过这种方式，我们可以收集到确定性小工具在运行过程中的实时数据，让我们知道确定性小工具会追随现有客户端达成的共识。

与确定性小工具同步进行的还有开发和上线信标链；我们在部署确定性小工具之前先要通过信标链来对区块进行最终确定，这点无需多做解释。

一旦我们明白了我们需要部署什么，我们就可以撰写一个 EIP 来阐明部署流程，并一步一步将其纳入接下来的分叉计划中。我认为比较明智的选择是先部署确定性小工具，然后再讨论减少挖矿补贴或者引入新的 EVM 操作码的问题。这个提议秉承着 “一次只做一项更改” 的思想，并且表明了在每个阶段确定性小工具的哪些部分会产生哪些影响。我们不希望在减少区块奖励之后发现确定性小工具没有如预想般有效，这样会导致主网安全性的降低。

确定性小工具的风险

从广义上来说，确定性小工具代表了 1.0 链和 2.0 信标链的双向耦合。两个系统的耦合度越高，受攻击面就越广，从而引起更大的担忧。在针对确定性小工具提出一些具体的设计建议之前，我们会对耦合进行全方位的分析。

确定性小工具的主要功能就是将新的 1.0 链数据导入到信标链中。信标链上的验证者必须是以太坊 1.0 的轻客户端；若某个 1.0 区块哈希不在特定 1.0 链验证者视图中，那么由该哈希形成的信标链区块共识会被视为无效。这一有效性条件确保了只要大多数 2.0 验证者是诚实的，1.0 链上就不会有任何无效的数据得到最终确定。如果超过 2/3 的验证者是恶意的，他们就有可能会串通起来确定一个可能并没有遵循底层 PoW 共识的 1.0 区块。通过设置一个较大的初始验证者集并采取保守的确定性小工具部署方案，我们就可以降低对这种情况的担忧。如果信标链启动，且我们知晓验证者集中作恶者占大多数的话，那我们还有机会重新考虑我们的方案。以太坊 2.0 和确定性小工具的设计方案需要确保即使这种情况发生，也不会对以太坊 1.0 区块链带来任何改变或影响。

另一个担忧是，鉴于验证者要在一个投票周期内协同提议下一个区块，这虽然不会影响确定性小工具的正确性，但会影响其性能。当前规范建议验证者选择先前区块发起人提议的多数区块，同时要保证该区块是在自己的视图中。实际上，这就意味着诚实的验证者只需要在每轮投票中选择第一个被提议的有效区块，并且最终达成共识。下一个得到最终确定的区块将从所有被提议的区块中选出。因此，如果不能（在划分好的 SLOTS_PER_ETH1_VOTING_PERIOD 时间段中）选出下一个区块，即表明确定性小工具没办法将 1.0 的区块尽快确定下来。通过进一步研究更好的投票策略来促进对 1.0 链的最终确定，我们就可以减少这样的担忧。

最后一类风险是在跟随距离非常短，且 1.0 链在受到攻击时，在可能产生很多短分叉情况下的 1.0 链的分叉选择。这是最终确定性的质量（由得到最终确定的头和链的 GHOST 头部之间的距离决定）和 PoW 链上不稳定分叉选择所产生的风险之间存在权衡关系。在今后的研究中，我们会通过模拟的方式更好地理解二者之间的权衡关系，并给出确定性小工具的最终提议。

这类攻击会造成 1.0 链的最终确定机制延缓甚至瘫痪，导致确定性小工具的性能降级，在我们依赖最终确定性来保障 1.0 链的安全性的情况下，就会产生很大的风险。

未解决的问题

· 假设确定性小工具投入运行，我们如何调整挖矿补贴（亦或完全不调整）？应该通过硬分叉来削减挖矿补贴吗？发行量是否应该是跟随距离的一个函数？我们是否可以将最终确定性所带来的经济安全性（用 ETH 来计价）当前主网算力所实现的安全性上作同质比较？

· 跟随距离可以减少到什么程度？又该如何调整？是随着时间的推移慢慢缩短，还是在部署完确定性小工具后就缩短至最小值？

· 在信标链上进行的以太坊 1.0 数据块投票过程是否足以支持确定性小工具的高性能运作？

结论

希望你能更好地理解什么是确定性小工具，为什么我们需要它以及我们应该如何规划后续进展。我们还有一些问题尚需解决，我们也很期待你能够提供任何有用的帮助。

如果你想要为我们提供帮助的话， Alexey 和我正在组建一个工作群，致力于实现确定性小工具。你可以点击这里进行参与：以太坊 1.x 确定性小工具工作小组

我要感谢 Danny Ryan 与我进行了很多有用的讨论，以便更好地理解信标链以及如何通过它来为以太坊 1.0 带来最终确定性，还要感谢 Alexey Akhunov 在工作组中的贡献。感谢 Terence Tsao 对本文的反馈。