eth合約abi編譯

❶ DApp開發入門

本文僅介紹以太坊系列的DApp開發，其他鏈原理差不太多。

MetaMask安裝完成並運行後，可以在Chrome控制台列印 MetaMask注入的window.ethereum對象

關於ethereum對象，我們只需要關心 ethereum.request 就足夠了，MetaMask 使用 ethereum.request(args) 方法 來包裝 RPC API。這些 API 基於所有以太坊客戶端公開的介面。 簡單來說錢包交互的大部分操作都是由 request() 方法實現，通過傳入不同的方法名來區分。

⚠️ 即使ethereum對象中提供了chainId，isMetaMask，selectAddress屬性，我們也不能完全相信這些屬性，他們是不穩定或不標准，不建議使用。我們可以通過上面說的request方法，拿到可靠的數據 。

錢包通過method方法名，進行對應的實現 以獲取錢包地址為例

調用 ethereum.request({ method: "eth_requestAccounts" }) ，錢包實現了該方法，那麼就可以拿到錢包的地址了。

MetaMask注入的 window.ethereum 就是一個Provider，一個RPC節點也是一個Provider，通過Provider，我們有了訪問區塊鏈的能力。 在連接到錢包的情況下，通常使用錢包的Provider就可以了， ethers.providers.Web3Provider(ethereum)

如果只需要查詢一些區塊鏈數據，可以使用EtherscanProvider 和 InfuraProvider 連接公開的 第三方節點服務提供商 。JsonRpcProvider 和 IpcProvider 允許連接到我們控制或可以訪問的以太坊節點。

獲取當前賬戶余額

獲取最新區塊號

其他RPC操作，可以通過 JSON-RPC 查看。

通過 ethers.js 可以連接ERC20的合約，合約編譯後會生成ABI，合約部署後，會生成合約地址，開發者通過 ABI和合約地址 ，對合約發送消息。

合約中的方法大致分為兩種： 視圖方法(免費)，非視圖方法(消耗Gas) ，可以通過ABI查看方法類型。

⚠️ ERC20需要多加關注的是 Approve() 方法以及 transfer() 和 transferFrom() 的區別 ，授權過的代幣，被授權的那一方，可以通過調用 transferFrom() 方法,轉走你授權數量內的代幣，所以授權是一個很危險的操作，假設你授權了一個不良的合約，那你會面臨授權的token被轉走的風險，即使你沒有泄露私鑰助記詞。

便利三方庫： web3-react use-wallet

文檔： doc.metamask.io ethers

❷ 如何開發編譯部署調用智能合約

在Solidity中，一個合約由一組代碼（合約的函數）和數據（合約的狀態）組成。合約位於以太坊區塊鏈上的一個特殊地址。uint storedData; 這行代碼聲明了一個狀態變數，變數名為storedData，類型為 uint （256bits無符號整數）。你可以認為它就像資料庫裡面的一個存儲單元，跟管理資料庫一樣，可以通過調用函數查詢和修改它。在以太坊中，通常只有合約 的擁有者才能這樣做。在這個例子中，函數 set 和 get 分別用於修改和查詢變數的值。

跟很多其他語言一樣，訪問狀態變數時，不需要在前面增加 this. 這樣的前綴。

這個合約還無法做很多事情（受限於以太坊的基礎設施），僅僅是允許任何人儲存一個數字。而且世界上任何一個人都可以來存取這個數字，缺少一個（可靠 的）方式來保護你發布的數字。任何人都可以調用set方法設置一個不同的數字覆蓋你發布的數字。但是你的數字將會留存在區塊鏈的歷史上。稍後我們會學習如 何增加一個存取限制，使得只有你才能修改這個數字。

代幣的例子

接下來的合約將實現一個形式最簡單的加密貨幣。空中取幣不再是一個魔術，當然只有創建合約的人才能做這件事情（想用其他貨幣發行模式也很簡單，只是實現細節上的差異）。而且任何人都可以發送貨幣給其他人，不需要注冊用戶名和密碼，只要有一對以太坊的公私鑰即可。

注意
對於在線solidity環境來說，這不是一個好的例子。如果你使用在線solidity環境 來嘗試這個例子。調用函數時，將無法改變from的地址。所以你只能扮演鑄幣者的角色，可以鑄造貨幣並發送給其他人，而無法扮演其他人的角色。這點在線 solidity環境將來會做改進。

