SOL:智能合約解構（2）：創建與運行時間代碼解析_SolarMineX

本文是系列文章的第二部分。如果您還沒有閱讀本文的前言，請先看一下，第一部分·引言我們正在解構一個簡單的solidity智能合約的EVM字節碼。今天，讓我們開始用“分而治之”的策略來拆解智能合約的復雜代碼吧。我在介紹性的前言中說過，這個反匯編的代碼其實非常低級，但與原始字節碼相比會比較易讀。請確保已在遵循了我在前言中介紹的操作，把BasicToken的代碼在remix編譯器中進行了部署。免責聲明：本文中提供的所有說明均受我自己對transaction運作方式的解釋，不代表以太坊官方意見。現在，讓我們聚焦在JUMP、JUMPI、JUMPDES、RETURN和STOP操作嗎，并忽略所有其他的操作。每當我們發現不是其中之一的操作碼時，我們就忽略它，并跳到下一條指令，不要被他們干預。當EVM執行代碼時，是自上而下的順序，代碼中沒有其他入口點，始終從頂部開始執行。JUMP和JUMPI可以讓代碼跳轉。JUMP獲取堆棧中的最上面的值，并將執行移動到該位置的指令。但是，目標位置必須包含JUMPDEST操作碼，否則執行將失敗。這樣做的唯一目的是：JUMPDEST將位置標記為有效的跳轉目標。JUMPI也完全相同，但堆棧的第二個位置一定不能有“0”，否則就沒有跳轉。所以這是一個有條件的跳轉，STOP是讓智能合約完全停止的指令，RETURN則是暫停智能合約的執行，但返回EVM內存的一部分數據，這很方便。所以，讓我們開始解釋代碼時考慮到所有這些。在Remix的調試器中，將“transaction”的滑塊滑到最左邊。你可以使用StepInto按鈕并按照說明進行操作。前面的指令可以忽略，直接到第11條指令，我們找到了第一條JUMPI。如果它沒有跳轉，它將繼續通過指令12到15并最終進入REVERT，接著將停止執行。但如果跳轉，它將跳過這些指令到位置16。指令16是一個JUMPDEST。繼續單步執行操作碼，直到“transaction”滑塊一直向右。剛剛發生了很多等等，但只有在68的位置才能找到RETURN操作碼。這很奇怪。如果您考慮一下，本智能合約的控制流程將始終在指令15或68結束。我們剛剛完成它并確定沒有其他可能的流程，那么剩下的指令是什么？。我們剛剛遍歷的指令集就是所謂的合約的“創建代碼”。它永遠不會成為智能合約代碼本身的一部分，但僅在創建智能合約的交易期間由EVM執行一次。我們很快就會發現，這段代碼負責設置創建的合約的初始狀態，以及返回其運行時代碼的副本。剩下的497條指令，正如我們所見，執行流程永遠不會達到的，正是這些代碼將成為已部署智能合約的一部分。接下來，我們對代碼進行第一次拆分：把創建時的代碼與運行時的代碼區分開。創建部分

硅谷王川：Uniswap等撮合交易的智能合約是以太網絡擁堵，費用高企不下的最重要原因:獨立投資人硅谷王川表示，以太坊網絡上的不同操作，傳輸的數據大小不一樣，因此消耗費用也不一樣。Uniswap等撮合交易的智能合約，消耗了網絡上20%的流量，是以太網絡擁堵，費用高企不下的最重要原因。可以把這些智能合約看成一個完全開放的國際倒爺做買賣的貿易自由港。從這個角度看，70美元的gas成本其實不貴，如果嫌貴，那是因為你做的生意太小。Paypal做國際支付，一旦涉及到匯率不同的國家之間支付，支付費用可以到金額的4.5%，而且清算常常有延遲。從這個角度看，以太網的費用，即使在現在的相對高位，仍然是良心價格。

最終解決問題的方案，可能是Uniswap或者其競爭者推出一個rollup的智能合約，把交易批處理，費用可以壓縮到忽略不計 (但清算會有些延遲)。只要有一家推出，競爭者必須馬上跟進，否則別人就不用了，這樣主網絡上的費用也會迅速大幅下降。現在已經有二層rollup解決方案，如zkswap上線，但和Uniswap相比，鎖倉金額不到后者的5%，主要交易對的流動性不到Uniswap的十分之一，還需要一段時間市場檢驗。[2021/2/25 17:51:22]

