feat(spec): Proofs scheduling protocol, English specification #241
Conversation
cason
changed the title
cason
changed the title
| There is a deterministic function `proposer(H,R)` that defines from `valset(H)` | ||
| the validator that should propose a block in the round `R` of the instance `H` |
There was a problem hiding this comment.
I think mathematically this is not precise. I think there is one function for each epoch, or there is just one function proposer with additional parameters (some input that simulations randomness based on some hashes on L1).
Perhaps we should make it less explicit, and say that validators have a means to compute a unique proposers for each round, so that all validators agree on this proposer.
There was a problem hiding this comment.
This is kind of disconnected here, but proposer computes from valset(H) the validator set. I will make this more explicit.
There was a problem hiding this comment.
Regarding the second part, yes, we miss a subsection about epochs, in terms of how validator sets change and how long in the future we can compute the proposer of a height/round.
specs/english/proofs_scheduling.md
Outdated
| There is an exception for this mechanism intended to limit the number of | ||
| **empty blocks** in a strand. | ||
| So, if there are `P` empty blocks in the current strand `s`, namely if | ||
| `|unproven(s)| > P`, the proposer of **any round** of a height `H` with | ||
| `strand(H) == s` can only propose a block if it includes `expected_proofs(H)`. |
There was a problem hiding this comment.
Can we do some analysis here. Assume the proposer of round 0 is faulty, and doesn't have a prove, and no-one else does. This means that we will spend L time units going through unsuccessful consensus rounds, before someone comes up with a proof and becomes proposer. That is, Starknet doesn't generate blocks for a couple of minutes.
I wonder whether one should consider additional incentives to the proposer who adds a proof after P, so that it may pay of that multiple parties start producing the block.
There was a problem hiding this comment.
Yes, agree.
This is another point it is missing, it is present on the PR description. We need, first, describe this scenario here, then, propose some form of mitigation.
Co-authored-by: Josef Widder <44643235+josef-widder@users.noreply.github.com>
cason
force-pushed
the
cason/proofs-english-spec
branch
from
c1e0638 to
f0497d2
Compare
Contributes to #237.
Rendered: https://github.com/informalsystems/malachite/blob/cason/proofs-english-spec/specs/english/proofs_scheduling.md
Main reference: https://docs.google.com/document/d/1qjngaq9GoMWa5UJOrTlKNqwi_pI0aHt8iULWD9Gy9hE/edit
There are some pending tasks:
Ideally, this spec should be aligned with the Quint spec of the same protocol: #198.
PR author checklist