https://hackerone.com/reports/2289066

Summary:

AleoBFT updates the committee (stake, status, etc) with every block. At each even round, elect the leader from the committee with latest committed block. This will introduce two issues:

** Issue a. Leader Manipulation **:

The leader is selected from the committee by the seed which is composed of self.starting_round, current_round, total_stake. However, the current leader can manipulate total_stake by adding bond_public transactions in its batch. The leader can easily find the target total_stake which make itself the leader for the next round. Thus, a leader can keep itself as a leader forever.

** Issue b. Permanent Chain State Split **

In current AleoBFT, the leader election directly depends on the latest committed block. However, for asynchronous network, some validators may have committed a block but some others not, making validators elect different leaders. This will cause permanent chain state split.

I will provide Steps To Reproduce for Issue a and Proof-of-Concept for Issue b.

Steps To Reproduce:

For Issue a.

1. Clone https://github.com/Gooong/snarkOS/tree/manipulate_consensus
2. Run ./devnet.sh with default setting
3. Wait for 100 rounds
4. Check validator-0.log and find that the validator 0 has been leader for most even rounds. (Just count the line by searching elected a leader - aleo1rhgdu77hgyqd3xjj8ucu3jj9r2krwz6mnzyd80gncr5fxcwlh5rsvzp9px and compare that by count the line elected a leader)

Also see the example validator-0.log at the attachment.

Note that, in our code, Validator 0 only send the transaction with best effort. In practice, the the leader can directly simulate and add the transaction to the batch. This will 100% make itself the leader of future rounds and other validator can not do anything to prevent this.

For issue b.

Take the picture in the bullshark blog as example.

Suppose we are in Round 3, while deciding the leader for current round, Validator 1 will find that Round 1 hasn’t been committed so it will use committee in the round before Round 1. However, in Validator 4’s view, Round 1 has been committed so it just decide the leader from Round 1’s committee. This will cause permanent chain state split.

Additional considerations

The ambiguous of latest committee will also introduce other tricky problems:

If last block haven’t been committed, we can’t tell if the current round BatchCertificate (either from other peers or from myself) has reached quorum. Because the committe will change once the last block is committed. This function in LedgerService makes the committee ambiguous.

    /// Returns the committee for the given round.
    /// If the given round is in the future, then the current committee is returned.
    fn get_committee_for_round(&self, round: u64) -> Result<Committee<N>> {
        match self.ledger.get_committee_for_round(round)? {
            // Return the committee if it exists.
            Some(committee) => Ok(committee),
            // Return the current committee if the round is in the future.
            None => {
                // Retrieve the current committee.
                let current_committee = self.current_committee()?;
                // Return the current committee if the round is in the future.
                match current_committee.starting_round() <= round {
                    true => Ok(current_committee),
                    false => bail!("No committee found for round {round} in the ledger"),
                }
            }
        }
    }

I think we can fix this by:

1. In current_round, use the committe from current_round - COMMITTEE_LAG_ROUND round. (COMMITTEE_LAG_ROUND could be large enough like 100 or 1000) The function will be like:

    /// Returns the committee for the given round.
    /// If the given round is in the future, then the current committee is returned.
    fn get_committee_for_round(&self, round: u64) -> Result<Committee<N>> {
        match self.ledger.get_committee_for_round(round.saturating_sub(COMMITTEE_LAG_ROUND) )? {
            // Return the committee if it exists.
            Some(committee) => Ok(committee),
            // Return the current committee if the round is in the future.
            None => {
                bail!("No committee found for round {round} in the ledger"),
            }
        }
    }

In this way, the concensue will stall if the latest COMMITTEE_LAG_ROUND round hasn’t been committed.

1. Or keep the committee the same for the whole Epoch. But we need to be cautious at the Epoch boundary.

Supporting Material/References:

See the attachment

Fix Suggestions:

The problem here is that AleoBFT’s committee directly depends on the latest committed state. However, the latest state is easy to manipulate and can temporarily mismatch.

It’s suggested to fix the committee for some fixed rounds. Also, while choosing leader, only use random seed that is hard to manipulate.

In SUI, the validator committee is fixed for the whole epoh (~24h). In the codebase of bullshark paper, it directly use round-robin: https://github.com/asonnino/narwhal/blob/667595d9dc82a472bade5afd59993d8479047a48/consensus/src/lib.rs#L205

Impact

Current AleoBFT implementation will cause: (a) leader manipulation and (b) permanent chain state split