DEV Community

Cover image for EVM, Quantum-Ready, Quantum-Resistant: How Modulax Puts Them Together
Modulax
Modulax

Posted on

EVM, Quantum-Ready, Quantum-Resistant: How Modulax Puts Them Together

1) What the EVM is and why it matters

The Ethereum Virtual Machine (EVM) is the execution environment that runs smart contracts and applies state changes. It defines opcodes, gas accounting, and transaction semantics.

EVM compatibility means:

  1. Developers keep using Solidity, Hardhat, Foundry, MetaMask, Blockscout, and other Ethereum tools without rewriting code.
  2. Existing patterns for logs, events, ABI encoding, and receipts behave the same, so indexers and wallets integrate cleanly.
  3. Migration cost is low because applications do not need a new VM or custom SDKs.

Resource

  1. Ethereum EVM docs: https://ethereum.org/en/developers/docs/evm/

2) The real state of quantum computing and the risk model

Quantum computers exist today but remain noisy and small. Breaking ECDSA at blockchain scale needs far more stable qubits than are currently available. The practical risk is Harvest-Now-Decrypt-Later (HNDL).

HNDL explained:

  1. Adversaries capture public data and signatures today.
  2. When quantum hardware matures, those archives can be attacked retroactively.
  3. Long-lived systems need a credible path to stronger cryptography before that point.

Resources

  1. Shor’s algorithm overview: https://en.wikipedia.org/wiki/Shor%27s_algorithm
  2. NIST Post-Quantum Cryptography project: https://csrc.nist.gov/projects/post-quantum-cryptography

3) Definitions that avoid confusion

Quantum-ready and quantum-resistant operate at different layers than the EVM. They refer to the cryptography beneath execution, not the VM itself.

Concept Quantum-Ready Quantum-Resistant
Meaning Architecture supports PQC integration without breaking EVM PQC algorithms run in production
Crypto in use ECDSA today for compatibility Dilithium for signatures, Kyber for key exchange
Contract changes Not required Not required
Wallets ECDSA now; PQ wallets can be added via account abstraction PQ-capable wallets by default

Resource

  1. Account Abstraction (ERC-4337): https://eips.ethereum.org/EIPS/eip-4337

4) What “quantum-ready” means in Modulax code and architecture

Current facts about the public repo and chain:

  1. Modulax mainnet is live and EVM-compatible. Explorer and JSON-RPC are public.
  2. The codebase uses ECDSA today for account and consensus signatures to remain compatible with EVM tooling.
  3. Cryptographic logic is separated in the repository so future primitives can be added without changing EVM execution.

Repository reality to point reviewers at:

  1. The crypto/ package currently contains ECDSA key and signature handling plus hashing utilities. Link: https://github.com/Modulax-Labs/go-modulax/tree/main/crypto
  2. EVM execution code lives outside crypto/, so changing signature primitives does not require changes to contract execution.
  3. Consensus and networking call into crypto helpers. The goal is to keep those call sites stable while swapping implementations when PQC is introduced.

Resource

  1. Modulax repo root: https://github.com/Modulax-Labs/go-modulax

5) Where post-quantum fits without breaking EVM

A safe PQC rollout touches four surfaces. The intention is to change cryptography under the hood while leaving execution intact.

Layer What stays the same What changes during PQC integration
Contract execution EVM bytecode, gas rules, logs, state transition No change
Transaction surface Nonce, value, data, gas fields Signature algorithm and encoding envelope to carry larger artifacts
Consensus verification Block and vote verification pipeline Verifier swaps from ECDSA to Dilithium
Networking Peer discovery and messaging Handshake key exchange swaps from ECDH to Kyber

Design implications to account for:

  1. PQ signatures and public keys are larger than ECDSA, so headers, receipts, and RPC payloads must allow bigger fields.
  2. Indexers and explorers need parsers that accept multiple signature encodings.
  3. Benchmarks are required to size validator hardware and p2p bandwidth.

Resources

  1. CRYSTALS-Dilithium: https://pq-crystals.org/dilithium/
  2. CRYSTALS-Kyber: https://pq-crystals.org/kyber/
  3. NIST PQC selections: https://csrc.nist.gov/projects/post-quantum-cryptography

6) How wallets migrate without breaking users

Account abstraction allows multiple signature schemes to coexist.

Migration plan for accounts:

  1. ECDSA accounts continue to work for backward compatibility.
  2. PQ-capable accounts are introduced that sign with Dilithium.
  3. Contracts do not change because verification rules are bound to account type, not the EVM.
  4. Users opt in to PQ wallets when ready while the network supports both during transition.

Resource

  1. ERC-4337 docs: https://eips.ethereum.org/EIPS/eip-4337

