以太坊中的交易树与收据树

1、定义：

• 交易树：每次发布区块时，区块中的交易会组织成一颗交易树。
• 收据树：每个交易执行完后，会形成一个收据，该收据中包含一个bloom filter，用来记录交易的相关信息。所以交易树与收据树节点是一一对应的。增加收据树是因为以太坊的智能合约执行过程比较复杂，所以收据树有利于快速查询执行结果。从数据结构上来说，交易树和收据树都是MPT。

2、交易树、收据树、状态树的区别：

交易树、收据树都是只组织当前发布的区块的交易，所以每个区块的交易树、收据树是独立的。

而状态树包含了系统中所有账户的状态，所以多个区块的状态树的共享节点的，每次新发布一个区块的时候，只有新发布的区块的交易改变了状态的节点需要新建一个分支，其他节点会沿用之前的节点。

这三棵树的根哈希值都保存在块头（block header）中。

3、交易树、收据树的作用：

提供Merkle Proof，要证明某个交易的执行结果，需要在收据树中提供一个Merkle Proof。

4、bloom filter

可以高效查找某个特定元素是否在一个比较大的集合中。

实现方法：

把一个大的集合计算出一个紧凑的摘要（digest），比如一个128位的向量。该向量初始值为0，然后将集合中的元素取哈希映射到向量中的对应位置，该位置的值置为1。得到的这个向量就是摘要，它比集合要小很多。

如果想要判断一个元素是否在集合中，则对该元素取哈希值，映射到集合中，如果集合中该位置为0，则元素不在这个集合中。如果集合中该位置为1，则无法判断该元素是否在集合中。因为存在哈希碰撞，集合中可能有另外一个元素也映射到这个位置。这也是简单的bloom filter不支持删除操作的原因。要想实现删除，需要计数器计算该位置有多少个元素映射，还要考虑到计数器会不会overflow，这种数据结构就会很复杂。

所以，对于bloom filter而言，存在false positive，在集合中的元素一定会判断在里面，不在集合中的元素也有可能判断在里面。

在以太坊中，发布的区块在块头中有一个总的bloom filter，是这个区块里所有交易的并集。

所以，如果要查找过去10天和这个只能合约相关的所有的交易，则先查找各个区块的块头的bloom filter是否存在所需的交易内容。如果块头的bloom filter中有需要查找的交易内容，再去查找区块里面的交易所对应的数据库里的bloom filter。

所以，通过bloom filter，可以快速过滤掉无关区块，提高查找效率。

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

以太坊的运行过程可以看作是交易驱动的状态机（transaction-driven state machine），通过执行交易，驱动系统从当前的状态转移到下一个状态。

以太坊和比特币一样，创建账户的时候不需要通知其他人，只有账户第一次收到钱的时候，其他节点才会知道该账户的存在。此时在状态树中新插入一个节点。

为什么状态树需要保存系统中所有账户的状态，可不可以只保存与当前交易相关的状态信息？

这样设计的话，每个区块没有一颗完整的状态树，不便于查找某个账户的状态。

比如A转给B10个以太币，则需要检查A中是否有10个以太币，那么A最近的区块可能没有A这个账户，则需要往前找，直到找到包含A这个账户的最近的区块，才能知道A账户的余额。所以如果A在很长时间没有进行交易，就需要找很多个区块才能找到A的区块状态。

还存在一个问题，A在给B转账的时候也需要知道B账户的状态，才能在B的账户上加10个以太币。如果B是新建的账户，则需要查找每个区块，一直找到创世纪块才会发现B账户是新建的。