Dear Dapp Developers,
Following a recommendation by the Plutus Cost Model Team based on new benchmark calibration results (plutus/plutus-core/cost-model/data/benching-conway.csv at master · IntersectMBO/plutus · GitHub), Intersect’s Parameter Committee proposes to alter a number of coefficients in the CPU cost model for multiple UPLC operations.
The changes are:
-
an increase of divideInteger (c11) from 549 CPU units to 960 CPU units in Plutus V3
-
an increase of modInteger (c11) from 549 CPU units to 960 CPU units in Plutus V3
-
an increase of quotientInteger (c11) from 549 CPU units to 960 CPU units in Plutus V3
-
an increase of remainderInteger (c11) from 549 units to 960 units in Plutus V3
-
alterations to the cost curve of equalsByteString in Plutus V1, V2 and V3
Collectively, these increases carry a possible risk of transaction failure for scripts that are near their CPU cost cap today and that use these primitives. While it seems unlikely that live scripts would be broken by this change, we recommend that all Dapp Developers should check their scripts’ CPU costs against the new cost model that will shortly be enacted on the Preview network.
Further context: The next intra-era hardfork (vanRossem) will introduce new Plutus primitives; The implementation of these approved CIPs: CIP-109, CIP-132, CIP-133, CIP-138, CIP-153. These primitives will be activated with a Parameter Change Governance Action post-hardfork, alongside which, the above parameters will be changed.
If you have questions reach out here or to the Parameter Committee Co-Chairs on X: @alxaex or @ensurablesys
Thank you!