Conversation
…ferred-block-proving
sergerad
requested review from
Mirko-von-Leipzig,
bobbinth and
drahnr
and removed request for
Mirko-von-Leipzig
| /// Returns the highest block number that has been proven, or `None` if no blocks have been | ||
| /// proven yet. | ||
| #[instrument(level = "debug", target = COMPONENT, skip_all, ret(level = "debug"), err)] | ||
| pub async fn select_latest_proven_block_num(&self) -> Result<Option<BlockNumber>> { |
There was a problem hiding this comment.
How do we treat the genesis block? Should it not always be considered proven?
There was a problem hiding this comment.
Updated the comments to reflect - we treat the genesis block as proven
|
|
||
| /// Errors that can occur during block proving. | ||
| #[derive(Debug, Error)] | ||
| enum ProveBlockError { |
There was a problem hiding this comment.
If this is something we want to use more, we should take a look at https://crates.io/crates/fatality
|
|
||
| // Mark completed proofs as proven sequentially. | ||
| // Find the lowest in-flight block. | ||
| let lowest_in_flight = inflight.first().copied().unwrap_or(next_to_schedule); |
There was a problem hiding this comment.
This implies that we set anything that is not inflight to be proven. What if these fail? We'd currently error out above in line 153. I'd prefer to have the individual proven blocks set deliberately to retain a 1:1 relationship.
How important is the continuity property in this context?
There was a problem hiding this comment.
@Mirko-von-Leipzig @bobbinth it turned out to be much simpler to allow out-of-order proof saves. We have gone through quite a few iterations now and latest one is by far the simplest IMO.
…ferred-block-proving
| block_header BLOB NOT NULL, | ||
| signature BLOB NOT NULL, | ||
| commitment BLOB NOT NULL, | ||
| proving_inputs BLOB, -- Serialized BlockProofRequest needed for deferred proving. NULL if it has been proven or never proven (genesis block). |
There was a problem hiding this comment.
nit: leave a TODO that the size might become a problem in the future
5 participants
Context
We are adding deferred (asynchronous) block proving for the node, as described #1592. Currently, block proving happens synchronously during
apply_block, which means block commitment is blocked until the proof is generated.Blocks will now exhibit committed (not yet proven) and proven states. A committed block is already part of the canonical chain and fully usable. Clients that require proof-level finality can opt into it via the new
finalityparameter onSyncChainMmr.Changes
proving_inputs BLOBandis_proven BOOLEANcolumns to theblock_headerstable, with partial index for querying proven (is_proven = 1) blocks.BlockStore(following the existing block file pattern) rather than as BLOBs in SQLite.mark_block_proven,select_block_proving_inputs(returns deserializedBlockProofRequest), andselect_latest_proven_block_num.apply_block: TheBlockProofRequestis now serialized and persisted alongside the block duringapply_block.proof_scheduler.rs) that drives deferred proving. It queries unproven blocks on startup (restart recovery), listens for new block commits viaNotify, and proves blocks concurrently usingFuturesOrderedfor FIFO completion ordering. Proofs are saved to files, then the block is marked proven in the DB.SyncChainMmr: Added aFinalityenum (COMMITTED,PROVEN) to the protobuf and afinalityfield onSyncChainMmrRequest.apply_blockquery: IntroducedApplyBlockDatastruct to replace the 7-parameter function signature.