On startup, check that the finalized state blocks match the checkpoint hashes #5912
Labels
A-concurrency
Area: Async code, needs extra work to make it work properly.
A-consensus
Area: Consensus rule updates
C-security
Category: Security issues
I-consensus
Zebra breaks a Zcash consensus rule
Motivation
Currently, Zebra doesn't check if its checkpoints match the blocks in its cached state. This means that Zebra can follow a chain fork for a very long time, even after restarts.
This has become more of an issue recently, because Zebra will soon be able to:
Specifications
zcashd
checks for a few well-known block hashes on startup, which are typically network upgrade activations.Complex Code or Requirements
To avoid startup delays, Zebra can do these checks concurrently with the rest of its startup and sync tasks. This can happen in a similar way to the Zcash parameter downloads. (But it can be async, because the state service is async.)
zebra/zebra-consensus/src/chain.rs
Lines 242 to 251 in bc783a7
Testing
We could manually insert a bad block hash into the database, then run this check and make sure it fails.
The success case will be covered by existing tests.
Related Work
This is part of a larger issue for the Zcash network - we don't have good monitoring for chain forks or other serious network events.
We also want to track the recent chain forks that an individual Zebra node has discovered in our metrics:
The text was updated successfully, but these errors were encountered: