• Pricing
  • Enterprise
  • Customers
  • Blog

Optimism blockchain – Ethereum Layer 2 scaling solution

One of the most widely used blockchains for smart contracts is Ethereum; As more users sign up, the network becomes more expensive and slower. However, there are many scaling options (layer 2 chains) like Polygon, Optimism, and Arbitrum exist which can scale Ethereum to make it faster and cheaper. 

What are Layer 2 chains? 

The phrase “Layer 2”, or L2 refers to a protocol that is based on an existing blockchain and used to address the scaling issues of Layer 1 (L1) blockchains. As mentioned above, it is quite challenging for blockchains like Bitcoin and Ethereum to process thousands of transactions per second, which makes the blockchains slow and expensive. This is where layer 2 solutions come into play; these solution helps to scale these existing blockchain. 

The current blockchains are not replaced by layer 2 chains. Although layer 2 chains would do the majority of the work, layer 1 serves as the main chain and gives security while layer 2 offers quick transactions, low transaction fees, and the ability to process thousands of transactions per second. 

What is Optimism? 

Optimism is a layer 2 chain that is built on top of the Ethereum blockchain. Optimism reduces transaction fees and speeds up Ethereum transactions. While every transaction happens on the Optimism, the data is posted to Ethereum and validated there. 

With more than 313 million USD locked in its smart contract as of this writing, Optimism is the second-largest layer. 

How does Optimism work? 

Optimism uses advanced data compression technique known as Optimistic Rollups. They are new methods of scaling the Ethereum blockchain developed by the amazing team behind Optimism Foundation. Rollups can be divided into two categories: optimistic rollups which it developed by the Optimism Foundation, and ZK rollups, often known as zero-knowledge rollups. 

Rollups significantly increase processing speeds by moving a large amount of transactions data off-chain. Unlike other sidechains, optimistic rollups still publish a small amount of data on the decentralized layer 1 network to be validated which would increase the security. 

Optimistic rollups do not publish proofs of validity for transaction batches posted on-chain since they presume off-chain transactions are valid. This separates optimistic rollups from zero-knowledge rollups that publish cryptographic proofs of validity for off-chain transactions. 

In order to stop invalid state transitions from happening, optimistic rollups rely on using fraud proofs. To do this, an Ethereum Optimism transaction must be executed. In simple language, between Layer 1 and Layer 2, the OVM, or Optimistic Virtual Machine, is a sandboxed environment that ensures deterministic smart contract execution. 

Because they both serve to execute computation, the OVM and EVM are similar. The OVM, however, just acts as the EVM’s interface. You can see that virtualization occurs through the Execution Manager by comparing EVM and OVM execution. 

The Solidity compiler converts Solidity to Yul, which is subsequently converted into EVM Instructions, and eventually into bytecode. After compiling to EVM assembly, you can “rewrite” each opcode in its OVM variant if necessary. 

Optimism Bridge 

Even though Optimism is a layer 2 chain connected that is connected to Ethereum, it is also a separate blockchain system, meaning if you want to transfer a data from one blockchain to another blockchain, you will need to use a bridge. 

A bridge connects two chains and allows NFT (Non-Fungible Token), tokens, and other arbitrary data to be transferred between them. 

For common use cases such as moving tokens between blockchains, you can use Standard Token Bridge. It is a smart contract created by the Optimism team and has all the features required to transfer tokens between Ethereum and Optimism. 

However, if Standard Token Bridge does not entirely cover your use-case, you can send data between L1 and L2 using the following approach. 

Communication basics between layers 

Communication between L1 and L2 is enabled by two unique smart contracts known as “messengers.” Because each layer has its own messenger contract, some lower-level communication elements are abstracted away. Here is an example of sendMessage function which is attached to each messenge written in Solidity. 

function sendMessage( 
    address _target, 
    bytes memory _message, 
    uint32 _gasLimit 
) public; 

Here is another example, in case you want to call a contract on optimism from a contract on Ethereum. 

// A L2 contract 
contract MyOptimisticContract { 
    doSomething(uint256 myFunctionParam) public { 
        // ... some code goes here 
// And pretend this is on L1 
contract MyOtherContract { 
    function doTheThing(address myOptimisticContractAddress, uint256 myFunctionParam) public { 
            1000000 // use whatever gas limit you want 

code from optimism docs 


The calls between Ethereum and Optimism are not instantaneous meaning the exact speed of transactions depends on the directions in which the transactions are sent. 

For Layer 1 to Layer 2 transactions 

A transaction sent from L1 to L2 can take up to 15 minutes to reach the target L2 contract on the mainnet and 5 minutes on the Optimism Goerli testnet. This is due to the fact that L2 nodes often wait for a certain number of Ethereum block confirmations before performing an L1 to L2 transaction. 

For Layer 2 to Layer 1 transactions 

The interactions between Layers 2 and 1 cannot be sent for at least a week, so messages sent from Layer 2 will only be received after the week has passed. 

It takes a few seconds on goerli and seven days on mainnet to complete the challenge, often known as the fault challenge period. This waiting period is intended to keep Optimism’s functionality secure. 

Decentralized and Centralized 

You can use Optimism’s message infrastructure to create fully decentralized applications. You can issue a single L1 transaction to allow layer 1 code to call layer 2 at any moment or to update the code. 

However, it can be a little challenging to send messages from layer 2 to layer 1. You must initiate a transaction on layer 2 first, then when the fault challenge period has passed, you must initiate a transaction on layer 1 that includes a merkle proof. Due to the high cost of merkle proof verification, this is expensive. 

If your app is on a centralized server, the most straightforward approach is to have two providers, one connected to Layer 1 (Ethereum) and the other to Layer 2 (Optimism). 


The sole purpose of this post was to provide you with an overview of the Optimism blockchain and the interaction between Optimism and Ethereum. More about optimism and its mechanism will be covered in upcoming posts. 

👋 Thanks for reading, See you next time 

Have you already explored what you can achieve with Chainstack? Get started for free today.


Querying full and archive Ethereum nodes with Python

Whenever we need to query data from the blockchain, we fetch it from a node. An archive node differs from a full node since the first holds the entire history of network transactions. Thus, some queries for older block transactions cannot be fetched easily on a full node. In this tutorial, we will programmatically fetch data from the blockchain, switching between full and archive nodes when necessary.

Bastian Simpertigue
Sep 22