5

Vitalik:如何实现跨Rollup DEX

 3 years ago
source link: https://news.ethereum.cn/Technology/cross-rollup-dex-with-smart-contracts-only-on-the-destination-side
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
ETH   $ 1877   0.52%      Gas:  121 Gwei          Epoch / Slot : 23166 / 741312       活跃验证者 : 109084

Vitalik:如何实现跨Rollup DEX

当仅有目标地址完全支持智能合约时,如何实现跨rollup


Vitalik Buterin       2021-03-10

来源 | ethresear.ch

假设我们有两种 rollup 解决方案 A 和 B,Alice 想要用 rollup A 上一定数量的代币来换取 rollup B 上同样的代币。已经有人提出方案解决这个问题了,如果 rollup A 和 B 都是完全支持智能合约时,那么就可以去中心化地实现这个假设。然而这篇文章提出的是,当仅有 rollup B 完全地支持智能合约时 (且 rollup A 只能处理简单交易) 如何实现跨 rollup 转账。

我们假定 rollup A 上的交易有某种“备注字段”;如果没有的话,可以使用该交易值的低位数字作为备注发送。

假设我们有一个交换中介 Ivan (在实现时有许多中介可供选择)。Ivan 在 rollup A 中拥有一个 (完全由他控制的账户) IVAN_A。同时,Ivan 还在 rollup B 的智能合约 IVAN_B 中存了一些资金。

智能合约 IVAN_B 具有以下规则:

  • 如果任意用户发送了一笔交易 (发送某代币交易值 TRADE_VALUE 至账户 IVAN_A) ,(交易中还附上了一个目的地址 B DESTINATION 作为备注),则在最小偿还延迟 MIN_REDEMPTION_DELAY 区块之后,该用户就可以返还一笔交易至账户 IVAN_B 中 (其中包括之前的转账证明),然后这笔交易就会排队等候提款至地址 DESTINATION 中。
  • 等待一定的延迟 (例如一天) 后,按照转账打包进 rollup A 的批次和索引顺序处理提款。
  • 当 Ivan 发现其账户 IVAN_A 收到款项时,他就可以亲自发送 TRADE_VALUE * (1 - fee) 代币至 DESTINATION 中。他可以用 IVAN_B 的方法发送交易来完成上述操作,这个方法保存了一个记录,防止合约中的自动发送条款触发该交易。

预期的行为很简单:

  1. Alice 发送一笔交易至账户 IVAN_A 中 (包含 N 代币 和一个备注 ALICE_B)

  2. Ivan 通过 IVAN_B 发送 TRADE_VALUE * (1 - fee) 代币至 ALICE_B

第二笔交易紧接着第一笔交易发生。如果 Ivan 可以证明第一笔交易和第二笔交易之间的时间戳差异非常小,那么合约甚至有规则允许提高费用 fee

最糟糕的情况是,Ivan 没有如他所期望那样向 ALICE_B 发送代币。遇到这种情况,Alice 可以等待 rollup A 上的交易确认之后,在 rollup B 上找到其他获取代币的替代路径来支付费用,然后就可以自己认领其资金。

该方案的主要限制是,IVAN_B 需要持有大量的资金,以确保所有交易发送者都能得到支付。尤其是,假设出现以下情况:

  • We place a trade size limit of TRADE_LIMIT coins (so transactions going to IVAN_A with value > TRADE_LIMIT are not valid trades)
  • 我们将交易上限设置为 TRADE_LIMIT (所以当发送至 IVAN_A 的交易超出限额 value > TRADE_LIMIT 时,交易无效)
  • 每个 rollup 批次最多可以包含 TXS_PER_BATCH 笔交易

Alice 可以自行检查 rollup A 下一批需要处理的交易之前,还有多少未处理的交易,用她在合约 IVAN_B 中的资金减去这些交易的总值,并检查剩余的金额是否足够。由于提款是按顺序处理的 (这是上述的排列机制的目的),Alice 不需要担心合约先处理其他提款申请,再处理她的提款交易申请。

在每批次中最大交易额为 TRADE_LIMIT * TXS_PER_BATCH ,因此 IVAN_B 合约中至少需要这么多的 ETH,还需要额外的资金包含为处理的交易。举个例子,假设交易上限为 0.1 ETH TRADE_LIMIT = 0.1 ETH (交易上限可以设得比较低,因为一笔大额交易可以分成几笔小交易完成),并且每批次可以处理1000笔交易 TXS_PER_BATCH = 1000。那么,合约 IVAN_B 需要持有 100 ETH。

注意,这个设计中还包括隐含的费用,因为交易额超过 0.1 ETH 的任意用户都需要浪费区块空间。这与资本要求相权衡,也就是说,如果用户消耗了一半的区块空间,那么其资本要求将翻倍,反之亦然。如果想要获得合适的平衡,那么隐含的费用要比市场上明确的费用少几倍。

如果我们想要减少或者消除这种消耗,可以这样设计 rollup A:让序列器发送一个已签名的信息,该信息证明了 Alice 在该批次的所有交易。然后 Alice 就会知道在她之前没有交易 (尽管恶意的序列器可以欺骗 Alice,但是作恶代价会很高)。

上述设计基于一个假设:Rollup A 上的交易有一个备注字段,Alice 可以通过该备注指定 ALICE_B 作为她接收代币的目的地址。如果 rollup 没有这种特性,那么我们可以使用以下解决方案。Alice 可以在 rollup B 上的一个以顺序登记的合约上注册账号 ALICE_B ,并获得一个按顺序分配的 ID (因此 Alice 的 ID 等于在她之前注册的用户数量)。

设置用户数的最大值 MAX_USER_COUNT ;如果有必要,这个值可以随时间向上调整。则 Alice 可以确保 TRADE_VALUE % MAX_USER_COUNT 等于 (Alice 的 ID),使用 TRADE_VALUE 的低位数字 (这个数字是这笔交易的一个小数值) 来表示她想交易的代币数量。

从 Rollup B 到 Rollup A 的交易

如果 Alice 把 Rollup B 上的代币转移到 Rollup A,她可以使用相同的机制,只是角色颠倒了:

  • Alice 将代币发送给 IVAN_B
  • 经过一段时间的延迟后,她将获得取回代币的权利
  • 如果 Ivan 可以向 IVAN_B 证明,他在 Rollup A 上给 Alice 发送了代币,Alice 就失去了这个权利

ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源,文章版权归原作者所有,转载须注明原文出处以及ethereum.cn,若需长期转载,请联系[email protected]进行授权。



About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK