[Feature] TRON Post-Quantum Signature Migration

[Federico2014]

Summary

Introduce post-quantum (PQ) digital signature support at the TRON protocol layer. The first activation enables only Falcon-512 as the sole post-quantum signature algorithm, covering all consensus-flow signatures. The design principle is to leave the Account structure unchanged — the address field carries both ECDSA- and Falcon-derived addresses in an "algorithm-agnostic" way. New PQAuthSig fields are added to Transaction, Block, and HelloMessage payloads, and verification is routed to the matching path based on which signature field is set. The entire capability is gated by an on-chain governance proposal.

Target timeline: launch the testnet in Q2 2026, completing the deployment ~3 years ahead of the industry-projected quantum-threat threshold (~2029) and positioning TRON as the first major public blockchain to complete a full PQ migration.

Problem

Motivation

All major blockchains today (TRON, Bitcoin, Ethereum, BNB Smart Chain, etc.) use elliptic-curve cryptography (ECDSA) for consensus-flow signatures. The security of ECDSA rests on the discrete-logarithm problem — billions of years for a classical computer, but only minutes for a quantum computer running Shor's algorithm. The industry widely projects the quantum-threat threshold to arrive around 2029; on Bitcoin alone, over 6.9M BTC (~1/3 of supply) sit at addresses whose public keys are already exposed.

Cryptographic migration itself is highly complex: protocol changes, third-party security audits, and adoption across wallets, exchanges, and contract ecosystems typically take a long time. Waiting until the quantum threat actually arrives is too late — the work must start now.

Current State

• All TRON transaction and block signatures currently use secp256k1 ECDSA, with addresses derived as 0x41 ‖ Keccak-256(ecdsa_pk[1:])[12..32]. The protocol layer carries no post-quantum-signature fields.
• The TVM precompiles ValidateMultiSign, BatchValidateSign, and ECRecover all depend on ECDSA and cannot be directly reused for PQ signatures, which require an explicit public key as an input parameter.

Post-Quantum Algorithm Challenges

PQ algorithms, like ECDSA, are based on public-key / private-key pairs, but porting them to the protocol layer raises several core challenges.

Explicit public-key transmission — the core problem to solve in this cycle

ECDSA has the Swiss-army-knife ecrecover: given a 65-byte secp256k1 signature, the node can recover the public key (65 bytes) and derive the account address (21 bytes). This lets the TRON transaction carry no public key at all; all upper-layer protocols rest on this implicit convention.

Falcon, ML-DSA, SLH-DSA, and other PQ algorithms have no equivalent recover primitive:

• Falcon key recovery is still at the academic-research stage; BouncyCastle 1.84 has not yet exposed any related API.
• ML-DSA / SLH-DSA do not, by design, support recovering the public key from a signature.

In other words, to verify a PQ signature, a node must first obtain the full public key — that is the first problem this round of protocol changes must solve. The concrete design choice boils down to where to store the public key. We weighed two paths:

• Option A — store the PQ public key on chain; transactions only reference it. The transaction body still grows ≥ 5× because the Falcon signature alone is ~11× the size of an ECDSA signature. Additional costs: passively activated accounts have no public key on file, account state inflates significantly, wallets cannot sign without reading real-time on-chain data, and the protocol layer itself requires substantial new design — on-chain key-storage layout, the reference mechanism used from transactions, key-rotation semantics, etc. — none of which has a validated, mature precedent in any major chain today, translating into notable stability risk.
• Option B — carry the PQ public key inside each transaction. Benefits: minimal protocol intrusion (account state fields are unchanged), zero friction for passively activated accounts, and stateless signing from wallets / SDKs. The only downside compared with Option A is that the transaction body grows ~10× (a cost that can be optimized over time).

Weighing the three dimensions of "minimal intrusion into the existing protocol, lowest first-release implementation cost, smallest ecosystem-side change", we choose Option B. The protocol-size cost is mitigated chiefly by Falcon key-recovery, with a possible BLOCK_SIZE increase as a benchmarked follow-up, whereas Option A's architectural problems (passive activation, state inflation, Account-structure breakage) would be virtually irreversible once shipped. Implementation details are covered below in Proposed Design.

Per-signature size inflation — known cost, optimizable in stages

A side effect of carrying the public key is the jump in signature footprint: a Falcon-512 public key + signature is ~25× the ECDSA size, and the average transaction body grows ~9.5×. The table below compares ECDSA against three PQ candidates:

Algorithm	Public key	Signature
secp256k1 ECDSA	33 B (compressed)	65 B
Falcon-512	896 B	≤ 752 B (variable)
ML-DSA-44	1312 B	2420 B
SLH-DSA-128s	32 B	7856 B

Ten ML-DSA / SLH-DSA transactions combined would approach or exceed the block-size cap (2MB) — Falcon-512 is the only PQ algorithm whose size profile is viable this cycle, which is why we select it as the sole algorithm.

This constitutes a material protocol-layer overhead and is treated as an explicit trade-off rather than a minimized concern. As the initial launch design — with PQ adoption expected to stay low (< 10%) in the early phase — the size growth is acceptable and not a launch blocker. Concrete post-launch optimization paths can be rolled out as adoption ramps up:

• Falcon key-recovery mode — trims roughly 9% off per-transaction wire size by reconstructing the public key from the signature instead of carrying it.
• BLOCK_SIZE increase — available as a fallback, but only via a separate dedicated TIP through the standard governance process. The change affects FullNode bandwidth, state growth, block-propagation time, and archive storage, so it must not be bundled with this PQ rollout.

Proposed Solution

Proposed Design

Core design principles: the Account protocol structure is completely unchanged. The account address is derived from the signing public key via Keccak-256, and the derivation is decoupled from the signing algorithm — ECDSA and Falcon public keys share the same slicing rule and produce addresses in the standard 21-byte T-prefixed form (e.g. TTW663tQYJTTCtHh6DWKAfexRhPMf2DxQ1).

Transactions and blocks add a PQAuthSig field to carry the full PQ signature along with its public key. This field coexists with the original signature field; it is neither a replacement nor mutually exclusive, except for block signatures, where only one of the two may be set. Nodes dispatch verification based on which field is present:

• signature takes the ECDSA path, using ecrecover to recover the public key from the signature;
• pq_auth_sig takes the PQ path, reading the embedded public_key directly.

