閱讀更多關於為什麼 Rollups 需要安全委員會的資訊?

原作者:派翠克·麥考里

原創:路飛、遠見新聞

任何與加密資產交互的資料庫總有一天會選擇 Rollup 作為技術堆疊。 開發人員做出這樣的決定有很多很好的理由:

  • 實時審計
  • 預設償付能力憑證
  • 使用者資金託管是可選的
  • 誠實的一方參與者保護整個系統

最重要的是,Rollup 的所有設計和實施工作都集中在保護使用者、他們的資金以及他們的所有交互中免受潛在未知和強大的系統運營商的影響。

即使整個系統處於離線狀態,使用者也可以自行收回資金。

如果Rollups可以作為技術堆疊廣泛部署,那麼我們可能有能力打破信任障礙,為全球社區中的任何人提供財務互動,從而開創全球電子商務,遠端招聘和無摩擦服務交付的新時代。

要使匯總正確執行,確實需要付出很多努力。

多重簽名呢?

這聽起來不錯,但整個系統最終由多重簽名控制。 如果簽名者遭到入侵或惡意,那麼他們可以輕鬆竊取所有資金。

那麼,誰在乎Rollups?在CT的某個地方。

的確,當前所有匯總都有多重簽名,並有權升級底層智能合約,但正如我們將看到的,它是一種保護用戶資金的保守機制,是更廣泛的系統架構的一部分。

安全委員會的職責

多重簽名是一個技術術語,指的是需要多個簽名者授權操作的系統。 例如,N 個簽名者中的 K 完成允許交易的數位簽名。

在匯總的上下文中,多重簽名通常被稱為安全委員會,簽名者有權升級所有相關的智能合約。

讓我們看一下仲裁中的安全理事會(因為我非常熟悉它),以了解該組織可能承擔的責任類型:

*否決權。 如果安全委員會認為仲裁DAO通過的提案違反了仲裁章程,並可能損害仲裁生態系統,則可以取消該提案。 例如,取消由於治理攻擊而通過的提案。 *維護。 升級 Arbitrum 智慧合約套件,進行影響較小且不需要 Arbitrum DAO 參與的微小更改。

  • 緊急情況。 在緊急情況下快速回應,如果他們認為用戶資金面臨迫在眉睫的風險,他們可以緊急升級智能合約。

當然,最重要的是,安全委員會的首要職責是應對緊急情況,迅速採取行動保護用戶資金。

安全委員會的成員需要是非常值得信賴的人。

人們相信簽名者能夠快速做出反應,能夠在緊急情況下升級智能合約,並盡最大努力確保智慧合約中的資金安全。

選擇正確的多重簽名閾值

在決定成立安全委員會時,需要考慮兩個重要因素:

  • 有多少個簽署國?
  • 批准一項行動所需的最低簽署人數是多少?
  • 這似乎是一個微不足道的問題,畢竟它只是兩個數位,但必須考慮一個平衡行為:
  • 安全漏洞:K 成員可能串通更改智慧合約並竊取用戶資金。
  • 主動違規:N-K+ 1 成員串通起來阻止對智慧合約進行任何更改,尤其是在發現嚴重漏洞的情況下。

面臨的挑戰是建立一個門檻,既能保證和平時期的資金安全,又能在用戶資金受到威脅時在緊急情況下迅速採取行動。

讓我們考慮一個具體的例子。 假設閾值設置為 9/10,其中 9 個簽名者必須共同簽署郵件。 這是一個嚴格的安全門檻,因為9個簽名者必須串通竊取資金。 然而,不利的一面是,任何兩個簽署方都可以在緊急情況下阻止任何行動。 例如,如果兩個簽署方乘坐跨大西洋航班遠行,安全委員會將無法履行其職責。

當然,如果安全門檻很低,比如說 2/10,那麼只需要任意兩個簽名者串通(或者私鑰被洩露)就可以竊取用戶資金。

深读解读为什么Rollup都需要安全委员会?

對一個人正直的看法可能會隨著時間的推移而改變

