以此為基礎進行展開：如果我們在任意邊界分割字節碼，PUSH操作碼及未來引入的其它多字節操作碼的操作數可能會被接收到塊的客戶端誤以為是JUMPDEST(0x5b)。如下所示，一個擁有完整代碼的客戶端可以得知JUMP是無效的（由于0x5b是PUSH1的一個操作數）并停止執行。然而，一個接收到塊6和塊8但沒有接收塊7的客戶端將跳轉到位置41，從而以不同的方式對合約進行解析。我們將在后文簡要地提及能夠避免該問題并支持任意邊界的方案。
為了解決這個問題，Martin Holst Swende 建議在每個塊上添加一個元數據，指定頭部的多少個字節為PUSH的操作數。然后，驗證程序可以在進行 JUMPDEST 分析期間跳過這些字節。Alexey正探索的另一條路徑為禁止EVM中的動態跳轉（至少對于希望默克爾化代碼的合約而言），讓我們能在部署時一次過靜態地對跳轉進行分析而不是在每次代碼執行期間。Alex Beregszaszi 提出使用合約控制流圖能夠更好地指引默克爾化。同時，Christian Reitweissner 提出一個執行證明方案，其中默克爾化 DAG 是由合約的控制流圖所創建。我不能客觀地評價他在這篇文章中的思路，同時希望他能夠在未來進行更多的說明。
結果或許會表明不同的分割算法在效率上僅有微不足道的提升。在這種情況下，最簡單的算法將成為最明智的選擇。好消息是，我們至少有一個在早期數據上似乎可以顯著地減少無狀態區塊中傳輸代碼量的算法。
本文特地對 EVM 字節碼的默克爾化進行了討論，但其總體思路并不局限于 EVM。事實上，其它 EWASM 團隊正同時對默克爾化 WASM 代碼進行實驗，其面臨著自身的一系列挑戰。這主要是因為 WASM 代碼由多個部分組成并在執行前有著嚴格的校驗，這意味著重構的字節碼必須通過校驗。請持續關注這方面的進展。
致謝：非常感謝 EWASM 團隊的 Guillaume Ballet，Alex Beregszaszi 和 Casey Detrio 對本文的審閱和反饋。
原文鏈接：
https://medium.com/ewasm/evm-bytecode-merklization-2a8366ab0c90
參考鏈接：
[1]https://ethereum-magicians.org/t/protocol-changes-to-bound-witness-size/3885
[2]https://ethresear.ch/t/the-stateless-client-concept/172
[3]https://blog.ethereum.org/2019/12/30/eth1x-files-state-of-stateless-ethereum/
[4]https://medium.com/@akhounov/data-from-the-ethereum-stateless-prototype-8c69479c8abc
[5]https://github.com/ledgerwatch/turbo-geth
[6]https://github.com/mandrigin/ethereum-mainnet-bin-tries-data
[7]https://en.wikipedia.org/wiki/Basic_block
[8]https://github.com/ethereum/evmone/blob/master/docs/efficient_gas_calculation_algorithm.md#basic-instruction-blocks
[9]https://github.com/ledgerwatch/turbo-geth/blob/master/docs/programmers_guide/guide.md
[10]https://github.com/ewasm/biturbo/pull/64
[11]https://medium.com/@mandrigin/stateless-ethereum-binary-tries-experiment-b2c035497768
本文首發于微信公眾號：Unitimes。文章內容屬作者個人觀點，不代表和訊網立場。投資者據此操作，風險請自擔。
此文由 中國比特幣官網 編輯，未經允許不得轉載?。?a href="http://m.huohuxiazai.com/">首頁 > 比特幣新聞 » 引介 | EVM 字節碼的默克爾化