Is the storageRoot serialized to RLP as part of the Account?

[siladu]

https://github.com/ethereum/yellowpaper/blob/f41ec9a6785374c1d9b9e9a064e3ceae1413805a/Paper.tex#L272

It shall be understood that $\boldsymbol{\sigma}[a]_{\mathbf{s}}$ is not a `physical' member of the account and does not contribute to its later serialisation.

Is the storageRoot not included because it is unnecessary duplication since the trie can be referenced directly with an Address?

[siladu]

Answer from @ajsutton:

Formally the Account is nonce, balance, storageRoot and codeHash and I think it’s encoded just as an RLP list of those values. I think https://github.com/hyperledger/besu/blob/110052c9f3990dce7e3035579a692ab9bb75daec/ethereum/core/src/main/java/org/hyperledger/besu/ethereum/worldstate/StateTrieAccountValue.java#L99 is the relevant code in besu.

Given the way the executable specs are storing the storage trie by Account rather than it’s root hash then yeah I think you’re right that they can not actually store the storage root in the account but generate it when needed from the stored trie which is looked up by Address.

There seems to be some confusion between the storage trie root hash and the storage trie itself. The root hash is part of the account serialization but the storage trie itself is not. σ[a]s is defined as the root hash but an equivalence is defined in equation 7 which says the trie itself is equivalent to σ[a]s.

[siladu]

confusion between the storage trie root hash and the storage trie itself.

Yes, that could well be it. I understand the σ[a]s being used as an alias to the trie’s underlying values.

However, the execution spec does seem to confirm that the storageRoot is excluded: https://ethereum.github.io/execution-specs/autoapi/ethereum/istanbul/eth_types/index.html#ethereum.istanbul.eth_types.Account

classAccount
  nonce:ethereum.base_types.Uint
  balance:ethereum.base_types.U256
  code:bytes

[siladu]

Answer from @ajsutton:

I think that’s because internally they’re indexing the storage trie by Account rather than by root hash. But the storage root has to be included in the world state trie account data, otherwise the world state trie root hash wouldn’t change when a storage trie changed and it’s only the world state trie that’s included in the block header - ie it’s the only thing we check to make sure we have the exact same world state.

We want to cryptographically prove that the storage tries we have are exactly the same as the storage tries everyone else has. ie that there wasn’t a bug in the transaction execution that caused a chain split.