❸ 以太坊擴容方案ETH

以太坊擴容方案 Optimism 宣布將於 10 月推出一鍵部署功能，將在下一次主網升級中放棄自定義 Solidity 編譯器，一些無法解決自定義編譯器的項目將可以在不修改其代碼的情況下部署在 Optimism。團隊表示，Optimistic 將與對現有以太坊客戶端代碼（Geth）緊密耦合，可以引入對以太坊所做的任何改進，例如將能夠快速引入主要的硬分叉。此外， 團隊推出了 Optimistic 規范存儲庫，正在收集此設計相關的所有文檔。

以太坊 Layer 2 擴容方案 Optimism 宣布將升級成為 EVM 全兼容，升級後任何編寫了以 Geth 為目標的代碼的人現在都可以不加修改地進行合約部署，預計一鍵部署功能將於 10 月推出。 升級後，任何可以在以太坊上運行的工具都將在也被允許在 Optimistic Ethereum. 上運行。這意味著用戶將可以在 L2 上使用 DappTools、Vyper、Tenderly 以及 Hardhat。

9 月 18 日，Yearn.finance 的核心開發者「banteg」發推文表示，SushiSwap Launchpad 平台 MISO 攻擊者歸還全部 865 ETH。據以太坊區塊瀏覽器 Etherscan 顯示，此前攻擊 SushiSwap Launchpad 平台 MISO 的攻擊者向 SushiSwap 歸還了 800 ETH ，該操作分為兩筆交易，第一筆歸還 100ETH，第二筆歸還 700ETH，SushiSwap Launchpad 平台 MISO 上 Jay Pegs Auto Mart 項目的 DONA 代幣拍賣遭到攻擊，攻擊者向 MISO 前端插入了惡意代碼，將拍賣錢包地址改為了自己的錢包地址，損失目前已達 865 ETH （約 307 萬美元）。

❹ 用Go來做以太坊開發④智能合約

在這個章節中我們會介紹如何用Go來編譯，部署，寫入和讀取智能合約。

與智能合約交互，我們要先生成相應智能合約的應用二進制介面ABI(application binary interface)，並把ABI編譯成我們可以在Go應用中調用的格式。

第一步是安裝 Solidity編譯器 ( solc ).

Solc 在Ubuntu上有snapcraft包。

Solc在macOS上有Homebrew的包。

其他的平台或者從源碼編譯的教程請查閱官方solidity文檔 install guide .

我們還得安裝一個叫 abigen 的工具，來從solidity智能合約生成ABI。

假設您已經在計算機上設置了Go，只需運行以下命令即可安裝 abigen 工具。

我們將創建一個簡單的智能合約來測試。 學習更復雜的智能合約，或者智能合約的開發的內容則超出了本書的范圍。 我強烈建議您查看 truffle framework 來學習開發和測試智能合約。

這里只是一個簡單的合約，就是一個鍵/值存儲，只有一個外部方法來設置任何人的鍵/值對。 我們還在設置值後添加了要發出的事件。

雖然這個智能合約很簡單，但它將適用於這個例子。

現在我們可以從一個solidity文件生成ABI。

它會將其寫入名為「Store_sol_Store.abi」的文件中

現在讓我們用 abigen 將ABI轉換為我們可以導入的Go文件。 這個新文件將包含我們可以用來與Go應用程序中的智能合約進行交互的所有可用方法。

為了從Go部署智能合約，我們還需要將solidity智能合約編譯為EVM位元組碼。 EVM位元組碼將在事務的數據欄位中發送。 在Go文件上生成部署方法需要bin文件。

現在我們編譯Go合約文件，其中包括deploy方法，因為我們包含了bin文件。

在接下來的課程中，我們將學習如何部署智能合約，然後與之交互。

Commands

Store.sol

solc version used for these examples

如果你還沒看之前的章節，請先學習 編譯智能合約的章節 因為這節內容，需要先了解如何將智能合約編譯為Go文件。

假設你已經導入從 abigen 生成的新創建的Go包文件，並設置ethclient，載入您的私鑰，下一步是創建一個有配置密匙的交易發送器(tansactor)。 首先從go-ethereum導入 accounts/abi/bind 包，然後調用傳入私鑰的 NewKeyedTransactor 。 然後設置通常的屬性，如nonce，燃氣價格，燃氣上線限制和ETH值。

