区块链技术学习笔记(16) 以太坊交易树和收据树

最新推荐文章于 2024-05-08 23:45:00 发布

原创

最新推荐文章于 2024-05-08 23:45:00 发布 · 673 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#区块链 #学习 #笔记

本文解释了以太坊中交易树、收据树和状态树的结构，以及它们在证明交易打包和高效查询方面的应用，特别是利用Bloomfilter进行复杂查询的技术。还提到比特币与以太坊的相似之处，即两者都是交易驱动的状态机，状态转移需确定性。

发布区块的时候，区块中所包含的交易会组织成一棵交易树(Merkel Tree)，同时以太坊增加了一棵收据树，每个交易执行完之后会生成一个收据，记录交易的相关信息。交易树和收据树其中的节点是一一对应的，从结构上讲交易树和收据树都是MPT，其中key为交易中排的序号（序号由发布区块的节点决定）

交易树和收据树都是只把当前发布区块的交易组织起来的，而状态树则需要将系统中所有账户的状态都要包含。多个区块的状态树是共享节点的，每次发布一个新区块的时候，需要新建一个分支，其他的节点都是沿用之前状态树节点。相比之下每个区块的交易树和收据树都是独立的，不共享节点，一个区块和另一个区块也被认为是相互独立的。

交易树和收据树的作用

提供Merkel proof，用于证明某一个交易被打包到区块中。可以向轻节点提供这样的Merkel proof。

以太坊支持更加复杂的查询操作

例如：找到过去十天和某个智能合约相关的交易，应该如何查找

bloom filter：

作用：能够高效查找某个元素是否在一个大的集合中

思想：为这个包含很多元素的大集合计算出一个很紧凑的摘要，例如一个128位的向量。对集合计算出一个digest，把每个元素映射到向量的某个位置并将值从0置为1。也就是把每个元素都取哈希，找到相应位置并将值置为1，将所有元素处理完之后得到的就是这个元素的摘要。在进行查询时，将查询数据取哈希，映射到摘要上，如果当前位置的值为0，则当前查询数据一定不在集合中，如果为1，不能确定查找元素一定在集合中（哈希碰撞）。

有的bloom filter用的不是一个哈希函数，而是一组哈希函数，每一个哈希函数独立将元素映射到向量相应位置。如果出现哈希碰撞，一般不会所有的哈希函数都出现哈希碰撞。