了解Polygon新產品Avail 一種可擴展數據可用性層

我們非常高興地宣布 Avail——未來區塊鏈如何運作的全新方式的重要組成部分。 Avail 是一個通用的、可擴展的、以數據可用性為中心的區塊鏈，適用於獨立鏈、側鏈和鏈外擴展解決方案。

Avail 通過使用極其安全的數學原語提供了一個強大的數據可用性層——使用具有關鍵創新的糾刪碼進行數據可用性檢查——我們使用 Kate 多項式承諾來創建一個二維數據可用性方案，避免欺詐證明，不需要誠實的多數假設，並且不依賴誠實的全節點來獲得數據可用的信心。

Avail 提供了一個通用的數據可用性層，可供不同的執行環境使用，例如獨立鏈、側鏈和鏈下擴展解決方案。從長遠來看，它將支持在執行環境方面和最終實施方面的各種實驗，而無需團隊和項目自行啓動自己的安全性。使用 Polygon SDK、Cosmos SDK 或 Substrate 創建的鏈可以受益於為此目的使用 Avail。

Avail 將交易執行和有效性與共識層解耦，因此共識只負責 a) 對交易進行排序和 b) 保證其數據可用性。

主要目標

• 啓用具有任意執行環境的獨立鏈或側鏈，以通過保證交易數據可用性來引導驗證器安全性，而無需創建和管理自己的驗證器集

• Validiums 等二層（Layer 2）解決方案通過將 Avail 用作鏈下數據可用性層來提供更高的可擴展性吞吐量

自 2020 年底以來，我們一直在祕密研究 Avail，目前，它處於 Devnet 階段。 測試網正在开發中。 可以在參考文檔中找到有關問題、架構和解決方案的更多詳細信息，包括對代碼庫的引用。

背景

在當今類似以太坊的生態系統中，主要有三種類型的節點：

1. 驗證節點

2. 全節點

3. 輕客戶端

一個區塊由驗證器節點附加到區塊鏈，該節點從內存池收集交易，執行它們，在通過網絡傳播之前生成區塊。該區塊包含一個小區塊頭，其中包含與該區塊中包含的交易相關的摘要和元數據。整個網絡的全節點接收該區塊並通過重新執行該區塊中包含的交易來驗證其正確性。輕客戶端僅根據需要從相鄰的全節點獲取區塊頭和交易細節。區塊頭中的元數據使輕客戶端能夠驗證接收到的交易細節的真實性。

雖然這種架構非常安全並已被廣泛採用，但它有一些嚴重的實際限制。由於輕客戶端不會下載整個區塊，因此它們可能會被誘騙接受底層數據不可用的區塊。區塊生產者可能會在一個區塊中包含惡意交易，而不會將其全部內容透露給網絡。這被稱為數據可用性問題，對輕客戶端構成嚴重威脅。更糟糕的是，數據不可用是一種不可歸因的故障，這使我們無法添加欺詐證明結構，該結構允許全節點以令人信服的方式通知輕客戶端丟失數據。

現有區塊鏈架構 vs.Polygon Avail

相比之下，Avail 採取了不同的方法來解決這個問題——它不是驗證應用程序狀態，而是專注於確保發布的交易數據的可用性，並確保交易排序。只有當該區塊背後的數據可用時，具有共識的區塊才被認為是有效的。這是為了防止區塊生產者在不釋放區塊頭背後的數據的情況下釋放區塊頭，這將阻止客戶端讀取計算其應用程序狀態所需的交易。

Avail 將區塊驗證的問題簡化為數據可用性驗證，這可以使用數據可用性檢查以恆定成本高效完成。數據可用性檢查利用糾刪碼，在數據冗余設計中大量使用。

數據可用性檢查要求每個輕客戶端從鏈中的每個區塊中採樣非常少量的隨機區塊。一組輕客戶端可以以這種方式對整個區塊鏈進行集體採樣。一個很好的思維模型是像 Torrent 這樣的 p2p 文件共享系統這樣的系統，其中不同的節點通常只存儲文件的某些部分。

請注意，這些技術將在 Ethereum 2.0 和 Celestia（以前稱為 LazyLedger）等系統中大量使用。

這也導致了一個有趣的結果：網絡中存在的非共識節點越多，您可以安全地擁有的區塊大小（以及吞吐量）就越大。這是一個有用的屬性，因為它意味着非共識節點也可以為網絡的吞吐量和安全性做出貢獻。

KZG 基於承諾的方案

在 Avail 使用的基於 KZG 承諾的方案中，主要有三個特點：

1. 數據冗余使出塊者很難隱藏區塊的任何部分。

