作者：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 團隊本身。這些努力共同將使我們能夠建立卓越的區塊鏈，最終使區塊鏈技術更容易被更廣泛的受眾所使用。
