Disclosure letter: Fairness Attack against the Vechain Thor Consensus

Report date: May 25, 2024

Attacking target: Vechain Thor consensus protocols

1. Key Deliveries:

In VeChain’s whitepaper, The consensus security is stated as follows:

Once authorized, all nodes have an equal opportunity to create new blocks and earn rewards, without the need to spend vast resources competing against each other. This ensures that richer nodes do not have an unfair advantage over other nodes in the system

However, our attack undermines this assertion. Specifically, under our attack strategy, malicious nodes can usurp the block generation rights from honest nodes, effectively depriving them of their chance to earn rewards. This disruption undermines the fairness and the foundational claims of the consensus protocol’s security model.

Our attack involves intentionally delaying the broadcast of blocks to create forks, and then broadcasting its own block just before the next proposer starts packaging blocks in the next cycle. This leads subsequent proposers to select the attacker’s block as bestBlock, resulting in the discarding of the block that was packaged by the honest proposer.

To well describe our strategy, we set the current time as T, the time for the next block as T+1, and the time for the block after that as T+2. The attacking strategy is summarized as follows:

  1. Upon receiving the next block T+1 (1:10:30 ), it packages the block but delays broadcasting.
  2. Before the proposer for the next cycle T+2 (1:10:40 ) begins packaging, it broadcasts its own block.

This action results in forks among other nodes, with some nodes selecting the attacking node’s block as bestBlock. Due to the BFT algorithm prioritizing the comparison of Quality in the state, blocks created by the attacking node may have a higher Quality, thus having a higher probability of being chosen as the bestBlock.

Such an attack could lead to the block packaged by the proposer at T+1 being discarded, thereby affecting the rewards of that proposer.

The diagram below illustrates how our attacks lead to the discarding of blocks from honest nodes, consequently depriving them of block rewards.

We follow the initial settings of VechainThor, with seven nodes participating in the consensus processes. We control (mostly, by modifying the parameter or delaying the block) either one or two of the nodes to launch our attacks with different strategies.

Hardware environment: (1) Cloud server with aws c5.4xlarge instance; (2) Ubuntu-22.04 Operate System; and (3) docker/git command tools. Network Configuration: Consisting of seven nodes, labeled from N0 to N6.

We have developed an “Attacker Simulator” to emulate the behavior of an attacker. This simulator introduces a delay before broadcasting blocks, building on the original codebase. All modifications are documented and available in the GitHub repository.

Deployment: Node N0, operating as a malicious node, runs the attacker simulator (see our code at Anonymous Github), while nodes N1, N2, N3, N4, N5, N6 run the standard client with some base change (see our code at Anonymous Github).

Results and Analysis:

Expected results: Due to the deliberate delay introduced by N0, the blocks from certain nodes after N0 will be lost.

Observed results:

Observed behavior: N0’s delayed broadcast caused node N4 to produce Block 6377 again, albeit after a 10-second delay.

Block comparison: The block IDs for the 6377th block from nodes N0 and N4 were found to be different, labeled with suffixes 669e and 1edc, respectively.

Chain selection: Other nodes, such as N3, chose N0’s 6377th block (ID suffix 669e) for inclusion in the chain. Meanwhile, N4’s block with the suffix 1edc was discarded, demonstrating the impact of the delay introduced by N0.

The original post suggests that there is a potential reduction in fairness of the VeChainThor blockchain when a block proposer delays block issuance. This is not correct and is a false statement. The described attack vector suggests that malicious validator nodes can disrupt the block generation process, effectively preventing honest nodes from earning rewards. If a block proposer delays the block issuance, the consensus mechanism will elect the next scheduled proposer in order to maintain the liveness of the network, this is by design. The claim is that this is not fair consensus.

Network tolerance resilience is accounted for in the consensus protocol as an important piece of network liveness. In other words, if an validator node has a problem producing a block, another validator node will produce a block for that slot. This ensures that the network continues to progress. The attack is no different from lag in the network, or a hardware hiccup from a validator node. The exact same behaviour can happen if a non-malicious validator node just happens to have network issues and delays the sending of the new block.

The incorrect part of the original post is that it is a fairness issue, this is not a true statement. The validator node has an obligation to produce a block if it’s next in line to produce one. As it’s accounted for in the consensus protocol, if the new block of the expected block producer for that round arrives in time, the produced block is discarded.

We understand that this may lead to a tolerance block being discarded however it does not impact the protocol fairness in the short or long term, it’s an expected network liveness feature.

Thank you for your response and for the inclusiveness fostered within our community. Let’s continue working together to make VeChainThor better.

The original post raised a concern about a potential decrease in fairness within the VeChainThor blockchain when there is a delay in block issuance.

Your understanding of our attack description appears accurate. However, it seems there might be some ambiguity in your understanding of what ‘fairness’ entails in this context.

Fairness, according to the Cambridge Dictionary, is “the treatment of everyone in the same way, so that no one has an advantage.” In this specific discussion, it means:

  1. Honest validator nodes that follow the protocol for block creation should receive consistent rewards.
  2. Malicious validator nodes that deviate from the protocol should face appropriate penalties.

It is evident that malicious nodes, by their damaging actions (e.g., delay the block), not only evade penalties but also impede honest block-producing validators from earning rewards. Therefore, we believe that the current reward mechanism in the consensus protocol lacks fairness.

For a more detailed exploration of fairness, I suggest reviewing the definition provided by Pass and Shi in their 2016 FruitChains paper, available here: https://eprint.iacr.org/2016/916.pdf

If you still have doubts about fairness, let us set aside the conventional definition of fairness and start with this statement from the white paper:

All nodes have an equal opportunity to create new blocks and earn rewards, without the need to spend vast resources competing against each other.

This principle underscores the right to equal reward opportunities. Under the attack strategy discussed, it is apparent that the current version of the VeChainThor algorithm does not ensure equal rewards, as honest validators’ blocks are discarded and their rewards nullified.

We appreciate your engagement in this important discussion and look forward to your thoughts.

We understand that this may lead to a tolerance block being discarded however it does not impact the protocol fairness in the short or long term, it’s an expected network liveness feature.

Yep, it is correct ! A simple strategy resulting in the brief loss of a block does not compromise the chain’s safety or liveness. This is a designed aspect of the network’s liveness features, anticipated to handle transient disruptions efficiently.

Thank you @garayle8 for shedding light on this! We appreciate your dedication to ensuring fairness and integrity within the VeChainThor blockchain.

The concept of fairness, especially as it pertains to the consistent rewards for honest validators and penalties for malicious actors, is crucial for the success of our network.

It is important to ensure all nodes have an equal opportunity to create new blocks and earn rewards. Like you say this is a foundational principle of our network. The concern that honest validators could be disadvantaged by the described attack vector is something we will always take seriously, so thank you for bringing it to our attention!

To address this, we want to highlight that any actions by validator nodes that could be perceived as unfair or disruptive are subject to review by our governance committee. This committee is responsible for maintaining the health of the network and can implement measures to penalize malicious actions. In our Proof of Authority (PoA) consensus mechanism, particularly with the incorporation of KYC, we have the means to identify and penalize validators that engage in unfair practices.

We are committed to continuously improving our protocol and ensuring that it aligns with our principles of fairness and equal opportunity. Thank you for your valuable contributions and for helping us work towards a healthier and more equitable network.

1 Like