When we bootstrap a node, it continues replicating from its latest epoch stored in its ledger.
This means that the epoch changes it performs rely on the fact that the blocks that cause the epoch change are properly signed by a quorum of nodes from the latest epoch.
However, this can be problematic in a setting where the node was offline for a long time or is a new node, because if the keys of the validator set have been leaked in the past, a malicious node can falsify an entire chain of blocks.
What we should do instead is when we bootstrap the node, we replicate only the sealing blocks backwards, until we reach the latest committed sealing block, and then we keep the chain of sealing blocks and use them and never replicate them by verifying quorum certificates.
When we bootstrap a node, it continues replicating from its latest epoch stored in its ledger.
This means that the epoch changes it performs rely on the fact that the blocks that cause the epoch change are properly signed by a quorum of nodes from the latest epoch.
However, this can be problematic in a setting where the node was offline for a long time or is a new node, because if the keys of the validator set have been leaked in the past, a malicious node can falsify an entire chain of blocks.
What we should do instead is when we bootstrap the node, we replicate only the sealing blocks backwards, until we reach the latest committed sealing block, and then we keep the chain of sealing blocks and use them and never replicate them by verifying quorum certificates.