lea-improvement-proposals

LIP: 2
Layer: Core Encoding
Title: Typed Crypto Schemes and Segregated PQC Signature Proofs
Author: Allwin Ketnawang
Created: 2025-04-28
Superseded-By: 6
Status: Replaced

Abstract

This LIP proposes extending the CTE specification to support multiple cryptographic schemes, including Post-Quantum Cryptography (PQC) algorithms like SLH-DSA (also known as SPHINCS+). It utilizes the two previously reserved padding bits within the header bytes of the Public Key List (Tag 00) and Signature List (Tag 01) fields to encode the specific cryptographic scheme being used. For PQC signatures, which are typically very large, this proposal adopts a segregated proof model: only a 32-byte BLAKE3 hash of the PQC signature is stored on-chain within the Signature List field, while the full signature proof is expected to be distributed via a separate mechanism. This allows LEA blockchain transactions to gain PQC resistance while maintaining the core compactness principle of CTE.

Motivation

As quantum computing advances, blockchains need to transition to PQC algorithms to ensure long-term security. However, many PQC signatures are significantly larger than traditional signatures (e.g., Ed25519 used in CTE v1.0), potentially exceeding CTE's strict Maximum Transaction Size limit (1232 bytes). Storing these large signatures directly on-chain would undermine CTE's efficiency and compactness.

This proposal aims to:

Introduce a mechanism to identify different cryptographic schemes (standard ECC and PQC) within the existing CTE structure without consuming new tags.
Enable the use of PQC public keys (specifically SLH-DSA variants) within transactions.
Allow verification of PQC signatures without storing the entire large signature on-chain, by committing only to a secure hash (BLAKE3) of the signature within the transaction data.

This approach maintains small transaction sizes while paving the way for quantum resistance.

Specification

This LIP modifies Sections 4.1 and 4.2 of the CTE v1.0 specification by assigning meaning to the previously reserved bits 1-0 of their respective header bytes.

4.1. Public Key List (Tag `00`) - Updated

Tag: 00
Purpose: Encodes a list of one or more public keys used within the transaction. The type and size of the keys are determined by the header byte's Type Code bits.

Format:

Header Byte:

Bits	Field	Description
7-6	Tag (`00`)	Identifies this as a Public Key List.
5-2	Length (N)	Number of keys in the list (1-15).
1-0	Type Code (`TT`)	Specifies the cryptographic scheme (see table below).

Data: Followed by N contiguous public keys. The size of each key depends on the Type Code.

Type Codes (TT):

`TT` (Bin)	`TT` (Dec)	Cryptographic Scheme	Key Size (Bytes)	Notes
`00`	0	Ed25519	32	CTE v1.0 Default
`01`	1	SLH-DSA-SHA2-128f	32	SPHINCS+ variant public key
`10`	2	SLH-DSA-SHA2-192f	48	SPHINCS+ variant public key
`11`	3	SLH-DSA-SHA2-256f	64	SPHINCS+ variant public key

Constraints:
- The Length field (N) must be between 1 and 15.
- The total size = 1 + (N * Size(Type[TT])) bytes. Implementations must consider the overall transaction size limit.

4.2. Signature List (Tag `01`) - Updated

Tag: 01
Purpose: Encodes a list of one or more cryptographic signatures or signature hashes used to authorize the transaction. The format (full signature or hash) and the underlying scheme are determined by the header byte's Type Code bits.

Format:

Header Byte:

Bits	Field	Description
7-6	Tag (`01`)	Identifies this as a Signature List.
5-2	Length (N)	Number of signatures/hashes in list (1-15).
1-0	Type Code (`TT`)	Specifies the scheme and format (see table below).

Data: Followed by N contiguous signatures or signature hashes. The size of each item depends on the Type Code.

Type Codes (TT):

`TT` (Bin)	`TT` (Dec)	Cryptographic Scheme / Format	Item Size (Bytes)	Notes
`00`	0	Ed25519 Signature	64	CTE v1.0 Default, full signature
`01`	1	BLAKE3 Hash of SLH-DSA-SHA2-128f Signature	32	256-bit hash of the corresponding full PQC signature proof
`10`	2	BLAKE3 Hash of SLH-DSA-SHA2-192f Signature	32	256-bit hash of the corresponding full PQC signature proof
`11`	3	BLAKE3 Hash of SLH-DSA-SHA2-256f Signature	32	256-bit hash of the corresponding full PQC signature proof

Constraints:
- The Length field (N) must be between 1 and 15.
- For TT = 01, 10, 11, the data represents a 32-byte hash generated using the BLAKE3 cryptographic hash function on the full PQC signature.
- The validation process for TT = 01, 10, 11 requires obtaining the corresponding full PQC signature proof from an external source (off-chain mechanism), verifying the proof against the public key, and then hashing the proof with BLAKE3 to compare against the 32-byte hash stored in this field.
- Total size = 1 + (N * Size(Type[TT])) bytes.

Off-Chain Proof Distribution

The mechanism for distributing and retrieving the full PQC signature proofs corresponding to the on-chain hashes (TT = 01, 10, 11 in Tag 01) is outside the scope of this core encoding specification but is a critical component required for validation. Implementations MUST ensure a reliable and secure system for this purpose.

Rationale

Leveraging Reserved Bits: Using the 2 reserved bits in the Tag 00 and 01 headers is the intended mechanism for extending CTE functionality without consuming new tags, maintaining the compact 2-bit tag structure. This provides 4 type codes, sufficient for the default scheme and the initial set of PQC algorithms.
Segregated Proofs: Storing only a hash of large PQC signatures on-chain drastically reduces the data footprint, preserving CTE's suitability for constrained environments. This avoids a potentially massive increase in the Maximum Transaction Size.
BLAKE3 Hash: BLAKE3 is chosen as a modern, high-performance, and secure cryptographic hash function suitable for generating the 32-byte (256-bit) on-chain commitments.
PQC Algorithm Choice: SLH-DSA (SPHINCS+) is selected as a prominent stateless hash-based signature scheme, known for its strong security properties against quantum adversaries. The specific variants (128f, 192f, 256f) offer different security/performance trade-offs.

Backwards Compatibility

Transactions using only Type Code 00 in the Public Key List and Signature List headers remain compatible with CTE v1.0 / v1.1 parsers that ignore or expect the padding bits to be zero.
Transactions utilizing the new Type Codes (01, 10, 11) in either header are incompatible with older parsers. These parsers will likely fail or misinterpret the data due to unexpected key/signature sizes or formats.
Adoption of this LIP requires updating CTE processors to recognize and handle all defined Type Codes for Tags 00 and 01. This change effectively defines CTE v1.2 (or potentially CTE v2.0 depending on community consensus regarding the significance of PQC integration and the segregated proof model).

Security Considerations

Off-Chain Proof Availability & Integrity: The security of the entire system heavily relies on the external mechanism used to distribute and retrieve the full PQC signature proofs. This mechanism must guarantee proof availability for validation and resist tampering or censorship. Delays or failures in retrieving proofs can stall transaction validation. The design of this mechanism is critical.
Validation Logic: Validators must implement robust logic to fetch the correct off-chain proof, verify it using the appropriate PQC algorithm (indicated by the Type Code) against the public key (also typed), and then hash the verified proof with BLAKE3 to compare against the on-chain hash. Any failure in this chain invalidates the transaction authorization.
PQC Public Key Sizes: While this LIP allows specifying different PQC public key types, including the full keys in the Public Key List still consumes transaction space (32, 48, or 64 bytes per key). Applications should consider the impact on the overall transaction size limit.

Copyright

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