这一篇会介绍Eth2.0 的客户端架构中共识和执行两个元件的拆分以及The Merge 对应用和开发者的影响。

在第一次写共识与执行拆分时，当时以为Eth 2.0 客户端架构中的共识层（Consensus Layer，以下代称CL）及执行层（Execution Layer，以下代称EL）拆分是真的在协议设计上将共识与执行分开，但其实只是Eth 2.0 客户端软体工程上的架构拆分而已，实际上共识和执行还是绑在一起的。

接下来会先介绍Eth 2.0 的CL 和EL 架构，然后会介绍The Merge 将PoW 并入PoS 链后，对应用及开发者的影响。

将客户端再细分为CL 及EL

Eth 1.0 及Eth 2.0 的共识机制

Eth 1.0 的共识机制由PoW 和Fork Choice Rule 组成，节点在收到一个新的区块时，先验证PoW 的有效性，接着比对新的链所累积的work 是否是最高的，如果是的话就采用新的链。

Eth 2.0 也是一样的组成，只是PoW 换成PoS，而是否选择新的链在于验证者（Validator）的见证（Attestation）数量，如果一个区块被越多验证者见证则它的权重越高，而节点会选择权重高的链。

执行、验证交易

上一段讲到节点收到一个新的区块时所执行的步骤其实还少了一步：执行、验证区块里的交易，确保交易是有效的。因为其他节点不会接受包含无效交易的区块，收录这样的区块会导致你的链分叉出去。

在Eth 1.0 的客户端中，验证PoW、Fork Choice Rule 和执行验证交易是绑在一起的。当你跑起Geth，每次它收到新的区块就会执行这三个步骤。但在Eth 2.0 的客户端中，这三个步骤被分开了：验证PoS 和Fork Choice Rule 交给CL，执行验证交易交给EL。

例如当前的Eth 2.0 客户端之一Prysm 就是一个CL，那EL 是谁呢？答案是目前还没有。目前的Beacon chain 节点都是对一个一个装着无意义内容的Dummy 区块去达成共识，但在The Merge 之后，原本的Geth 就会放下验证PoW 及Eth 1.0 Fork Choice Rule 的工作，专门负责执行验证交易，变成Eth 2.0 的EL。

CL 和EL 的合作方式

拆成CL 和EL 元件之后表示你可以选择跑起自己的CL（例如Prysm），但是EL（例如Geth） 是和其他人一起共用，其实就像现在的矿池一样，你加入矿池只负责算PoW，不负责验证交易或是打包交易。或是你也可以自己跑CL 和EL。

而CL 和EL 之间会透过一层定义好的API （叫做Engine API）来沟通。每当CL 收到新的区块时，它会将里面的EL 相关内容送去请EL 验证，并依照EL 的回覆内容决定区块是否合法。如果区块合法且依照CL 的Fork Choice Rule 判断，选择将该区块所代表的链作为最长链，则CL 会去通知EL「目前最新的区块是这一个区块，请套用里面的交易并算出最新的State 并更新」。

不过CL 和EL 分拆之后，也代表它们是各自独立的，不只是开发者、使用者要和它们个别互动，CL 和EL 彼此之间的p2p 网络也是独立的。

原本开发者熟悉的取用链上资料的 web3.eth 用法还是会照旧，web3.eth背后会去EL （一样是Geth）拿资料。如果是需要共识、PoS 相关的资料，要透过新增的 web3.beacon 方法去拿，web3.beacon背后会去CL 拿资料。而CL 和EL 会分别使用不同的p2p 网络去和其他CL 或EL 沟通：EL 还是使用原本的Eth 1.0 的devp2p，CL 则是使用Eth 2.0 的libp2p。

基本上就想像成原本的Geth 节点（包含p2p 网络）都照旧继续运作，只是共识（PoW、Fork Choice Rule）的元件被拔掉，交给另一个独立的节点（CL，例如Prysm）来负责。开发者所使用的web3 套件例如web3.js 或ethers.js 会自动将不同指令送到不同节点，开发者不需要担心。

这里可以注意的是EVM 交易还是会走原本的devp2p 网络送到EL 节点而不是CL 节点，表示如果你的CL 节点是一个准备要propose 区块的验证者时，它会需要去请EL 帮它组EL 区块，里面放的是EVM 交易。CL 自己也要组CL 的区块，只是里面放的是Attestation，和EVM 无关。

