一般来说，基于收据（receipt）的机制确实办理了这一问题，但它是通过具有“已耗损收据ID”的状态树来实现的，这将相当巨大地添加到当前名义上的无状态系统中。之所以需要此收据ID树，是因为我们答允收据（receipt）无序利用。也就是说，假如爱丽丝（Alice）从分片A向分片B发送一笔生意业务，然后Applebaum也从分片A向分片B发送一笔生意业务，，那么有大概会呈现Appelbaum的生意业务更早在分片B中被接管的环境。这是须要的，因为系统利用的是gas要领来处理惩罚收据耗损生意业务，爱丽丝（Alice）大概会抉择不为这笔传输生意业务付出用度。

这确保了在极度环境下，DoS进攻最终无法增加接管分片行列的长度，因此，每则动静城市得处处理惩罚，但这始终可发送一笔执行最小数量跨分片勾当的生意业务。可能，分片需要将其EIP 1559 gasprice宣布到信标链来处理惩罚区块用度；该用度也可用于此项成果。

为了办理这个问题，我们可以回收以下机制：每个分片都需在一个区块中处理惩罚最高N个收据（譬喻N = 64）；假如其他分片处理惩罚的收据少于N，它可利用其它分片的Merkle证明来证明这一点。每个分片不绝地向信标链（beacon chain）转发它已处理惩罚的收据总数，这用于提供更新的“gas价值”，以便将收据发送到该分片。譬喻，每一区块分片的收据处理惩罚行列是满的，gas价值可增加10%，最多可到达N。

也就是说，每个分片A保持其状态，对付每个其他分片B而言，则是两个值：（i）将从分片A发送到分片B的下一个收据的nonce，以及（ii）将从分片B吸收到分片A的下一个收据的nonce。

N个分片别离都发送N个收据，会对方针分片发生的负载。

这里存在的主要挑战是，为了计较收据的结果，我们需要有人自愿提供状态的Merkle验证内容。假如未写入完整状态，则无法在协议级别强制执行此操纵；但可以做的是添加表单要求：“为了包括你本身的一笔生意业务，你还必需为行列中的跨分片收据提供验证内容。”

以太坊2.0 阶段2 （phase 2）的要求之一，是可以或许快速地将ETH从一个分片移动到另一个分片。尽量通过常用吸收机制的跨分片生意业务是大概的，因为协议自己只需提供对互相分片的每个分片的状态根的会见，但跨分片ETH需要在协议勾当中实现更安详的目标。原因是我们需要跟踪每个分片中有几多ETH，而且我们需要一个重要的机制来防备跨分片传输的重放（replay）问题。

以下是提案译文：

因此，这里就呈现了一个问题：我们是否可用一个按顺序处理惩罚收据的机制，来取代处理惩罚收据的机制，这样对付“上次从分片A收到的分片B的收据ID” ，我们只需一个变量可递增？

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