Vitalik:爭吵該停了,我對Layer2的定義有話說

原文標題:《Different types of layer 2s》

撰文:Vitalik Buterin

編譯:BlockBeats

生態系統在過去一年中迅速擴展。 傳統上以 StarkNet、Arbitrum、Optimism 和 Scroll 為代表的 ZK-EVM rollup 生態系統進展迅速,不斷提高其安全性,L2beat 頁面很好地總結了每個項目的狀態。

此外,我們還看到一些團隊正在構建側鏈,同時也開始構建 rollup 方案(如 Polygon),一些 L1 專案試圖朝著有效性驗證方向發展(如 Celo),還有全新的嘗試(如 Linea、Zeth... )。

其中不可避免的結果之一是,我們看到 L2 專案趨向更加 heterogeneous(即「異構化」。 譯者注:在加密領域,「異構化」指的是不同種類或不同性質的事物共存或混合在一起的情況。 這個詞通常用於描述不同的區塊鏈、協定、技術或資產,它們具有不同的特性、規則或屬性)。 我預計這一趨勢將持續下去,原因如下:

目前,一些獨立的 L1 專案正尋求更緊密地與乙太坊生態系統接觸,並有可能轉變為 L2 專案。 這些專案可能希望採取分階段的過渡方式。 立即進行整體過渡將降低可用性,因為技術尚未準備好將所有內容放入 rollup 方案中。 而在較晚的整體過渡中,可能會犧牲勢頭並來不及具有實際意義。

一些中心化專案希望為其使用者提供更多的安全保障,並正在探索基於區塊鏈的途徑。 在許多情況下,這些項目過去可能會研究「許可聯盟鏈」。 實際上,它們可能只需要達到「半中心化」水準的程度。 此外,它們通常具有非常高的輸送量,至少在短期內不適合使用 rollup 方案。

非金融應用,如遊戲或社交媒體,希望去中心化,但只需要一定程度的安全性。

在社交媒體的情況下,實際上涉及以不同方式處理應用的不同部分:像使用者名註冊和帳戶恢復這樣的罕見且具有高價值的活動應該在 rollup 方案中完成,但像帖子和投票這樣頻繁且低價值的活動需要較少的安全保障,如果區塊鏈失敗導致您的帖子消失,那是可以接受的代價; 但如果區塊鏈失敗導致您丟失了您的帳戶,那將是一個更大的問題。

一個重要的主題是,儘管目前位於乙太坊 L1 的應用程式和使用者在短期內願意支付較小但仍然可見的 rollup 費用,但來自非區塊鏈世界的使用者不太願意這樣做:如果您之前支付了 1 美元,那麼支付 0.10 美元就更容易接受,而如果之前支付了 0 美元,那就難以接受。

這適用於今天仍然中心化的應用程式,以及通常在其用戶群體較小的情況下擁有極低費用的較小的 L1 專案。

一個自然而然的問題是:對於特定應用程式,rollup 方案、validiums(有效性驗證)和其他系統之間的這些複雜權衡中,哪一個對其而言是合理的?

Rollups vs Validiums vs Disconnected s

我們將探討的安全性與擴展性的第一個維度可以描述如下:如果您擁有一個在 L1 上發行的資產,然後將其存入 L2,再將其轉移到您手中,那麼您能獲得多大程度的保證可以將資產取回到 L1?

同時還有一個相關問題:是什麼技術選擇導致了這種保證程度,以及該技術選擇的權衡是什麼?

我們可以用一個簡單的圖表來描述這個問題:

