Skip to content

Allow for full replication #254

@samliok

Description

@samliok

Replication is currently kickstarted when a node receives a finalization for a future round. It then knows it is missing x amount of sequences so it requests them from other nodes. A node will respond with the requested sequences and also send its latest quorum round to ensure the requesting node has the most recent sequence. This works for finalizations, but is not enough since we aren't guaranteed to receive the most up-to-date notarization(without a finalization) or empty notarization. Furthermore, we need to kickstart the process of replication when we receive future Notarizations and EmptyNotarizations since the network might be stuck and waiting for the lagging node to complete the QC.

To do so, we should extend our replication logic to distinguish between replicating finalized sequences and future rounds with Notarizations/EmptyNotarizations. By keeping track of the latestFinalizedSeq and latestKnownRound, our node also knows if it needs to vote on rounds while replicating(noted here).

With this proposed logic, a lagging node would being replication when it receives a EmptyNotarization, Finalization or Notarization from a future round. In the case where a lagging node reconnects into a halted network, it will send an emptyVote message which will be responded to via

func (e *Epoch) maybeSendNotarizationOrFinalization(to NodeID, round uint64) {
. This logic should be updated to also send the latestQuorumRound.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions