1. Block structure
In various blockchain projects (such as Ethereum), nodes often need to maintain three Trie Roots, which are recorded in each block header
- stateRoot
- transactionsRoot
- receiptsRoot
二、TransactionsRoot
TransactionsRoot stores the Trie's Root , which is composed of transactions in the block. The
TransactionRoot has the simplest function and is used by the receiver to check the integrity of transactions in the block .
Three, ReceiptsRoot
ReceiptsRoot stores the transaction receipt content
The receipt itself records whether the transaction is successfully executed in the block .
receipts, logs, usedGas, err := bc.processor.Process(block, statedb, bc.vmConfig)
Four, StateRoot
StateRoot records the world state after the transaction execution ends .
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)
}
But the functions of StateRoot and ReceiptRoot seem to be similar.
It is to check whether the result of the state change is correct.
Five, the difference between ReceiptsRoot and StateRoot
The function is very similar, both are to check whether the transaction execution result is correct.
Why do we need to implement it twice? Can we ensure that the content of the transaction is correct and the order of execution is correct by comparing the StateRoot with the header?
Take a closer look at the content of Receipts
ReceiptsRoot
We found that in addition to result.Failed() to record whether the transaction was executed successfully, there is also a receipt.GasUsed field worth paying attention to.
This field indicates how much gas has been consumed by the block after the current transaction is executed.
So obviously receiptsRoot also has the consistency of the execution order of transactions.
But the order is consistent, it can still be checked by the consistency of stateRoot.
StateRoot
We look at the content of stateRoot, there is the content of Account. StateRoot is more of the Root of the world environment. So he is more expressing the world after transaction execution.
to sum up
The function of receiptRoot and StateRoot is to check whether the transaction execution is correct and reliable.
The difference is that receiptRoot only indicates the success and failure of transaction execution and the execution order .
The role of StateRoot is to record the state of the world after the execution of the transaction.
Note that Ethereum allows the existence of uncle blocks such as solitary blocks.
When a BP node itself is on a non-mainstream fork, the StateRoot it generates is different from the StateRoot executed by the receiver.
If you simply compare the StateRoot and blindly think that the BP node is an evil node, it is somewhat unfair.
We can reach a consensus on the correctness of the execution of the transaction by comparing receiptsRoot, regardless of whether the execution environment is the same .
In this way, Ethereum is more friendly to uncle blocks.
https://blog.csdn.net/cemao4548/article/details/105939491