現在，我們將深入研究代碼的創建部分。圖1.解構BasicToken.sol的創建時EVM字節碼這是本文中要理解的最重要的概念。創建代碼在事務中執行，該事務返回運行時代碼的副本，該副本是智能合約的實際代碼。正如我們將看到的，構造函數是創建代碼的一部分，而不是運行時代碼的一部分。智能合約的構造函數是創建代碼的一部分;一旦部署，它將不會出現在智能合約的代碼中。這種魔力是如何發生的？這就是我們現在要逐步分析的內容。好的。所以現在我們的問題被簡化為理解這些與創建時代碼相對應的70條指令。讓我們重新采用自上而下的方法，這次了解所有指令，而不是跳過任何指令。首先，讓我們關注使用PUSH1和MSTORE操作碼的指令0到2。圖2.空閑內存指針EVM字節碼結構PUSH1只需將一個字節壓入堆棧頂部，而MSTORE從堆棧中抓取最后兩個項并將其中一個存儲在內存中：mstore(0x40,0x80)|||Whattostore.Wheretostore.(inmemory)注意：上面的代碼片段是Yul-ish代碼。注意它是如何從左到右消耗堆棧中的元素，總是首先消耗堆棧頂部的元素。這是將數字0x80存儲在位置0x40的位置。在我們現在討論的問題中，不用去管它，如果必須有一個原因，我后面會解釋。現在，在Remix的Debugger選項卡中打開Stack以及Memory的面板，以便在逐步查看這些指令時可以可視化。你可能想知道：指令1和3發生了什么？PUSH是唯一由兩個或多個字節組成的EVM指令。所以，PUSH80是兩條指令。所以我們揭開了謎底：指令1是0x80，而指令3的0x40。接下來我會說明從5到15的指令。圖3.non-payable檢查EVM字節碼結構。在這里，又有一大堆的新的操作碼：CALLVALUE，DUP1，ISZERO，PUSH2，和REVERT。CALLVALUE推送創建事務中涉及的wei的數量，DUP1復制堆棧中的第一個元素，如果堆棧的最高值為零，ISZERO則將1推送到堆棧，PUSH2就像PUSH1，但它將兩個字節推送到堆棧，而REVERT則是停止執行。那么這里發生了什么？在Solidity中，我們可以像這樣編寫這個匯編：ifrevert;這段代碼實際上不是我們原始Solidity源的一部分，而是由編譯器注入的，因為我們沒有將構造函數聲明為payable。在Solidity的最新版本中，未明確聲明為payable的函數不能接收以太。返回到匯編代碼，在指令11的JUMPI將跳過指令12到15，如果沒有相關的以太幣，則跳轉到16。否則，REVERT將以兩個參數執行為0。好的！讓我們中場休息一下，來杯咖啡。如果您想要另一種方式來可視化我們剛剛完成的工作，請嘗試使用我構建的這個簡單工具：solmap。它允許您實時編譯Solidity代碼，然后單擊EVM操作碼以突出顯示相關的Solidity代碼。反匯編與Remix有點不同，但你應該能夠通過比較來理解它。咖啡時間到！準備繼續前進了嗎？接下來是指令16到37。請繼續使用Remix的調試器。。圖4.EVM字節碼結構，用于從智能合約字節碼末尾附加的代碼中檢索構造函數參數前四個指令讀取位置在存儲器中的任何內容0x40，并將其推送到堆棧。如果你能回憶起來，那應該是數字0x80。下面是推0x20到堆棧，并拷貝該值，壓棧0x0217，最后拷貝第四個值，這應該是0x80。在查看這樣的EVM指令時，可以暫時不了解發生了什么。別擔心，它會時不時出現在你的腦海。在指令28，執行了CODECOPY，它接受三個參數：目標內存位置，用來存儲復制代碼，從中復制的指令編號，以及要復制的代碼的字節數。因此，在這種情況下，0x80從位于代碼中的字節位置開始。如果查看整個反匯編代碼，有566條指令。為什么這段代碼試圖復制最后32個字節的代碼呢？實際上，在部署包含參數的構造函數的合約時，參數作為原始十六進制數據附加到代碼的末尾。在這種情況下，構造函數接受一個uint256參數，因此所有這些代碼所做的就是將參數從附加在代碼末尾的值復制到內存中。這些32條指令作為反匯編代碼沒有意義，但是它們用原始的十六進制表示：0x0000000000000000000000000...0000000000000000000002710。當然，這是我們在部署智能合約時傳遞給構造函數的十進制值10000！你可以一步一步地在Remix中重復這一部分，確保您了解剛剛發生的事情。最終結果應該是0x00..002710的位置，看到在內存中的數字0x80。好，開始下一部分之前，我建議來一杯威士忌休息一下。威士忌時光！為什么建議你來一杯威士忌，因為從這里開始，都是下坡路了。下一組指令是29到35，更新內存地址0x40的值0x80到值0xa0，可以看到，它們將值偏移了0x20字節。現在我們可以開始理解指令0到2了。Solidity追蹤稱為“空內存指針”的東西：即內存中我們可以用來存儲東西的地方，保證沒有人會覆蓋它。因此，由于我們將數字10000存儲在舊的空閑內存位置，我們通過向前移動32個字節來更新空閑存儲器指針。即使是經驗豐富的Solidity開發人員在看到“空閑內存指針”或代碼時也會感到困惑，mload(0x40,0x80)，這些只是說，“每當我們寫一個新條目時，我們將從這一點開始寫入內存并保留偏移記錄”。Solidity中的每個函數，當編譯為EVM字節碼時，將初始化此指針。在0x00到0x40之間的內存有什么，你可能不知道。沒有。Solidity保留的一段內存，計算哈希值，我們很快就會看到，這對于映射和其他類型的動態數據是必需的。現在，在指令37中，MLOAD從存儲器讀取位置0x40并基本上將我們10000的值從內存下載到堆棧中，在那里它將是新的，并且可以在下一組指令中使用的。這是由Solidity生成的EVM字節碼中的常見模式：在執行函數體之前，函數的參數被加載到堆棧中，以便即將到來的代碼可以使用它們-這正是接下來會發生的事情。讓我們繼續說明38至55。圖5.構造函數的主體EVM代碼。這些指令只不過是構造函數的主體：也就是Solidity代碼：totalSupply_=_initialSupply;balances=_initialSupply;前四條指令非常明顯，首先，0被壓入堆棧，然后堆棧中的第二項被復制，然后數字0被復制并被推送到堆棧，這是存儲中的位置槽totalSupply_。現在，SSTORE可以使用這些值，并且仍然保持10000個以下以備將來使用：sstore(0x00,0x2710)|||Whattostore.Wheretostore.(instorage)瞧！我們將數字10000存儲在變量中totalSupply_。是不是很神奇??一定要在Remix的Debugger選項卡中可視化這個值。你可以在存儲完全加載的面板中找到它。下一組指令有點棘手，但基本上會處理在balances映射中存儲10000的密鑰msg.sender。在繼續之前，請確保您了解Solidity文檔的這一部分，該文檔說明了如何在內存中保存映射。簡而言之，它將連接映射值的槽與使用的鍵，然后用SHA3操作碼取摘要并使用它作為在內存中的目標位置。最后，存儲只是一個簡單的字典或哈希表。繼續執行指令43至45，將msg.sender地址存儲在內存中，然后在指令46至50中，將值1存儲在內存位置0x20。最后，SHA3操作碼計算從位置0x00到位置0x40的內存中的任何內容的Keccak256散列-即映射的插槽/位置與所使用的鍵的串聯。這正是值10000將存儲在我們的映射中的位置：sstore(hash...,0x2710)|||Whattostore.Wheretostore.此時，構造函數的主體已完全執行。所有這些起初可能有點壓倒性，但它是存儲在Solidity中工作的基本部分。如果你沒有得到它，我建議你跟著Remix的調試器重復幾次，保持堆棧和內存面板。另外，請隨時提出以下問題。此模式在Solidity生成的EVM字節碼中普遍使用，您將很快學會輕松識別它。最后，它只是計算在內存中保存映射的某個鍵的值的位置。圖6.運行時代碼復制結構在指令56至65中，我們再次執行代碼復制。只有這一次，我們不會將代碼的最后32個字節復制到內存中;我們從位置0x0046開始復制0x01d1字節到位置0的內存。這是要復制的一大塊代碼！如果您再次將滑塊一直向右滑動，您將注意到位置70正好在我們的創建時EVM代碼之后，執行停止的地方。運行時字節碼包含在那些465個字節中。這是代碼的一部分，它將作為智能合約的運行時代碼保存在區塊鏈中，該代碼將是每次有人或某事與智能合約交互時執行的代碼。。這正是指令66到69所做的：返回我們復制到內存的代碼。圖7.運行時代碼返回EVM字節碼結構。RETURN抓取復制到內存的代碼并將其交給EVM。如果此創建代碼在對0x0地址的事務的上下文中執行，則EVM將執行代碼并將返回值存儲為創建的智能合約的運行時代碼。到現在為止，我們的BasicToken代碼將創建和部署智能合約實例，并準備好使用其初始狀態和運行時代碼。如果退后一步并查看圖2，您將看到我們分析的所有EVM字節碼結構都是通用的，除了以紫色突出顯示的那個：也就是說，它們將是由Solidity編譯器生成的創建時字節碼。構造函數與構造函數的區別僅在于紫色部分-構造函數的實際體。獲取嵌入在字節碼末尾的參數的結構，以及復制運行時代碼并將其返回的結構，可以被認為是樣板代碼和通用EVM操作碼結構。您現在應該能夠查看任何構造函數，在按指令學習之前，您應該對構成它的組件有一個大概的了解。在本系列的下一篇文章中，我們將介紹實際的運行時代碼，首先介紹如何在不同的入口點與智能合約的EVM代碼進行交互。現在，給自己一個當之無愧的輕拍，因為你剛剛消化了系列中最困難的部分。你還應該具有強大的能力來讀取和調試EVM字節碼，理解通用結構，最重要的是，了解創建時和運行時EVM字節碼之間的區別。這就是使得合約的構造函數在Solidity中如此特殊的原因。我們將在下一篇的系列文章中繼續解構！*本文由AlejandroSantander首發于medium，由獵豹區塊鏈安全翻譯并整理*獵豹區塊鏈安全以金山霸的技術為依托，結合人工智能、nlp等技術，為區塊鏈用戶提供合約審計、情感分析等生態安全服務。Ratingtoken官網https://www.ratingtoken.net/?from=z

