以太坊2.0 的中继者网络与手续费机制

本文将总结现有围绕着以太坊2.0 Phase 2 的研究成果，重点关注中继网络以及手续费机制。每种提案都有其不同的权衡取舍，而且被不同的平台所采用，因此做一次合理且全面的汇总，能让新入门的研究者更快上手。

背景

在深入讨论中继网络之前，我们先回顾一下以太坊的主要瓶颈之一（or没有之一）：状态。

在以太坊中，状态指的是账户余额、合约代码、合约存储内容的集合（在比特币中，状态指的是UTXO 的集合）。不论什么时候执行交易，都要对状态（约45 GB 的不可压缩数据）进行读写操作。早些时候，人们曾对以太坊计算模型原生的不可扩展性提出过质疑；但时至今日，反而是状态的读写成为执行交易的成本瓶颈，磁盘的I/O 性能成了运行以太坊全节点的制约因素。

请注意，为了能够按照富状态范式（stateful paradigm）执行任何的交易，全节点必须保证所有状态始终放在可访问的位置（比如内存、交换空间）。如果应用在单一区块链的场景，或许这还能勉强接受，但是一旦面临分片、面临分片上委员会的重组，这种要求是非常不合理的。设想一下，每当验证者被指定到一条分片链，他就得同步该分片上的所有状态；则这种系统就等价于单一区块链，只是此时的区块大小等于分片区块大小*分片数量。

这就是为什么我们需要无状态客户端。

分片及无状态客户端

在无状态客户端范式中（原名「storageless」），验证者只需要存储一个经过压缩的区块链状态表（通常称之为累加器，accumulator），大幅降低了执行交易的负担。一般来说累加器的大小是常量（例如：状态的Merkle 树根值），不过也有可能是对数大小。

无状态客户端的本质是，每笔交易都附带当前累加器的见证数据（witness），见证数据中包含了所有执行该交易所需的信息。在以太坊中，使用稀疏Merkle树（SMT，Sparse Merkle Tree）作为累加器，一笔交易所涉及的所有状态元素都可以被包含进默克尔树分支中。

在其他应用上，无状态客户端可以缩短以太坊节点的初次同步时间，这就是Beam Sync 的原理。

备注：有一些密码学累加器（如RSA 累加器）比Merkle 累加器性能更好，但是这种累加器需要受信任初始化，或是使用未验证的前沿密码技术，所以安全部署到生产系统上还需要点时间。

但无状态客户端也有自己的挑战：一旦使用Merkle 累加器，每当结束一次完整的执行后，见证就过期了。如果模型要求每笔交易都包含单独的见证，然后顺序执行这些交易，则排在后头的交易的见证数据就会过期，必须能够随着前面每一笔交易结束而更新自己的见证。幸亏更新这些Merkle 累加器的见证涉及零哈希开销方法——如果见证数据可以作为附加物添加到「一大包」交易上的话，就不需要更新属于每笔交易的单独见证，或是说可以整合为多重证明（multiproof）。

假如所有用户都维护着全节点，并实时更新见证的状态，那么无状态客户端系统是能够马上被采用的。可惜在分片环境下，这意味着要求所有用户维护自己所在分片上的所有状态；这样做不仅不切实际，而且就如我们上面提到的，这就相当于只是建立一条区块体量更大的单一区块链。

为了解决问题，这里引入了中继者（也称为状态提供者）的概念。中继者负责提供用户所需的见证，并以此向用户收取服务费。和用户不一样，中继者可以将服务聚焦在单一分片上；但中继者无法预知用户什么时候需要状态，因此必须保证见证的及时更新，也就是实时存储状态（所以被称为状态提供者），以供用户获取。

中继者的引入也会引来一大堆复杂的问题，也是以太坊2.0 的全面部署所面临的最重要的开放问题之一。第一点，如果不能很好地平衡中继者和区块提议者（ie 验证者）所得到的利益，验证者就会被激励成为中继者，则相关服务的获取成本可能会让一般使用者望而却步。第二点，要让中继者能够从用户和验证者处收取费用（即：手续费机制（fee market）），同时不至于引入太大的开销，显然不是件简单的事；换言之，验证无状态交易很容易，但是提供必要的见证很困难。

中继网路及费用市场提案

以太坊2.0 Phase 2 的设计空间很大，也出现了很多对执行模式的提议。每种提议都各自表述了如何通过付费，结合中继网路的机制，将交易更好地在用户和区块提议者之间进行传递。本章节会尽可能简洁而全面地总结不同的协议，并着重分析它们在中继网路及手续费机制上的异同。

校勘者（Collator）提案（已弃用）

这是Phase 2 阶段的早期提议，将分片链的建块分为三个部分：提议者（proposer）、校勘者（collator）、执行者（executor）。一些提议者负责收集交易，打包成区块（也叫collation），一些提议者负责提交collation 到链上（变成区块），最终，执行者根据被提议的collation给出一个新的状态根。

该提案从未得到完全的研究；因此，也没有对手续费支付机制的研究。除去别的因素，这项提案被弃用还因为，它的激励机制鼓励用户同时成为提议者、校勘者、执行者，以得到利益最大化。

Phase 1 and Done

Casey Detrio 在其开创先河的博文《Phase 1 and Done：数据可用性引擎——以太坊2.0》中强调：在phase 1 阶段，可以添加尽可能少的执行分片来桥接数据，而不需要做状态分片。在此方案中，分片可以做到两件事：1）对数据进行认证（ie 将一系列交易插入如Merkle 树等受认可的数据结构中）；2）执行简单的无状态操作，例如验证受认可数据的零知识证明。

可以通过上传合约到信标链（beacon chain）来定义一个数据块处理程序（合约未来会转为「预编译（precompiles）」，然后成为「执行环境（execution environment）」），合约的形式可能是客户端可解析的字节码，具体怎么选择要从视整个协议的内容而定。

「Phase 1 and Done」回避了大部分关于费用支付机制的问题，因为支付机制问题在以往的提案中都存在，而且也将继续存在，所以该提案转而试图定义为使Eth2.0 长期可用而需作出的最小变更，并且希望能尽快找出答案。还有个建议是通过以太坊1.x 上的合约来支付费用（区块提议者在以太坊2.0 上提供经过处理的可用数据块，然后我们通过一个rollup 合约在以太坊1.x 上付费给提议者）；不过这个可行性令人怀疑，因为这会使得以太坊2.0 的可用性强烈依赖以太坊1.x 。

Phase 2 Proposal 1

紧接着Detrio 的研究，Vitalik Buterin 对Phase 2 阶段提出了具体的新提案：phase 2 proposal 1。在此提案中，执行脚本（execution script，最初叫做「信标链合约」）存放在信标链上，以太币可以被存入执行脚本（为了支付费用），而且绝对不会脱离信标链；每个分片的状态和执行都是完全独立的。

请注意，它们的名字可能会有误导性——执行脚本乃是定义执行交易的虚拟机的规则，而非我们今天在以太坊看到的智能合约。执行脚本必须以客户端可解析、计量、编码的方式（例如ewasm 代码）定义数据模型及操作码。

为了支付费用，每个执行脚本本质上都是个layer-2 系统，验证者无法「得知」其内部的付费机制。这不是设计缺陷，而是故意为之的；如果要求分片验证者去解析和计算不同的费用机制（可能涉及不同货币），这无疑会导致实施难度及经济机制复杂性大幅增加，引入更多可能被攻击的弱点，甚至变得完全不可用。很大程度上，反对「经济抽象化」的理由也可以用于反对这种依脚本定义手续费种类的执行模式（译者注：「经济抽象化」也被称为「费用泛化」，在协议层支持用户及验证者自定义用何种代币来支付手续费。有人认为这会使原生代币失去价值根基）。

因为验证者无法直接从执行脚本中收取费用，他们必须通过其他方式拿到服务费。这里通过一个特殊的（即enshrined类型的）执行脚本完成；任何人都可以发送包含以下逻辑的交易：「如果在某分片中的某时隙打包了这个使用了某执行脚本的数据，则我要向记录这个数据块的人支付这笔费用」；这里的操作都是由中继者（也被称为操作者）完成：中继者负责收集用户的交易，根据非-enshrined普通执行脚本指定的规则收取费用，然后再向分片中的区块提议者（建块人）根据enshrined执行脚本支付打包交易的费用。

William Villanueva 的博客A Journey Through Phase 2 of Ethereum 2.0 对到这里为止的Phase 2 提案给出了完美的总结。

Phase 2 Proposal 2

受到Detrio 前期工作的启发，V 神再次提出Phase 2 Proposal 2，针对对提案1 进行简化，移除了分片链上状态，改用信标链追踪随分片各异、随执行环境（Execution Environment ， EE，原先叫执行脚本）各异的状态根。

这种设计的好处是，不同的执行环境能选择自己的累加器（例如：稀疏Merkle树、红黑树、密码学累加器，等等），而不像之前的提案，必须尊奉（enshrine）一种累加器形式。

现在，一般交易流程如下：用户创建交易并将其发送给中继者，中继者随用户需要添加见证（如果使用Merkle 累加器，则以Merkle 分支的形式添加）以获得用户支付的费用。接着中继者将多个交易进行打包，一起发送给区块提议者，并通过协议内置的机制向他们支付费用，让提议者将该批交易打包到下一个（分片）区块中。与提案1 一样，这里的「协议内置的机制」是指一个更高等的EE（an enshrined EE），所有验证者都能识别的EE。

对于验证者来说，此方案一定程度上减轻了他们的负担，但是由于以上操作仍需要一些分片状态，而该提案又没有设计用户与中继者的协议内费用支付机制，所以还没有解决中继网络的全部问题。首先，使用协议外手段进行支付会削弱用户的隐私保护；其次，我们不清楚要如何创建一个完全脱链的系统（不依赖于另一个外部的区块链）来保证用户和中继者一手交钱一手交货（即交易原子性）；第三，使用协议外手段进行支付的潜在高风险，以及成为中继者的高算力要求（因为中继者如果想服务某个EE 或分片，就必须存有他们的所有状态，才能能够生成见证），可能会导致中心化问题——在最糟的情况下，用户和以太坊2.0 网络之间可能只剩下几个「把关的」中继者。

