Eth 2.0 的共识层和执行层分工及合并影响

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

在第一次写协议与代执行协议时，当时认为 Eth 2.0 客户端架构中层的共识层（Consensus Layer，以下 CL）及执行（以下代 EL）协议是真正在设计中上将共识与执行单独分开，但实际上只是将Eth 2.0工程上的架构解析出来，实际上的共识和执行还是绑定的。

写共识和捆绑是什么意思，可以参考我后来成执行的结果：
以太坊公益与改善方案
本文将介绍以太坊的促进作用以及将交易执行从共识中分离出来如何提高效果。


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

将客户端再细分为CL及EL
这里的资料参考 Hsiao-Wei Wang 的 《以太坊 The Merge 合并之技术面懒人包（2022-04版）》 的文件，里面有很多链接。

Eth 1.0 及 Eth 2.0 的共识机制
Eth 1.0 的共识机制是由 PoW 和 Fork Choice Rule 组成的，节点在一个新的最高区块时，首先是验证 PoW 的有效性，如果比对新的链所收集的工作是否是真实的，采用新的链。

Eth 2.0 也是一样的组成，只是 W 换成的也是一样的组成，只是 W 换成的，而它是否选择的链验证者（Validator），它是 Po 的验证（Attestation）数量，新的验证者同时也是验证者的验证者节点会选择权重高的链。

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

在 Eth Eth 1.0 的客户端中，验证 PoW、Fork Choice Rule 和执行交易是绑定的。当你跑起来验证时，每次执行它收到的新的这三个步骤。但在 Eth 2.0 客户端中，这三个步骤被分别和了：验证PoS选择规则交给CL，执行验证交易交给EL。


Eth 1.0 的区块
例如当前的 Eth 2.0 客户端的一个 Prysm CL，那个 EL 是谁？在 Merge 中，原本的 Geth 是接下来验证 PoW 及 Eth 1.0 的选择规则的工作，负责执行 Fork 的验证交易，变成 Eth 2.0 的 EL。


Eth 2.0 的区块，可以看到 EL 的内容/内容和 Eth 1.0 的区块是一样的

CL 和 EL 的合作方式
拆成CL和EL之后组件表示你可以选择跑但是自己起CL（比如Prysm），EL（比如Geth）是和其他人一起共用的，就像现在的矿池一样，你加入矿池只负责算PoW，不负责替换交换包交易。你也可以自己跑 CL 和 EL。

并且 CL 之间会定义良好的 API（引擎 API）来启用。每当 CL 收到新的分期时，相关的它就将其送去的 EL 内容命名为请 EL，并根据 EL 的如果区块且根据 CL 的选择规则判断，作为 CL 选择的区块所代表的链上最长链通知，EL「目前的区块是这块区域」块，请套用里面的交易并算出最新的状态并更新”。


CL 和 EL 之间的互动
CL和EL分开之后，也代表自己的独立和独立网路之间的，不只是、使用它们的EL和它们各自独立和独立的，CL和它们之间的p2路也是独立的。

原本开发者的取用链上资料的web3.eth用法还是会照旧，背后会web3.eth去拿资料。而CL和EL会分别使用不同的p2p网路去和其他CL或EL可以：EL还是使用原本的Eth 1.0的devp2，CL分别使用Eth 2.0的libp2p。web3.beaconweb3.beacon


CL 和 EL 之间的互动及和外部的互动方式
比如说原来就想像成原本的Geth节点（包含p2p网路都照旧使用CL路，只是为了共识（PoW、k Choice Rule）的组件被拔掉，以独立的节点（Prysm）来负责开发者所使用的 web3 套件 web3.js 或 ethers.js 会自动将例如不同的指针指向不同的节点，开发者不必担心。

这里可以注意的是EVM交易还是会走的devp2p网路前往EL节点而不是CL节点，表示如果你的CL节点是一个准备去提议区块的验证者的时候，它需要EL帮它帮忙组自己的区块，里面放的是 EVM 交易。CL 必须是 CL 的区块，只是里面放的是 Attestation，和 EVM 的各种交易。

合并的影响
合并以后会发生使用服务，虽然对开发者有影响，但不大可能会提早想一下你的项目、应用程序或应用程序是否会受到影响，提早迁移。资讯当乱数来源的应用程序。

合并如何影响以太坊的应用层
注意：这篇文章于 2022 年 3 月更新，以反映对规范的最新更改。其中包括重命名。

区块时间
在 PoS 每隔 12 秒选一个时段 2 个时段。每一个时段，每个时段负责一个时段，每个时段负责一个时段，每个时段将有一个验证者提议，如果验证者不在线上或不来及送出区块，请务必被其他验证者用这个空位培育下一个区块，延迟 12 秒的插槽，再有时间。

DIFFICULTY 操作码改名并被挪用
首先因为没有PoW，再改一次没有难度（Difficulty）的概念，但为了让这个改变会导致使用到DIFFICULTYopcode的合约直接掉掉），所以DIFFICULTYopcode将被命名为PREVRANDAO，并且把每一个都改成放一个由验证所以他们会产生乱序的数字。本来可以用来DIFFICULTY 在这个操作码的合约中合并的，就不能再假设这个值之后会继续递增的数字，会是一个乱序的数字。

BLOCKHASH opcode 的价值将被美食享用
Block Hash 区块的内容是由矿工决定的，但里面的内容是由矿工计算出来的结果，所以要由区块链决定，因为区块链的内容是由区块链决定的，而且是区块链的内容，不是很容易决定的。矿工算算PoW结果，因此代表入网后出块发现结果的Block Hash不满意，此时如果它放弃并重算PoW就放弃了本次的区块奖赏机会）。，某合约会使用BLOCKHASHopcode的值来假成乱数来源。

PREVRANDAO但在 Pos 的验证者（Pos 的矿工）要在 Pos 的内容中找到（即图块），可以说是如反掌。，虽然还是有被会的风险比Po更频繁、更难的，这个数据源乱七八糟。

因为这个验证者所提供的任意一个经常不断变化的数值，是一个不同的验证者所提供的数字，所以每个验证者的范围很可能是有限的。该区块的槽位选择不做事，让每个槽位保持不变（如果这样做是对他有价值的话）。区块链的验证者来提议。

详细关于PREVRANDAO opcode 的安全性分析可以参考EIP 4399 的安全性分析章节。

确定性
这是 PoS 带来的比最大的影响之一，我们有了 Block Confirmation 更可靠的 Finality 参考：如果网路准许正常且没有攻击者，则约 2 个 epoch（约 12 分钟左右）区块会被 Finalized，最终，这个区块被代表的形象为被揭开，而最终的承诺就不会留下纪念者的牺牲。

叉子选择规则及安全头
12 确定性 对某个应用的时间可能有点久，有没有其他的方法，然后再一分钟还是会被不断的结果，并在 12 被最终确定，在这期间还是有可能因为网路的问题分叉，因此我仍然在这期间有一条叉路，因为网路选择规则而链。

当然，这些区块对应用来说，就和 PoW 一样，要通过区块确认机制来做机率上的确保。每个区块所记录的是验证者他们的证明，区块里的证明的这个数量可以让验证者有一个比“收录或不区块”更录影的参考：“这个区块里的证明”只有 1/6 的验证者的 Attestation，抖音的，被分叉的传播者的机率要颇高”、「这个区块有 3/4 的验证者的验证，稳了，出现 2/3 的验证者冒险分叉出去的机率很低”。

因此，这个新的分叉选择规则会带来一个新的时间标签safe。原本开发者看似默认的latest时间标签：请节点给你最新收到的区块里的信息。而safe标签就是请节点给你的是它的时间标签。 Fork Choice Rule 计算后，觉得够稳妥的标签的信息。在正常情况下，标签的区块会延续的大约四个区块的时间。所以在 Merge 中，开发者要注意safeweb3latest默认会是使用latest还是safe，以及你想要使用的应用的标签。