11月27日，以太坊开发者Mikhail Kalinin提出了一种名为「可履行信标链」的Eth1-Eth2过渡提案，据悉，该提案的开端想法来自以太坊联合创始人Vitalik Buterin，其旨在将eth1数据（买卖、状况根等）嵌入到信标区块中，并强制信标链提议者生成可履行的eth1数据来消除复杂性。
以下是该提案的具体内容：
特别感谢Vitalik Buterin的构思，@djrtwo、 @zilm以及其他人的评论和有用的贡献。
最近提出的以rollup为中心的道路图，提出数据分片作为以太坊2.0中履行的首要扩容因子，答应在单个履行分片上进行扩展，并简化了总体规划。
Eth1 分片规划假定经过信标链与数据分片进行通讯。假如具有多个履行分片的第二阶段（Phase 2）在今后推出，那么这种办法将是有意义的。由于当时首要集中在以rollup为中心的道路图上，将以太坊1.0放在一个专用的分片上（也就是说，独立于信标链）给共识层带来了不必要的复杂性，并增加了在分片上发布数据以及在Eth1 中拜访它们之间的推迟。
咱们主张经过将eth1数据（买卖、状况根等）嵌入到信标区块中，并强制信标链提议者生成可履行的eth1数据来消除这种复杂性。这会把eth1履行和有效性作为共识的一等公民。
提案概述
-
Eth1引擎由体系中的每个验证者负责保护。
-
当验证者计划提出一个信标区块时，它会要求eth1引擎创立eth1数据。然后，Eth1数据会被嵌入正在生成的信标区块体当中。
-
假如eth1数据无效，它也会使得承载它的信标区块失效。
Eth1引擎修正
依据之前的计划，Eth1分片中枢、Eth1引擎以及eth2客户端是松散结合并经过RPC协议进行通讯的（请查看Eth1+eth2客户端关系以了解更多详细信息）。Eth1引擎继续保护买卖池和需求自己网络仓库的状况下载器，它还应该保存eth1区块的存储。
当时的提案删去了eht1区块的概念，eth1引擎有两种潜在的办法来处理这种变化：
-
由信标区块带着的eth1数据合成生成eth1区块；
-
修正引擎，使买卖处理不需求eth1区块，而是运用eth1数据；
前者看起来比后者要更简略完结，它答应更快地将eth1客户端转化为eth1引擎，并且已经被eth1分片poc证明。
咱们运用术语「可履行数据」来表明包括eth1状况根、买卖列表（包括收据根和bloom过滤器）、coinbase、时刻戳、区块哈希以及eth1状况转化功用所需的所有其他数据位的数据。在eth2标准中，它或许如下所示：
class ExecutableData(Container):coinbase: bytes20 # Eth1 address that collects txs feesstate_root: bytes32gas_limit: uint64gas_used: uint64transactions: [Transaction, MAX_TRANSACTIONS]receipts_root: bytes32logs_bloom: ByteList[LOGS_BLOOM_SIZE]
eth1引擎的责任列表与咱们曾经对eth1分片的责任相似。首要的调查项有：
-
买卖履行，eth2客户端向eth1引擎发送可履行数据。eth1引擎经过处理数据更新其内部内部状况，假如共识查看经过，则回来true，否则回来false。高级用例，比如即时存款处理，也或许需求成果中的完整买卖凭证。
-
买卖池保护，Eth1引擎运用ETH网络协议来播送和盯梢网络中的买卖。等候中的买卖保存在mempool中，用于创立新的可履行数据。
-
可履行数据创立，Eth2客户端发送从前的区块哈希以及eth1状况根、coinbase、时刻戳以及创立可履行数据所需的所有其他信息（买卖列表除外）。Eth1引擎回来ExcecutableData的实例。
-
状况管理，Eth1引擎保护状况存储以能够运转Eth1状况履行函数。4、1 它涉及到终究触发的状况trie修剪机制，需求基于信标区块链的状况trie版别控制；注意：长时刻没有终究成果，会导致存储中出现大量废物，因此会消耗额外的磁盘空间。 4、2 当无状况履行和“区块创立”就绪时，eth1引擎可选择作为纯状况转化功用运转，它能够禁用状况存储，然后削减对磁盘空间的需求。
-
JSON-RPC支撑，为了便于运用及选用，保存对以太坊JSON-RPC的支撑非常重要。这一责任将由eth2客户端和eth1引擎分管，由于eth1引擎或许会失掉独立处理JSON-RPC端点子集的才能，例如基于区块号和哈希的调用。这种分离将在今后解决。
信标区块处理
ExecutableData结构替换信标区块体中的Eth1Data，此外，信标链和eth1的同步处理可完结即时存入，因此，能够从信标区块主体移除deposit。
更新的信标区块体（block body）：
class ExecutableBeaconBlockBody(Container):randao_reveal: BLSSignatureexecutable_data: ExecutableData # Eth1 executable datagraffiti: Bytes32 # Arbitrary data# Operationsproposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]attestations: List[Attestation, MAX_ATTESTATIONS]voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
咱们依照以下办法修正process_block函数：
def process_block(state: BeaconState, block: BeaconBlock) -> None:process_block_header(state, block)process_randao(state, block.body)# process_eth1_data(state, block.body) used to be hereprocess_operations(state, block.body)process_executable_data(state, block.body)
在process_operations完结后处理可履行数据是合理的，由于在许多地方，操作处理或许会使整个区块失效。不过，这种办法或许是次优的，这为客户端优化留下了空间。
在EVM中拜访信标状况
咱们更改用于回来eth1区块哈希的BLOCKHASH操作码的语义。现在，它回来的是信标区块根，这答应查看从256个slot开端直到前一个slot的信标状况或区块中包括的那些数据的证明。
异步状况读取有一个首要缺点。 客户端有必要要等候一个区块，才干创立带有链接到该区块的证明或它产生的状况根的买卖。 简而言之，异步状况拜访至少要推迟一个slot的时刻。
直接状况拜访
假定eth1引擎能够拜访表明整个信标状况的merkle树。然后，能够运用操作码READBEACONSTATEDATA(gindex)来供给EVM功用，以供给对任何信标状况的直接拜访。此操作码具有几个不错的属性。首要，这种读取的复杂性取决于gindex值，并且易于计算，因此能够轻松推断出gas价格。其次，回来数据的巨细为32字节，这完全合适EVM。
有了这个操作码，人们能够创立一个更高级别的信标状况拜访器库，然后为智能合约供给便捷的API。例如：
v = create_validator_accessor(index) # creates an accessorv.get_balance() # returns balance of the validatorv.is_slashed() # returns the value of slashed flag
该模型消除了状况拜访推迟。因此，经过对信标链操作和eth1履行适当的排序，能够在slot N中拜访到slot N-1 分片数据的交联（crosslink），然后答应rollup以最快的办法证明数据包括在内。
并且，这种办法还降低了信标状况读取的数据及计算复杂性。
注意：或许值得一开端就使READBEACONSTATEDATA操作码的语义独立于特定的承诺计划（即merkle树），以便于轻松升级。
直接拜访的本钱增加了eth1引擎的复杂性。读取信标状况的才能能够经过不同的办法完结：
-
传递状况以及可履行数据。这种办法的首要问题在于处理大的状况副本，假如将直接拜访限制为状况数据的一个子集，而该状况数据的子集需求将一小部分状况传递给履行，那么它或许会起作用。
-
双工通讯信道，有了一个双工通道，eth1引擎将能够向信标节点恳求EVM同步恳求的状况片段。将能够同步向信标节点询问EVM恳求的状况。 依据通道的设置办法，推迟或许会成为履行具有信标状况读取的买卖的瓶颈。
-
嵌入式eth1引擎，假如eth1引擎被嵌入到信标节点中（例如，作为一个同享库），它能够经过该节点供给的主机功用从同一内存空间读取状况。
分析
1、网络带宽
现在的提案经过可履行数据的巨细来扩大信标区块。不过，由于该提案答应运用高级存入计划，因此有或许删去Deposit操作。
依据区块利用率，以及均匀eth1区块巨细，预期的增长在10％到20％之间，这对网络接口要求的影响很小。
值得注意的是，假如rollup运用CALLDATA，那么eth1区块的巨细在最坏的情况下或许会增长到200kb（gas限制为1200万），然后使可履行信标区块巨细在300kb左右，增加了60%。
2、区块处理时刻
均匀处理时刻如下：
-
信标区块 12 ms
-
Epoch 64 ms
-
以太坊主网区块 200 ms
很难推断出信标链的处理时刻，尤其是在验证器集和交联（crosslink ）处理相对较大的情况下（由于分片已推出）。或许在某个时候，epoch处理将与eth1履行简直一起进行。
削减epoch边界处处理时刻的潜在办法，是在epoch的最后一个区块及时到达的情况下，不必等候下一个slot的开端而提前处理epoch。异步状况拜访模型答应进行另一种优化。在这种情况下，process_executable_data能够与主process_block乃至process_epoch有效负载并行运转。
改善这项规划
有人或许会说，当时的提案会把履行模型设置为原封不动的，并降低了在需求时引入更多可履行分片的才能。
另一方面，一些可履行分片引入了比如跨分片通讯、同享帐户空间等问题，而这些问题与履行模型的预期改变相同重要且难以解决。
对于该提案，Vitalik Buterin评论称：
“干得好！我的确担心eth1履行和信标链之间的同步交互。原因是运用同步交互虽然更简略，但会永久性地规定了验证eth2区块需求运转相应的eth1履行的要求。例如，它排除了答应eth2节点成为eth1无状况客户端等代替办法，并且仅验证eth1方是否是指定委员会的一部分。 因此，即便可履行数据直接在信标区块中，我也会倾向于保持可履行数据与信标链逻辑之间的通讯完全异步。”
视野开拓
人寿保险史学家典型地聚焦于该产业发展的经济决定因素，结果却忽略了那段历史中某些外在于经济领域的基本元素。巴伯已经批评了在大多数社会科学学科中，作为一种社会分析工具的市场的“绝对化”（absolutizatio）。我们的研究强调了单因素理论的不足和其理论上的天真；也强调了发展更为复杂的多维度解释模型的重要性。并没有人声称人寿保险业务的变化能力仅仅归因于文化因素，或者经济和技术变量是无关的分析工具。几乎没有疑问的是，对人寿保险的发展而言，19世纪中期美国经济发展的更高水平和进一步的城市化都是必要的。但他们对解释人寿保险被接纳并不充分。-《道德与市场》
