区块链 以太坊 三元组是什么 state root transaction root receipt root

 

 

 

一、区块结构

在各种区块链项目中(例如以太坊)，节点往往需要维护三个 Trie Root，在每个区块头中会记录

• stateRoot
• transactionsRoot
• receiptsRoot

 

 

代码：https://github.com/ethereum/go-ethereum/blob/053ed9cc847647a9b3ef707d0efe7104c4ab2a4c/core/types/block.go

 

 

二、TransactionsRoot

TransactionsRoot 存储的是 block中transactions组成的Trie的Root
TransactionsRoot的作用最简单，用于接收者检查block中transactions的完整性。

 

 

三、ReceiptsRoot

ReceiptsRoot存储的是交易回执内容

receipt本身记录交易是否在block被成功执行。

代码：https://github.com/ethereum/go-ethereum/blob/ddadc3d27379a3326fd1b78278e5e5da44a91d94/core/blockchain.go

receipts, logs, usedGas, err := bc.processor.Process(block, statedb, bc.vmConfig)

 

 

 

四、StateRoot

StateRoot 记录的是 transaction执行结束之后的世界状态。

	if root := statedb.IntermediateRoot(v.config.IsEIP158(header.Number)); header.Root != root {
		return fmt.Errorf("invalid merkle root (remote: %x local: %x)", header.Root, root)
	}

但是这个StateRoot 和 ReceiptRoot的作用仿佛就相似了。
都是检查状态改变结果是否正确。

 

五、ReceiptsRoot与StateRoot 作用的差异

作用上很相似，都是检查transaction执行结果是否正确。
为啥要实现两遍呢，我们是否可以通过比较StateRoot和header中一致，来保障transaction的内容正确和执行顺序正确？

仔细看一下Receipts的内容

ReceiptsRoot

代码：https://github.com/ethereum/go-ethereum/blob/7770e41cb5fcc386a7d2329d1187174839122f24/core/state_processor.go

我们发现除了result.Failed()来记录transaction执行是否成功外，还有一个receipt.GasUsed域值得关注。
这个域表示当前transaction执行后，该block一共消耗了多少Gas。
所以明显receiptsRoot还有transactions执行顺序的一致性。

但是顺序一致，依旧可以通过stateRoot的一致来检查。

 

StateRoot

代码： https://github.com/ethereum/go-ethereum/blob/ddadc3d27379a3326fd1b78278e5e5da44a91d94/core/blockchain.go

我们看stateRoot的内容，有Account的内容。StateRoot更多是世界环境的Root。所以他更多是表达transaction执行后的世界。

 

总结

receiptRoot 和 StateRoot的作用都是检查transaction执行是否正确可靠。
不同点在于receiptRoot只是表示transaction执行成功失败还有执行顺序。
StateRoot的作用是记录 transaction执行结束之后的世界状态。

注意，以太坊允许uncle block这种孤块的存在。
当一个BP节点本身处在一条非主流分叉上时，它所产生的StateRoot与接收者执行后的StateRoot不同
如果单纯比较StateRoot不同而盲目的认为BP节点是evil节点，就有些不公正。
我们可以通过比较receiptsRoot来对transaction的执行正确性达成一致，不必在乎执行的环境是否相同。
这样以太坊就对uncle block更加友善了。

 

https://blog.csdn.net/cemao4548/article/details/105939491

 

https://docker.blog.csdn.net/article/details/109741079