1. Estructura de bloque
En varios proyectos de blockchain (como Ethereum), los nodos a menudo necesitan mantener tres Trie Roots, que se registran en cada encabezado de bloque.
- stateRoot
- TransaccionesRoot
- recibosRoot
二 、 TransactionsRoot
TransactionsRoot almacena la raíz de Trie , que se compone de transacciones en el bloque.
TransactionRoot tiene la función más simple y es utilizada por el receptor para verificar la integridad de las transacciones en el bloque .
Tres, RecibosRoot
ReceiptsRoot almacena el contenido del recibo de la transacción
El propio recibo registra si la transacción se ejecutó correctamente en el bloque .
receipts, logs, usedGas, err := bc.processor.Process(block, statedb, bc.vmConfig)
Cuatro, StateRoot
StateRoot registra el estado mundial después de que finaliza la ejecución de la transacción .
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)
}
Pero las funciones de StateRoot y ReceiptRoot parecen ser similares.
Se trata de comprobar si el resultado del cambio de estado es correcto.
Cinco, la diferencia entre ReceiptsRoot y StateRoot
La función es muy similar, ambos son para verificar si el resultado de la ejecución de la transacción es correcto.
¿Por qué necesitamos implementarlo dos veces? ¿Podemos asegurarnos de que el contenido de la transacción es correcto y el orden de ejecución es correcto comparando StateRoot con el encabezado?
Eche un vistazo más de cerca al contenido de los recibos
RecibosRoot
Descubrimos que, además de result.Failed () para registrar si la transacción se ejecutó correctamente, también hay un campo Receta.GasUsed al que vale la pena prestar atención.
Este campo indica cuánto gas ha consumido el bloque después de que se ejecuta la transacción actual.
Entonces, obviamente, RecetsRoot también tiene la consistencia del orden de ejecución de las transacciones.
Pero el orden es consistente, aún se puede verificar mediante la consistencia de stateRoot.
StateRoot
Observamos el contenido de stateRoot, está el contenido de Account. StateRoot es más una raíz del entorno mundial. Así que expresa más el mundo después de la ejecución de la transacción.
para resumir
La función de ReceiveRoot y StateRoot es verificar si la ejecución de la transacción es correcta y confiable.
La diferencia es que ReceiveRoot solo indica el éxito y el fracaso de la ejecución de la transacción y la orden de ejecución .
El papel de StateRoot es registrar el estado del mundo después de la ejecución de la transacción.
Tenga en cuenta que Ethereum permite la existencia de bloques huérfanos como los bloques tío.
Cuando un nodo BP en sí mismo está en una bifurcación no convencional, el StateRoot que genera es diferente del StateRoot ejecutado por el receptor.
Si simplemente compara StateRoot y piensa ciegamente que el nodo BP es un nodo maligno, es algo injusto.
Podemos llegar a un consenso sobre la exactitud de la ejecución de la transacción comparando RecetsRoot, independientemente de si el entorno de ejecución es el mismo .
De esta manera, Ethereum es más amigable con los bloques de tíos.
https://blog.csdn.net/cemao4548/article/details/105939491