-
交易树&收据树：
- 每次发布⼀个区块时，区块中的交易会形成⼀棵交易树（也是一棵MPT）
- 每个交易执⾏完之后形成⼀个收据，记录交易相关信息，且交易树和收据树上的节点是⼀⼀对应
- 由于以太坊智能合约执⾏较为复杂，通过增加收据树，可以快速查询执⾏结果
- MPT的好处是⽀持查找操作，通过键值沿着树进⾏查找即可：
- 对于状态树，查找键值为账户地址
- 对于交易树和收据树，查找键值为交易在发布的区块中的序号
- 状态树 vs. 交易树&收据树：
- 交易树/收据树只将当前区块中的交易/收据组织起来，⽽状态树将所有账户的状态都包含进去，⽆论这些账户与当前区块中交易有⽆关系
- 多个区块状态树共享节点，⽽交易树和收据树依照区块独⽴
- 交易树和收据树的⽤途：
- 向轻节点提供Merkle Proof
- 更加复杂的查找查询，比如查询过去⼗天与某⼀智能合约有关的交易、过去⼗天的众筹事件等
-
Bloom Filter(布隆过滤器)- ⽀持较为⾼效查找某个元素是否在某个集合中
- 给⼀个⼤的集合，计算出⼀个紧凑的“摘要”
digest - 给定⼀个数据集，其中含元素a、b、c，通过⼀个哈希函数H()对其进⾏计算，将其映射到⼀个其初始全为0的128位的向量的某个位置，将该位置置为1
- 将所有元素处理完，就可以得到⼀个向量，称该向量为原集合的“摘要”
- 假定想要查询⼀个元素d是否在集合中，假设H(d)映射到向量中的位置处为0，说明d⼀定不在集合中；假设H(d)映射到向量中的位置处为1，有可能集合中确实有d，也有可能因为哈希碰撞产⽣误报
- Bloom Filter特点：有可能出现误报
false positive，但不会出现漏报 - Bloom Filter变种：采⽤⼀组哈希函数进⾏向量映射，有效避免哈希碰撞
- 如何删除集合中的元素？
- 简单的Bloom Filter不⽀持删除操作
- 如果想要⽀持删除操作，需要将记录数修改为⼀个计数器（需要考虑计数器是否会溢出）
- ETH每个交易完成后会产⽣⼀个收据，包含⼀个Bloom Filter记录交易类型、地址等信息
- 在block header中也包含⼀个Bloom Filter，其为该区块中所有交易的Bloom Filter的并集
- 查找时先查找区块头中的Bloom Filter，如果块头中包含，再查看区块中包含的交易所对应的收据树的Bloom Filter，如果存在，再查看交易进⾏确认是否存在
-
以太坊模型：
- 以太坊的运⾏过程，可以视为交易驱动的状态机
transaction-driven state machine - 状态是指所有账户的状态，交易是指每次发布的区块中的交易
- 通过执⾏当前区块中包含的交易，驱动系统从当前状态转移到下⼀状态
- BTC也可以被视为交易驱动的状态机，其状态为UTXO
- 对于给定的当前状态和给定的⼀组交易，可以确定性地转移到下⼀状态（保证系统⼀致性）
- 以太坊的运⾏过程，可以视为交易驱动的状态机
-
其他问题：
- A转账给B，收款账户有没有可能不包含在状态树中？
- 答：可能，因为以太坊中账户可以节点⾃⼰产⽣，只有在产⽣交易时才会被系统知道
- 能否将每个区块中的状态树更改为只包含和区块中交易相关的账户状态 (从⽽⼤幅削减状态树⼤⼩，且和交易树、收据树保持⼀致)？
- 答：不能。这样设计要查找账户状态很不⽅便，因为不存在某个区块包含所有状态；如果需要向⼀个新建账户转账，因为需要知道收款账户的状态，才能给其添加⾦额，但由于其是新创建的账户，需要⼀直找到创世区块才能知道该账户为新建账户，系统中并未存储，⽽区块链是不断延⻓的
- A转账给B，收款账户有没有可能不包含在状态树中？