回归交易缓存池模式

Vitalik 在新的提案中提到，让中继者有条件地向区块提议者付费，需要繁重的双重承诺方法来保证支付的原子性，因此，不如用一个手续费市场EE 来解决所有问题。在该提案中，EE 将具有自己的余额。EE 执行一批交易后会输出一个收据，负责支付费用的高等EE（enshrined EE）会根据这个数据，将以太币从该EE 账户转给区块提议者。因此，支付费用的高等EE 能够「回看」之前的收据并处理转账。而充值EE 账户可能就是中继者（或是其他利益相关方）的责任了。

这个提案的好处是，不需要通过什么复杂的方法来协调中继者和区块提议者之间的支付往来，但没有指明用户该怎么和中继者进行交互，只是建议使用支付通道。

基于最初的提案，Villanueva 建议回归交易缓存池模式。在这种情况下，中继者只需作为状态提供者，仅提供见证而不需要打包交易；区块提议者（或更普适地说，分片验证者）维护一个缓存池，合并所需的见证数据来打包交易。有鉴于每个EE 可以选择不同的累加器，因此EE 必须事先声明一个固定的合并见证的方法，让区块提议者可以整合两个及以上的见证，例如将多个Merkle 分支整合成一个Merkle 多重证明。

因为状态提供者只需要提供见证（通常以Merkle 分支的形式），目前已有的很多角色都可以胜任这个任务：如，轻客户端服务器。可以使用更方便的工具和更低的成本来激励更多轻客户端服务器提供见证，这对于高可靠性大有帮助。不过对于用户来说，不得不使用高摩擦力的支付渠道付费给状态提供者，仍然很令人头疼。

Phase 2 另类架构

就在不久之前，V 神提出了Phase 2 另类架构，打算完全去掉分片的状态。关键之处在于，在信标链中加入了完整的、有状态的、可表达的状态转换引擎（例如EVM）。这个引擎作为「调度员」，持续追踪EE 的状态根。调度员设计也让多分片事务执行成为可能：按照既定的顺序检查分片和时隙，以确保正确执行了跨分片到同一个EE 的多个交易（通过对执行前状态和执行后状态的状态根进行排列、忽略掉任何无效或乱序的分片区块）。

这个提案的费用支付机制与前一个提案相比没有什么变化，不过因为调度员具有足够的能力来处理EE 余额管理和收据消费，因此不再需要特定的支付费用EE 存在。

分片链简化提案

在DevCon 5 大会上，V 神发布了关于以太坊2.0 架构的重大重构消息，这是启发自Near 协议的分片块——夜影（Nightshade）的设计。在新的提案中，不要求每个分片链都运行相互独立的分叉选择规则，而是交错着以更快的速度生成区块和交联（crosslink）；分片中的区块紧随着信标链的区块一起生成，而且所每个分片都与每个信标链区块交叉连接（在正常情况下）。该体系结构增加了分片交叉链接的数量，为应对交联数量的增加，分片的数量从1024 减少到64 个；与此同时每个分片的吞吐量也有所增加，使整个系统的吞吐量保持原来水平。

上述思维模式的根本变化，使得费用市场变得更更加简单：由于分片数量大大减少，跨分片通信更为简化，用户大可直接在每一个分片上都存有Ether，直接给区块提议者支付（又可以通过前面提到的通过EE 输出收据的提案）。

消弭了大半的费用市场问题，现在只剩下中继网络（状态提供者）的挑战还依然存在。

提醒

以上关于以太坊2.0 的中继网路/费用市场的讨论，并非完全详尽的：

对于用户、中继者、区块提议者来说，大家都需要适当的付费激励及服务。用户可以通过付费得到所需的见证，中继者收取费用提供见证，而区块提议者收费打包交易。关于中继者向区块提议者付费（或间接的通过EE 付费）的方式，可以在协议内声明；但是用户希望一边要取得见证数据，一边要保证交易被打包，其付费的方式就没有那么单纯了。
对于用户来说，好的支付方法应该是低阻力的，方便其转换不同的中继者。但是依赖外部区块链的支付通道，存在预先支付押金及对外部链活性（liveness）的要求；理想的情况还是能在协议内解决用户支付的问题。
续上一点，应该让中继者难以审查用户。可惜的是，见证取自于内嵌的访问列表，因此没有办法阻止中继者设置黑名单。
验证者不必「理解」每个EE 内部的支付方式，因为这会极为复杂，对部署及建立有效的市场带来巨大的阻力。
用户不是非维护全节点不可（例如，不需要为了维护自己所需的见证而去维护）。我们希望这个提案对于轻客户端非常友好。
最后一点同样很关键：抵御DoS 攻击非常重要。按照见证的合并/刷新方式，很有可能会有向验证者发起的DoS 攻击。务必要当心有人利用这种漏洞。