Module aggregation 

Recover quorum certificates over an externally synchronized sequencer of items.

This module allows a dynamic set of participants to collectively produce quorum certificates for any ordered sequence of items.

The primary use case for this primitive is to allow blockchain validators to agree on a series of state roots emitted from an opaque consensus process. Because some chains may finalize transaction data but not the output of said transactions during consensus, agreement must be achieved asynchronously over the output of consensus to support state sync and client balance proofs.

For applications that want to collect quorum certificates over concurrent, sequencer-driven broadcast, check out crate::ordered_broadcast.

Pluggable Cryptography

The aggregation module is generic over the signing scheme, allowing users to choose the cryptographic scheme best suited for their requirements:

• ed25519: Attributable signatures with individual verification. HSM-friendly, no trusted setup required. Certificates contain individual signatures.

• bls12381_multisig: Attributable signatures with aggregated verification. Produces compact certificates while preserving signer attribution.

• bls12381_threshold: Non-attributable threshold signatures. Produces succinct constant-size certificates. Requires trusted setup (DKG).

Architecture

The core of the module is the Engine. It manages the agreement process by:

• Requesting externally synchronized commonware_cryptography::Digests
• Signing said digests with the configured scheme’s signature type
• Multicasting signatures/shares to other validators
• Assembling certificates from a quorum of signatures
• Monitoring recovery progress and notifying the application layer of recoveries

The engine interacts with four main components:

• crate::Automaton: Provides external digests
• crate::Reporter: Receives agreement confirmations
• crate::Monitor: Tracks epoch transitions
• commonware_cryptography::certificate::Provider: Manages validator sets and network identities

Design Decisions

Missing Certificate Resolution

The engine does not try to “fill gaps” when certificates are missing. When validators fall behind or miss signatures for certain indices, the tip may skip ahead and those certificates may never be emitted by the local engine. Before skipping ahead, we ensure that at-least-one honest validator has the certificate for any skipped index.

Like other consensus primitives, aggregation’s design prioritizes doing useful work at tip and minimal complexity over providing a comprehensive recovery mechanism. As a result, applications that need to build a complete history of all formed types::Certificates must implement their own mechanism to synchronize historical results.

Recovering Certificates

In aggregation, participants never gossip recovered certificates. Rather, they gossip types::TipAcks with signatures over some index and their latest tip. This approach reduces the overhead of running aggregation concurrently with a consensus mechanism and consistently results in local recovery on stable networks. To increase the likelihood of local recovery, participants should tune the Config::activity_timeout to a value larger than the expected drift of online participants (even if all participants are synchronous the tip advancement logic will advance to the f+1th highest reported tip and drop all work below that tip minus the Config::activity_timeout).

Modules

scheme

Signing scheme implementations for aggregation.

types

Types used in aggregation.

Structs

Config

Configuration for the super::Engine.

Engine

Instance of the engine.