Background

In general, when a new version of some node software is released that contains changes affecting consensus rules or parameters, upgrading may involve transient network interruption as a super-majority of validators update, or even require full network migration if backward compatibility is lost. If the new software is unable to execute historical transactions in blocks produced by previous versions, the resolution is deploying a new chain with previous state at genesis (network migration). It is desirable to avoid these outcomes.

Network interruption may be minimized with a network-wide coordinated upgrade. For instance, CometBFT (the consensus engine)¹^,² and Cosmos SDK³^,⁴ have required coordinated upgrades between major releases. In some cases, operators plan to upgrade their software around the same time to minimize interruption in block production while the required 2/3+ of validators update. In other cases, it involves a network halt followed by exporting state for a new genesis.

kwild provides mechanisms for performing coordinated upgrades with minimal network disruption and without resetting a chain from genesis. The next section describes how network operators and developers may specify these upgrades.