Fixed synthesis limit - #3374
Conversation
There was a problem hiding this comment.
Pull request overview
Updates consensus logic to apply a fixed block-wide synthesis limit starting at V19 (instead of the V18-era certificate-count-dependent computation), and adjusts tests/documentation to reflect the V18/V19 boundary behavior.
Changes:
- Introduces
Network::STATIC_SYNTHESIS_LIMITand uses it forSubdag::synthesis_limitat V19+. - Adjusts the V18 synthesis-limit test setup so the tested block height lands exactly on V18.
- Updates consensus version docs for V19 and tweaks CircleCI branch gating.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| synthesizer/src/vm/tests/test_v18/blockwide_synthesis_limit.rs | Adjusts VM height setup so the tested block executes at V18. |
| ledger/narwhal/subdag/src/lib.rs | Switches synthesis limit behavior to a fixed limit at V19+ while preserving V18 computation. |
| console/network/src/lib.rs | Adds a network-level constant for the static synthesis limit. |
| console/network/src/consensus_heights.rs | Updates V19 documentation to note the fixed block-wide synthesis limit. |
| .circleci/config.yml | Changes merge-workflow branch gating to include this feature branch name. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
There was a problem hiding this comment.
Shall we do the same for the spend_limit? Just a minor comment.
I think we should keep the spend_limit the same, see this comment: #3366 (comment)
| const SYNTHESIS_PER_SECOND_OF_RUNTIME: u64 = 1_500_000; | ||
| /// Starting with consensus version V19, the synthesis limit is fixed at 15_000_000, roughly 10 seconds of | ||
| /// synthesis work. | ||
| const STATIC_SYNTHESIS_LIMIT: u64 = 10 * Self::SYNTHESIS_PER_SECOND_OF_RUNTIME; |
There was a problem hiding this comment.
STATIC_ is implied by it being a constant. I think SYNTHESIS_LIMIT would be fine.
|
Please set the limit to |
|
How does a user calculate their synthesis limit? Is this communicated with Leo (and maybe SDK)? They had to play catchup on the previous variable/constraint limit, so changes here will affect their internal checks. |
|
2^24 as a density limit is still too restrictive. Our AMM contracts already hit 11M density. We need to increase it drastically; how did you back into these numbers in the first place? |
How was this calculated? On the validator machine specs? |
|
It seems V19 will move back to (increased) combined variable and constraint limits, so this PR is discontinued for now. |
Switches the block-wide synthesis limit introduced in V18 from the value computed there (which depended on the number of certificates in the consensus rounds) to a hardcoded value of 15_000_000 (roughly equivalent to 10 seconds of deployment-verification time).