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的低階位(這個數字表示一個不重要的值)來表示她想交易的代幣數量。
從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上的可能性。區塊鏈解決方案從某些角度來看,或許就是規則設計。
鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播信息之目的,不構成任何投資建議,如有侵權行為,請第一時間聯絡我們修改或刪除,多謝。
Arthur Hayes 新文聚焦 | 全球貨幣政策的真相,比特幣接下來何去何從?
作為一名宏觀經濟預測者,我試圖基於公开數據和當前事件,作出能夠指導投資組合資產配置的預測。我喜歡“...
Ouroboros DeFi:為什么 Usual Money 被低估了?
前言:Ouroboros DeFi 方法論在Ouroboros DeFi收益基金,我們的投資策略始...
WEEX 唯客交易所贊助臺北區塊鏈周 支持更多全球用戶Onboard Web3
第三屆臺北區塊鏈周(Taipei Blockchain Week, TBW)於 12 月 12-1...