以太坊虛擬機

算術操作碼指令包括：

注意，所有算術運算（除非另有說明）都是對 2^256 取模進行的，而零的零次方 0^0 視為 1。

管理堆疊、記憶體與儲存空間的指令包括：

控制流程的指令包括：

與執行程式的系統有關的操作碼包括：

用於比較與位元邏輯的操作碼包括：

處理執行環境資訊的操作碼包括：

存取目前區塊資訊的操作碼包括：

默克爾樹是一種非常古老的資料結構，由 Ralph Merkle 在 1988 年發明，原本是為了打造更好的數位簽章。當你需要驗證某筆資料存在於資料庫中、而且沒有被竄改，又不想為了證明這一點而送出整個資料庫時，默克爾樹非常有效率。

從一組資料建立默克爾樹相當容易。你要先把資料分成好幾個資料塊，接著把這些資料塊合併起來計算雜湊，再以遞迴的方式重複這最後一步，直到只剩下最後一塊為止。這一塊就是默克爾根：可以說是建立這棵樹的所有資料的數位指紋。

讓我們從零開始建立一棵二元默克爾樹（最簡單的默克爾樹形式），讓你更熟悉它。我們從八塊資料開始，你可以把它們想成八個不同的英文單字。我們用特定的雜湊函數計算每一塊資料的雜湊值（如第 4 章所述，以太坊使用 Keccak-256 雜湊函數），得到默克爾樹的葉節點，在圖 14-2 中標示為 hash_1、hash_2 等等。接著，我們把每一對葉節點串接起來，再計算一次雜湊，得到 hash_12、hash_34 等等。我們把串接與計算雜湊的過程再重複兩次，直到得到單一的最終結果，也就是我們的默克爾根：hash_12345678。

你現在可能會問：為什麼需要用默克爾樹來儲存資料？這不是比直接把每一塊資料存進傳統資料庫還複雜嗎？

答案是肯定的，這比把每一塊資料存進鍵值資料庫或 SQL 資料庫複雜得多。我們使用這類資料結構的唯一理由，是它們能非常有效率地提供低成本的密碼學證明，證明某一塊資料確實存在於整個資料集合中，而且沒有被竄改。事實上，如果我們用一般的資料庫儲存資料，而有人要求我們證明自己擁有某一塊特定的資料，我們就得公開整個資料集，讀者才能確定我們沒有說謊。

讓我們用前面的例子實際看看。假設我們想證明 data_1 包含在資料集中。最單純的做法是提供整個資料集，從 data_1 到 data_8，總共八項。如果用默克爾樹，我們只需要提供 hash_2、hash_34 與 hash_5678。這樣一來，任何人都能自己算出默克爾根，再與我們一開始算出的（公開分享的）默克爾根比較。如果兩者相符，你就能完全確定 data_1 屬於最初的資料集，如圖 14-3 所示。

注意，我們只用了三項資料；如果不用默克爾樹、採取最單純的做法，就需要八項。而這只是個玩具範例——資料量很大時，節省的幅度會大得多。

用數學的說法，默克爾樹的複雜度是 O(log(n))，而單純做法則是線性的 O(n)，如圖 14-4 所示。

在以太坊的世界裡，這表示要證明某個地址的餘額、某筆交易的結果，或某個智能合約的位元組碼，都更便宜、更容易。

比特幣率先在區塊鏈技術中使用默克爾樹。事實上，每個比特幣區塊都包含該區塊中所有交易的默克爾根，因此任何一筆交易都無法在不修改整個區塊頭的情況下被修改，而修改區塊頭也會讓工作量證明（PoW）失效。

以太坊採用了同樣的概念，並針對自身的特定需求做了一些修改。默克爾樹非常適合永遠不會改變的永久資料，例如比特幣的交易。然而，以太坊狀態不斷在變，因此我們需要調整默克爾樹，讓它在保有原本那些實用特性的同時，也能讓底層的資料頻繁變動。

