Ethereum 2.0 基本架构理解
Ethereum （以下简称 eth）2.0 从 2018 年提出改进到现在已经 4 年了。现有的 eth 1.0 是基于 pow 共识的链。pow 共识主要存在以下问题：
浪费能源。
性能低，每秒只能处理十几笔交易。
数据完全集中存储在一个节点。
算力集中问题，芯片巨头理论上有 51% 算力攻击能力。
eth 2.0 最核心的改动是把 pow 换为 pos，和分片链。eth 2.0 最主要的目标有：
- 数据的读写分片，解决 block 数据读写在一个节点的问题。
- 通过 pos 算法提高 TPS
- 防止过度中心化
- 平民化，任何民用的机器（树霉派都行）只要质押 32 个 ETH 都能成为 validator 节点
以下是 eth2.0 基本架构 
上图解释： beacon chain 是个单独的链，它协调所有的 sharding chain。注意上面图里面的 shard 1～shard 100。它表示一个 beacon chain 的 block 负责管理 1～100 的 shard block。
eth1.0 到 2.0 以 phase 的形式进行迭代。具体的时间节点从 2018 年开始。（很明显，已经 delay 很久了）
Phase 0： 构建 beacon chain 网络。
Phase 1： 构建分片网络，让数据读写分片。
Phase 2： EVM 可支持分片网络。
以下是各项升级涉及到的一些技术细节，你可以到这里深入了解里面的具体技术。
beacon chain 网络
beacon chain 网络是整个 eth2.0 非常关键的一环，它负责 validator 的注册和质押，以及随机的分配 validator 到一个 committee 进行 pos 投票。为了保证区块的随机性和防止做假预测， eth 2.0 引入了 RANDAO（随机数生成器）random+DAO。它的简要原理如下：
设想一堆人坐在一个房间，每个人任意给一个数字，最后给出数字的那个人把其他人给出的数字加总，然后以此做为随机数 seed。为了防止最后一个人给出他自己可以预测的数字进行做假，他需要做一轮 VDF（Verifiable Delay Functions） 运算得出一个最终的随机数。
beacon chain 也是一个 block chain 系统，它需要 validator 通过 pos 共识算法给每一个 block 进行投票。每 12 秒会有一个时间同步 slot， 每个 slot 里面会产生一个 block。32 个 slot 组成一个 epoch。这里 slot 和 epoch 的作用先按下不表，下文再做介绍。先说下投票的过程。
在每轮 epoch 里，validator 将会被随机分配到一个 committee 进行投票。每个 slot 会随机选一个 proposer 做为 block producer（出块者）。 其他的 validator 会投票（POS）验证成这个块是否合法。如果超过三分之二同意就通过，高于三分之一的反对票则无法达成共识。（拜占庭共识）。一个 validator 有可能同时兼具 proposer 和 validator 角色，但这种情况比较罕见。
为防止共谋发生，每轮 epoch 中 validator 只会被随机的分配到一个 committee 里面。每个 committee 不会让他们连续投相邻两个区块的票。eth2.0 在数学上保证超过三分之一 validator 共谋的概率是万亿分之一。
从以上我们可以看出 slot 的作用是给 validator 之间的分布式环境做同步用的，还有就是每个 slot 的分割投票减少 validator 的共谋，每轮 epoch 后 validator 和 committee 会重新进行洗牌投票。
现在的 beacon chain 只运行了 pos 的投票验证，还未见到任何和 sharding block 有关的数据详情见 beaconscan。也未见到如何把 beacon chain 和 sharding chain 联合起来的方案（欢迎留言补充）。不过社区已经有不少关于 sharding chain 的讨论，我们可以初探一下。
sharding chain
eth2.0 把 shred（分片） 分为 64 个。每个 shred 只负责它自己内部的数据读写，涉及到跨链的读写操作需要 beacon chain 进行协调。这里sharding chain 有个关键的问题需要解决，就是执行交易和合约时需要全局的数据，如何与其他节点高效的进行交互？社区讨论的有两种方案，同步和异步：
-
同步
同步的改两个 shred 的 block。两边必须进行状态同步通信。 -
异步
假设有一笔跨 shred 的交易需要从 shred A 里的 账户a 里减 10 块钱，然后到 shred B 里面的 账户 b 里加 10 块钱。 shred A 先创建好一个 receipt（扣掉 a 的钱，目标账户地址，目标 shred，金额）。 shred B 拿到这个 receipt 后会先执行验证，验证成功后往账户 b 里面加 10 块钱。这个 receipt 必须要可验证，还要防止 double spending，需要给这个 receipt 赋一个唯一的自增长 ID 存在 shred A 中。shred B 只要去追踪源 shred A 里面的这个 ID 就能知道这笔钱有没有被花掉。
这里需要注意的是有一个中间状态，就是 sharding A 把钱扣掉了，然后创建 receipt。sharding B 再把创建好的 receipt 状态同步到它自己的 shred 里。
Eth 2.0 的共识层和执行层分工及合并影响
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，以及你想要使用的应用的标签。