TIP-854: Canonicalize calldata for signature-verification precompiles

[yanghang8612]

tip: 854
title: Canonicalize calldata for signature-verification precompiles
author: yanghang8612@163.com
discussions-to: https://github.com/tronprotocol/tips/issues/854
status: Draft
type: Standards Track
category: VM
created: 2026-04-12

Simple Summary

Canonicalize the calldata of the two signature-verification precompiles (batchValidateSign at 0x...09, validateMultiSign at 0x...0a): reject calldata whose byte length does not match the shape the per-call energy cost already assumes when pricing the call. On reject, the precompile's execute returns false with empty output; the invoking call frame — reachable through any of CALL / CALLTOKEN / STATICCALL / DELEGATECALL / CALLCODE — consumes its pre-allocated energy, the stack receives 0, memory receives no return data, and the outer transaction continues with its remaining budget intact.

Motivation

These two precompiles charge energy under a fixed shape assumption: the per-call energy cost is derived from a formula that treats the calldata as a static head followed by exactly N equally-sized tail items. The current execution path does not enforce the same shape before decoding — the decoder follows whatever offsets the calldata supplies and zero-pads any missing bytes through Arrays.copyOfRange. The set of byte strings the precompile actually accepts is therefore a superset of the shapes the pricing formula has ever been evaluated for, and many distinct byte strings can represent the same logical call: non-word-aligned calldata has its trailing sub-word bytes silently dropped at parse time, calldata shorter than the static head is zero-padded out, and calldata whose tail length does not decompose into an integer number of items still flows through the decoder.

The effect is that the set of inputs these precompiles accept is larger than the documented interface suggests, which makes them harder to reason about for wallets, SDKs, indexers, audits, and formal specifications. This TIP closes the gap by rejecting calldata whose byte length is incompatible with the shape the pricing formula already assumes. The set of accepted inputs then collapses to exactly the shapes pricing has been computed for.

These two precompiles happen to use Solidity ABI encoding, but the TIP does not claim general Solidity-ABI canonicalisation as the reference. The reference is specifically the shape the existing energy-cost formula already bakes in.

Specification

Let W = 32. For each precompile, let H be the number of static head words it declares, and I the number of words consumed per element of its tail array. H and I are exactly the offset and divisor already present in the per-call energy cost as (words - H) / I:

Precompile	H	I
validateMultiSign	5	5
batchValidateSign	5	6

After activation, at the top of each precompile's execute entry:

• If data == null, or data.length % W != 0, or data.length < H * W, or (data.length - H * W) % (I * W) != 0, execute returns false with empty output, without invoking the decoder and without performing any ecrecover. From the caller's perspective, the invoking call frame consumes its pre-allocated energy, the stack receives 0, memory receives no return data, and the outer transaction continues.
• Otherwise, behaviour is identical to the current implementation.

The per-call energy cost itself is unchanged, and its value on rejected calldata is not observable to the caller: the rejection path is a failed-execution return, and the runtime never evaluates the success-branch refund that would otherwise subtract the cost.

Rationale

The pricing formula has always assumed calldata is a static head followed by an integer number of equally-sized tail items. What this TIP fixes is that execute did not previously enforce the same assumption at runtime. The check is deliberately restricted to exactly what that formula implies:

• Non-multiple-of-32 length: the word-level parser silently drops trailing sub-word bytes, so such input cannot represent an integer number of header-plus-items words for any N.
• Fewer than H words: the static head is not fully present.
• (data.length - H*W) mod (I*W) != 0: the tail cannot be parsed as exactly N items of size I words.

Validation of inner dynamic offsets, full-shape abi.encode conformance, and any further decoder hardening are out of scope for this TIP. They can be addressed in a follow-up if the community wants stronger containment.

As a side observation, the length check also closes one specific path through the decoder — inputs shorter than the static head — that today raises a RuntimeException during word-array access. Length-valid inputs with malformed inner offsets can still cause the decoder to dereference past the end of the parsed word array and are not addressed by this TIP.

Compatibility

This feature is gated behind a hardfork flag and constitutes a hard fork. Pre-activation behaviour, including the per-call energy cost, is byte-for-byte unchanged.

For any calldata whose byte length already satisfies data.length == H*W + I*W*N for some non-negative N (the shape pricing has been assuming all along), the new rule is a no-op. The only inputs whose observable behaviour changes are those whose byte length is incompatible with that formula.

[lxcmyf]

I support this direction.

The main reason is that the current implementation already prices these two precompiles as if calldata had the shape 5 + 5*N words (validateMultiSign) or 5 + 6*N words (batchValidateSign), but execute() does not enforce the same shape before decoding. So adding the boundary check makes pricing and decoding consistent with each other.

It also seems like the right failure mode: return the normal precompile failure value (bytes32(0)) instead of letting malformed calldata escape as a generic runtime failure.

The key regression tests to add would be:

• non-32-byte-aligned calldata
• fewer than 5 words
• valid 32-byte alignment but invalid tail remainder for each precompile
• an outer contract call proving malformed inner calldata does not consume the whole transaction energy after activation

[waynercheung]

@yanghang8612 This is a good direction and I support it, but I think the TIP should tighten a few points so the spec matches the current implementation more precisely.

1. 5 + 5*N / 5 + 6*N is not "canonical Solidity ABI" in the general sense. It is a stricter, precompile-specific shape that only holds if each signature element is treated as a 65-byte item. Also, batchValidateSign(bytes32,bytes[],address[]) has two dynamic arrays, not one.

2. In java-tron, pricing happens before execution: Program.callToPrecompiledAddress() calls getEnergyForData(data) before execute(data). So if the guard is only added at the top of execute(), pricing and decoding are still not fully aligned. The rejected-input rule should also be reflected at pricing time, or validation should happen before pricing.

3. A total-length check alone does not fully guarantee that malformed calldata cannot still escape as a runtime failure, because there are still unchecked dynamic-offset dereferences in the current decoder path. If full containment is a goal, offset validation (or helper hardening) should also be in scope. Otherwise the rationale should state more narrowly that this TIP only rejects obvious total-length mismatches.

4. The text should pick one observable failure semantic and state it consistently: either "the precompile returns bytes32(0)" or "the CALL fails and pushes 0 on the stack". Those are different behaviors.

Ethereum precedent is mixed here, so I think the strongest justification is the TRON-specific mismatch today between pricing, decoding, and failure propagation.

[yanghang8612]

@lxcmyf Thanks. That "pricing already assumes the 5 + N*item shape but decoding doesn't" framing is exactly the mental model behind the draft — after activation the energy formula and the boundary check share the same (H, I) per precompile, so the two can't drift.

Test buckets map cleanly:

• Non-32-aligned: length = 32*k + r, r ∈ {1, 31}.
• Fewer than 5 words: length ∈ {0, 32, 64, 96, 128}.
• Aligned but bad tail: length = 32*(5 + k) with k % I != 0 (k ∈ {1..4} for validateMultiSign, k ∈ {1..5} for batchValidateSign).
• Outer-frame containment: a fixture contract CALLs the precompile with malformed calldata, then does work after. Assert the outer tx completes and tx.energyUsed is bounded by outer overhead + msg.gas of the inner call.

Will add all four in the PR.

[xxo1shine]

@yanghang8612 This looks like a reasonable direction.

I have a question regarding potential side effects: will this change affect any existing behavioral consistency between pricing (getEnergyForData) and execution (execute), especially for malformed but previously accepted inputs?

Also, since this changes the runtime behavior for out-of-spec calldata, should this be explicitly treated as a hard fork?

[yanghang8612]

@waynercheung Thanks — checking each against the text:

(1) Fair. The draft body does frame the change as "treat Solidity ABI encoding as the canonical input form" / "canonicalize the input format", which overclaims in exactly the sense you describe — the title says "canonicalize calldata", but the body treats the canonical form as ABI specifically. I'll weaken that: the premise is that these two precompiles happen to have chosen ABI encoding for their input, but the TIP's scope is canonicalizing these precompiles' calldata, not claiming Solidity ABI is the reference. Concretely the text will shift to describe the rejected shapes in terms of (words - H) / I (the formula already in getEnergyForData) rather than in terms of a general ABI property.

(2) I'd push back here. getEnergyForData(byte[]) isn't proposing to describe what counts as well-formed input — it's a conditional price: "if the input is shaped H + N*I, the cost is N * 1500". That shape assumption is correct on its own; validation is execute's job. With the guard at the top of execute returning a failed inner-CALL signal, the refund math that would otherwise evaluate msg.getEnergy() - requiredEnergy is never reached — getEnergyForData's value on rejected inputs is internal and not observable to the caller. Adding a symmetric validator inside getEnergyForData would duplicate the shape assumption without changing any observable behaviour.

(3) Agreed. Rationale narrows to "align execute's input check with the shape getEnergyForData already assumes". Dynamic-offset validation and further decoder hardening are out of scope for this TIP; they can be a follow-up if the community wants stronger containment.

(4) Fair — current text is inconsistent. The Summary reads as "precompile returns bytes32(0)" (implies CALL succeeds, memory has 0), while Motivation (2) and the Specification bullet describe the (false, ...) semantics ("failed inner call", "stack receives 0"). I'll pick one and state it consistently: on reject, the inner CALL fails, the stack receives 0, memory receives bytes32(0), the CALL's pre-allocated energy is consumed, and the outer transaction continues.

[lxcmyf]

@yanghang8612 Makes sense. These four buckets cover the main edges pretty well. For the last one, I would also assert the observable reject semantics directly: inner CALL returns 0, output word is zero, and the outer tx still continues.