Add upgrade mechanism

[cmwaters]

There needs to be a mechanism in place to:

• Change the verifier keys (for the STF)
• Accommodate to changes to possibly the verifier keys or to tree algorithms that the rollup uses (i.e. membership)
• To any of the zk circuit hyper-parameters:
  • ZK circuit algorithm: groth16, plonky or something in the future
  • The curve used i.e. BN254
  • Some breaking change that would not allow a current verifier key to determine the next correct app hash (this might be some simple versioning system)
• Change in the supplied public inputs (may be represented by a general ZK IBC Client version number)

There have been proposed various mechanisms which can be employed to support such changes:

1. Rollup commits to future changes in it's own state
   The rollup then provides a path in the state tree for where to look up future modifications. There is then a mapping to the height and when these changes should be made. The relayer submits a message to Celestia with a proof of inclusion of an item in the map to the state root. Past that height, the IBC Client will now use the new parameters i.e. verifier key.

2. Changes can optionally be added to the public inputs
   For example, if changing the verifier key, the new verifier key and the height of the change is added in the update client message and is provided as a public input. The current zk circuit should be able to correctly validate the valid proof with these updates as part of the public inputs.

3. A separate ZK circuit for tracking updates
   Similar to option 2 but now the changes are separated into their own ZK circuit

4. Celestia Chain Governance
   While this adds security dependence on the TIA holders, this may be a useful safeguard early on in the event that an IBC client gets bricked. IBC already relies on governance to unfreeze IBC connections. This could be applied to allow for modifications to the IBC Client by it being proposed and passing on-chain governance. As an additional security mechanism, the IBC client could be initialised with a period of time/height in which no updates can have occurred before accepting a governance proposal to change (similar as to with freezing). This can be an additional optional mechanism

[nashqueue]

Some comments:

• To minimize on-chain governance participation, I would not allow using TIA token voting as governance natively. This could lead to devs being lazy and opting for this as the default opinion. If we expect many ZK accounts to be deployed, the sheer number of votes you would have to cast would be unsustainable.

• I am also against using option 1 as the default option. Some governance will be outside of the Rollups STF, which limits the design space. Another consideration is that there might be a non-determinism bug, a bug in the circuit, or a bug in the ZKVM. All of these bugs would prevent the governance from actually changing anything because a valid zk proof of a valid state transition function cannot be created anymore.

• I propose that the ZK account can specify an account that can upgrade the account. That could be a single private key, but it could also be another ZK account. That means you can now build a separate circuit for your governance, which can be creative and customized for your application. In addition, that could enable a new field of open-source development to create more creative ways of doing governance. A developer can also choose from some default examples that we and the community provide, which will be independent from any VM or structure and reused and refined among all rollups.

• This does not mean that option 1 will not work anymore. If you specify the same zk account as the zk account that upgrades it, then you basically replicate option 1. The only difference is that you now have many other options for doing it, and don't couple it to some predefined structure in the state machine.