如果你還記得上個章節的內容, 我們創建了一個非常簡單的「Store」合約，用於設置和存儲鍵/值對。 生成的Go合約文件提供了部署方法。 部署方法名稱始終以單詞 Deploy 開頭，後跟合約名稱，在本例中為 Store 。

deploy函數接受有密匙的事務處理器，ethclient，以及智能合約構造函數可能接受的任何輸入參數。我們測試的智能合約接受一個版本號的字元串參數。 此函數將返回新部署的合約地址，事務對象，我們可以交互的合約實例，還有錯誤（如果有）。

就這么簡單：）你可以用事務哈希來在Etherscan上查詢合約的部署狀態: https://rinkeby.etherscan.io/tx/

Commands

Store.sol

contract_deploy.go

solc version used for these examples

這寫章節需要了解如何將智能合約的ABI編譯成Go的合約文件。如果你還沒看， 前先讀 上一個章節 。

一旦使用 abigen 工具將智能合約的ABI編譯為Go包，下一步就是調用「New」方法，其格式為「New<contractname style="box-sizing: border-box; font-size: 16px; -ms-text-size-adjust: auto; -webkit-tap-highlight-color: transparent;">」，所以在我們的例子中如果你 回想一下它將是 NewStore 。 此初始化方法接收智能合約的地址，並返回可以開始與之交互的合約實例。</contractname>

Commands

Store.sol

contract_load.go

solc version used for these examples

這寫章節需要了解如何將智能合約的ABI編譯成Go的合約文件。如果你還沒看， 前先讀 上一個章節 。

在上個章節我們學習了如何在Go應用程序中初始化合約實例。 現在我們將使用新合約實例提供的方法來閱讀智能合約。 如果你還記得我們在部署過程中設置的合約中有一個名為 version 的全局變數。 因為它是公開的，這意味著它們將成為我們自動創建的getter函數。 常量和view函數也接受 bind.CallOpts 作為第一個參數。了解可用的具體選項要看相應類的 文檔 一般情況下我們可以用 nil 。

Commands

Store.sol

contract_read.go

solc version used for these examples

這寫章節需要了解如何將智能合約的ABI編譯成Go的合約文件。如果你還沒看， 前先讀 上一個章節 。

寫入智能合約需要我們用私鑰來對交易事務進行簽名。

我們還需要先查到nonce和燃氣價格。

接下來，我們創建一個新的keyed transactor，它接收私鑰。

然後我們需要設置keyed transactor的標准交易選項。

現在我們載入一個智能合約的實例。如果你還記得 上個章節 我們創建一個名為 Store 的合約，並使用 abigen 工具生成一個Go文件。 要初始化它，我們只需調用合約包的 New 方法，並提供智能合約地址和ethclient，它返回我們可以使用的合約實例。

我們創建的智能合約有一個名為 SetItem 的外部方法，它接受solidity「bytes32」格式的兩個參數（key，value）。 這意味著Go合約包要求我們傳遞一個長度為32個位元組的位元組數組。 調用 SetItem 方法需要我們傳遞我們之前創建的 auth 對象（keyed transactor）。 在幕後，此方法將使用它的參數對此函數調用進行編碼，將其設置為事務的 data 屬性，並使用私鑰對其進行簽名。 結果將是一個已簽名的事務對象。

現在我就可以看到交易已經成功被發送到了以太坊網路了: https://rinkeby.etherscan.io/tx/

要驗證鍵/值是否已設置，我們可以讀取智能合約中的值。

搞定！

Commands

Store.sol

contract_write.go

solc version used for these examples

有時您需要讀取已部署的智能合約的位元組碼。 由於所有智能合約位元組碼都存在於區塊鏈中，因此我們可以輕松獲取它。

首先設置客戶端和要讀取的位元組碼的智能合約地址。

現在你需要調用客戶端的 codeAt 方法。 codeAt 方法接受智能合約地址和可選的塊編號，並以位元組格式返回位元組碼。

你也可以在etherscan上查詢16進制格式的位元組碼 https://rinkeby.etherscan.io/address/#code

contract_bytecode.go

首先創建一個ERC20智能合約interface。 這只是與您可以調用的函數的函數定義的契約。

然後將interface智能合約編譯為JSON ABI，並使用 abigen 從ABI創建Go包。

假設我們已經像往常一樣設置了以太坊客戶端，我們現在可以將新的 token 包導入我們的應用程序並實例化它。這個例子里我們用 Golem 代幣的地址.