! [Vitalik:爭吵該停了,我對Layer2的定義有話說] (https://cdn-img.panewslab.com//panews/2022/10/31/images/641c1134cde471478d058f6d0e2eaab1.jpg)

值得一提的是,這是一個簡化的方案,其中存在許多中間選項。 例如:

在 rollup 和 validium 之間:在 validium,任何人可以進行鏈上支付以支付交易費用,此時,操作者將被迫將一些數據提供到鏈上,否則將損失押金。

在 plasma 和 validium 之間:一個 Plasma 系統提供類似 rollup 的安全保證,具有鏈下數據可用性,但它僅支援有限數量的應用程式。 一個系統可以提供完整的EVM,併為那些不使用這些較複雜應用程式的使用者提供 Plasma 級別的保證,以及為使用這些應用程式的使用者提供 validium 級別的保證。

這些中間選項可以看作是在 rollup 和 validium 之間的一個 spectrum 上。 但是,是什麼促使應用程式選擇該spectrum上的特定點,而不是更左邊或更右邊的某個點呢? 在這裡,有兩個主要因素:

**1. 乙太坊原生數據可用性的成本,隨著技術的發展,這一成本將隨著時間的推移而降低。 **乙太坊的下一個硬分叉 Dencun 引入了 EIP-4844( 又稱 「proto-danksharding」),它提供了大約 32 kB/ 秒的鏈上數據可用性。

預計在未來幾年,隨著完整的 danksharding 推出,這一數據可用性將逐步提高,最終目標約為 1.3 MB/ 秒的數據可用性。 同時,數據壓縮的改進將讓我們在相同數據量下實現更多功能。

**2. 應用程式的自身需求:使用者在高費用方面的損失,相對於應用程式出現問題,有多嚴重? **金融應用程式會因為應用程式的故障而損失更多; 遊戲和社交媒體涉及大量的用戶活動,且相對較低價值的活動,因此對於它們來說,不同的安全權衡是有意義的。

這種權衡大致上看起來如圖所示:

! [Vitalik:爭吵該停了,我對Layer2的定義有話說] (https://cdn-img.panewslab.com//panews/2022/10/31/images/eb26cf8cf9fde9560ac2bdae8828a175.jpg)

另一種值得一提的類型是預確認(pre-confirmations)。 預確認是由一組參與者在 rollup 或 validium 中簽署的消息,表示「我們證明這些交易按此順序包含在其中,且 post-state root 是這個」。 這些參與者可能會簽署一個與現實不符的預確認,但如果確實如此,他們的押金將被銷毀。

這對於低價值應用(如消費者支付)非常有用,而高價值應用(如數百萬美元的金融轉帳)可能會等待由系統完整安全性支援的「常規」確認。

預確認可以被視為另一個混合系統的例子,類似於上文提到的「plasma/validium 混合」,但這次是在具有完整安全性但高延遲的 rollup(或 validium)與具有較低安全級別但低延遲的系統之間進行混合。 需要較低延遲的應用會獲得較低的安全性,但可以與那些願意為獲得最大安全性而承受較高延遲的應用共存於同一生態系統中。

無需信任地讀取乙太坊

另一種較少被考慮但仍然非常重要的連接形式,與系統讀取乙太坊區塊鏈的能力有關。 具體而言,這包括系統能夠在乙太坊發生回滾時進行回滾的能力。 要了解為什麼這是有價值的,請考慮以下情況:

! [Vitalik:爭吵該停了,我對Layer2的定義有話說] (https://cdn-img.panewslab.com//panews/2022/10/31/images/4de6c8f1f9b77155639e6a286f4162a1.jpg)

假設如圖所示,乙太坊區塊鏈發生回滾。 這可能是在一個紀元內的臨時中斷,此時區塊鏈尚未最終確定; 或者可能是因為過多的驗證者離線,而導致區塊鏈在較長時間內無法最終確定的非活動洩漏期。

由此可能產生的最糟糕情況如下所示:假設頂部鏈(top chain)的第一個區塊從乙太坊鏈的最左側區塊中讀取某些數據。 例如,有人在乙太坊上存入了 100 個 ETH 到頂部鏈中。 然後乙太坊發生回滾,然而頂部鏈沒有回滾。 結果是,頂部鏈的未來區塊正確地跟隨新的、正確的乙太坊區塊鏈上的區塊,但錯誤的交易(即 100 個 ETH 的存款)仍然存在於頂部鏈中。 這種漏洞可能導致貨幣的增發,將頂部鏈上的橋接 ETH 轉變為部分準備金。

有兩種方法可以解決這個問題:

  1. 頂部鏈只能讀取乙太坊已最終確定的區塊,因此它永遠不需要進行回滾;

  2. 如果乙太坊發生回滾,頂部鏈也可能發生回滾。 兩者都可以防止這個問題。 前者更容易實施,但如果乙太坊進入非活動洩漏期,可能會導致功能在較長時間內喪失。 後者更難實施,但可以確保始終具有最佳功能。

請注意,第一種方法確實存在一種特殊情況。 如果乙太坊發生了 51% 攻擊,導致同時出現兩個新的不相容區塊,它們都看起來已經最終確定,那麼頂部鏈可能會選擇錯誤的區塊(即乙太坊社會共識最終不支援的區塊),並且需要回滾以切換到正確的區塊。 可以說,事先編寫代碼來處理這種情況是沒有必要的; 可以通過對頂部鏈進行硬分叉來處理這個問題。

區塊鏈能夠在無需信任的情況下讀取乙太坊的能力有兩個重要原因:

首先,這種能力可以降低將在乙太坊(或其他第二層解決方案)上發行的代幣橋接到該鏈上涉及的安全問題;

其次,這種能力使得使用共用密鑰存儲結構的帳戶抽象錢包,能夠安全地持有該鏈上的資產。

儘管有爭議,但第一種方法的重要性已經被廣泛認可。 同樣,第二種方法也很重要,因為它意味著你可以擁有一個錢包,可以輕鬆更改密鑰,並在許多不同的鏈上持有資產。

擁有橋接器是否能成為 validium?

假設頂部鏈最初是作為一個獨立鏈啟動的,然後有人在乙太坊上部署了一個橋接合約。 橋接合約只是一個接受頂部鏈區塊頭(block headers)的合約,它會驗證提交給它的任何區塊頭是否附帶有效的證書,證明該區塊頭已被頂部鏈的共識接受,並將該區塊頭添加到清單中。

應用程式可以在此基礎上構建功能,如代幣的存款和提取。 一旦這樣的橋接建立起來,它是否提供了我們之前提到的任何資產安全保障呢?

! [Vitalik:爭吵該停了,我對Layer2的定義有話說] (https://cdn-img.panewslab.com//panews/2022/10/31/images/f2e4d6973f59d0520636a41407c9a20a.jpg)

到目前為止,還沒有! 有兩個原因:

  1. 我們正在驗證區塊的簽名,但沒有驗證狀態轉換是否正確。 因此,如果您將在乙太坊上發行的資產存入頂部鏈,並且頂部鏈的驗證器變得不誠實,他們可以簽署一個無效的狀態轉換,從而竊取這些資產;

  2. 頂部鏈仍然無法讀取乙太坊。 因此,您無法將乙太坊本地資產存入頂部鏈,除非依賴於其他(可能不安全)的第三方橋接。

現在,讓我們將橋接器構建為驗證型橋接器:它不僅驗證共識,還驗證了使用 ZK-SNARK 證明計算出的任何新區塊的狀態是否正確。

一旦完成這一步驟,頂部鏈的驗證器將無法竊取您的資金。 他們可以發佈一個包含不可用數據的區塊,阻止所有人提取資金,但他們無法竊取資金(除非試圖通過向使用者索要贖金來揭示允許其提取資金的數據)。 這與 validium 具有相同的安全模型。

然而,我們仍然沒有解決第二個問題:頂部鏈無法讀取乙太坊的數據。 為了實現這一點,我們需要採取以下兩種方式之一:

  1. 在頂部鏈中放置一個驗證已最終確定的乙太坊區塊的橋接合約;

  2. 在頂部鏈的每個區塊中包含一個最近乙太坊區塊的哈希,並採用分叉選擇規則來強制進行哈希連結。 也就是說,將連結到非主鏈上的乙太坊區塊的頂部鏈區塊本身,就是非主鏈的。 如果頂部鏈區塊鏈接到的乙太坊區塊起初在主鏈上,但後來變為非主鏈,頂部鏈區塊必須也成為非主鏈的。

! [Vitalik:爭吵該停了,我對Layer2的定義有話說] (https://cdn-img.panewslab.com//panews/2022/10/31/images/5fa31bfce1306e3527691085ad238a99.jpg)

這些紫色的連結可以是哈希連結,也可以是驗證乙太坊共識的橋接合約

這就夠了嗎? 實際上,還不夠,因為存在一些小的邊緣情況:

  1. 如果乙太坊遭受了 51% 攻擊,會發生什麼?

  2. 如何處理乙太坊的硬分叉升級?

  3. 如何處理您的鏈的硬分叉升級?

對乙太坊的 51% 攻擊會導致與頂部鏈的 51% 攻擊類似的後果,但情況相反。 乙太坊的硬分叉可能會使頂部鏈內的乙太坊橋接失效。 一個社會承諾(social commitment),即如果乙太坊還原了一個已最終確定的區塊,就會還原,如果乙太坊進行了硬分叉,就會進行硬分叉,是解決這個問題最乾淨的方式。

這樣的承諾實際上可能永遠不需要真正執行:如果頂部鏈的治理機構發現可能發生攻擊或硬分叉的證據,可以啟動治理機構,僅在治理機構失敗時才對頂部鏈進行硬分叉。

對於第三個問題,唯一可行的答案是,在乙太坊上設置某種形式的治理機構,使其能夠讓乙太坊上的橋接合約意識到頂部鏈的硬分叉升級。

總結:雙向驗證橋接幾乎足以使區塊鏈成為 validium。 主要剩下的要素是一種社會承諾,即如果乙太坊發生異常情況導致橋接合約無法正常工作,另一條區塊鏈將進行硬分叉作出回應。

結論

「與乙太坊連接」有兩個關鍵維度:

  1. 提取到乙太坊的安全性;

  2. 讀取乙太坊的安全性。

這兩者都非常重要,並有不同的考慮因素。 在這兩種情況下都存在一個連續譜:

! [Vitalik:爭吵該停了,我對Layer2的定義有話說] (https://cdn-img.panewslab.com//panews/2022/10/31/images/8c582e1b1fa730531869238da7787bbc.jpg)

請注意,每個維度都有兩種不同的衡量方式(實際上有四個維度):提取安全性可以通過(i)安全級別,和(ii)多少使用者或使用方式受益於最高安全級別來衡量;

而讀取安全性可以通過(i)鏈路能夠多快讀取乙太坊的區塊,特別是最終確定的區塊與任何區塊的區別,以及(ii)鏈路在處理諸如 51% 攻擊和硬分叉等邊緣情況時的社會承諾程度來衡量。

在這個設計空間的許多區域中都存在項目的價值。 對於某些應用程式,高度的安全性和緊密的連接至關重要。 對於其他應用程式,為了獲得更大的可擴充性,可以接受更寬鬆的條件。 在許多情況下,從今天開始使用較寬鬆的條件,隨著技術的改進,在未來十年內逐漸過渡到更緊密的耦合可能是最優選擇。

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