jakiro
作者：Steve 來源：4pillars 翻譯：善歐巴，比特鏈視界
要點
-
「並行執行」是過去一年區塊鏈行業的關鍵詞之一。然而，要真正實現並行執行，還需要各個領域的創新，其中最關鍵的是區塊鏈資料庫的完善。
-
EVM並行處理的先驅之一Sei已經意識到了這種必要性，並從去年開始就不斷考慮資料庫優化。這些努力的成果就是 Sei DB。
-
Sei DB將傳統的單一資料庫結構轉變為分為兩層的模塊化結構。它消除了不必要的元數據並優化了狀態訪問，從而消除了資料庫級別的低效率並提高了區塊鏈的整體性能。Sei 的方法不僅對於追求事務並行性的區塊鏈來說是一個很好的例子，而且對於旨在提高整體區塊鏈效率的構建者來說也是如此。
2023年和2024年區塊鏈市場周期升溫的關鍵詞不少，Meme幣、Farcaster、restake等都在其中。然而，我發現技術上最有趣的關鍵詞是「事務並行執行」。雖然市場對 EVM 並行處理很熟悉，但我認為通過並行化交易從根本上提高區塊鏈性能比 EVM 本身更重要。
說到「交易並行執行」，你可能會想到各種鏈，但我第一個想到的就是Sei區塊鏈。他們並不是第一個引入事務並行處理概念的人，但他們在市場上普及這個關鍵詞方面發揮了重要作用。截至撰寫本文時，Sei Network 已成為第一個能夠進行 EVM 並行處理的 Layer 1 區塊鏈。這是因為他們已經通過了一項支持 EVM 並行處理的治理提案。
Sei V2治理提案的通過意義重大，因為它表明以前被認為難以實施的事務並行處理已經達到了實用階段。為什麼事務並行處理的應用如此困難？我的調查揭示了幾個原因。首先，影響同一狀態的交易之間很可能發生衝突（例如更改相同帳戶餘額的交易）。確定交易順序時，複雜性也會增加。最重要的是，即使事務在執行層並行化，如果沒有資料庫級別的優化，也很難實現可擴展性的顯著提升。這些問題使得事務並行處理的實施變得尤為困難。
Sei的聯合創始人兼CTO Jayendra一直通過各種媒體渠道指出這個問題（資料庫級優化）。如果 EVM 並行處理或一般的事務並行處理僅被視為區塊鏈「執行」級別的優化，則無法實現顯著的可擴展性改進。因此，要討論通過並行處理提高性能，必須解決如何實現資料庫級優化。
今天我想談談Sei區塊鏈是如何優化其資料庫的。請注意，資料庫優化不僅僅是支持並行處理的區塊鏈的問題；對於支持並行處理的區塊鏈來說，資料庫優化也是一個問題。這是所有需要處理大量交易的高性能區塊鏈所面臨的挑戰。通過這篇文章，我希望讀者能夠更深入地了解 Sei V2，也希望那些設計高性能區塊鏈的人能夠獲得在高性能區塊鏈中設計資料庫的寶貴見解。
1. 區塊鏈存儲的問題：狀態膨脹
1.1 區塊鏈中的狀態是什麼？
在討論存儲問題之前，我們需要先定義一下狀態的含義。區塊鏈背景下的狀態是什麼？狀態是指區塊鏈內所有帳戶的信息，包括帳戶本身、帳戶餘額和合約代碼的詳細信息。因此，當區塊鏈上發生交易時，它不可避免地會影響特定的狀態。例如，如果A將Sei代幣轉移給B，則A和B的餘額都需要更新。這就是國家改變的意義。當狀態發生變化時，會產生什麼影響？通常，我們不認為狀態只是通過改變而增加，但即使是僅僅改變狀態的交易也會在區塊鏈的歷史中留下交易記錄（這種類型的數據稱為歷史狀態））。因此，可以說即使是狀態改變的交易也會稍微增加狀態大小。換句話說，所有鏈上交易都有助於國家的增長。
1.2 快速區塊鏈中的狀態增長問題
正如我之前解釋的，鏈上交易有助於狀態增長。對於像 Sei 這樣的快速區塊鏈來說，它在給定時間內處理更多交易，與其他區塊鏈相比，狀態的增長速度會更快。如果我們進一步添加對事務並行執行的支持，狀態將會增長得更快，從而導致幾個問題：
-
增加節點運行成本：全節點必須存儲整個區塊鏈狀態，這增加了存儲成本並使該區塊鏈上的節點操作變得困難。這可能會導致中心化，因為運行全節點的進入門檻變得更高。
-
區塊鏈性能下降：較大的狀態意味著節點需要更多的時間來處理和驗證交易。每當發生改變區塊鏈狀態的事務時，節點都需要讀取並更新相關的狀態值。隨著狀態的增長，有更多的數據需要訪問，更多的狀態值需要更改。這最終會導致區塊鏈性能變慢。
-
節點同步問題：區塊鏈從根本上涉及多個節點共享帳本並不斷相互同步有效帳本。如果狀態變得太大，新節點的加入就會變得非常困難。新節點必須下載鏈的整個帳本才能參與主網。鏈在特定點拍攝整個記錄的「快照」，新節點使用這些快照進行同步。但是，如果鏈太大，則拍攝快照需要很長時間，並且在此期間，區塊鏈不斷添加新的交易和數據。這種差異可能會使新節點的同步變得困難。同步落後的節點還將面臨大量的時間和成本來追趕，從而導致性能問題並使新節點更難加入，從而可能導致中心化問題。
區塊鏈中狀態變得太大的問題稱為狀態膨脹。如果在沒有資料庫改進的情況下實現事務並行執行，狀態將進一步膨脹，導致上述各種問題。這些問題最終阻礙了事務並行執行所帶來的好處的實現。Sei 從一開始就意識到了這個問題，這種認識的結果就是 Sei DB。那麼，Sei DB在設計上注重了什麼，對資料庫的改進有多大呢？
2. 介紹Sei DB，最快的區塊鏈最快的資料庫
Sei V1 採用了基於不可變 Adelson-Velsky 和 Landis (IAVL) 樹數據結構的普通資料庫結構，Cosmos SDK 使用該結構來存儲狀態。在以太坊中，類似的概念是 Merkle Patricia Trie (MPT)。然而，這種結構在幾個方面被證明是低效的：1) 它需要在每個節點上存儲大量的元數據，2) 維持樹內的平衡需要多次磁碟訪問，減慢內存訪問，3) 它通常會導致存儲更多的元數據。數據超出預期。為了解決這些低效率問題，Sei 推出了 Sei DB，這是一種模塊化資料庫架構，將存儲分為兩層。
為什麼要把資料庫分成兩層？因為國家本身分為歷史狀態和活躍狀態。為了更好地理解 Sei DB，有必要定義這兩種類型的狀態：
-
歷史狀態
歷史狀態是指區塊鏈最新區塊高度之前記錄的所有狀態。換句話說，它包含了區塊鏈的所有過去記錄，不包括當前處理的塊。例如，用戶過去的所有餘額記錄都屬於歷史狀態。
-
活動狀態
活動狀態涉及與最新區塊高度相關的信息。簡單來說，它包括區塊鏈上記錄的最新信息，例如用戶當前的餘額。
即使從這些定義來看，很明顯歷史狀態和活動狀態包含明顯不同的信息，歷史狀態比活動狀態重得多。Sei 旨在通過不同地處理這兩種類型的狀態來優化資料庫。
Sei DB 分為 1）狀態承諾層（SC 層）和 2）狀態存儲層（SS 層）。讓我們研究一下這些層的角色以及它們如何交互。
2.1 狀態承諾層（SC層）
狀態承諾層管理 Sei 區塊鏈的活動狀態。SC 層最關鍵的組件是內存映射 IAVL 樹 (MemIAVL)，它是 Cosmos SDK 中使用的 IAVL 樹的修改版本。由於前面提到的效率低下而進行的修改優化了狀態訪問。但為什麼 MemIAVL 對於狀態訪問如此有效？為了理解這一點，我們需要深入研究 Sei 使用的內存映射的概念。
通常，在處理文件時，使用文件描述符或文件結構指針來訪問它們，這需要通過緩衝區進行輸入和輸出操作。內存映射（mmap()）通過將文件映射到進程的虛擬地址空間來解決這個問題，允許在不使用讀取或寫入函數的情況下讀取或寫入數據。
據 Sei 介紹，MemIAVL 可以在數百納秒內實現狀態訪問，與傳統樹結構相比，寫入速度快 10~287 倍，讀取速度快 10 倍。
（上圖重點關注狀態寫入（提交）而不是狀態讀取。這一結果表明，通過 SeiDB 和異步提交的結合實現了顯著的性能改進。）
為了便於理解，我們概述一下使用 MemIAVL 實現記錄在區塊鏈上的交易的整個生命周期：
-
事務發生，從 MemIAVL 讀取狀態，事務執行將導致狀態更改（也稱為更改集）
-
變更集首先應用於 MemIAVL 樹，然後可以重新計算新的根哈希。
-
新計算的狀態根值包含在塊頭中，標記交易已成功記錄在區塊鏈上。
-
在不同的goroutine中，這些變更集會異步持久化到一個WAL文件中，可以用於恢復（如果需要恢復某個節點，則可以使用最近的快照以及WAL中存儲的信息進行恢復） .)。
這些變化從根本上減少了 CPU 和內存的使用，使 Sei 能夠構建異常快速的區塊鏈，而無需高硬體規格。
2.2 狀態存儲層（SS層）
狀態提交層管理最關鍵的活動狀態，而狀態存儲層處理活動狀態之前的所有記錄，也稱為歷史狀態。Sei V2 的狀態存儲層由三個關鍵組件組成，我們將詳細研究它們：
2.2.1 原始鍵值存儲
任何熟悉區塊鏈的人都會遇到鍵值對的概念。該數據存儲結構使用鍵作為唯一標識符，使用值作為關聯數據。例如，在區塊鏈的背景下，帳戶餘額或合約狀態由鍵表示，而相應的數據（例如帳戶中的代幣數量）是值。
雖然鍵值存儲結構在其他區塊鏈和資料庫中很常見，但 Sei 通過最小化元數據存儲來優化這一點，從而減少存儲的數據量。此外，由於鍵直接映射到值，不需要額外的抽象層，因此數據訪問速度更快，從而提高了區塊鏈的整體效率。
2.2.2 靈活的資料庫後端
資料庫結構的效率與其對各種存儲後端的支持同樣重要。要求節點運營商使用單個存儲後端可能會受到限制，因為這會阻止他們優化後端以滿足其特定需求。Sei V2 支持 PebbleDB、RocksDB 和 SQLite，允許節點選擇最適合其需求的資料庫。下表比較了這三個資料庫的特點：
Sei V2 支持的資料庫的特徵與 Sei 對性能的關注一致。這些資料庫中的每一個都經過優化，可以有效地處理大規模數據，同時最大限度地減少寫入放大（即降低數據寫入磁碟的頻率）。
Sei 表示，PebbleDB 在受支持的資料庫中表現出最佳性能。然而，值得注意的是，這些資料庫都有自己的優點和缺點。詳細的優缺點對比可以參考Sei團隊提供的對比圖。
2.2.3 異步剪枝
最後要討論的組件是異步修剪。在區塊鏈的背景下，修剪是指從區塊鏈中刪除不必要或過時的數據的過程。傳統上，修剪操作會對網絡性能產生負面影響。然而，Sei 異步執行修剪操作，這意味著這些任務在後臺執行，不會影響主要的區塊鏈操作。這種方法允許 Sei 優化歷史狀態數據並減少節點的存儲需求，而不會影響區塊鏈的性能。
綜上所述，Sei V2 的創新資料庫管理方法，包括原始鍵值存儲、靈活的資料庫後端支持和異步剪枝，確保有效處理活動和歷史狀態數據，從而提高區塊鏈的整體性能和可擴展性。
3. Sei DB的實施結果
我們現在已經探索了 SeiDB 的兩層（狀態提交層和狀態存儲層），並研究了每一層的角色和功能。通過這個解釋，我們了解到SeiDB理論上是通過資料庫改進來增強Sei區塊鏈的性能並對其進行優化。然而，最關鍵的還是實際結果。Sei團隊在測試網環境中實現SeiDB時，獲得了以下數據：
1.減少活動狀態大小
測量了內存中存儲的活動狀態的大小，結果顯示活動狀態大小減少了60% 。
2.歷史數據增長率減少
對歷史狀態大小的增長速度進行了評估，發現與之前的資料庫相比慢了90%以上。
3.狀態同步時間減少
測量了節點同步狀態所需的時間，結果顯示速度提高了約1,200% 。
4.塊同步時間減少
測量了從快照點同步塊到最新塊高度所需的時間，顯示速度比之前的資料庫提高了2 倍。
5.塊提交時間減少
測量了將塊提交到區塊鏈所需的時間，結果表明與之前的資料庫相比，速度提高了287 倍。
6.TPS（每秒事務數）
測量了處理事務所需的時間，結果顯示與之前的資料庫相比，速度提高了2 倍以上。
基於這些指標，預計 Sei v2 通過 SeiDB 的實施將表現出顯著的性能改進。儘管被 EVM 兼容性的主要敘述所掩蓋，但 Sei 的長期重大改進很可能在於資料庫級別發生的變化。
4. 展望未來：超越敘述，做出實際貢獻
Sei v2 時代已經到來。在敘事至關重要的市場中，提到 Sei v2 通常會讓人想起「EVM 並行處理」。然而，仔細研究 v2 升級帶來的變化就會發現，技術密集型轉變遠遠超出了 EVM 支持和並行處理改進的範圍。雖然我之前提到的性能指標只是 v2 主網發布之前的測試結果，但實際影響仍有待觀察。儘管如此，這些努力值得持續關注，因為 Sei v2 的實際性能可以激勵其他 Layer 1 區塊鏈對自己的資料庫進行基準測試和增強，從而為「區塊鏈性能改進」這一更廣泛的目標做出重大貢獻。
從一開始，Sei 就一直追求成為「快速區塊鏈」的單一目標，並進行廣泛的研究來實現這一目標。作為一名研究人員，我讚揚他們對實施快速區塊鏈的不懈奉獻。此外，我希望他們的研究能夠繼續發展，帶來更好的資料庫創新，這些創新可能來自 Sei 團隊本身。這些努力共同將使我們能夠構建卓越的區塊鏈，最終使區塊鏈技術更容易被更廣泛的受眾所使用。