我們現在可以調用任何ERC20的方法。 例如，我們可以查詢用戶的代幣余額。

我們還可以讀ERC20智能合約的公共變數。

我們可以做一些簡單的數學運算將余額轉換為可讀的十進制格式。

同樣的信息也可以在etherscan上查詢: https://etherscan.io/token/?a=

Commands

erc20.sol

contract_read_erc20.go

solc version used for these examples

❺ 006：MPT與RLP|《ETH原理與智能合約開發》筆記

待字閨中開發了一門區塊鏈方面的課程：《深入淺出ETH原理與智能合約開發》，馬良老師講授。此文集記錄我的學習筆記。

課程共8節課。其中，前四課講ETH原理，後四課講智能合約。
第二課分為三部分：

這篇文章是第二課第二部分的學習筆記：MPT與RLP。

MPT，Merkle Patricia Tree，結合了Merkle Tree（默克爾樹）和 Patricia Tree（帕特里夏樹）的一種數據結構。
RLP，Recursive Length Prefix，一種編碼方法。

這是兩個非常重要的數據結構，在以太坊的區塊和交易中都有用到。

先分別介紹一下Merkle Tree 和 Patricia Tree。
Merkle Tree 和 Patricia Tree Merkle Tree 和 Patricia Tree
默克爾樹的解釋：對每一個交易計算其散列值（Hash），再對兩個散列值求他們的散列值。如果是奇數個，就把最後一個重復一次。最後得到的一個散列值就是默克爾樹根的值。如圖，交易1、1、2、3的散列值分別是HASH0、HASH1、HASH2、HASH3。HASH0和HASH1結合在一起計算散列值得HASH01，HASH2和HASH3結合在一起計算散列值得HASH23，接下來HASH01、HASH23結合在一起，計算散列值得HASH0123。

採用默克爾樹的好處是可以方便的判斷一個交易是否在區塊中。

Patricia Tree，可稱為壓縮前綴樹。如上圖右半部分。相同的前綴在同一分支中，後面一同的部分分叉出來，如test和toast，都有相同的t，est和oast在兩個分支中。

這個結構的好處是節省空間，因為每一級的鍵值可以是多個字元。

了解了Merkle Tree 和 Patricia Tree後，再來看這兩者混合後的產物——MPT。
這里的原理知識單獨來看不易理解，和具體的例子結合起來才更容易理解，此處先放上課件截圖。在後面的例子中再做說明。
Merkle Patricia Tree 規格 Merkle Patricia Tree 規格
在MPT中，還涉及到三個小的編碼標准。主要規則如圖。下面結合兩個例子說明一下。
三個編碼標准 三個編碼標准
HEX編碼的例子：從ASCII碼表中可以查出，b的十六進制編碼為62，o的十六進制編碼為6F，F在十六進制中就是15的意思。因為這是個葉子節點，最後加上0x10表示結束，也就是16。所以最後的編碼為[6 2 6 15 6 2 16]

HEX-Prefix編碼的例子：[6 2 6 15 6 2 16]，將其最後的0x10去掉，[6 2 6 15 6 2]。前面補一個四元組，其中（倒數）第0位是區分奇偶信息的，[6 2 6 15 6 2]是偶數位，第0位是0；第1位是區分節點類型的，這是葉子節點，第1位是1。所以這個四元組就是0010是2。「如果輸入key的長度是偶數則再添加一個四元組0x0在flag四元組之後。」，所以，最終的前綴是0x20。本例最終的結果，[32 98 111 98]，即[0x20, 0x62, 0x6F, 0x62]

下面是綜合性的例子，通過它可以很方便地理解前面的理論知識。值得多看幾篇，仔細休會。

初始的key-value對為：

其中，<>中的數據為key的16進制編碼。
MPT.jpg MPT.jpg
因為4組數據都有公共的6，所以這個節點的值為6，長度為1，奇數；節點類型：擴展節點；所以前綴就是0001，即1。

這是個擴展節點，它的值是一個Hashvalue，它指向一個分支節點。Hashvalue，具體指的是分支節點RLP編碼的結果的散列值。（RLP見下小節）

分支節點。上面4組數據的第2位是4和8兩種情況。在4的位置上存的是下面的擴展節點的散列值，在8的位置上存的是下面的葉子節點的散列值。

