upgrades

README

Osmosis Upgrades

This folder contains sub-folders for every osmosis upgrade. (Both state migrations, and hard forks) It also defines upgrade & hard fork structs, that each upgrade implements. These then get included in the application app.go to run the upgrade.

Version History

• v1 - Initial version
• v3 - short blurb on prop19 and the fork
• v4 - Berylium State Migration
• v5 - Boron State migration
• v6 - hard fork for IBC bug fix
• v7 - Carbon State migration
• v8 - Nitrogen State migration

Upgrade types

There are two upgrade types exposed, Upgrade and Fork. An Upgrade defines an upgrade that is to be acted upon by state migrations from the SDK x/upgrade module. A Fork defines a hard fork that changes some logic at a block height. If the goal is to have a new binary be compatible with the old binary prior to the upgrade height, as is the case for all osmosis Forks, then all logic changes must be height-gated or in the BeginForkLogic code.

type Upgrade struct {
 // Upgrade version name, for the upgrade handler, e.g. `v7`
 UpgradeName string
 // Function that creates an upgrade handler
 CreateUpgradeHandler func(mm *module.Manager, configurator module.Configurator, keepers *keepers.AppKeepers) upgradetypes.UpgradeHandler
 // Store upgrades, should be used for any new modules introduced, new modules deleted, or store names renamed.
 StoreUpgrades store.StoreUpgrades
}

type Fork struct {
 // Upgrade version name, for the upgrade handler, e.g. `v7`
 UpgradeName string
 // height the upgrade occurs at
 UpgradeHeight int64

 // Function that runs some custom state transition code at the beginning of a fork.
 BeginForkLogic func(ctx sdk.Context, keepers *keepers.AppKeepers)
}

Documentation

Index

• type BaseAppParamManager
• type Fork
• type Upgrade

Types

type BaseAppParamManager

type BaseAppParamManager interface {
	GetConsensusParams(ctx sdk.Context) tmproto.ConsensusParams
	StoreConsensusParams(ctx sdk.Context, cp tmproto.ConsensusParams) error
}

BaseAppParamManager defines an interrace that BaseApp is expected to fulfill that allows upgrade handlers to modify BaseApp parameters.

type Fork

type Fork struct {
	// Upgrade version name, for the upgrade handler, e.g. `v7`
	UpgradeName string
	// height the upgrade occurs at
	UpgradeHeight int64

	// Function that runs some custom state transition code at the beginning of a fork.
	BeginForkLogic func(ctx sdk.Context, keepers *keepers.AppKeepers)
}

Fork defines a struct containing the requisite fields for a non-software upgrade proposal Hard Fork at a given height to implement. There is one time code that can be added for the start of the Fork, in `BeginForkLogic`. Any other change in the code should be height-gated, if the goal is to have old and new binaries to be compatible prior to the upgrade height.

type Upgrade

type Upgrade struct {
	// Upgrade version name, for the upgrade handler, e.g. `v7`
	UpgradeName string

	// CreateUpgradeHandler defines the function that creates an upgrade handler
	CreateUpgradeHandler func(*module.Manager, module.Configurator, BaseAppParamManager, *keepers.AppKeepers) upgradetypes.UpgradeHandler

	// Store upgrades, should be used for any new modules introduced, new modules deleted, or store names renamed.
	StoreUpgrades store.StoreUpgrades
}

Upgrade defines a struct containing necessary fields that a SoftwareUpgradeProposal must have written, in order for the state migration to go smoothly. An upgrade must implement this struct, and then set it in the app.go. The app.go will then define the handler.