作者：Sina Mahmoodi
編譯：Unitimes_David
摘要：無狀態客戶端需要將區塊中調用的智能合約代碼作為區塊見證的一部分進行發送。合約代碼是導致無狀態區塊帶寬開銷的第二大因素。代碼默克爾化被認為有助于降低該開銷。本文詳細解釋了我們如何將合約代碼分割成塊，默克爾化這些塊（筆者注：指的是讓這些塊組成一棵默克爾樹）并僅傳輸交易執行所必須的塊。根據對最近主網區塊所做的實驗，我們可以發現該方法總計節約了 40-60% 的代碼傳輸量。
無狀態區塊很大
雖然未被深入研究過，代碼默克爾化這個想法由來已久，其主要被用于代碼解耦。然而，它最近因不同用途而重獲新生，即減小無狀態客戶端的帶寬需求（如本文[1]）。如果你想知道無狀態客戶端[2]背后的動機是什么，我建議你看看最近這篇概要[3]或者 Alexey Akhunov 的文章[4]（文中發布了其實驗數據）。我不會在本文深入模型細節，但為了完整起見，我提供了相關細節的摘要（如果你熟悉的話，你可以直接跳到下一段）。
在無狀態模型下，（至少有些）節點不需要存儲狀態，并依賴其它節點（如礦工）在區塊中打包所有必要狀態（包括合約代碼）及證明這些狀態有效性的默克爾證明。這意味著和原來相比大得多的網絡帶寬。Alexey Akhunov 與 turbo-geth[5] 團隊一直在做測量歷史主網區塊的區塊見證大小的實驗。下面是最近 50,000 個區塊的測量結果。紅線跟蹤在一個無狀態區塊中需要發送的合約代碼量，其為區塊見證大小的第二大來源。如果以太坊從當前的十六進制 trie 樹遷移到二進制 trie 樹的話，這些見證中的哈希部分將會縮減約3倍，從而使得合約代碼成為見證大小的主要來源。
來自github[6]的數據。圖表顯示了50000個近期主網區塊的無狀態區塊見證組成。這些值是以128個塊為窗口的移動平均值。
無需發送完整代碼
直觀地，我們可以假設一個給定的交易將僅僅觸及其調用合約的部分代碼（如4個函數中的2個）。因此，我們的目標是把代碼分割成塊并在區塊見證中發送給定交易所必須的塊（加上塊有效證明）。如果我們的假設是正確的而且交易確實僅使用了小部分合約字節碼（劇透：早期數據表明情況確實如此），那么區塊見證中的合約代碼部分會顯著減少。
為了確切地了解其原理，讓我們想象一個正在部署的新合約。我們掃描合約代碼并識別出基本塊[7]（見算法[8]）（筆者注，基本塊可以理解為按序執行的一段代碼片段）。注意，客戶端僅需為JUMPDEST分析作一次代碼掃描，因此不會引入很高的開銷。這些基本塊有兩個特征：
一個虛構字節碼的基本塊
每個基本塊要么從索引0開始，要么從JUMPDEST開始。這是為了讓無狀態客戶端能夠安全地進行JUMPDEST分析（稍后將更為詳細地介紹）。
此文由 中國比特幣官網 編輯，未經允許不得轉載?。?a href="http://www.huohuxiazai.com/">首頁 > 比特幣新聞 » 引介 | EVM 字節碼的默克爾化