葉子節點。以68開頭的只有一個了。所以這個節點上的四元組就是6f727365了。它是偶數位。前綴是0x20（同前文HEX-Prefix編碼的例子）。這個葉子節點的value值為'stallion'。

擴展節點。在64之後，公共的部分是6f，這個擴展節點的key即為6f，前綴為0000，即00。這個擴展節點的value存放的是一個hashvalue，指向下一個節點，一個分支節點。

分支節點。646f已經表達完，這個節點的value值就是646f對應的值，'verb'。

除此之外，646f之後就是6，所以在這個分支節點的6位置上有一個散列值，指向下一個節點。

擴展節點。在646f6之後，公共的部分是7，其長度為1，奇數。所以前綴為0001。這個節點的value是一個散列值，指向下一個節點。

分支節點。646f67已經表達完，這個節點的value值就是646f67對應的值，'puppy'。

除此之外，646f67之後就是6，所以在這個分支節點的6位置上有一個散列值，指向下一個節點。

葉子節點。key為5，value為'coin'。長度為1，奇數，前綴0011，即3。

整個分析過程結束。可結合上圖和前文的理論多加復習。

這小節也是理論性較強，通過例子可以方便理解。先放上課件，再根據我的理解舉更多的例子。同樣，學習方法也是理論和例子配合學習。其中，list的例子在下篇文章的上機實驗部分再列舉。 RLP的編碼標准 RLP的編碼標准 再舉幾個例子 再舉幾個例子

❻ ETH hardhat介紹

官方doc

官方Tutorial

環境配置：因為需要使用 Ethers.js 進行測試和交互，所以需要安裝node.js；

安裝：npm install --save-dev hardhat

在項目中執行 npx hardhat，經過提示，選擇自己要使用的模版，然後會在根目錄中創建必要的文件和目錄；

可以看到框架已經幫我們分好了目錄，其中contracts目錄下是具體的solidity合約代碼；scripts中是部署合約需要的代碼；test中是測試代碼；

編譯： npx hardhat complie

部署： npx hardhat run scripts/deploy.js --network

測試： npx hardhat test

由於hardhat自帶本地ETH網路，所以不需要啟動節點可以通過web3介面進行測試；

Debug:

❼ java中怎麼樣調用eth的智能合約

一般來說，部署智能合約的步驟為：
1啟動一個以太坊節點 (例如geth或者testrpc)。
2使用solc編譯智能合約。 => 獲得二進制代碼。
3將編譯好的合約部署到網路。（這一步會消耗以太幣，還需要使用你的節點的默認地址或者指定地址來給合約簽名。） => 獲得合約的區塊鏈地址和ABI（合約介面的JSON表示，包括變數，事件和可以調用的方法）。(譯註：作者在這里把ABI與合約介面弄混了。ABI是合約介面的二進製表示。)
4用web3.js提供的JavaScript API來調用合約。（根據調用的類型有可能會消耗以太幣。）

❽ 以太坊的ABI編碼

ABI全稱Application Binary Interface, 是調用智能合約函數以及合約之間函數調用的消息編碼格式定義,也可以理解為智能合約函數調用的介面說明. 類似Webservice里的SOAP協議一樣；也就是定義操作函數簽名，參數編碼，返回結果編碼等。

使用ABI協議時必須要求在編譯時知道類型,即強類型相關.

當一個智能合約編譯出來後, 他的abi介面定義就確定了. 比如下面的智能合約:

生成的位元組碼:

生成的abi定義:

可以看出, 生成abi包含了2個定義: 函數 lotus , 事件 Log_lotus , 各個欄位含義見上. 根據該abi定義,就可以生成調用該智能合約函數的abi格式的數據了.

格式簡單的可以表示為: 函數選擇器+參數編碼

一個函數調用的前四個位元組數據指定了要調用的函數簽名。計算方式是使用函數簽名的 keccak256 的哈希，取4個位元組。

函數名如果有多個參數使用,隔開，要去掉表達式中的所有空格。在geth客戶端,通過命令可以得到hash:

由於前面的函數簽名使用了四個位元組，參數的數據將從第五個位元組開始。

根據參數類型,編碼規則有所區別:

除了bytes,和string, 其他類型的數據不足32位元組長度的需要加0補足32位元組. 動態長度的編碼在例子中介紹.

函數: function baz(uint32 x, bool y) :

調用: baz(69, true)

生成的數據如下:

