EIPsInsight

Loading Experience

Preparing your insights...

Loading0%
PQTS2026-04-15_006

PQ Transaction Signatures #006

2026-04-15 4 decisions 409 transcript lines

Transcript

Ask about this call

Answered from this call's summary and transcript only.

AI-generated — verify against the recording.

Call summary

Targets
  • Two weeks - Next PQTS breakout with Matteo's ephemeral key updates — 00:50:18
Decisions
  • Lesson learned: NTT/LEGO abstraction approach doesn't work for PQ signatures — 00:14:36
  • Solidity contracts for PQ verification must be formally verified, not precompiles — 00:43:06
Highlights
  • Strategy Discussion:
    • ·Proposed dual approach: ephemeral keys for low-value, Dilithium for high-value transactions — 00:32:23
    • ·Ephemeral key security concerns: censorship attacks and long mempool times — 00:36:10
    • ·Formal verification critical for Solidity-based PQ signature contracts — 00:42:48
  • Hardware Constraints:
    • ·NIST SLHDSA-24: ~6 minutes signing time on Ledger hardware wallet — 00:27:18
    • ·New NIST parameters still impractical: millions of hashes needed per signature — 00:38:25
    • ·Custom Keccak-based parameters achieve 100-1000x faster signing than NIST proposal — 00:39:14
  • Protocol Developments:
    • ·Frame transaction/native AA no longer headliner for Hegotá fork — 00:04:01
    • ·NIST released limited-use SLHDSA parameters: 2^24 signatures, ~3-4KB size — 00:04:36
  • Implementation Updates:
    • ·Daisugi testnet live: Erigon node with Falcon/Dilithium/ephemeral ECDSA support — 00:06:52
    • ·NTT/LEGO approach requires scheme-specific precompiles; abstraction doesn't work well — 00:14:21
    • ·Direct precompiles much lower gas than NTT, especially Dilithium (~100k difference) — 00:17:41
Action Items
  • Nico C — Publish EVM-friendly SLHDSA parameter research with Keccak instantiation — 00:40:02
  • Ethereum Foundation representatives — Send NIST feedback at tomorrow's workshop on hash function crypto-agility — 00:41:23
  • Simon ZKNOX (future call) — Present full Dilithium ledger integration round-trip demo — 00:50:43

Meeting chat47

  • Simon ZKNOX

    2²⁴ :-)

  • Kenneth

    Where can I access all these and try them ?

  • Antonio Sanso

    https://daisugi.fyi/create

  • Kenneth

    ❤️

  • Kenneth

    May I also have the repo url if they are open sourced

  • Simon ZKNOX

    This is the cost of the precompile without the call data, right? A Falcon signature is 666B which means at least 10k additional gas in practice?

  • Giulio

    https://daisugi.fyi/create https://daisugi.fyi/explorer

  • Giulio

    https://github.com/Giulio2002/pq-eth-precompiles

  • Oleg Lodygensky

    Is there any work to standardize PQWallet. There are different paths, different algorithms and I think it would be interesting to have (1) a discovery mechanism so that an endpoint would publish its requirements and features (used library (OQS?); available algorithms etc.) And (2) a « standardized » API. e.g /createwallet, /signtx etc

  • Giulio

    I think signing time is not important

  • Simon ZKNOX

    Agreed with this! You trade verification cost against number of hash for the signer :-)

  • Lumi | Wonderland

    Reacted to "Agreed with this! ..." with ❤️

  • Simon ZKNOX

    Replying to "I think signing ti..." On a HW wallet, it does if signing takes 10 min 🤡

  • Giulio

    Replying to "I think signing time..." nvm

  • Simon ZKNOX

    Reacted to "Agreed with this! ..." with 🧉

  • Yannick Seurin (Ledger)

    KeyGen for SLH-DSA-128s (2^64 sigs) is currently 50sec

  • Simon ZKNOX

    but this will increase with a 2²⁴ version

  • Yannick Seurin (Ledger)

    Indeed, will need to test it

  • Simon ZKNOX

    Reacted to "Indeed, will need ..." with 👍

  • Oleg Lodygensky

    no

  • Oleg Lodygensky

    maybe Hadrien Croubois ( ? )

  • Oleg Lodygensky

    he works at OpenZeppelin

  • Oleg Lodygensky

    yes

  • Matteo Vicari

    Certora

  • Oleg Lodygensky

    I will ask him

  • Matteo Vicari

    We have pretty interesting updates coming soon on the ephemeral keys design, including specs, hopefully ready for the next call!

  • Giulio

    It’s dangerous if someone makes a tx that hangs in the txpool for days. Can happen with high congestion

  • Giulio

    I had a tx pending for 3 days back in 2021

  • Gottfried Herold

    I am also concerned about Ephemeral keys + censorship (essentially, if your transaction is refused from inclusion, attackers have more time)

  • Matteo Vena

    It depends on the context. Ephemeral keys for example are currently enough for rollups with private sequencers

  • Nico C

    Hello everyone sry being late

  • Simon ZKNOX

    No it was a bit different

  • Simon ZKNOX

    the link is here if you are interested: https://www.youtube.com/watch?v=FW5gkC9TwRg Deploy and send a tx using PQ sig in clear-signing :-)

  • Nico C

    Will do !

  • Alexandre Roque

    In the ephemeral key setting you still need to publish the pub keys map in advance, no? what impedes a CQRC to revert a couple of pub keys and then front run when the time is right? It seems to work if we assume the user will rotate often and in a short time-frame

  • Matteo Vicari

    Replying to "In the ephemeral key..." The hash of public key , like and address

  • Simon ZKNOX

    It's mostly the same as before, but we showed the ledger integration. I don't think it makes sense to do a demo here as it was mostly already presented

  • Gottfried Herold

    Re: only using Ephemeral keys for low-value transactions: IIUC, what matters is the value of the account, not the value of the transaction.

  • Alexandre Roque

    Reacted to "The hash of public k..." with 👍

  • Alexandre Roque

    Reacted to "Re: only using Ephem..." with 👍

  • Yannick Seurin (Ledger)

    I was thinking of https://github.com/Verified-zkEVM/VCV-io (@Nico C you're probably aware of it)

  • Yannick Seurin (Ledger)

    For hash-based sigs there has been work in EasyCrypt: https://eprint.iacr.org/2026/134

  • Nico C

    Reacted to "I was thinking of ..." with 👍

  • Lumi | Wonderland

    Thank you everyone! 🤍

  • Alexandre Roque

    Thanks!

  • Ottie | Wonderland

    Thanks!

  • Simon ZKNOX

    Thanks, see you!

Key decisions

  • Frame transaction/native AA no longer headliner for Hegotá fork

    headlinerFrame transaction and native Account Abstraction were removed as headliner features for the Hegotá fork.
  • Daisugi testnet live: Erigon node with Falcon/Dilithium/ephemeral ECDSA support

    DaisugiThe Daisugi testnet was launched featuring Erigon nodes with support for Falcon, Dilithium, and ephemeral ECDSA.
  • Lesson learned: NTT/LEGO abstraction approach doesn't work for PQ signatures

    The NTT/LEGO approach was found to require scheme-specific precompiles, making abstraction ineffective for Post-Quantum signatures.
  • Solidity contracts for PQ verification must be formally verified, not precompiles

    The group decided that Solidity contracts used for PQ verification require formal verification rather than relying on precompiles.