P2P 接口（1、本日以太坊上的生意业务 gossip，2、状态同步，3、没有 eth1 分片区块 gossip）；

除了验证者外，许多用户 / 应用措施节点也大概利用无状态或半状态的 eth1 引擎运行。利用瘦 eth2 客户端，来跟从 eth1 分片链的头部，并以无状态或半无状态的方法与其交互。

图片来自：tuchong.com

由于 eth1 引擎完全依赖 eth2 客户端敦促共鸣，因此我们提议 eth2 客户端与 eth1 引擎之间的通信，都是 eth2 客户端挪用的 eth1 引擎上的所有要领（譬喻 addBlock， getBlockProposal 等）。这将强制执行一个 leader/follower 干系，以低落系统推理的巨大性，并限制 eth1 引擎所需的业务逻辑。

eth2 有一种与焦点共鸣相关的状态，这就是所谓的「信标状态」（beacon-state）。信标状态数据很小（约莫只有 10-40MB，取决于验证者集的巨细），它包括了领略焦点共鸣及如那里理惩罚分片链所需的所有信息。事实上，要处理惩罚分片链中与共鸣相关的部门，客户端必需可以或许会见信标状态（譬喻，运行分片链分叉选择的最新交联 crosslink、验证分片链签名的当前验证集或 shuffling 随机分派）。

eth1 分片区块是从隶属 eth2 客户端提供应 eth1 引擎的。包括在这些区块中的生意业务，应该以雷同于当前以太坊主网 PoW 区块的方法从存储池中排除。

EVM 虚拟机（eth1 分片区块的执行与验证）；

在 eth2 协议中，所有区块（信标区块、分片区块、eth1 分片区块）必需由 PoS 验证者按照焦点共鸣举办出产及签名。为此，eth2 客户端最终要认真所有区块的出产。

从焦点共鸣的角度来看，eth2 客户端认真并敦促信标链、数据分片链以及 eth1 分片链的构建。eth2 客户端通过 RPC 直接提供有关 eth1 引擎关于 eth1 分片链和焦点共鸣（信标链 / 状态）的任何常识。

本日，eth1 客户端具有相对简朴且较薄的共鸣层，它只有一条链，而且 PoW 可处理惩罚协议外硬件中的大部门巨大性。eth1 客户端的大大都巨大性及优化，都位于用户层（包罗状态存储 / 打点、状态同步、虚拟机执行、生意业务处理惩罚、生意业务池等）。

思量到 eth1 和 eth2 客户端实现的多样性，这种要领可以防备客户端软件在任一侧锁定，答允客户端团队保持独立，并专注于他们本身的研发事情，使软件项目在很洪流平上保持不变，以便举办快速原型建造。

eth1 引擎险些会以当前以太坊沟通的方法，维护用户生意业务 gossip 以及 eth1 生意业务储存池。同样的网络协议和当地机制，可以用于 gossip 及存储池的维护，为区块的出产做好筹备。

而要领略本文的内容，前提条件是需要你根基熟悉以太坊 2.0 以及无状态以太坊的观念。

更明晰地界说用于驱动 eth1 引擎的通信协议，譬喻 new_head(block)、validate_block_transition(block)、get_proposal(parent_root) 等；

对付 eth1 分片区块，eth2 客户端当即 / 随时会见 eth1 状态、生意业务和其它底层 eth1 布局，以生成有效区块。相反，当指定验证者生成 eth1 区块时，eth2 客户端从 eth1 引擎请求一个可行的 eth1 区块数据（TX、状态根等）。然后，eth2 客户端将此 eth1 区块数据打包到完整的分片区块中（添加 slot、positer_index、positer_signature 等），并将该区块广播至网络。

eth1 成果（状态、生意业务等）由 ENR 中的现有 eth （或新 eth1） key 暗示。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。