LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 区块链资讯 > Vitalik:实现跨分片交易的新提案

Vitalik:实现跨分片交易的新提案

2019-11-02 区块律动BlockBeat 来源:区块链网络

原文标题:《Implementing cross-shard transactions》

原文作者:Vitalik Buterin
原文翻译:双花,Unitimes


Eth2.0 的阶段 2 的一个重要指标是实现 ETH 在分片间快速转移。虽然一般的跨分片交易可以通过采用普通的收据 (receipt) 机制①来支撑,这种机制只是需要协议本身能够让每个分片的状态根可以被其他分片获取,但是跨分片的 ETH 交易需要更加底层的协议内交互。这是因为我们需要追踪每个分片上 ETH 的数量,同时我们需要一个底层机制去防止跨分片交易的重放 (replay)。

虽然通过普通的收据机制的确能够解决上述的问题,但是该机制需要节点去维护一棵记录「已被花费的收据 ID」(笔者注,收据本身其实相当于一笔交易)的默克尔树,这对于名义上的无状态系统是很难集成的。需要这棵收据树的原因在于我们允许收据可以无序地被消耗。也就是说,如果 Alice 发送了一笔从分片 A 到分片 B 的交易,Applebaum 随后发送了另一笔从分片 A 到分片 B 的交易,那么 Applebaum 的交易可能更早地被分片 B 打包。这个场景是很合理的,原因在于分片节点也是基于 Gas 市场的方式来处理收据消耗交易 (receipt-consuming transactions)。这样的话,而 Alice 可能会决定不为这笔交易支付费用 (笔者注:如果 Alice 选择不支付交易费,那 Applebaum 的交易会先被分片 B 打包)。

那么问题来了,我们是否可以设计一种机制让收据能够按序地被处理?这样的话,我们只需要用一个一直递增的收据 ID 去维护分片 B 从分片 A 收到的收据 ID(笔者注,就是不需要再维护一个树的意思)。

也就是说,对于分片 A(即发送交易的分片) 来说只需要维护自身的状态,对于分片 B(即接收交易的分片) 来说,它需要维护两个值:(i)分片 A 发送给分片 B 的下一个收据的 nonce 值;(ii) 分片 A 接收的分片 B 的下一个收据的 nonce 值。

在这种情况下,该怎么收费?这个问题的答案是很显然的。处理跨分片交易另一半的交易费用(区块生产者需要在每个区块上处理来自其他分片的收据)被原分片上收取的收据费用所限制。(笔者注:这是按序处理收据的性质所决定的,目标分片必须处理来自源分片的收据,这会引入后续的 DoS 攻击)然而,这里会有一个很严重的问题:如果某个人有意无意地对特定的的分片进行 DoS 攻击(笔者注:恶意低成本地占用分片的收据收据资源,不让其他人的收据被处理),即从所有的其他分片往特定分片发送收据?




N 个分片发送 N 个收据会使得目标分片需要处理 O(N^2) 的负载

为了解决这个问题,我们可以采用下述的机制,即限制每个分片在每个区块中处理的收据上限为 N(比如 N=64)。如果来自其他分片需要处理的收据数小于 N,那么可以利用来自其他分片的默克尔证明对收据进行校验。每个分片持续地把自己处理的收据总数转发至信标链,从而对发送给自己的收据的 Gas 价格进行更新。例如,如果一个分片要处理的收据队列已经满了(达到上限 N),那么满足这样情况的区块的 Gas 价格可以提高 10%。

这样的设计保证了在极端的情况下,DoS 攻击最终难以延展接收分片的收据队列。因而,所有的交易都会被处理,总是有发送一笔涉及最小限度分片交互的交易的可能。或者,分片需要把他们的遵循 EIP 1559 的交易费发布到信标链上以决定区块处理费用。那么这个费用同时也可以被用于本文的机制中。

如果我们有了这样的机制去支撑 ETH 的跨分片转移,那么我们同时也可以把这个机制用于通用的收据发送能力的支持,这样就可以构造一个可靠的跨分片交易系统。

这里还存在的一个重要的挑战是如何计算每个收据的作用影响,我们需要有人自愿提供状态的默克尔见证。如果保存所有状态没有被要求,那么我们不能在协议的级别强制要求见证的提供。但是我们可以增加这项要求:为了你的交易被成功打包,那么你需要为队列中的跨分片队列提供见证数据。

原文链接:https://ethresear.ch/t/implementing-cross-shard-transactions/6382

—-

编译者/作者:区块律动BlockBeat

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...