Layer1 科普介紹｜用白話文快速搞懂 Sei Network v2 有什麼亮點

專為交易而生的平行處理公鏈 Sei Network 於今年八月發行代幣並啟動主網，引起市場一陣熱潮後，Sei Labs 創辦人 Jayendra Jog 於近日宣布將推出 Sei v2，將整合 EVM、優化平行處理機制與帳本儲存結構。

Sei Network 是什麼？

Sei 為交易而生

Sei Network 有明確的市場定位，提供虛擬資產交易的高效環境，虛擬資產除了常見的代幣之外，也包含 NFT、社交圖譜、遊戲道具，藉由提供專門交易的底層環境打造最佳的用戶體驗。

 

交易不限於加密貨幣，因此虛擬資產的交易是網路世界最廣泛的需求，團隊認為最成功的 Web3 應用程式都涉及交易屬性：

• 間接交易：大多數鏈上用戶藉由使用 Uniswap、OpenSea 進行虛擬資產交易。
• 直接交易：直接受到交易的專案，大多是遊戲或 NFT 專案，例如 Axie Infinity 或是 BAYC。

因此交易的需求從不消失，是未來 Web3 重要的環節，而要完成最佳交易網路的定位，需要提供高效率的環境，而 Sei 利用平行鏈處理設計與共識機制做到此目標。

Sei 平行處理機制

Sei Network 主網現已上線 3 個多月，根據官方資料顯示，目前網路平均可以達到 20,000 的 TPS 與 390 毫秒的最終確認性，目前團隊表示都是業界最有效率的網路，這都有賴於其創新的平行處理機制。

當 Sei 區塊鏈上的交易沒有涉及相同的資源 (地址) 時，可以將把所有交易同時並行處理，而不需要排序交易順序，藉此可以提高網路運作效率。

Sei v2 更新方向

看待一個區塊鏈專案，主要有三個評估重點：帳本結構、共識機制、虛擬機。再加上 Sei 特有的平行處理機制，就可以清楚理解 Sei v2 本次的更新內容有什麼差異。

創辦人 Jayendra 表示 Sei v2 僅是附加新功能，對於現有功能並不會受到影響，用戶與開發者無需為此更新執行任何額外操作。

Sei v2 提案主要包含三項更新：

• 支援 EVM
• 優化平行處理機制
• 優化帳本儲存結構

本次更新預計將於 2024 年第一季完成。

虛擬機：支援 EVM

原有設計：Sei v1 使用 CosmWasm 虛擬機

Sei 是利用 Cosmos SDK 所建構的，並使用後者提供的組件 CosmWasm 虛擬機。CosmWasm 是專為 Cosmos 生態系統打造的虛擬機組件，底層是 WebAssembly (Wasm) 而得名。使用 Cosmos SDK 所建立的區塊鏈都可以將 CosmWasm 添加到其鏈中，而無需調整現有邏輯。

WebAssembly 可以支援多種常見的程式語言，包含 Rust、C、C++等等，因此如果是 Rust 開發人員，則可以在 CosmWasm 上輕鬆編寫智能合約，因此 Sei 吸引的是圈外的開發者。

更新重點：Sei v2 將支援 EVM 整合

不過 Sei Labs 團隊發現雖然開發人員的參與度高，卻失去以太坊虛擬機 (EVM) 生態。EVM 是現有大多產業應用與產品所使用的虛擬機，失去此生態將對於 Sei 現階段的快速發展造成阻礙，例如現有以太坊專案無法分叉到 Sei 生態。

團隊為此更新了專用的代碼庫 Core Sei Binary，導入了 EVM RPC 與 Geth 節點的專用介面，讓 EVM 的交易可以無縫上鏈到 Sei 網路與互動。

選用 Geth 是因為其相對穩定，Jayendra Jog 表示目前有 80% 的以太坊節點使用 Geth，而且支援完整的 EVM 字節碼兼容性，代表開發人員可以完全複製其他 EVM 的合約至其上運行。

Sei v2 還將使用 EVM RPC，讓用戶可以輕鬆使用 Metamask 等錢包操作，而開發人員則可以繼續使用 Foundry、Remix 和 Hardhat 等工具。

因此，Sei v2 將可以讓 EVM 和 Cosmwasm 交易之間的產生可組合性。 Sei 的 Geth 有一個預編譯器，允許調用 Cosmwasm 合約，而 Sei 的 wasmd 模組也能夠反向調用 EVM 合約，將可以讓 Sei 的生態內的資產更有價值。

優化 Sei 平行處理機制

原有設計：Sei v1 合約需定義資源範疇

在原本 Sei Network 為了讓交易可以平行處理，需要開發人員學習如何「標記合約的資源使用」。

