ICYMI the release process for the core smart contracts is published here.
The proposal is to always release all smart contract changes atomically. This will make keeping track of what contracts are deployed on a given network much simpler, as we can always ensure that the deployed contracts correspond to a specific commit hash. This also ensure that the contracts remain interoperable, as we don’t need to worry about keeping contracts interoperable with each other across different commits.
The implication here is that governance proposals to upgrade core smart contracts will be “all or nothing”, in the sense that each time there will be a single proposal to upgrade the smart contracts from commit hash X to commit hash Y, which will contain updates to all smart contracts that had code changes between X and Y. This means that if there are controversial changes, it will be easiest (though not strictly necessary) to commit to or reject those changes before they make it into master, rather than by voting down the governance proposal. Certainly rejecting those changes is still possible by rejecting the proposal, but it will mean those specific changes that were rejected would need to then be reverted on master, and a new governance proposal be made.
Some of us at cLabs are currently working on smart contract upgradability tooling in order to make sure deploying upgrades is safe and easy, so that Celo can maintain the development velocity needed in order to respond to user feedback and needs. We’re hoping to have this ready such that we can begin executing the first upgrade process within the next few weeks.
Some changes that are in master already that would be batched into the first upgrade include:
- Election.sol: A minor bug fix in which a value guaranteed to be zero was being subtracted unnecessarily
- Governance.sol: Return
3: LockedGold.sol: Add additional
requirestatements to confirm consistency of balances
- Exchange.sol: Short circuit to return zero when buy/sell amount is zero
- DowntimeSlasher.sol: Totally reimplemented, to allow downtime to be computed in pieces so as not to exceed the block gas limit.
I’d love to get more feedback on all of this, so that by the time the tooling is ready, we’re all on the same page with respect to how core contract upgrades should be done.