當人們還在思考用rollup的方式緩解layer1擁堵的時候，vitalik已經在考慮rollup之間怎麼做互動。
6天前，vitalik發起了一個叫做“跨rollup dex”的提案，其中提到當一條rollup有智慧合約部署，另一條rollup沒有完全的智慧合約功能的時候，資產可以在兩條rollup之間以去中心化的方式轉移。有一點“隔空挪物”的感覺。
這個過程到底是怎麼實現的呢？嗶嗶news將提案，以及vitalik和社羣成員間的精彩討論內容翻譯如下：
假設我們有兩條rollup，分別是rollup a和rollup b。alice想要把rollup a上特定數量的代幣轉移到rollup b上。如果a和b都有完全的智慧合約支援，在這種情況下，已經有關於如何以去中心化的方式解決這個問題的提案。本提案想要為只有rollup b有完全的智慧合約支援（rollup a只能處理簡單的交易）的情況提供思路。
我們假設，rollup a上的交易有某種“備註欄位”，如果沒有的話，我們可以使用值的低階位作為備註傳送。
提案
假設存在一個交易中介ivan(在實際實現中，將有許多中介可供選擇)。ivan在rollup a上有一個賬戶ivan_a(他完全控制該帳戶)。ivan還將一些資金存入了rollup b上的智慧合約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和rollup b間不需要進行過多的互動，alice就可以提供打幣證明。根據vitalik的表述，在從rollup a向rollup b轉賬的場景中，提供證明這一步操作可以直接在rollup b上進行，只要rollup b能獲取rollup a的區塊雜湊，就可以計算出rollup a上的交易記錄，從而向ivan索賠。
在索賠這個過程中，vitalik還給出了更多的可能性。比如，可以在ivan b上增加一個“快速通道”，alice b可以把她在ivan b上的提幣插槽出售給其他使用者。
假設這個使用者叫bob，那麼bob可以把款項先轉賬給alice b，此後，ivan b應該轉賬給alice b的資金將被bob獲取。也就是由bob先墊付資金給alice，以此來提升alice的使用者體驗，這個過程或許可以涉及到挖礦之類的玩法。
github上有使用者提到，如果中間商ivan不是個體，而是去中心化的資金池，這個模型是否會更好。vitalik表示，這會涉及到rollup a上資金池的所有權問題（可能池子中的所有資金被一個私鑰控制），相比之下，由多箇中間商來作為分散的“資金橋”可能更合理。
這就是跨rollup dex的大致思路。雖然可應用場景可能不多，也有一些影響到資金安全的場景可能沒有被考慮進去，但是這讓我們又看到了一些layer2上的可能性。區塊鏈解決方案從某些角度來看，或許就是規則設計。