返回結果是一個bool值，在這里，返回的是false:

函數: f(uint,uint32[],bytes10,bytes)

調用: (0x123, [0x456, 0x789], "1234567890", "Hello, world!")

函數選擇器: bytes4(sha3("f(uint256,uint32[],bytes10,bytes)"))

對於 固定大小的類型 值 uint256 和 bytes10 ，直接編碼值。

對於 動態內容類型 值 uint32[] 和 bytes ，我們先 編碼偏移值 ，偏移值是整個值編碼的開始到真正存這個數據的偏移值（這里不計算頭四個用於表示函數簽名的位元組）。

所以參數編碼數據依次為：

尾部部分的第一個動態參數， [0x456, 0x789] 編碼拆解如下：

最後我們來看看第二個動態參數的的編碼， Hello, world! 。

所以最終結果是:

❾ 用Go來做以太坊開發⑤事件日誌

智能合約具有在執行期間「發出」事件的能力。 事件在以太坊中也稱為「日誌」。 事件的輸出存儲在日誌部分下的事務處理中。 事件已經在以太坊智能合約中被廣泛使用，以便在發生相對重要的動作時記錄，特別是在代幣合約（即ERC-20）中，以指示代幣轉賬已經發生。 這些部分將引導您完成從區塊鏈中讀取事件以及訂閱事件的過程，以便交易事務被礦工打包入塊的時候及時收到通知。

為了訂閱事件日誌，我們需要做的第一件事就是撥打啟用websocket的以太坊客戶端。 幸運的是，Infura支持websockets。

下一步是創建篩選查詢。 在這個例子中，我們將閱讀來自我們在之前課程中創建的示例合約中的所有事件。

我們接收事件的方式是通過Go channel。 讓我們從go-ethereum core/types 包創建一個類型為 Log 的channel。

現在我們所要做的就是通過從客戶端調用 SubscribeFilterLogs 來訂閱，它接收查詢選項和輸出通道。 這將返回包含unsubscribe和error方法的訂閱結構。

最後，我們要做的就是使用select語句設置一個連續循環來讀入新的日誌事件或訂閱錯誤。

我們會在下個章節介紹如何解析日誌。

Commands

Store.sol

event_subscribe.go

智能合約可以可選地釋放「事件」，其作為交易收據的一部分存儲日誌。讀取這些事件相當簡單。首先我們需要構造一個過濾查詢。我們從go-ethereum包中導入 FilterQuery 結構體並用過濾選項初始化它。我們告訴它我們想過濾的區塊范圍並指定從中讀取此日誌的合約地址。在示例中，我們將從在 智能合約章節 創建的智能合約中讀取特定區塊所有日誌。

下一步是調用ethclient的 FilterLogs ，它接收我們的查詢並將返回所有的匹配事件日誌。

返回的所有日誌將是ABI編碼，因此它們本身不會非常易讀。為了解碼日誌，我們需要導入我們智能合約的ABI。為此，我們導入編譯好的智能合約Go包，它將包含名稱格式為 <Contract>ABI 的外部屬性。之後，我們使用go-ethereum中的 accounts/abi 包的 abi.JSON 函數返回一個我們可以在Go應用程序中使用的解析過的ABI介面。

現在我們可以通過日誌進行迭代並將它們解碼為我么可以使用的類型。若您回憶起我們的樣例合約釋放的日誌在Solidity中是類型為 bytes32 ，那麼Go中的等價物將是 [32]byte 。我們可以使用這些類型創建一個匿名結構體，並將指針作為第一個參數傳遞給解析後的ABI介面的 Unpack 函數，以解碼原始的日誌數據。第二個參數是我們嘗試解碼的事件名稱，最後一個參數是編碼的日誌數據。

此外，日誌結構體包含附加信息，例如，區塊摘要，區塊號和交易摘要。

若您的solidity事件包含 indexed 事件類型，那麼它們將成為 主題 而不是日誌的數據屬性的一部分。在solidity中您最多隻能有4個主題，但只有3個可索引的事件類型。第一個主題總是事件的簽名。我們的示例合約不包含可索引的事件，但如果它確實包含，這是如何讀取事件主題。

正如您所見，首個主題只是被哈希過的事件簽名。

這就是閱讀和解析日誌的全部內容。要學習如何訂閱日誌，閱讀上個章節。

命令

Store.sol

event_read.go