After obtaining the public key, both paths converge on the same permission-check flow: derive address → match against Permission.keys[] → accumulate weight → compare against threshold. A single transaction may carry a mix of ECDSA and Falcon signers, with their weights pooled into one sum.

1. New PQ signature structure

message PQAuthSig {
  PQScheme scheme     = 1;   // Mandatory; UNKNOWN_PQ_SCHEME (proto3 default) is rejected at validation time. See Compatibility for rationale.
  bytes    public_key = 2;
  bytes    signature  = 3;
}

enum PQScheme {
  UNKNOWN_PQ_SCHEME = 0;   // proto3 default value (reserved per API-evolution convention)
  FN_DSA_512        = 1;   // Falcon-512 (enabled at first launch)
  reserved 2 to 15;        // Future expansion: ML-DSA / SLH-DSA ... (protocol-reserved)
}

// Example: the transaction body gains a PQAuthSig field
message Transaction {
  ...
  repeated bytes signature = 2;
  ...
  repeated PQAuthSig pq_auth_sig = 6; // newly added field
}

2. Four PQ signature channels and field additions

Channel	Field	Relationship with ECDSA
Transaction	repeated Transaction.pq_auth_sig = 6	May coexist; a multi-sig account can be authorized by a mix of ECDSA + Falcon signers, and the transaction is accepted once accumulated weight ≥ threshold
SR block production	BlockHeader.pq_auth_sig = 3 — by delegating its witness permission to a new quantum-resistant account, the SR account enables PQ block production while keeping the SR address unchanged	Mutually exclusive with witness_signature — only one may be set
Relay handshake	HelloMessage.pq_auth_sig = 12 (set / verified by RelayService)	Mutually exclusive with HelloMessage.signature — only one may be set, determined by whether the local node has an ECDSA or PQ key configured
TVM signature verification	Three new precompiles (see §5)	The public key must be supplied as an input parameter; coexists with ValidateMultiSign, BatchValidateSign, and ecrecover

3. Address derivation (identical form to ECDSA derivation)

falcon_address = 0x41 ‖ Keccak-256(falcon_public_key)[12..32]

The address stays 21 bytes with the T prefix, fully compatible with the existing ECDSA address format; only the hash input differs. Collision probability is algorithm-independent and remains at 1 / 2^160.

4. Signature target (unchanged)

• Transaction signature target: txid = SHA-256(Transaction.raw)
• Block signature target: blockHash = SHA-256(BlockHeader.raw)
• Relay-identity signature target: SHA-256(BigEndian(timestamp)) (inherits the existing ECDSA digest construction)

5. TVM precompiles (three new, input layout aligned with EIP-8052)

Address	Name	Algorithm	Energy
0x16	VerifyFnDsa512 (single signature)	FN-DSA / Falcon-512	4000
0x17	ValidateMultiFnDsa512 (algorithm-agnostic account multi-sig, MAX_SIZE=5 signatures)	ECDSA + Falcon-512	ecdsaCnt × 1500 + pqCnt × 2000
0x18	BatchValidateFnDsa512 (batch independent verification, MAX_SIZE=16 signatures)	FN-DSA / Falcon-512	cnt × 2000

All three are gated by the ALLOW_FN_DSA_512 governance proposal. We do not reuse 0x09 / 0x0A because the PQ verification interface verify(pk, msg, sig) → bool provides no way to recover the public key — the caller must supply the full public key explicitly.

Note: the energy figures above are placeholders. Final values will be set through JMH benchmarking and calibration against existing ECDSA precompile pricing — see Open Questions §2 for the calibration plan.

6. Governance activation

Proposal	Number	Scope
ALLOW_FN_DSA_512	99	All Falcon-512 signature channels (Tx / Block / HelloMessage) + TVM precompiles (0x16 / 0x17 / 0x18)

7. Performance

Metric	ECDSA	Falcon-512 (with public key)
Verify time	1195 μs	114 μs (~10× faster)
Sign time	3177 μs	1905 μs (~1.7× faster)
TRX transfer avg size	175 B	~1670 B (~9.5×)

TPS ceiling scales with the blended average transaction size against a roughly constant block-byte throughput of ~666 KB/s:

PQ adoption mix	Blended avg tx size	TRX TPS ceiling
0% PQ (pure ECDSA, today)	175 B	~3809 (baseline)
10% PQ + 90% ECDSA	~325 B	~2054 (≈54% of baseline)
100% PQ (worst case)	~1670 B	~399 (≈10% of baseline)

During the transition, Falcon adoption is expected to stay well below 10% — the launch-phase assumption from §Per-signature size inflation above. The 10% row should therefore be read as a conservative upper-bound scenario rather than the expected launch steady state. Exact launch-phase TPS impact still needs measurement, but the current expectation is that PQ adoption will remain low enough for throughput impact to stay manageable and not block launch.

As adoption ramps up, Falcon key-recovery mode and a possible BLOCK_SIZE increase are available as follow-ups (see §Per-signature size inflation).

Key Changes

Module	Changes
Protocol	New PQScheme enum and PQAuthSig message; Transaction.pq_auth_sig=6, BlockHeader.pq_auth_sig=3, HelloMessage.pq_auth_sig=12
Crypto	New crypto/pqc package, wrapping BouncyCastle FalconSigner (FNDSA512); PQSchemeRegistry static dispatch table centrally manages seedLength / signLength / pkLength / deriveHash / verify / computeAddress metadata
Actuator	AccountPermissionUpdateActuator accepts Falcon-derived addresses as Key entries; getTransactionSignWeight accounts for pq_auth_sig weight
Framework	TransactionCapsule.validatePQSignature / BlockCapsule.validatePQSignature run in parallel with the existing ECDSA path; JSON / RPC exposes the pq_auth_sig field
Consensus	The SR block-production path dispatches signing / verification based on which BlockHeader field is set; LocalWitnesses supports localwitness_pq.keys for pre-derived keypair configuration (operator-side offline generation, no on-node keygen — sidesteps BC Falcon FFT / FPR cross-platform FP drift)
Net	HelloMessage gains a pq_auth_sig field. On the FastForward path, RelayService signs HelloMessage with whichever key (ECDSA or PQ) the local node is configured with. On the verification side, it runs a four-step strict check — scheme registered + scheme activated on chain + public-key / signature length match + derived address bound to witness — before invoking PQSchemeRegistry.verify
VM	Three new precompiles: VerifyFnDsa512 (0x16), ValidateMultiFnDsa512 (0x17), BatchValidateFnDsa512 (0x18); gated by VMConfig.allowFnDsa512()
Governance	New ALLOW_FN_DSA_512 on-chain proposal; ProposalUtil strictly rejects invalid values and duplicate settings before activation
Config	config.conf gains localwitness_pq.scheme / localwitness_pq.keys fields (HOCON structure)