選擇適當的門檻與其說是技術問題,不如說是一個社會問題,我認為這與其說是一門科學,不如說是一門藝術。 安全性高度依賴於單個簽名者的完整性。 正如我們稍後將看到的,有一些方法可以降低對多重簽名的信任,但這需要權衡取捨。

安全委員會成員

深读解读为什么Rollup都需要安全委员会?

主匯總立即升級所有智慧合約所需的多重簽名閾值

大多數匯總在其安全委員會中都有一組匿名簽名者。 我們懷疑這可能是由於:

  • 匯總的發展階段,
  • 為了保護會員的人身安全,
  • 相信匿名是保護用戶資金的最佳選擇。
  • 另一方面,有三個匯總專案公開宣佈了其安全委員會成員資格: *仲裁:簽名者是公開選舉產生的,當前名單可以在Tally上查看。 只有三個簽署者與Arbitrum項目有關(兩個來自Offchain Labs,一個來自Arbitrum基金會)。
  • 基數:2/2 多重簽名,一個由 Base 控制,另一個由 Optimism 控制。 Polygon zkEVM:尚未實施,但他們已經宣佈將把他們的多重簽名升級到10/13,其中包括來自Polygon Labs的兩名成員和Polygon Labs的一名顧問。 zkSync Lite:zkSync Lite應與ZkSync Era區分開來,ZkSync Era的安全委員會是公開宣佈的,不包括Rollup專案的直接附屬公司(zkSync的投資者除外)。

在Arbitrum和即將推出的Polygon中,只有少數簽署者與Rollup專案直接相關,而且數量足夠小,可以確保附屬公司不能串通阻止安全委員會採取的行動。 在zkSync Lite中,除了zkSync的投資者外,他們還任命獨立於項目的簽名者。

在所有情況下,匯總都會對與專案沒有直接關係的簽名者給予很高的價值。

然而,對於什麼是好的多重簽名似乎缺乏共識,這給我們帶來了幾個設計問題:

  • 應該允許匿名會員嗎?
  • 成員應該來自不同的地區嗎?
  • 會員應該是個人還是公司?
  • 成員應由任命還是選舉產生?
  • 應該允許來自同一公司(或國家)的多少名成員?
  • 是否有合適的最小大小和閾值?

一般的經驗法則應該是挑選具有高度誠信的成員,以便公眾對系統的安全性充滿信心。 至少,我相信大多數專案可能會這樣做,即使這並不總是公開可驗證的。

附言:仲裁安全委員會的六名成員目前是預先任命的,但他們將在3月的選舉中被取代。

削弱委員會的權力

深读解读为什么Rollup都需要安全委员会?

到目前為止,我們只考慮過一個有權立即升級智慧合約的委員會,但有一些方法可以限制委員會的權力:

延時。 委員會授權的所有行動將不會執行,並在T經過之前生效。

僅暫停。 原生跨鏈橋持有的所有資產都可以由委員會凍結。 這可能會暫停以下功能:

  • 將消息從L2傳遞到L1(即取款),
  • 完成待處理交易的排序, *完成新的檢查點/證書,
  • 接受新的匯總數據(即待處理事務)。

繞過委員會(已刪除)。 放棄委員會,依靠另一種治理機制(如 DAO)來批准升級。

當然,這限制了委員會迅速採取行動的能力及其對威脅用戶資金的緊急情況作出有效反應的能力。

如果漏洞已私下披露給委員會,但尚未被駭客利用,安全委員會可以選擇升級智慧合約並修復錯誤。 向升級添加時間延遲會增加攻擊者研究公開披露的升級、發現漏洞,然後利用它的風險。

例如,BTC中的CVE-2018-17144最初被宣傳為DDoS漏洞,試圖隱藏更嚴重的代幣通脹漏洞。 升級速度對於防止其被利用至關重要。

評估僅暫停機制的防禦