The Merge 的影响

The Merge 还要一段时间才会发生，虽然对开发者影响不大，但有时间还是可以提早想一下你的项目、应用或使用的服务是否会受到影响，并提早规划迁移。尤其是使用区块资讯当乱数来源的应用。

区块时间

在PoS 中，区块间隔会固定为12 秒产出一个区块，每12 秒称作一个slot。每个slot 会有一个验证者被选到负责propose 区块，如果验证者不在线上或来不及送出区块，这个slot 就会被其他验证者视为空的slot，也就导致下一个区块要再延迟12 秒才会产出。

DIFFICULTY opcode 改名并被挪用

首先因为没有PoW，也就再没有难度（Difficulty）的概念，但为了向下兼容（让使用到DIFFICULTYopcode 的合约不会直接坏掉），所以DIFFICULTYopcode 将改名为PREVRANDAO，并且这个值会改成放每一个slot 由验证者们累积产生的乱数值。所以原本有用到 DIFFICULTY 这个opcode 的合约在The Merge 之后，就不能再假设这个值会继续递增，而是会是一个乱数。

BLOCKHASH opcode 的值将更好被操控

Block Hash 由区块内容决定，虽然区块内容都是矿工决定，但因为里面包含PoW 算出来的结果，所以要藉由操控区块内容来影响Block Hash 并非易事，而且是有机会成本的（矿工算出PoW 结果，但填入区块后发现得出的Block Hash 不满意，此时如果它放弃并重算PoW 就代表它放弃了这次的区块奖赏机会）。因此，有些合约会利用BLOCKHASHopcode 的值来当作乱数来源。

但在PoS 后已经不用算PoW，所以验证者（PoS 的矿工）要操纵区块内容（即操纵Block Hash）可说是易如反掌。不过如果合约还是需要乱数来源，可以用上一段提到的PREVRANDAOopcode，虽然还是有被操纵的风险，这个乱数来源会比PoW 更随机、更难操纵。

因为这个随机值是一个经过每一个slot 不断融入不同验证者所提供的乱数而被不断更新、累加的乱数，所以一个验证者能影响随机值的范围很有限。最多能做的就是在他该propose 区块的slot 选择不做事，让随机值到下一个slot 保持一样（如果这么做对他有利的话）。或是攻击者很有钱运气也很好，刚好连续好几个slot 都是由他掌控的验证者来propose 区块。

Finality

这是PoS 带来最大的影响之一，我们有了比Block Confirmation 更可靠的Finality 参考：如果网络运作正常且没有攻击者，则约2 个epoch（约12 分钟左右）区块会被Finalized，被Finalized 就代表这个区块可视为不会被推翻，除非攻击者愿意牺牲大量的押金来试图推翻这个区块。

Fork Choice Rule 及Safe Head

12 分钟的Finality 时间对某些应用来说可能还是有点久，有没有其他折衷方法？有的，新的区块还是会被不断产出，并在12 分钟后被Finalized，在这期间区块还是有可能因为网络问题而分叉，因此节点还是要有一套Fork Choice Rule 来在这期间找出最长链。

当然，这些还未Finalize 的区块对应用来说，其实就和PoW 一样，要透过Block Confirmation 机制来做机率上的确保。不过相比于PoW，PoS 能更细致的去计算这个机率，因为PoS 的每个区块所纪录的是验证者们的Attestation，区块里收录的Attestation 的数量可以让验证者有一个相比于「收录或不收录这个区块」更细致的参考：「这个区块只有1/6 的验证者的Attestation，抖抖的，被分叉淘汰的机率颇高」、「这个区块有3/4 的验证者的Attestation，稳了，要出现2/3 验证者冒险分叉出去的机率很低」。

因此，这个新的Fork Choice Rule 也会引入一个新的时间标签safe。原本开发者熟悉的是默认的 latest 时间标签：请节点给你最新收到的区块里的资讯。而 safe 标签就是请节点给你它经过Fork Choice Rule 计算后，觉得够稳妥的区块的资讯。在正常情况下，safe标签的区块会落后 latest 标签的区块大约四个区块的时间。所以在The Merge 之后，开发者要注意web3 套件预设会是使用 latest 还是safe，以及你的应用想要使用的标签。

本文链接地址：https://www.wwsww.cn/jishu/12913.html
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。