引介：EVM字節碼的默克爾化
編者按：本文來自Unitimes（ID：Uni-times）編者按：本文來自
摘要：無狀態客戶端需要將區塊中調用的智能合約代碼作為區塊見證的一部分進行發送。合約代碼是導致無狀態區塊帶寬開銷的第二大因素。代碼默克爾化被認為有助於降低該開銷。本文詳細解釋了我們如何將合約代碼分割成塊，默克爾化這些塊（筆者註：指的是讓這些塊組成一棵默克爾樹）並僅傳輸交易執行所必須的塊。根據對最近主網區塊所做的實驗，我們可以發現該方法總計節約了40-60% 的代碼傳輸量。
二級標題
二級標題
無狀態區塊很大
來自github[6]的數據。圖表顯示了50000個近期主網區塊的無狀態區塊見證組成。這些值是以128個塊為窗口的移動平均值。
二級標題
二級標題
為了確切地了解其原理，讓我們想像一個正在部署的新合約。我們掃描合約代碼並識別出基本塊[7]（見算法[8]）（筆者註，基本塊可以理解為按序執行的一段代碼片段）。注意，客戶端僅需為JUMPDEST分析作一次代碼掃描，因此不會引入很高的開銷。這些基本塊有兩個特徵：
圖片描述
圖片描述
圖片描述
一個虛構字節碼的基本塊
每個基本塊要么從索引0開始，要么從JUMPDEST開始。這是為了讓無狀態客戶端能夠安全地進行JUMPDEST分析（稍後將更為詳細地介紹）。
讓我們通過提交調用合約的交易來進行測試。礦工執行交易並標記在執行過程中觸及的塊（在本例中為塊1和塊3）。當發佈區塊時，礦工會納入合約賬戶狀態證明和触及代碼塊的turbo證明[9]。
圖片描述
二級標題
二級標題
實驗
實驗
二級標題
何去何從
何去何從
何去何從
何去何從
你可能仍記得，每個塊的最小長度是一個可配置的參數（上文把其設為128字節）。修改該參數會對塊見證的大小有著兩種相反影響。例如減少至32字節，讓塊的粒度更細，從而減少了需要發送的代碼總量。但同時也增加了trie樹的深度，最終導致證明所需的哈希數增大。下一步將會對最小塊大小的設定進行更徹底的分析，看看是否有一個最為節約空間的值。不管最小塊大小的值，從十六進制trie樹切換為二進制trie 樹會將證明所需的哈希值減少為原來的1/4（見這裡[11]），從而進一步減小塊見證的大小。
對於該原型，我們選擇將代碼分割為一個個基本塊，但也存在著其它各種各樣的分割算法，有些更為簡單，有些更為複雜。最簡單的方法是把代碼分割為固定大小的塊（如每32個字節為一個塊）。目前，該方案的唯一問題圍繞在PUSH 數據和JUMPDEST 分析之上。
原文鏈接：
原文鏈接：
原文鏈接：
參考鏈接：