7) A practical, low-risk migration plan

Phase 1. Preparation

  1. Keep mainnet on ECDSA for stability.
  2. Publish a design note describing signature and key-exchange envelopes, wire-size limits, and RPC impact.
  3. Land interface tests that validate signer and verifier behavior independent of algorithm.

Phase 2. Devnet proof-of-concept

  1. Introduce a dedicated branch wiring a Dilithium verifier behind the crypto interface using official test vectors.
  2. Run micro-benchmarks for verification cost at block-processing speeds.
  3. Provide a Kyber handshake prototype in the p2p layer and measure connection setup overhead.

Phase 3. Dual-mode support

  1. Allow ECDSA and Dilithium to coexist on a gated network.
  2. Enable PQ accounts via account abstraction while ECDSA accounts continue.
  3. Validate indexer and explorer support for larger signatures.

Phase 4. Governance-driven default

  1. When tooling, wallets, and performance are acceptable, make PQ signatures the network default by parameter upgrade.
  2. Maintain legacy verification for a sunset period so users can migrate gracefully.

8) Performance and resource expectations

Dilithium verification has higher CPU cost and larger key and signature sizes than ECDSA. Kyber has different size tradeoffs than ECDH.

Expectations for an EVM chain:

  1. Verification cost per block rises. Batching and parallel verification mitigate the impact on throughput.
  2. Gossip and block propagation pay a bandwidth penalty due to larger artifacts. Tuning chunk sizes and compression helps.
  3. On-chain gas accounting for contract execution does not change because signature work is performed in the client, not inside the EVM.

Resources

  1. High-level PQC performance surveys: https://arxiv.org/ (search “Dilithium performance”, “Kyber performance”)
  2. PQClean and liboqs references: https://github.com/PQClean/PQClean and https://github.com/open-quantum-safe/liboqs

9) What Modulax has today

Network and infra:

  1. Modulax mainnet live in bootstrap validator mode. Public validator onboarding is planned after Bridge and DEX readiness.
  2. Explorer is public at https://explorer.modulax.org
  3. JSON-RPC endpoints are live for basic operations. Additional public endpoints will expand over time.
  4. Docs are in active sync with the live chain. For the most accurate status, refer to GitHub and the developer blog.

Token and distribution:

  1. ERC-20 MDX on Ethereum with a 4 and 4 fee structure. Contract: 0x8cC41583E1Bf4f3Ee08e7EdC21AeCD6833929F6b (verify on Etherscan)
  2. Daily native rewards on Modulax chain for ERC-20 holders at or above the published threshold.
  3. UNCX vesting contracts live for long-term allocation management. Links: a. https://app.uncx.network/vesting-v2/flux/1-4919?chain=1&wallet=0x981e4e9E91736250AEDA4335bf3be35576F138b7 b. https://app.uncx.network/vesting-v2/flux/1-4918?chain=1&wallet=0x981e4e9E91736250AEDA4335bf3be35576F138b7 c. https://app.uncx.network/vesting-v2/token/chain/1/address/0x8cc41583e1bf4f3ee08e7edc21aecd6833929f6b

Developer resources:

  1. GitHub: https://github.com/Modulax-Labs
  2. Docs: https://modulax.gitbook.io
  3. Dev blog: https://dev.to/modulaxorg

Notes on scope today:

  1. Mainnet uses ECDSA like Ethereum and most EVM chains. Modulax does not claim to be quantum-resistant today.
  2. Quantum-ready refers to the architectural separation that allows Dilithium and Kyber to be integrated later without breaking contracts or state.

10) What external reviewers should check in the repo

Code organization signals readiness even before PQC lands.

Checklist:

  1. Confirm cryptographic calls in consensus and networking go through helper functions, not hard-coded ECDSA specifics.
  2. Inspect transaction signing and verification code paths for algorithm-agnostic interfaces.
  3. Review RPC and block serialization for assumptions about fixed signature sizes.
  4. Verify that EVM execution code does not import or depend directly on crypto primitives.

11) Why doing this early matters for a live chain

Preparing early reduces migration risk and preserves developer velocity.

Rationale:

  1. Chains that wait until PQC is urgent face wider breakage and compressed timelines.
  2. Upgrading cryptography while keeping the EVM constant avoids contract churn and app downtime.
  3. A devnet PQC phase gives wallets, explorers, and indexers time to adapt to larger artifacts and new encodings.

Resources

  1. NIST PQC standards overview and process: https://csrc.nist.gov/projects/post-quantum-cryptography
  2. Vitalik’s writing on quantum risk and mitigations: https://vitalik.eth.limo/general/2023/05/21/quantum.html

Top comments (0)