Delegated Attestation

In delegated attestation, a validator delegates the signing duty of its attestations to a remote service. The validator retains custody of its private withdrawal and signing keys but provides a BLST (Boneh–Lynn–Shacham) signature to the attester service, authorizing it to sign attestations on its behalf for a specific epoch. This separates the operational burden of maintaining high-availability signing infrastructure from the stake ownership.

The dominant implementation is within Ethereum's PBS (Proposer-Builder Separation) ecosystem. Validators running MEV-Boost delegate their attestations to relays. This is critical because:

• The validator must attest to the correct block header received from the relay.
• Fast, reliable attestation is necessary to avoid penalties.
• It allows validators to focus on block proposal logic while the relay handles the attestation broadcast network.

1. Authorization: Validator signs a message with its BLS key granting attestation rights to a specific service for an epoch.
2. Duty Delivery: The attester service monitors the blockchain for the validator's assigned attestation slots.
3. Signing & Propagation: The service creates the attestation data, signs it using the provided authorization, and immediately broadcasts it to the network.
4. Separation of Concerns: The validator's primary machine does not need to be online for attestation duties, reducing its attack surface and infrastructure cost.

• Improved Uptime: Professional attester services have robust, geographically distributed infrastructure, leading to higher reward rates and fewer inactivity leaks.
• Infrastructure Simplification: Validators can run less complex, more secure setups for their key custody.
• Network Health: Delegation to high-performance nodes can improve the overall speed and reliability of the consensus layer.
• Focus on Proposals: Validators concentrate resources on the more complex and lucrative block proposal role.

• Trust Assumption: The validator must trust the attester service not to sign incorrect or slashable attestations (e.g., surrounding or double votes).
• Centralization Pressure: Reliance on a few major attester services creates network resilience risks.
• Latency Sensitivity: The attester service must have extremely low latency to the validator client and the peer-to-peer network to avoid late attestations.
• Authorization Scope: The delegated permission is time-bound (per-epoch) to limit exposure if a service is compromised.

• Ethereum Relays: Services like BloXroute, Flashbots, Agnostic, and Ultra Sound relay blocks to validators and typically provide delegated attestation services to their users.
• Staking Pools & SaaS: Enterprise staking providers and Staking-as-a-Service platforms often operate internal attester networks for all their managed validators.
• DVT Clusters: In Distributed Validator Technology (DVT) setups, the attestation duty is often handled by a designated node within the cluster, representing a form of internal delegation.

Delegation concentrates power in a small set of attestors. This creates a single point of failure and a high-value target for attacks. If a major attestor is compromised or acts maliciously, it can:

• Censor transactions or state updates.
• Sign fraudulent attestations, potentially stealing funds or corrupting data.
• Cause system-wide downtime if its service fails.

This risk is analogous to the validator centralization problem in Proof-of-Stake networks.

The security of the entire delegated system hinges on the private keys held by attestors. Key-related risks include:

• Hot Wallet Exploits: Attestors using online keys for signing are vulnerable to remote attacks.
• Insider Threats: Malicious employees or operators with key access.
• Inadequate Key Rotation: Failure to regularly rotate keys increases the window for compromise.

A single key breach can lead to the signing of invalid or malicious attestations, undermining the system's integrity.

Delegated attestation systems must balance two fundamental failure modes:

• Liveness Fault: Attestors go offline, causing the system to halt because no new attestations can be produced.
• Safety Fault: Attestors produce conflicting or incorrect attestations, leading to a fork or invalid state transition.

Mitigations like attestor slashing for safety faults and quick replacement mechanisms for liveness faults are critical but add protocol complexity.

The economic model for attestors must be carefully designed to ensure honest behavior is the rational choice. Key risks include:

• Insufficient Bond/Slash: If the cost of being slashed for misbehavior is less than the profit from an attack, the system is vulnerable.
• Profit Maximization: Attestors may prioritize fee revenue over system health (e.g., attesting to congested, high-fee chains).
• Collusion: Attestors may collude to censor or extract maximum value from users, forming a cartel.

Delegated attestors act as a relay layer for data. They can censor by:

• Withholding data needed to verify state transitions.
• Selectively attesting to certain transactions or blocks while ignoring others.
• Charging prohibitive fees for inclusion, a form of economic censorship.

This requires mechanisms like data availability sampling and fallback attestor networks to ensure liveness and permissionless access.

The ability to upgrade the attestation protocol or smart contracts introduces governance risks:

• Malicious Upgrades: A governance takeover could push an upgrade that compromises attestor keys or logic.
• Upgrade Timelock Bypass: If upgrade mechanisms lack sufficient delays or multi-sig controls, they can be exploited.
• Attestor Client Diversity: A bug in a dominant attestor client software could cause a mass slashing event or chain halt.

Timelocks, multi-sig governance, and client diversity are essential countermeasures.

An attestation is a signed vote by a validator on the validity and finality of a block in a proof-of-stake blockchain. It is the fundamental unit of consensus signaling, containing:

• A vote for the block at a specific slot.
• A vote for the block's ancestor, establishing the LMD-GHOST fork choice rule.
• The validator's cryptographic signature. Delegated attestation outsources the signing of this critical message to a trusted service.

The validator client is the software responsible for a validator's core duties: proposing blocks and making attestations. In a delegated setup, this client is often run by the staker (delegator) and contains the withdrawal credentials and fee recipient address. It generates unsigned attestation duties and sends them to a separate Remote Signer for cryptographic signing, separating key management from consensus logic.

A Remote Signer is a dedicated, secure service that holds a validator's private signing keys and performs cryptographic operations on request. It is the core infrastructure in delegated attestation, offering:

• Hardware Security Module (HSM) or TEE protection for keys.
• High availability and low-latency signing.
• Audit logs for all signing requests. The validator client communicates with it via standards like the Web3Signer API, sending unsigned payloads and receiving signatures.

MEV-Boost is a prominent example of role delegation in Ethereum, specifically for block proposal. It implements Proposer-Builder Separation (PBS):

• Builders construct full blocks, competing on value (including MEV).
• Proposers (validators) simply sign and broadcast the most valuable header. This separates block construction from proposal, analogous to how delegated attestation separates attestation duty from signing.

Distributed Validator Technology (DVT) is a related but distinct primitive that uses multi-party computation (MPC) and consensus to split a single validator's duties across multiple nodes. Unlike simple delegation to one signer, DVT:

• Distributes trust across an operator committee.
• Requires a threshold (e.g., 3-of-4) of signatures to produce a valid attestation.
• Provides fault tolerance against individual node failure. It enhances security and resilience where delegation optimizes for performance.

Staking pools (e.g., Lido, Rocket Pool) are large-scale applications built on top of delegated attestation infrastructure. They aggregate stake from many users, run vast arrays of validators, and issue liquid staking tokens (LSTs) like stETH. Their operation relies critically on:

• Secure, scalable remote signers to manage thousands of validator keys.
• Sophisticated orchestration to handle attestation duties for the entire pool. They represent the end-user-facing service enabled by the delegation primitive.