Skip to content

v5.1.0

Latest

Choose a tag to compare

@cyc60 cyc60 released this 23 Sep 07:04
1fa37a5

Highlights

Lower execution client requirements: no more full-history event scans (#840, #842, #843, #848, #851)

Until now the operator walked the chain from the keeper genesis block to build its caches. That meant the execution client on the operator machine had to keep the entire event log history since the keeper deployment. On Ethereum mainnet and Gnosis that is hundreds of gigabytes of receipt and log data, stored and indexed just so the operator can replay events it will never need again. The requirement only puts more pressure on operators as the chains grow.

That requirement is gone. Each network config now carries pinned checkpoints, and the operator only scans forward from them:

  • Vault validators are seeded from a network-wide IPFS dump (#842). The vault's ValidatorRegistered events up to the dump block are loaded in a single fetch, and the validators checkpoint starts there instead of at genesis.
  • Oracle config (ConfigUpdated) scans start from a release checkpoint, falling back to the pinned last-event block when nothing newer exists (#840).
  • Exit signatures (ExitSignaturesUpdated) do the same on a cold cache (#843). Older rotations are long finalized and already synced by oracles, so they don't gate a new rotation.
  • Rewards (RewardsUpdated) lookback is limited to one month instead of sweeping to genesis when no recent event is found (#851).
  • Removed the unreachable genesis-block scan in ProcessedSharesCache (#848).

Net effect:

  • The execution client can prune receipts and logs below the checkpoint and reclaim that space.
  • The operator puts much lower RPC load on the node, which matters most with providers that enforce strict getLogs limits.
  • First run reaches ready state noticeably faster.

New event log retention requirements

The operator needs event logs only from the network's checkpoint onward. If your execution client prunes history, make sure logs are retained from at least these blocks:

Network Required from block Recommended setting
Ethereum mainnet 25,933,938 25,900,000
Hoodi 3,583,807 3,580,000
Gnosis 48,127,042 48,100,000

The recommended value simply rounds down to leave a safety margin; anything at or below it works.

Older operator versions still require the full log history, so do not prune before upgrading.

Withdrawals: reward accrual buffer (#846)

Queued exit assets keep accruing rewards while a withdrawal is pending on the consensus layer (~27h for a partial withdrawal, up to ~11 days for a full exit), so requesting the exact shortfall always left a new tiny one behind — an endless trickle of dust withdrawals. Withdrawal requests are now padded with a buffer of 0.1% of the exit queue value, with a floor and a 1 ETH cap. Two new environment variables:

  • MIN_WITHDRAWAL_BUFFER_GWEI (default 10000) — minimum padding added on top of the shortfall, capped at 1 ETH.
  • MISSING_ASSETS_THRESHOLD_GWEI (default 1) — minimum exit queue shortfall that triggers a withdrawal, capped at 0.01 ETH to stay below the oracle's own exit threshold. Validated at startup.

Operator version telemetry (#838)

The operator reports its version to the StakeWise backend once every 24h (TELEMETRY_INTERVAL), signed by the vault validators manager wallet. Opt out with --disable-telemetry / DISABLE_TELEMETRY; it is disabled automatically in relayer mode, where the relayer holds the manager role.

Other notable changes

  • Wait for the execution client to import the latest consensus head, fixing intermittent header not found errors at the chain tip (#850)
  • Verify deposit signatures returned by remote signers (#836)
  • Remove stale web3signer key files on export; fix disable-validators env var names (#837)

What's Changed

Full Changelog: v5.0.0...v5.1.0