Review of votes and certificates sections of tech report #122
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rrtoledo
requested changes
Jan 10, 2025
There was a problem hiding this comment.
Sorry for the long awaited review.
That's a very well written and exhaustive document. I think the document could be made a bit clearer however, e.g. if we properly define what the committee and quorum are (perhaps it is done in a different section that I have not read) and gave more arguments on why 500 votes (or is it voters?) would be enough. I am not sure reading this PR if this is due to the stake distribution (which I assumed) or the historical number of unique signers.
I have added some questions and corrections (mostly in the alba-mithril-musen sections).
| - The identifier for the pipeline. | ||
| - This could be omitted because it can be inferred from the EB. | ||
| - The identity of the voter. | ||
| - The number of votes cast. |
There was a problem hiding this comment.
We may also need vote identifiers/labels (for both Mithril and Alba).
| - *ECVRF signature on pipeline identifier and nonce:* 80 bytes | ||
| - *Compressed BLS12-381 signature:* 96 bytes | ||
|
|
||
| The above assumes that the keys for verifying the signature and the proof of possession have already been transmitted. These would need to be registered on the chain, presumably on the Praos chain. |
There was a problem hiding this comment.
Perhaps we could rename "proof of possession" "proof of registration" or even "proof of membership" which is more commonly used in cryptography.
|
|
||
| ### Committee size and quorum requirement | ||
|
|
||
| The combinatorics associated with obtaining a quorum of voters from a mixture of honest and dishonest parties set fundamental limits on the safe size for voting quorums in Leios. (However, the specific choice of certificate scheme my imposing additional limits and security considerations.) We are concerned about both the probability that a quorum of honest votes is reached and the probability that dishonest voters form their own quorum. For Leios, the situation where there are multiple quora of mixed honest and dishonest parties is not equivalent to having a dishonest quorum, though it may cause inefficiencies when EBs with duplicate or clashing transactions are later included in RBs. The table below shows situations that may be encountered. |
There was a problem hiding this comment.
Suggested change
| The combinatorics associated with obtaining a quorum of voters from a mixture of honest and dishonest parties set fundamental limits on the safe size for voting quorums in Leios. (However, the specific choice of certificate scheme my imposing additional limits and security considerations.) We are concerned about both the probability that a quorum of honest votes is reached and the probability that dishonest voters form their own quorum. For Leios, the situation where there are multiple quora of mixed honest and dishonest parties is not equivalent to having a dishonest quorum, though it may cause inefficiencies when EBs with duplicate or clashing transactions are later included in RBs. The table below shows situations that may be encountered. | |
| The combinatorics associated with obtaining a quorum of voters from a mixture of honest and dishonest parties set fundamental limits on the safe size for voting quorums in Leios. (However, the specific choice of certificate scheme may be imposing additional limits and security considerations.) We are concerned about both the probability that a quorum of honest votes is reached and the probability that dishonest voters form their own quorum. For Leios, the situation where there are multiple quora of mixed honest and dishonest parties is not equivalent to having a dishonest quorum, though it may cause inefficiencies when EBs with duplicate or clashing transactions are later included in RBs. The table below shows situations that may be encountered. |
| 3. Larger committees and quorum requirements make it harder for an adversary to obtain a quorum. | ||
| 4. Larger quorum requirements make it easier for an adversary to prevent an honest quorum. | ||
|
|
||
| For Leios the third criterion above is critical, so we need to avoid at all costs a chance of an adversarial quorum. The first and third criteria are important only in that they affect the cost of running Leios nodes. The fourth criterion is less important because it only creates inefficiency leading to lower throughput. |
There was a problem hiding this comment.
You are referring twice to the third criterion, perhaps you mean the second criterion instead in the second sentence?
|
|
||
| ### Number of unique SPOs voting | ||
|
|
||
| Because stake in Cardano is very unevenly distributed among stake pools, it is likely that some stake pools will win several votes in a Leios lottery and many will win no votes. See the section [Stake pool distribution](#stake-pool-distribution) below for a plot of the typical stake distribution on the Cardano mainnet. We need to estimate how many distinct SPO nodes vote in a given round because this affects the number of votes transmitted and the size of the Leios certificate. |
There was a problem hiding this comment.
Wouldn't the number of distinct SPOs be strictly equal to the number of votes? Or are you considering here unweighted ones?
| 4. Using ephemeral keys would make votes smaller, but then a key registration layer would have to be added to the protocol. | ||
| 2. Neither ALBA, BLS, MUSEN, or their ZK variants are clear winners for the best choice of certificate scheme for Leios. | ||
| 1. Each has at least one strength and one drawback related to certificate size, proof time, or verification time. | ||
| 2. ALBA is close to being viable if vote size can reduced or if quorum disruption by adversaries with 10% of stake is acceptable. |
There was a problem hiding this comment.
This 10% adversarial stake is within the committee, which may be possible with smaller overall adversarial stake though! We should compute some numbers here to show the probability of having an adversarial quorum of a given size w.r.t. the total adversarial stake.
| 2. Neither ALBA, BLS, MUSEN, or their ZK variants are clear winners for the best choice of certificate scheme for Leios. | ||
| 1. Each has at least one strength and one drawback related to certificate size, proof time, or verification time. | ||
| 2. ALBA is close to being viable if vote size can reduced or if quorum disruption by adversaries with 10% of stake is acceptable. | ||
| 3. An ALBA security setting of $\ell_\text{sec} = \ell_\text{rel} = 80$ (i.e., eighty-bit security) seems sufficient for Leios voting. |
There was a problem hiding this comment.
Suggested change
| 3. An ALBA security setting of $\ell_\text{sec} = \ell_\text{rel} = 80$ (i.e., eighty-bit security) seems sufficient for Leios voting. | |
| 3. An ALBA security setting of $\ell_\text{sec} = \ell_\text{rel} = 80$ (i.e., eighty-bit security) seems sufficient for Leios voting but the lower security may be not acceptable. |
| 1. Each has at least one strength and one drawback related to certificate size, proof time, or verification time. | ||
| 2. ALBA is close to being viable if vote size can reduced or if quorum disruption by adversaries with 10% of stake is acceptable. | ||
| 3. An ALBA security setting of $\ell_\text{sec} = \ell_\text{rel} = 80$ (i.e., eighty-bit security) seems sufficient for Leios voting. | ||
| 4. BLS is viable if ephemeral keys are used, but those would require pre-registration. |
There was a problem hiding this comment.
Suggested change
| 4. BLS is viable if ephemeral keys are used, but those would require pre-registration. | |
| 4. Mithril is viable if ephemeral keys are used, but those would require pre-registration. |
| 2. ALBA is close to being viable if vote size can reduced or if quorum disruption by adversaries with 10% of stake is acceptable. | ||
| 3. An ALBA security setting of $\ell_\text{sec} = \ell_\text{rel} = 80$ (i.e., eighty-bit security) seems sufficient for Leios voting. | ||
| 4. BLS is viable if ephemeral keys are used, but those would require pre-registration. | ||
| 5. BLS with KES keys could work if oversized Praos blocks (~160 kB) are allowed. |
There was a problem hiding this comment.
Suggested change
| 5. BLS with KES keys could work if oversized Praos blocks (~160 kB) are allowed. | |
| 5. A Mithril variant with KES keys could work if oversized Praos blocks (~160 kB) are allowed but would increase significantly increase the verification time. |
| 4. The clumpiness of the Cardano stake distribution on mainnet means that some producer nodes might cast more than one vote in a given pipeline. | ||
| 5. MUSEN and BLS certificates need further evaluation for Leios. | ||
| 4. Generic benchmarks for cryptographic operations have provided guidance on the pros and cons of the prospective voting and certificate schemes, but further work on estimating CPU resources needed will require detailed implementation of the prospective voting and certificate schemes. For the time being, the following values can be used in simulation studies. | ||
| 1. Number of votes: 600 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please review the votes and certificates sections of the first technical report.