DA的可擴展性:Avail目前的狀態

avatar
ODAILY
11-20

DA的可擴展性:Avail目前的狀態

隨著用戶開始將 Avail 集成到他們的鏈設計中,經常會出現一個問題:“Avail 能處理多少交易?”在這篇文章中,我們將根據目前兩個鏈的架構,比較以太坊和 Avail 的吞吐量。

這是關於 Avail 擴展性系列文章的第一篇,將討論 Avail 目前的性能以及其在近期和長期的擴展能力。

Avail vs Ethereum

以太坊的區塊最大可以容納 1.875 MB 數據,區塊時間約為 13 秒。然而,以太坊的區塊通常並不是被填滿的。幾乎每個區塊都會因為達到 gas 限制而未達到數據的上限,因為執行和結算都消耗 gas。因此,每個區塊存儲的數據量是可變的。

將執行、結算和數據可用性結合在同一個區塊中的需求,是單一區塊鏈架構的核心問題。L2 rollup 開始了模塊化區塊鏈的運動,允許在一個單獨的鏈上處理執行操作,且該鏈的區塊專門用於執行。Avail 進一步採用了模塊化設計,將數據可用性也解耦,允許一個鏈的區塊專門用於數據可用性。

DA的可擴展性:Avail目前的狀態

目前,Avail 的區塊時間為 20 秒,每個區塊可容納大約 2 MB 數據。假設平均交易大小為 250 字節,每個 Avail 區塊今天可以容納大約 8, 400 筆交易(每秒 420 筆交易)。

更重要的是,Avail 可以始終將區塊填滿到存儲限制,並根據需要增加大小。我們有許多可以快速調整的槓桿,以在需要時將每個區塊的交易數量提高到超過 500, 000 筆(每秒 25, 000 筆交易)。

我們能增加吞吐量嗎?

為了增加吞吐量(特別是每秒交易數),鏈的架構師需要增加區塊大小或減少區塊時間。

要被添加到鏈上,每個區塊必須產生承諾、構建證明、傳播它們,並讓所有其他節點驗證這些證明。這些步驟始終需要時間,這為區塊的生成和確認時間設定了一個自然的上限。

因此,我們不能將區塊時間簡單地減少到比如一秒鐘。這樣根本沒有足夠的時間來產生承諾、生成證明,並將這些部分傳播給整個網絡的所有參與者。在理論上的一秒鐘區塊時間內,即使每個網絡參與者都運行著能夠瞬間產生承諾和證明的最強大的機器,瓶頸也在於數據的傳播。由於互聯網速度的限制,網絡無法足夠快地將區塊通知給所有全節點。所以我們必須確保區塊時間足夠高,以允許在達成共識後將數據分發到網絡中。

相反,通過增加區塊大小來也可以增加吞吐量,即增加我們每個區塊可以包含的數據量。

當前架構:向鏈上添加一個區塊

首先,讓我們看看向鏈上添加一個區塊所需的步驟。向鏈上添加每個區塊需要三個主要步驟。這包括生成區塊、傳播區塊和驗證該區塊所需的時間。

DA的可擴展性:Avail目前的狀態

1. 區塊生成

這一步包括收集和排序 Avail 交易、構建承諾以及擴展(糾刪碼)數據矩陣所需的時間。

區塊生成測量生成區塊所需的時間,因為這至少總是需要一些時間。因此,我們必須考慮不僅是最佳情況下的時間,還有在不同機器上的平均情況和最壞情況下的時間。

能夠參與新區塊生成的最弱機器是在平均情況下性能達到極限的那一臺。所有更慢的機器最終都會落後,因為它們無法趕上更快的機器。

2. 傳播延遲

傳播延遲是衡量將區塊從生產者傳播到驗證者和點對點網絡所需的時間。

目前,Avail 的區塊大小為 2 MB。在當前 20 秒的區塊時間限制內,這樣的區塊大小可以被傳播。更大的區塊尺寸使得傳播變得更加棘手。

