[Proposal] Request for Proposal to Audit XDC2.0

XDC Protocol Team — Sun, 10 Sep 2023 09:09:03 +0000

TL;DR

This post calls for proposals to audit the forthcoming XDC2.0 consensus upgrade. Deadline: 30/Sep/2023, anywhere in the earth.

Background

XDC2.0 is a significant backward-incompatible upgrade of the XDC network. It will create a hard fork that requires all the network participants to comply. This upgrade will change the consensus engine of the XDC network from XDPoS1.0, a delegated proof-stake (DPoS) plus longest-chain mechanism, to XDPoS2.0, a DPoS mechanism with the optimal Byzantine-fault-tolerance (BFT) based on the chained-Hotstuff algorithm.

The upgrade is led by Professor Pramod Viswanath from Princeton University and his protocol engineering team. This upgrade will enhance the security level of XDC network against malicious master nodes without compromising the network’s high performance (e.g., high transaction throughput) and applications (e.g., all the EVM-compatible smart contract-based applications). It will also broaden the adoption of the XDC network due to the new features it brings in, such as forensics and enterprise private subnet.

The upgrade has been deployed on the XDC devnet since June 2023 and has worked properly without any issues for 2 months – until the protocol team shut it down and redeployed it to incorporate recent upgrades from the community.

Before applying XDC2.0 to the XDC mainnet, at least two requirements should be met:

The upgrade is deployed to the XDC Apothem testnet and works without issues for at least three months.
The upgrade passes the audit from at least one highly professional and reputable audit team.

The results of the deployment and audit will be published for the community to make the final decision.

Scope of the Audit

Object: all the code developed between V1.1.0 and V1.4.8 under the XDPoSChain repo
Goal: to provide, after neccesary iterations of code modifications, an assessment on whether XDC2.0 is suitable to be deployed to the XDC mainnet or not. Here, by “suitable”, we mean:
- The implementation of the algorithm meets the desired BFT security (including safety and liveness) properties.
- The code is high-quality and robust, with all edge cases covered, so it will not cause network failures or enable security-threatening attacks.
Supports from the protocol team:
- Provide all the related codes and documentation
- Guide deployment and testing
- Answer technical questions and participate in technical discussions
- Evaluate code revision suggestions and implement the changes

Requirements

The successful audit team should:

be highly reputable in the industry
have deep expertise in auditing consensus protocols with a provable track record
submit a comprehensive proposal with:
- clearly defined scope of work
- clearly explained methodology
- a good estimate of the workforce the team will bring in
- a good estimate of the timeline, or a convincing justification if an estimate cannot be given
- a comprehensive fee scheme

How to Submit

Please submit your proposal by either replying to this post with your proposal in text, or, if your proposal is a file, replying to this post with a link to your file.
Deadline: 31/Sep/2023, anywhere in the earth.

XDC2.0 Voting Latency Analysis

XDC Protocol Team — Wed, 26 Apr 2023 14:45:09 +0000

Context

XDC has a target block time of 2 seconds. This gives the network 2 seconds of time to propose, verify, vote, and execute each block. If the total time taken for a block is greater than 2 seconds, then the block time of this block will be higher than 2 seconds.

Block proposal, verification, and execution are done locally by each master node and, thus, are very fast. The main factor is thus the voting latency, i.e., the time it takes a block to receive enough votes, which is determined by the network latency.

The Impact of Voting Latency

In XDPoS 1.0, voting latency is not an issue because each block only needs to receive one vote. However, to achieve the maximum BFT (Byzantine fault tolerance), with the upcoming XDC2.0 upgrade, each block needs to receive 73 votes (2/3 of the 108 master nodes). This raises the following question: is the XDC network fast enough to cope with such an increase in votes?

Experiment Results

To answer this question, we deployed a 120-node XDC2.0 devnet globally using AWS across 5 very diverse regions (even more diverse than the current XDC mainnet), including Ohio, Ireland, Tokyo, Sydney, and San Paulo. We then measured and analyzed the voting latency for all the blocks.

The result is affirming. From 19/April to 24/April, we observed a medium (50th percentile) voting latency of only 0.52 seconds, and a 95th percentile of 1.3 seconds (meaning that the voting latency of 95% of the blocks is less than 1.3 seconds). Both are far smaller than the 2-second target.

You can also observe the devnet live here: Devnet Explorer
You will see that every two seconds, a new block is created. You will also see the geological distribution of the nodes across the 5 regions (as of 27/April/2023). We may change the set up in the future.

Conclusion

Thus, we conclude that, with high confidence, XDC network is fast enough to support the upcoming XDC2.0 upgrade from the voting latency and block time perspective.

In the future, we will investigate the P2P protocol optimization for the consensus engine. We welcome collaborations and contributions from the community.

Developers Forum for XinFin XDC Network: XDC Protocol Team