Open
Conversation
| - Valid values: `1` to `4`. | ||
| - This field is set only when `is_aggregator: true`. | ||
| - Semantics: | ||
| - `1`: least proof efficiency, fastest proof construction. |
Contributor
There was a problem hiding this comment.
I would suggest renaming "least/highest proof efficiency" by "biggest/lowest proof size".
Collaborator
|
lgtm! |
g11tech
reviewed
Feb 27, 2026
g11tech
reviewed
Feb 27, 2026
g11tech
reviewed
Feb 27, 2026
g11tech
reviewed
Feb 27, 2026
Collaborator
|
Can you also help link this doc to https://github.com/leanEthereum/pm/blob/main/breakout-rooms/leanConsensus/pq-interop/README.md in this PR? Thanks! |
anshalshukla
force-pushed
the
anshalshukla/pq-devnet-4-plan
branch
from
ae839c3 to
24f3baa
Compare
anshalshukla
force-pushed
the
anshalshukla/pq-devnet-4-plan
branch
from
e43aec4 to
d509cc9
Compare
unnawut
reviewed
Apr 15, 2026
Collaborator
unnawut
left a comment
unnawut
left a comment
There was a problem hiding this comment.
Just one request to expand on log_inv_rate description, the rest are pretty minor. Thanks!
| - **Signature aggregation base:** [leanMultisig](https://github.com/leanEthereum/leanMultisig) | ||
|
|
||
| - **Changes** | ||
| - **`log_inv_rate` (protocol-level config):** |
Collaborator
There was a problem hiding this comment.
Can we add a description of what this config means? So far we only define its bounds but not its meaning
| ## Objectives | ||
|
|
||
| 1. Introduce proposer keys for validators (attestation key + proposer key), enabling block signing | ||
| 2. Enable recursive aggregation per message using `leanVm` |
Collaborator
There was a problem hiding this comment.
Not sure if the term leanVM is still valid. I remember most if not all leanVM references were renamed to leanMultisig cc: @TomWambsgans.
But this is cosmetic change and non-blocking.
|
|
||
| ## Completion target | ||
|
|
||
| 2026-03-25 (TBC) |
Collaborator
There was a problem hiding this comment.
Suggested change
| 2026-03-25 (TBC) | |
| 2026-04-30 (TBC) |
Comment on lines
+107
to
+111
| - **Proposer keys:** Each validator now maintains two distinct keys (attestation key and proposer key), enabling block signing. | ||
| - **Recursive aggregation per message:** Proofs for a single `attestation_data` can be recursively aggregated, producing a single aggregated payload per `attestation_data`. | ||
| - **In-block aggregation by proposers:** During block construction, proposers aggregate all proof payloads for a given `attestation_data` and produce a single aggregated payload. A constant `MAX_ATTESTATION_DATA` limits the number of unique `attestation_data` included in a block to 8. | ||
| - **Reduced block size and bandwidth:** With one aggregated payload per `attestation_data` instead of multiple proofs, the number of payloads per block and overall block size are reduced, decreasing network bandwidth usage and improving block propagation efficiency. | ||
| - **Remaining limitation:** A block still contains multiple aggregated payloads (one per `attestation_data`), and proofs remain the largest component of the block. This motivates further compression via block-level proof aggregation (multi-message aggregation) in devnet-5. |
Collaborator
There was a problem hiding this comment.
Suggested change
| - **Proposer keys:** Each validator now maintains two distinct keys (attestation key and proposer key), enabling block signing. | |
| - **Recursive aggregation per message:** Proofs for a single `attestation_data` can be recursively aggregated, producing a single aggregated payload per `attestation_data`. | |
| - **In-block aggregation by proposers:** During block construction, proposers aggregate all proof payloads for a given `attestation_data` and produce a single aggregated payload. A constant `MAX_ATTESTATION_DATA` limits the number of unique `attestation_data` included in a block to 8. | |
| - **Reduced block size and bandwidth:** With one aggregated payload per `attestation_data` instead of multiple proofs, the number of payloads per block and overall block size are reduced, decreasing network bandwidth usage and improving block propagation efficiency. | |
| - **Remaining limitation:** A block still contains multiple aggregated payloads (one per `attestation_data`), and proofs remain the largest component of the block. This motivates further compression via block-level proof aggregation (multi-message aggregation) in devnet-5. |
This should be updated after the devnet is complete
Author
There was a problem hiding this comment.
I've addressed everything except this point as I think we can continue to update this as and when the changes are made
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
No description provided.