Review of sortition sections of tech report #119
Conversation
bwbush
force-pushed
the
bwbush/review-sortition
branch
from
557b93c to
28a7535
Compare
|
@bwbush sortition for IB and EB production starts from a protocol parameter expressed as a probability, but the protocol documents instead specify a production rate (per slot, or per pipeline). How do we handle the case where the specified rate is greater than I believe we have been discussing an |
|
|
||
| ### Input blocks | ||
|
|
||
| In Leios, even if a node wins the IB lottery several times, it is only allowed to build a single block. This is identical to the sortition rule in Praos. Let $f_\text{IB}$ be the protocol parameter specifying the per-slot probability of a node producing an IB: |
There was a problem hiding this comment.
"it is only allowed to build a single block", there maybe cases where it would sense that the same producer creates more than one IBs in the same slot, e.g., for the sharding scheme we were discussing.
|
|
||
| > [!CAUTION] | ||
| > | ||
| > - [ ] Is there a theoretical argument (like the law of large numbers) why splitting the stake doesn't make a visible difference? |
There was a problem hiding this comment.
From Praos ( https://eprint.iacr.org/2017/573.pdf ), p.10:
"In particular, when leadership is determined according to ϕf , the probability of a stakeholder
becoming a slot leader in a particular slot is independent of whether this stakeholder acts as a single
party in the protocol, or splits its stake among several “virtual” parties."
Our case is a bit more complicated as by splitting the stake the adversary may try to get more blocks.
Still the above claim at least ensures that the probability that the adversary gets no blocks remains the same.
|
|
||
| > [!IMPORTANT] | ||
| > | ||
| > The above argument needs reworking because it doesn't account for various effects like the EB being per-pipeline, propagation delays, and the RB being per-slot or that there are multiple pipelines. There also may be ambiguities in the specification for the case when several EBs are waiting for an RB: presumably, the "freshest first" rule would be applied here, so the newest EB would go into the RB. We might need simulation for this analysis. |
There was a problem hiding this comment.
I agree that this part needs some more work. E.g., it may be wiser to avoid following the freshest-first rule here, and instead allow the creation of a (limited size) queue of certified EBs that is absorbed by the more frequent creation of RBs.
Please review the sortition sections of the first technical report.