Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spec: Introduce a ValidValue(v, r) event #312

Open
Tracked by #260
cason opened this issue Aug 6, 2024 · 2 comments
Open
Tracked by #260

spec: Introduce a ValidValue(v, r) event #312

cason opened this issue Aug 6, 2024 · 2 comments
Labels
spec Related to specifications sync Synchronization protocols
Milestone

Comments

@cason
Copy link
Contributor

cason commented Aug 6, 2024

When a value v is received and 2/3+ Prevotes for id(v) are received during a round, v becomes a valid value at that round. If a value becomes valid while the node hasn't yet issued a Precommit for that round, the valid value also becomes the locked value.

When a value becomes valid for a node it is liked to be precommitted and locked by other nodes, which renders this event particular relevant for liveness. Moreover, due to equivocation (#309), it is possible that a node learns that a value is valid while other node, but considering a different vote from equivocating senders, does not. This, again, can harm liveness.

As a result, nodes that observe that a value have became valid in a round should be able to forward this information to other nodes, with a distinct view of the system state. This is one element to be considered for the sake of node synchronization (#260).

At the moment, however, updating the valid_value and valid_round fields is an internal transition in the consensus state-machine. I argue here that this event should be exported by it so that synchronization protocols can be aware of this scenario and provide the associated prevotes, from the 2/3+ certificate, to peers.

@cason cason added the spec Related to specifications label Aug 6, 2024
@romac romac added the phase3 label Aug 8, 2024
@romac romac added this to the Phase 3 milestone Aug 8, 2024
@cason
Copy link
Contributor Author

cason commented Sep 5, 2024

A relevant question on this regard is whether we need to know the full value v in order to emit the ValidValue(v,r) event.

We possibly can update it to be ValidValue(id(v), r) and produce it even though we have not received the full value v. In fact, emitting this event can be a trigger for the synchronization protocol to retrieve the full value v, as the validator has learned that it is a valid value, therefore a value that is very likely to eventually be decided.

Notice that the distinction of v and id(v) is still not really clear, see #365.

Notice also that the consensus state machine cannot update validValue_p and validRound_p if the full value v was not received.

This proposal also means that the driver can produce the ValidValue events, i.e., that we don't need consensus to produce it.

@cason
Copy link
Contributor Author

cason commented Sep 17, 2024

Partially covered in Quint by #364.

@cason cason removed the phase3 label Sep 17, 2024
@romac romac modified the milestones: Phase 3, Phase 4 Oct 17, 2024
@cason cason added the sync Synchronization protocols label Nov 22, 2024
@romac romac added the phase4 label Dec 4, 2024
@romac romac changed the title spec: introduce a ValidValue(v,r) event spec: Introduce a ValidValue(v,r) event Dec 19, 2024
@romac romac changed the title spec: Introduce a ValidValue(v,r) event spec: Introduce a ValidValue(v, r) event Dec 19, 2024
@romac romac removed the phase4 label Dec 19, 2024
@romac romac modified the milestones: Phase 4, Phase 5 Jan 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec Related to specifications sync Synchronization protocols
Projects
None yet
Development

No branches or pull requests

2 participants