Context
Per van Rossem (Cardano protocol v11), the new Plutus builtins introduced via CIPs 109, 132, 133, 138, and 153 — including ripemd_160, expModInteger, dropList, lengthOfArray, listToArray, indexArray, plus the bytestring/bit ops 75–85 — are backported to all three Plutus language versions (V1, V2, V3), not only V3.
Sources:
Current state
Pallas now uses amaru-uplc 0.1.0 as the phase-2 backend (since a7b5a86, "switch from txpipe uplc-turbo fork to pragma-org amaru-uplc"). In that crate:
src/builtin/default_function.rs declares all new variants (Ripemd_160 = 86, ExpModInteger = 87, DropList = 88, LengthOfArray = 89, ListToArray = 90, IndexArray = 91).
src/machine/cost_model/builtin_costs/builtin_costs_v3.rs has costing entries for all of them (33 references).
src/machine/cost_model/builtin_costs/builtin_costs_v1.rs and builtin_costs_v2.rs have zero references to the new builtins.
Verified via:
$ grep -c "ripemd_160\|exp_mod_integer\|drop_list\|length_of_array\|list_to_array\|index_array" \
src/machine/cost_model/builtin_costs/builtin_costs_v{1,2,3}.rs
v1: 0
v2: 0
v3: 33
Upstream tracking
Filed upstream as pragma-org/uplc#48. The bulk of the change lives there; this issue tracks the pallas-side bump once upstream lands.
Required change
Either:
- Coordinate upstream with
pragma-org/uplc (see #48) to extend builtin_costs_v1.rs and builtin_costs_v2.rs with the same builtin set, then bump the dependency in pallas-validate/Cargo.toml.
- Or, fork the cost-model files locally in pallas if the upstream timeline doesn't match.
Without this, V1/V2 cost-model arrays decoded from post-v11 PParamsUpdate proposals will fail to map to costing entries, breaking phase-2 evaluation for V1/V2 scripts.
Why this is blocking
Tracked here as it blocks pallas's van Rossem readiness even though the bulk of the change lives in the amaru-uplc crate.
Context
Per van Rossem (Cardano protocol v11), the new Plutus builtins introduced via CIPs 109, 132, 133, 138, and 153 — including
ripemd_160,expModInteger,dropList,lengthOfArray,listToArray,indexArray, plus the bytestring/bit ops 75–85 — are backported to all three Plutus language versions (V1, V2, V3), not only V3.Sources:
Current state
Pallas now uses
amaru-uplc0.1.0 as the phase-2 backend (sincea7b5a86, "switch from txpipe uplc-turbo fork to pragma-org amaru-uplc"). In that crate:src/builtin/default_function.rsdeclares all new variants (Ripemd_160 = 86,ExpModInteger = 87,DropList = 88,LengthOfArray = 89,ListToArray = 90,IndexArray = 91).src/machine/cost_model/builtin_costs/builtin_costs_v3.rshas costing entries for all of them (33 references).src/machine/cost_model/builtin_costs/builtin_costs_v1.rsandbuiltin_costs_v2.rshave zero references to the new builtins.Verified via:
Upstream tracking
Filed upstream as pragma-org/uplc#48. The bulk of the change lives there; this issue tracks the pallas-side bump once upstream lands.
Required change
Either:
pragma-org/uplc(see #48) to extendbuiltin_costs_v1.rsandbuiltin_costs_v2.rswith the same builtin set, then bump the dependency inpallas-validate/Cargo.toml.Without this, V1/V2 cost-model arrays decoded from post-v11
PParamsUpdateproposals will fail to map to costing entries, breaking phase-2 evaluation for V1/V2 scripts.Why this is blocking
Tracked here as it blocks pallas's van Rossem readiness even though the bulk of the change lives in the
amaru-uplccrate.