Split out of #225 so the Core cutover is not blocked on it.
What
COST_PER_EC_OP_REPEAT (prover/host/src/main.rs) stays at 104,222 in the Core-canonical change, while its four siblings were refit to Core's per-curve fit:
| constant |
was (#139/Ghost) |
now (Core) |
COST_PER_EC_OP |
141,612 |
417,798 |
COST_PER_SCHNORR_OP |
1,950,000 |
462,435 |
COST_INPUT_BASE |
34,000 |
41,387 |
COST_PER_INPUT_BYTE |
6 |
2 |
COST_PER_EC_OP_REPEAT |
104,222 |
104,222 ← unrefit |
Why it is almost certainly wrong for Core
104,222 was derived as 0.736 of a fresh key, from a post-G1 (#139) profile: hazync_ecmult_verify 561 M, hazync_lift_x 254 M, scalar inverse 147 M ⇒ the decompression a memo hit avoids is 26.4% of per-verify EC work.
Core's liftx hint (patches/0013) removes most of that decompression. If lift_x is close to free, a repeat key saves much less than 26.4%, so the true Core ratio should be nearer parity, not 0.736. Left as-is the ratio is now an implicit 0.25 (104,222 / 417,798) — further from parity than the value it replaced, in the direction the physics says is wrong.
It bites hard on this block: on 962,000, 6,913 verifying inputs use only 2,160 distinct keys, so 68.8% of inputs take this discount. It is not a rounding term.
⛔ Why it was NOT changed in the cutover
The straggler 1.210 that justifies the whole Core channel was MEASURED with this constant at 104,222, and docs/BUILDS.md §2's recipe sets only the four variables above. Changing a fifth constant would invalidate the number being cited to justify the change — → [[feedback_only_measured_numbers]] applies: no projections.
So it ships unrefit and documented as unrefit, rather than silently "improved" on a plausible-sounding inference.
⚠ There is direct precedent for that inference being wrong. COST_PER_SCHNORR_OP was set equal to COST_PER_EC_OP once G3 put Schnorr through the same accelerator — the obvious deduction — and it measured worse: straggler 1.361 → 1.539, a whole card, because 93 of the block's 145 Schnorr inputs sit in one chunk and the packer over-loaded it. Do not repeat that here by reasoning instead of measuring.
What would settle it
A profile of a Core build (not G1/#139) breaking out hazync_lift_x_hint against the rest of per-verify EC work, giving the real memo-hit saving ⇒ the ratio. Then an A/B on block 962,000, that constant the only difference, reporting straggler and block total — the same shape as the Schnorr experiment.
⏰ Potential upside is real but unmeasured: it mis-prices ~69% of inputs on a representative block. 8 cards needs straggler 1.163 and Core sits at 1.210 — 3.4% over the line. This is a plausible place to find 3.4%; it is not a promise of it.
Split out of #225 so the Core cutover is not blocked on it.
What
COST_PER_EC_OP_REPEAT(prover/host/src/main.rs) stays at 104,222 in the Core-canonical change, while its four siblings were refit to Core's per-curve fit:COST_PER_EC_OPCOST_PER_SCHNORR_OPCOST_INPUT_BASECOST_PER_INPUT_BYTECOST_PER_EC_OP_REPEATWhy it is almost certainly wrong for Core
104,222 was derived as 0.736 of a fresh key, from a post-G1 (#139) profile:
hazync_ecmult_verify561 M,hazync_lift_x254 M, scalar inverse 147 M ⇒ the decompression a memo hit avoids is 26.4% of per-verify EC work.Core's liftx hint (
patches/0013) removes most of that decompression. Iflift_xis close to free, a repeat key saves much less than 26.4%, so the true Core ratio should be nearer parity, not 0.736. Left as-is the ratio is now an implicit 0.25 (104,222 / 417,798) — further from parity than the value it replaced, in the direction the physics says is wrong.It bites hard on this block: on 962,000, 6,913 verifying inputs use only 2,160 distinct keys, so 68.8% of inputs take this discount. It is not a rounding term.
⛔ Why it was NOT changed in the cutover
The straggler 1.210 that justifies the whole Core channel was MEASURED with this constant at 104,222, and
docs/BUILDS.md§2's recipe sets only the four variables above. Changing a fifth constant would invalidate the number being cited to justify the change — → [[feedback_only_measured_numbers]] applies: no projections.So it ships unrefit and documented as unrefit, rather than silently "improved" on a plausible-sounding inference.
⚠ There is direct precedent for that inference being wrong.
COST_PER_SCHNORR_OPwas set equal toCOST_PER_EC_OPonce G3 put Schnorr through the same accelerator — the obvious deduction — and it measured worse: straggler 1.361 → 1.539, a whole card, because 93 of the block's 145 Schnorr inputs sit in one chunk and the packer over-loaded it. Do not repeat that here by reasoning instead of measuring.What would settle it
A profile of a Core build (not G1/#139) breaking out
hazync_lift_x_hintagainst the rest of per-verify EC work, giving the real memo-hit saving ⇒ the ratio. Then an A/B on block 962,000, that constant the only difference, reporting straggler and block total — the same shape as the Schnorr experiment.⏰ Potential upside is real but unmeasured: it mis-prices ~69% of inputs on a representative block. 8 cards needs straggler 1.163 and Core sits at 1.210 — 3.4% over the line. This is a plausible place to find 3.4%; it is not a promise of it.