這時就輪到默克爾帕特里夏前綴樹登場了。這個名字結合了默克爾樹、Patricia（Practical Algorithm to Retrieve Information Coded in Alphanumeric，擷取以英數字編碼之資訊的實用演算法），以及源自 retrieval（擷取）一詞的前綴樹（trie），提醒我們它是為了什麼而最佳化的。

本質上，默克爾帕特里夏前綴樹是每個節點有 16 個子節點的修改版默克爾樹。它們很適合以太坊狀態這類有大量鍵值項目的資料（鍵是地址，值是每個地址的帳戶資訊，例如餘額、nonce，以及程式碼（如果有的話）），因為鍵本身就編碼在你要抵達樹中正確位置所必須走的路徑上。

假設我們要儲存以下這個鍵值項目：

car 的十六進位編碼是 (0x) 6 3 6 1 7 2，因此你要從默克爾根開始走到第 6 個子節點，再往下走到第 3 個子節點，一直重複這個過程，直到抵達最終的值，讀出與這個鍵對應的值（在這個例子中是 Schumacher），如圖 14-5 所示。

具體來說，以太坊使用四棵默克爾帕特里夏前綴樹：

狀態前綴樹

儲存整個狀態

交易前綴樹

儲存區塊中包含的所有交易

收據前綴樹

儲存區塊中包含的所有交易的結果

儲存前綴樹

儲存智能合約的資料

每個以太坊區塊頭都包含狀態前綴樹、交易前綴樹與收據前綴樹的默克爾根，而每個帳戶（包含在狀態前綴樹中）則儲存自己的儲存前綴樹的默克爾根。

堆疊是一種非常簡單的資料結構，依照後進先出（last in, first out，LIFO）的順序進行操作，其中每個項目都是 32 位元組的物件。它最多可以同時容納 1,024 個項目。

EVM 可以透過不同種類的操作碼，把項目推入堆疊或從堆疊彈出，也可以調整堆疊中元素的順序，如圖 14-6 所示。

EVM 記憶體是一種以位元組為單位定址的資料結構：本質上就是一個非常長的位元組陣列。事實上，記憶體中的每個位元組都可以用 32 位元組（256 位元）的鍵來存取，這表示它最多可以容納 2^256 個位元組。它是揮發性的（也就是在執行結束後就會被刪除），而且一律初始化為 0。

雖然可以對記憶體讀寫單一位元組，但大多數操作都需要讀寫更大塊的資料，通常是 32 位元組一塊，如圖 14-7 所示。

EVM 儲存空間是一種鍵值資料結構，其中的鍵（通常稱為 slot）與值都是 32 位元組長。這是每個智能合約的持久記憶：存在裡面的所有值，都會跨越不同的交易與區塊無限期地保留下來。每個智能合約都只能存取與修改自己的儲存空間；如果你存取一個沒有任何值的 slot，它一律會回傳 0，而不會丟出任何錯誤。圖 14-8 非常簡略地呈現了兩個合約的儲存空間。

另外還有隨 EIP-1153 加入的暫時儲存空間，它的行為和一般的儲存空間相同，唯一的差別是交易執行結束後就會被完全丟棄。因此，它的使用成本比一般儲存空間便宜得多。

calldata 是一種不可變更的資料結構，內容一律是送給下一個呼叫框架（也就是一個沙盒化的 EVM 環境）作為輸入的位元組。例如，在建立合約的交易中，calldata 包含即將部署的合約的位元組碼。calldata 也可以是空的，例如單純的 ETH 轉帳。

CREATE 與 CREATE2 是僅有的兩個能在鏈上部署新合約的操作碼。兩者的主要差別在於新建立合約的地址。使用 CREATE 時，目的地址的計算方式如下：

也就是把發送者地址及其後的 nonce 做 RLP 編碼，計算 Keccak-256 雜湊，取最右邊的 20 個位元組。

CREATE2 是在 2019 年的 Constantinople 硬分叉中加入的，讓開發者建立新合約時，產生的地址不取決於發送者的狀態（也就是 nonce）。事實上，它的行為和 CREATE 操作碼完全相同，只是目的地址改用以下方式計算：

其中：

首先，你要確認電腦上已經安裝了 Rust。如果還沒有，請執行以下指令：

然後依序執行以下兩個指令：

現在，Heimdall 應該已經正確安裝了。你可以執行以下指令確認：

你應該會看到類似這樣的輸出：

既然已經正確安裝了 Heimdall，我們就可以產生你在圖 14-21 看到的那張圖了。從 Faucet.sol 合約的執行期位元組碼開始，你可以執行以下指令：

以下是這個指令實際的樣子：

現在，你應該會看到一個名為 output 的新資料夾。進入這個資料夾，再進入產生出來的 local 資料夾，應該就能找到 cfg.dot 檔案：

因為這是 .dot 檔案，需要特別的程式才能正確開啟。在這個例子中，我們會使用一個網站，只要貼上 .dot 檔案的內容，它就會幫我們產生圖形。

首先，你要複製 .dot 檔案的內容：

這個指令會把檔案的完整內容印在螢幕上。把它複製下來，打開一個控制流程圖（control flow graph，CFG）線上產生器，貼到網頁的左側，如圖 14-22 所示。

圖 14-23 是 Faucet.sol 合約一開頭的位元組碼。如你所見，它的開頭和前面的 Example.sol 合約是同樣的模式：PUSH1 0x80 PUSH1 0x40 MSTORE。

當你送一筆交易給與 ABI 相容的智能合約（你可以假設所有合約都是）時，這筆交易會先和該智能合約的分派器互動。分派器會讀取交易的 data 欄位，把相關的部分送到對應的函式。在反組譯後的 Faucet.sol 執行期位元組碼開頭，就可以看到一個分派器的例子。在熟悉的 MSTORE 指令之後，我們看到以下指令：

如前所述，PUSH1 0x04 把 0x04 放到堆疊頂端，此時堆疊上沒有其他東西。CALLDATASIZE 取得隨交易送來的資料（也就是 calldata）的大小（以位元組計），並把這個數字推入堆疊。執行完這些操作後，堆疊會像這樣：

下一個指令是 LT，是「less than」（小於）的縮寫。LT 指令會檢查堆疊頂端的項目是否小於堆疊上的下一個項目。在我們的例子中，它檢查的是 CALLDATASIZE 的結果是否小於 4 個位元組。

EVM 為什麼要檢查交易的 calldata 至少有 4 個位元組？這和函式識別碼的運作方式有關。每個 Solidity 函式都以它的 Keccak-256 雜湊值的前 4 個位元組來識別。把函式名稱與它接受的所有引數放進 keccak256 雜湊函數，就能推算出它的函式識別碼。在我們的例子中：

因此，withdraw(uint256,address) 函式的函式識別碼是 0x00f714ce，因為這是雜湊結果的前 4 個位元組。函式識別碼一律是 4 個位元組長，所以如果送給合約的交易，整個 data 欄位不到 4 個位元組，那麼除非定義了 fallback 函式，否則這筆交易不可能是在和任何函式溝通。因為我們在 Faucet.sol 中實作了 fallback 函式，所以當 calldata 的長度小於 4 個位元組時，EVM 就會跳到這個函式。

LT 從堆疊彈出最上面的兩個值；如果交易的 data 欄位小於 4 個位元組，就把 1 推入堆疊，否則推入 0。在我們的例子中，假設送給合約的交易，data 欄位小於 4 個位元組。

PUSH2 0x0020 指令把位元組 0x0020 推入堆疊。執行這個指令後，堆疊會像這樣：

下一個指令是 JUMPI，代表「jump if」（條件成立就跳躍）。它的運作方式如下：

在我們的例子中，label 是 0x0020，也就是 fallback 函式在智能合約中的位置。cond 引數是 1，也就是前面 LT 指令的結果。把這整串指令用文字說明，就是：如果交易資料小於 4 個位元組，合約就跳到 fallback 函式。

