Intention to ChangePlutus script memory unit limits (maxTxExecutionUnits[memory] and maxBlockExecutionUnits[memory])

Governance Parameters Committee Updates
1

Intersect’s Parameter Committee proposes a Parameter Update governance action that will increase Plutus script memory unit limits to allow greater flexibility for DApp developers. This post gives the constitutionally necessary notice of this intention to the community.

Motivation

The update is motivated by the desire of some Community members o increase the Plutus script memory unit limits to simplify DApp development and enhance scalability - see PCP-003.

Rationale

Intersect’s Parameter Committee proposes to update the Plutus memory unit limits to enable more work to be done by a Plutus script.

Technical Evaluation

The changes described here have been recommended by Intersect’s Parameter Committee on 2025-05-08.

Functionality

As described below, the main effect of the update will be to enable more work to be done by Plutus scripts within a single block. This removes or reduces pain points for DApp developers and users.

Security

No specific security concerns are raised by this change. Performance results indicate that Praos timing guarantees will be maintained following this change.

Performance

There is no impact on overall performance or timing guarantees from increasing maxTxExecutionUnits[memory]. The impact on overall performance from increasing maxBlockExecutionUnits[memory] has been evaluated by IOE’s Performance and Tracing team using node versions 10.2 and 10.3. These benchmarking results indicate that there is adequate headroom in critical timing metrics to allow the proposed increase.

Sustainability

The upgrade:

  1. reduces a pain point when building Plutus scripts (reducing the need for manual tweaking to meet per-transaction limits);

  2. allows more work to be done by an existing Plutus script;

  3. potentially allows more Plutus scripts to execute per block, if the work remains the same;

These upgrades ensure decentralized applications on Cardano can scale sustainably.

Plutus Memory Unit Changes

Both per-transaction and per-block Plutus memory unit limits will be increased by 25% in total. This will maintain the ratio between the parameters, ensuring that the same number of maximally sized transactions will fit into a single block.

  1. maxTxExecutionUnits[memory] will be increased from 14,000,000 memory units to 17,500,000 memory units;

  2. maxBlockExecutionUnits[memory] will be increased from 62,000,000 memory units to 77,500,000 memory units.

In order to ensure consistency with the guardrails, the change will be executed in two stages. In the first stage:

  • maxTxExecutionUnits[memory] will be increased from 14,000,000 memory units to 16,500,000 memory units (a 17.9% increase);

  • maxBlockExecutionUnits[memory] will be increased from 62,000,000 memory units to 72,000,000 memory units (an 18.1% increase).

In the second stage:

  • maxTxExecutionUnits[memory] will be increased from 16,500,000 memory units to 17,500,000 memory units (a 6.1% increase);

  • maxBlockExecutionUnits[memory] will be increased from 72,000,000 memory units to 77,500,000 memory units (a 7.6% increase).

Impact of the Change to Memory Unit Limits

The Plutus memory unit settings serve to limit the total execution time that a Plutus script can take, as well as the memory usage. Measurements show that this is a more significant restriction on total Plutus execution time than maxTxExecutionUnits[steps] and maxBlockExecutionUnits[steps]. The limits have been increased historically, but were restricted by the need to adhere to Praos security guarantees. New benchmarking results following improvements to the Plutus interpreter and elsewhere indicate that there is now sufficient headroom to increase these limits.

Scope for Further Changes in Future

This is a deliberately conservative change. Further increases in either or both per-transaction and per-block memory unit limits may be possible following careful measurement of the on-chain effect of this change (taking into account possible future increases in e.g. block sizes).

Consistency with Guardrails

This post provides the necessary advance notice for changing maxBlockExecutionUnits[memory], as required by PARAM-04a:

  • PARAM-04a: At least 3 months should normally pass between the publication of an off-chain proposal to change a critical protocol parameter and the submission of the corresponding on-chain governance action. This Guardrail may be relaxed in the event of a Severity 1 or Severity 2 network issue following careful technical discussion and evaluation.

In order to ensure consistency with MTEU-M-04: and MBEU-M-03, this change will be executed in two stages:

  • MTEU-M-04: maxTxExecutionUnits[memory] should not be increased by more than 2,500,000 units in any epoch

  • MBEU-M-03: maxBlockExecutionUnits[memory] should not be changed (increased or decreased) by more than 10,000,000 units in ANY epoch

Reversion Plan

This change has minimal or no effect on overall network performance, so it is unlikely to need to be reverted. The change to maxTxExecutionUnits[memory] could be reverted, if necessary, to its current setting. However, the change can only sensibly be reversed if no transactions or scripts have taken advantage of it: reverting maxTxExecutionUnits[memory] to its present setting would cause disruption to any DApp developers and users that have exploited it, requiring them to rewrite or reconfigure their Plutus scripts. Reverting this setting without also reverting maxBlockExecutionUnits[memory] would increase the number of full-sized Plutus script transactions that could be processed in a single block. This is unlikely to be harmful.

The change to maxBlockExecutionUnits[memory] could be reverted to its current setting if network performance showed an unexpectedly negative impact. Reverting it without also reverting maxTxExecutionUnits[memory] could, however, reduce the number of full-sized Plutus script transactions that could be processed in a single block.

References

7 Likes