開發人員在 Sei 撰寫合約時，需要定義合約可能需要存取的資源與獨立性，以便未來當 Sei 執行合約可以快速分辨資源獨立性，決定是否要並行交易或是排序交易。

為了並行執行合約，開發人員需要識別在執行過程中需要存取的資源 (包含查詢合約)，並將資源範圍寫成 JSON 的格式上鏈，無形中對開發人員造成困擾，並增加進入門檻與安全性問題。

更新重點：Sei v2 簡化合約平行運行機制

Sei v2 將優化並行處理機制，不再需要開發人員手動定義依賴關係，而是能夠自行處理並行化機制，減少了開發人員的負擔。

新的平行處理機制會將所有交易統一執行，若發現資源相衝突的情況，則網路會重新檢視先後順序，並再重新執行。

如果交易涉及不同的帳戶，例如 Alice 轉帳給 Bob，同時 Carol 轉帳給 Dave，那麼由於沒有重疊的依賴關係，本交易將平行處理；如果交易涉及相同的帳戶，例如 Alice 與 Bob 都轉帳給 Carol，那麼需要按順序重新運行。

不過此設計可能有疑慮，若發生最壞的情況，所有交易都涉及相關性而都需要按順序重新運行，重新運行這些交易將比原本就按照順序運行的情況增加 30% 的執行時間。

所幸根據 Ethereum 歷史資料，實際上只會有大約 15% 的交易會有資源重疊而需要按順序重新處理，因此團隊評估後認為 Sei 整體性能仍會顯著提高。

優化帳本儲存結構：SeiDB

原有設計：Sei v1 儲存狀態資料量大

但其實 Sei 還有另外一個問題，會將整個 IAVL 樹永久儲存到分散式帳本中，由於快速的最終性與平行處理設計，需要頻繁紀錄全局的狀態變化，整體的網路帳本大小將會增長的很快。

平行處理的代價是會記錄許多無效的中間狀態資料，根據 Sei 團隊提出的 RFC，以 atlantic-2 測試網節點為例，atlantic-2 節點儲存 25 GB 的資料只有 10 GB 是真正有意義的交易資訊，節點磁碟空間運用效率低。

由於資料膨脹，Sei 節點磁碟使用量成長很快。atlantic-2 歸檔節點硬碟使用量每天增長超過 150 GB，每週超過 1TB。 隨著鏈狀態的不斷增長，儲存空間增長率也會不斷增加 (會越來越快)。

將會導致許多問題：

• 節點的維護成本將變得越來越高
• 資料庫操作會變得越來越慢
• 由於磁碟填滿很快 RPC 節點不能長時間運行

加上未來 v2 來回處理重新驗證的平行處理設計，網路整體狀態改變會更高頻，導致狀態資料量大幅增加。

更新重點：Sei v2 分離帳本結構

Sei v2 為解決上述問題也有優化儲存機制，以防止狀態資料量膨脹，並提高全節點讀取資料速度。

Sei v2 將狀態儲存帳本拆成兩種，稱為 SeiDB：

• 狀態承諾帳本 (State Commitment, SC)：紀錄 MemIAVL 樹資訊
• 狀態儲存帳本 (State Store, SS)：紀錄完整資訊

由於 SeiDB 的改進，驗證節點僅需要紀錄 SC 帳本資訊即可，而完整狀態資訊則交由 SS 層紀錄，且傳輸會先放在預寫日誌中而不需要即時傳輸，這允許狀態儲存非同步發生以提高了效能，因為不會影響區塊生成。

藉由 SeiDB 改良，Sei 性能各方面都有所增加。包含區塊提交時間提升 100 倍、每天產生的資料量從 100 GB 壓縮至 5 GB、全節點或需要同步資訊的節點的追趕時間提升 10 倍。

共識機制

Sei Network v2 並沒有更改其原有的共識機制，仍保持 Twin Turbo 設計。藉由改良 Cosmos 的共識接口 Tendermint ABCI，將區塊確認時間大幅降低。

Sei 藉由取捨進入一線競爭鏈行列

Sei v2 新增了 EVM 虛擬機，並改良了平行處理機制與分散式帳本儲存機制，目的都是為了讓開發者、節點、用戶的使用體驗提升，進而增加生態影響力。

不過也藉由這三個月的營運，發現 Sei 平行交易提高 TPS 與快速的最終確認性，背後的代價是狀態資料量會變大，導致節點所需要的硬體規格上升，團隊做出妥協將帳本結構分開，某方面來說是犧牲去中心化以提升效率的取捨。

整體來說 Sei 相對於其他以太坊殺手，若上述更新可以確實落地，有機會進入一線的競爭鏈行列中，期待看到明年團隊更新的成果。

(本文非投資建議)