Add specs for MPTs #1383
Add specs for MPTs #1383
Conversation
|
Amazing @wborgeaud can we get this merged before Monday? |
Co-authored-by: David <[email protected]>
Co-authored-by: David <[email protected]>
Co-authored-by: David <[email protected]>
Co-authored-by: David <[email protected]>
Co-authored-by: David <[email protected]>
Co-authored-by: David <[email protected]>
| \item the nonce, | ||
| \item the balance, | ||
| \item a pointer to the account's storage trie, | ||
| \item a hash of the account's code. |
There was a problem hiding this comment.
It's the hash of the empty byte sequence keccak(b'') = 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470.
| \item a pointer to the account's storage trie, | ||
| \item a hash of the account's code. | ||
| \end{enumerate} | ||
| The storage trie payload in turn is a single word. |
There was a problem hiding this comment.
Yes, Ethereum storage slots hold one 256-bit integer.
| \item[State Trie:] Encoded as a list containing nonce, balance, storage trie hash and code hash. | ||
| \item[Storage Trie:] The RLP encoding of the value (thus the double RLP encoding) | ||
| \item[Transaction Trie:] The RLP encoded transaction. | ||
| \item[Receipt Trie:] Depending on the transaction type it's encoded as ${\sf RLP}({\sf RLP}({\tt receipt}))$ for Legacy transactions or ${\sf RLP}({\tt txn\_type}||{\sf RLP}({\tt receipt}))$ for transactions of type 1 or 2. Each receipt is encoded as a list containing: |
There was a problem hiding this comment.
Shouldn't it be just {\tt txn\_type}||{\sf RLP}({\tt receipt}) for type 1 or 2 txns?
There was a problem hiding this comment.
Hmmm, at least the comment on the code explicitly says
// There is a double encoding! What we compute is: // either RLP(RLP(receipt)) for Legacy transactions or RLP(txn_type||RLP(receipt)) for transactions of type 1 or 2
@LindaGuiga or @hratoanina?
There was a problem hiding this comment.
Indeed, we are doubly encoding (it didn't work with a simple encoding). I believe the value is the simple RLP encoding, and the actual node encoding is then the RLP encoding of the value (and therefore the double encoding). @hratoanina?
There was a problem hiding this comment.
Hm this is confusing. When running the ERC20 test, the receipt trie root is gotten with
Hashing [249, 1, 176, 130, 32, 128, 185, 1, 170, 2, 249, 1, 166, 1, 130, 220, 179, 185, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8, 0, 0, 0, 0, 0, 8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 64, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 20, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 66, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 248, 157, 248, 155, 148, 95, 189, 178, 49, 86, 120, 175, 236, 179, 103, 240, 50, 217, 63, 100, 47, 100, 24, 10, 163, 248, 99, 160, 221, 242, 82, 173, 27, 226, 200, 155, 105, 194, 176, 104, 252, 55, 141, 170, 149, 43, 167, 241, 99, 196, 161, 22, 40, 245, 90, 77, 245, 35, 179, 239, 160, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 231, 241, 114, 94, 119, 52, 206, 40, 143, 131, 103, 225, 187, 20, 62, 144, 187, 63, 5, 18, 160, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 31, 144, 144, 170, 226, 139, 138, 61, 206, 173, 242, 129, 176, 241, 40, 40, 230, 118, 195, 38, 160, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 5, 107, 199, 94, 45, 99, 16, 0, 0]
which is the RLP encoding of [0x2080, 0x2 + RLP(receipt)], the leaf node at 0 with payload tx_type + RLP(receipt). So there doesn't seem to be a double RLP encoding here, unless I'm missing something.
There was a problem hiding this comment.
Doesn't the 185 indicate the start of an RLP encoding for (0x2 || RLP(receipt)) here? (with 249 starting the RLP encoding of the receipt)?
There was a problem hiding this comment.
But actually, I think we should also change that for transactions: when calling the encode method on a transaction node, we also RLP encode the RLP encoding
There was a problem hiding this comment.
Doesn't the
185indicate the start of an RLP encoding for (0x2 || RLP(receipt)) here? (with249starting the RLP encoding of the receipt)?
Sure, but that's just because the RLP of a list is the concatenation of the RLP of the items of the list (prefixed by the length).
Co-authored-by: David <[email protected]>
Co-authored-by: wborgeaud <[email protected]>
|
Kudos, SonarCloud Quality Gate passed!
|
No description provided.