vitalik所说的交叉汇总DEX是什么意思？

当人们还在考虑使用汇总来缓解第1层的拥塞时，vitalik已经在考虑如何在汇总之间进行交互。

六天前，vitalik推出了一个名为“cross rollup DEX”的提案，其中提到当一个rollup部署了智能合约，而另一个没有完整的智能合约功能时，可以在两个rollup之间以去中心化的方式转移资产。有点像“在空中移动物体”。

这个过程是如何实现的？Bili news将vitalik和社区成员之间的提议和精彩讨论翻译如下：

假设我们有两个rollup，rollup A和rollup B。Alice希望将一定数量的代币从rollup A转移到rollup B。如果A和B都有完全的智能合约支持，在这种情况下，已经有关于如何以去中心化方式解决此问题的建议。本提案旨在为只有rollup B完全支持智能合约（rollup a只能处理简单事务）的情况提供思路。

假设rollup上的事务有某种“remark字段”。如果不是，我们可以用值的低阶作为备注。

建议

假设有一个交易中介Ivan（在实践中，有许多中介可以选择）。Ivan有一个帐户Ivan在汇总表上（他完全控制这个帐户）。Ivan还将部分资金存入Ivan，这是rollupb的智能合约。

智能合约Ivan_ub有以下规则：如果任何人向Ivan_uuuua发送交易值代币数。如果它包含一个地址目的地作为备注，那么在延迟块之后的最小赎回中，Ivan_uub将收到一个包含代币转移证明的交易，这样，一个事务排队到目的地地址，从而收回交易价值的代币数。取款按照汇总a中包含的交易的批次和索引顺序进行处理，会有一定的延迟（比如一天）。

当Ivan看到他在Ivan_uuu收到资金时，他可以将交易金额*（1-费用）个数的代币发送到目的地地址。他可以使用Ivan_u2;B中的方法发送事务，该方法保存一条记录，以防止合同中的自动发送条款触发事务。

预期操作很简单：

Alice to Ivan_ua发送一个包含N个代币和一个便笺地址Alice_uub的事务

Ivan通过Ivan_ub向Alice_ub发送交易价值*（1-费用）代币数量

第二步可以在第一步之后立即进行。如果Ivan证明第二笔交易和第一笔交易之间的时间戳差异非常小，那么合同甚至可以制定规则来允许更高的成本。

“最坏情况”是Ivan没有按预期向Alice报告发送代币。在这种情况下，Alice可以等待rollup a上的交易确认，找到另一种方法让rollup B上的代币支付费用，然后她可以自己索要资金。

资本成本

这项计划的主要限制是伊万需要持有大量资金，以确保所有发件人都能获得报酬。特别地，假设我们将交易金额的上限设置为tradelimit（因此发送给Ivan）在a的交易中，交易值为gt；tradelimit的交易是无效的交易）。

同时，我们将每个汇总批处理的**事务数设置为TXS per batch。Alice可以在汇总A即将进行的批处理之前检查自己有多少未处理的事务，把她用在伊凡尼，从合同中看到的资金中减去这个值，检查剩余的金额是否足够。由于取款是按顺序处理的（这是上述订单机制的目标），爱丽丝在自己取款之前不必担心伊万，她将处理以后的取款要求。

批量交易的**金额是每批交易限额*TXS，因此Ivan合同B至少需要持有这一笔ETH，再加上足够的资本来支付未完成的交易。

例如，假设trade_u2;Limit=0.1ETH（上限可以设置得相对较低，因为通过多次交易可以完成更高数量的交易），TXS_u2;PER_u2;BATCH=1000，那么Ivan_2;B需要100 ETH。

请注意，此设计中还有一个额外的隐含成本，因为任何交易量超过0.1 ETH的人都需要消耗块空间，这与资本要求相权衡：如果您消耗一半的块空间，您的资本要求将翻倍（这可能意味着更高的隐含成本），反之亦然。为了建立正确的平衡，似乎隐性成本应该是市场上显性成本的几倍。

如果我们想减少或消除这种消耗，rollup a可以设计成，例如，让分拣机发送一个签名的消息，向Alice证明到目前为止批处理中所有已批准的消息。然后爱丽丝就会知道，她面前没有交易（虽然恶意的分拣机可以欺骗爱丽丝，但成本很高）。

评论

上述设计基于这样的假设，即rollup a上的事务有一个remark字段，Alice可以使用该字段指定Alice_ub作为接收代币的目的地地址。如果rollup没有这个特性，我们可以使用下面的解决方案。

Alice可以在顺序注册契约的rollup B上注册Alice，并获得顺序分配的ID（因此Alice的ID等于在她之前注册的用户数）。Set Max USER Count是**用户数，如果需要，可以随时间向上调整。Alice可以简单地确保tradeVALUE%MAXUSERCount等于（Alice的ID），使用tradeVALUE的较低顺序（表示不重要的值）表示她想要交易的代币数。

从汇总B到汇总a的事务

如果Alice将rollup B上的代币转移到rollup a，则可以使用类似的机制，但角色是相反的

爱丽丝把信物送给伊凡·吴B

拖延一段时间后，她将有权收回代币

如果伊**向伊万报告，伊万证明他在汇总表a上给爱丽丝发了一个代币，爱丽丝失去了权利

总结

因此，我们可以看到，在这个过程中，很多“Ivan”实际上是去中心化的银行，在两个汇总上分别扮演存款机和ATM机的角色，以此赚取手续费。

如果伊万作恶，罗拉A和罗拉B不需要太多的互动，爱丽丝可以提供硬币的证据。根据vitalik的陈述，在将资金从汇总a转移到汇总B的场景中，提供证明可以直接在汇总B上执行，只要汇总B可以获得汇总a的块哈希，就可以计算汇总a上的交易记录并向Ivan索赔。

维塔利克在索赔过程中也提供了更多的可能性。例如，可以给Ivan B添加一个“快速通道”，Alice B可以将Ivan B上的投币口卖给其他用户。

假设这个用户叫Bob，那么Bob可以先把钱转给aliceb。之后，Ivan B应转移给Alice B的资金将由Bob获得。也就是说，为了改善Alice的用户体验，Bob提前向Alice付款。这个过程可能涉及挖矿和其他游戏。

GitHub上的一位用户问，如果中间人伊万不是个人而是去中心化的资金池，这种模式是否会更好。Vitalik表示，这将涉及到rollup a上基金池的所有权（基金池中的所有基金可能都由私钥控制）。相比之下，多个中介机构充当去中心化的“资金桥梁”可能更为合理。

这是交叉汇总DEX的总体思想。虽然适用的场景可能不多，一些影响资本安全的场景可能没有考虑在内，但我们在Layer2看到了一些可能性。区块链解决方案在某些方面可能是规则设计。