
An attestation is a validator's signed vote about the state of the chain: which block it believes is the current head, and which checkpoints it believes should be locked in as final. In a proof-of-stake network, attestations are how the chain finds out what its validators actually think. Blocks are proposed by one validator at a time, but a block only means something once thousands of other validators have attested to it.
Most explanations of proof of stake focus on the proposer — the validator chosen to build the next block. That's understandable; it's the visible job. But it's also rare. On Ethereum, with well over a million active validators and one proposer per 12-second slot, an individual validator might wait months between proposals. What every validator does constantly, once per epoch, every epoch, is attest. Attesting is the day job. Proposing is the occasional lottery win. If you want to understand what "voting weight" or "two-thirds of stake" actually refers to when people discuss PoS security, the answer is attestations.
An Ethereum attestation is compact, but it's carrying three votes in one signature, and the three do different jobs:
The source and target votes feed Casper FFG, the finality mechanism. When two-thirds of all staked ETH attests to the same source-target pair, the target checkpoint becomes justified; when the next checkpoint is justified on top of it, the earlier one becomes final — economically irreversible, in the sense that reverting it would require at least a third of all staked ETH to be slashed.
So one small signed message is simultaneously steering the chain's short-term growth and casting a ballot in its long-term finality. That dual role is worth sitting with, because it explains why attestation health is the vital sign of a proof-of-stake network. If attestations stop flowing, the chain doesn't just get slower — it stops finalizing.
The obvious design — every validator votes on every block — doesn't survive contact with the numbers. Over a million validators broadcasting a signature every 12 seconds would drown the network in messages before it did anything else. The protocol solves this two ways.
First, it rations the votes. Each validator attests exactly once per epoch, and the validator set is shuffled into committees spread across the epoch's 32 slots. Each slot, that slot's committees vote; by the end of the epoch, every active validator has spoken exactly once. One complete voting round per epoch, paid out in 32 installments.
Second, it compresses them. Attestations use BLS signatures, which have a convenient mathematical property: many signatures over the same message can be merged into a single aggregate signature that verifies as one. Within each slot, designated aggregators collect the individual attestations from their committee and bundle the matching ones. The next block doesn't carry thousands of separate votes — it carries a handful of dense aggregates. Without aggregation, committee-based voting still wouldn't fit; with it, a block can represent the voice of tens of thousands of validators in a few kilobytes.
Timing matters here, and it's tight. Inside the 12-second slot, the block is published in the first four seconds, attestations are cast in the middle four, and aggregation happens in the final four. A validator that attests late — because its node was slow, or the block reached it late — earns less than one that attests on time, and an attestation that arrives too late to be included does nothing at all.
Attestation rewards are where a validator makes most of its money. The protocol scores each attestation on whether the source, target, and head votes were correct and timely, and pays accordingly. Miss the attestation entirely and you take a small penalty. Vote for the wrong head because your node was momentarily confused? You just forfeit part of the reward. This is ordinary wear and tear — every validator drops attestations occasionally, and the design tolerates it.
Slashing is a different category, and the distinction gets muddled constantly. Being offline or wrong is penalized lightly. What gets a validator slashed — a forced exit plus a meaningful loss of stake — is equivocation: signing two different attestations for the same target epoch, or signing one attestation that "surrounds" another. Both amount to voting twice, which is the one thing a voting system can't tolerate. An honest validator running one properly configured node essentially can't commit these offenses by accident; the classic way it happens is running the same validator key on two machines for redundancy. The protocol doesn't punish being wrong. It punishes trying to have it both ways.
The hard constraint is bandwidth arithmetic. Committee scheduling and BLS aggregation exist because a global network physically cannot carry one message per validator per slot at this scale. That constraint shapes everything downstream — including finality taking about two epochs, since a full round of voting takes an epoch to collect.
The soft constraint is the two-thirds participation assumption. Justification needs a supermajority of stake attesting, correctly and on time. The network has run above that line for almost its entire history, but not without incident: in May 2023, Ethereum mainnet briefly lost finality twice when consensus clients choked on an unusual load of old attestations. Blocks kept being produced — the chain kept moving — but checkpoints stopped finalizing for around an hour. It recovered on its own, and it remains the clearest real-world demonstration that block production and finality are separate systems with separate failure modes.
The attestation mechanism ran essentially unchanged from the Beacon Chain's launch in December 2020 until the Pectra upgrade in May 2025, which made two adjustments worth knowing about. One restructured the attestation message itself (EIP-7549) so that identical votes from different committees aggregate together instead of separately — same votes, fewer and denser aggregates. The other raised the maximum effective balance per validator (EIP-7251), letting large operators consolidate many 32-ETH validators into fewer, bigger ones. Fewer validators means fewer attestations for the same stake, which relieves load without changing what an attestation is.
The direction of travel is the interesting part: both changes are about compressing the voting apparatus, and that's exactly the bottleneck single-slot finality has to solve. SSF would ask every validator to vote every slot rather than once per epoch — which is an aggregation problem before it's anything else. As of mid-2026 it remains a research direction with no scheduled fork. If it ships, the once-per-epoch cadence described here gets retired.
Health looks boring: participation comfortably above two-thirds, the large majority of attestations landing on time with correct head votes, checkpoints finalizing on the two-epoch cadence. The stress signals are equally specific — participation sagging toward the threshold, timeliness degrading network-wide, or finality delays recurring beyond the isolated 2023-style incident. A redesign signal is different from a stress signal: SSF or another restructuring of the voting cadence reaching a scheduled hard fork wouldn't mean attestations failed; it would mean the protocol replaced this arrangement deliberately.
This describes what an attestation is and the role it plays in Ethereum's consensus. It isn't a validator-operations manual — the exact reward weights, penalty amounts, and slashing math have precise values this post doesn't cover — and it says nothing about the value of ETH or the returns from staking. The specifics are Ethereum's: other proof-of-stake designs vote differently (Tendermint-style chains, for instance, have every validator vote on every block, which is exactly the pattern Ethereum's scale rules out). The mechanism works as described today; how long the once-per-epoch cadence survives is a question the roadmap hasn't settled.