在 0x20 處，兩個 JUMPDEST 指令之後就只剩一個 STOP 指令，因為我們雖然宣告了 fallback 函式，卻讓它保持空白。如圖 14-24 所示，如果我們沒有實作 fallback 函式，合約就會改成丟出例外。

讓我們來看看分派器的核心區塊。假設收到的 calldata 長度大於 4 個位元組，JUMPI 指令就不會跳到 fallback 函式，而是繼續執行以下指令：

PUSH0 把 0 推入堆疊，此時堆疊上又沒有其他東西了。CALLDATALOAD 接受一個引數，也就是送給智能合約的 calldata 中的某個索引，並從該索引開始讀取 32 個位元組，如下所示：

因為 PUSH0 指令傳給它的索引是 0，CALLDATALOAD 會從第 0 個位元組開始讀取 32 個位元組的 calldata，然後（在彈出原本的 0x0 之後）把它推到堆疊頂端。執行 PUSH1 0xe0 指令後，堆疊會變成：

SHR 把堆疊上那個 32 位元組的值，邏輯右移 0xe0 個位元（224 個位元，即 28 個位元組）。把 calldata 右移 28 個位元組，就能單獨取出 calldata 的前 4 個位元組。事實上，向右位移時，被移出最右端的所有位元都會被丟棄，左邊補進來的新位元則設為 0。記住，calldata 的前 4 個位元組，代表我們想要觸發的函式的函式識別碼。

用一個例子會更容易理解。假設堆疊是：

我們只想取得前兩個位元組（也就是 0x1234）。只用 EVM 操作碼的話，可以這樣做：

事實上，把堆疊上的項目向右位移 3 個位元組（記住，這裡每個位元組用 2 個十六進位數字表示），就會得到以下項目：

4567890 的部分被丟棄，剩下的只有：

所有前導零都不影響數值，可以忽略。

新的堆疊是：

下一個指令是 DUP1，它會複製堆疊中的第一個項目。現在堆疊變成：

接著是一個 PUSH3 指令，後面跟著推入資料（push data）0xf714ce。這個操作碼只是把這段推入資料推入堆疊。執行這個操作碼後，堆疊會像這樣：

現在，0xf714ce 看起來眼熟嗎？還記得 withdraw(uint256,address) 函式的函式識別碼是什麼嗎？就是 0x00f714ce……注意，因為前導零可以忽略，所以它們是同一個數字。

下一個指令 EQ 會從堆疊彈出最上面的兩個項目並加以比較。分派器的主要工作就在這裡：它比較交易的 msg.data 欄位中送來的函式識別碼，是否與 withdraw(uint256,address) 的函式識別碼相符。如果相等，EQ 就把 1 推入堆疊，最後會用來跳到 withdraw 函式；否則，EQ 會把 0 推入堆疊。

假設送給合約的交易確實是以 withdraw(uint256,address) 的函式識別碼開頭，我們的堆疊就會變成：

接下來是 PUSH2 0x23，0x23 就是 withdraw(uint256,address) 函式在合約中的位置。執行這個指令後，堆疊會像這樣：

接著是 JUMPI 指令，它同樣以堆疊最上面的兩個元素作為引數。在這個例子中是 JUMPI(0x23, 1)，告訴 EVM 跳到 withdraw(uint256,address) 函式的位置，接著就可以繼續執行該函式的程式碼。

gas 是以太坊用來衡量在以太坊區塊鏈上執行動作所需的計算與儲存資源的單位。比特幣的交易手續費只考慮交易的大小（以 KB 計）；以太坊則不同，必須計算交易與智能合約程式碼執行時所進行的每一個計算步驟。

交易或合約執行的每個操作，都要花費固定數量的 gas。以太坊「黃皮書」中的一些例子包括：

