Developers Forum for XinFin XDC Network: Gary

Securing XDC with Post-Quantum Signatures

Gary — Sat, 16 Aug 2025 14:31:36 +0000

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

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.
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.
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

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

DApp Layer

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

Implementation Challenges

Performance Considerations: PQ signatures may increase block size by 10-100x.
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

Component	Timeframe	Ecosystem Impact	User Experience
Consensus	Major consensus change (~2-3 years)	Seamless for masternodes	Mandatory upgrade
Transaction	Comparable to EIP-1559 (~2 years)	Moderate impact for upgraders	Optional transition
DApp	Dependent on Ethereum timeline	Moderate impact for upgraders	Developer discretion

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:

For Windows Systems:

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

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:

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.

🔄 Proposal: XDC Network Reward Mechanism Upgrade

Gary — Mon, 21 Apr 2025 13:40:27 +0000

The XDC Network is evolving — and so is its reward mechanism.

This article outlines a detailed proposal to upgrade how rewards are calculated and distributed in the XDC Network’s XDC 2.0’s Consensus. This builds on our earlier discussion and introduces new logic to better recognize node contributions while preparing the network for future security and scalability.

🧠 Background: How Rewards Work Today

In the current XDC Network’s consensus model:

Rewards are distributed every epoch, not every block.
An epoch equals 900 blocks (XDC 1.0) or 900 rounds (XDC 2.0).
At the start of each epoch, a total reward (currently 5000 XDC) is allocated, defined by the parameter XDPoSConfig.Reward.

🔧 Current Reward Flow (3 Steps):

Count Contributions: Only block signers who were Master Nodes are counted.
Calculate Reward: The protocol uses a fixed reward per epoch (e.g., 5000 XDC).
Distribute Rewards:

90% to the owner of each contributing signer
10% to the Foundation Wallet (xdc92a289fe95a85c53b8d0d113cbaef0c1ec98ac65)

🚀 What’s Changing: Introducing Protector & Observer Nodes

We're proposing a multi-tiered node reward system, where three types of nodes will now receive fixed, per-node rewards based on their rank and contribution:

Role	Rank by Stake Cap	Total Nodes
Master Nodes	1 – 108	108
Protector Nodes	109 – 324	216
Observer Nodes	325 – 1324	1000

Each role will have a predefined per-epoch reward — but only if they actively contribute to network health.

💰 Proposed Per-Epoch Rewards

Role	XDC Contribution	Annual Rewards	Approx. Per Epoch Reward
Master Node	10,000,000 XDC	1,000,000 XDC	≈ 57 XDC
Protector Node	10,000,000 XDC	800,000 XDC	≈ 45 XDC
Observer Node	10,000,000 XDC	400,000 XDC	≈ 23 XDC

This is a major shift — rewards are now fixed per contributing node, rather than dynamically split.

Technically, no restriction to Contribute more XDC compared to 10,000,000 XDC to become a Masternode or protector node but Per EPoch Rewards will remain the same. Higher XDC contribution increases probability to be masternode as timestamp based validation will be replaced with new updates which includes XDC Contribution, Timestamp (to check longevity of node), Hardware/ Network resources allocated to the Masternode/Protector Node/Observer Node.

⚠️ Inactive nodes (no contribution during epoch) will receive no rewards also provision of penalty to serve few epoch before start getting rewards.

🔍 Technical Enhancements

The new configuration will be managed via the upgraded V2Config struct:

type V2Config struct {  
    MasternodeReward     float64 `json:"masternodeReward"`  
    ProtectorReward      float64 `json:"protectorReward"`  
    ObserverReward       float64 `json:"observerReward"`  
    MaxProtectorNodes    int    `json:"maxProtectorNodes"`  
    MaxObserverNodes     int    `json:"maxObserverNodes"`  
}

Implementation Steps:

Pull candidates from the parent state of the epoch switch block.
Rank by Candidate Cap (stake from owner + voters).
Assign roles (Master, Protector, Observer).
Distribute fixed rewards to the owner of each contributing node. Also distribute rewards to the Foundation Wallet according to the 90/10 split.

📈 Future-Proofing the Network

While the reward values proposed are grounded in staking math and real-world logic, they are subject to change based on:

