This article was written in collaboration with Maurelian.
With the recent successful migration of the Optimism Goerli Testnet to Bedrock, we are approaching a crucial phase of the Bedrock release: the Optimism Mainnet upgrade.
The size and complexity of Bedrock means that ensuring the security and stability of the system was just as ambitious a task as building it. We learned a lot and are excited to share what we learned with you.
In this article we go over some security highlights and introduce an opportunity for intrepid protocol and smart contract experts to find bugs in exchange for prizes 👀
Ensuring the Security of the Bedrock Release
Bedrock is a radical reimagining of both the OP Stack and how Optimism works. To meet our objectives for this release, much of the system was redesigned from scratch to be as elegant, simple, and future-proof as possible.
We used this process as an opportunity to integrate trusted third-party security reviews and audits into our learning and growth process as developers and as a team that always aims to improve upon the security of our code.
This holistic approach resulted in our most secure, stable codebase yet, and led to some novel solutions to common security issues that arise for L2 ecosystems.
Code Reviews & Audits
Too often third-party audits are viewed as merely a box to tick before shipping. We engaged the best software assurance partners in the game very early on in the Bedrock development process.
Receiving ongoing feedback from security reviews enabled us to identify gaps in our process and incorporate recommendations, which ultimately improved our capacity to write secure software.
Here’s a summary of the reviews we commissioned throughout development to help secure this release:
- In April of 2022, we worked with OpenZeppelin on a review of an early version of the Bedrock contracts.
- In the same month, Trail of Bits performed a review of our Rollup Node and Optimistic Geth.
- In early July, Sigma Prime conducted a review of Bedrock’s critical Golang components (the Rollup Node and Optimistic Geth).
- In mid-July (with the Sigma Prime audit ongoing) OpenZeppelin took another look at the contracts. They focused on our Bridge, including the new ERC721 Bridge.
- In September we asked our partners at Trail of Bits to identify and test the invariants of our system. Not only did this report give us a useful artifact listing those invariants, but we also received numerous fuzz tests for both our Golang and Solidity code.
- By November, our Bedrock codebase had matured, and engineering work was focused primarily on clean up, testing, planning the upgrade. At this time, we asked Trail of Bits to take one last look at Bedrock.
If nothing else, 2022 was the year the crypto community learned that cross chain bridge security is hard. Many vulnerabilities were reported (or exploited) throughout the industry, including some which took advantage of faulty proof implementations.
In order to increase the safety of the assets in our bridge contracts, we’ve implemented a two-step withdrawal process for funds being moved from Optimism to Ethereum Mainnet.
Here’s what we changed:
- Currently, when a user makes a withdrawal from the Optimism Network to Ethereum Mainnet, they initiate the withdrawal on Optimism and then finalize the withdrawal 7 days later on Ethereum Mainnet.
- With two-step withdrawals, users make a withdrawal from the Optimism Network, prove the validity of that withdrawal on Ethereum Mainnet about an hour later, and then they wait the standard 7 days to finalize the withdrawal on Ethereum Mainnet.
Two-step withdrawals allow us to verify early in the withdrawal process that the withdrawal is not a duplicate; that it matches a withdrawal on Optimism Mainnet. It ensures that every withdrawal from the bridge on Ethereum Mainnet has a corresponding withdrawal on Optimism, making it much more difficult to exploit a potential flaw in our bridge mechanism.
A critical component of securing Bedrock was going through a rigorous process of defining the invariants in our code. We then verified these invariants using Echidna for fuzzing and Foundry for fuzzing and invariant tests.
We found that clearly defining our invariants was an effective way to ensure a common understanding of the intended behaviour of our system, across the engineering team.
Formal Verification of our Deposit Path
Bedrock’s deposit path introduces a variable pricing mechanism (similar to that of EIP1559), which charges based on the demand for L2 gas from deposits.
We recently completed an engagement with Runtime Verification to formally verify that deposits will always succeed when users make a deposit to Optimism. We will share the report for this engagement when it is available.
Putting Bedrock’s Security to the Test: Join our Audit Contest!
We’ve gone to great lengths to ensure the Bedrock release of the OP Stack is stable and secure, but there’s one more step we can take to confirm we didn’t overlook anything.
With the help of Sherlock, we will be hosting an audit contest to put Bedrock’s security to the test.
The Bedrock release is substantial. It presented us with an opportunity to host an unconventional and innovative audit contest that includes client software (i.e. Geth and Golang) and involves looking at a live system on a testnet instead of just source code in Github.
This is a fun and novel opportunity for bounty hunters with diverse skillsets to flex their expertise!
This means that rather than looking for bugs in the contract’s source code, participants will be able to interact with a live system, complete with block explorers and other infrastructure.
For full contest details, including some pointers for how to get started with your analysis, check out our competition page on Sherlock.
How to Participate
- Read the competition details (including all available prizes!) on Sherlock’s website.
- Sign up to participate through Sherlock.
- Read our code, look for bugs, and win bounties!
The competition will run from Jan. 23 to Feb. 6. Thank you for helping us ensure the security of Optimism!