bee icon indicating copy to clipboard operation
bee copied to clipboard
verified publisher icon ethersphere

Graceful Swarm hardforking

Open mfw78 opened this issue 2 years ago • 4 comments

Summary

A graceful way to migrate nodes from a version of Swarm to another version with breaking changes.

Motivation

For any production-grade code, continuity of service, even when under maintenance, is a necessity. As Swarm matures, there may very well be upgrades required that are not backwards compatible, requiring a method to co-ordinate network-wide upgrades.

Use cases include:

  1. Future changes that may occur to economics (requiring a change in the game, different contracts etc).
  2. Future changes to underlying transport technologies (read: libp2p upgrades, migration from TCP to UDP for hole punching, wss mesh capabilities etc).

Implementation

Suggest to use a "target round" for upgrades. i.e the current storage-incentives uses the concept of "rounds", with each round having 152 blocks, therefore from Swarm's perspective, the current round = block.height / 152.

By co-ordinating protocol upgrades on a round-based target:

  1. A fixed point in time is known (block timing is highly predictable on Gnosis Chain, though missed blocks do occur at a higher frequency than on Ethereum mainnet).
  2. Internal components within bee are already dependent on the notion of a round - ie. samplers / redistribution agent.

Therefore:

  1. By using the swarm version on handshake, can record a protocol support matrix (such as when pullsync is bumped, or other protocols within are bumped).
  2. At the target round, non-upgraded nodes are pruned.

Drawbacks

Adds increased complexity / co-ordination overhead.

mfw78 avatar Apr 10 '23 16:04 mfw78

what do you mean by "target round" ?

istae avatar Apr 10 '23 17:04 istae

what do you mean by "target round" ?

I suspect he means the round at which the changes should become effective. At least, that's how the blockchain clients handle things. Doing such a thing allows individual nodes to upgrade before the effective round and then all of the upgraded nodes will automatically start using the new functionality when that round arrives. It allows for pro-active upgrades and minimal swarm disruption as compared to the current "catch-up" upgrade path where slow-to-upgrade swaths of the swarm are summarily dropped when the new version is deployed.

ldeffenb avatar Apr 10 '23 18:04 ldeffenb

what do you mean by "target round" ?

As @ldeffenb alluded to. I've updated the head issue to further expand on this.

mfw78 avatar Apr 11 '23 05:04 mfw78

Great! I add also: with the time to test new APIs for breaking changes and update clients and dependent software.

tmm360 avatar Apr 11 '23 23:04 tmm360