讓我們考慮攻擊者主動利用漏洞的潛在場景:

  • 惡意 L2 → L1 消息。 攻擊者可以在匯總上手工創建源自智慧合約的任意消息,並通過本機跨鏈橋將消息轉發到ETH上的智能合約。
  • 無效的狀態轉換。 攻擊者可以在匯總上執行違反狀態轉換函數規則的事務,通常應將其視為無效。
  • 提款漏洞。 攻擊者只需在ETH方(第 1 層)上發佈交易即可從原生跨鏈橋中提取資金。

在所有三種情況下,時間延遲只會讓攻擊者有更多時間繼續竊取資金,並減少委員會捍衛系統的機會視窗。 延時攝影功能不能防止主動攻擊,只能用於日常維護和非緊急任務。

我們只會評估暫停系統的能力以及系統可以暫停的程度。

在惡意 L2 → L1 消息的情況下,暫停功能可以在不干擾交易活動的情況下緩解攻擊。 委員會應暫停發送消息和/或最終確定新檢查站的功能。 有一種觀點認為,在執行L2→L1消息之前應該有時間延遲,以便委員會有時間發現錯誤並對緊急情況做出反應。

防禦無效狀態轉換更加棘手,因為事務最終性在匯總中具有不同的層。 如果我們只考慮匯總事務而不考慮任何副作用,那麼安全委員會的最佳防禦措施是停止檢查點最終確定的能力,但繼續允許對事務進行排序。 這允許有時間修復錯誤,重新啟動檢查點完成,並簡單地忽略無效事務。

但是,如果未關閉匯總上的交易活動,用戶體驗將混亂,並且匯總可能會嚴重損壞,直到用戶端軟體升級。

這將我們帶到下一個場景。 如果我們考慮匯總上的無效事務如何影響其他系統,委員會應該如何反應。 最好的防線是凍結原生跨鏈橋完成交易排序的能力,或者完全關閉排序器。

這是因為某些系統,例如將資金從一個匯總轉移到另一個匯總的快速跨鏈橋,一旦它們認為匯總的交易(包括無效交易)被排序,可能會授權轉移資金。 在此示例中,它可能允許攻擊者利用匯總上的 DeFi 協定,然後通過快速跨鏈橋將其轉移到另一個匯總,從而快速轉移資金。

當委員會修復違規行為並恢復無效交易時,損害可能已經造成。 DeFi協定和跨鏈橋中的LP都可以承擔攻擊的成本。

最後,如果該漏洞允許攻擊者直接從原生跨鏈橋中提取資金,類似於Nomad Hack,安全委員會可能無力阻止它。

懸掛機制最終存在一個總體問題。 我們必須假設有一個更廣泛的治理系統可以批准升級和重新啟動匯總。 如果我們假設治理系統是一個在 Rollup 上運行鏈上投票系統的 DAO,那麼就會出現棘手的實現問題。

例如,如果 L2→L1 消息跨鏈橋暫停,則 DAO 的投票結果無法從匯總傳遞到ETH上的原生跨鏈橋,DAO 必須有替代方式發送批准並執行升級。

逐步解散安全理事會

社區中有些人認為應該逐步取消安全委員會,但在我看來,這帶來了兩個問題:

虛假的安全感。 知道此漏洞的攻擊者會等到安全委員會逐步退出后再執行攻擊。 隨著時間的推移,這可能會削弱我們對系統安全性的信心。

恢復選項有限。 沒有安全委員會,社區就無法反擊攻擊者。 唯一可用的選擇是運行並行的白帽駭客攻擊,並希望收回一些資金。

在我看來,安全委員會永遠是必要的,但賦予它們的權力應該逐漸減少。

考慮到這一點,設計問題應該是:

我們如何才能讓安全委員會在對用戶影響最小的情況下暫停系統,同時允許更廣泛的社區參與決定如何修復錯誤和重新啟動系統?

換句話說,我們需要一個真正允許社區介入並恢復系統的計劃,然後限制安全理事會的暫停權力。

