以太坊logdebug

1. 以太坊的input和log數據結構（記錄以備忘）

以bsc上的一個普通的erc20轉賬交易（ Binance Transaction Hash (Txhash) Details | BscScan ）為例

input：』』

前面4位元組（8個十六進制）用來匹配調用的方法（用截取哈希值來匹配），這里匹配出來的是erc20的transfer方法：transfer(address recipient, uint256 amount)

再往後32個位元組（64個十六進制）是第一個入參的值，這里是recipient地址

再往後32個位元組（64個十六進制）是第二個入參，這里是amount，把十六進制轉回十進制即可

log：{

topic0：『』，

topic1：』 』，

topic2：『 』，

data：『『

}

這里topic0是event方法的哈希，這里是 web3py.keccak(text='Transfer(address,address,uint256)').hex()

topic1，2，3分別是event裡面的有indexed的入參，搜索得知transfer這個event的入參分別為address indexed from，address indexed to，正好對應著這里的topic1和topic2，即發送方和接收方的地址

data是event裡面沒有indexed的入參由先後順序按照相應的類型所佔的位元組數分隔開就行了，這里就是uint256（也就是每個變數佔64個十六進制的長度），轉賬金額

2. 以太坊合約地址錯誤是怎麼回事

可能是你的一台放屁的伺服器出現了問題，或者是嗯這個伺服器暫時有問題，IP地址有問題，都可能出現這樣的情況。

3. 【Ethereum】給MetaMask導入助記詞，恢復賬號

去年7月創建的MetaMask，存了一些ETH。已經過去半年了，我想恢復賬號該怎麼做呢？

步驟：

點擊工具欄的metamask按鈕打開頁面，點擊continue ↓

點擊頁面底部的 "import with seed phrase"，導入助記詞（因為太隱蔽我試了好幾遍才看到😓）
注意：輸密碼並點擊"create"會 新建 助記詞 ↓

1.2 如果已經安裝，並登錄了其他賬戶，則點擊log out ↓

並點擊下方的 import using account seed phrase：↓

會自動打開一個頁面，點擊 import using account seed phrase：↓

P.S. 本文章參考 https://medium.com/publicaio/how-import-a-wallet-to-your-metamask-account-dcaba25e558d

4. 用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版本

5. ETH(實現Etherscan的eventlog)

例如碼棚乎：
https://etherscan.io/tx/#eventlog

event的Keccak-256哈和檔希遲悉值

6. 以太坊的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! 。

所以最終結果是:

7. Quorum介紹

Quorum和以太坊的主要區別:

Quorum 的主要組件：

1,用其自己實現的基於投票機制的共識方式 來代替原來的 「Proof of work」 。
2,在原來無限制的P2P傳輸方式上增加了許可權功能。使得P2P傳輸只能在互相允許的節點間傳輸。
3, 修改區塊校驗邏輯使其能支持 private transaction。
4, Transaction 生成時支持 transaction 內容的替換。這個調整是為了能支持聯盟中的私有交易。

Constellation 模塊的主要職責是支持 private transaction。Constellation 由兩部分組成：Transaction Manager 和 Enclave。Transaction Manager 用來管理和傳遞私有消息，Enclave 用來對私有消息的加解密。

在私有交易中，Transaction Manager 會存儲私有交易的內容，並且會將這條私有交易內容與其他相關的 Transaction Manager 進行交互。同時它也會利用 Enclave 來加密或解密其收到的私有交易。

為了能更有效率的處理消息的加密與解密，Quorum 將這個功能單獨拉出並命名為 Enclave 模塊。Enclave 和 Transaction Manager 是一對一的關系。

在 Quorum 中有兩種交易類型，」Public Transaction」 和 「Privat Transaction」。在實際的交易中，這兩種類型都採用了以太坊的 Transaction 模型，但是又做了部分修改。Quorum 在原有的以太坊 tx 模型基礎上添加了一個新的 「privateFor」 欄位。同時，針對一個 tx 類型的對象添加了一個新的方法 「IsPrivate」。用 「IsPrivate」 方法來判斷 Transaction是 public 還是 private，用 「privateFor」 來記錄 事務只有誰能查看。

Public Transaction 的機理和以太坊一致。Transaction中的交易內容能被鏈上的所有人訪問到。

Private Transaction 雖然被叫做 「Private」，但是在全網上也會出現與其相關的交易。只不過交易的明細只有與此交易有關系的成員才能訪問到。在全網上看到的交易內容是一段hash值，當你是交易的相關人員時，你就能利用這個hash值，然後通過 Transaction Manager 和 Enclave 來獲得這筆交易的正確內容。

Public Transaction的處理流程和以太坊的Transaction流程一致。Transaction 廣播全網後，被礦工打包到區塊中。節點收到區塊並校驗區塊中的 事務 信息。然後根據 Transaction信息更新本地的區塊

Private Transaction也會將 Transaction 廣播至全網。但是它的 Transaction payload已經從原來的真實內容替換為一個hash值。這個hash值是由Transaction Manager提供的。

有兩個共識機制：QuorumChain Consensus 和 Raft-Based Consensus。
在 Quorum 1.2 之前的 Release 版本都採用了 QuorumChain。
從 2.0 版本開始，Quorum 廢棄了 QuorumChain 轉而只支持 Raft-based Consensus。

QuorumChain Consensus 是一個基於投票的共識演算法。其主要特點有：

相比較以太坊的POW，Raft-based 提供了更快更高效的區塊生成方式。相比 QuorumChain，Raft-based 不會產生空的區塊，而且在區塊的生成上比前者更有效率。

要想了解Raft-based Consensus，必須先了解Raft演算法

Raft演算法
Raft是一種一致性演算法，是為了確保容錯性，也就是即使系統中有一兩個伺服器當機，也不會影響其處理過程。這就意味著只要超過半數的大多數伺服器達成一致就可以了，假設有N台伺服器，N/2 +1 就超過半數，代表大多數了。
Raft的工作模式：
raft的工作模式是一個Leader和多個Follower模式，即我們通常說的領導者-追隨者模式。除了這兩種身份，還有Candidate身份。下面是身份的轉化示意圖

1，leader的選舉過程
raft初始狀態時所有server都處於Follower狀態，並且隨機睡眠一段時間，這個時間在0~1000ms之間。最先醒來的server A進入Candidate狀態，Candidate狀態的server A有權利發起投票，向其它所有server發出投票請求，請求其它server給它投票成為Leader。
2，Leader產生數據並同步給Follower
Leader產生數據，並向其它Follower節點發送數據添加請求。其它Follower收到數據添加請求後，判斷該append請求滿足接收條件（接收條件在後面安全保證問題3給出），如果滿足條件就將其添加到本地，並給Leader發送添加成功的response。Leader在收到大多數Follower添加成功的response後。提交後的log日誌就意味著已經被raft系統接受，並能應用到狀態機中了。

Leader具有絕對的數據產生權利，其它Follower上存在數據不全或者與Leader數據不一致的情況時，一切都以Leader上的數據為主，最終所有server上的日誌都會復製成與Leader一致的狀態。

Raft的動態演示： http://thesecretlivesofdata.com/raft/

安全性保證，對於異常情況下Raft如何處理：

1，Leader選舉過程中，如果有兩個FollowerA和B同時醒來並發出投票請求怎麼辦？
在一次選舉過程中，一個Follower只能投一票，這就保證了FollowerA和B不可能同時得到大多數（一半以上）的投票。如果A或者B中其一幸運地得到了大多數投票，就能順利地成為Leader，Raft系統正常運行下去。但是A和B可能剛好都得到一半的投票，兩者都成為不了Leader。這時A和B繼續保持Candidate狀態，並且隨機睡眠一段時間，等待進入到下一個選舉周期。由於所有Follower都是隨機選擇睡眠時間，所以連續出現多個server競選的概率很低。
2，Leader掛了後，如何選舉出新的Leader？
Leader在正常運行時候，會周期性的向Follower節點發送數據的同步請求，同時也是起到一個心跳作用。Follower節點如果在一段時間之內（一般是2000ms左右）沒有收到數據同步請求，則認為Leader已經死了，於是進入到Candidate狀態，開始發起投票競選新的Leader，每個新的Leader產生後就是一個新的任期，每個任期都對應一個唯一的任期號term。這個term是單調遞增的，用來唯一標識一個Leader的任期。投票開始時，Candidate將自己的term加1，並在投票請求中帶上term；Follower只會接受任期號term比自己大的request_vote請求，並為之投票。 這條規則保證了只有最新的Candidate才有可能成為Leader。

3，Follower的數據的生效時間
Follower在收到一條添加數據請求後，是否立即保存並將其應用到狀態機中去？如果不是立即應用，那麼由什麼來決定該條日誌生效的時間？
首先會檢查這條數據同步請求的來源信息是否與本地保存的leader信息符合，包括leaderId和任期號term。檢查合法後就將日誌保存到本地中，並給Leader回復添加log成功，但是不會立即將其應用到本地狀態機。Leader收到大部分Follower添加log成功的回復後，就正式將這條日誌commit提交。Leader在隨後發出的心跳append_entires中會帶上已經提交日誌索引。Follower收到Leader發出的心跳append_entries後，就可以確認剛才的log已經被commit(提交)了，這個時候Follower才會把日誌應用到本地狀態機。下表即是append_entries請求的內容，其中leaderCommit即是Leader已經確認提交的最大日誌索引。Follower在收到Leader發出的append_entries後即可以通過leaderCommit欄位決定哪些日誌可以應用到狀態機。