Transaction volume
Network activity
Validator participation
New edge cases that emerge in production

🌟 Why This Is Unique

This model introduces a first-of-its-kind, tiered validator reward system in the blockchain space.

To our knowledge, no other blockchain has implemented a structure that:

Recognizes not just core validators, but mid-tier and observer nodes
Distributes fixed per-node rewards based on participation
Provides room for adaptive scalability via upgradable node caps and reward values

But with innovation comes risk:

⚠️ As this model is unprecedented, no guarantee exists that it will work flawlessly in all conditions.

High network traffic, edge-case validator behaviors, and real-world operations may necessitate future refinements.

🧪 Security & Activation

This upgrade will be rolled out as a hard fork, requiring:

A full security audit
Rigorous testnet simulations
A clearly defined activation block (e.g., TIPUpgradeReward \= big.NewInt(XXXX))

🧩 Final Thoughts

The XDC Network is on a journey of rapid technical innovation. This reward upgrade is a big leap forward — one that honors contribution, encourages decentralization, and positions XDC for long-term sustainability.

We welcome feedback from developers, node operators, and community members to refine this proposal before implementation.

Let’s build the future of contribute-based reward systems — together.

Please note: There is nothing new in this proposal — it simply reinforces the original vision that has been in place since day one. We are not changing anything, only aligning the implementation more closely with XDC’s core principles.

✍️ Questions or thoughts? Comment below.

[Informative] Block Structure in XDPoS 2.0

Gary — Sat, 02 Sep 2023 18:01:14 +0000

Blocks are the core data structure in a blockchain. Each block has a batch of transactions that should be executed. Besides transactions, there are metadata that is crucial to the consensus algorithm, which are stored in block headers. Transactions in XDPoS 2.0 are the same as those in XDPoS 1.0, so this document focuses on block headers. The following sections describe the fields of block headers in XDPoS 2.0.

Block Header's Extra Data

XDPoS 2.0 requires the block header to carry extra consensus data. The extra_data field of the block header is an ideal place for this purpose because it does not cause breaking changes to the header structure. More specifically, we redefined this field, and in this section we first describe the new structure and also introduce the old structure for completeness.

New Fields in Block Header's Extra Data

XDPoS 2.0 requires these new fields in block header's extra data:

Field name	Type	Description
Round	integer (int64)	Round is the basic tick of XDPoS2.0' consensus algorithm (chained Hotstuff). Each round has a different and deterministic block proposer (a.k.a. leader) from the master list. This Round is the time when this block is proposed.
QuorumCert	QuorumCert (described below)	The quorum certificate (QuorumCert, QC) for the parent block, which consists of the signatures from 2/3 of the master nodes.

These fields are RLP-encoded as bytes and injected into extra data.

QuorumCert struct

Block infos. First, a QuorumCert has all the block infos that a vote contains. The infos include the voted block's hash, round, and block number. These three fields are combined into a structure called ProposedBlockInfo.
Signatures. Second, it has signatures from 2/3 of the master nodes on these block infos. In practice, it may be a concatenated array of signatures. The signer’s address can be derived from the signature. The signature is secp256k1, which is currently used in XDPoS 1.0. Each signature is 65 bytes.

Extra Data of XDPoS 1.0

The extra data in header of XDPoS 1.0 consists of three parts: vanity, signers, and seal. The table below gives a description for them.

Bytes	Part	Description	Reason for changing
First 32 bytes	Vanity	Reserved for fixed unique bytes for each master node.	Not used in XDPoS.
Middle bytes	Signers	The list of master nodes for the coming epoch, whose addresses are concatenated into one byte-array. Non-empty only in checkpoint headers.	Replaced by `header.Validators`.
Last 65 bytes	Seal	The signature of the block proposer for the block.	Replaced by `header.Validator`.

As you can see in the following sections, the signers and seal part are replaced by other fields in the headers. And the vanity part is removed since it is not used. Therefore, we can have a completely new structure of extra data in XDPoS 2.0.

Exsting Header Fields with Updated Definitons

Apart from the extra data, these fields exist in XDPoS 1.0 blocks and we keep these fields but use them in a different way in XDPoS 2.0.

Field name	Type	Before change	After change	Reason for changing
Coinbase	address	It’s all zeros.	Change it to the leader’s (or proposer's) address.	Convenient to query who is the leader.
Difficulty	integer (big.Int)	It’s computed in a function calcDifficulty and adaptively changes.	Change it to a constant.	Difficulty is not used in XDPoS 2.0.
Validator	bytes	It’s the second signature in XDPoS 1.0.	Change it to the leader’s signature.	The second signature is not used in XDPoS 2.0.
Validators	bytes	It’s the M1M2 mapping, and only valid if this block is a checkpoint block.	Change it to the list of master nodes' addresses. The addresses are concatenated into bytes. And it is also only valid if this block is an epoch switch block. If not epoch switch, this is empty bytes.	The M1M2 mapping is not used in XDPoS 2.0.

Unchanged Fields in Block Headers

These fields are used in the same way as in XDPoS 1.0. No change is needed.

ParentHash
UncleHash
Root
TxHash
ReceiptHash
Bloom
Number
GasLimit
GasUsed
Time
MixDigest
Nonce
Penalties

Report on fixing CVEs

Gary — Sun, 14 May 2023 12:21:30 +0000

Our team surveyed go-ethereum (geth) security vulnerabilities on CVE details website (https://www.cvedetails.com/vulnerability-list/vendor_id-17524/product_id-51210/Ethereum-Go-Ethereum.html) and spotted several ones that could affect XDC. Here is a list of the vulnerabilities.

1. CVE-2022-29177

This vulnerability is about using an index d of type uint to access an array discReasonToString, and the index bound check is done by converting d to int(d) and checking whether len(discReasonToString) < int(d). This check misses the situation where int(d) could be negative. We fix the check to len(discReasonToString) <= int(d) || int(d) < 0.
In XDC codebase, our team finds that we cannot use geth fix (ethereum#24507) since modifying DiscReason to uint8 messes up the message encoding.
Status: Merged into branch dev-upgrade.
Links:
https://www.cvedetails.com/cve/CVE-2022-29177/
https://github.com/XinFinOrg/XDPoSChain/pull/242

2. CVE-2021-39137

This vulnerability is caused by pointer misusage in the Go language. It is fixed by using CopyBytes to copy bytes rather than using the same pointer.
Status: Merged into branch master.
Links:
https://www.cvedetails.com/cve/CVE-2021-39137/
https://github.com/XinFinOrg/XDPoSChain/commit/b5abbfed79084fdd188837d645d13db229b2d5d0

3. CVE-2020-26241

This vulnerability is about the wrong implementation of the data copy native contract. It is fixed by using CopyBytes to copy bytes.
Status: PR created.
Links:
https://www.cvedetails.com/cve/CVE-2020-26241/
https://github.com/XinFinOrg/XDPoSChain/pull/255

4. CVE-2018-16733

This vulnerability is about the attacker using incorrect starting and ending block numbers to trace blocks. If the starting block number is larger than the ending one, the program would be stuck in an infinite loop. We fix it by checking the starting and ending block numbers.
Status: PR created.
Links:
https://www.cvedetails.com/cve/CVE-2018-16733/
https://github.com/XinFinOrg/XDPoSChain/pull/251/files

5. CVE-2018-12018

This vulnerability is about the attacker using a negative skip number to cause an infinite loop. We fix it by checking the skip number.
Links:
https://www.cvedetails.com/cve/CVE-2018-12018/
https://github.com/XinFinOrg/XDPoSChain/pull/250

Unrelated CVEs

Proposal on EVM upgrade

Gary — Sun, 06 Nov 2022 15:32:31 +0000

This article analyzes the feasibility of upgrading Xinfin network's EVM to Ethereum latest EVM. There are three types of potential upgrades:

feature upgrade,
bug fix,
other small PRs.

We will analyze separately. Then in each section, we provide a conclusion of whether we should apply the upgrade or not, and if yes, how.

Version Comparison

Since Xinfin's last EVM upgrade (commit link), there are the following new EVM-related hard forks (reverse chronologically ordered):

The Merge, which changes Ethereum consensus to the Beacon Chain proof-of-stake system. Xinfin works with XDPoS consensus, thus this hard fork is unnecessary.
The London hard fork contains two EVM-related EIPs: EIP-3198: BASEFEE opcode and EIP-3529: Reduction in refunds. As the EIP title suggests, the former enables BASEFEE opcode and the latter changes the gas calculating rule.
The Berlin hard fork contains these EIP:
- EIP-2929: Gas cost increases for state access opcodes. As the EIP title suggests, it changes the gas calculating rule.
- EIP-2930: Optional access lists. This EIP introduces a new type of transaction which contains an access list.
- EIP-2718: Typed Transaction Envelope, required by EIP-2930.

As illustrated above, the Merge hard fork is unnecessary for Xinfin. On the contrary, the London hard fork and the Berlin hard fork is crucial for Xinfin as they are necessary to make Xinfin's EVM compatible with latest DApps. These two hard forks include a new opcode and a new type of transaction, which is necessary to upgrade the EVM funcionality, and two modifications to the gas rule, which give a more accurate estimation of the time needed to process EVM opcodes.

In short, it is recommended to adopt the new EVM feature in the London and Berlin hard fork, which includes a new opcode, two modification to gas rule, and a new type of transaction.

In addition, there is an opcode push0 which is not in final status yet, but it's in Ethereum's codebase now. It can be put onto the pending list of EVM upgrade.

Bug fix

Looking through a few recent PRs on Ethereum (with search filter "EVM") Pull requests · ethereum/go-ethereum), there is no bug fix PR. However, labeling is not often used for PRs. So it will take some effort to study them and understand their goals and changes to the code. For instance, to understand whether they are small improvement, or bug fix, or a major feature. It will take some effort to pick the major PRs (such as EIPs) among the small ones and to skim through more PRs.

Other Small PRs

The majority of Ethereum PRs (with filter "EVM") are small ones, each of which contains few lines of codes and are easy to port to Xinfin codebase.

By looking through the recent PRs, we found that they only provide minor improvements, such as renaming SUICIDE to SELFDESTRUCT, use uint256 rather than big.Int, etc. No bug fix PR is in recent PRs so they are unnecessary for Xinfin.

A short summary of unique features of Xinfin

Precompiled contracts

Xinfin has the following unique precompiled contracts (and Ethereum does not have them), core/vm/contracts.go:

ringSignatureVerifier{},
bulletproofVerifier{},
XDCxLastPrice{},
XDCxEpochPrice{},

XDCx trading

The XDCx trading logic is inside evm. core/vm/evm.go.

How to do the upgrade

After illustrating the current status of Xinfin and Ethereum EVM and their comparisons, we come to the following conclusion on how to do the upgrade:

Overriding Xinfin code by Ethereum code is infeasible, since there are unique features of Xinfin and Ethereum does not have them.
Merging the whole Ethereum EVM is cumbersome, as there will be a huge amount of code conflicts and a dedicated team is needed to handle them. Even if the merge is handled for PRs separately, the huge number of PRs still make it difficult.
Specific hard-fork feature upgrade is necessary: features such as new opcodes and new gas rules are necessary to make Xinfin EVM compatible to the latest DApps and reduce the vulnerability of gas-fee related attacks. There needs to be a dedicated upgrading team to port the aforementioned EIPs. And the workload of the EIPs are:
- EIP-2929: this PR, 28 changed files with 980 additions and 73 deletions (lines of code).
- EIP-2930: this PR, 69 changed files with 2,446 additions and 909 deletions.
- EIP-2718: this PR again, 69 changed files with 2,446 additions and 909 deletions.
- EIP-3198: this PR, along with EIP-1559，47 changed files with 1,099 additions and 909 deletions. Or refer to the squashed PR.
- EIP-3529: this PR, 7 changed files with 166 additions and 114 deletions.

Given the workload and its complexity, it will take about 2 months for a small EVM expert team (3-5 people) to properly apply the upgrades, followed by sufficient testing on XDC dev-net and test-net.

Reactive upgrade is recommended for the future: for the long term EVM upgrade, we recommend reactive upgrade, that is, when there is a request of feature or bug fix, we port the corresponding Ethereum PR to Xinfin codebase.