Walrus Reconfiguration: Zero Downtime Handover Between Committees

Most distributed systems require downtime during validator set changes. The old committee stops accepting new requests. Data is migrated. The new committee activates. Applications experience brief service interruptions while the transition occurs.

Walrus eliminates this interruption through overlapping committee operation. Rather than switching committees atomically, Walrus maintains both old and new committees simultaneously for a transition period. Writes go to the new committee.

Reads continue from the old committee. The system remains available throughout.

The mechanism is subtle but powerful. When an epoch transitions, the new committee begins immediately. Clients writing new blobs receive fragments distributed to new validators according to the new grid structure. Simultaneously, old validators remain available for reads. A client requesting data from old blobs connects to old validators, who continue serving.

This creates a brief window where the system serves dual responsibilities. New data flows to new validators. Old data remains retrievable from old validators. The two validator sets operate independently without coordination. There is no bottleneck, no synchronization point, no ceremony.

Over time, old validators can be retired. As clients gradually request old data less frequently, old validators fade from use. Eventually they can be decommissioned. The transition is gradual and invisible to applications.

This zero-downtime handover is possible because Walrus doesn't require all validators to agree on current state. Each blob has an associated epoch. The protocol knows which committee should hold which blobs. Reads and writes route to the appropriate committee automatically. No explicit migration mechanism needed.

@Walrus 🦭/acc #Walrus $WAL

WALSui
WAL
--
--