-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log/LogTrie processing panic #161
Comments
The bug we are running into is due to this optimization in Ethereum’s modified merle Patricia trie where if a “leaf node” (partial path + RLP encoding of the value it stores) is less than or equal to 32 bytes in size (the size of a keccak256 hash) then its parent branch node will store it directly in one of its 16 hex slots rather than it existing as a distinct leaf node referenced by a hash in that hex slot. In this case there is a leaf value but it is not stored in a distinct leaf node and can't be associated with a leaf key. This can also occur, and often does, in the storage trie where contract variables can be less than 32 bytes in length. It can’t occur in the state trie because an RLP encoded account is always greater than 32 bytes even when it is empty. Nor can it occur in the tx or rct tries as txs and rcts always encode to >32 bytes. We aren’t properly accounting for this in the new LogTrie (which doesn’t exist in canonical Ethereum data structures). Somewhat rarely, contracts will emit event logs that don’t contain any topics or data, the log only contains a 20 byte address. If the partial path for the node in the trie is <= 12 bytes then the “leaf node” is <= 32 bytes and will be stored in its parent branch node. When this happens, the number of leaf nodes in the trie does not match the number of logs (hence the panic on out-of-bounds where we expected them to match), and it is not possible to associate the eth.log_cids entry with a leaf_cid/leaf_mh_key (the association becomes nonsensical). |
On mainnet data we sometimes run into blocks where the log/logTrie processing causes the below panic. Infrequent enough to have not caught in our unit tests/earlier trial runs, but often enough to be a major issue with the current production deployment.
The text was updated successfully, but these errors were encountered: