關於執行模型、共識、EVM 基礎與可驗證 AI 的技術長文。每一篇洞察，都讓 Web3 世界變得更清晰。
編輯推薦執行客戶端把 EVM 當作一塊可替換的執行器，中間隔著一層狀態存取介面。go-ethereum 的內建解譯器、evmone 與 revm 定位各不相同，多實作一致性靠規範測試向量保障，解譯器的最佳化空間則集中在分派、gas 計量與記憶體管理上。
閱讀全文 →執行客戶端把 EVM 當作一塊可替換的執行器，中間隔著一層狀態存取介面。go-ethereum 的內建解譯器、evmone 與 revm 定位各不相同，多實作一致性靠規範測試向量保障，解譯器的最佳化空間則集中在分派、gas 計量與記憶體管理上。
狀態變數按宣告順序落在 32 位元組的槽位裡：小類型共用槽位，映射與動態陣列靠雜湊派生位置，繼承順序還會整體平移槽位編號。這些定位規則決定了升級代理為什麼必須繞開編譯器會分配的槽位。
四個呼叫指令在位元組碼裡只差幾個編號，語意卻決定程式碼跑在誰的上下文、寫誰的儲存、msg.sender 與 address(this) 變成什麼。逐個對照 CALL、CALLCODE、DELEGATECALL 與 STATICCALL，可以看清代理為何依賴 DELEGATECALL、STATICCALL 因何引入。
從裸 calldata 出發拆解 ABI：4 位元組 selector 由規範簽章截斷而來，靜態類型直接佔滿一個字，動態類型靠偏移量與長度二級定址；事件把 indexed 參數寫進 topics，換來可檢索性。ABI 不自描述，解碼與升級因此都受約束。
以太坊黃皮書把區塊級狀態轉移寫成巢狀呼叫，求值順序因此屬於規範的一部分。逐筆串列的語意來源、讀寫集衝突為何無法預先判定、確定性與驗證簡單性換來了什麼，以及這個設計原點正在被怎樣的方案正面回應，是接下來的主線。
區塊頭裡的 stateRoot 只有 32 位元組，卻綁定了全網帳戶、餘額與合約儲存。下面拆開 Merkle Patricia Trie 的節點結構與帳戶下掛儲存字典樹的設計，說明 Merkle 證明如何支撐鏈下驗證，以及狀態膨脹的成本落到誰身上。
Gas 是 EVM 的資源計量單位，價格則由費用市場決定；把兩者混為一談，會誤判擴容與執行中止的邊界。下面拆解固有成本與動態成本的構成，說明 out-of-gas 與 REVERT 各退什麼，EIP-1559 的 base fee 與 tip 各歸誰。
同一份 32 位元組資料放在 memory、storage 還是 transient storage，gas 成本能差兩個數量級，生命週期也完全不同。下面沿歸屬、壽命與計價三條線拆開三類儲存，說明重入鎖、臨時陣列與狀態變數各自該放在哪裡。
EVM 是一台沒有暫存器的堆疊機：256 位字長、1024 項堆疊深度、一個只能跳到 JUMPDEST 的程式計數器。取指、解碼、執行這一輪迴圈解釋了堆疊下溢與溢位為何燒光 gas，也解釋了堆疊機相對暫存器機買到了什麼、付出了什麼代價。
把以太坊當成一本記錄轉帳的帳本，會漏掉它最關鍵的部分：帳戶儲存裡可任意讀寫的變數。依據黃皮書的狀態轉移函數 Υ(σ, T)，以太坊是一個分散式狀態機，EVM 是這套狀態轉移的執行規範。全網逐位重放又給執行語意帶來了一組硬約束。