gas 是以太坊的關鍵組成部分，扮演雙重角色：一是作為（波動劇烈的）以太幣價格與驗證者工作報酬之間的緩衝，二是用來防禦阻斷服務（DoS）攻擊。為了防止網路中出現意外或惡意的無窮迴圈或其他計算浪費，每筆交易的發起者都必須為自己願意付費的計算量設定上限。gas 系統因此讓攻擊者失去發送「垃圾」交易的誘因，因為他們必須為自己消耗的計算、頻寬與儲存資源按比例付費。

當需要 EVM 來完成一筆交易時，一開始會分配給它等同於交易中 gas 上限所指定數量的可用 gas。每個被執行的操作碼都有 gas 成本，因此 EVM 在逐步執行程式的過程中，可用 gas 會越來越少。在每個操作之前，EVM 都會檢查是否有足夠的 gas 支付這個操作的執行。如果 gas 不夠，執行就會停止，交易也會被回復。

如果 EVM 順利執行到最後、沒有耗盡 gas，所用掉的 gas 成本就會依照交易中指定的 gas 價格換算成以太幣，作為交易手續費支付給驗證者：

可用 gas 中剩下的 gas 會退還給發送者，同樣依照交易中指定的 gas 價格換算成以太幣：

如果交易在執行期間「gas 耗盡」，操作就會立即終止，並引發 OOG 例外。交易會被回復，對狀態的所有變更也都會被撤銷。雖然交易沒有成功，發送者仍然要支付交易手續費，因為驗證者已經完成了到那一刻為止的計算工作，必須獲得補償。

區塊 gas 上限是一個區塊中所有交易總共可以消耗的最大 gas 數量。它限制了一個區塊能容納多少筆交易。

例如，假設我們有五筆交易，gas 上限分別設為 30,000、30,000、40,000、50,000 與 50,000。如果區塊 gas 上限是 180,000，那麼其中任意四筆交易都能放進一個區塊，而第五筆就必須等待之後的區塊。如前所述，由驗證者決定要把哪些交易放進區塊。不同的驗證者很可能會選擇不同的組合，主要是因為它們從網路接收到交易的順序不同。

如果驗證者試圖放進一筆所需 gas 超過目前區塊 gas 上限的交易，該區塊就會被網路拒絕。大多數以太坊客戶端會發出類似「transaction exceeds block gas limit」（交易超過區塊 gas 上限）的警告，阻止你發出這樣的交易。根據 Etherscan 的資料，在本書撰寫時（2025 年 6 月），以太坊主網的區塊 gas 上限是 3,600 萬 gas，這表示一個區塊大約可以容納 1,428 筆基本交易（也就是 ETH 轉帳，每筆消耗 21,000 gas）。^[40]

舊版 EVM 在合約建立時，不會驗證發布到鏈上的位元組碼。一方面，這看起來似乎不錯，因為你想發布什麼合約都可以：你可以部署包含不存在的操作碼的位元組碼、加入永遠不會執行到的程式碼，或是在 PUSH 操作的中間截斷，不提供它正確執行所必需的下一個立即值。但這其實帶來了許多低效率。事實上，EVM 必須在執行期檢查一切，這增加了複雜度，也拖慢了整體效能。以下是一個在 EVM 位元組碼中包含不存在的操作碼的例子：

以下是把這段位元組碼轉換成人類可讀的操作碼：

操作碼 0C 並不存在，當 EVM 執行到那裡時，就會發生 panic 並提早返回。注意，前面這段位元組碼的第二個位元組也是 0C，但 EVM 並沒有在那裡失敗。差別在於，最後那個 0C 位元組被解讀為操作碼，因為無效而失敗；另一個則因為是第一個 PUSH1 操作碼的立即值，而被解讀為推入資料。

這種執行期檢查的一個關鍵部分，就是 JUMPDEST 分析。每次執行合約時，每個客戶端都需要在執行期進行這項分析。讓我們花點時間了解 JUMPDEST 分析，以及舊版 EVM 為什麼需要它。

舊版 EVM 只有動態跳躍（JUMP 與 JUMPI 操作碼）可以管理位元組碼的控制流程。這非常方便，因為只要兩個操作碼，就能改變一般的操作流程。缺點是動態跳躍非常昂貴，需要在執行期進行深入的驗證，即使大多數時候，跳躍根本不需要是動態的。事實上，要跳躍的目標值，往往就是在 JUMP 操作碼的前一個指令才推入堆疊的。以下是一個小例子：

轉換成人類可讀的操作碼如下：

如你所見，跳躍目的地（也就是要跳到的偏移量 0x09）只是在 JUMP 操作碼的前一個指令，透過 PUSH1 操作碼推入堆疊而已。EVM 把 0x09 推入堆疊，接著執行 JUMP 操作碼；這個操作碼以先前推入的 0x09 作為輸入，把執行移到該偏移量的指令。在 0x09 處有一個 JUMPDEST 操作碼，因此它被視為有效的跳躍目的地，執行可以正確地繼續下去。

為了避免跳到無效的目的地，必須在執行期進行驗證。有效的目的地只有不屬於推入資料的 JUMPDEST 指令。這一點非常重要：舊版 EVM 並沒有把程式碼與資料適當地分開。因此，每當你在某段位元組碼中遇到 0x5b 這個位元組（也就是 JUMPDEST 操作碼），如果不把整個合約分析一遍，就無法完全確定它是真正的 JUMPDEST 操作碼，還是推入資料的一部分。

看看以下這個呈現這種細微差異的例子：

這兩段位元組碼看起來幾乎一模一樣；事實上，它們只差了一個位元。^[41]但這就足以讓結果天差地遠。第一段位元組碼和前一個例子中的相同。第二段以人類可讀的格式表示如下：

如果你試著執行第二段程式碼，它會因為無效的跳躍目的地而失敗。這看起來可能有點奇怪，因為在偏移量 0x09 處仍然是代表 JUMPDEST 操作碼的 0x5b 位元組。問題在於，在這個例子中，0x5b 位元組是推入資料的一部分，因此不能視為有效的跳躍目的地。這就是執行在那裡失敗的原因。

JUMPDEST 分析是分析合約、找出哪些跳躍目的地有效、哪些無效的過程，讓 EVM 執行合約時能偵測到無效的跳躍目的地並 panic。

假設你送出一筆與合約 A 互動的交易。EVM 載入合約 A 時，會立刻進行 JUMPDEST 分析，把有效跳躍目的地的對照表存起來，然後才開始真正執行這筆交易：

以人類可讀的格式表示如下：

EVM 會快速掃過整段位元組碼，建立一份對照表，把每個 0x5b 位元組標記為有效或無效的跳躍目的地，如圖 14-26 所示。

新增或棄用一個操作碼或某項功能，並不像看起來那麼容易。雖然確實已經新增過不少操作碼，例如 BLOBHASH、BLOBBASEFEE、BASEFEE 等等，但由於 EVM 的位元組碼沒有結構、也沒有經過驗證，這件事總是很複雜。

看看以下這個例子，其中包含一個無效的操作碼，也就是 0x0C。假設這是一個實際部署在以太坊主網上的合約：

以人類可讀的格式表示如下：

如果你試著在 EVM 中執行這一小段位元組碼，會看到執行到那個不存在的操作碼時就失敗了。

假設未來某次升級新增了一個操作碼 MAX，它從堆疊取出兩個項目，回傳其中值較大的那一個，分配給它的位元組是 0x0C。再看一次前面的位元組碼（記住，我們假設它是部署在主網上的真實合約）：

現在，這段位元組碼的結果完全不同了。事實上，它不再失敗，而是順利返回。如果有其他合約依賴「這個合約因為（以前）不存在的操作碼而一定會失敗」這個假設，就可能出問題。

棄用功能更困難，因為 EVM 沒有版本系統可以依靠。所以，如果你移除某個操作碼或改變它的運作方式，原本使用它的舊合約就可能壞掉，而除了人工介入（建立新合約）之外，沒有任何辦法可以修復。

EIP-2929 改變存取狀態的操作碼的 gas 計量方式時，有些合約因為把要使用或預期的 gas 數量寫死在程式碼中而壞掉了。讓它們恢復運作的解決辦法，是引進存取清單：你可以預先載入已知交易會用到的一些帳戶與儲存 slot，藉此降低 gas 成本。

舊版 EVM 讓升級更困難的其他重要因素，還有程式碼自省與 gas 可觀測性（gas observability）。gas 可觀測性來自 GAS 這類操作碼，甚至所有以 gas 作為輸入的 *CALL 操作碼；程式碼自省則是透過 CODESIZE、CODECOPY、EXTCODESIZE、EXTCODECOPY 與 EXTCODEHASH 等操作碼達成的。

問題在於，如果 EVM 能在執行的某個時間點取得剩餘的 gas，智能合約的邏輯就可能依賴這個值。而如果未來某些操作碼的 gas 計量方式改變了（這種事並不罕見），所有依賴舊 gas 計量方式的智能合約都可能出問題。程式碼自省也是同樣的道理。

舊版 EVM 不會對發布到鏈上的位元組碼強加任何結構。真正的程式碼和程式碼中使用的資料之間沒有區別。一切都只是位元組，由 EVM 在執行期間逐步解讀。

不看整個合約，就無法斷定位元組碼的某個部分是程式碼還是資料。看看以下這個例子：

不深入研究程式碼，你無法馬上看出 0102030405060708090a0b0c0d0e0f1011121314 不應該被解讀成一連串的操作碼（0x01：ADD、0x02：MUL，依此類推），而是代表一個固定地址的推入資料，我們想查詢這個地址的餘額。這對靜態分析工具與形式化驗證都很不利，也讓智能合約更難直接在鏈上正確處理可執行的程式碼。

接下來，我們要看看 EVM 最讓人討厭的限制之一：「stack too deep」錯誤。如果你試著編譯以下這個智能合約，馬上就會遇到它：

以下是試著編譯這個合約時的輸出：

這個錯誤相當隱晦，因為它是 EVM 運作方式的直接結果。事實上，雖然可以推入堆疊的項目最多有 1,024 個，但 EVM 只能透過 DUP1..16 與 SWAP1..16 這類操作碼，輕鬆存取其中最上面的 16 個元素。

在我們的 StackTooDeep 例子中，add 函式接受九個不同的參數，每個參數都必須放到堆疊上。接著，它要進行八次加法才能得到最終結果。問題就出在這些細節上。雖然最後的運算看起來像是一次大的加法，但實際上，編譯器必須把每一次加法拆開，並建立一個暫存變數來保存需要存進堆疊的中間結果。所以最後我們會有九個參數加上八個中間結果，總共需要 17 個堆疊項目。當編譯器試圖引用堆疊中第 17 個或更深位置的變數時，就會失敗，因為它沒有任何能輕鬆存取那個位置的操作碼。

為了更清楚地呈現這個問題，你可以看看圖 14-27，圖中詳細列出了每一步的堆疊組成。你很容易就能看出，執行到最後時，變數 i 位於深度 17 的位置。編譯器不允許區域變數或參數在函式的作用域中無法輕鬆存取，因此會丟出「stack too deep」錯誤。

這只是一個非常簡單的例子，呈現了智能合約開發者在日常工作中必須克服的問題之一。雖然編譯器在自動分析與處理這類情況方面已經越來越進步，但 EVM 目前的運作方式仍然帶來了一些硬性的限制。

EOF 引進了一種在部署時驗證的 EVM 位元組碼容器格式、一套版本系統，以及程式碼與資料的完全分離，藉此解決上述所有問題。以下是一段有效的 EOF 位元組碼範例：

轉換成人類可讀的格式如下：

先別急，接下來幾節會解釋所有內容。