Committee

Committees are crucial for achieving finality—the irreversible confirmation of a block. Members attest to the validity of proposed blocks by casting votes. When a supermajority (e.g., two-thirds) of a committee agrees, the block is finalized. This process, central to Casper FFG and other BFT-style consensus, makes blockchain reorganizations beyond the finalized checkpoint extremely costly.

Committees monitor for malicious behavior and enforce protocol rules. They participate in slashing—the punitive removal of a validator's staked funds—for offenses like double-signing or liveness failures. By distributing this oversight role across a randomly selected group, the network mitigates corruption and ensures no single validator can falsely accuse others without consensus.

In Proof-of-Stake (PoS) and Byzantine Fault Tolerant (BFT) systems, a committee is a randomly selected subset of validators responsible for proposing and finalizing blocks for a specific slot or epoch. This reduces the communication overhead of involving the entire validator set, enabling faster finality and higher throughput. Examples include:

• Ethereum's Beacon Chain: The sync committee signs block headers for light clients.
• Avalanche: Uses repeated sub-sampled voting by committees to achieve consensus.
• Solana: A leader (block producer) is chosen from a rotating committee schedule.

These are elected or appointed bodies that manage protocol upgrades, treasury funds, or parameter changes. They provide a more agile decision-making layer than full token-holder votes for routine operations.

• MakerDAO's Governance Facilitators: Manage the executive vote process.
• Compound's Comet Committee: Can adjust market parameters for new assets.
• Decentralized Autonomous Organization (DAO) Subcommittees: Often handle grants, security, or legal matters, delegating specialized tasks from the main DAO.

Act as a circuit breaker or guardian role in smart contract ecosystems, typically with multisig control over critical protocol functions to mitigate risks.

• Optimism's Security Council: Can execute emergency actions to protect the network.
• Arbitrum's Security Council: Holds upgrade keys for the core contracts, enabling rapid response to vulnerabilities.
• Cross-chain Bridge Committees: Often manage multisig wallets that hold bridged assets, representing a centralization trade-off for usability.

How members are chosen is critical for security and decentralization. Common methods include:

• Random Sampling: Validators are pseudorandomly selected based on stake (e.g., Ethereum's RANDAO/VDF).
• Approval Voting: Token holders vote to elect a fixed set of committee members for a term.
• Delegated Proof-of-Stake (DPoS): Top vote-getters in a stake-weighted election form the active block production committee. The goal is to prevent takeover attacks while ensuring liveness and performance.

Committees introduce specific design considerations:

• Security vs. Efficiency: A smaller committee is faster but more vulnerable to corruption if a threshold (e.g., 1/3 or 1/2) is compromised.
• Decentralization: Over-reliance on a fixed committee can lead to centralization. Regular rotation is essential.
• Accountability: Mechanisms like slashing (for consensus committees) or reputation systems are needed to penalize malicious or lazy members.
• Sybil Resistance: Selection must be tied to a costly resource like stake or a verified identity.

A secure committee must be Sybil-resistant, meaning a single entity cannot easily create multiple identities to control it. Selection is typically based on a scarce resource like staked tokens (Proof-of-Stake) or computational work (Proof-of-Work). Random sampling, often using Verifiable Random Functions (VRFs), is used to ensure unpredictability and fairness in member selection.

Committees are designed to be Byzantine Fault Tolerant (BFT), tolerating a certain fraction of malicious or faulty members. For a committee of size n, classic BFT protocols like PBFT require more than 2/3 of members to be honest (f < n/3 faults). This threshold ensures safety (no two conflicting blocks are finalized) and liveness (the network continues to produce blocks).

• Static Corruption: Adversary selects which nodes to corrupt before the protocol run. Easier to defend against.
• Adaptive Corruption: Adversary can choose which nodes to corrupt during the protocol, based on observed behavior. This is a stronger, more realistic threat model. Secure committee designs must account for adaptive adversaries, often through frequent committee rotation and secret leader election.

Security increases with committee size (larger n makes collusion harder) but conflicts with scalability. Larger committees increase communication overhead (O(n²) messages in naive BFT). Solutions include:

• Hierarchical committees (e.g., Ethereum's beacon chain)
• Threshold cryptography (e.g., DKG, BLS signatures)
• Sub-sampling for specific tasks (e.g., availability committees).

In Proof-of-Stake, a past committee could collude to create an alternative chain history (long-range attack). Defenses include:

• Weak subjectivity: New nodes rely on recent, socially-verified checkpoints.
• Slashing: Penalizing validators for signing conflicting blocks, making attacks economically prohibitive.
• Ethereum's checkpoint finality requires a 2/3 supermajority of the validator set across two epochs.

Ethereum's consensus layer uses a committee of 128 validators randomly assigned to each slot. Key security parameters:

• Requires at least ≥ 2/3 of the committee for attestation.
• Slashing penalizes equivocation.
• Inactivity leak reduces stake of validators if the chain fails to finalize, eventually allowing honest majority to regain control. This design balances scalability (small per-slot committee) with security (full validator set secures finality over epochs).