Post Quantum transaction signature (PQTS) Breakout #3

Protocol Calls & happenings
1

Agenda

Meeting Time: Wednesday, March 04, 2026 at 15:00 UTC (60 minutes)

GitHub Issue

2

Meeting Summary:

The meeting focused on post-quantum transaction signatures, with discussions centered around MPT precompiles and related cryptographic implementations including polynomial multiplication using the NTRU algorithm. The team explored various technical aspects including implementation details of precompiles, hardwired primes, bit width handling, and cost considerations for different signature schemes. The group also discussed account abstraction and post-quantum transaction formats, with plans to bring in account abstraction experts for the next meeting to ensure proper collaboration and address implementation challenges.

Click to expand detailed summary

Antonio led the third call of the post-quantum Transaction Signatures series, focusing on entity and non-person compile topics. He introduced the concept of MPT precompile and mentioned a tweet by Justin Drake showing a long-term roadmap for Ethereum’s future. The agenda was kept lean, with plans for future calls to include more presentations and open discussions. Simon and Renaud were scheduled to present on the MPT precompile and zkox, which they had attempted to launch last year.

Renaud presented an EIP (Ethereum Improvement Proposal) for a precompile that implements polynomial multiplication using the NTRU algorithm, which can be used for PoW and lattice-based cryptography applications. The precompile significantly reduces gas costs compared to previous implementations, lowering the cost of Falcon verification from 1.5 million gas to 400k gas. Renaud also discussed a related NVM Py precompile initiative that introduces vectorized modular arithmetic for the EVM, though this work is still in early stages.

Renaud-ZKNOX and Antonio discussed the implementation of NMP and MP precompiles, clarifying that they are not antagonistic but can work together. Renaud-ZKNOX explained that while multiple precompiles can be submitted, it’s better to choose a champion due to the complexity of evaluation by the core team. They also addressed the number of opcodes and the use of vectorized operations, with Renaud-ZKNOX noting that the current proposal uses only one opcode and supports flexible operations through parameters. The discussion concluded with an agreement that supporting a limited set of standard primes would be more efficient than implementing all possible primes.

The team discussed implementation details of precompiles, focusing on hardwired primes and bit width handling. Renaud-ZKNOX explained that while hardwiring is crucial for entity precompiles due to large lookup tables, Barrett multiplication offers advantages over Montgomery for NVMP precompiles due to faster constant precomputation and reduced need for linear permutation layers. Danno raised concerns about handling multiple bit widths in key encoding, particularly for Lithium and Falcon keys which use various bit lengths, and Renaud-ZKNOX clarified that decompression could be handled either at the contract level or by the signer, with the specific implementation details to be determined based on NISC compliance requirements.

Danno expressed concerns about drifting from NIST algorithms, noting it could limit market adoption by institutions. Renaud-ZKNOX suggested using software adapters between hardware signers and mentioned that verifying Falcon signatures would cost around 200K gas, primarily due to data costs rather than computational costs. Antonio inquired about the specific costs involved, and Renaud-ZKNOX clarified that while Numpy could potentially speed up certain computations, direct NIST precompiles would be necessary to keep costs competitive with current signature schemes. Danno concluded that any EVM costs exceeding data carriage costs might not be economically viable, particularly given the inevitable 5-10X higher data carriage costs for post-quantum signatures.

The team discussed the high costs associated with blockchain signatures, with Danno explaining that each signature could cost $200K due to data carriage costs increasing 5-20X. Renaud-ZKNOX suggested exploring lattice-based signature aggregation and native account abstraction to potentially reduce these costs, though acknowledged that NAMPI would not necessarily produce lower gas costs. The group agreed to focus on the JUMP precompile for now, with Antonio requesting detailed cost breakdowns to better understand where the $200K costs are being spent.

The group discussed a precompile for vectorized operations, with Renaud-ZKNOX explaining that it uses a generic field with Barrett constants that can handle any modulus less than 2^32. Stefano suggested expanding beyond basic arithmetic operations to include more complex vectorized primitives that could benefit on-chain finance applications, though Renaud-ZKNOX requested concrete examples for benchmarking. The discussion concluded with Danno raising questions about public key storage, noting that removing public keys from transactions could reduce chain data but also enable key rotation capabilities.

The group discussed account abstraction and post-quantum signatures, with Renaud explaining how CREATE2 can provide deterministic hashing from public material to contract deployment addresses. Antonio proposed bringing in account abstraction experts for the next call in two weeks to ensure collaboration and avoid missing important aspects. Danno expressed concern that Frame Transactions are being marketed as a post-quantum solution when they appear to be primarily about account abstraction, suggesting this may be an attempt to gain momentum by leveraging post-quantum buzz.

The group discussed post-quantum transaction formats, with Danno emphasizing the need for cryptographic agility and separate handling of signatures and transaction bodies. Fab explained that AA (account abstraction) was chosen because existing post-quantum standards are still relatively new, and he expressed concern about relying on untested schemes. The participants agreed that while account abstraction provides flexibility, it doesn’t fully solve the signature scheme selection problem, as wallet providers will eventually need to choose compatible schemes. Antonio announced that account abstraction would be the topic of the next meeting in two weeks.

Next Steps:

  • Renaud and Simon (zkNOX): Provide detailed breakdown of where the 200K gas costs are spent in Falcon verification (call data vs each operation) for the NTT + Shake precompile approach
  • Renaud and Simon (zkNOX): Provide gas cost estimates for NumPy precompile + Shake combination for signature verification within a few weeks
  • Antonio: Organize next call (call #4) in two weeks focused on account abstraction, including inviting account abstraction team and frame transaction developers to present
  • Antonio: Facilitate collaboration between post-quantum signature researchers and frame transaction/account abstraction developers to ensure alignment

Recording Access:

3

YouTube recording available: https://youtu.be/awucKGkiZZI

4

When is PQTS #4? I would like to revisit my cryptographic agility presentation with a specific proposal.