Opside推出NCRC協議，允許無需信任的原生跨Rollup通信

Opside ｜2023-08-21 19:30

该解决方案既继承了native bridge绝对的安全性，也避免了第三方桥所带来的系统复杂度和信任成本。

TL; DR

Opside的NCRC（Native Cross Rollup Communication）協議提供了一種無需信任的Rollup互操作性解決方案。 NCRC協議並不是在各個Rollup上額外添加一個第三方橋，而是在系統層面改造了ZK-Rollup自帶的bridge（native bridge），從而直接使用各個ZK-Rollup的native bridge來實現跨Rollup通信。這樣的做法更加簡潔和徹底，既繼承了native bridge絕對的安全性，也避免了第三方橋所帶來的系統複雜度和信任成本。

為什麼我們需要無需信任的跨 Rollup 通信？

Rollup 能夠顯著提高區塊鍊網絡的可擴展性、降低交易成本並提高整體效率，它們受到越來越多的關注和使用。 Opside為Web3應用提供ZK-RaaS服務，任何開發者都可以通過Opside Rollup Launchbase創建自己的Rollup。在這個多 Rollup 的時代裡，我們預計會有越來越多的 Rollup 共存，因此不同的 Layer 2 之間的無縫互操作性變得至關重要。目前，Rollup 之間運作相對孤立，缺乏實時的跨鏈通信和資產互通。這種隔離導致了碎片化的格局，其中資產在特定的 Rollup 內被隔離，限制了它們在不同網絡之間的自由流動和利用。

缺乏高效的跨 Rollup 通信不僅限制了各個 Rollup 的潛力，還影響了整體用戶體驗。用戶在嘗試在 Rollup 之間轉移資產或執行跨鏈交易時面臨繁瑣而耗時的流程。這種次優的體驗削弱了 Rollup 的吸引力，並在一定程度上阻礙了二層擴展方案的廣泛採用。

目前的跨Rollup橋接方案大部分是在Rollup鏈上部署新的一套跨鏈合約，然後通過多鏈流動性激勵機制來提供資產的跨鏈。這些方案並不是通用的消息跨鏈，同時帶來了中心化和信任的風險。

為了釋放多 Rollup 時代的全部潛力，迫切需要一種無需信任的通用的跨 Rollup 通信協議。

Opside的解決方案: Native Cross Rollup Communication

實際上，每一個ZK-Rollup都自帶一個L1<>L2的bridge，我們稱之為Native bridge。與第三方bridge採用流動性方案不同，Native bridge是唯一的“mint-burn”跨鏈機制。它由零知識證明來保證安全性，同時也是無需信任的。一個Rollup上所有的資產，都來自native bridge的deposit交易，同時也都由native bridge來提供最終的安全性背書。

我們堅信奧卡姆剃刀原理，“如無必要，勿增實體（Entities are not to be multiplied beyond necessity.）”。第三方橋擁有更加便宜和快捷的跨鏈體驗，但也帶來了更多的信任成本和安全風險。前不久的Multichain事件，就是一個案例。因此，在一開始，Opside的跨rollup通信的靈感就簡單得出奇：直接使用native bridge來實現多rollup互操作性，而不是新增一個第三方的橋。這就有了現在的NCRC（Native Cross Rollup Communication）協議。

NCRC的前提條件

多個Rollup之間實現NCRC需要滿足以下2個前提條件：

這些Rollup屬於ZK-Rollup類型
這些Rollup在相同的L1上

滿足以上2個條件的ZK-Rollups，在理論上，擁有和L1一樣的安全性。同樣地，這些Rollup之間的native bridge的安全等級是一樣的，且無需信任對方。所有的NCRC交易都是被validity proof所驗證的，這也是NCRC的安全性保證的根本來源。

Rollup Recognition Contract（RRC）

截至2023年8月，已經有多個ZK-Rollups主網上線了，包括Polygon zkEVM、zkSync Era、Linea等。然而，這些ZK-Rollups之間是獨立不相關的，用戶的資產也因此碎片化。造成這種問題的根本原因在於，它們在L1（以太坊主網）上的合約是不相關的。它們感受不到對方的存在，更無法實現原生Rollup bridge的直接通信。

因此，我們要做的第一步，是在L1上部署一個特殊的合約，來讓Rollup互相發現和識別。我們稱之為RRC（Rollup Recognition Contract）。 RRC負責管理所有參與NCRC的ZK-Rollups，包括Rollup的新增、暫停、退出等。 RRC中的每個Rollup，都會有一個專屬的Rollup ID，L1的ID則固定為0。