例如,如果我們增加 Avail 以支持 128 MB 的區塊,計算可能能夠擴展(約 7 秒)。然而,瓶頸則變成了在網絡上發送和下載這些區塊所需的時間。

在 5 秒內通過點對點網絡向全球發送 128 MB 的區塊可能是目前可以實現的極限。

128 MB 的限制與數據可用性或我們的承諾方案無關,而是通信帶寬限制的問題。

這種需要考慮傳播延遲的需求為我們提供了 Avail 當前理論上的區塊大小限制。

3. 區塊驗證

一旦傳播完畢,參與的驗證者並不會簡單地信任由區塊提議者提供給他們的區塊 —— 他們需要驗證生產出的區塊是否真的包含了生產者所聲稱的數據。

這三個步驟之間存在一定的緊張關係。我們可以讓所有的驗證者都是強大的機器,並通過同一數據中心的優秀網絡緊密連接起來 —— 這將減少生產和驗證時間,並讓我們傳播大量更多的數據。但是,因為我們也希望擁有一個去中心化、多樣化的網絡,包含不同類型的參與者,所以這並不是一個理想的方法。

相反,吞吐量的提升將通過理解向 Avail 鏈添加區塊所需的步驟,以及哪些步驟可以優化來實現。

DA的可擴展性:Avail目前的狀態

目前,使用 Avail 的驗證者會取得整個區塊,並複製提議者生成的所有承諾,以驗證區塊。這意味著區塊生產者和所有驗證者都需要執行上面圖表中的每個步驟。

在單一區塊鏈中,每個驗證者重建整個區塊是默認做法。然而,在像 Avail 這樣的鏈上,交易不被執行,這種重建並不是必需的。因此,我們可以優化 Avail 的一種方式是允許驗證者通過採樣來達到對數據可用性的自己的保證,而不是通過重建區塊。這比要求他們複製所有承諾,對驗證者的資源要求更低。更多相關內容將在後續文章中介紹。

探索數據可用性採樣是如何工作的?

在 Avail 中,輕客戶端使用三個核心工具來確認數據的可用性:樣本、承諾和證明。

  • 目前輕客戶端執行樣本操作,它們向 Avail 網絡請求特定單元格的值及其相關的有效性證明。他們採集的樣本越多,就越能確信所有數據都是可用的。

  • 承諾由區塊提議者生成,總結了 Avail 區塊中一整行的數據。(提示:這是我們將在本系列後續優化的步驟。)

  • 網絡中的每個單元格都會生成證明。輕客戶端使用證明和承諾來驗證提供給它們的單元格的值是否正確。

使用這些工具,輕客戶端然後執行三個步驟。

  • 決定:所需的可用性信心決定了輕客戶端執行的樣本數量。他們不需要許多樣本(8-30 個樣本)就能達到超過 99.95% 的可用性保證。

  • 下載:輕客戶端然後請求這些樣本及其相關證明,並從網絡(全節點或其他輕客戶端)下載它們。

  • 驗證:他們查看區塊頭部的承諾(輕客戶端始終可以訪問),並針對承諾驗證每個單元格的證明。

僅憑這些,輕客戶端就能在不需要下載區塊的絕大部分內容的情況下確認區塊中所有數據的可用性。輕客戶端執行的其他步驟也有助於 Avail 的安全性,但未在此列出。例如,輕客戶端能夠與其他輕客戶端共享他們下載的樣本和證明,以防他們需要。但這就是輕客戶端確認數據可用性的程序!

在本系列的第二部分中,我們將探討短期內提高 Avail 吞吐量的方法。我們將解釋為什麼我們相信 Avail 能夠滿足未來一年內任何網絡的需求,並且如何改進網絡以迎接未來幾年的挑戰。

來源
免責聲明:以上內容僅為作者觀點,不代表Followin的任何立場,不構成與Followin相關的任何投資建議。
喜歡
收藏
評論