Consensus manager

The consensus-manager blueprint is responsible for handling consensus between validator nodes.

A consensus-manager component was created at genesis by the system bootstrap transaction. New epochs are created under the following conditions:

1. If the current round in this epoch is below min_round_count, the current epoch stays.

2. If the current round in this epoch is above max_round_count, a new epoch is created.

3. If neither conditions 1 nor 2 are the case, then a new epoch is created if more than target_duration_millis time has passed in the current epoch.

The consensus manager contains getter functions that can be used to deterministically fetch the current time in the context of the blockchain. This is done by fetching the timestamp that the latest round was started on.

The two most important functions are the create_validator() and next_round() methods, which handle creating new validators and advancing the consensus state to the next round, respectively. The next_round() method in particular is only callable through a system transaction, and thus we will not cover the details of this function here. However, we have not found any issues in the method logic after auditing this method.

Method: create_validator()

The method signature is create_validator(key: Secp256k1PublicKey, fee_factor: Decimal, xrd_payment: Bucket, api: &mut Y).

This method can be called by anyone to create a new validator. The key argument is used as the public key for the newly created validator.

The xrd_payment bucket must contain enough XRD in it to pay for the validator-creation cost, which is a configurable field in the consensus-manager component. The XRD in the bucket is burned.

The fee_factor argument is used to determine the amount of the emissions that the validator owner keeps. This is important in the context of delegators staking their tokens to a validator.

This function creates a component of the validator native blueprint and returns the address.