Now that we have networks that shouldn't be restarted, we want to avoid changing the genesis block at all costs. We will have to update some or all of the core contracts over time, and although there is a route to doing that (truffle migrate), it's not well defined or documented.
The process
I imagine (and this might be inagineering as oppose to reality) that the update process is, or could be, as follows:
The solidity code is updated.
Someone (or possibly the CI) runs a truffle migration, which creates one or more transactions that represent the update (essentially changes to the proxied contracts).
The transactions are entered into each network, either manually or via truffle and definitely by a governance account holder, as multsig contract submissions. This is probably via the console, a bit like the token minting (see #700).
Each proposed transaction includes a bit of meta data: the release number, perhaps a github diff link, that sort of thing. If this can't be stored in the chain, then it needs to be easily findable in version control.
Other governance account holders (we currently need 2/3 total) review the contract update transactions and approve them if they think they're sound.
The multisig then sends the final transactions to wherever they need to go (presumably the proxy wrappers) and the contracts are updates.
Implementation
In order for this, or anything like it, to work, we need to be able to create truffle migrations easily. If the steps above are realistic, then we'll need to be able to generate some transactions on the network and sign them with a governance key. And the process needs to be well documented, otherwise we'll get it wrong.
Ideally some of this would happen in the CI, but because of the need to sign the transactions with a governance key, it might not be possible on the main net.
We don't want to generate transactions unless they're necessary, so no transactions should be generated or propagated if the contracts haven't changed. Presumably truffle takes care of this, but we need to be sure.
Things we need to produce
[ ] Documentation for the process
[ ] Any console-level tooling required (probably something like #700)
[ ] A way of reconciling contract updates with meta data (could just be a text file in git)
[ ] And end-to-end test, in which a contract is provably updated on a running network
Now that we have networks that shouldn't be restarted, we want to avoid changing the genesis block at all costs. We will have to update some or all of the core contracts over time, and although there is a route to doing that (
truffle migrate), it's not well defined or documented.The process
I imagine (and this might be inagineering as oppose to reality) that the update process is, or could be, as follows:
Implementation
In order for this, or anything like it, to work, we need to be able to create truffle migrations easily. If the steps above are realistic, then we'll need to be able to generate some transactions on the network and sign them with a governance key. And the process needs to be well documented, otherwise we'll get it wrong.
Ideally some of this would happen in the CI, but because of the need to sign the transactions with a governance key, it might not be possible on the main net.
We don't want to generate transactions unless they're necessary, so no transactions should be generated or propagated if the contracts haven't changed. Presumably truffle takes care of this, but we need to be sure.
Things we need to produce