Everything you need to know about Optimistic Rollups with Optimism (Part2)
This post is the second part of our Optimistic Rollup series, where we discussed optimism nodes, OVM and contracts. If you haven’t read Part 1 of this series, it won’t be easy to follow along with Part 2.
Bridge
Bridges facilitate communication between Layer 1 and Layer 2 through the transfer of information and assets.
One way to achieve this is to lock assets (ETH and ERC-20) on L1 and receive equivalent assets to use on L2. Eventually, whoever ends up with them might want to bridge them back to L1. When doing this, the assets are burned on L2 and then released back to the user on L1. This is the way the Optimism standard bridge.
The Standard Bridge is composed of two main contracts the L1StandardBridge and the L2StandardBridge.
The bridge has two main flows:
- Deposit (from L1 to L2)
- Withdrawal (from L2 to L1)
Deposit
Layer 1
1. If depositing an ERC-20, the depositor gives the bridge an allowance to spend the amount being deposited.
2.The depositor calls functions on the L1StandardBridge (depositERC20, depositERC20To, depositETH, or depositETHTo)
3. The L1 bridge takes possession of the bridged asset
- ETH: The asset is transferred by the depositor as part of the call.
- ERC-20: The asset is transferred by the bridge to itself using the allowance provided by the depositor.
4. the L1 bridge uses the cross-domain message mechanism to call finalizeDeposit on the L2StandardBridge.
Layer 2
5. The L2StandardBridge verifies the call to finalizeDeposit is legitimate:
- Came from the cross-domain message contract
- Was originally from the bridge on L1
6. The L2StandardBridge checks if the ERC-20 token contract on L2 is the correct one:
- The L2 contract reports that its L1 counterpart is the same as the one the tokens came from on L1
- The L2 contract reports that it supports the correct interface (using ERC-165).
7. If the L2 contract is correct, call it to mint the appropriate number of tokens to the appropriate address. If not, start a withdrawal process to allow the user to claim the tokens on L1.
Withdraw
The assets are burned on L2 and then released back to the user on L1.
Layer 2
1.The withdrawer calls the L2StandardBridge (withdraw or withdrawTo)
2.The L2StandardBridge burns the appropriate number of tokens belonging to the sender
3.The L2StandardBridge uses the cross-domain message mechanism to call finalizeETHWithdrawal or finalizeERC20Withdrawal on the L1StandardBridge.
Layer 1
4. The L1StandardBridge verifies the call to finalizeETHWithdrawal or finalizeERC20Withdrawal is legitimate:
- Came from the cross-domain message mechanism
- Was originally from the bridge on L2
5. The L1StandardBridge transfers the appropriate assets (ETH or ERC-20) to the appropriate address.
Transactions in Optimism
To reduce costs while increasing speed, Optimism runs all its calculations outside the Ethereum blockchain (Off-Chain). Transaction data is, however, stored on the Ethereum mainnet (Mainnet).
Transactions and state updates are all posted on the main chain while resource intensive computation and storage are moved to the rollup.
Transactions data layout
Optimistic rollups transaction data is composed of five fields:
- From: The signatures of the addresses from which funds are sent during the transactions. (65 bytes)
- To: The address to which the funds are sent during the transactions. (3 bytes)
- Value: The Amount of Ether to be sent during the transaction. (4–6 bytes)
- Fee: The transaction fee imposed upon the transaction by the system (1 byte)
- Nonce: The Nonce value hash randomization. (2 bytes)
Transaction types
There are two types of transactions:
- L2 <> L2 transactions (occur between two addresses at the same layer).
- Cross-chain transactions that occur between L1 <> L2 chains.
L2 <> L2 transactions
- The user sends his transactions to the sequencer node.
- The sequencer verifies the validity of transactions by checking its gas fee and adding it to the L2 immediately adds it to L2 chain.
- After adding a few transactions to the L2 chain, the sequencer will call a smart contract on L1 (defined by optimism) and send it the transaction data for all those L2 transactions performed.
- The smart contract on L1 store transaction data and state roots (rollups) in another smart contract designed for storage.
- Once the transaction data has been stored on L1, the verifying nodes will include the transaction in their copies of the L2 chain.
L2 <> L1 transactions
Transactions from L2 to L1 can be more complicated because the L1 must ensure that the L2 state root after the transaction and state change is valid.
- A user sends a deploy transaction of a smart contract off-chain to an aggregator ( a bloc producer in this construction)
- An aggregator locally deploys the transaction creating the new smart contract
- That aggregator computes the new state root (a Merkle root)
- That aggregator creates an Ethereum transaction which contains that state root calculated in step 3.
- Operators identifying an aggregator deploying an invalid state root can challenge the aggregator by posting the valid state root and Merkle proof. If correct, bonds can be slashed, and rewards claimed
- After an invalid block has been committed and a fraud-proof is finalized, the chain in layer 2 can be rolled back and resume from the previous non-fraudulent block.
Transaction fees
The process of sending a transaction on Optimism is identical to the process of sending a transaction on Ethereum. When sending a transaction, you should provide a gas price greater than or equal to the current L2 gas price. Like on Ethereum, you can query this gas price with the eth_gasPrice RPC method. Similarly, you should set your transaction gas limit in the same way that you would set your transaction gas limit on Ethereum (e.g., via eth_estimateGas).
Generally speaking, fees on the Optimism mainnet (also known as L2) are far lower than on the L1 Ethereum network.
As shown in the figure below, there are two fees associated with every Optimism transaction: an L1 (security) fee and an L2 (execution) fee: the L2 fee is the cost to execute your transaction in L2 and the L1 fee is the estimated cost to publish your transaction on L1 (in a rollup batch).
L2 Execution Cost:
Transactions on the Optimism mainnet consume the same amount of gas as analogous transactions on the Ethereum mainnet, but the typical price for gas on Optimism is merely 0.001 gwei, hundreds of times less expensive than Layer 1. Although the price of gas may rise significantly during times of high usage, it typically only accounts for 0.4% of the total transaction fee.
l2_execution_fee = transaction_gas_price * l2_gas_used
L1 security fee:
The L1 security fee is the cost of publishing the transaction on L1 (the cost of Ethereum equivalent security). It is deducted automatically from the user’s ETH balance on Optimistic Ethereum. It is based on three factors that are multiplied together:
The gas price for L1 transactions (The current gas price on Ethereum).
The gas used on L1 to publish the transaction. This is based on the transaction length,
A fixed overhead cost denominated in gas. This is currently set to 2100.
A dynamic overhead cost which scales the L1 fee paid by a fixed number. This is currently set to 1.0.
l1_data_fee = l1_gas_price * (tx_data_gas + fixed_overhead) * dynamic_overhead
Fraud Proof
Fraud proofs are consensus protocols that verifiers use to check if the sequencer is honest or not. If the sequencer posts a state root to layer L1 in StateCommitmentChain, any light node can download this state root. If it detects that at least one transaction is fraudulent, it requests the execution of the fraud proof mechanism. In this case, the verifier node starts a fraud proof consensus by doing the following steps:
Step 1: Download all states root forming this fraudulent batch state root from a predeployed smart contract called StateCommitmentChain.
Step 2: Scan the download list to find the first corrupted root state corresponding to the fraudulent transaction reported by the light node.
Once this disputed transaction is detected, the FraudVerifier smart contract is called by invoking its initializeFraudVerification method with parameters such as the root state which com comes before the corrupt root state, the disputed transaction, and others (Intialize fraud verification method).
The FraudVerifier smart contract manages the entire fraud proofs consensus. It starts by calling the StateTransitionerFactory smart contract by invoking its method _deployTransitioner (FraudVerifier method) and this method calls the StateTransitionerFactory method (create) with parameters: state manager contract address, corrupt state root index, pre-state root, and disputed transaction hash to create stateTransitioner smart contract.
The stateTransitioner smart contract thus created by the StateTransitionerFactory smart contract will subsequently call the StateManager smart contract (stateManager is calling here) to properly execute the disputed transaction. This execution goes through the call of the method StateTransitioner execution method by the verifier.
The smart contract StateManager is designed to only contain information from the state root that contains the disputed transaction. Once the execution of this function completeTransition is complete a new root state of the disputed transaction is provided to the verifier.
Step 3: compare the state root obtained by the verifier in step 2 with the fraudulent state root downloaded in step 1.
If the disputed transaction was not fraudulent, the transaction from the L2 to the L1 is finalized on the L1, else the finalizeFraudVerification method of the FraudVerifier smart contract is called. This method calls deleteStateBatch method which proceeds to delete all state root batches after (including) the disputed transaction from the StateCommitmentChain smart contract.
The CanonicalTransactionChain smart contract remains unchanged, so the original transactions are re-executed in the same order.
If a root state is published on the L1 by the sequencer, all other nodes have a 7 days period to dispute. After this period, no dispute concerning this state root is possible, so the transaction is finalized on the L1.
Conclusion
You’ve made it! That was a long technical post on how Optimism works and its key components. We hope you’ve learned quite a bit about Optimism under the hood. Optimism provides a throughput increasing solution for Ethereum, while maintaining full compatibility with existing tooling and re-using software written by the Ethereum community like Geth and EVM and deriving the security from Ethereum Mainnet for data availability and verification.