diff --git a/contribute-to-celo/release-process/smart-contracts.mdx b/contribute-to-celo/release-process/smart-contracts.mdx index 3171aa4ca..15b5e69b4 100644 --- a/contribute-to-celo/release-process/smart-contracts.mdx +++ b/contribute-to-celo/release-process/smart-contracts.mdx @@ -4,8 +4,6 @@ sidebarTitle: "Smart Contracts" og:description: Details of the release process for updating smart contracts on the Celo platform. --- -export const N = "N"; - Details of the release process for updating smart contracts on the Celo platform. @@ -44,7 +42,7 @@ Mixin contracts and libraries are considered part of the contracts that consume ### Initialize Data -Whenever Celo Core Contracts need to be re-initialized, their initialization arguments should be checked into version control under `packages/what-is-celo/about-celo-l1/protocol/releaseData/initializationData/release${N}.json`. +Whenever Celo Core Contracts need to be re-initialized, their initialization arguments should be checked into version control under `packages/protocol/releaseData/initializationData/release${N}.json`. ### Release management in Git/Github @@ -55,13 +53,13 @@ Github branches/tags and Github releases are used to coordinate past and ongoing 1. A new release branch is created `release/core-contracts/${N}` with the contracts to be audited. 2. The latest commit on the release branch is tagged with `core-contracts.v${N}.pre-audit`. 3. On Github, a pre-release Github release should be created pointing at the latest tag on the release branch. -4. On master branch, `.circleci/config.yml` should be edited so that the variable `RELEASE_TAG` points to the tag `celo-core-contracts-v${N}.pre-audit` so that all future changes to master are versioned against the new release. +4. On master branch, `.github/workflows/celo-monorepo.yml` should be edited so that the variable `RELEASE_TAG` points to the tag `celo-core-contracts-v${N}.pre-audit` so that all future changes to master are versioned against the new release. 5. Ongoing audit responses/fixes should continue to go into `release/celo-core-contracts/${N}`. #### After a completed release process: 1. The release branch should be merged into `master` with a merge commit (instead of the usual squash merge strategy). -2. On master branch, `.circleci/config.yml` should be edited so that the variable `RELEASE_TAG` points to the tag `core-contracts.v${N}` +2. On master branch, `.github/workflows/celo-monorepo.yml` should be edited so that the variable `RELEASE_TAG` points to the tag `core-contracts.v${N}` ## Release Process @@ -90,13 +88,14 @@ yarn tags:view ```bash # Run from `packages/protocol` in the celo-monorepo -PREVIOUS_RELEASE="core-contracts.v${N-1}" -NETWORK=${"baklava"|"alfajores"|"mainnet"} +N=15 # release number +PREVIOUS_RELEASE="core-contracts.v$((N-1))" +NETWORK= # "mainnet" or "celo-sepolia" # A -f boolean flag can be provided to use a forno full node to connect to the provided network yarn release:verify-deployed -n $NETWORK -b $PREVIOUS_RELEASE -f ``` -A `libraries.json` file is written to disk only necessary for `release:make` that describes linked library addresses. +A `$NETWORK-$PREVIOUS_RELEASE-libraries.json` file is written to disk that describes linked library addresses. This file is required by `release:make`. ### Check Backward Compatibility @@ -124,11 +123,12 @@ check for it. The script generates a detailed report on version changes in JSON format. ```bash -PREVIOUS_RELEASE="core-contracts.v${N-1}" RELEASE_CANDIDATE="core-contracts.v${N}" -yarn release:check-versions -a $PREVIOUS_RELEASE -b $RELEASE_CANDIDATE -r "report.json" +yarn release:check-versions -a $PREVIOUS_RELEASE -b $RELEASE_CANDIDATE ``` +The report is written to `report-$PREVIOUS_RELEASE-$RELEASE_CANDIDATE.json`. + This should be used in tandem with `release:verify-deployed -b $PREVIOUS_RELEASE -n $NETWORK` to ensure the compatibility checks compare the release candidate to what is actually active on the network. ### Deploy the release candidate @@ -137,11 +137,13 @@ Use the following script to build and deploy a candidate release. This takes as STORAGE updates are adopted by deploying a new proxy/implementation pair. This script outputs a JSON contract upgrade governance proposal. ```bash -NETWORK=${"baklava"|"alfajores"|"mainnet"} +NETWORK= # "mainnet" or "celo-sepolia" RELEASE_CANDIDATE="core-contracts.v${N}" -yarn release:make -b $RELEASE_CANDIDATE -n $NETWORK -r "report.json" -i "releaseData/initializationData/release${N}.json" -p "proposal.json" -l "libraries.json" +yarn release:make -b $RELEASE_CANDIDATE -n $NETWORK -r "report-$PREVIOUS_RELEASE-$RELEASE_CANDIDATE.json" -i "releaseData/initializationData/release${N}.json" -l "$NETWORK-$PREVIOUS_RELEASE-libraries.json" -k $PRIVATE_KEY ``` +The proposal is written to `proposal-$NETWORK-$RELEASE_CANDIDATE.json`. + The proposal encodes STORAGE updates by repointing the Registry to the new proxy. Storage compatible upgrades are encoded by repointing the existing proxy's implementation. ### Submit Upgrade Proposal @@ -150,7 +152,7 @@ Submit the autogenerated upgrade proposal to the Governance contract for review ```bash # resultant proposal ID should be communicated publicly -celocli governance:propose --deposit 100e18 --from $YOUR_ADDRESS --jsonTransactions "proposal.json" --descriptionURL https://github.com/celo-org/governance/blob/main/CGPs/cgp-0055.md +celocli governance:propose --deposit 100e18 --from $YOUR_ADDRESS --jsonTransactions "proposal-$NETWORK-$RELEASE_CANDIDATE.json" --descriptionURL https://github.com/celo-org/governance/blob/main/CGPs/cgp-0055.md ``` ### Fetch Upgrade Proposal @@ -171,7 +173,7 @@ Additionally, include `initialization_data.json` from the CGP if any of the cont ```bash RELEASE_CANDIDATE="core-contracts.v${N}" -NETWORK=${"baklava"|"alfajores"|"mainnet"} +NETWORK= # "mainnet" or "celo-sepolia" # A -f boolean flag can be provided to use a forno full node to connect to the provided network yarn release:verify-release -p "upgrade_proposal.json" -b $RELEASE_CANDIDATE -n $NETWORK -f -i initialization_data.json ``` @@ -182,7 +184,7 @@ After a release executes via Governance, you can use `release:verify-deployed` a ```bash RELEASE="core-contracts.v${N}" -NETWORK=${"baklava"|"alfajores"|"mainnet"} +NETWORK= # "mainnet" or "celo-sepolia" yarn release:verify-deployed -n $NETWORK -b $RELEASE -f ``` @@ -218,7 +220,7 @@ After a successful release execution on a testnet, the resulting network state s ``` - Complete a round of attestation - Redeem from Escrow -- Register a Vaildator +- Register a Validator ```bash celocli validator:register --blsKey --blsSignature --ecdsaKey --from ``` @@ -227,7 +229,7 @@ After a successful release execution on a testnet, the resulting network state s ```bash celocli election:run ``` -- Get a valildator slashed for downtime and ejected from the validator set +- Get a validator slashed for downtime and ejected from the validator set - Propose a governance proposal and get it executed ```bash celocli governance:propose --jsonTransactions --deposit --from --descriptionURL https://gist.github.com/yorhodes/46430eacb8ed2f73f7bf79bef9d58a33 @@ -345,14 +347,14 @@ Deploying a new contract release should occur with the following process. On-cha
  • On Tuesday: Run the{" "} smart contract release script{" "} - in order to to deploy the contracts to Baklava as well as submit a + in order to to deploy the contracts to Celo Sepolia as well as submit a governance proposal.
    • - Transition proposal through Baklava governance process. + Transition proposal through Celo Sepolia governance process.
    • - Update your forum post with the Baklava PROPOSAL_ID, + Update your forum post with the Celo Sepolia PROPOSAL_ID, updated timings (if any changes), and notify the community in the Discord #governance channel.
      • @@ -365,17 +367,17 @@ Deploying a new contract release should occur with the following process. On-cha T+3w
        -
      1. Confirm all contracts working as intended on Baklava.
        2. +
      2. Confirm all contracts working as intended on Celo Sepolia.
      3. Run the{" "} smart contract release script {" "} - in order to to deploy the contracts to Alfajores as well as submit a + in order to to deploy the contracts to Celo Sepolia as well as submit a governance proposal.
      4. - Update your forum post with the Alfajores PROPOSAL_ID, + Update your forum post with the Celo Sepolia PROPOSAL_ID, updated timings (if any changes), and notify the community in the Discord #governance channel.
        5. @@ -386,7 +388,7 @@ Deploying a new contract release should occur with the following process. On-cha T+4w
          -
        1. Confirm all contracts working as intended on Alfajores.
          2. +
        2. Confirm all contracts working as intended on Celo Sepolia.
        3. Confirm audit is complete and make the release notes and forum post contain a link to it. @@ -446,7 +448,7 @@ Deploying a new contract release should occur with the following process. On-cha Passed or Rejected) and notify the community in the Discord #governance channel.
          4. -
        4. Change corresponding CGP status to EXCECUTED.
          5. +
        5. Change corresponding CGP status to EXECUTED.
        6. Merge the release branch into master with a merge commit @@ -476,9 +478,9 @@ Each smart contract release governance proposal should be accompanied by a [Gove - Background information. - Link to the release on Github. - Link to the audit report(s). -- Anticipated timings for the Baklava and Alfajores testnets and Mainnet. +- Anticipated timings for the Celo Sepolia testnet and Mainnet. -It's recommended to post as early as possible and at minimum one week before the anticipated Baklava testnet governance proposal date. +It's recommended to post as early as possible and at minimum one week before the anticipated Celo Sepolia testnet governance proposal date. Make sure to keep the post up to date. All updates (excluding fixing typos) should be communicated to the community in the [Discord](http://chat.celo.org/) `#governance` channel.