Rollup上的地址在native bridge發起跨Rollup交易時，可以指定目標的Rollup ID：

如果Rollup ID為0，則表示把消息跨到L1，例如withdrawal
如果Rollup ID不為0，則表示要把消息跨到其他Rollup

Opside將在每一個L1 層都部署了一個RRC合約，並允許對應的ZK-Rollup無需許可地加入或者退出。這個RRC合約將用於維護各個 Rollup ID 對應的Rollup信息，包括L1上的bridge合約地址等。值得一提的是，RRC合約只是負責提供數據檢索服務，不會跟跨鏈資產產生直接聯繫。

兼容native bridge的smart contract與service

一般來說，一個Rollup的native bridge分成3個模塊：L1上的bridge合約、L2上的bridge合約，以及一個bridge service負責傳遞信息。 NCRC協議在底層復用了這些模塊，並在其基礎上做了更高級的封裝。主要的改動如下：

L2上的bridge合約：在保留原有方法的基礎上，添加了新的bridgeAsset方法，允許用戶在destinationNetwork 參數中指定目標Rollup的ID
L1上的bridge合約：封裝一個新方法來處理新bridgeAsset方法的跨鏈消息。 bridge合約會在RRC合約中根據Rollup ID尋找到目標Rollup的信息，並將跨鏈資產轉移到目標Rollup的bridge合約中。跨鏈資產在那裡被deposit到目標Rollup
bridge service：負責傳遞信息，並向用戶收取跨Rollup交易的手續費

當一個Rollup完成以上NCRC相關的兼容適配之後，就可以將該Rollup註冊到RRC，從而加入原生跨Rollup通信網絡。

原生跨Rollup交易的流程

對於用戶來說，NCRC的操作方式和rollup的native bridge是完全一致的。用戶在 Rollup1 上發起到 Rollup2 的跨鏈交易，整個流程將自動完成，包括以下步驟：

首先，跨Rollup交易發起者User1在 Rollup1 上調用native bridge的bridgeAsset方法，發起跨鏈交易。該交易中的 destinationNetwork 參數被設置為Rollup2的Rollup ID。這個 Rollup ID將被用於檢索對應的 L1 層橋合約地址。若 Rollup ID為0，則代表目標網絡為L1。

接著，這筆交易被 Rollup1的sequencer1打包。跨rollup交易的費用，由交易發起者User1承擔，並支付給所在的Rollup1的sequencer1。 Rollup1 的 Bridge service將跨鏈資產先轉移到在 L1中的Rollup1橋合約。此時Rollup1和L1分別完成了資產的burn操作與release操作。

為了完成資產的跨 Rollup 轉移，Rollup1 的 Bridge 服務調用RRC合約來查詢參數 destinationNetwork 對應的目標 Rollup2信息，從而獲取到Rollup2在 L1 層的橋合約地址。然後，Rollup2的橋合約將直接接管這些資產，並通過bridgeAsset方法將資產映射到Rollup2中。

最終，這筆交易在成功打包並生成證明後，會被Rollup2 的 Bridge 服務執行 claimAsset 操作。最終，Rollup1 發出的跨鏈資產安全地到達Rollup2指定的地址。

值得一提的是，在整個跨鏈過程中，用戶的資產流經：Rollup1 -> Rollup1在L1的橋合約-> Rollup2在L1的橋合約-> Rollup2 。也就是說，用戶的資產沒有經過任何第三方協議，而是複用了Rollup自帶的native bridge，整個流程都是安全且無需信任的。

Opside推出NCRC協議，允許無需信任的原生跨Rollup通信

當用戶在 Rollup1 上執行跨鏈操作，選擇Rollup2作為目標，技術流程實際上涉及 Rollup1、L1 以及 Rollup2 這三者。然而，用戶在此過程中並不需要感知 L1 的存在，他們的體驗只是從 Rollup1 直接跨到了 Rollup2。背後的實際情況是跨鏈資產在 L1 中進行了2次橋接操作，使得用戶感受到的是 Rollup1到 Rollup2 的無縫連接。在這個過程中，L1 上的操作將自動處理，用戶不需要有其他的操作。對用戶而言，他們所在的當前 Rollup 可以實現向 L1 和任意其他 Rollup進行跨鏈操作。這種設計使得用戶體驗更加流暢，同時隱藏了底層複雜性。