Vitalik说的跨Rollup DEX是什么？_数据来源

Vitalik说的跨Rollup DEX是什么？

当大家仍在思索用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的低级位(这一数字表示一个不重要的值)来表明她想交易的代币总数。

假如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的区块链hach，就可以测算出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上的概率。区块链技术解决方法从一些视角看来，也许便是标准设计方案。

该计划方案的关键限定是，IVAN_B必须拥有很多资金，以保证 全部发布者都能获得付款。尤其是，假设：大家把交易额度限制设定为TRADE_LIMIT（因此发送至IVAN_A的交易中，交

标签：

区块链热门资讯