Cardano Proposes Removing Plutus Scope Check

Cardano proposal CIP-0205 would eliminate one of the steps used to prepare Plutus scripts for execution. Author Jacco Krijnen proposes handling unbound variable errors during execution instead of checking the entire program beforehand. Submitted on September 25, the proposal remains under review.

The Cost of Preparing Plutus Scripts

Before executing a script, a node checks that its variables are properly defined within the program. Known as a scope check, this takes place during the second phase of transaction validation.

Earlier benchmarks cited by the proposal found that the check accounted for roughly 20% of script preparation time, including decoding and version checking. In full validation benchmarks, it represented approximately 3% of total validation time. These figures measure the check’s share of processing time in those test workloads.

Removing it would reduce processing work for eligible scripts. Any resulting reduction in transaction fees would depend on subsequent adjustments to fee parameters, according to the proposal.

How Plutus Would Handle Variable Errors

Plutus Core is the language used to execute smart contract scripts on Cardano. Its execution engine, the CEK machine, already handles attempts to use variables without a bound value.

In the proposal’s review discussion, developer Seungheon Oh noted that CEK does not depend on the preliminary scope check. Attempting to evaluate an unbound variable results in an ordinary execution failure.

Under the proposed rules, a program could succeed if an unbound variable appears only in code that is never executed. Properly scoped programs would retain the same execution results.

Development languages including Aiken, Plinth and Plutarch already enforce variable scoping through their type checkers before scripts reach the blockchain, the proposal notes.

A New Language Version and Hard Fork

The draft ties the change to Plutus Core language version 1.2.0, which would require a hard fork. Implementation would include updates to the specification, execution code, formal model and conformance tests.

The proposal received the number CIP-0205 on September 29. CIP editor Robert Phair requested wider circulation among working groups before the review proceeds, citing the breadth of the change.

Under the current draft, existing scripts using language versions 1.0.0 and 1.1.0 would retain their behavior. After activation, new scripts declaring version 1.2.0 could execute without the separate preliminary scope check.