当人们还在思考用rollup的方法缓解Layer1拥堵的时候，Vitalik已经在考虑rollup之间怎样做交互。 6天前，Vitalik发起了一个叫做“跨rollup DEX”的提案，其间说到当一条rollup有智能合约布置，另一条rollup没有彻底的智能合约功能的时候，财物能够在两条rollup之间以去中心化的方法转移。
有一点“隔空挪物”的感觉。 这个进程到底是怎样完成的呢？哔哔News将提案，以及Vitalik和社区成员间的精彩讨论内容翻译如下： 假定咱们有两条rollup，分别是rollup A和rollupB。Alice想要把rollup A上特定数量的代币转移到rollup B上。假如A和B都有彻底的智能合约支持，在这种状况下，已经有关于如何故去中心化的方法解决这个问题的提案。本提案想要为只有rollup B有彻底的智能合约支持（rollup A只能处理简单的买卖）的状况供给思路。 咱们假定，rollup A上的买卖有某种“补白字段”，假如没有的话，咱们能够使用值的低阶位作为补白发送。
提案
假定存在一个买卖中介Ivan(在实践完成中，将有许多中介可供挑选)。Ivan在rollup A上有一个账户IVAN_A(他彻底操控该帐户)。Ivan还将一些资金存入了rollupB上的智能合约IVAN_B中。 智能合约IVAN_B有以下规矩：假如任何人发送TRADE_VALUE数量的代币到IVAN_A，其间包括一个地址DESTINATION作为补白，那么在MIN_REDEMPTION_DELAY块之后， IVAN_B将收到一笔买卖，该买卖包括一个代币转移的证明，然后把提取TRADE_VALUE数量的代币这样一笔买卖排队到DESTINATION地址。提币按照买卖被包括到rollup A中的批次和索引次序处理，要通过一些延迟(比如1天)。
当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证明第二笔买卖和第一笔买卖之间的时刻戳差异十分小，那么合约乃至能够拟定规矩，允许费用更高。 “最坏的状况”是Ivan没有像预期的那样向ALICE_B发送代币。在这种状况下，Alice能够等候rollup A上的买卖确认，找到取得rollup B上的代币的其他途径来付出费用，然后她自己就能够索要资金。
本钱本钱
该方案的主要约束是，IVAN_B需求持有大量资金，以保证一切发送者都能得到付出。特别是，假定：咱们把买卖金额上限设置为TRADE_LIMIT（所以发送到IVAN_A的买卖中，买卖值> TRADE_LIMIT的买卖都不是有用买卖)。 同时，咱们设置每个rollup批次最多可包括的买卖数量是TXS_PER_BATCH。Alice能够自己检查，rollup A即将到来的批处理之前有多少未处理买卖，用她在IVAN_B合约中看到的资金减去这个值，并检查剩余的金额是否满足。
由于提币是按次序处理的(这是上面次序机制的目标)，Alice不需求忧虑在她自己提币之前IVAN_B会去处理后面的提币需求。 在一个批次中能够买卖的最大金额是TRADE_LIMIT * TXS_PER_BATCH，因而IVAN_B合约需求至少持有这个数量的ETH，再加上满足的资金来覆盖未处理的买卖。 例如，假定TRADE_LIMIT = 0.1 ETH（上限能够设得比较低，由于一笔较高金额的买卖能够通过多笔买卖完成)，并且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就失去了这个权力
总结
所以咱们能够看到，在这个进程中，许许多多的“Ivan”其实便是去中心化的银行，在两条rollup上分别扮演存款机和取款机的人物，然后赚取手续费。 假如Ivan作恶，rollup A和rollupB间不需求进行过多的交互，Alice就能够供给打币证明。依据Vitalik的表述，在从rollup A向rollup B转账的场景中，供给证明这一步操作能够直接在rollup B上进行，只需rollup B能获取rollup A的区块哈希，就能够计算出rollup A上的买卖记载，然后向Ivan索赔。 在索赔这个进程中，Vitalik还给出了更多的或许性。
比如，能够在Ivan B上添加一个“快速通道”，Alice B能够把她在Ivan B上的提币插槽出售给其他用户。 假定这个用户叫Bob，那么Bob能够把金钱先转账给AliceB，尔后，Ivan B应该转账给Alice B的资金将被Bob获取。也便是由Bob先垫付资金给Alice，以此来提高Alice的用户体验，这个进程或许能够涉及到挖矿之类的玩法。 Github上有用户说到，假如中间商Ivan不是个体，而是去中心化的资金池，这个模型是否会更好。
Vitalik表明，这会涉及到rollup A上资金池的一切权问题（或许池子中的一切资金被一个私钥操控），相比之下，由多个中间商来作为涣散的“资金桥”或许更合理。 这便是跨rollup DEX的大致思路。
虽然可应用场景或许不多，也有一些影响到资金安全的场景或许没有被考虑进去，可是这让咱们又看到了一些Layer2上的或许性。区块链解决方案从某些角度来看，或许便是规矩规划。
