Securing XDC with Post-Quantum Signatures

This proposal for making XDC post-quantum (PQ) secure encompasses three key components: consensus layer, transaction layer, and DApp layer. The consensus layer involves upgrading signatures within XDC 2.0 (replacing ECDSA), the transaction layer introduces new PQ-signed transaction types, and the DApp layer implements PQ cryptography within the EVM.

Upgrade Workflow

Consensus Layer

1. Deploy a smart contract for PQ public key registration. The smart contract maintains a map from existing addresses to PQ public keys, allowing nodes to maintain existing addresses while adopting PQ keys. Note: this preserves masternode addresses during the transition.
2. Implement PQ signatures in consensus V2 for block headers, votes, timeouts, QCs and TCs. Signature verification will utilize the registration contract to retrieve PQ public keys.
3. Require all masternodes and observers to register PQ public keys. Schedule a hard fork to activate PQ signatures and disable ECC in consensus operations.

Transaction Layer

1. Introduce PQ signatures at the transaction layer through new transaction types, leveraging the existing registration contract.
2. Integrate PQ signatures into wallet toolkits (e.g., MetaMask). Note: Significant development effort required.
3. Schedule a hard fork to enable PQ signatures while maintaining legacy signature support for compatibility.
4. Facilitate wallet migration by allowing users to register PQ public keys while retaining their existing addresses.

DApp Layer

1. Implement PQ signatures in virtual machine precompiles. Note: Substantial development effort; recommended to coordinate with Ethereum core developers.
2. Enable DApp migration through smart contract upgrades incorporating PQ signatures. Note: Significant implementation requirements.

Implementation Challenges

1. Performance Considerations: PQ signatures may increase block size by 10-100x.
2. Backward Compatibility: Legacy signatures will coexist with PQ signatures, requiring user action for full PQ security.

Comment on Account Abstraction

Contrary to some Ethereum community perspectives, account abstraction alone cannot achieve full PQ security. While account abstraction offers flexibility for users' PQ implementation, the bundler still requires PQ-secure implementation at the transaction layer.

Analysis

Implementation Roadmap

The consensus layer upgrade requires 2-3 years for implementation while maintaining seamless operation for masternodes, though it will require every masternode's participation. The transaction layer implementation, comparable in scope to Ethereum's EIP-1559 with an estimated 2-year timeline, will have moderate ecosystem impact limited to users who choose to upgrade. DApp layer remains contingent on Ethereum's development timeline, similarly offering optional adoption for developers while maintaining moderate ecosystem impact.

Cryptographic Options

Three NIST-standardized PQ signatures currently exist: FALCON, Dilithium (ML-DSA), and SPHINCS. Community discussions on Ethereum forums indicate FALCON as the preferred option. However, with NIST continuing to evaluate additional PQ signatures, final selection remains premature.

Proof of Concept on XDC codebase

We have implemented a proof-of-concept of consensus layer post-quantum signature demonstrating Falcon signatures for both block signing and consensus quorum certificate (QC) signing. Benchmark results for verifying a block with no transaction show:

• Verification time: 0.138 ms per operation, with Falcon signature verification as the primary computational cost
• Block size components:
  • Block signature: 652 bytes
  • Extra data (including Falcon signatures with corresponding signer addresses): 49562 bytes for 73 masternodes

As a comparison, current XDC's block verification takes 0.017 ms and signature is 65 bytes. Extra data is around 5000 bytes.

This PoC confirms the technical feasibility of implementing post-quantum signatures in our consensus mechanism, as well as the block size concern.

Hardware Environment

The benchmark is performed in the following environment.

​​- OS​​: Windows 10 (64-bit)
​​- CPU​​: Intel Core i5-10600KF @ 4.10GHz (6 cores, 12 threads)

• ​​Memory​​: 64GB @ 2667MHz

Codebase Implementation

The proof-of-concept implementation is available in the https://github.com/XinFinOrg/XDPoSChain/tree/poc_falcon under the poc_falcon branch.

Reproduction Instructions

Prerequisites:

• Golang environment
• Windows system (for direct execution) OR Falcon compilation tools for other platforms

Setup Process:

1. For Windows Systems:

   git clone -b poc_falcon https://github.com/XinFinOrg/XDPoSChain.git

1. For Non-Windows Systems:

   git clone -b poc_falcon https://github.com/XinFinOrg/XDPoSChain.git
   git clone https://github.com/zhenfeizhang/falcon-go.git
   cd falcon-go && make
   cp -r c falcon ../XDPoSChain/

Execution:

cd XDPoSChain
go test -benchmem -run=^$ -bench ^BenchmarkVerifyHeaderFalcon$ github.com/XinFinOrg/XDPoSChain/consensus/tests/engine_v2_tests

Conclusion

The proposed post-quantum security implementation for XDC is technically feasible but requires fundamental, full-stack change. The decision among emerging post-quantum cryptographic algorithms remains premature.

Appendix

Ethereum's Roadmap

According to official Ethereum documentation, full quantum resistance for core protocols remains in the research phase and may require several years for implementation (https://ethereum.org/en/roadmap/future-proofing/).

References

Key discussions from ethresearch:

1. https://ethresear.ch/t/so-you-wanna-post-quantum-ethereum-transaction-signature/21291
2. https://ethresear.ch/t/falcon-as-an-ethereum-transaction-signature-the-good-the-bad-and-the-gnarly/21512
3. https://ethresear.ch/t/the-road-to-post-quantum-ethereum-transaction-is-paved-with-account-abstraction-aa/21783

The third reference proved particularly insightful, demonstrating that account abstraction alone cannot resolve the fundamental PQ security challenge, as bundler transactions remain dependent on ECDSA signatures.