中幣支持LEND智能合約置換為AAVE:根據Aave官方說明，Aave已經啟動通過智能合約將原LEND代幣按照100LEND：1AAVE的比例轉換為AAVE新代幣，新的AAVE持有人將可以根據持幣權重參與Aave protocol協議的治理。

根據中幣官方公告，中幣將支持LEND（Aave Protocol）智能合約置換為Aave Protocol（AAVE），置換后，用戶將持有AAVE，10月10日14:00暫停LEND充提，16:00停止LEND/USDT交易。同時將于10月11日14:00開啟AAVE/USDT交易，并開放AAVE充值、提現。更多詳情請關注中幣官方公告。[2020/10/9]

OpenZeppelin智能合約開發庫更新3.2版本:區塊鏈開發工具提供商OpenZeppelin發布智能合約開發庫OpenZeppelinContracts的3.2版本，此次最大的變更是將代理合約（proxycontract）從OpenZeppelinSDK遷移到了OpenZeppelinContracts項目中。另外對于智能合約編程語言Solidity0.7版本的用戶而言，OpenZeppelin已經在npm上發布了較新的編譯器版本支持，最新版本為3.2.0-solc-0.7。[2020/9/14]

聲音 | 法學教授：智能合約不一定會擾亂傳統合同法:據cointelegraph報道，德國弗里德里希席勒大學法學教授Giesela Ruhl近日發文稱，智能合約不一定會擾亂傳統合同法，她認為智能合約與既定法律先例之間的摩擦可能被過分夸大了。智能合約將使商品和服務的交換不受國家法律的約束，但這一預期似乎沒有實現。事實上，合同法的經典問題也出現在當事人簽訂智能合約的時候。就像所有其他合約一樣，它需要法律來解決。因此，重要的不是智能合約是否應受法律約束，而是應受哪些法律的約束。[2019/1/24]

動態 | TrustToken推出新的智能合約AutoSweep:據coinspeaker消息，TrustToken團隊為TrueUSD推出了一項新的智能合約AutoSweep，它將允許交易所創建獨特的TUSD存款地址，以自動結算到主錢包中。[2019/1/14]

Tags：SOLSOLIDLIDDITSolarMineXVSolidusSolidexgamecredits

火必