Open SurfingNerd opened 3 years ago
SurfingNerd
commented
2 years ago we can confirm now that the error is reproduceable if trying to resync a node that happened to be part of the active validator set in the past. If syncing as RPC node, the chain can sync without problem. If syncing as regular validator - this problem can occur.
SurfingNerd
commented
2 years ago stage 5 verification fails, because of is_end_epoch argument cannot get calculated. Why:
on close block, do_keygen() is getting called. we have pending validators, so we try to figure out if the key gen is ready. initalize_synckeygen reads all part_of_address for every validator.
In the section "// We are a validator: Decrypt and deserialize our row and compare it to the commitment." ".decrypt(&rows[our_idx as usize])"
This rows array holds the PART data. A part data contains a secret message for every pending validator.
It looks like the validator "0x5C132de048605FB4e90B97a14cd25DA230dAf218" wrote a part, with informations that we ("0x40703fe50d7cbd36bc70295d29a93ec05badc6bd") are unable to decrypt.
dforsten
commented
2 years ago All blocks are verified on import, requiring all contract calls to be executed exactly the same way on all nodes. This includes system calls, which also have to be called with exactly the same arguments on all nodes.
Stage 5 verification excecutes all contract calls as well as all system calls to verify that the same state results as specified in the block's header.
If the state after all calls differs from the state root specified in the block's header stage 5 verification fails!
The block rewards contract is executed when the block is getting closed, and only accepts a single boolean argument: is_end_epoch
If for some reason on some pending validators this argument is false when it should be true. This results in a stage 5 verification error, which marks the block as "bad block" which prevents it from being imported.
If that block in fact was correct, syncing will fail indefinitely because this block is falsely marked as "bad" and no following block can be imported either.
The on_close_block() function calls do_keygen() to determine if there are enough "Parts" and "Acks" to finish the KeyGen Phase and start a new epoch with a new validator set.
do_keygen() calls initalize_synckeygen() which uses the part_of_address() function to read all available Parts and passes them to the hbbft library for processing, which uses the private key of the pending validator to decrypt the information other pending validators have written for it into their Part contributions.
On decrypting the information written into the Part for us by other pending validators we encounter a decryption error. This happens in the handle_part_or_fault() function in the hbbft library:
// We are a validator: Decrypt and deserialize our row and compare it to the commitment.
let ser_row = self
.sec_key
.decrypt(&rows[our_idx as usize])
.map_err(|_| PartFault::DecryptRow)?; rows is the array of information encrypted with the public keys of each pending validator, contained in the "Part" written into the KeyGen contract by each pending validator.
It looks like the validator "0x5C132de048605FB4e90B97a14cd25DA230dAf218" wrote a part, with information that we ("0x40703fe50d7cbd36bc70295d29a93ec05badc6bd") are unable to decrypt.
This fails the generation of the new hbbft Keys even if technically there would be enough Parts and Acks written to finish Key generation.
This causes the block reward system call to be called with the is_end_epoch argument as false, when it should be true, thus causing a different block state, failing stage 5 verification.
We experienced the same error on the same block on different machines, while other machines with the similiar hardware could process the block
documentation for the import of an existing block: https://openethereum.github.io/Trace-NewBlock Branch with additional logging information about whats going on: https://github.com/SurfingNerd/openethereum-3.x/tree/surfingnerd/stage-5-logging