Impact

Security

• Adds quantum-resistant signing capability, closing the systemic risk of accounts being hijacked in the post-quantum era.
• Falcon signatures are only accepted after ALLOW_FN_DSA_512 passes — before activation, the existing ECDSA channel is fully unaffected. Post-activation, PQ can be disabled via a reverse governance proposal under the standard 27-SR maintenance-cycle timing (a faster emergency channel is itself out of scope this cycle — see Future Phases).

Implementation Validation Plan

Governance gating is only one layer of the security rollout. Because this change introduces a new post-quantum cryptography path for consensus-flow signatures and new TVM precompiles, implementation-level validation should be planned explicitly before mainnet activation.

Current direction:

• External audit — an independent cryptographic and implementation review is intended to complete before mainnet activation. The exact sequencing relative to the Q2 2026 testnet phase and the ALLOW_FN_DSA_512 governance vote is still under discussion.
• Audit disclosure — the activation discussion should be informed by public audit material. The current expectation is to publish at least an audit summary before the SR vote; whether a full report can be published, and the exact disclosure window, still need to be finalized.
• Bug bounty coverage — the rollout should evaluate explicit PQ security coverage for crypto/pqc, PQSchemeRegistry, and the 0x16 / 0x17 / 0x18 precompiles, including whether these components require a higher bounty tier than ordinary protocol bugs.

These items are part of the security-readiness work for the PQ rollout and will be updated once the audit, disclosure, and bounty plan is finalized.

Stability

• ECDSA and Falcon coexist at the protocol layer; existing structures and state fields such as Account and Permission remain completely unchanged.
• The SR block-production path uses configuration-driven, pre-derived keypairs; FullNodes never run key generation, which structurally sidesteps the cross-platform floating-point key-drift risk in BC Falcon's FFT / FPR routines.

Storage Impact

Open question — no conclusion yet. This is an unresolved area that requires dedicated stress testing before mainnet activation.

DB write amplification: with transaction bodies ~9.5× larger, will RocksDB / LevelDB show non-linear degradation in write throughput, compaction frequency, or disk I/O? Is there a tipping point at some PQ-share threshold? The stress-test plan is tracked in Open Questions §1 — please raise data, numbers, or counterexamples in the comments on this issue.

Developer Experience

• TVM side: a one-line staticcall to 0x16 / 0x17 / 0x18 suffices for Falcon verification — no need to implement PQ algorithms inside the contract.
• Wallets / SDKs only need to extend key management, address derivation, signature construction, and node-capability detection; the existing AccountPermissionUpdateContract path handles in-place account upgrades.
• Permission is algorithm-agnostic at the protocol layer — no changes required in wallet / exchange / contract parsing logic.

Account Migration

Regular accounts can choose either of the two paths below:

• Path 1: in-place permission replacement (zero asset movement) — an AccountPermissionUpdateContract that simultaneously adds a Falcon-derived Key and rebalances the Permission so that no ECDSA-only signature set can meet the threshold.

  ⚠️ The rebalancing step is mandatory for quantum safety. Simply adding a Falcon key while leaving the existing ECDSA key with enough weight to meet the threshold alone provides no actual PQ protection — a quantum attacker who breaks the ECDSA key still controls the account. The Falcon key in that case adds only key-management overhead, not security.

  Any configuration that requires at least one Falcon signature in every passing signature set is acceptable. Examples:

  Configuration	ECDSA-alone meets threshold?	Safe?
  keys=[ECDSA w=1, Falcon w=1], threshold=1	yes (either alone)	No — same as today
  keys=[ECDSA w=1, Falcon w=1], threshold=2	no (both required)	Yes — both required
  keys=[ECDSA w=1, Falcon w=2], threshold=2	no (ECDSA w=1 < 2)	Yes — Falcon alone still works
  keys=[Falcon w=1], threshold=1 (ECDSA removed)	n/a	Yes — strongest

  Operators choose the strictness based on tolerance for ECDSA continuity during the transition. Once the rebalancing is in effect, the old account address, assets, contract bindings, cross-chain whitelists, and DApp integrations are all preserved. Costs: the one-shot permission-update fee plus the standard MultiSignFee for any subsequent multi-sig transaction.

• Path 2: asset migration, deprecating the old account — generate a brand-new Falcon account, transfer all TRX / TRC10 / TRC20 / staked / delegated assets to the new account (staked / frozen resources must first be released via UnfreezeBalance / UnDelegateResource, then wait out the unlock window), and finally deprecate the old account. This fully cuts off the quantum attack surface, at the cost of transfer fees, the unlock waiting period, and address-change adaptation across external systems (exchanges, DApps, cross-chain bridges, contract whitelists).

• SR accounts — after Falcon is enabled on mainnet, complete the Witness Permission switch and configure the pre-derived keypair via localwitness_pq.scheme / localwitness_pq.keys.

• Wallets / SDKs / exchanges / block explorers — need to extend key management, address derivation, signature construction, node-capability detection, and pq_auth_sig field parsing. Falcon keypairs can be generated with TRON's Toolkit via the --key-factory command.

Compatibility

• Breaking Change: No (before ALLOW_FN_DSA_512 activates, node behavior is identical to today's mainnet).
• Default Behavior Change: Disabled by default; activation requires passage of the 27-SR on-chain proposal vote.
• Strict scheme validation: the PQScheme field is mandatory — UNKNOWN_PQ_SCHEME = 0 (proto3 default) is rejected at validation time by PQSchemeRegistry.resolve(), not aliased to FN_DSA_512. The ~1 byte varint saved by aliasing is not worth losing the input-validation signal, particularly as future schemes (e.g. ML_DSA_44) are added.
• JSON-RPC / HTTP API: transactions, blocks messages, and HelloMessage JSON gain a pq_auth_sig field; legacy formats are unaffected.
• The PBFT module will not introduce post-quantum signatures for now, to minimize the scope of impact.

Open Questions / Discussion Points

This section lists open questions in the current design that require community discussion and stress-test validation. Data, observations, and reference cases are welcome in the Issue comments — the goal is to reach consensus before mainnet activation.

1. Stress-test scope at intermediate PQ adoption ratios

The TPS reduction itself is largely deterministic from average transaction size against block-byte throughput (see §7 Performance table). What needs validation is the second-order effects beyond that arithmetic, which split cleanly along the block-size axis.

1a. Fixed block size

Block size limit stays unchanged. Stress test confirms that no implementation-layer surprise lurks beyond the deterministic TPS drop.

Concern	What stress-test confirms
Per-block verify CPU	Falcon verify (~113 μs) is ~10× faster than ECDSA (~1.2 ms); per-block verify CPU should drop, not rise. Confirm empirically and rule out unexpected JVM/GC behavior.
Block-propagation latency	A block with N% PQ traffic is larger in bytes even if tx count drops. Propagation is bandwidth-bound — verify SR miss rate stays within SLO as PQ share rises.
Mempool footprint & admission	Per-tx memory footprint grows ~10×. Verify admission throughput, eviction behavior, and memory pressure under flood.
DB write throughput	Confirm LevelDB/RocksDB write throughput stays linear in bytes-per-second, with no compaction-stall surprises under sustained 10–50% PQ share.

Pass criteria: SR miss rate, mempool admission throughput, per-block verify CPU, and DB write throughput all stay within current operating ranges across the 10%/20%/30%/50% PQ-share scenarios.

Follow-up: run stress tests at the four PQ-share points and publish block-latency, miss-rate, and DB-I/O curves as governance decision input.

1b. Increased block size

Separate governance decision, only considered if sustained PQ share makes the deterministic TPS reduction from 1a a real user-facing bottleneck.

If triggered, the evaluation would cover:

• Propagation latency under larger blocks at 2× / 4× block size; correlation with SR miss rate
• DB write amplification — compaction overhead, write-stall frequency, SSTable size distribution
• Archive storage growth — chain growth rate and cost impact for archive node operators
• New-node sync time as a function of historical block-size mix

Tracked separately and would require its own TIP if it leads to a block-size parameter change.

2. Fee model and user cost

With transaction bodies inflating ~9.5× and no adjustment to quotas such as getFreeNetLimit / getTotalNetLimit:

• Precompile energy calibration — the placeholder figures listed for 0x16 / 0x17 / 0x18 in §5 (4000, ecdsaCnt × 1500 + pqCnt × 2000, cnt × 2000) need to be finalized through JMH benchmarking and cross-calibrated against existing ECDSA precompile pricing (e.g. ValidateMultiSign at 1500 / sig) so that PQ-vs-ECDSA economics stay coherent across both the precompile path and the transaction-signature path.
• Extra cost in typical scenarios — covering (a) single-signer transfer, (b) multi-sig N-of-M transfer, (c) AccountPermissionUpdateContract upgrade, (d) contracts that call the PQ precompiles.
• Logical waiver opportunities — amortizing the "one-shot disclosure" of public keys (for example, not charging again after the first signature), discounting the PQ-migration AccountPermissionUpdateContract fee, batch-amortizing PQ verifications for large contracts, etc.
• Cross-chain reference — how do Ethereum / Solana / Algorand price PQ verification or large signature structures? Are those approaches worth borrowing?

Follow-up: produce a "PQ migration user-cost estimate" table, finalize the three precompile energy figures with reproducible benchmarks, and draft a governance proposal covering the waiver mechanism.

3. Smart-contract layer PQ readiness

Major contracts (TRC20 leaders, cross-chain bridges, institutional custody) may use ecrecover or self-implemented signature verification:

• Inventory — Which contracts use the "self-verify → authorize" pattern?
• Onboarding path — How can they progressively call the PQ precompiles (0x16 / 0x17 / 0x18) without breaking existing ECDSA callers?
• Transition capability — Do we need a standardized "dual-signature compatible" mode (contract accepts both ECDSA and PQ, either one valid)?

Follow-up: collect requirements from major contract owners and maintain a "contract PQ onboarding reference + upgrade checklist".

4. Wallet / hardware-wallet / SDK adoption path

Unified guidance for wallets such as TronLink and Wallet-cli, hardware wallets such as Ledger and Trezor, and SDKs such as TronWeb and Trident:

• Key derivation — How is BIP-39 + BIP-32 extended to support Falcon-512? Do we need TRON-specific coin_type / purpose?
• Hardware wallets — Ledger Nano S has insufficient RAM (4 KB vs. ~50 KB needed for Falcon keygen); when do Nano X / Stax / Flex begin adaptation?
• SDK APIs — A unified spec for the signing API, pq_auth_sig field layout, and node-capability probing (getChainParameters → ALLOW_FN_DSA_512).
• Industry references — Is the Solana Firedancer Falcon design or the Algorand state-proof wallet adoption flow worth aligning with?

Follow-up: publish TIP-XXX: Wallet & SDK PQ Adoption Guide, including recommended derivation paths, signing pseudocode, capability-probe interfaces, and a compatibility test matrix.

Future Phases (out of scope this cycle)

1. SR emergency-proposal channel: 6-hour voting window, 22/27 threshold, immediate effect — intended as a pre-positioned emergency-response capability for safety-critical switches.
2. FORBID_ECDSA_SIGN proposal: the entire network accepts only Falcon signatures, instantly cutting the quantum attack surface.
3. ZK proof for asset recovery: introduce RecoverAccountByZkContract; dormant accounts prove ownership using their ECDSA private key, while active accounts prove ownership using their wallet seed — both relying on quantum-resistant SNARKs (Plonky2 / STARK). See Ethereum Research: How to hard fork to save most users' funds in a quantum emergency.

Risk Hedging — ML-DSA-44 as Audit Fallback

Falcon-512 is the primary choice, but FN-DSA / Falcon-512 is still at the draft FIPS 206 stage — NIST has not yet finalized the standard. The specification could still shift during the formal-publication review cycle, and our implementation will be audited against a moving target, leaving meaningful audit risk. To de-risk this, a parallel ML-DSA-44 implementation should be developed in tandem as a backup. The protocol design makes the swap cheap:

• Both schemes share the same PQAuthSig wire structure — only the scheme enum value differs. No Transaction / BlockHeader re-design required.
• PQSchemeRegistry is already a plug-in dispatch table; adding ML-DSA-44 means registering one extra SchemeInfo + SignatureOps.
• The ML_DSA_44 slot is reserved in the PQScheme enum (reserved 2 to 15).

If activated as the launch algorithm, ML-DSA-44 keeps the same migration story and timeline, at the cost of a larger per-transaction footprint (~3700 B vs Falcon-512's ~1650 B) until further optimization. The option value is high: ML-DSA-44 was finalized as FIPS 204 in August 2024 — it is the NIST primary post-quantum signature standard and the natural fallback if Falcon-512 fails audit.

References

• NIST FIPS 206 draft (FN-DSA / Falcon): https://csrc.nist.gov/csrc/media/presentations/2025/fips-206-fn-dsa-(falcon)/images-media/fips_206-perlner_2.1.pdf
• Falcon specification: https://falcon-sign.info/falcon.pdf
• EIP-8052 (Ethereum Falcon-verification precompile draft): https://eips.ethereum.org/EIPS/eip-8052
• Solana Falcon-512 PR: firedancer-io/firedancer#9446
• Algorand quantum-resistant transactions: Quantum-Resistant Transactions on Algorand with Falcon Signatures

Additional Notes

• Do you have ideas regarding implementation? Yes
• Are you willing to implement this feature? Yes

[yanghang8612]

Great work on this. This is a huge protocol-level change, and the proposal is already very thorough.

My first question is about the Falcon-512 / FN-DSA-512 specification status.

I agree with the algorithm choice in principle. Given TRON’s throughput and transaction-size constraints, Falcon-512 looks like the most practical option among the current PQ signature candidates, mainly because its signature/public-key footprint is much smaller than ML-DSA or SLH-DSA.

That said, could you clarify the current status of the Falcon-512 / FN-DSA-512 standardization process?

• Is the specification already considered stable enough for protocol integration?
• Are there still possible large changes before final standardization?
• If changes are still possible, what parts are most likely to change: parameter set, encoding format, signature generation/verification behavior, test vectors, or API-level details?
• Since our launch timeline is already planned, understanding this risk is necessary before we commit to the wire format and consensus rules.

Also, since the main reason for choosing Falcon-512 appears to be its smaller signature size compared with other PQ signature algorithms, should we include a more explicit horizontal comparison of the security levels of the candidate algorithms as well? For example, Falcon-512 vs ML-DSA-44 vs SLH-DSA-128s in terms of NIST security category, classical security estimate, quantum security estimate, public key size, signature size, signing cost, verification cost, and implementation maturity.

This would make the trade-off clearer: not only “Falcon is smaller”, but also “Falcon provides sufficient PQ security for this use case, with these implementation and standardization risks.”

[yanghang8612]

Another question is about the TVM precompile design.

The proposal mentions that the new Falcon/FN-DSA precompiles are aligned with EIP-8052, but the current description is still relatively high-level. EIP-8052 defines fairly detailed semantics around input layout, fixed signature size, Hash-to-Point mode, canonical encoding checks, return values, gas behavior on malformed input, and the split between Hash-to-Point and Falcon Core.

Do we plan to add a more detailed protocol specification for the TRON precompiles in a follow-up section or separate TIP?

In particular, it would be helpful to clarify:

• the exact ABI/input layout for VerifyFnDsa512, ValidateMultiFnDsa512, and BatchValidateFnDsa512;
• whether TRON follows the NIST-compliant SHAKE256 mode from EIP-8052 or supports any EVM-friendly Keccak-PRNG variant;
• the exact accepted public-key and signature encodings and lengths;
• canonical-encoding validation rules;
• return values and error behavior for malformed input vs well-formed but invalid signatures;
• the rationale behind the proposed energy costs, especially why single verification and batch/multi verification have different per-signature pricing.

This would make it much clearer which parts are directly inherited from EIP-8052 and which parts are TRON-specific protocol design.

[yanghang8612]

One question about Open Question 1.

I understand the need for stress testing before mainnet activation, especially for block propagation, SR miss rate, DB I/O, and storage impact. However, I wonder whether the scope of this open question could be clarified a bit more.

If the block size limit remains unchanged, the TPS reduction caused by larger PQ transactions seems mostly deterministic: as the average transaction size increases, the number of transactions per block decreases. In that case, the main effect can be estimated from transaction size and block capacity.

For the other concerns, such as network bandwidth, DB write amplification, and consensus stability, are these intended to measure PQ-specific overhead, or are they mainly intended to evaluate the impact of larger block payloads / a possible future block-size increase?

In other words, should this open question distinguish between two cases?

• Fixed block size: validate the expected TPS reduction and check for unexpected implementation overhead.
• Increased block size: evaluate the broader system impact on propagation latency, SR miss rate, DB I/O, archive storage, and node sync.

This distinction might make the purpose of the proposed stress tests clearer, and help separate the direct impact of PQ signatures from the more general impact of larger blocks or larger payloads.

[Federico2014]

@yanghang8612 Thanks for the careful review. Both points are good ones, for the first question.

FIPS 206 standardization status

You're right that FN-DSA-512 is still in motion. Current status:

• NIST submitted the FIPS 206 draft for approval on 2025-08-28; final standard expected late 2026 / early 2027.
• IPD will include External-μ, HashFN-DSA, and ePrint 2024/1769.
• Under consideration but not yet committed: key-recovery modes, fixed-point signing.

Our Q2 testnet/Q3 mainnet target lands ahead of finalization, so the design assumes the wire format may need to evolve. We've built two structural mitigations:

1. Versioning via PQScheme enum. PQAuthSig.scheme is a PQScheme enum with reserved slots (reserved 5 to 15). Any incompatible FIPS 206 change — wire encoding, domain separation, message preprocessing — gets activated as a new scheme value via PQSchemeRegistry, not a mutation of FN_DSA_512. v1 signatures stay verifiable indefinitely.
2. Governance-gated activation. The whole Falcon path is behind the ALLOW_FN_DSA proposal and can be paused on-chain if a critical IPD change surfaces mid-rollout. ECDSA remains the authoritative fallback.

This way the standardization timeline risk is bounded: parameter set is already fixed at n=512 (no change expected), signing-side changes (fixed-point) don't affect verifiers, and any wire-format shift is absorbed via a new scheme value rather than a hard fork of v1.

Horizontal algorithm comparison

Fair point — making the trade-off explicit, not just "Falcon is smaller":

Algorithm	Public key	Signature	Verify speed	Security strength	Standard
ECDSA secp256k1	33 B	65 B	1195 μs	128-bit classical / 0-bit quantum	RFC 6979
Falcon-512	897 B	~666 B	113 μs	128-bit (NIST Cat 1, quantum-resistant)	FIPS 206 (draft)
ML-DSA-44	1312 B	2420 B	~150 μs	128-bit (NIST Cat 2, quantum-resistant)	FIPS 204
ML-DSA-65	1952 B	3309 B	~250 μs	192-bit (NIST Cat 3, quantum-resistant)	FIPS 204
SLH-DSA-128s	32 B	7856 B	~2 ms	128-bit (NIST Cat 1, quantum-resistant)	FIPS 205

Optional footnote: "Security strength" follows NIST PQC Category labeling. Cat 1 is equivalent to brute-forcing an AES-128 key; Cat 2 is equivalent to finding a SHA-256 collision.

For TRON specifically:

• Falcon-512 gives the smallest on-chain footprint (3.2× smaller sig than ML-DSA-44), fastest verification, and aligns with EIP-8052 — at the cost of accepting draft-standard risk, mitigated as above.
• ML-DSA-44 is the safer "already final" choice but ~893 B more per tx pushes block utilization 1.5× harder.
• SLH-DSA-128s is hash-based (most conservative quantum security assumption) but 7.8 KB signatures are a non-starter for a high-TPS chain.

[Federico2014]

@yanghang8612 For the second question. The proposal currently treats the precompile section at a high level and a detailed protocol spec is the right next step. We plan to publish a follow-up section (or a dedicated TIP) covering exactly the items you listed. Sharing our current direction below so the design intent is on the table while the formal spec is being drafted.

1. Relationship to EIP-8052

We treat EIP-8052 as the reference baseline for the single-verify precompile semantics (algorithm choice, public-key/signature length, NIST mode), and add two TRON-specific precompiles that have no EIP-8052 equivalent:

Precompile	Address	Source	Status
VerifyFnDsa512	0x16	Aligned with EIP-8052	TRON-flavored ABI wrapping the same primitive
ValidateMultiFnDsa512	0x17	TRON-specific	Permission multi-sign (parallel to 0x09 ValidateMultiSign)
BatchValidateFnDsa512	0x18	TRON-specific	Batch verify (parallel to 0x0A BatchValidateSign)

0x17/0x18 inherit ABI shape from the existing ECDSA precompiles 0x09/0x0A so contract developers see the same patterns, not from EIP-8052.

2. ABI / input layout

0x16 VerifyFnDsa512

Compact byte layout (not standard ABI encoding) to avoid 32-byte padding overhead on the ~666 B signature:

input  = msg(32) ‖ sigLen(uint16 BE, 2) ‖ sig(sigLen, 1..752) ‖ pk(896)
output = bytes32  // 0x..01 = valid, 0x..00 = invalid or malformed

Strict equality check on input.length == 32 + 2 + sigLen + 896 — any extra/missing trailing byte returns 0. The sigLen field is needed because Falcon signatures are variable-length (1..752 B).

0x17 ValidateMultiFnDsa512

Standard Solidity ABI; mirrors 0x09 hash construction:

validateMultiSign(
    address  account,          // word[0]
    uint256  permissionId,     // word[1]
    bytes32  data,             // word[2]
    bytes[]  ecdsaSignatures,  // each entry = 65 B
    bytes[]  pqSignatures,     // each entry = 1..752 B
    bytes[]  pqPublicKeys      // each entry = 896 B
) returns (bool)

• Hash construction: SHA-256(account ‖ permissionId(uint32 BE) ‖ data) — bit-identical to 0x09, so existing Permission accounts work unchanged
• MAX_SIZE = 5 applies to ecdsaCnt + pqCnt
• pqSignatures.length must equal pqPublicKeys.length
• Permission key matching uses derived TRON address from the PK (not the raw PK), so the existing Permission.keys[] schema stays untouched

0x18 BatchValidateFnDsa512

batchValidateFnDsa512(
    bytes32   hash,                // word[0]
    bytes[]   signatures,          // each 1..752 B
    bytes[]   publicKeys,          // each 896 B
    bytes32[] expectedAddresses    // 21-byte addr packed in low 21 bytes
) returns (bytes32)

• Returns a 256-bit bitmap (matches 0x0A): bit i is set iff derive(pk_i) == expectedAddr_i AND verify(pk_i, hash, sig_i)
• MAX_SIZE = 16 (same cap as 0x0A)
• Per-entry verifies run on BatchValidateSign.workers (shared pool) when not in a constant call, with getCPUTimeLeftInNanoSecond() timeout enforcement

3. NIST mode vs Keccak-PRNG

For v1 we follow the NIST-compliant SHAKE256 mode, primarily because we delegate to BouncyCastle 1.84's FalconNIST, which only ships the NIST Round 3 reference path (SHAKE256-based Hash-to-Point and seed expansion).

A Keccak-PRNG-based optimization (as offered in EIP-8052 for EVM clients without SHAKE256 acceleration) is on the table as a follow-up, once we have benchmarks justifying the divergence from KAT vectors and a maintained implementation. If FIPS 206 final adds Keccak-PRNG as a normative option, we will revisit immediately.

4. Public-key and signature encodings

Field	Encoding	Length
Public key	NIST Round 3 packed form (BouncyCastle FalconNIST output)	fixed 896 B
Signature	NIST Round 3 packed form, salt-prefixed	variable 1..752 B

• PK rejected with non-success result if length != 896
• Signature rejected if length < 1 or length > 752
• No leading zero stripping, no trailing padding — bytes must match BouncyCastle output exactly

5. Canonical-encoding validation

Three layers, all enforced by the precompile (not deferred to the underlying library):

Check	Where	Failure mode
Total input length matches declared sigLen (strict equality, no trailing bytes)	Precompile entry	Returns 0 (well-formed but rejected)
PK length == 896, sig length in [1, 752]	Precompile entry	Returns 0
Falcon canonical packed-form (polynomial coefficient bounds, nonce length, NIST mode tag)	BouncyCastle FalconNIST.verify	Returns 0
Hash-to-Point ↔ NTRU equation	BouncyCastle	Returns 0

The strict-equality length check follows the same pattern as 0x100 P256Verify in EIP-7212 — one logical input ↔ one byte encoding, leaving room for future EIP-8052 trailing fields.

6. Return values and error behavior

We use three distinct outcome classes, following the same convention as existing precompiles:

Outcome	Pair<Boolean, byte[]>	EVM-level effect
Well-formed input, signature valid	(true, 0x..01)	CALL succeeds, returns 1
Well-formed input, signature invalid	(true, 0x..00)	CALL succeeds, returns 0
Malformed input (bad ABI head, oversized array, length mismatch)	(false, EMPTY) for 0x17/0x18; (true, 0x..00) for 0x16	0x17/0x18: CALL reverts, all energy consumed. 0x16: CALL succeeds, returns 0

Difference between 0x16 and 0x17/0x18 is intentional:

• 0x16 is a thin verify primitive — it follows ECRecover (0x01) / P256Verify (0x100) convention of "any malformed input returns 0, never reverts"
• 0x17/0x18 wrap Solidity ABI decoding — any ABI head violation reverts because the caller is expected to construct valid ABI; this matches 0x09/0x0A behavior

7. Energy / gas pricing rationale

The numbers below are tentative placeholders — a follow-up benchmarking pass on representative SR hardware will determine the final values before mainnet activation.

Precompile	Per-signature energy (tentative)	Reasoning sketch
0x16 VerifyFnDsa512	4000 (flat)	Single verify includes Hash-to-Point + NTT + polynomial bounds check
0x17 ValidateMultiFnDsa512	ECDSA: 1500 / PQ: 2000	ECDSA reuses existing 0x09 cost. PQ entry priced lower than 0x16 because the message hash is computed once and reused across members
0x18 BatchValidateFnDsa512	2000 per entry	Hash provided by caller, so amortization is fully realized; per-entry steady-state cost approaches the batched path

Open items for the calibration pass:

• Per-CPU-cycle pricing vs wall-clock — particularly relevant for 0x18 which uses the shared worker pool
• Cost asymmetry between first-call and steady-state (JIT warmup on the BouncyCastle Falcon path)
• Address-derivation overhead for 0x17/0x18 (derive(pk) → addr) which 0x16 skips
• Comparison against EIP-8052 single-verify gas to ensure cross-ecosystem fee parity

[Federico2014]

@yanghang8612 Good distinction — the split is sharper than the original framing and avoids coupling v1 activation to a block-size decision that may never become necessary. Updated Open Question 1 in the issue body according to your suggestions.

[yanghang8612]

Thanks for the detailed follow-up. This addresses most of my original concerns, and the updated Open Question 1 is much clearer now.

I have a few remaining encoding/spec clarification points:

1. Falcon signature length

The reply says sigLen in [1, 752]. I understand 752 likely comes from Falcon-512’s compressed-signature maximum size, but the lower bound 1 does not seem meaningful for a valid Falcon signature.

Depending on the selected format, the signature should include at least a salt/nonce, and possibly a header:

• Falcon compressed format: header(1) || nonce(40) || compressed_s2
• EIP-8052 style: salt(40) || compressed_s2
• BouncyCastle FalconSigner output: header(1) || nonce(40) || compressed_s2

Could the spec explicitly state the exact signature wire format, whether the header byte is included, the real minimum structural length, and whether TRON intentionally uses variable-length compressed signatures instead of EIP-8052’s fixed 666-byte format?

2. Public-key length

Some places use 896 B, while the algorithm comparison table uses 897 B. My understanding is that standard Falcon public-key encoding is 897 bytes with a header, while EIP-8052 uses the 896-byte public polynomial.

Could we make the TRON rule explicit for PQAuthSig.public_key, precompile input, and address derivation, so all paths hash/verify the exact same byte representation?

3. PQScheme enum reservation

The proto snippet says:

reserved 2 to 15; // Future expansion

I understand the intention may be to keep these values under protocol control. However, protobuf reserved values are intended for removed values that must not be reused. The official proto3 guide says the compiler will complain if future users try to use reserved identifiers, while adding new enum values is wire-safe:

• https://protobuf.dev/programming-guides/proto3/#reserved-values
• https://protobuf.dev/programming-guides/proto3/#updating

If 2..15 are intended for future schemes, maybe they should be left unassigned with a comment instead of using reserved, e.g.:

// Values 2..15 are intentionally left unassigned for future
// protocol-defined PQ schemes. Do not allocate without TIP/governance.

4. Precompile energy

One small point on pricing: the reply says 0x17/0x18 PQ verification is cheaper because the message hash is reused. But Falcon Hash-to-Point depends on both the message and the per-signature salt, so each PQ signature still seems to require its own H2P step. The 2000 per-entry cost may need benchmark justification rather than relying mainly on hash reuse.

Finally, I agree that canonical encoding should be enforced at the protocol/precompile level. It would be useful to include negative test vectors for padding-bit malleability, trailing bytes, invalid coefficient ranges, and header/logn mismatch.

[Federico2014]

Thanks for the careful read — these are all worth nailing down in the spec. Replies inline.

1. Falcon signature wire format — variable vs fixed-length

You're right that sigLen ∈ [1, 752] is inappropriate. A valid Falcon signature always carries at least a 40-byte nonce plus a non-empty compressed_s2, so the real lower bound is roughly 40 + minCompressedS2Len.

The wire format itself is still open between BC's native variable-length output (nonce ‖ compressed_s2, length in roughly [minStruct, 752]) and the EIP-8052 fixed-length format (exactly 666 bytes with zero-padding). Variable-length saves ~75 B per signature — about 4–5% of a PQ transaction body — and uses BC directly with no wrapper code. Fixed-length costs those bytes but gives a stricter length check (== 666), a simpler malleability rule (padding bytes must be all-zero), and most importantly aligns with EIP-8052 so wallets, hardware wallets, and any EVM-side PQ tooling can reuse one signing implementation across TRON and other chains.

Leaning toward fixed-length. The wire savings don't justify locking TRON into a custom Falcon format. Variable-length will be kept in the spec's "alternatives considered" section.

2. Public-key length: 896 vs 897

The 897-vs-896 split is real and intentional. BC's FalconPublicKeyParameters.getH() returns 897 bytes including the 1-byte serialization header (0x30 | logn); TRON strips that header and stores/transmits the bare 896-byte modq-encoded h polynomial — matching EIP-8052's 896-byte form. Concretely:

Path	Encoding	Length
PQAuthSig.public_key (proto field)	bare h polynomial, no header	896 B
Precompile input pk field	bare h polynomial, no header	896 B
Address derivation: Keccak-256(public_key)[12..32]	bare h polynomial, no header	hashes 896 B
BC interop	TRON prepends 0x39 before calling new FalconPublicKeyParameters(PARAMS, h)	896 B in / 897 B with header

So every TRON-visible path hashes/verifies the exact same 896-byte representation. The 897 B mention in the algorithm comparison table is the standard BC encoding with header and should be replaced with 896 B (header stripped, see §Address derivation) for consistency. I'll fix the table and add a one-paragraph "Canonical PQ public-key encoding" subsection so wallets/SDKs have an unambiguous reference.

3. PQScheme reserved 2 to 15 semantics

Agreed — proto3 reserved is the wrong tool here. Its purpose is to fence off removed values from accidental reuse; using it as a "future protocol-defined range" prevents the very allocation we want to do later. I'll change the proto to:

enum PQScheme {
  UNKNOWN_PQ_SCHEME = 0;   // proto3 default — rejected at validation time
  FN_DSA_512        = 1;   // Falcon-512 (enabled at first launch)
  // Values 2..15 are intentionally left unassigned for future
  // protocol-defined PQ schemes (e.g. ML-DSA, SLH-DSA). Allocation
  // requires a TIP and on-chain governance proposal — do not assign
  // ad-hoc in client forks.
}

This keeps the "protocol-controlled" intent in the comment without burning the slots.

4. Precompile energy and Hash-to-Point cost

Fair pushback — the "hash reuse" framing in the previous reply was imprecise. Falcon's HashToPoint(msg ‖ salt, ...) folds the per-signature nonce into SHAKE-256, so H2P runs per signature; what 0x18 reuses across the batch is only the upstream SHA-256(message) of the common message. The 2000 / sig figure is a placeholder pending JMH, to be cross-calibrated against ValidateMultiSign (1500 / ECDSA sig) using measured per-verify CPU. Final numbers will be published in this issue before mainnet activation.

Negative test vectors

Agreed — I'll add a "Canonical-encoding test vectors" section listing the negative cases:

• Padding-bit malleability (non-zero bits in compressed s2 tail-pad, or non-zero padding bytes if fixed-length is chosen)
• Trailing bytes after compressed_s2
• Out-of-range polynomial coefficients (BC raises but we want explicit reject path)
• Header / logn mismatch (e.g. Falcon-1024 header 0x3A on the Falcon-512 channel)
• Wrong-length nonce (≠ 40 B implicit from header position)
• Public key with leading header byte (897 B instead of 896 B) — must be rejected by the precompile and PQAuthSig field-length check
• Wrong total signature length (≠ 666 B if fixed-length is chosen)

These will land alongside the spec text update and be cross-referenced from the precompile sections.

[trezoa-labs]

Great initiative on PQ signature migration at the protocol layer. A few technical observations: Falcon-512 is solid for consensus, though you might consider the verification latency impact at 50K+ TPS scales — we found dual-path routing (legacy + PQ) benefits from aggressive batching and parallel verification kernels. Also worth thinking about whether address derivation stays ECDSA-only or eventually migrates, since that can create long-term compatibility friction. If you're exploring Rust-based verification or optimizing the signature verification pipeline, the team at developers@trzledger.org has spent considerable time on this for TrezoaChain's native PQ stack and might have useful insights to share.

[yanghang8612]

@Federico2014 Thanks for the detailed clarification. This addresses my main concerns.

I agree that leaning toward the fixed-length 666-byte format is the better direction if the goal is EIP-8052 compatibility and easier reuse across wallets, hardware wallets, and EVM-side tooling. The ~75-byte saving from variable-length encoding does not seem worth introducing a TRON-specific Falcon wire format.

The 896-byte canonical public-key representation, the correction to the PQScheme enum reservation, and the explicit negative test-vector plan all look good to me as well. Given the scope of these clarifications, do you plan to split the detailed protocol/precompile specification into a dedicated TIP? That might align better with TRON’s existing protocol development process and make review easier.

One additional point: I think the biggest practical blocker for PQ adoption may be wallet implementation rather than node-side verification. From the BTC/ETH discussions, there does not seem to be a mature, widely adopted equivalent of BIP39 + BIP32 for Falcon/ML-DSA-style wallets yet. Key derivation, deterministic key generation, derivation paths, hardware-wallet constraints, test vectors, and cross-wallet recovery behavior will all need to be specified carefully.

This may be outside the proper scope of this issue, and probably requires strong support from other TRON ecosystem teams, especially wallets, SDKs, hardware-wallet integrations, and exchange/custody providers. A dedicated Wallet/SDK adoption guide or follow-up TIP might be useful for the actual rollout.

Looking forward to the detailed spec update and implementation.

[Federico2014]

@trezoa-labs Thanks for the comment and the suggestions in this proposal. The design is still evolving, and we're collecting feedback openly — further technical discussion, suggestions, or specific concerns are welcome on this issue.

[Sunny6889]

One area not covered in the proposal yet: the third-party cryptographic audit plan.

A change of this scope — a draft-FIPS-206 Falcon with ML_DSA_44 signature scheme on the consensus path plus three new TVM precompiles — typically warrants independent review (Trail of Bits / NCC Group / Cure53 / SECBIT) before mainnet activation. The current Impact > Security sections only mention governance-level safeguards, nothing about implementation validation.

Three specific things worth pinning down:

1. Audit timing — is an external audit planned, and where does it sit relative to testnet (Q2 2026) and the ALLOW_FN_DSA_512 vote?
2. Public disclosure — will the report (or a summary) be published before the SR vote? Hard to form an informed opinion on activating a draft-standard scheme without it.
3. Bug bounty scope — is there a dedicated allocation explicitly covering crypto/pqc, PQSchemeRegistry, and the 0x16 / 0x17 / 0x18 precompiles, ideally at a higher tier than regular protocol bugs?