首先，創建ERC-20智能合約的事件日誌的interface文件 erc20.sol :

然後在給定abi使用 abigen 創建Go包

現在在我們的Go應用程序中，讓我們創建與ERC-20事件日誌簽名類型相匹配的結構類型：

初始化以太坊客戶端

按照ERC-20智能合約地址和所需的塊范圍創建一個「FilterQuery」。這個例子我們會用 ZRX 代幣:

用 FilterLogs 來過濾日誌：

接下來我們將解析JSON abi，稍後我們將使用解壓縮原始日誌數據：

為了按某種日誌類型進行過濾，我們需要弄清楚每個事件日誌函數簽名的keccak256哈希值。 事件日誌函數簽名哈希始終是 topic [0] ，我們很快就會看到。 以下是使用go-ethereum crypto 包計算keccak256哈希的方法：

現在我們將遍歷所有日誌並設置switch語句以按事件日誌類型進行過濾：

現在要解析 Transfer 事件日誌，我們將使用 abi.Unpack 將原始日誌數據解析為我們的日誌類型結構。 解包不會解析 indexed 事件類型，因為它們存儲在 topics 下，所以對於那些我們必須單獨解析，如下例所示：

Approval 日誌也是類似的方法：

最後，把所有的步驟放一起：

我們可以把解析的日誌與etherscan的數據對比: https://etherscan.io/tx/#eventlog

Commands

erc20.sol

event_read_erc20.go

solc version used for these examples

要讀取 0x Protocol 事件日誌，我們必須首先將solidity智能合約編譯為一個Go包。

安裝solc版本 0.4.11

為例如 Exchange.sol 的事件日誌創建0x Protocol交易所智能合約介面:

Create the 0x protocol exchange smart contract interface for event logs as Exchange.sol :

接著給定abi，使用 abigen 來創建Go exchange 包：

Then use abigen to create the Go exchange package given the abi:

現在在我們的Go應用程序中，讓我們創建與0xProtocol事件日誌簽名類型匹配的結構體類型：

初始化以太坊客戶端：

創建一個 FilterQuery ，並為其傳遞0x Protocol智能合約地址和所需的區塊范圍：

用 FilterLogs 查詢日誌：

接下來我們將解析JSON abi，我們後續將使用解壓縮原始日誌數據：

為了按某種日誌類型過濾，我們需要知曉每個事件日誌函數簽名的keccak256摘要。正如我們很快所見到的那樣，事件日誌函數簽名摘要總是 topic[0] ：

現在我們迭代所有的日誌並設置一個switch語句來按事件日誌類型過濾：

現在要解析 LogFill ，我們將使用 abi.Unpack 將原始數據類型解析為我們自定義的日誌類型結構體。Unpack不會解析 indexed 事件類型，因為這些它們存儲在 topics 下，所以對於那些我們必須單獨解析，如下例所示：

對於 LogCancel 類似：

最後是 LogError ：

將它們放在一起並運行我們將看到以下輸出：

將解析後的日誌輸出與etherscan上的內容進行比較： https://etherscan.io/tx/

命令

Exchange.sol

event_read_0xprotocol.go

這些示例使用的solc版本

❿ ETH合約開發語言是啥

Solidity 語言是一種專門用於編寫和執行智能合約的語言,是在以太坊虛擬機基礎上運行的、面向合約的高級語言。

「分布式平台」部分意味著任何人都可以建立並運行以太坊節點，就像任何人都可以運行比特幣節點一樣。任何想要在節點上運行「智能合約」的人都必須向Ether中的這些節點的運營商付款，這是一個與以太坊相關的加密貨幣。

因此，運行乙太網節點的人提供計算能力，並在乙太網中獲得支付，這與運行比特幣節點的人提供哈希能力並以比特幣支付的方式類似。

功能應用：

以太坊是一個平台，它上面提供各種模塊讓用戶來搭建應用，如果將搭建應用比作造房子，那麼以太坊就提供了牆面、屋頂、地板等模塊，用戶只需像搭積木一樣把房子搭起來，因此在以太坊上建立應用的成本和速度都大大改善。

以太坊通過一套圖靈完備的腳本語言來建立應用，它類似於匯編語言。我們知道，直接用匯編語言編程是非常痛苦的，但以太坊里的編程並不需要直接使用EVM語言，而是類似C語言、Python、Lisp等高級語言，再通過編譯器轉成EVM語言。