Mainnet Soft Launch!
By: Ethereum Optimism
Tags: Optimism, Ethereum, Cryptocurrency

Ethereum is at an unprecedented moment in its history — there has never been more usage, more excitement, or more value created. Last year, cumulative transaction fees surpassed Bitcoin, and today, Ethereum remains the top dawg in terms of daily transaction fee revenue. Usage of decentralized apps like Uniswap has eclipsed their centralized counterparts despite these soaring fees.

The demand for Ethereum has been undeniably insane, and the adoption is so exciting to see, but it drives home the importance of scalability in making Ethereum usable by the masses. For the last year, we have been building relentlessly to satiate the demand for an easy-to-integrate scaling solution with lightning fast transactions. Today, it is finally time to take our first material steps towards alleviating the gas crisis by deploying to mainnet.

Crypto Utopia is right on the horizon

Not Your Average Mainnet Launch

We rolled our testnet out in phases in order to test each set of features in a controlled environment before shipping the next set. Similarly, we’re calling this a “soft launch” because it’s not your typical mainnet launch. Just as we did with our testnet, we are taking an iterative approach by launching first with training wheels (outlined in the next section) and removing them as we gain confidence in the production system.

Why the incremental approach? WE WANT COMPLETE OPTIMISM NOW, you say. We hear you!! We want the same thing. But more importantly we want to be sure our features are right and our system is rock solid, which can only be confirmed in the harsh and unforgiving environment of mainnet. By developing incrementally, we can:

Launch sooner in order to start alleviating congestion ASAP

Validate that our features are all things that users actually want & work the way they want them to!

Keep the new surface area much smaller, allowing us to stabilize before exposing more new code to mainnet.

The fastest route to an open, fully decentralized & secure optimistic future is to relentlessly iterate. It’s incredibly satisfying to reach this milestone after a long year of hard work, but our journey is far from over, as we expect the toughest lessons will be on mainnet. We’ll learn to ship new features with minimal disruption, how to handle bugs in production, and much much more.

Defense in Depth

One challenge of an iterative deployment strategy is the increased difficulty of “purchasing security” through third-party audits, because subsequent changes may quickly deprecate earlier findings. The most effective security approach for our current needs starts with a layered defense in depth strategy, combined with audits when it makes sense. These layers of defense are centralized, and as we gain confidence in the system they will be removed. Until then, please do not consider this the full and final protocol.

Our core objective is to employ defenses that are:

Transparent , meaning that it should be obvious when a defense is used, and

, meaning that it should be obvious when a defense is used, and Additive, meaning that the failure of one layer can still be recovered by successful use of the next.

Of course, the entire point of the OΞ protocol is to defend users’ funds in a scalable manner — this is the core purpose of our fraud proofs, adjudication contracts, and so on. While we have dealt with all of the major security issues surfaced through multiple internal reviews of the contracts, as well as consultations with external auditors, we are launching with several additional safeguards.

Defense Layer #1: Permissioned contract deployment

The most probable way to bypass the core security is through deploying a malicious contract that breaks the OVM’s L2 sandbox. To minimize this risk, we are temporarily maintaining a whitelist of deployers until a later release.

The most probable way to bypass the core security is through deploying a malicious contract that breaks the OVM’s L2 sandbox. To minimize this risk, we are temporarily maintaining a whitelist of deployers until a later release. Defense Layer #2: Authenticated withdrawals

If the first line of defense is breached, then the next risk is invalid withdrawals. To prevent this, we have added a check that allows us to investigate pending withdrawals and stop misbehavior before it hits L1.

If the first line of defense is breached, then the next risk is invalid withdrawals. To prevent this, we have added a check that allows us to investigate pending withdrawals and stop misbehavior before it hits L1. Defense Layer #3: Upgrade keys

The final layer of defense relies on admin keys which can be used to upgrade the contracts in emergencies. We also plan to use these keys on a bi-monthly basis to ship scheduled improvements and new features.

Go give it a whirl!!!!

Join our discord! Report bugs in #bug-reports!

Sneak Peek: The Next 2 Milestones

Just a peek for now. The full flash coming soon!

Public Testnet — Late February/Early March

A public testnet that anyone can deploy to and interact with. What’s left to get there:

Polishing a handful of features

Bug bounty program launch

Incorporating user feedback from the initial mainnet launch

Public Mainnet — As soon as humanly possible.

A public mainnet that anyone can deploy to and interact with. What’s left to get there:

Implement fixes from public testnet.

Code freeze!

Audits!

Acknowledgements