Self-Usable Transaction Outputs

Abstract

We propose to allow transactions to reference scripts and data present on their own outputs during validation.

Motivation: Why is this CIP necessary?

Transaction outputs carry scripts (via reference scripts). However, the Cardano Ledger currently enforces a restriction that prevents a transaction from satisfying its validation requirements using scripts contained within its own outputs.

This restriction creates a specific inefficiency: if a transaction produces an output containing a script that is also required to validate that same transaction, the transaction cannot utilize the copy present in the output. Instead, the transaction must provide a redundant copy of the same script in the transaction witnesses. This forced redundancy increases transaction size, and thus transaction fees, directly inflating the costs incurred by users.

In combination with the upcoming feature of nested transactions, in the Dijkstra era, the current restriction imposes a strict constraint in how scripts can be shared within a batch. Specifically, without this proposal, scripts produced in transaction outputs are only accessible to subsequent sub-transactions (via reference inputs). This forces transaction builders to artificially order transactions or to provide redundant copies of the same script (e.g., if two sub-transactions mutually depend on each other's script).

The key idea of this CIP is to remove this restriction, allowing transactions to reference their own outputs for validation purposes.

Use cases

Combine publishing reference scripts with first usage

Currently deploying stateful dApps on Cardano requires a multi-transaction workflow:

• First transaction: Deploy the dApp's script as a reference script in the UTxO.
• Second transaction: Reference this script (via reference inputs) to mint state tokens.

(Note that this can be achieved swapping the order of transactions. However, it still requires two transactions)

With the proposed changes, such applications could be deployed in a single transaction, which simultaneously deploys the reference script UTxO's and mints the state token. This eliminates the need for submitting multiple transactions, thereby reducing costs, while at the same time improving the developer's experience.

Nested transactions: order-agnostic script sharing across a batch

The nested transactions CIP specifies that scripts are to be shared among all sub- and top-level transactions within a batch (see CIP-0118 > Changes to Transaction Validity).

With the current restriction, this requirement can only be partially achieved by sharing scripts either (1) from transaction witnesses or (2) via reference inputs that point to outputs of sub-transactions in the same batch which have already been applied to the UTxO state.

With the proposed change in this CIP, the requirement can be achieved allowing scripts to be shared directly from transaction outputs, regardless of which sub- or top-level transaction they appear in. This eliminates the dependency on processing order and enables more flexible script sharing within the batch.

Specification

There is an Agda specification prototype of the proposed changes (for Conway).

Changes to the Ledger logic

• The function txscripts needs to be modified to include scripts from txouts.

Rationale: How does this CIP achieve its goals?

The current logic in Ledger rules does not utilize scripts present in transaction outputs during validation. This restriction comes at the cost of redundancy when the same script serves dual purposes: being included in an output for future use and being required for current validation.

This CIP achieves its goal by enhancing the Ledger rules so that validation may reference scripts committed in the transaction body’s outputs, which removes the need to carry duplicate copies in witnesses and reduces transaction size and fees.

Backward compatibility

The changes proposed in this CIP do not break backward compatibility of any of the older Plutus scripts.

Path to Active

Acceptance Criteria

• Fully implemented in Cardano node

Implementation Plan

• Update the formal Ledger specification with "changes to the Ledger logic" above
• Implement the outlined changes in the Cardano node
• Complete a hard fork enabling support for the changes outlined here

Copyright

This CIP is licensed under CC-BY-4.0.