Proof of Authority (PoA) Consensus
The PoA consensus module provides a complete Proof of Authority implementation where a fixed set of pre-approved authorities (validators) take turns producing blocks in a round-robin fashion. This is efficient and deterministic, making it ideal for private/consortium blockchains and educational purposes.Core Types
PoAConfig
Configuration for the Proof of Authority consensus mechanism.List of authority addresses that can produce blocks. These are the pre-approved validators.
Block time target in seconds (e.g., 5 seconds per block).
Maximum allowed clock drift in seconds for timestamp validation.
Methods
new(authorities: Vec<Address>, block_time: u64) -> Self
Creates a new PoA configuration with the given authorities and block time.
is_authority(&self, address: &Address) -> bool
Checks if an address is registered as an authority.
authority_count(&self) -> usize
Returns the number of configured authorities.
authority_at_height(&self, height: u64) -> Result<Address>
Calculates which authority should produce a block at a given height using round-robin selection: height % authority_count.
Authority
Authority management for PoA consensus, including block verification and signature validation.Methods
new(config: PoAConfig) -> Self
Creates a new Authority manager with the given configuration.
register_public_key(&mut self, address: Address, public_key: PublicKey)
Registers a public key for an authority address. This is required for signature verification.
get_public_key(&self, address: &Address) -> Option<&PublicKey>
Retrieves the public key for an authority address.
config(&self) -> &PoAConfig
Returns a reference to the configuration.
is_authority(&self, address: &Address) -> bool
Checks if an address is an authority.
verify_block_authority(&self, block: &Block) -> Result<()>
Verifies that a block was produced by the correct authority:
- Checks if the author is an authority
- Checks if it’s this authority’s turn based on block height
verify_block_signature(&self, block: &Block) -> Result<()>
Verifies the block signature using the author’s registered public key.
verify_block_timestamp(&self, block: &Block, parent_timestamp: u64, now: u64) -> Result<()>
Verifies the block timestamp is valid:
- Block timestamp must be after parent
- Block timestamp cannot be too far in the future (respects
max_clock_drift)
verify_block(&self, block: &Block, parent_timestamp: u64) -> Result<()>
Performs full consensus verification:
- Verifies authority (correct turn)
- Verifies signature
- Verifies timestamp
BlockProposer
Block proposer for authorities to create and sign new blocks.Methods
new(keypair: Keypair, config: PoAConfig) -> Self
Creates a new block proposer with the given keypair and configuration.
address(&self) -> Address
Returns the proposer’s address.
can_propose_at_height(&self, height: u64) -> Result<bool>
Checks if this proposer can produce a block at the given height.
propose_block(&self, height: u64, prev_hash: Hash, transactions: Vec<Transaction>, state_root: Hash) -> Result<Block>
Proposes a new block (creates and signs it). Returns an error if it’s not this proposer’s turn.
Block height
Hash of the parent block
Transactions to include in the block
Merkle root of the state tree
Errors
ConsensusError
Errors that can occur during consensus operations.The block author is not in the authority set.
The block signature verification failed.
It’s not this authority’s turn to produce a block.
Block timestamp is too far in the future.
Block timestamp is earlier than parent.
No authorities are configured.
Complete Example
How It Works
Round-Robin Selection
PoA uses a simple round-robin algorithm to determine which authority produces each block:- Predictable block production
- Fair distribution among authorities
- Deterministic verification
Block Verification Process
- Authority Check: Verify the author is in the authority set
- Turn Check: Verify it’s this authority’s turn based on block height
- Signature Check: Verify the block signature with the authority’s public key
- Timestamp Check: Verify the timestamp is valid (after parent, not too far in future)
Advantages
- Fast: No mining, instant block production
- Predictable: Deterministic block production schedule
- Simple: Easy to understand and implement
- Efficient: Low computational requirements
Use Cases
- Private/consortium blockchains
- Development and testing environments
- Educational blockchain implementations
- Applications requiring fast finality