Attestation Duty

An attestation duty is a validator's primary task to cryptographically sign and broadcast a vote on the canonical chain. This vote includes:

• The validator's view of the current head of the chain.
• The validator's view of the most recent justified checkpoint.
• The validator's view of the most recent finalized checkpoint. These votes are aggregated by the network to achieve consensus on the state of the blockchain.

Attestation duties are not performed at random. The Beacon Chain's consensus client schedules them precisely. Each validator is assigned to a specific committee and a specific slot (a 12-second period) within an epoch (32 slots). A validator typically performs one attestation duty per epoch, ensuring a predictable and distributed workload across the entire validator set.

Successful completion of attestation duties is the primary source of staking rewards. Rewards are weighted based on:

• Correctness: Voting for the canonical chain head and correct checkpoints.
• Inclusion delay: How quickly the attestation is included in a block. Failure to perform a duty results in an inactivity leak penalty, and consistently incorrect attestations can lead to slashing, where a portion of the validator's stake is burned.

Individual validator attestations are not processed alone. They are aggregated by attestation aggregators within the same committee. Aggregators combine hundreds of BLS signatures into a single aggregated signature. This signature aggregation is critical for scalability, drastically reducing the data that needs to be stored on-chain and verified by all nodes.

Attestations are the mechanism that drives the Casper FFG (Friendly Finality Gadget) protocol. When a supermajority (two-thirds) of the total staked ETH attests to a checkpoint over two consecutive epochs, that checkpoint becomes justified and then finalized. Finality means the block is irreversible under normal network conditions, providing strong economic security.

Executing an attestation duty is a coordinated task between a validator's consensus client (e.g., Prysm, Lighthouse) and validator client (e.g., Teku, Nimbus). The consensus client informs the validator client of its duty schedule. The validator client then:

1. Creates the attestation data (vote).
2. Signs it with its private key.
3. Returns the signed attestation to the consensus client for broadcasting to the network.

Rollups like Optimism and Arbitrum use attestation-like mechanisms for their sequencer selection or fault proofs. A committee of validators may attest to the validity of state transitions or the correct ordering of transactions before data is posted to L1.

• Ensures data availability and state correctness.
• Prevents malicious sequencers from censoring or reordering transactions.

Attestation committees are used by light client bridges and optimistic verification systems to validate events on a source chain. Validators attest to the validity of a transaction or state root, which is then relayed to a destination chain.

• Examples: Succinct Labs' Telepathy, Polygon zkEVM Bridge.
• Provides a cryptoeconomically secure alternative to multisig validators.

Oracle networks like Chainlink and Pyth Network employ attestation duties within their decentralized data feeds. Node operators attest to the accuracy of price data or real-world events, with consensus reached off-chain before an aggregate value is posted on-chain.

• Mitigates single points of failure.
• Uses cryptographic signatures to prove data provenance and node participation.

In modular blockchain architectures like Celestia and EigenDA, attestation duties are performed by light nodes or DA committee members. They sample small, random chunks of block data and attest to its availability, enabling scalable data verification without downloading entire blocks.

• Critical for validity proofs and fraud proofs in rollups.
• Enables secure scaling through erasure coding.

Independent PoS sidechains and app-chains (e.g., built with Cosmos SDK, Polygon Edge) implement their own attestation duties for block validation and consensus. Validators propose and attest to blocks to secure the network and produce finality.

• Similar mechanics to Ethereum but with customizable parameters.
• Often uses Tendermint BFT or other consensus engines.

An attestation is a validator's signed vote on the validity of a block and the current state of the chain. It includes votes for:

• Block Head: The most recent valid block.
• Source Checkpoint: The most recent justified epoch.
• Target Checkpoint: The current epoch's boundary block.

These votes are aggregated by the consensus protocol to finalize the chain.

The inactivity leak is a severe penalty mechanism that activates if the chain fails to finalize for more than four epochs. Validators who are not attesting correctly see their staked ETH slashed progressively faster. This mechanism forces the network to converge on a canonical chain by penalizing validators on the non-finalizing fork, eventually allowing the active majority to regain finality.

Validators receive small penalties for incorrect or missing attestations, distinct from slashing. These include:

• Missed Attestation: A penalty equal to the reward you would have earned.
• Incorrect Attestation: A penalty for attesting to an incorrect source, target, or head.

These penalties are proportional to the validator's effective balance and ensure liveness is economically incentivized.

Slashing is a severe penalty for provably malicious actions. For attestation duty, the primary slashable offense is double voting (also called a surround vote). This occurs when a validator signs two conflicting attestations for the same target epoch. The penalty includes:

• An immediate slash of up to 1 ETH.
• Forced exit from the validator set.
• A correlated penalty that increases if many validators are slashed simultaneously.

Attestation performance directly impacts a validator's Annual Percentage Yield (APY). Rewards and penalties are calculated per epoch based on:

• Inclusion Delay: How quickly an attestation is included in a block.
• Correctness: Voting for the right source, target, and head.

Optimal performance yields maximum rewards, while poor uptime or incorrect votes results in a net loss of staked ETH over time.

To avoid penalties, node operators must ensure:

• High Uptime: Maintain >99% consensus client and execution client availability.
• Time Synchronization: Use NTP to keep system time within 0.5 seconds of standard time.
• Network Redundancy: Employ multiple, diverse peers and reliable internet connectivity.
• Monitoring: Use tools like beacon chain explorers to track attestation effectiveness and missed duties.