📢 Gate廣場 #MBG任务挑战# 發帖贏大獎活動火熱開啓!
想要瓜分1,000枚MBG?現在就來參與,展示你的洞察與實操,成爲MBG推廣達人!
💰️ 本期將評選出20位優質發帖用戶,每人可輕鬆獲得50枚MBG!
如何參與:
1️⃣ 調研MBG項目
對MBG的基本面、社區治理、發展目標、代幣經濟模型等方面進行研究,分享你對項目的深度研究。
2️⃣ 參與並分享真實體驗
參與MBG相關活動(包括CandyDrop、Launchpool或現貨交易),並曬出你的參與截圖、收益圖或實用教程。可以是收益展示、簡明易懂的新手攻略、小竅門,也可以是現貨行情點位分析,內容詳實優先。
3️⃣ 鼓勵帶新互動
如果你的帖子吸引到他人參與活動,或者有好友評論“已參與/已交易”,將大幅提升你的獲獎概率!
MBG熱門活動(帖文需附下列活動連結):
Gate第287期Launchpool:MBG — 質押ETH、MBG即可免費瓜分112,500 MBG,每小時領取獎勵!參與攻略見公告:https://www.gate.com/announcements/article/46230
Gate CandyDrop第55期:CandyDrop x MBG — 通過首次交易、交易MBG、邀請好友註冊交易即可分187,500 MBG!參與攻略見公告:https://www.gate.com/announcements
EVM並行化優化:以Reddio爲例提升交易處理效率
EVM的並行優化之路
衆所周知,EVM是以太坊的核心執行引擎和智能合約運行環境。作爲一個包含大量節點的開放網路,公鏈面臨着如何在硬件參數差異巨大的設備上實現一致性執行的挑戰。虛擬機技術爲解決這一問題提供了可能,使智能合約能夠在不同操作系統和設備上以相同方式運行,確保結果的一致性。
智能合約在上鏈前會被編譯爲EVM字節碼。EVM執行合約時按順序讀取這些字節碼,每條指令都有相應的Gas成本。EVM會追蹤每條指令執行過程中的Gas消耗,消耗量取決於操作的復雜度。
傳統上,EVM採用串行方式處理交易,所有交易在單一隊列中排隊並按確定順序執行。這種設計簡單易維護,但隨着區塊鏈技術的發展和用戶羣的擴大,對TPS和吞吐量的要求不斷提高。在Rollup技術成熟後,EVM串行執行的性能瓶頸在以太坊二層網路中變得尤爲明顯。
Sequencer作爲Layer2的關鍵組件,以單個服務器形式承擔所有計算任務。如果配套模塊效率足夠高,最終瓶頸將取決於Sequencer本身的效率,此時串行執行將成爲重大障礙。因此,交易處理的並行化成爲未來的必然趨勢。
以太坊交易執行的核心組件
除EVM外,go-ethereum中與交易執行相關的另一核心組件是stateDB,用於管理以太坊中的帳戶狀態和數據存儲。以太坊使用Merkle Patricia Trie樹狀結構作爲數據庫索引。每次交易執行都會改變stateDB中的某些數據,這些變更最終反映在全局狀態樹中。
stateDB負責維護所有以太坊帳戶的狀態,包括EOA帳戶和合約帳戶,存儲帳戶餘額、智能合約代碼等數據。交易執行過程中,stateDB對相應帳戶數據進行讀寫。交易執行結束後,stateDB將新狀態提交到底層數據庫中進行持久化。
總的來說,EVM負責解釋和執行智能合約指令,根據計算結果變更區塊鏈狀態,而stateDB作爲全局狀態存儲,管理所有帳戶和合約的狀態變化。兩者協作構建了以太坊的交易執行環境。
串行執行的具體過程
以太坊的交易分爲EOA轉帳和合約交易兩種類型。EOA轉帳是最簡單的交易類型,即普通帳戶間的ETH轉帳,不涉及合約調用,處理速度快,gas費低。
合約交易涉及智能合約的調用與執行。EVM處理合約交易時,需逐條解釋和執行智能合約中的字節碼指令。合約邏輯越復雜,涉及的指令越多,消耗的資源也越多。
例如,ERC-20轉帳的處理時間約爲EOA轉帳的2倍,而更復雜的智能合約,如Uniswap上的交易操作,耗時可能是EOA轉帳的十幾倍。這是因爲DeFi協議在交易時需要處理流動性池、價格計算、代幣swap等復雜邏輯,需要進行大量計算。
在串行執行模式下,EVM與stateDB的協作過程如下:
這種串行執行模式的瓶頸明顯:交易必須按順序排隊執行,如遇到耗時較長的智能合約交易,其他交易只能等待,無法充分利用硬件資源,效率受到較大限制。
EVM的多線程並行優化方案
並行執行模式可以開啓多個線程同時處理多筆交易,效率可提升數倍,但面臨狀態衝突問題。當多筆交易同時聲明要改寫某個帳戶的數據時,就會產生衝突,需要進行協調處理。
並行優化原理
以ZKRollup項目Reddio的並行優化思路爲例,其主要特點包括:
多線程並行執行交易:設置多個線程同時處理不同交易,線程間互不幹擾,可數倍提升交易處理速度。
爲每個線程分配臨時狀態數據庫:每個線程都有獨立的臨時狀態數據庫(pending-stateDB)。交易執行時,狀態變化結果暫時記錄在pending-stateDB中,不直接修改全局stateDB。
同步狀態變更:區塊內所有交易執行完畢後,將每個pending-stateDB中記錄的狀態變更結果依次同步到全局stateDB中。
Reddio對讀寫操作的處理進行了優化:
讀操作:首先檢查Pending-state的ReadSet。如存在所需數據,直接從pending-stateDB中讀取;否則從上一個區塊對應的全局stateDB中讀取歷史狀態數據。
寫操作:所有寫操作先記錄到Pending-state的WriteSet中,待交易執行完成後,通過衝突檢測再嘗試將狀態變更結果合並到全局stateDB中。
爲解決狀態衝突問題,Reddio引入了衝突檢測機制:
衝突檢測:監測不同交易的ReadSet和WriteSet,如發現多個交易嘗試讀寫相同狀態項,視爲發生衝突。
衝突處理:衝突交易被標記爲需要重新執行。
所有交易執行完成後,多個pending-stateDB中的變更記錄合並到全局stateDB中。合並成功後,最終狀態提交到全局狀態樹中,生成新的狀態根。
多線程並行優化顯著提升了性能,特別是在處理復雜智能合約交易時。研究顯示,在低衝突工作負載中,基準測試的TPS比傳統串行執行提升了3~5倍。在高衝突工作負載中,理論上如果採用所有優化手段,甚至可達到60倍提升。
總結
Reddio的EVM多線程並行優化方案通過爲每個交易分配臨時狀態庫,並在不同線程中並行執行交易,顯著提高了EVM的交易處理能力。通過優化讀寫操作和引入衝突檢測機制,EVM系公鏈能在保證狀態一致性的前提下實現交易的大規模並行化,解決了傳統串行執行模式的性能瓶頸。這爲以太坊Rollup的未來發展奠定了重要基礎。
後續可進一步探討Reddio的實現細節,包括如何進一步優化存儲效率,高衝突情況下的優化方案,以及如何借助GPU進行優化等內容。