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 total calldata length of the two signature-verification precompiles (batchValidateSign at 0x...09, validateMultiSign at 0x...0a): reject calldata whose byte length does not match the positive-tail 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 positive-tail total-length assumption: the per-call energy cost is derived from a formula that treats the calldata as a static head followed by exactly N >= 1 equally-sized tail slots. The current execution path does not enforce the same total-length predicate before decoding — the decoder follows whatever offsets the calldata supplies and zero-pads any missing bytes through Arrays.copyOfRange. The set of byte lengths the precompile currently accepts is therefore a superset of the lengths the pricing formula has 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 or equal to the static head is zero-padded out or treated as empty arrays, 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 total-length gap by rejecting calldata whose byte length is outside the positive-tail predicate.

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 positive-tail total-length predicate the existing energy-cost formula already bakes in. Validation of inner dynamic offsets and full abi.encode conformance is intentionally out of scope.

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 priced tail item. 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 existing decoder runs and follows the offsets supplied by calldata.

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 positive-tail slots. What this TIP fixes is that execute did not previously enforce the same total-length predicate 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 or equal to H words: the static head is not followed by any priced tail item. This includes ABI-encoded empty arrays, which are intentionally rejected because they are the zero-cost boundary that can otherwise still drive decoder work through attacker-controlled offsets.
• (data.length - H*W) mod (I*W) != 0: the tail cannot be priced as exactly N >= 1 items of size I words.

Validation of inner dynamic offsets, array lengths, per-element 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 or equal to the static head — that can otherwise be zero-padded or interpreted as empty arrays. Length-valid inputs with malformed inner offsets can still cause the decoder to read non-canonical locations or 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 positive N (the positive-tail shape pricing has been assuming), the new rule is a no-op and execution proceeds into the existing decoder exactly as before. The inputs whose observable behaviour changes are those whose byte length is incompatible with that formula, plus header-only / empty-array calldata at data.length == H*W.

Header-only / empty-array calldata changes from the legacy soft verification-failure path (execute succeeds with a zero word) to the new malformed-calldata path (execute returns false with empty output; the caller sees the inner call push 0, no return data copied, and the call's pre-allocated energy consumed). This is intentional because such input sits at the zero-cost boundary while still allowing decoder-controlled work in the legacy implementation.

[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.

[alan-eth]

Beautifully framed TIP, @yanghang8612 — pinning rejection and pricing to the same (H, I) constants is a genuinely elegant invariant, and the scope discipline is exactly right. The draft has also converged impressively fast after the back-and-forth. Looking forward to the PR! 🚀

[yanghang8612]

Thanks @lxcmyf — good catch. Asserting the observable reject shape directly is stronger than only checking energy accounting, and it pins the failure mode so it can't be confused with a revert or a tx-level abort.

For the outer-call test I'll extend the assertions to all three:

1. The inner CALL to the precompile returns 1 at the EVM level (success), and the returned 32-byte word is bytes32(0) — i.e. the standard "verification failed" signal that validateMultiSign / batchValidateSign already use, not a revert.
2. The output buffer is exactly one zero word (no partial decode artifacts leaking through).
3. The outer transaction continues past the failed precompile call: a follow-up opcode after the CALL (e.g. an SSTORE or a second CALL) executes normally, and only the precompile's own energy is charged — not the full remaining gas.

This matches the existing soft-reject semantics of both precompiles on signature-verification failure, and makes the post-activation behavior unambiguous for tooling. Will fold these into the test vectors in the next draft.