CGP [0013]: Celo Core Contracts Release 1

[nambrot]

• Date: 2020-10-16
• Author(s): @nambrot
• Status: DRAFT
• Governance Proposal ID #: [if submitted]
• Date Executed: [if executed]

Overview

In this governance proposal, we propose to complete the first Celo Core Contracts Upgrade. This release debuts a new release process that culminates in this proposal. The goal of this new release process is to enable more agile changes to the Celo Core Contracts while prioritizing realiability and security of the whole Celo platform. cLabs engineers have invested significant effort in verfication tooling in the past months to allow Celo stakeholders to assert the validity of the prposal itself. See more under Verification

Changes that are being proposed in this release are described in this Github release. OpenZeppelin audited all core Celo contracts and found no “critical” or “high” severity issues. The audit report can be found here.

Proposed Changes

This Celo Core Contracts Upgrade proposal is special since it operationalizes the new release process. As part of the new versioning schema, most Celo Core Contracts added a getVersionNumber function which changed the bytecode of all implementations. For that reason, this proposal contains transactions to update the implementation contract of these contracts' proxies.

1. AccountsProxy setImplementation
2. AttestationsProxy setImplementation
3. DoubleSigningSlasherProxy setImplementation
4. ElectionProxy setImplementation
5. EpochRewardsProxy setImplementation
6. EscrowProxy setImplementation
7. ExchangeProxy setImplementation
8. GasPriceMinimumProxy setImplementation
9. GoldTokenProxy setImplementation
10. GovernanceProxy setImplementation
11. LockedGoldProxy setImplementation
12. RandomProxy setImplementation
13. ReserveProxy setImplementation
14. SortedOraclesProxy setImplementation
15. StableTokenProxy setImplementation
16. UsingPrecompilesProxy setImplementation
17. ValidatorsProxy setImplementation

Additionally, to avoid future updated bytecode of Celo Core Contracts when underlying libraries are changed, some libraries are being proxied and linked via the proxy. That necessitates the following transactions:

1. Registry setAddressFor Signatures library
2. Registry setAddressFor AddressLinkedList library
3. Registry setAddressFor AddressSortedLinkedList library
4. Registry setAddressFor AddressSortedLinkedListWithMedian library
5. Registry setAddressFor Proposals library
6. Registry setAddressFor IntegerSortedLinkedList library

Regular features that were being added or bugs that were fixed are described in the Github release. Since the major version of these Celo Core Contracts changed due to the version change, no separate transactions will reflect the "regular" changes. One exception to that is the newly added DowntimeSlasher:

1. Registry setAddressFor DowntimeSlasher

Since this release is larger than usual and more opaque, it is crucial for Celo stakeholders to follow the verification steps below.

Verification

This section follows the process as prescribed in Smart Contract Release Process.

Any Celo stakeholder can fetch the proposal as a JSON file by running

celocli governance:show --proposalID <proposalId> --jsonTransactions "upgrade_proposal.json"

With that proposal, any Celo stakeholder can run the following script

RELEASE="celo-core-contracts-v${N}.rc${X}"
NETWORK=${"baklava"|"alfajores"|"mainnet"}
# A -f boolean flag can be provided to use a forno full node to connect to the provided network
yarn verify-release -p "upgrade_proposal.json" -b $RELEASE -n $NETWORK -f

With this script, any Celo stakeholder can verify that the proposal will result in Celo Core Contracts bytecode that matches the release tag (which stakeholders can verify that it matches the audited commit in the OpenZeppelin report)

Risks

This proposal is the first governance proposal on Celo mainnet to significantly changing Celo Core Contracts beyind simple parameter updates. Celo Core Contracts are critical for the functioning of the Celo Platform. This proposal touches all of the contracts which impact Celo's Proof-of-Stake and consensus, the stability and identity protocol and Governance itself. While cLabs have invested significant efforts to expand testing and verification tooling, errors in this proposal could lead to catastrophic situations that are only recoverable with a very difficult hard fork.

Useful Links

• Celo Core Contracts Release Process
• Github release
• OpenZeppelin Audit Report
• Forum post about the upgrade
• Github Ticket tracking progress of the release

[clrblmt]

Consider adding link to Core Contracts

[clrblmt]

"beyind" typo

[m-chrzan]

Add that this is in the protocol/ package of the monorepo? celocli is expected to be installed globally, but this needs to be run from the monorepo.

[m-chrzan]

Should this section also include instructions for verifying the current deployment as well as that versions have been correctly set between the current deployment and the proposed release?

[nambrot]

I had tried to keep it short as to not effectively copy everything from the docs. I'd also imagine that stakeholders will mostly care about verifying the proposal, than verifying the current deployment (as there is nothing this proposal could do about it)

[nambrot]

Though I guess the version check is maybe a good idea

[m-chrzan]

Maybe add a comment saying that you can omit -f if you have a local node exposing RPC at 8545?