Introduction
Hello! When you’re done reading this page, you should have a basic grasp of how Optimism scales Ethereum and Ethereum’s values, how Optimism makes Ethereum transactions cheaper and faster, and why Optimism is the perfect place to create your next Ethereum-native project.
This tutorial is intended to be as thorough as possible while yet being understandable to the majority of readers. While some of the information on this page is intended for readers with technical backgrounds, it should still be understandable to people with a fundamental knowledge of how blockchains operate. In general, we err on the side of clarity and approachability. Readers interested in a detailed examination of Optimism’s workings might consult the Protocol section.
Design philosophy
The design philosophy behind optimism is based on four fundamental principles: simplicity, pragmatism, sustainability, and, of course, optimism. Understanding these pillars is crucial since they have a significant impact on how optimism as a whole is designed.
Simplicity
For the features it offers, optimism is intended to be as basic as possible. For Optimism to be a secure, scalable, and adaptable L2 system, it should contain the fewest possible moving parts. The design of Optimism has a number of important advantages over other, more sophisticated L2 designs because of its simplicity.
We can spend more time working on new features rather than reinventing old ones since simplicity lowers engineering overhead. Whenever possible, Optimism prefers to employ Ethereum’s battle-tested technology and infrastructure. The decision to use Geth as Optimism’s client software is the clearest illustration of this tenet in action.
Simplicity is security when working with essential infrastructure. Every line of code we create presents the possibility of unintentionally adding bugs. A straightforward protocol implies less code needs to be written, which reduces the opportunity for error. Additionally, external contributors and auditors have easier access to a codebase that is clear and uncluttered. All of these works to increase the Optimism protocol’s security and correctness.
The long-term goals of optimism depend on simplicity. We are able to spend the majority of our time directly working with existing codebases by reducing the amount of code that we create on top of Ethereum technology. Ethereum can immediately benefit from the engineering work put into Optimism, and vice versa. This situation will only worsen.
Pragmatism
Despite its idealistic nature, Optimism’s design is ultimately motivated by pragmatism. Real-world needs and limits are faced by the core Optimism team, the projects that are built upon it, and the users who interact with it. The design ethos of optimism puts user and developer needs ahead of theoretical perfection. Sometimes the best answer isn’t the most attractive.
With the knowledge that any core team will have restricted areas of expertise, optimism is also fostered. Iterative development is used to create optimism, which aims to continually solicit customer feedback. This iterative method of protocol development is the only one that makes it possible for many of the key Optimism features that are present today, such as EVM Equivalence (opens new window).
Sustainability
The outlook is for the long haul. Application developers need to have confidence that the platform they’re using will be both functional and competitive for a very long time. The idea of long-term sustainability and avoiding taking short cuts to scalability is essential to optimism’s design methodology. A scalable system is ultimately useless without the ecosystem that supports it.
Optimism’s protocol design is deliberately influenced by sustainability in ways that support our commitment to simplicity. It becomes increasingly challenging for those outside of the core development team to actively contribute to codebases that are more complex. We are able to grow a larger community of contributors that can help maintain the protocol over time by keeping our codebase basic.
Optimism
Of all, without a positive outlook, none of this would be possible. This project is progressing because of our confidence in the Ethereum concept. We have high hopes for Ethereum’s future, one in which we can reshape our interactions with the organisations that manage our lives.
Despite having the appearance of an own blockchain, Optimism is actually intended to be an addition to Ethereum. When developing new features or attempting to make old ones simpler, we keep this in mind. Because optimism exists in order for Ethereum to flourish, it is as similar to Ethereum as is humanly possible. We hope that when you examine the design of Optimism, you can understand how this philosophy has influenced it.
Rollup Protocol
The majority of the “why” of optimism has been discussed. It is now time to discuss the central concept that underlies optimism: the Optimistic Rollup. We’ll go over a quick explanation of optimistic rollups’ high-level operation. Then, we’ll discuss why we think Optimism is the greatest option for a system that fully realises all of our design objectives and why it is constructed as an Optimistic Rollup.
Optimistic Rollups TL;DR
An “optimistic rollup,” which is merely a fancy way of saying a blockchain that benefits from another “parent” blockchain’s security, is optimism. Specifically, Optimistic Rollups use their parent chain’s consensus process (such as PoW or PoS) rather than supplying their own. This parent blockchain in the instance of Optimism is Ethereum.
Block storage
The CanonicalTransactionChain (opens new window), a unique smart contract on Ethereum, houses all Optimism blocks (or CTC for short). In the CTC, optimism blocks are kept in an append-only list (we’ll go into more detail about how blocks are added to this list in the following section). The Optimism blockchain is made up of this append-only list.
Code in the CanonicalTransactionChain ensures that new Ethereum transactions cannot change the list of current blocks. However, if the Ethereum blockchain is rearranged and the chronological order of earlier Ethereum transactions is altered, this guarantee could be compromised. The mainnet of Optimism is set designed to be resistant to block reorganisations involving up to 50 Ethereum blocks. Optimism will reorganise if Ethereum undergoes a reorg that is more significant than this.
Of course, Ethereum’s primary security objective is to avoid these kinds of major block reorganisations. Therefore, optimism is resistant to significant block reorganisations so long as the Ethereum consensus mechanism is as well. This connection is how Optimism gets its security features from Ethereum, at least in part.
Block production
The “sequencer,” who controls the majority of optimism block manufacturing, benefits the network by offering the following services:
Instant transaction confirmations and state updates are provided.
building and running L2 blocks.
User transactions submitted to L1.
Transactions are immediately accepted or refused in the order they were received since the sequencer lacks a mempool. A transaction is applied to the sequencer’s local state as a pending block after the sequencer receives it from the user and verifies that it is valid (i.e., that the user has paid the required charge). Large batches of these pending blocks are frequently sent to Ethereum for completion. By distributing fixed costs across all of the transactions in a given batch, this batching procedure drastically lowers overall transaction fees.
The sequencer can give a solid assurance that the state will be finished as soon as it decides on a new pending block because it is granted priority write access to the L2 chain. In other words, the precise effects of the transaction are known. As a result, the L2 state may be changed very fast and reliably. This offers advantages such a quick, immediate user experience and nearly real-time Uniswap pricing updates.
Users can also submit their transactions directly to the CanonicalTransactionChain via an Ethereum transaction instead of using the sequencer at all. This is often more expensive because the user is responsible for covering the total fixed cost of submitting this transaction; it is not spread out over numerous transactions. The advantage of this alternative submission technique is that it is unaffected by sequencer censoring. The user can always send transactions on Optimism even if the sequencer is actively censoring them.
OP Labs PBC (opens new window) now controls the lone block producer on the Optimism network. For further details on how we intend to decentralise the Sequencer role in the future, see the Protocol specifications section.
NOTE
A rollup must enable participants to trustlessly post transaction results to Ethereum in order for consumers to be able to carry out withdrawals in a way that is resistant to censorship. While we aim to decentralise the “result proposal” role, OP Labs PBC (opens new window) is the only entity that is currently able to publish transaction outcomes. Although these security features are not particular to Optimism, it is nonetheless important to be aware of them when using the system. The production release of our Cannon (opens new window)fault proving system should be accompanied by the introduction of permissionless result publication.
Block execution
Blocks are downloaded by Ethereum nodes from the peer-to-peer network. In contrast, optimism nodes immediately download blocks from the CanonicalTransactionChain contract’s append-only list of blocks. For further details on how blocks are stored in this contract, go to the block storage section above.
The Ethereum data indexer and the Optimism client software are the two main parts of optimism nodes. The “data transit layer” (opens new window), also known as the Ethereum data indexer, reconstructs the Optimism blockchain from blocks posted to the CanonicalTransactionChain contract. The DTL looks for CanonicalTransactionChain events that indicate the publication of fresh Optimism blocks. In order to recreate the published blocks in the default Ethereum block format, it then examines the transactions that generated these events (opens
The Optimism client software, the second component of the Optimism node, is a nearly stock version of Geth (opens new window). As a result, Optimism and Ethereum are practically identical. In particular, Optimism shares the identical Ethereum Virtual Machine, the identical account and state structure, the identical gas metering method, and the identical price schedule (all open in new windows) (opens new window). This architecture, which we call “EVM Equivalence” (opens new window), allows for Optimism to “simply work” with the majority of Ethereum tools, including the most complicated ones.
The DTL is regularly checked by the Optimism client software for freshly indexed blocks. The client programme will download and carry out the transactions contained in a new block when it is indexed.
Bridging assets between layers
Users can communicate any messages between smart contracts on Optimism and Ethereum because to the way optimism is constructed. This enables the exchange of assets between the two networks, including ERC20 tokens. Depending on which way messages are transmitted, several mechanisms are used for this communication to take place.
Users can deposit assets (ERC20s and ETH) from Ethereum to Optimism using this functionality in the Standard bridge, and they can also withdraw the same assets from Optimism back to Ethereum. For further information on the Standard bridge’s inner workings, consult the developer documentation and examples.
Moving from Ethereum to Optimism
Users only need to activate the CanonicalTransactionChain contract on Ethereum to add a new block to the Optimism block in order to send messages from Ethereum to Optimism. For more information, go to the block creation section above. Transactions that seem to come from the address that produced the block can be found in user-made blocks.
Moving from Optimism to Ethereum
In the same manner that Ethereum contracts can easily produce transactions on Optimism, this is not possible for contracts on Optimism. As a result, returning data from Optimism to Ethereum requires a little more effort. We need to be able to make verifiable claims about the optimism of Ethereum-based contracts rather than automatically producing authenticated transactions.
Making statements about the state of optimism that can be proven requires a cryptographic commitment in the form of the trie’s root (opens new window). This commitment will alter after each block since optimism’s state is changed after each block. A smart contract publishes commitments on a regular basis (about once or twice each hour).
These promises can be used by users to produce Merkle tree proofs (opens new window) about the optimism situation. Ethereum smart contracts can verify these proofs. The L1CrossDomainMessenger, a handy cross-chain communication contract that Optimism manages, can verify these proofs on behalf of other contracts.
Verifiable claims regarding the information included in the storage of any contract on Optimism at a particular block height may be made using these proofs. Then, using this fundamental functionality, it will be possible for contracts on Optimism to communicate with contracts on Ethereum. Contracts on Optimism can use the L2ToL1MessagePasser (opens new window)contract (predeployed to the Optimism network) to store a message in the state of Optimism. Users can later demonstrate that contracts on
Fault proofs
Without any direct evidence of their legality, state pledges are broadcast to Ethereum in an optimistic rollup. Instead, for a while, these promises are regarded as pending (called the “challenge window”). A proposed state commitment is deemed final if it is not contested during the challenge window, which is currently set to seven days. On Ethereum, smart contracts can securely accept proofs about the status of Optimism based on a commitment once it is deemed to be final.
When a state promise is contested, a “defect proof” process—previously known as a “fraud proof” method (opens new window)—can be used to render it invalid. The commitment is withdrawn from the StateCommitmentChain if the challenge is successful, at which point another proposed commitment will take its place. It’s crucial to understand that only the publicly available promises regarding the state of the chain are reversed by a successful challenge, not Optimism itself. A fault proof challenge leaves the transaction sequencing and optimism unaltered.
The November 11th EVM Equivalence (opens new window)update is having an adverse influence on the fault proof process, which is now undergoing significant rebuilding. The Protocol specifications area of this website has more information on this procedure.
Start building
You have reached the conclusion of How Optimism Works. We believe you have gained a thorough understanding of optimism. Of course, a journey’s end always marks the start of another. It’s time to start constructing now that you’re an authority on all things optimism!
Deploy an app today
On Optimism, creating smart contracts has never been simpler. We suggest reading through our developer docs if you’re searching for a place to start. Everything you require to create and launch your first app on Optimism is contained there.
Get involved with Optimism
Optimistic about it? Want to make a direct donation? Visit our contributing page for a list of several ways you can actively contribute to the development of Optimism. To find more methods to assist, you may also consider joining the Optimism discord (opens new window).