2. 無欺詐保證正確糾刪碼

3. 向量承諾，允許全節點使用簡潔的證明說服輕節點包含交易。

簡單來說，一個區塊中的整個數據被排列成一個二維矩陣。通過對矩陣的每一列進行擦除編碼以將原始列的大小加倍來引入數據冗余。 Kate 承諾用於提交每一行，並且承諾包含在區塊頭中。該方案可以輕松捕獲數據隱藏嘗試，因為任何只能訪問區塊頭的輕客戶端都可以查詢矩陣的隨機單元格並獲得可以根據區塊頭檢查的簡短證明（多虧Kate 承諾）。數據冗余迫使區塊生產者隱藏區塊的大部分，即使它只想隱藏單個交易，使其容易被隨機抽樣捕獲。我們避免了欺詐證明的需要，因為 Kate 承諾的約束性使得區塊生產者構建錯誤的承諾而不被抓住在計算上是非常不可行的。此外，可以使用 KZG 承諾方案的同態屬性計算擴展行的承諾。

KZG承諾方案

盡管我們在這裏提到了Avail構造的主要功能，但還有其他功能，例如部分數據獲取和協作可用性保證。我們在這裏省略了細節，並將在後續文章中重新討論它們。

現在可能是舉個例子並演練實際用例的好時機。假設一個新的應用程序想要托管一個特定於應用程序的獨立鏈。它使用 Polygon SDK 或任何其他類似框架（如 Cosmos SDK 或 Substrate）啓動新的 PoS 鏈，並將業務邏輯嵌入其中。但它面臨着通過驗證者質押獲得足夠安全性的引導問題。

為了避免這種情況，它使用 Avail 進行交易排序和數據可用性。應用程序用戶向 Polygon SDK 鏈提交交易，這些交易會自動轉發到 Avail，並在那裏自行維護訂單。有序的事務由一個（或多個）操作員拾取，並根據業務邏輯構建最終的應用程序狀態。應用程序用戶可以放心，有序數據是可用的，並且可以自己在任何時候重建應用程序狀態，使他們能夠使用由 Avail 提供的強大安全保證的鏈。

雖然上面的例子討論了一個使用 Avail 來保證安全的新獨立鏈，但該平臺是通用的，任何現有的鏈也可以使用它來確保數據可用性。在下一節中，我們將簡要提及 Avail 如何幫助現有匯總擴展以太坊。

關於以太坊鏈下擴展解決方案數據可用性的說明

已經提出了各種各樣的以太坊Layer 2解決方案，例如Optimistic Rollup、ZK Rollup和 Validiums。這些解決方案將執行移到鏈下，同時確保應用程序驗證和數據在鏈上的可用性。雖然基於鏈下執行的架構提高了吞吐量，但它仍然受到像以太坊這樣的主鏈可以處理的數據量的限制。這是因為雖然執行是鏈下的，但驗證或爭議解決是嚴格在鏈上進行的。交易數據在以太坊上作為 calldata 提交，以確保數據可用於未來的重建。這是極其重要的。

在Optimistic Rollup的情況下，操作者可能會提交無效交易，然後向整個區塊鏈壓制部分區塊。這樣，系統中的其他全節點將無法驗證提交的斷言是否正確。由於缺乏數據，他們將無法產生任何欺詐證明/挑战來證明該斷言確實無效。

在基於零知識的Rollup的情況下，ZKP 穩健性確保接受的交易是有效的。然而，即使有這樣的保證，不透露支持交易的數據也會產生嚴重的副作用。

這可能會導致其他驗證者無法計算系統的當前狀態，以及用戶被排除在系統之外並且他們的余額被凍結，因為他們沒有訪問該余額所需的信息（見證人）。

我們認識到，為了實現更高的吞吐量，我們不僅需要將執行置於鏈下，還需要有一個可擴展的數據托管層來保證數據可用性。

這種區塊鏈設計需要解決以下部分：

• 數據托管和排序：這部分將接收事務數據並對其進行排序，無需任何執行。然後它將存儲數據並以分散的方式確保完整的數據可用性。這是Avail的關鍵。

• 執行：執行組件應該從 Avail 中獲取有序交易並執行它們。它應該創建一個檢查點/斷言/證明並將其提交給數據驗證層。我們稱之為執行層。

• 驗證/爭議解決：這部分代表系統錨定的主鏈。設計的安全性取決於該部分的穩健性和安全屬性。執行層提交的檢查點/斷言/證明由該層處理，以保證系統中僅接受有效的狀態轉換（前提是數據可用）。我們將這部分稱為數據驗證層。

本文作者：Polygon官方

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。