ETH-17交易树和收据树

内容整理自 北京大学肖臻老师《区块链技术与应用》公开课 ETH-17交易树和收据树

每次发布一个区块，区块中所包含的交易会组织成一棵交易树。每个交易执行完之后会形成一个收据，记录交易的相关信息，交易树与收据树上的节点是一一对应的。增加收据树是考虑到以太坊的智能合约执行过程比较复杂，所以通过增加收据树的结构有利于快速查询一些执行结果。交易树和收据树都是MPT，比特币中的交易树是普通的merkle tree。 

三棵树有一个重要的区别

交易树和收据树都是只把当前发布的区块里的交易组织起来的。而状态树是把系统中所有账户的状态都要包含进去，不管这些账户和当前这些交易有没有关系。
多个区块的状态树是共享节点的，每次新发布一个区块的时候，只有区块中的交易改变了状态的节点需要新建分支，其他节点沿用原状态树的节点。相比之下，每个区块的交易树和收据树都是独立的，不会共享节点。

交易树和收据树的作用

1.提供merkle proof，证明某个交易的执行结果
2.支持更复杂的查询操作，比如想找到过去十天中和某个智能合约有关的交易，一种做法是把过去十天产生的所有区块都扫描一遍，看其中哪些交易是和智能合约相关。该方法复杂度高，而且对于轻节点来说，没有交易列表，没办法通过扫描所有交易列表的方法来找到符合条件的交易。还有就是查找过去十天符合某种类型的交易事件（如众筹事件，发行新币事件），这些需要高效的方法才能支持。
而以太坊中引用了bloom filter数据结构，该数据结构支持比较高效的查找某个元素是否在一个比较大的集合中。比如一个集合中有很多元素，想知道某个指定元素是否在集合中。bloom filter给包含很多元素的集合计算出一个紧凑的摘要，比如一个128bits的向量，向量初始的时候都是0，有一个哈希函数H，把每个元素映射到向量中的某个位置，该位置的元素就从0变成1。等到所有元素都处理完，得到的向量就是原集合的一个摘要，该摘要比集合小很多。
如果要判断一个元素是否在集合中，集合本身可能不被保存，用哈希函数对元素取哈希值，如果取完之后发现映射到一个0的位置，说明该元素一定不在集合中，如果映射到一个1的位置，该元素可能在集合中，也可能不在集合中，出现了哈希碰撞。bloom filter可能会出现false positive，但不会出现false negative。可能会误报，但不会漏报。另外bloom filter不支持删除操作。
每个交易执行完之后会形成一个收据，收据里面包含一个bloom filter，记录交易的类型，地址等信息，发布的区块在块头中有一个总的bloom filter，是区块里所有bloom filter的一个并集。所以如果要找到过去十天中和某个智能合约有关的交易，先查哪个区块的块头里的bloom filter有我要的交易的类型。如果块头里没有，那么这个区块就不是我们要找的。如果块头的bloom filter里有的话，再去查找区块里面包含的交易所对应的收据树里面的那些bloom filter，看看哪个有，也可能都没有，因为false positive，如果有再找到对应的交易确认。这样的好处是通过bloom filter的结构，能够快速过滤掉大量无关的区块。

交易驱动的状态机

以太坊的运行过程可以看作是一个交易驱动的状态机transaction-driven state machine，状态机的状态就是所有账户的状态（状态树包含的内容），交易是每次发布的区块里包含的交易，通过执行这些交易会驱动系统从当前的状态转移到下一个状态。

比特币也可以认为是一个交易驱动的状态机，比特币中状态是UTXO，每次新发布一个区块，会从UTXO中用掉一些输出，又会增加一些新的输出，所以发布的区块会驱动状态机从当前状态转移到下一个状态。

两个状态机一个共同点就是状态转移都必须是确定性的，对一个给定的当前状态，一组给定的交易，能够确定性的转移到下一个状态，因为所有的全节点、矿工都要执行同样的状态转移。