-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conduct contract release 1 #4812
Comments
Meaningful PRs that went in this release:
|
The commit that was submitted to OpenZeppelin was https://github.com/celo-org/celo-monorepo/tree/b2f0a58fcc7667d41585123aae5b24c47aa894f6 and the release branch is oz-prerelease |
Release Notes draft in progress here https://docs.google.com/document/d/1vmZCKJRM9WO4VYinKEb5q4QetXjNzYFxq0AvPy_t8pA/edit Please add any improvements! |
@pranaymohan confirmed that increasing the block gas limit to 13M is safe to do with the current blockchain version on Mainnet. Thanks @jcortejoso @kevjue @vslavich @mcortesi! |
CGP for the block gas limit increase proposal celo-org/celo-proposals#46 |
Created the branch |
Baklava Gas Limit Increase has been proposed as It will enter into approval stage tomorrow ~10:40AM PDT. Baklava just needs 1 approver. It will then enter the voting stage Thursday. |
Block Gas Limit Increase Proposal on Baklava is approved
|
Baklava GasLimit Proposal is executed, blocks are stable!
|
The Block Gas Limit update has been proposed on Alfajores with proposalID 1
|
The blockGasLimit proposal has been executed on alfajores |
The release process documentation is up to date with the internal and community tooling. |
The cLabs team asked OpenZeppelin to review and audit the recent changes in the smart contracts from their protocol. We examined the code, and here we publish our findings in Phase 3. 👇 |
Block GasLimit increase proposal is live on Mainnet, thanks @aslawson https://celo.stake.id/#/proposal/11 |
Thanks @zviadm for noticing that our block gasLimit proposals had specified the wrong number for the increase (130M instead of 13M). This post will track the work needed to rectify that mistake:
|
Baklava Proposal to set the gasLimit to 13M has been proposed
|
Alfajores Proposal to set the gasLimit to 13M has been proposed
|
Alfajores Proposal to set the gasLimit to 13M has been executed |
Baklalva Proposal to set the gasLimit to 13M has been executed |
### Description Previously the script would just exit with code 0 and no stdout output about success. Added logs reporting which contracts have been checked and at which address on the network. Added a `--quiet` flag to optionally suppress this new output (`-q` in the bash wrapper). ### Other changes `getImplementationAddress` was previously returning pre-release 1 library addresses without a "0x" prefix, fixed this for consistency in logs. Improved the documentation comment in `verify-bytecodes.ts`. ### Tested `yarn verify-bytecodes -b rc1 -n rc1 -r -f` succeeds outputs the new logs. Adding `-q` still succeeds and suppresses output. ### Related issues - Part of #4812 ### Backwards compatibility Only cosmetic script change.
### Description Some regressions sneaked their way into the make-release script. * missing `;;` in `case` statement * wrong artifacts directory passed (extra `/contracts` appended) * the "all libraries have been relinked" check could fail on ignored contracts This PR also makes it such that when running `make-release.sh`, it will return to the current branch to run `make-release.js`. Similar steps should be taken with `check-versions` (and potentially other scripts in the backwards compatibility suite?). ### Other changes There is a temporary hack to increase the gas limit when making the release. This should ideally be captured in a more global config? ### Tested `yarn make-release -b celo-core-contracts-v1.rc1 -n development -p proposal.json -i example-initialize-data.json -r report.json` against a previously generated devchain with rc1 contracts, and a correctly generated `report.json` . ### Related issues - Part of #4812 ### Backwards compatibility Should be good.
) ### Description Makes it such that when running check-versions.sh, it will return to the current branch to run make-release.js. ### Tested `yarn check-versions -a rc1 -b celo-core-contracts-v1.rc1 -r report.json`. I made a temporary commit that added logging to check-backwards.ts, and verified that you could see the new log with this PR's change. ### Related issues - Part of #4812 ### Backwards compatibility All good.
The block gas limit increase has been proposed on Mainnet
|
Baklava Contract Upgrade has been proposed Proposal was not executed since it contained a bug |
Baklava contract upgrade has been proposed
|
Alfajores has been upgraded 🎉 |
Mainnet has been executed! celo-org/celo-proposals#85 |
This issue is tracking Celo's first smart contract upgrade release. While executing upon this release according to the process laid out in https://docs.celo.org/community/release-process/smart-contracts, we are simultaneously going to improve it as we go and reference those changes here as well
Process Checklist:
Blockers:
To-Dos:
--dryrun
to make-release script and reconcile build args @nambrot easySlasherUtil
/UsingPrecompiles
hack since it addedgetVersionNumber
@yorhodesgetVersionNumber
only on proxied contractsgetVersionNumber
make-release
only releases contracts with proxiesMetaTransactionWallet
from check version @yorhodesgetVersionNumber
from wrong files @nambrotContract
instead ofContractProxy
when decoding a contract upgrade governance proposal, which breaksverify-release
)--jsonProposals
option togovernance:show
verify-release
should check Proxy bytecodes and ownersmake-release
, check that new Proxies have empty bytecode inverify-release
make-release
The text was updated successfully, but these errors were encountered: