Vitalik：怎样完成跨Rollup DEX_数据来源

Vitalik：怎样完成跨Rollup DEX

假定大家有二种 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 的方式发送交易来进行所述实际操作，这一方式储存了一个纪录，避免合约中的全自动发送条文开启该交易。

预估的个人行为非常简单：

Alice 发送一笔交易至帐户 IVAN_A 中 (包括 N 代币 和一个备注 ALICE_B)

Ivan 根据 IVAN_B 发送 TRADE_VALUE * (1 - fee) 代币至 ALICE_B 中

第二笔交易随后第一笔交易产生。假如 Ivan 能够证实第一笔交易和第二笔交易中间的时间格式差别十分小，那麼合约乃至有标准容许提升 花费 fee 。

最槽糕的状况是，Ivan 沒有如他所期待那般向 ALICE_B 发送代币。碰到这类状况，Alice 能够等候 rollup A 上的交易确定以后，在 rollup B 上寻找别的获得代币的取代途径来付款花费，随后就可以自身领取其资产。

资金成本率

该计划方案的关键限定是，IVAN_B 必须拥有很多的资产，以保证全部交易发送者都能获得付款。尤其是，假定发生下列状况：

大家将交易限制设定为 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 就失去这一支配权

全文连接：https://ethresear.ch/t/cross-rollup-dex-with-smart-contracts-only-on-the-destination-side/8778

大家将交易限制设定为 TRADE_LIMIT (因此 当发送至 IVAN_A 的交易超过额度 valu

标签：

区块链热门资讯