You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running standalone Silkworm at commit b0ce84b using Prism as Consensus Layer client, the Execution stage stumbled upon an invalid block failure due to wrong block gas error at block 21099525:
...
INFO [12-31|20:44:03.457 UTC] PoSSync: new_payload block_hash=ac49f15fd77604e834dbb1949673b2351bd439f39d18049179f2d999951f2529 block_num: 21'495'630 <- reply SYNCING
INFO [12-31|20:44:03.463 UTC] [5/13 Execution] block=21099525 blocks/s=36 txns/s=5645 Mgas/s=559
INFO [12-31|20:44:03.628 UTC] PoSSync: fork_choice_update head_block_hash=ac49f15fd77604e834dbb1949673b2351bd439f39d18049179f2d999951f2529 safe_block_hash=5f7ee85f7be8e81187c7054d55dbd7e6780d54982f5ab0d306a3f237b8eaac7b finalized_block_hash=da920d7b9edcfa4aafe460bc665c30447f8d879e61744608839410bf60e4fde3
...
INFO [12-31|20:44:16.124 UTC] Flushed state size=301.45 MB in=15.250s
WARN [12-31|20:44:16.140 UTC] [5/13 Execution] block=21099525 hash=0xf47efd5411ae2c21430ff662155ee0bb8ba27b36083c44ff76d09bb93b50a4d0 error=kWrongBlockGas
INFO [12-31|20:44:19.005 UTC] PoSSync: new_payload block_hash=765e667f093d766f98e38ff37e5dd1966b1e6ab252a1ae7a19328c83efbce96b block_num: 21'495'631 <- reply SYNCING
...
INFO [12-31|20:44:19.968 UTC] PoSSync: fork_choice_update head_block_hash=ea20eb203c2be7ec82dc05e5be58dad3317801e3f85fda783cf1df3474a7b795 safe_block_hash=4e61981a8039d4b539da00e519b74a52f95ff8781811eb2d08b2c41a69f47498 finalized_block_hash=765e667f093d766f98e38ff37e5dd1966b1e6ab252a1ae7a19328c83efbce96b
INFO [12-31|20:44:20.099 UTC] [5/13 Execution] commit batch time=3.917s
ERROR [12-31|20:44:20.109 UTC] [5/13 Execution] op=Forward failure=kInvalidBlock
INFO [12-31|20:44:20.109 UTC] MainChain::verify_chain forward_result=kInvalidBlock
INFO [12-31|20:44:20.109 UTC] MainChain::collect_bad_headers bad_count=387'643 skip=1
The last known valid state can be found looking at the block span applied by the last staged sync or reading the progress of stages from the database. It turned out that the last valid state root was computed at block 21049761.
Applying the bisect command in staged_pipeline utility:
you get the first block that breaks the state root computation:
...
INFO [01-04|02:05:40.140 UTC] [7/13 IntermediateHashes] op=kForward mode=full op=building merkle tree key=0xfd05c9fee26045c766...
INFO [01-04|02:06:10.140 UTC] [7/13 IntermediateHashes] op=kForward mode=full op=building merkle tree key=0xfdf580df66b644757f...
ERROR [01-04|02:06:28.379 UTC] [7/13 IntermediateHashes] function=regenerate_intermediate_hashes exception=expected 0x0cc0db0367272cf732cadbf7ff0975e06679b6d91cc45c08e5479073ea9520a2 got 0xbd02257d7e054c423bac16885ffca857dcb22ba6c18c572061c25f5ed5a6cbfb
ERROR [01-04|02:06:28.379 UTC] [7/13 IntermediateHashes] function=forward exception=kWrongStateRoot
ERROR [01-04|02:06:28.379 UTC] [7/13 IntermediateHashes] op=Forward failure=kWrongStateRoot
INFO [01-04|02:06:28.379 UTC] Bisect: forward from=21'072'001 to=21'072'002 END
INFO [01-04|02:06:28.379 UTC] Bisect: left=21'072'001 median=21'072'001 unwind=21'072'001
INFO [01-04|02:06:28.379 UTC] Bisect: unwind down to block=21'072'001 START
INFO [01-04|02:06:28.379 UTC] ExecutionPipeline Unwind start
INFO [01-04|02:06:28.379 UTC] [7/13 HashState] op=kUnwind from=21072002 to=21072001 span=1
INFO [01-04|02:06:28.381 UTC] [9/13 Execution] op=kUnwind from=21072002 to=21072001 span=1
INFO [01-04|02:06:28.382 UTC] Erased 2 records from AccountChangeSet
INFO [01-04|02:06:28.382 UTC] Erased 2 records from StorageChangeSet
INFO [01-04|02:06:28.382 UTC] Erased 1 records from Receipt
INFO [01-04|02:06:28.382 UTC] Erased 0 records from TransactionLog
INFO [01-04|02:06:28.382 UTC] Erased 3 records from CallTraceSet
INFO [01-04|02:06:28.383 UTC] [10/13 Senders] op=kUnwind from=21072002 to=21072001 span=1
INFO [01-04|02:06:28.383 UTC] [11/13 Bodies] op=kUnwind from=21072002 to=21072001 span=1
INFO [01-04|02:06:28.383 UTC] [12/13 BlockHashes] op=kUnwind from=21072002 to=21072001 span=1
INFO [01-04|02:06:28.383 UTC] [13/13 Headers] op=kUnwind from=21072002 to=21072001 span=1
INFO [01-04|02:06:28.384 UTC] ExecutionPipeline Unwind done
INFO [01-04|02:06:28.384 UTC] Bisect: unwind down to block=21'072'001 END
INFO [01-04|02:06:28.384 UTC] Bisect: failed at block=21'072'002
Using the blocks command in db_toolbox to inspect such a block saved on the database:
This output reveals that the saved copy of block 21072002 is invalid because computing the withdrawals root from the withdrawals data you get a mismatch. Moreover, if you decode the RLP storage-encoded data for the body and print the content of the the withdrawals you get:
Surprisingly or not, this shows that the invalid content of the withdrawals is indeed well-formed and you can even deduce from the validator_index values that these withdrawals are indeed the ones from block 21070352, which is kind of weird.
The text was updated successfully, but these errors were encountered:
Running standalone Silkworm at commit b0ce84b using Prism as Consensus Layer client, the
Execution
stage stumbled upon an invalid block failure due to wrong block gas error at block 21099525:The last known valid state can be found looking at the block span applied by the last staged sync or reading the progress of stages from the database. It turned out that the last valid state root was computed at block 21049761.
Applying the
bisect
command instaged_pipeline
utility:you get the first block that breaks the state root computation:
Using the
blocks
command indb_toolbox
to inspect such a block saved on the database:this is what you get:
This output reveals that the saved copy of block 21072002 is invalid because computing the withdrawals root from the withdrawals data you get a mismatch. Moreover, if you decode the RLP storage-encoded data for the body and print the content of the the withdrawals you get:
Surprisingly or not, this shows that the invalid content of the withdrawals is indeed well-formed and you can even deduce from the
validator_index
values that these withdrawals are indeed the ones from block 21070352, which is kind of weird.The text was updated successfully, but these errors were encountered: