lea-improvement-proposals

• LIP: 4
• Layer: Core Encoding
• Title: Decouple Legacy Index Field from List Context
• Author: Allwin Ketnawang
• Created: 2025-05-01
• Superseded-By: 6
• Status: Replaced

Abstract

This LIP proposes modifying the definition and processing rules for the IxData Field Sub-Type 00 ("Legacy Index Reference"), as introduced in LIP-1. While retaining its semantic meaning as an index into a Public Key List or Signature List present within the transaction, this proposal removes the requirement that the index field must immediately follow the list it references. The responsibility for associating the index with the correct list and performing the bounds check is shifted from the raw decoder to the higher-level application logic consuming the decoded stream.

Motivation

The current specification (CTE v1.1 / LIP-1) requires the IxData Sub-Type 00 field (10 IIII 00) to immediately follow the Public Key or Signature List it references. This restricts its use, particularly within Command Data (Tag 11). This proposal allows the 10xxxx00 field to appear anywhere, including within the encoded payload of a command (e.g., smart contract arguments). This enables commands or contracts to compactly reference items (like public keys or signatures) from lists defined earlier in the transaction, leaving the interpretation (which list is referenced) and bounds checking to the application or contract logic.

Specification

This LIP modifies the description and constraints associated with Section 4.3.1 ("Sub-Type 00: Legacy Index Reference") of the CTE specification, as previously defined by LIP-1. The field format remains unchanged.

The modified Section 4.3.1 reads as follows:

---

4.3.1. Sub-Type 00: List Index Reference

• Sub-Type Code (SS): 00
• Purpose: Provides a zero-based index referencing an item within a Public Key List (Section 4.1) or Signature List (Section 4.2) that exists elsewhere within the same CTE transaction.
• Format:
  • Header Byte: 10 IIII 00

    Bits	Field	Description
    7-6	Tag (10)	IxData Field family.
    5-2	Index (IIII)	The 4-bit index value (0-15).
    1-0	Sub-Type (00)	Specifies List Index Reference format.

  • Data: No following data bytes.
• Constraints:
  • The Index value (IIII) MUST correspond to a valid position within the intended target list (Public Key or Signature List).
  • The association between this index field and its target list (i.e., whether it refers to the Public Key List or the Signature List) is not defined at the raw CTE encoding layer but MUST be defined by the application or higher-level protocol interpreting the CTE stream.
  • The validation that the Index value is within the bounds of the target list (Index < list_size) MUST be performed by the application logic, using the decoded index and the size of the appropriate target list (obtained when decoding that list).
• Total Size: 1 byte.
• Reserved Values: None within this sub-type.
• Example (Encoding index 1): Header Byte: 10 0001 00 = 0x84. (The application logic determines if this refers to the PubKey list or Sig list and performs bounds checks accordingly).

---

Summary of Changes:

1. The section title is changed back to "List Index Reference" (or similar) to reflect its purpose.
2. The description clarifies that the referenced list can be elsewhere in the transaction, not necessarily immediately preceding.
3. Explicit constraints are added stating that:
   • The target list association is application-defined.
   • The bounds checking responsibility lies with the application, not the raw decoder.
4. The previous decoder constraint requiring last_list_count > 0 is removed from the raw decoding step for this field.

Rationale

This approach balances flexibility with semantic clarity:

• Flexibility: Allows indices to be placed anywhere, including within Command Data payloads, enabling more complex or optimized transaction structures and smart contract interactions.
• Preserved Meaning: The field (10xxxx00) retains its specific meaning as a list index, preventing it from being overloaded as a generic 4-bit integer, which could lead to ambiguity.
• Clear Responsibility: Explicitly defines that the context (which list is targeted) and bounds validation are application-level concerns. The raw CTE decoder's job is simply to extract the 4-bit index value from this field type.
• Minimal Encoding Change: Achieves the goal without altering the byte-level format of the field itself.

Security Considerations

• Application-Level Validation Crucial: The primary security consideration is ensuring that the application logic correctly associates each index with its intended target list and performs rigorous bounds checking. Failure to do so could lead to vulnerabilities, such as using the wrong public key for verification or referencing non-existent signatures.

Copyright

This LIP is licensed under the MIT License, in alignment with the main LEA Project License.