以太坊的交易树和收据树

交易树和收据树

 

每次发布一个区块时，区块中的交易会形成一颗交易树。此外，以太坊还添加了一个收据树，每个交易执行完之后形成一个收据，记录交易相关信息。也就是说，交易树和收据树上的节点是一一对应的。

为什么要增加收据树？

由于以太坊智能合约执行较为复杂，通过增加收据树，便于快速查询执行结果。

---

交易树和收据树都是M(Merkle)PT，而BTC中都采用普通的MT(Merkle Tree)。（以太坊为啥不用Merkle Tree，肖老师认为可能就仅仅是为了以太坊的三棵树代码统一好所以这样设计的）
MPT的好处是支持查找操作，通过键值沿着树进行查找即可。对于状态树，查找键值为账户地址；对于交易树和收据树，查找键值为交易在发布的区块中的序号。

交易树和收据树的用途：

1.向轻节点提供Merkle Proof。

2.更加复杂的查找操作(例如：查找过去十天的交易；过去十天的众筹事件等)。

Bloom filter(布隆过滤器)

Bloom filter支持比较高效的查找某个元素是否在某个集合中。

如果不用Bloom filter，最原始的方法是全部遍历一遍，O(n)的复杂度，且轻节点没有足够的空间存储所有元素，也没有全部的交易列表，所以暴力遍历的方法轻节点是用不了的！

Bloom filter的查找思想

如下图，给定一个数据集，其中含义元素a、b、c，通过一个哈希函数H()对其进行计算，将其映射到一个其初始全为0的128位的向量的某个位置，将该位置置为1。将所有元素处理完，就可以得到一个向量，则称该向量为原集合的“摘要”。可见该“摘要”比原集合是要小很多的。
假定想要查询一个元素d是否在集合中，假设H(d)映射到向量中的位置处为0，说明d一定不在集合中；假设H(d)映射到向量中的位置处为1，有可能集合中确实有d，也有可能因为哈希碰撞产生误报。

false positive

利用 Bloom filter有一个特点就是，该在集合里的元素，一定会在能播报正确，不在集合里的元素有可能也被播报成在集合里。

由此 Bloom filter会有一些变种用法，比如在映射哈希的时候，采用一组哈希函数进行向量映射，有效避免哈希碰撞。

如果集合中要删除一个元素要怎么做？

若想用 Bloom filter的话，就不好做了。如果你只是简单的把1改成0，其实你没办法判定这个操作改的是你需要改的1，还是哈希碰撞造成的1。如果想要支持删除操作，需要将记录数不能为0和1，需要修改为一个计数器(需要考虑计数器是否会溢出)。

以太坊中Bloom filter的作用

每个交易完成后会产生一个收据，收据包含一个Bloom filter记录交易类型、地址等信息。在区块block header中也包含一个Bloom filter，其为该区块中所有交易的Bloom filter的一个并集。
所以，查找时候先查找块头中的Bloom filter，如果块头中包含。再查看区块中包含的交易的Bloom filter，如果存在，再查看交易进行确认；如果不存在，则说明发生了“碰撞”。
好处是通过Bloom filter这样一个结构，比如你是一个轻节点，那么你可以利用块头就快速大量过滤掉大量无关区块，从而提高了查找效率，接着再去问全节点要进一步的信息。

总结

以太坊的运行过程，可以视为交易驱动的状态机，通过执行当前区块中包含的交易，驱动系统从当前状态转移到下一状态。当然，BTC我们也可以视为交易驱动的状态机，其状态为UTXO。
对于给定的当前状态和给定一组交易，可以确定性的转移到下一状态(保证系统一致性)。

A转账到B，有没有可能收款账户不包含再状态树中？
可能。因为以太坊中账户可以节点自己产生，只有在产生交易时才会被系统知道。
可否将每个区块中状态树更改为只包含和区块中交易相关的账户状态？(大幅削减状态树大小，且和交易树、收据树保持一致)
不能。首先，这样设计要查找账户状态很不方便，因为不存在某个区块包含所有状态，你需要逐个向前一个区块遍历是否包含你需要的账户的上一个状态。

最麻烦的情况是如果要向一个新创建账户转账，因为需要知道收款账户的状态，才能给其添加金额，但由于其是新创建的账户，所有需要一直找到创世纪块才能知道该账户为新建账户，系统中并未存储，而区块链是不断延长的。

参考资料

1.北京大学肖臻老师《区块链技术与应用》公开课

2.参考笔记