這個過程中需要許許多多「去中心化的銀行」,在兩條 Rollup 上分別扮演存款機和取款機的角色。

原文標題:《Vitalik 說的跨 Rollup DEX 是啥?》
撰文:Breeze

當人們還在思考用 Rollup 的方式緩解 Layer 1 擁堵的時候,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 還將一些資金存入了 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 可以把款項先轉賬給 Alice B,此後,Ivan B 應該轉賬給 Alice B 的資金將被 Bob 獲取。也就是由 Bob 先墊付資金給 Alice,以此來提升 Alice 的用戶體驗,這個過程或許可以涉及到挖礦之類的玩法。

Github 上有用戶提到,如果中間商 Ivan 不是個體,而是去中心化的資金池,這個模型是否會更好。Vitalik 表示,這會涉及到 Rollup A 上資金池的所有權問題(可能池子中的所有資金被一個私鑰控制),相比之下,由多箇中間商來作爲分散的「資金橋」可能更合理。

這就是跨 Rollup DEX 的大致思路。雖然可應用場景可能不多,也有一些影響到資金安全的場景可能沒有被考慮進去,但是這讓我們又看到了一些 Layer2 上的可能性。區塊鏈解決方案從某些角度來看,或許就是規則設計。