-
Notifications
You must be signed in to change notification settings - Fork 20k
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
Unexpected trie node
error occurs after initial snap sync
#28587
Comments
The node rlpdump corresponds to hash
|
The "unexpected" node is created in this transaction https://etherscan.io/tx/0xadf288639e9921292c8847c5b0ff1c66513f5472dd92b43e17d9451f235c0bfd in block https://etherscan.io/block/18583652 The "unexpected" node is deleted in this transaction According to the sync log, at block 18583652 node is still in the snap sync stage,
at block 18590132 node is still in the state healing stage.
|
System information
Geth version:
geth version
:1.13.5
Issue description
Ref: original ticket #27983 (comment)
The node is reported as invalid, with
5cc0a47442e6bc69eb1ec9e2ff1fe0c9657c26dfa5836f560fd7141038667982
,0x32400084C286CF3E17e7B677ea9583e60a000324
[12 5 9 3 7]
0xf87180a0df5465feffb831b1f31a6184b1efdf75f10f13b2b4900956c22f41a6108c45c9808080808080a0b1902b4fca66415f63634e3ddeae1bfa7b877a1db5ed4c029730e166ba2031ae808080a02ded9e78076e79e96fcd5562c7951f678d22a167429cc75c17d30a08705bb6e780808080
8b09b17b3a4e17de5274c52cc6387cf42c1fb25fd97effda757bb9a2cde87152
99f9a0c9f954cd0d8cf5bb7df9c2b5e529a1652fcc97824ee446ba9300b9f78f
After retrieving the correct node from our benchmark machine, I rlpdump them
correct node
corrupted node
The corrupted node has one more child at the index 1.
Also, I dumped out the parent nodes of this one, they are all full nodes with no shortNode in the middle of path, so it's not relevant with the shortNode trick at all.
This storage is quite huge, with 1.8m slots inside.
I analyzed the contract, there are two functions can mutate the states:
finalizeEthWithdrawal (0x6c0960f9)
: example from etherscanrequestL2Transaction (0xeb672419)
: example from etherscanBoth of them only create new storage slot, but never delete storage slot.
There are a few possibilities here for this situation:
The state sync target is forked, the transaction which creates the trie node at index 1 is reorged out and never get accepted
I don't think it's the case here. Geth uses
head-64
as the sync target, which is very very hard to be reorged in the proof-of-stake network.programatic problems??
The log is attached.
sync-log.zip
The text was updated successfully, but these errors were encountered: