Draft EIP‑8390 Would Remove Sync Committee, Cutting Annual ETH Issuance by About 33,800

A draft Ethereum Improvement Proposal (EIP‑8390) has been submitted that would retire the network’s 512‑validator sync committee, remove its reward weight, and replace the Altair light‑client update flow with off‑chain zero‑knowledge (ZK) proofs of finality.

Impact on ETH issuance

The sync committee currently carries a weight of 2 in a denominator of 64 within the consensus reward formula. Removing this weight reduces consensus issuance by 2/64, or 1/32. Based on the draft’s snapshot of 901,505 validators and 42,328,615 ETH staked, the proposal estimates an annual consensus issuance of about 1.082 million ETH. A 1/32 reduction translates to roughly 33,800 ETH less issued each year.

Effect on light‑client infrastructure

Altair light clients rely on a compact update flow (LightClientUpdate) that uses sync‑committee signatures to track the beacon chain without processing the full validator set. EIP‑8390 would remove the sync‑committee duties, associated network messages, data containers, and several Beacon API endpoints. Consequently, any client that follows the Altair update path would stop working at the fork.

Confirmed implementations that would be affected include:

• Helios – embedded in wallets and dApps, uses the light‑client Beacon API.
• Lodestar – provides a consumer‑side light‑client package.
• Nimbus – exposes a light‑client interface for the same update objects.
• Datachain’s Ethereum IBC client – builds headers from LightClientUpdate and FinalityUpdate data.

The proposal does not specify a replacement API, migration path, or incentive model for producing the ZK finality proofs.

Unresolved technical and economic questions

EIP‑8390 claims that a ZK proof of Casper FFG finality could be generated on a single GPU within one epoch and verified in milliseconds, but the draft provides no reproducible implementation, circuit description, hardware benchmark, or proof‑of‑concept. A publicly available design for a full‑set proof reports sub‑minute preprocessing on a 64‑core CPU without GPU acceleration, but it remains incomplete and uses a different hardware setup.

The proposal also lacks details on:

1. The proving service architecture and client interface.
2. Reliability guarantees and operator responsibilities.
3. Funding or incentive mechanisms for proof generation.

Without these components, the network would replace an existing, albeit imperfect, on‑chain trust mechanism with an unimplemented off‑chain system.

Next steps

EIP‑8390 is currently a draft in the official EIPs repository (entered on 24 August 2024). It has no activation epoch, roadmap commitment, or external review. Moving toward activation would require:

• A tested Beacon API contract for ZK finality proofs.
• Migration tooling for existing Altair light‑client users.
• Demonstrated, publicly auditable proof generation and verification.
• An incentive or funding model to sustain the proving service.

Until such specifications are provided, the proposal remains a design discussion rather than an imminent network upgrade.