在第 1 層區塊鏈空間中,確實可以使用使用者啟動的分叉直接到達社區,但這種方法不適用於ETH方塊上的智能合約(例如 Rollups),因為不需要分叉整個ETH。 在某些情況下,ETH社區可能會集體決定保存匯總,就像 2016 年的 TheDAO 一樣,但匯總永遠不應該依賴或期望這樣的結果。

沿著這些思路的另一個有趣的想法是為最高法院實施一個ETH,以決定智慧合約升級並啟用類似於用戶啟動的分叉。

如前所述,如果 Rollup 將其安全性委託給 DAO,那麼應該有一個允許 DAO 直接對ETH進行投票的實現。 這是非常棘手的,特別是如果投票協定存在於匯總中。

最後,我認為,需要全面審查可能需要安理會作出反應的局勢類型,以便利圍繞其必要性進行討論。

如果您有多重簽名,為什麼要擔心匯總?

我們花了相當多的時間瞭解安全委員會的職責、設計和需求,但重要的是要回到本文中的原始問題:

匯總只是一個多重簽名嗎?

答案是否定的。

為了説明理解原因,最好退後一步,了解區塊鏈系統真正想要做什麼。

區塊鏈協定是一種工具,允許使用者計算資料庫的副本,並確信他們擁有與其他人相同的資料庫。

考慮到這一點,任何區塊鏈系統都有兩個元件:

*區塊鏈協定。 軟體、加密和分散式系統的結合使任何人都對資料庫的完整性充滿信心。

  • 治理體系。 一種協調機制,允許所有利益相關者共同努力並就區塊鏈協定的更改達成一致。

任何區塊鏈系統(包括Rollup)的目標都是確保區塊鏈協議始終以99.9999%的極其可靠的正常運行時間運行。 受信任的系統操作員應該對系統的日常運行幾乎沒有干擾。 最終,軟體、密碼學和分散式系統最終負責保護用戶餘額、智慧合約代碼和狀態。

有時需要更改區塊鏈協定以提高用戶的興趣。 社區可能希望修復配置問題、添加新功能或對威脅系統完整性的關鍵漏洞做出反應。 這需要人為干預,並且只能調用0.0001%的時間。

治理系統負責實施人為干預,多年來出現了幾種方法:

極權主義政黨:單邊政黨可以單獨決定如何升級系統(包括BTC在內的許多專案都是以這種方式開始的)。

  • 粗略共識:大多數參與者表示他們已準備好部署升級,確定標記日,然後在標記日(BTC/ETH)執行升級。
  • 投票協定:所有政黨都參與選舉,並明確投票決定是否批准升級。 *無干擾:智能合約可以是不可變的,系統永遠無法更改。

除此之外,社區還可以決定任命一個安全委員會作為治理的補充選項,以便在緊急情況下迅速採取行動。

安全理事會沒有制止這次襲擊。 這是一種被動機制,當區塊鏈協定的用戶資金或系統可靠性/性能受到攻擊時,它與治理一起工作。

最後

圍繞區塊鏈協定、治理和安全委員會的所有討論都至關重要。 這種討論的存在使加密貨幣如此特別。

這是信任工程的一個很好的例子:一門專注於識別、測量和減少/消除系統中信任元素的工程學科。

在加密貨幣方面,我們專注於構建系統,不僅保護使用者免受強大的系統運營商的侵害,而且使他們能夠在最不利的條件下可靠(安全地)運行。

這就是為什麼社區成員對安全委員會的作用持懷疑態度是健康的,但他們有責任在緊急情況下提出更好的解決方案,以被動的方式保護用戶資金。

我希望這篇文章能闡明為什麼安全委員會是有用的,它們在今天是必要的,但它們只是智慧合約系統更廣泛架構的一小部分。

查看原文
此頁面可能包含第三方內容,僅供參考(非陳述或保證),不應被視為 Gate 認可其觀點表述,也不得被視為財務或專業建議。詳見聲明
  • 讚賞
  • 留言
  • 轉發
  • 分享
留言
0/400
暫無留言
交易,隨時隨地
qrCode
掃碼下載 Gate App
社群列表
繁體中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)