Skip to main content

create_segment_archiver_task

Function create_segment_archiver_task 

Source
pub async fn create_segment_archiver_task<Block, CI>(
    chain_info: CI,
    block_importing_notification_receiver: Receiver<BlockImportingNotification>,
    archived_segment_notification_sender: Sender<ArchivedSegmentNotification>,
    consensus_constants: ConsensusConstants,
    erasure_coding: ErasureCoding,
) -> Result<impl Future<Output = Result<(), SegmentArchiverTaskError>> + Send + 'static, SegmentArchiverTaskError>
where Block: GenericOwnedBlock, CI: ChainInfoWrite<Block> + 'static,
Expand description

Create a segment archiver task.

Archiver task will listen for importing blocks and archive confirmed blocks, producing pieces and segment headers. It produces local segments initially, which after confirmation by the beacon chain will be updated with the necessary proof and given a global segment index.

NOTE: Archiver is doing blocking operations and must run in a dedicated task.

Archiver is only able to move forward and doesn’t support reorgs. Upon restart, it will check segments in [ChainInfo] and chain history to reconstruct the “current” state it was in before the last shutdown and continue incrementally archiving blockchain history from there.

Archiving is triggered by block importing notification (block_importing_notification_receiver) and tries to archive the block that the block being imported confirms (see [ConsensusConstants::block_confirmation_depth]). Block importing will then wait for archiver to acknowledge processing, which is necessary for ensuring that when a child of the block being imported is imported, the newly archived segment is already available deterministically.

Once a new segment is archived, a notification (archived_segment_notification_sender) will be sent and archiver will be paused until all receivers have provided an acknowledgement for it (or a very generous timeout has passed). After a restart, a segment that was already announced can be announced again: blocks that the database didn’t write to disk yet (above its soft_confirmation_depth) are lost and imported again, and the blocks they confirm are archived again.

Snap sync must store all known segment headers before any block is imported, and a block that it inserts directly, without its ancestors, must be the last archived block of one of those segments. Re-initialization then resumes archiving from the latest of those segments whose last archived block is in the chain.