10月29日,以太坊联合创始人Vitalik Buterin发布了一份关于跨分片交易的新提案,所谓跨分片交易,是以太坊2.0平台需要实现的一种功能。
以下是提案译文:
以太坊2.0 阶段2 (phase 2)的要求之一,是能够快速地将ETH从一个分片移动到另一个分片。尽管通过常用接收机制的跨分片交易是可能的,因为协议本身只需提供对彼此分片的每个分片的状态根的访问,但跨分片ETH需要在协议活动中实现更安全的目的。原因是我们需要跟踪每个分片中有多少ETH,并且我们需要一个重要的机制来防止跨分片传输的重放(replay)问题。
一般来说,基于收据(receipt)的机制确实解决了这一问题,但它是通过具有“已消耗收据ID”的状态树来实现的,这将相当复杂地添加到当前名义上的无状态系统中。之所以需要此收据ID树,是因为我们允许收据(receipt)无序使用。也就是说,如果爱丽丝(Alice)从分片A向分片B发送一笔交易,然后Applebaum也从分片A向分片B发送一笔交易,那么有可能会出现Appelbaum的交易更早在分片B中被接受的情况。这是必要的,因为系统使用的是gas方法来处理收据消耗交易,爱丽丝(Alice)可能会决定不为这笔传输交易支付费用。
因此,这里就出现了一个问题:我们是否可用一个按顺序处理收据的机制,来代替处理收据的机制,这样对于“上次从分片A收到的分片B的收据ID” ,我们只需一个变量可递增?
也就是说,每个分片A保持其状态,对于每个其他分片B而言,则是两个值:(i)将从分片A发送到分片B的下一个收据的nonce,以及(ii)将从分片B接收到分片A的下一个收据的nonce。
至于“谁来买单”问题的答案很简单:区块生产者需处理每个区块来自其他分片一定数量的收据,通过对收据的源分片收费来限制费率。然而,这里有一个主要问题:如果一个人通过从所有分片向特定分片发送收据(可能是意外的,也可能是故意的),对其进行了拒绝服务攻击时,会发生什么呢?
N个分片分别发送N个收据,会对目标分片产生的负载。
为了解决这个问题,我们可以采用以下机制:每个分片都需在一个区块中处理最高N个收据(例如N = 64);如果其他分片处理的收据少于N,它可使用其它分片的Merkle证明来证明这一点。每个分片不断地向信标链(beacon chain)转发它已处理的收据总数,这用于提供更新的“gas价格”,以便将收据发送到该分片。例如,每一区块分片的收据处理队列是满的,gas价格可增加10%,最多可达到N。
这确保了在极端情况下,DoS攻击最终无法增加接受分片队列的长度,因此,每则消息都会得到处理,但这始终可发送一笔执行最小数量跨分片活动的交易。或者,分片需要将其EIP 1559 gasprice发布到信标链来处理区块费用;该费用也可用于此项功能。
如果我们有这种发送ETH跨分片的机制,我们还可以将其用于通用收据发送功能,从而创建一个有强大保证的跨分片交易系统。
这里存在的主要挑战是,为了计算收据的效果,我们需要有人自愿提供状态的Merkle验证内容。如果未写入完整状态,则无法在协议级别强制执行此操作;但可以做的是添加表单要求:“为了包含你自己的一笔交易,你还必须为队列中的跨分片收据提供验证内容。”