CIP-0167

Remove `isValid` from transactions

Status
Proposed
Category
Ledger
Created
License
CC-BY-4.0
Authors
Teodora DanciuAlexey Kuleshevich
Implementors
N/A
Discussions
Discussion 1

Abstract

We propose removing the isValid boolean from the CBOR encoding of standalone transactions (e.g. for mempool). This would not affect the serialization of the transactions within blocks, since isValid flag is already stored separately from the transaction

Motivation: why is this CIP necessary?

The isValid flag in standalone transaction CBOR is not intrinsic to the protocol or to the lendger-consensus boundary:

  • it is not signed by the transaction creator, so anyone can set it to any value they like.
  • for block validation: the value that is used is the one that was set by the consensus protocol
  • for remote submissions from untrusted nodes: the node ignores the incoming flag, evaluates the transaction as if isValid = True, if phase-2 fails for that reason alone - admits it to the mempool with isValid = False so collateral can be collected.

The only remaining use is local submission from trusted clients (like cardano-cli), where the node reads the flag to avoid unintended collateral burn. This use is important, but perhaps the transaction bytes are not the best layer to encode that intent.

Removing the flag simplifies encoding/decoding, slightly reduces on-wire size, and eliminates semantic ambiguity. Futhermore, because the flag is non-witnessed (excluded from the transaction ID), it cannot be trusted; keeping it invites inconsistency and confusion.

Specification

Currently, a stand-alone transaction is serialized like this:

transaction = [transaction_body, transaction_witness_set, bool, auxiliary_data/ nil]

The proposal is to change it to:

transaction = [transaction_body, transaction_witness_set, auxiliary_data/ nil]

Rationale: how does this CIP achieve its goals?

Removing the isValid flag from standalone transaction serialization simplifies the wire format without changing consensus or ledger semantics.

The trusted local client submission use case might be better expressed in a different way (for example, as a Node-to-Client submit parameter), rather than embedded in the transaction bytes.

Path to Active

Acceptance Criteria

  • Transaction serializers and deserializers in cardano-ledger are implemented such that they follow the cddl specification described above, and reflected in the cddl specs
  • The feature is integrated into cardano-node with necessary adjustments made to ouroboros-consensus and released as part of the Dijkstra era hard fork

Implementation Plan

The implementation of this CIP should not proceed without an assessment of the potential impact on all the components that deserialise standalone transactions.

This CIP is licensed under CC-BY-4.0.