编者按：本文来自以太坊爱好者，作者：JohnAdler，翻译&校对:IANLIU&阿剑，Odaily星球日报经授权转载。
导语：本文将总结现有围绕着以太坊2.0Phase2的研究成果，重点关注中继网络以及手续费机制。每种提案都有其不同的权衡取舍，而且被不同的平台所采用，因此做一次合理且全面的汇总，能让新入门的研究者更快上手。背景
在深入讨论中继网络之前，我们先回顾一下以太坊的主要瓶颈之一：状态。在以太坊中，状态指的是账户余额、合约代码、合约存储内容的集合。不论什么时候执行交易，都要对状态进行读写操作。早些时候，人们曾对以太坊计算模型原生的不可扩展性提出过质疑；但时至今日，反而是状态的读写成为执行交易的成本瓶颈，磁盘的I/O性能成了运行以太坊全节点的制约因素。请注意，为了能够按照富状态范式执行任何的交易，全节点必须保证所有状态始终放在可访问的位置。如果应用在单一区块链的场景，或许这还能勉强接受，但是一旦面临分片、面临分片上委员会的重组，这种要求是非常不合理的。设想一下，每当验证者被指定到一条分片链，他就得同步该分片上的所有状态；则这种系统就等价于单一区块链，只是此时的区块大小等于分片区块大小*分片数量。这就是为什么我们需要无状态客户端。分片及无状态客户端
在无状态客户端范式中，验证者只需要存储一个经过压缩的区块链状态表，大幅降低了执行交易的负担。一般来说累加器的大小是常量，不过也有可能是对数大小。无状态客户端的本质是，每笔交易都附带当前累加器的见证数据，见证数据中包含了所有执行该交易所需的信息。在以太坊中，使用稀疏Merkle树作为累加器，一笔交易所涉及的所有状态元素都可以被包含进默克尔树分支中。在其他应用上，无状态客户端可以缩短以太坊节点的初次同步时间，这就是BeamSync的原理。备注：有一些密码学累加器比Merkle累加器性能更好，但是这种累加器需要受信任初始化，或是使用未验证的前沿密码技术，所以安全部署到生产系统上还需要点时间。但无状态客户端也有自己的挑战：一旦使用Merkle累加器，每当结束一次完整的执行后，见证就过期了。如果模型要求每笔交易都包含单独的见证，然后顺序执行这些交易，则排在后头的交易的见证数据就会过期，必须能够随着前面每一笔交易结束而更新自己的见证。幸亏更新这些Merkle累加器的见证涉及零哈希开销方法——如果见证数据可以作为附加物添加到“一大包”交易上的话，就不需要更新属于每笔交易的单独见证，或是说可以整合为多重证明。假如所有用户都维护着全节点，并实时更新见证的状态，那么无状态客户端系统是能够马上被采用的。可惜在分片环境下，这意味着要求所有用户维护自己所在分片上的所有状态；这样做不仅不切实际，而且就如我们上面提到的，这就相当于只是建立一条区块体量更大的单一区块链。为了解决问题，这里引入了中继者的概念。中继者负责提供用户所需的见证，并以此向用户收取服务费。和用户不一样，中继者可以将服务聚焦在单一分片上；但中继者无法预知用户什么时候需要状态，因此必须保证见证的及时更新，也就是实时存储状态，以供用户获取。中继者的引入也会引来一大堆复杂的问题，也是以太坊2.0的全面部署所面临的最重要的开放问题之一。第一点，如果不能很好地平衡中继者和区块提议者所得到的利益，验证者就会被激励成为中继者，则相关服务的获取成本可能会让一般使用者望而却步。第二点，要让中继者能够从用户和验证者处收取费用），同时不至于引入太大的开销，显然不是件简单的事；换言之，验证无状态交易很容易，但是提供必要的见证很困难。中继网路及费用市场提案
以太坊2.0Phase2的设计空间很大，也出现了很多对执行模式的提议。每种提议都各自表述了如何通过付费，结合中继网路的机制，将交易更好地在用户和区块提议者之间进行传递。本章节会尽可能简洁而全面地总结不同的协议，并着重分析它们在中继网路及手续费机制上的异同。校勘者提案
这是Phase2阶段的早期提议，将分片链的建块分为三个部分：提议者、校勘者、执行者。一些提议者负责收集交易，打包成区块，一些提议者负责提交collation到链上，最终，执行者根据被提议的collation给出一个新的状态根。该提案从未得到完全的研究；因此，也没有对手续费支付机制的研究。除去别的因素，这项提案被弃用还因为，它的激励机制鼓励用户同时成为提议者、校勘者、执行者，以得到利益最大化。Phase1andDone
CaseyDetrio在其开创先河的博文《Phase1andDone：数据可用性引擎——以太坊2.0》中强调：在phase1阶段，可以添加尽可能少的执行分片来桥接数据，而不需要做状态分片。在此方案中，分片可以做到两件事：1）对数据进行认证；2）执行简单的无状态操作，例如验证受认可数据的零知识证明。可以通过上传合约到信标链来定义一个数据块处理程序”，然后成为“执行环境”），合约的形式可能是客户端可解析的字节码，具体怎么选择要从视整个协议的内容而定。“Phase1andDone”回避了大部分关于费用支付机制的问题，因为支付机制问题在以往的提案中都存在，而且也将继续存在，所以该提案转而试图定义为使Eth2.0长期可用而需作出的最小变更，并且希望能尽快找出答案。还有个建议是通过以太坊1.x上的合约来支付费用；不过这个可行性令人怀疑，因为这会使得以太坊2.0的可用性强烈依赖以太坊1.x。Phase2Proposal1
紧接着Detrio的研究，VitalikButerin对Phase2阶段提出了具体的新提案：phase2proposal1。在此提案中，执行脚本存放在信标链上，以太币可以被存入执行脚本，而且绝对不会脱离信标链；每个分片的状态和执行都是完全独立的。请注意，它们的名字可能会有误导性——执行脚本乃是定义执行交易的虚拟机的规则，而非我们今天在以太坊看到的智能合约。执行脚本必须以客户端可解析、计量、编码的方式定义数据模型及操作码。为了支付费用，每个执行脚本本质上都是个layer-2系统，验证者无法“得知”其内部的付费机制。这不是设计缺陷，而是故意为之的；如果要求分片验证者去解析和计算不同的费用机制，这无疑会导致实施难度及经济机制复杂性大幅增加，引入更多可能被攻击的弱点，甚至变得完全不可用。很大程度上，反对“经济抽象化”的理由也可以用于反对这种依脚本定义手续费种类的执行模式。因为验证者无法直接从执行脚本中收取费用，他们必须通过其他方式拿到服务费。这里通过一个特殊的执行脚本完成；任何人都可以发送包含以下逻辑的交易：“如果在某分片中的某时隙打包了这个使用了某执行脚本的数据，则我要向记录这个数据块的人支付这笔费用”；这里的操作都是由中继者完成：中继者负责收集用户的交易，根据非-enshrined普通执行脚本指定的规则收取费用，然后再向分片中的区块提议者根据enshrined执行脚本支付打包交易的费用。WilliamVillanueva的博客AJourneyThroughPhase2ofEthereum2.0对到这里为止的Phase2提案给出了完美的总结。Phase2Proposal2
受到Detrio前期工作的启发，V神再次提出Phase2Proposal2，针对对提案1进行简化，移除了分片链上状态，改用信标链追踪随分片各异、随执行环境各异的状态根。这种设计的好处是，不同的执行环境能选择自己的累加器，而不像之前的提案，必须尊奉一种累加器形式。现在，一般交易流程如下：用户创建交易并将其发送给中继者，中继者随用户需要添加见证以获得用户支付的费用。接着中继者将多个交易进行打包，一起发送给区块提议者，并通过协议内置的机制向他们支付费用，让提议者将该批交易打包到下一个区块中。与提案1一样，这里的“协议内置的机制”是指一个更高等的EE，所有验证者都能识别的EE。对于验证者来说，此方案一定程度上减轻了他们的负担，但是由于以上操作仍需要一些分片状态，而该提案又没有设计用户与中继者的协议内费用支付机制，所以还没有解决中继网络的全部问题。首先，使用协议外手段进行支付会削弱用户的隐私保护；其次，我们不清楚要如何创建一个完全脱链的系统来保证用户和中继者一手交钱一手交货；第三，使用协议外手段进行支付的潜在高风险，以及成为中继者的高算力要求，可能会导致中心化问题——在最糟的情况下，用户和以太坊2.0网络之间可能只剩下几个“把关的”中继者。回归交易缓存池模式
Vitalik在新的提案中提到，让中继者有条件地向区块提议者付费，需要繁重的双重承诺方法来保证支付的原子性，因此，不如用一个手续费市场EE来解决所有问题。在该提案中，EE将具有自己的余额。EE执行一批交易后会输出一个收据，负责支付费用的高等EE会根据这个数据，将以太币从该EE账户转给区块提议者。因此，支付费用的高等EE能够“回看”之前的收据并处理转账。而充值EE账户可能就是中继者的责任了。这个提案的好处是，不需要通过什么复杂的方法来协调中继者和区块提议者之间的支付往来，但没有指明用户该怎么和中继者进行交互，只是建议使用支付通道。基于最初的提案，Villanueva建议回归交易缓存池模式。在这种情况下，中继者只需作为状态提供者，仅提供见证而不需要打包交易；区块提议者维护一个缓存池，合并所需的见证数据来打包交易。有鉴于每个EE可以选择不同的累加器，因此EE必须事先声明一个固定的合并见证的方法，让区块提议者可以整合两个及以上的见证，例如将多个Merkle分支整合成一个Merkle多重证明。因为状态提供者只需要提供见证，目前已有的很多角色都可以胜任这个任务：如，轻客户端服务器。可以使用更方便的工具和更低的成本来激励更多轻客户端服务器提供见证，这对于高可靠性大有帮助。不过对于用户来说，不得不使用高摩擦力的支付渠道付费给状态提供者，仍然很令人头疼。Phase2另类架构
就在不久之前，V神提出了Phase2另类架构，打算完全去掉分片的状态。关键之处在于，在信标链中加入了完整的、有状态的、可表达的状态转换引擎。这个引擎作为“调度员”，持续追踪EE的状态根。调度员设计也让多分片事务执行成为可能：按照既定的顺序检查分片和时隙，以确保正确执行了跨分片到同一个EE的多个交易。这个提案的费用支付机制与前一个提案相比没有什么变化，不过因为调度员具有足够的能力来处理EE余额管理和收据消费，因此不再需要特定的支付费用EE存在。分片链简化提案
在DevCon5大会上，V神发布了关于以太坊2.0架构的重大重构消息，这是启发自Near协议的分片块——夜影的设计。在新的提案中，不要求每个分片链都运行相互独立的分叉选择规则，而是交错着以更快的速度生成区块和交联；分片中的区块紧随着信标链的区块一起生成，而且所每个分片都与每个信标链区块交叉连接。该体系结构增加了分片交叉链接的数量，为应对交联数量的增加，分片的数量从1024减少到64个；与此同时每个分片的吞吐量也有所增加，使整个系统的吞吐量保持原来水平。上述思维模式的根本变化，使得费用市场变得更更加简单：由于分片数量大大减少，跨分片通信更为简化，用户大可直接在每一个分片上都存有Ether，直接给区块提议者支付。消弭了大半的费用市场问题，现在只剩下中继网络的挑战还依然存在。提醒
以上关于以太坊2.0的中继网路/费用市场的讨论，并非完全详尽的：对于用户、中继者、区块提议者来说，大家都需要适当的付费激励及服务。用户可以通过付费得到所需的见证，中继者收取费用提供见证，而区块提议者收费打包交易。关于中继者向区块提议者付费的方式，可以在协议内声明；但是用户希望一边要取得见证数据，一边要保证交易被打包，其付费的方式就没有那么单纯了。对于用户来说，好的支付方法应该是低阻力的，方便其转换不同的中继者。但是依赖外部区块链的支付通道，存在预先支付押金及对外部链活性的要求；理想的情况还是能在协议内解决用户支付的问题。续上一点，应该让中继者难以审查用户。可惜的是，见证取自于内嵌的访问列表，因此没有办法阻止中继者设置黑名单。验证者不必“理解”每个EE内部的支付方式，因为这会极为复杂，对部署及建立有效的市场带来巨大的阻力。用户不是非维护全节点不可。我们希望这个提案对于轻客户端非常友好。最后一点同样很关键：抵御DoS攻击非常重要。按照见证的合并/刷新方式，很有可能会有向验证者发起的DoS攻击。务必要当心有人利用这种漏洞。总结回顾过去的一整年，围绕着中继网络及费用市场的研究进行了多次迭代，致力于给用户和轻节点带来良好的使用体验的同时，降低验证者负担，尽可能保证免准入性。展望未来，我们希望看到更多关于Phase2的提案，进一步改进和完善以太坊2.0的各个层面！注：原地址：https://medium.com/
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。