4，向raft系統中添加新機器時，由於配置信息不可能在各個系統上同時達到同步狀態，總會有某些server先得到新機器的信息，有些server後得到新機器的信息。比如在raft系統中有三個server，在某個時間段中新增加了server4和server5這兩台機器。只有server3率先感知到了這兩台機器的添加。這個時候如果進行選舉，就有可能出現兩個Leader選舉成功。因為server3認為有3台server給它投了票，它就是Leader，而server1認為只要有2台server給它投票就是Leader了。raft怎麼解決這個問題呢？

產生這個問題的根本原因是，raft系統中有一部分機器使用了舊的配置，如server1和server2，有一部分使用新的配置，如server3。解決這個問題的方法是添加一個中間配置(Cold, Cnew)，這個中間配置的內容是舊的配置表Cold和新的配置Cnew。這個時候server3收到添加機器的消息後，不是直接使用新的配置Cnew，而是使用(Cold, Cnew)來做決策。比如說server3在競選Leader的時候，不僅需要得到Cold中的大部分投票，還要得到Cnew中的大部分投票才能成為Leader。這樣就保證了server1和server2在使用Cold配置的情況下，還是只可能產生一個Leader。當所有server都獲得了添加機器的消息後，再統一切換到Cnew。raft實現中，將Cold，(Cold,Cnew)以及Cnew都當成一條普通的日誌。配置更改信息發送Leader後，由Leader先添加一條 (Cold, Cnew)日誌，並同步給其它Follower。當這條日誌(Cold, Cnew)提交後，再添加一條Cnew日誌同步給其它Follower，通過Cnew日誌將所有Follower的配置切換到最新。

Raft演算法和以太坊結合
所以為了連接以太坊節點和 Raft 共識，Quorum 採用了網路節點和 Raft 節點一對一的方式來實現 Raft-based 共識

一個Transaction完整流程
1，客戶端發起一筆 Transaction並通過 RPC 來呼叫節點。
2，節點通過以太坊的 P2P 協議將節點廣播給網路。
3，當前的 Raft leader 對應的以太坊節點收到了 Transaction後將它打包成區塊。
區塊被 編碼後傳遞給對應的 Raft leader。
leader 收到區塊後通過 Raft 演算法將區塊傳遞給 follower。這包括如下步驟：
3.1，leader 發送 AppendEntries 指令給 follower。
3.2，follower 收到這個包含區塊信息的指令後，返回確認回執給 leader。
3.3，leader 收到不少於指定數量的確認回執後，發送確認 append 的指令給 follower。
3.4，follower 收到確認 append 的指令後將區塊信息記錄到本地的 Raft log 上。
3.5，Raft 節點將區塊傳遞給對應的 Quorum 節點。Quorum 節點校驗區塊的合法性，如果合法則記錄到本地鏈上。

參考鏈接： http://blog.csdn.net/about_blockchain/article/details/78684901

8. 如何創建和簽署以太坊交易

交易

區塊鏈交易的行為遵循不同的規則集

• 由於公共區塊鏈分布式和無需許可的性質，任何人都可以簽署交易並將其廣播到網路。

• 根據區塊鏈的不同，交易者將被收取一定的交易費用，交易費用取決於用戶的需求而不是交易中資產的價值。

• 區塊鏈交易無需任何中央機構的驗證。僅需使用與其區塊鏈相對應的數字簽名演算法（DSA）使用私鑰對其進行簽名。

• 一旦一筆交易被簽名，廣播到網路中並被挖掘到網路中成功的區塊中，就無法恢復交易。

以太坊交易結構

• 以太坊交易的數據結構：交易0.1個ETH

  {
  'nonce':'0x00', // 十進制：0
  'gasLimit': '0x5208', //十進制： 21000
  'gasPrice': '0x3b9aca00', //十進制1，000，000，000
  'to': '' ，//發送地址
  'value': '0x16345785d8a0000',//100000000000000000 ，10^17
  'data': '0x', // 空數據的十進製表示
  'chainId': 1 // 區塊鏈網路ID
  }

  這些數據與交易內容無關，與交易的執行方式有關，這是由於在以太坊中發送交易中，您必須定義一些其他參數來告訴礦工如何處理您的交易。交易數據結構有2個屬性設計"gas": "gasPrice","gasLimit"。

