聲明：本文是要點筆記，介紹和系列筆記均收錄在專題：區塊鏈技術與應用
每次發佈一個區塊時，區塊中的交易會形成一顆 Merkle Tree，即交易樹。此外，以太坊還添加了一個收據樹，每個交易執行完之後形成一個收據，記錄交易相關信息。也就是說，交易樹和收據樹上的節點是一一對應的。
由於以太坊智能合約執行較爲複雜，通過增加收據樹，便於快速查詢執行結果。
交易樹和收據樹都是M(Merkle)PT，而 BTC 中都採用普通的MT(Merkle Tree)。（可能就僅僅是爲了三棵樹代碼複用好所以這樣設計的）
MPT的好處是支持查找操作，通過鍵值沿着樹進行查找即可。對於狀態樹，查找鍵值爲賬戶地址；對於交易樹和收據樹，查找鍵值爲交易在發佈的區塊中的序號。
交易樹和收據樹只將當前區塊中的交易組織起來，而狀態樹將所有賬戶的狀態都包含進去，無論這些賬戶是否與當前區塊中交易有關係。
多個區塊狀態樹共享節點，而交易樹和收據樹依照區塊獨立。
交易樹和收據樹的用途：
- 向輕節點提供Merkle Proof。
- 更加複雜的查找操作(例如：查找過去十天的交易；過去十天的衆籌事件等)
Bloom filter(布隆過濾器)
支持較爲高效查找某個元素是否在某個集合中
- 最笨：元素遍歷，複雜度爲O(n)——輕節點不能用
- 方法：給一個大的集合，計算出一個緊湊的“摘要”，
如下圖，給定一個數據集，其中含義元素a、b、c，通過一個哈希函數 H() 對其進行計算，將其映射到一個其初始全爲 0 的 128 位的向量的某個位置，將該位置置爲 1。將所有元素處理完，就可以得到一個向量，則稱該向量爲原集合的“摘要”。可見該“摘要”比原集合是要小很多的。
假定想要查詢一個元素 d 是否在集合中，假設 H(d) 映射到向量中的位置處爲 0，說明 d 一定不在集合中；假設 H(d) 映射到向量中的位置處爲 1，有可能集合中確實有d，也有可能因爲哈希碰撞產生誤報。
Bloom filter特點：有可能出現誤報，但不會出現漏報。
Bloom filter變種：採用一組哈希函數進行向量映射，有效避免哈希碰撞。
如果集合中刪除元素該怎麼操作？
無法操作。也就是說，簡單的Bloom filter不支持刪除操作。如果想要支持刪除操作，需要將記錄數不能爲0和1，需要修改爲一個計數器(需要考慮計數器是否會溢出)。
以太坊中Bloom filter的作用
每個交易完成後會產生一個收據，收據包含一個Bloom filter記錄交易類型、地址等信息。在區塊block header中也包含一個Bloom filter，其爲該區塊中所有交易的Bloom filter的一個並集。
所以，查找時候先查找塊頭中的Bloom filter，如果塊頭中包含。再查看區塊中包含的交易的Bloom filter，如果存在，再查看交易進行確認；如果不存在，則說明發生了“碰撞”。
好處是通過Bloom filter這樣一個結構，快速大量過濾掉大量無關區塊，從而提高了查找效率。
補充
以太坊的運行過程，可以視爲交易驅動的狀態機，通過執行當前區塊中包含的交易，驅動系統從當前狀態轉移到下一狀態。當然，BTC我們也可以視爲交易驅動的狀態機，其狀態爲UTXO。
對於給定的當前狀態和給定一組交易，可以確定性的轉移到下一狀態(保證系統一致性)。
問題1：A轉賬到B，有沒有可能收款賬戶不包含再狀態樹中？
可能。因爲以太坊中賬戶可以節點自己產生，只有在產生交易時纔會被系統知道。
問題2：可否將每個區塊中狀態樹更改爲只包含和區塊中交易相關的賬戶狀態？(大幅削減狀態樹大小，且和交易樹、收據樹保持一致)
不能。首先，這樣設計要查找賬戶狀態很不方便，因爲不存在某個區塊包含所有狀態。其次，如果要向一個新創建賬戶轉賬，因爲需要知道收款賬戶的狀態，才能給其添加金額，但由於其是新創建的賬戶，所有需要一直找到創世紀塊才能知道該賬戶爲新建賬戶，系統中並未存儲，而區塊鏈是不斷延長的。