ghostant-1017 - The introduction of ARC-41 in the current implementation of AleoBFT will make the network less secure compared to before.

[sherlock-admin3]

ghostant-1017

High

The introduction of ARC-41 in the current implementation of AleoBFT will make the network less secure compared to before.

Summary

I believe that the introduction of ARC-41 in the current implementation of AleoBFT will make the network less secure compared to before.

Vulnerability Detail

I base my analysis on the following three facts:

• In the current implementation of AleoBFT, the profit obtained by a Validator node not participating in consensus is exactly the same as that of a Validator node participating in consensus (only proportional to the amount staked).

• The introduction of ARC41 allows anyone who raises 10 million Aleo Credits to become a member of the consensus Committee and join the consensus network.

• Funds staked by users to any Validator node are secure, and the only factor affecting earnings is the validator's commission rate.

Hazards brought by ARC41:

• If a malicious Validator (not participating in consensus, existing in the committee at zero cost) sets its commission rate to 0, how can honest validator nodes (which require additional operational maintenance costs) compete with it? From an economic perspective, all users will choose the Validator with the lowest commission rate for delegation. To protect the network's security, honest Validators must set the commission rate to 0, preventing users from delegating Credits to malicious Validators, thus losing the meaning of the commission rate.
• In all PoS consensus mechanisms, networks incentivize users to stake and provide corresponding staking rewards. The purpose is to maintain network stability because more staking means attackers need higher costs to attack the network f + 1. However, ARC41 deviates from this purpose, and more retail staking instead leads to network instability. Please note that users cannot distinguish between who is honest and who is malicious; users only care about which validator's delegation will yield higher returns.

Impact

As above describes

Code Snippet

No

Tool used

Manual Review

Recommendation

Before this ARC can be introduced, slashing for malicious behavior needs to be implemented

[evanmarshall]

I don't think this is introduced or escalated by ARC-41. The real problem is that there is no slashing nor rewards scaling. The game of theory should could result in some validators going offline to save money while collecting rewards but enough validators have to be online or else no one earns any rewards (and presumably, the token price falls).

The key difference between before & after for ARC-41 is that if enough validators were offline as to halt the chain for long enough, before the honest validators work fork the balance of the lazy validator to 0. Now, the honest validators have to fork the balance of the lazy validator and their delegators to 0. Similarly, a delegator won't delegate to a lazy validator if it increases the risk of the chain going down significantly.

Long story short, this is an existing issue with the BFT and I don't think the economics have changed with ARC-41. The introduction of commission was already planned by ARC-38 which most validators would deploy (delegation pool with commission program) and then not accept native delegation by closing off to delegators.