• "gasPrice": 單位為Gwei, 為 1/1000個eth,表示交易費用

• "gasLimit": 交易允許使用的最大gas費用。

• 這2個值通常由錢包提供商自動填寫。

  除此之外還需要指定在哪個以太坊網路上執行交易（chainId）: 1表示以太坊主網。

  在開發時，通常會在本地以及測試網路上進行測試，通過測試網路發放的測試ETH進行交易以避免經濟損失。在測試完成後再進入主網交易。

  另外，如果需要提交一些其它數據，可以用"data"和"nonce"作為事務的一部分附加。

  A nonce（僅使用1次的數字）是以太坊網路用於跟蹤交易的數值，有助於避免網路中的雙重支出以及重放攻擊。

以太坊交易簽名

以太坊交易會涉及ECDSA演算法，以Javascript代碼為例，使用流行的ethers.js來調用ECDSA演算法進行交易簽名。

• const ethers = require('ethers')


• const signer = new ethers.Wallet('錢包地址')



• signer.signTransaction({


• 'nonce':'0x00', // 十進制：0


• 'gasLimit': '0x5208', //十進制： 21000


• 'gasPrice': '0x3b9aca00', //十進制1，000，000，000


• 'to': '' ，//發送地址


• 'value': '0x16345785d8a0000',//100000000000000000 ，10^17


• 'data': '0x', // 空數據的十進製表示


• 'chainId': 1 // 區塊鏈網路ID


• })


• .then(console.log)

可以使用在線使用程序Composer將已簽名的交易傳遞到以太坊網路。這種做法被稱為」離線簽名「。離線簽名對於諸如狀態通道之類的應用程序特別有用，這些通道是跟蹤兩個帳戶之間余額的智能合約，並且在提交已簽名的交易後就可以轉移資金。離線簽名也是去中心化交易所（DEXes）中的一種常見做法。

也可以使用在線錢包通過以太坊賬戶創建簽名驗證和廣播。

使用Portis，您可以簽署交易以與加油站網路（GSN）進行交互。

鏈喬教育在線旗下學碩創新區塊鏈技術工作站是中國教育部學校規劃建設發展中心開展的「智慧學習工場2020-學碩創新工作站 」唯一獲準的「區塊鏈技術專業」試點工作站。專業站立足為學生提供多樣化成長路徑，推進專業學位研究生產學研結合培養模式改革，構建應用型、復合型人才培養體系。

9. 以太坊event log查詢與解析

從 ethereum json-rpc文檔 的文檔中找到一個同時指定多個事件以 OR 或者 AND 查詢的方法.以下是查詢 Approval 或 Transfer 事件的方法：

topics 欄位中指定查詢條件的語法參考上面鏈接。

通過 getTransactionReceipt 在ropsten測試網上查詢到交易號為 的交易詳情

這個交易從 "from": "" 發送到合約地址 "to": "" .這個合約為ERC20代幣合約.從 topics 的第一個元素可以看出合約中產生了 Transfer 事件(topics第一個元素一定是事件的keccak哈希). topics 的第二個欄位是轉出代幣的地址，第三個欄位是接收者地址.ERC20代幣 Transfer 事件的簽名為

我們注意到 Transfer 事件的第一個和第二個參數被標記為 indexed , 因此他們的值被放在 topics array 中. 由於tokens參數沒有標記為 indexed , 所以他的值被放在 data 欄位. 如果事件中有多個欄位未標記為 indexed ， 那麼他們的值都會被記錄在 data 欄位中。

10. 以太坊開發(2):在以太坊私有鏈上的基本操作

在上一講 如何使用geth搭建以太坊私有鏈 完成了私有鏈的搭建，下面介紹在私有鏈上的基本操作。

啟動私有鏈後在命令行輸入：

執行完之後可以查看到生成的賬戶地址為

查詢賬戶余額：

剛剛創建的私有鏈賬戶都是沒有餘額的，需要通過挖礦才會產生eth，下面介紹如何在私有鏈上挖礦。

在geth環境下執行:

這時候查看日誌geth.log可以看到以太坊私有鏈有個啟動的百分比，到100就正式啟動了：

挖礦開始：

這時候有個疑問，挖礦挖到的eth到哪了，其實默認到了eth.account[0]，就是第一個賬戶上：

如何修改挖礦所得的賬戶：

命令如下：

下面開始進行轉賬：

這時候出現報錯，原因是轉賬的賬戶沒有解鎖，需要輸入密碼解鎖轉賬的賬戶才能完成轉賬操作：