Moving away from upgradeName-based control flows

[mujahidkay]

What is the Problem Being Solved?

Currently, for cases where we require different configurations based on different networks (devnet, emerynet, mainnet), we make use of specific upgrade names to trigger a specific control flow which maps to a specific configuration. This is the most recent example from upgrade 18. Ideally, in the best case scenario, we should only have one upgrade name and our core logic should determine which control flow to execute.

Description of the Design

The design of the problem is pretty simple. Instead of having network specific upgrade names, we should standardize it to a singular name. In case of multiple RCs during release, we would need new upgrade names for re applying the upgrades but that is mostly for internal testing and use. And even then, the control flow is not dependent on those upgrade names. The goal behind this is to minimize the confusion regarding upgrade names w.r.t external validators - as was observed multiple times during upgrade 18. Having a standardized agoric-upgrade-X each time moving forward will help in minimizing that confusion.

Security Considerations

None that I can think of.

Scaling Considerations

None

Test Plan

Kept as is. The only thing that will be different is how the specific flow is being triggered.

Upgrade Considerations

This is primarily for upgrades so this is all upgrade.

[mhofman]

How do you suggest we handle custom logic or values for specific chains? In theory we could use core proposals in upgrade info, but that make it a lot more difficult to get the upgrade proposal correct.

[mujahidkay]

How do you suggest we handle custom logic or values for specific chains?

I did some digging into how other chains execute similar logic. Turns out there's a ChainID field in sdk context that can be used instead. This allows us to de-couple upgrade names from such logic.

For instance, if we take u18 as an example, we needed different upgrade names for different networks (agoric-upgrade-18-mainnet, agoric-upgrade-18-devnet, agoric-upgrade-18-emerynet etc) to map the different config values associated with each of them. Using ChainID as a mapping source (for config objects) instead of upgrade names, this could have been simplified to just using agoric-upgrade-18 (for the ideal case of no reapplies to testnets).

[mhofman]

Since this was confusing for validators too, I agree we should move away from upgrade plan names that do not match the git tag / release name. I'm curious to know how other chains handle multiple RCs on the same testnet (which I hope we can avoid too in the future with fork testing)

[mhofman]

Ugh I just realized that u19 still has some per network customization. Wondering if we could address this for this release.

[mujahidkay]

I'm curious to know how other chains handle multiple RCs on the same testnet

I will do some digging into this and provide an update here.