Move the production evaluator to plutus-core 1.63 (post van Rossem) - #243
Open
Unisay wants to merge 1 commit into
Open
Move the production evaluator to plutus-core 1.63 (post van Rossem)#243Unisay wants to merge 1 commit into
Unisay wants to merge 1 commit into
Conversation
Mainnet has been on van Rossem (protocol v11) since 2026-07-18, but the production track still measured with plutus-core 1.45, whose CEK machine cannot execute a casing artifact at all. Move the production evaluator to 1.63.0.0, the line shipped by cardano-node 11.0.1, and the preview evaluator to 1.67.0.0, the newest release. The pin lives in cape.cabal (^>=1.63, i.e. <1.64), not in cabal.project: constraints in an imported project file are cumulative, so a plutus constraint at project level would intersect with cabal.project.preview's ^>=1.67 to an empty range and make the preview project unsolvable. Cape.Protocol.Parameters carried three stale mainnet limits, unrelated to the fork (epochs 640-648 report identical values; only protocol_major moved): maxTxMemory 14M -> 16.5M, maxBlockMemory 62M -> 72M, maxBlockCpu 40e9 -> 20e9. Fixed here so the tree is not re-measured twice, with the re-verification command recorded in the module haddock. The two causes separate cleanly. The same casing artifact measured under 1.65 and 1.63 gives byte-identical cpu_units, memory_units, term_size and all three fee fields; only the budget percentages move, and those come from the corrected limits. Tree-wide, the Chang to van Rossem cost model shift touches cpu_units.maximum on 23 of 96 submissions, memory_units on none, and total_fee_lovelace on 13, all by under 0.01%. pretty-uplc carried the same parser call as measure-app but without the CPP guard, so it compiled only while pinned at 1.45. Fixed; its output is byte-identical across Plinth, Aiken, Scalus and OpShin artifacts, so no .uplc churn. Both MIN_VERSION_plutus_core(1,46,0) guards are gone now that both projects are above that floor, which lets Cape.PrettyResult drop CPP entirely. The pr-ci.yml preview job did not fire on evaluator changes; its path filter now also matches cape_versions.sh, both cabal projects, and cape.cabal. Refs #242
Contributor
🚀 PR Preview DeployedPreview URL: https://intersectmbo.github.io/UPLC-CAPE/pr-243/ The preview site is automatically updated on every push to this PR and will be removed when the PR is closed. |
Unisay
marked this pull request as ready for review
August 14, 2026 09:58
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
1 participant
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.
Mainnet has been on van Rossem (protocol v11) since 2026-07-18, but CAPE still measured the production track with
plutus-core1.45, a CEK machine that cannot execute a casing artifact at all. This moves the production evaluator to 1.63.0.0, the line shipped bycardano-node11.0.1, and the preview evaluator to 1.67.0.0, the newest release. First half of #242; the submission promotion follows separately.Two independent confirmations that 1.63 is what mainnet charges: the 11.0.1 release-notes component table lists
plutus-core1.63.0.0, and the node's owncabal.projectat that tag pins CHaPindex-state 2026-05-02T16:21:41Z, 19 minutes after 1.63.0.0 was published to CHaP and 9 days before 1.64.0.0.The version pin lives in
cape.cabal(^>=1.63, i.e.<1.64), not incabal.project. Constraints in an imported project file are cumulative, so a plutus constraint at project level would intersect withcabal.project.preview's^>=1.67to an empty range and make the preview project unsolvable.Protocol parameters were stale, independently of the fork
While verifying
Cape.Protocol.Parametersagainst mainnet I found three limits that no longer match, and have not for some time. The van Rossem fork did not touch them: epochs 640 through 648 all report the same values, and onlyprotocol_majormoved.maxTxMemorymaxBlockMemorymaxBlockCpuPrices, per-transaction CPU, and the reference-script tiers were already correct. The source and the re-verification command are now recorded in the module haddock:
curl -s https://api.koios.rest/api/v1/epoch_params | jq '.[0]'.Fixing this here rather than in a follow-up avoids re-measuring all 96 submissions twice.
What moved in the numbers
The two causes separate cleanly. Measuring the same casing artifact under 1.65 and under 1.63 gives byte-identical
cpu_units,memory_units,term_size, and all three fee fields. Only the budget percentages and capacity counts differ, and those come from the corrected limits.Across the whole tree the Chang to van Rossem cost model shift is real but small:
cpu_units.maximummoved on 23 of 96 submissions,memory_units.maximumon none, andtotal_fee_lovelaceon 13, every one of them by under 0.01%. The visible churn in this diff is almost entirely the corrected budget percentages.Verification
submissions/htlc/Plinth_1.65.0.0_Unisay_preview/htlc.uplcis a BuiltinCasing artifact that failed on every happy path under 1.45 withA non-constructor value was scrutinized in a case expression. It now passes all 25 tests under the production binary.pretty-uplcneeded a fix. It carried the same parser call asmeasure-appbut without the CPP guard, so it only compiled while pinned at 1.45. Its output is unchanged: reformatting Plinth 1.45, Plinth casing, Aiken, Scalus, and OpShin artifacts with the 1.63 build produces byte-identical files, so there is no.uplcchurn.Both
MIN_VERSION_plutus_core(1,46,0)guards are gone now that both projects are above that floor, which letsCape.PrettyResultdrop CPP entirely.Known intermediate state
With the threshold at 1.63, the 16 submissions declaring
min_plutus_version1.60 or 1.61 (9 Scalus, 7 Plinth) move onto the production track while still sitting in_previewdirectories, so they show up in the production report under a preview name. The Plinth 1.64 and 1.65 previews stay above the threshold and keep measuring against the preview binary. The follow-up PR promoting the casing builds to default removes both wrinkles, so the two should merge close together.The
previewjob inpr-ci.ymldid not previously fire on evaluator changes: its path filter only matched submission data and the report pipeline, so a PR like this one deployed no preview site to review. Addedcape_versions.sh, both cabal projects, andcape.cabal.