『壹』 什麼是以太幣/以太坊ETH
以太幣（ETH）是以太坊（Ethereum）的一種數字代幣，被視為「比特幣2.0版」，採用與比特幣不同的區塊鏈技術「以太坊」（Ethereum），一個開源的有智能合約成果的民眾區塊鏈平台，由全球成千上萬的計算機構成的共鳴網路。開發者們需要支付以太幣（ETH）來支撐應用的運行。和其他數字貨幣一樣，以太幣可以在交易平台上進行買賣 。
溫馨提示：以上解釋僅供參考，不作任何建議。入市有風險，投資需謹慎。您在做任何投資之前，應確保自己完全明白該產品的投資性質和所涉及的風險，詳細了解和謹慎評估產品後，再自身判斷是否參與交易。
應答時間：2020-12-02，最新業務變化請以平安銀行官網公布為准。
[平安銀行我知道]想要知道更多？快來看「平安銀行我知道」吧~
https://b.pingan.com.cn/paim/iknow/index.html
『貳』 以太坊鏈上數據查詢工具： https://eth.tokenview.com/cn
etherscan.io目前在國內無法訪問，現在向大家推薦這個以太坊數據查詢工具， https://eth.tokenview.com/cn ，數據來自他們自己的以太坊節點，數據同步速度快。
四個優勢：
數據支持以太坊上的區塊信息，地址余額，轉賬交易，以太坊所有Token，基於以太坊發行的穩定幣。
鏈上存儲的數據（inputdata）可以解碼成普通語言，我們可以查看在以太坊上的留言。
幾十種鏈上數據圖表，同時有為高級數據分析師提供的Metrics模塊。
由中國團隊Tokenview開發，在國內可高速訪問。
『叄』 以太坊多節點私有鏈部署
假設兩台電腦A和B
要求：
1、兩台電腦要在一個網路中，能ping通
2、兩個節點使用相同的創世區塊文件
3、禁用ipc;同時使用參數--nodiscover
4、networkid要相同，埠號可以不同
1.4 搭建私有鏈
1.4.1 創建目錄和genesis.json文件
創建私有鏈根目錄./testnet
創建數據存儲目錄./testnet/data0
創建創世區塊配置文件./testnet/genesis.json
1.4.2 初始化操作
cd ./eth_test
geth --datadir data0 init genesis.json
1.4.3 啟動私有節點
1.4.4 創建賬號
personal.newAccount()
1.4.5 查看賬號
eth.accounts
1.4.6 查看賬號余額
eth.getBalance(eth.accounts[0])
1.4.7 啟動&停止挖礦
啟動挖礦：
miner.start(1)
其中 start 的參數表示挖礦使用的線程數。第一次啟動挖礦會先生成挖礦所需的 DAG 文件，這個過程有點慢，等進度達到 100% 後，就會開始挖礦，此時屏幕會被挖礦信息刷屏。
停止挖礦，在 console 中輸入：
miner.stop()
挖到一個區塊會獎勵5個以太幣，挖礦所得的獎勵會進入礦工的賬戶，這個賬戶叫做 coinbase，默認情況下 coinbase 是本地賬戶中的第一個賬戶，可以通過 miner.setEtherbase() 將其他賬戶設置成 coinbase。
1.4.8 轉賬
目前，賬戶 0 已經挖到了 3 個塊的獎勵，賬戶 1 的余額還是0：
我們要從賬戶 0 向賬戶 1 轉賬，所以要先解鎖賬戶 0，才能發起交易：
發送交易，賬戶 0 -> 賬戶 1：
需要輸入密碼 123456
此時如果沒有挖礦，用 txpool.status 命令可以看到本地交易池中有一個待確認的交易，可以使用 eth.getBlock("pending", true).transactions 查看當前待確認交易。
使用 miner.start() 命令開始挖礦：
miner.start(1);admin.sleepBlocks(1);miner.stop();
新區塊挖出後，挖礦結束，查看賬戶 1 的余額，已經收到了賬戶 0 的以太幣：
web3.fromWei(eth.getBalance(eth.accounts[1]),'ether')
用同樣的genesis.json初始化操作
cd ./eth_test
geth --datadir data1 init genesis.json
啟動私有節點一,修改 rpcport 和port
可以通過 admin.addPeer() 方法連接到其他節點，兩個節點要要指定相同的 chainID。
假設有兩個節點：節點一和節點二，chainID 都是 1024，通過下面的步驟就可以從節點二連接到節點一。
首先要知道節點一的 enode 信息，在節點一的 JavaScript console 中執行下面的命令查看 enode 信息：
admin.nodeInfo.enode
" enode://@[::]:30303 "
然後在節點二的 JavaScript console 中執行 admin.addPeer()，就可以連接到節點一：
addPeer() 的參數就是節點一的 enode 信息，注意要把 enode 中的 [::] 替換成節點一的 IP 地址。連接成功後，節點一就會開始同步節點二的區塊，同步完成後，任意一個節點開始挖礦，另一個節點會自動同步區塊，向任意一個節點發送交易，另一個節點也會收到該筆交易。
通過 admin.peers 可以查看連接到的其他節點信息，通過 net.peerCount 可以查看已連接到的節點數量。
除了上面的方法，也可以在啟動節點的時候指定 --bootnodes 選項連接到其他節點。 bootnode 是一個輕量級的引導節點，方便聯盟鏈的搭建 下一節講 通過 bootnode 自動找到節點
參考： https://cloud.tencent.com/developer/article/1332424
『肆』 以太坊源碼分析--p2p節點發現
節點發現功能主要涉及 Server Table udp 這幾個數據結構，它們有獨自的事件響應循環，節點發現功能便是它們互相協作完成的。其中，每個以太坊客戶端啟動後都會在本地運行一個 Server ，並將網路拓撲中相鄰的節點視為 Node ，而 Table 是 Node 的容器， udp 則是負責維持底層的連接。下面重點描述它們中重要的欄位和事件循環處理的關鍵部分。
PrivateKey - 本節點的私鑰，用於與其他節點建立時的握手協商
Protocols - 支持的所有上層協議
StaticNodes - 預設的靜態 Peer ，節點啟動時會首先去向它們發起連接，建立鄰居關系
newTransport - 下層傳輸層實現，定義握手過程中的數據加密解密方式，默認的傳輸層實現是用 newRLPX() 創建的 rlpx ，這不是本文的重點
ntab - 典型實現是 Table ，所有 peer 以 Node 的形式存放在 Table
ourHandshake - 與其他節點建立連接時的握手信息，包含本地節點的版本號以及支持的上層協議
addpeer － 連接握手完成後，連接過程通過這個通道通知 Server
Server 的監聽循環，啟動底層監聽socket，當收到連接請求時，Accept後調用 setupConn() 開始連接建立過程
Server的主要事件處理和功能實現循環
Node 唯一表示網路上的一個節點
IP - IP地址
UDP/TCP - 連接使用的UDP/TCP埠號
ID - 以太坊網路中唯一標識一個節點，本質上是一個橢圓曲線公鑰(PublicKey)，與 Server 的 PrivateKey 對應。一個節點的IP地址不一定是固定的，但ID是唯一的。
sha - 用於節點間的距離計算
Table 主要用來管理與本節點與其他節點的連接的建立更新刪除
bucket - 所有 peer 按與本節點的距離遠近放在不同的桶(bucket)中，詳見之後的 節點維護
refreshReq - 更新 Table 請求通道
Table 的主要事件循環，主要負責控制 refresh 和 revalidate 過程。
refresh.C - 定時(30s)啟動Peer刷新過程的定時器
refreshReq - 接收其他線程投遞到 Table 的 刷新Peer連接 的通知，當收到該通知時啟動更新，詳見之後的 更新鄰居關系
revalidate.C - 定時重新檢查以連接節點的有效性的定時器，詳見之後的 探活檢測
udp 負責節點間通信的底層消息控制，是 Table 運行的 Kademlia 協議的底層組件
conn - 底層監聽埠的連接
addpending － udp 用來接收 pending 的channel。使用場景為：當我們向其他節點發送數據包後(packet)後可能會期待收到它的回復，pending用來記錄一次這種還沒有到來的回復。舉個例子，當我們發送ping包時，總是期待對方回復pong包。這時就可以將構造一個pending結構，其中包含期待接收的pong包的信息以及對應的callback函數，將這個pengding投遞到udp的這個channel。 udp 在收到匹配的pong後，執行預設的callback。
gotreply - udp 用來接收其他節點回復的通道，配合上面的addpending，收到回復後，遍歷已有的pending鏈表，看是否有匹配的pending。
Table - 和 Server 中的ntab是同一個 Table
udp 的處理循環，負責控制消息的向上遞交和收發控制
udp 的底層接受數據包循環，負責接收其他節點的 packet
以太坊使用 Kademlia 分布式路由存儲協議來進行網路拓撲維護，了解該協議建議先閱讀 易懂分布式 。更權威的資料可以查看 wiki 。總的來說該協議：
源碼中由 Table 結構保存所有 bucket ， bucket 結構如下
節點可以在 entries 和 replacements 互相轉化，一個 entries 節點如果 Validate 失敗，那麼它會被原本將一個原本在 replacements 數組的節點替換。
有效性檢測就是利用 ping 消息進行探活操作。 Table.loop() 啟動了一個定時器（0~10s），定期隨機選擇一個bucket，向其 entries 中末尾的節點發送 ping 消息，如果對方回應了 pong ，則探活成功。
Table.loop() 會定期（定時器超時）或不定期（收到refreshReq）地進行更新鄰居關系（發現新鄰居），兩者都調用 doRefresh() 方法，該方法對在網路上查找離自身和三個隨機節點最近的若干個節點。
Table 的 lookup() 方法用來實現節點查找目標節點，它的實現就是 Kademlia 協議，通過節點間的接力，一步一步接近目標。
當一個節點啟動後，它會首先向配置的靜態節點發起連接，發起連接的過程稱為 Dial ，源碼中通過創建 dialTask 跟蹤這個過程
dialTask表示一次向其他節點主動發起連接的任務
在 Server 啟動時，會調用 newDialState() 根據預配置的 StaticNodes 初始化一批 dialTask ， 並在 Server.run() 方法中，啟動這些這些任務。
Dial 過程需要知道目標節點( dest )的IP地址，如果不知道的話，就要先使用 recolve() 解析出目標的IP地址，怎麼解析？就是先要用藉助 Kademlia 協議在網路中查找目標節點。
當得到目標節點的IP後，下一步便是建立連接，這是通過 dialTask.dial() 建立連接
連接建立的握手過程分為兩個階段，在在 SetupConn() 中實現
第一階段為 ECDH密鑰建立 ：
第二階段為協議握手,互相交換支持的上層協議
如果兩次握手都通過，dialTask將向 Server 的 addpeer 通道發送 peer 的信息
『伍』 metamask使用哪個以太坊節點
metamask使用rpcurl以太坊節點。根據查詢相關的公開信息，當用戶連接到自定義MetaMask網路時，MetaMask將與RPCURL中的以太坊節點通信，並使用它發送交易、從區塊鏈讀取數據以及與智能合約交互。
『陸』 以太坊節點一天分紅多少
以太坊節點一天分紅現在約60美元左右。節點收益根據節點數量靈活變通，並不是永恆不變的，當前以太坊價格1300美元左右，節點分紅一天60美元左右。
『柒』 2022以太坊節點數量
2022以太坊節點數量是2000多點。根據查詢相關公開信息顯示，截止於2022年11月30日，2022以太坊節點數量達到了2000多點，數量非常的穩定龐大，能夠體現出目前以太幣的強勢和利好，非常適合投資。以太坊是一個開源的有智能合約功能的公共區塊鏈平台，通過其專用加密貨幣以太幣提供去中心化的以太虛擬機來處理點對點合約。
『捌』 以太坊解讀——Recursive Length Prefix協議圖解(上)
在以太坊中，採用了一種名為Recursive Length Prefix(RLP)的方法對交易、賬號、合約等基礎的數據結構進行序列化處理，從而實現對鏈上數據的網路傳輸和持久化存儲。RLP作為最為底層的編碼方法，其重要性是不言而喻。因此，網上介紹RLP的文章也不少，但是由於RLP是二進制編碼，又涉及到嵌套結構，造成編碼過程的可讀性較差，在學習中過程中，也一直沒有找到完整的、易於理解的說明，總是繞在各種規則之中，且不能"自拔"，著實有點無奈。所以，在本文中，採用圖形化的解釋和舉例的方法，幫助大家理解RLP嵌套等特點、編解碼過程等。
和其他的序列化協議不同，RLP只支持兩種數據類型：
1）byte數組，可以是二進制數組，當然也可以是字元串；
2）byte數組的數組，也就是列表。並支持列表內的嵌套。
對於其他的數據類型，RLP都不支持，需要用戶自己先轉化為數組和列表的類型。
從RLP的命名中就可以看出兩個關鍵字：一個是遞歸Recursive和前綴Prefix。首先，關於遞歸，也就是嵌套結構，結構上非常接近「樹」，在Ethereum WiKi中，更是直接地採用樹的items來進行命名，葉子節點(leaf tress)來存儲「byte數組」，嵌套的節點就是一個樹的分叉(branching trees)。
比如，需要是對如下對象進行RLP的編碼，該對象中包含一個字元數組的列表、一個單個字元的字元數組、一個空字元數組。
< <[cat],[dog]>, [0xbf], [] >
將該對象展開為樹的結構，就如下圖。其中[0xbf]和[]屬於字元數組。<[cat], [dog]>屬於列表，可以嵌套展開，再根據各個節點，進行編碼。然後，對於不同長度的數組和列表，編碼的方法略有不同，這個也就是Length Prefix相關的內容，和「編碼過程」相關的內容，在第二節進行詳細地說明。
關於為什麼以太坊需要單獨設計一種序列化協議，目前還沒有找到官方的描述。但與其他序列化方法相比，RLP協議具有一些直接的優點，比如：
1）在以太坊中，最小貨幣單位為1 Wei，並且1 ETH = 10^18 Wei，所以在編碼中，需要考慮對很大的整數類型的序列化，在RLP中採用去除前導零(leading zero)的大端big-endian方式，可以有效處理大整數；
2）使用了靈活的長度前綴來表示數據的實際長度，並且使用遞歸的方式能編碼相當大的數據；
3）為了實現在鏈上節點的「共識Consensus」，防止出現數據的不一致，以太坊中並不支持浮點數類型，所以一般的序列化協議也不適用。
編碼的過程就是將嵌套結構(nested sequence)的樹形結構，添加長度前綴(Length Prefix)後，轉化為順序結構(flat sequence)的過程。添加長度前綴的目的，就是在反序列化時，可以根據長度前綴(Length Prefix)，將(flat sequence)重構出樹的結構(nested sequence)。
關於前綴的生成規則，《Ethereum Yellow Paper》[2]給出了非常形式化的數學符號描述，漂亮是非常漂亮，可惜不是人類的語言，非常難於理解和表達。網上大部分文章的寫法也是引用了Yellow Paper中的5個文字形式上的描述，把原文和翻譯一並給出如下：
將上面這個「長度」Length Prefix的編碼規則，通過「決策樹」可以圖形化的表達如下圖。
首先，根據編碼的類型，進行分類，分為「位元組數組」和「列表」兩類；第二，根據不同的長度，編碼的長度前綴不同。若待編碼對象的長度小於56，就是把長度和「前綴字元」進行求和，佔用一個位元組。反之，待編碼對象的長度大於56，其前綴需要多個位元組，第一個位元組，求出「長度」所佔的位元組數，再加上「前綴字元」，比如：長度為56，佔用1位元組。然後對「長度」進行編碼，其實也是一個嵌套的過程。
還是以上文中的例子，該編碼對象，已經完成了「樹的構建」，然後根據「長度前綴」的原則，對樹的各個項目進行長度前綴的計算。
< <[cat],[dog]>, [0xbf], [] >
-對於<[cat],[dog]>屬於嵌套數組，需要對內部各項非常進行長度編碼的計算
`對於[cat]，屬於字元數組，且長度為3，其對應的長度為0x80+3 = 0x83
`對於[dog]，屬於字元數組，且長度為3，其對應的長度為0x80+3 = 0x83
`<[cat],[dog]>整體上，其長度前綴為0xc0 + 2(新增的兩個子項的長度所佔用的位元組)+6(待編碼字元的長度)=0xC8
- 對於[0xbf], 屬於字元數組，且長度為1，其對應的長度為0x80+1 = 0x81
- 對於[dog]，屬於字元數組，且長度為3，其對應的長度為0x80+3 = 0x83
- 對於[]，屬於字元數組，且長度為0，其對應的長度為0x80+0=0x80
總體上，增加的「長度編碼」的位元組數為6，加上原來的長度為10，所以整個對象的長度前綴為0xC0+16d=0xD0。所以最後的編碼結果為：
D0 C8 83636174 83646F67 81B7 83646F67 80
解碼過程將在 《以太坊解讀——Recursive Length Prefix協議圖解(下)》 一文中，給出圖形化的解讀說明。
『玖』 走進以太坊網路
目錄
術語「以太坊節點」是指以某種方式與以太坊網路交互的程序。從簡單的手機錢包應用程序到存儲整個區塊鏈副本的計算機，任何設備均可扮演以太坊節點。
所有節點都以某種方式充當通信點，但以太坊網路中的節點分為多種類型。
與比特幣不同，以太坊找不到任何程序作為參考實施方案。在比特幣生態系統中， 比特幣核心 是主要節點軟體，以太坊黃皮書則提出了一系列獨立（但兼容）的程序。目前最流行的是Geth和Parity。
若要以允許獨立驗證區塊鏈數據的方式連接以太坊網路，則應使用之前提到的軟體運行全節點。
該軟體將從其他節點下載區塊，並驗證其所含交易的正確性。軟體還將運行調用的所有智能合約，確保接收的信息與其他節點相同。如果一切按計劃運行，我們可以認為所有節點設備均存儲相同的區塊鏈副本。
全節點對於以太坊的運行至關重要。如果沒有遍布全球的眾多節點，網路將喪失其抗審查性與去中心化特性。
通過運行全節點，您可以直接為網路的 健康 和安全發展貢獻一份力量。然而，全節點通常需要使用獨立的機器完成運行和維護。對於無法（或單純不願）運行全節點的用戶，輕節點是更好的選擇。
顧名思義，輕節點均為輕量級設備，可顯著降低資源和空間佔用率。手機或筆記本電腦等攜帶型設備均可作為輕節點。然而，降低開銷也要付出代價：輕節點無法完全實現自給自足。它們無法與整條區塊鏈同步，需要全節點提供相關信息。
輕節點備受商戶、服務供應商和用戶的青睞。在不必使用全節點並且運行成本過高的情況下，它們廣泛應用於支收付款。
挖礦節點既可以是全節點客戶端，也可以是輕節點客戶端。「挖礦節點」這個術語的使用方式與比特幣生態系統不同，但依然應用於識別參與者。
如需參與以太坊挖礦，必須使用一些附加硬體。最常見的做法是構建 礦機 。用戶通過礦機將多個GPU（圖形處理器）連接起來，高速計算哈希數據。
礦工可以選擇兩種挖礦方案：單獨挖礦或加入礦池。 單獨挖礦 表示礦工獨自創建區塊。如果成功，則獨享挖礦獎勵。如果加入 礦池 ，眾多礦工的哈希算力會結合起來。出塊速度得以提升，但挖礦獎勵將由眾多礦工共享。
區塊鏈最重要的特性之一就是「開放訪問」。這表明任何人均可運行以太坊節點，並通過驗證交易和區塊強化網路。
與比特幣相似，許多企業都提供即插即用的以太坊節點。如果只想啟動並運行單一節點，這種設備無疑是最佳選擇，缺點是必須為便捷性額外付費。
如前文所述，以太坊中存在眾多不同類型的節點軟體實施方案，例如Geth和Parity。若要運行個人節點，必須掌握所選實施方案的安裝流程。
除非運行名為 歸檔節點 的特殊節點，否則消費級筆記本電腦足以支持以太坊全節點正常運行。不過，最好不要使用日常工作設備，因為節點會嚴重拖慢運行速度。
運行個人節點時，建議設備始終在線。倘若節點離線，再次聯網時可能耗費大量的時間進行同步。因此，最好選擇造價低廉並且易於維護的設備。您甚至可以通過Raspberry Pi運行輕節點。
隨著網路即將過渡到權益證明機制，以太坊挖礦不再是最安全的長期投資方式。過渡成功後，以太坊礦工只能將挖礦設備轉入其他網路或直接變賣。
鑒於過渡尚未完成，參與以太坊挖礦仍需使用特殊硬體（例如GPU或ASIC）。若要獲得可觀收益，則必須定製礦機並尋找電價低廉的礦場。此外，還需創建以太坊錢包並配置相應的挖礦軟體。這一切都會耗費大量的時間和資金。在參與挖礦前，請認真考量自己能否應對各種挑戰。（國內嚴禁挖礦，切勿以身試法）
ProgPow代表 程序化工作量證明 。這是以太坊挖礦演算法Ethash的擴展方案，旨在提升GPU的競爭力，使其超過ASIC。
在比特幣和以太坊社區，抗ASIC多年來一直是飽受爭議的話題。在比特幣網路中，ASIC已經成為主要的挖礦力量。
在以太坊中，ASIC並不是主流，相當一部分礦工仍然使用GPU。然而，隨著越來越多的公司將以太坊ASIC礦機引入市場，這種情況很快就會改變。然而，ASIC到底存在什麼問題呢？
一方面，ASIC明顯削弱網路的去中心化。如果GPU礦工無法盈利，不得不停止挖礦，哈希率最終就會集中在少數礦工手中。此外，ASIC晶元的開發成本相當昂貴，坐擁開發能力與資源的公司屈指可數。這種現狀有可能導致以太坊挖礦產業集中在少數公司手中，形成一定程度的行業壟斷。
自2018年以來，ProgPow的集成一直飽受爭議。有些人認為，它有益於以太坊生態系統的 健康 發展。另一些人則持反對態度，認為它可能導致硬分叉。隨著權益證明機制的到來，ProgPoW能否應用於網路仍然有待觀察。
以太坊與比特幣是一樣，均為開源平台。所有人都可以參與協議開發，或基於協議構建應用程序。事實上，以太坊也是區塊鏈領域目前最大的開發者社區。
Andreas Antonopoulos和Gavin Wood出品的 Mastering Ethereum ，以及Ethereum.org推出的 開發者資源 等都是新晉開發者理想的入門之選。
智能合約的概念於20世紀90年代首次提出。其在區塊鏈中的應用帶來了一系列全新挑戰。2014年由Gavin Wood提出的Solidity已經成為開發以太坊智能合約的主要編程語言，其語法與Java、JavaScript以及C++類似。
從本質上講，使用Solidity語言，開發者可以編寫在分解後可由以太坊虛擬機(EVM)解析的指令。您可以通過Solidity GitHub詳細了解其工作原理。
其實，Solidity語言並非以太坊開發者的唯一選擇。Vyper也是一種熱門的開發語言，其語法更接近Python。
『拾』 以太坊技術系列-以太坊數據結構
本篇文章和大家介紹一下以太坊的數據結構，上篇文章我們提到，以太坊為了實現智能合約這一功能，使用了基於賬戶的模型。我們來看看以太坊中數據結構。
既然是基於賬戶的模型，我們需要通過賬戶地址找到賬戶的狀態。就像通過銀行卡號可以找到你在銀行中的各種信息一樣。最簡單的想法當然是一個簡單的哈希表 key是賬戶地址 value是賬戶狀態。但這里有個問題解決不了。
輕節點如何校驗賬戶合法性？
上篇我們說過，區塊鏈中有2類節點，全節點和輕節點，輕節點只會存儲block header，所以輕節點如何才能校驗賬號是否合法呢？
這個思路和我們平時用的md5校驗一致，我們會對區塊內的信息進行hash運算從而得出區塊內信息唯一確定的值，區塊鏈所有節點中這個值都是相同的。
在這個過程中我們用到了一種數據結構Merkle Tree（哈希樹），我們先看下Merkle Tree（哈希樹）的示意圖。
上篇文章說到區塊鏈中的鏈表(哈希鏈)和我們平時常見鏈表不同的是將指針從地址改為了hash指，這里也一樣，哈希樹和二叉樹的區別有2個
1.將地址改為了哈希值
2.只有葉子節點存儲數據
回到之前的問題輕節點是如何校驗1個賬戶或交易是否是在鏈上的呢？
整個流程如上圖所示
1.輕節點需要判斷1個賬號是否合法
2.輕節點由於只存儲block header，所以拿到1個賬號的時候會向全節點發出請求
3.全節點存儲了所有賬戶狀態，將賬戶路徑中的需要計算用到的hash值返回給輕節點
4.輕節點本地進行計算根hash值，如果計算結果和自己存儲一致則賬戶合法，不一致則不合法。
那以太坊中的賬戶信息的數據結構就是這樣嗎？
直接用這樣的數據結構來存儲賬戶信息會有2個問題
查找困難
生成hash值不確定
第1個問題應該比較容易發現，在這個樹中尋找1個賬號需要的復雜度是O(n),因為沒有任何順序。
第2個問題其實也是因為無序導致的，無序的組合每個節點針對同一批賬戶生成的hash值不一致，這就導致無法達成共識。
既然2個問題都和順序有關，那我們類似二叉排序樹一樣，使用哈希排序樹是不是就可以解決問題了呢？
使用排序樹後會帶來另外1個問題
插入困難
因為要維持樹是有序的，很可能帶來樹結構的很大變動。
以太坊中使用了另外一種數據結構字典樹。和哈希樹不同，字典樹應該是很多地方都有使用。我們簡單來看下字典樹的結構。
字典樹能夠較好地解決哈希樹的2個缺點1.查找困難 2.生成的hash值不確定以及排序二叉樹的1個缺點 插入困難。
但字典樹我們可以看到可能樹的深度可能由於部分元素導致整棵樹深度非常深。
這時我們可以進一步優化，將相同路徑進行壓縮。這就是壓縮字典樹。
將哈希樹和壓縮字典樹結合，就可以得到以太坊存儲賬戶的最終數據結構-MPT。
將壓縮字典樹裡面的指針從地址改為指針，並且將數據存儲在葉子節點中即可。
介紹完狀態樹的數據結構，我們接下來討論1個問題，區塊中存儲的賬戶狀態是什麼樣的范圍。有2種選擇。
只保存當時區塊中產生交易的賬戶狀態。
保存全局所有的賬戶。
我們可以看下這2種方式，無非就是空間和時間的平衡，只保存當前區塊產生的交易意味著是做懶載入(需要的時候才去尋找賬戶)，在區塊鏈中這個代價是非常大的，因為尋找的賬戶之前從未交易過，這樣會遍歷整個區塊鏈。另外一種保存全局的賬戶方式雖然看起來空間消耗較大，但查找快捷，而且空間的問題我們可以通過其他方式優化。所以最終以太坊選擇了第2種每個區塊都報錯全局所有賬戶的方式。
我們來看下以太坊中是如何保存狀態樹的。
可以看到以太坊中雖然每個區塊都保存了全部賬戶，但是會將未發生變化的賬戶狀態指向前1個節點，本身只存儲發生變化的狀態，這樣可以較大程度優化空間佔用。
介紹完以太坊中比較復雜的狀態樹後，我們繼續來看看以太坊中的另外兩棵樹，交易樹和收據樹。
首先介紹一下，為什麼需要交易樹&收據樹。
1.交易樹
雖然以太坊是基於賬戶的模型，但是就像銀行不僅會存儲銀行卡的余額，還會存儲卡中的每筆錢怎麼來的以及怎麼花的。交易樹中就存儲著當前區塊中的包含的所有交易。
2.收據樹
由於智能合約的引入增加了不少復雜性，所以以太坊用收據樹存儲著一些交易操作的額外信息。比如交易過程中執行日誌就包含在收據樹中方便查詢。收據樹和交易樹是一一對應的。每發生一次交易就會有一次收據。
和狀態樹不同交易樹和收據樹只維護當前區塊內發生的交易，因為當時區塊發生交易時不需要再去查找另外1個交易，也就之前需要可能遍歷整個區塊鏈的查找操作了。
由於以太坊中的出塊速度較快，我們進行一些查詢一些符合條件交易的時候會面臨大量數據遍歷困難的問題。收據樹中引入了布隆過濾器可以幫助我們有效緩解這一困難。
布隆過濾器將大集合中每個元素進行hash運算映射到1個較小的集合，這時再來1個元素要判斷是否在大集合的時候，不需要遍歷整個大集合，而是去進行hash運算去小集合中尋找是否存在，如果不存在，肯定不在大集合中，如果存在則不能說明任何問題。
如上圖所示，布隆過濾器只能證明某1個元素不在集合中，不能證明1個元素在結合中。
以太坊中如果我們要在較多區塊中尋找某1個交易，則可以利用布隆過濾器，過濾掉肯定不存在目標交易的區塊，然後進入收據樹內繼續利用布隆過濾器篩選，剩下的才是可能的目標交易的交易，進行一一比對即可。
我們介紹了以太坊的核心數據結構，狀態樹&交易樹&收據樹，他們都是使用相同的數據結構-哈希壓縮字典樹。但狀態樹是維護1顆全局賬戶樹，交易樹和收據樹則是維護本區塊內的交易或收據。
介紹完數據結構後，後面我們會用幾篇文章來介紹以太坊中的一些核心演算法，比如共識機制，挖礦演算法等。