Blockchain–Optimism (Layer2)

Hits: 0

Introduction

Optimism, formerly known as Plasma Group, is the development team behind the Optimistic Rollup scaling technology. Rollup is a [smart contract] on Ethereum that connects the Ethereum main chain and L2. Rollup receives transaction data from the Ethereum main chain, sends it to L2 that does the computation, and then receives the result of the L2 computation. It is important to note that there are two variants of Rollup: Optimistic Rollup and ZK-Rollups. Optimism only uses Optimistic Rollups.

On Optimism, transactions sent to L2 are received by the Sequencer, which is responsible for accurately executing received transactions. Sequencers are rewarded for executing transactions correctly, but punished if they act maliciously by slashing their staked funds.

If anyone suspects Sequencer of fraud, they may alert the arbitrator contract on the Ethereum mainnet. This verifies the validity of the results generated by the Sequencer using the Optimistic Virtual Machine (OVM), an Ethereum Virtual Machine (EVM)-compatible execution environment built for L2 systems. If it happens that Sequencer’s result is invalid, Optimistic Rollup will perform fraud proof and Sequencer’s funds will be forfeited. A portion of the forfeited funds will be awarded to the whistleblower. Whistleblowers challenge Sequencer’s results during a period known as the”challenge period.” This period typically lasts around a week, which results in a one-week delay in transferring assets from Optimism back to Ethereum.

While withdrawal delays are an issue with Optimism, the gas cost savings are significant. This is because Rollups are able to improve efficiency through a series of compression techniques that replace data with computation as much as possible. This results in a 100x savings in on-chain space.

block production

Optimism block production is primarily managed by a single party called a “sequencer”, which aids the network by providing the following services:

  • Provides instant transaction confirmation and status updates.
  • Build and execute L2 blocks.
  • Submit user transactions to L1.

The sequencer has no memory pool and transactions are accepted or rejected immediately in the order they were received. When a user sends their transaction to the sequencer, the sequencer checks that the transaction is valid (i.e. pays enough fees), and then applies the transaction to its local state as a pending block. These pending blocks are periodically bulk submitted to Ethereum for finalization. This batching process significantly reduces overall transaction fees by spreading fixed costs across all transactions within a given batch. The sequencer also applies some basic compression techniques to minimize the amount of data posted to Ethereum.

Because the sequencer is given preferential write access to the L2 chain, the sequencer can provide strong guarantees as to what state it will ultimately determine once it decides on a new pending block. In other words, know exactly what the impact of the transaction is. As a result, the L2 state can be updated very quickly and reliably. The benefits of this include a fast, instant user experience, and near real-time Uniswap price updates.

Alternatively, users can skip the sequencer entirely and submit their transactions directly via Ethereum CanonicalTransactionChaintransactions. This is usually more expensive because the fixed cost of submitting this transaction is paid entirely by the user and is not amortized over many different transactions. However, this alternative submission method has the advantage of being resistant to sequencer censorship. Even if the sequencer is actively censoring the user, the user can always continue to use Optimism and recover any funds through this mechanism.

From Ethereum to optimism

To send a message from Ethereum to Optimism, a user simply triggers a CanonicalTransactionChaincontract on Ethereum to create a new block on top of the Optimism block. For additional context, see the section above on block production. ** User-created blocks can include transactions that appear to originate from the address that generated the block

Switch from Optimism to Ethereum

Contracts on Optimism cannot generate transactions on Ethereum as easily as Ethereum contracts can generate transactions on Optimism. Therefore, the process of sending data from Optimism back to Ethereum is more complicated. Instead of automatically generating authenticated transactions, we must be able to make provable statements about the optimistic state of contracts on Ethereum.

Making a provable statement about an optimistic state requires a [cryptographic commitment (opens new window) in] in](https://en.wikipedia.org/wiki/Commitment_scheme “Cryptographic Commitment (opens in new window)”) the form of the root of the optimistic state tree *(opens new window) . Optimism’s state is updated after each block, so this commitment also will change after each block. Commitments are periodically posted (about once or twice an hour) to a smart contract on Ethereum called *  (  https://etherscan.io/address/0xBe5dAb4A2e9cd0F27300dB4aB94BeE3A233AEB19)** .StateCommitmentChain

Users can use these commitments to generate Merkle tree proofs (opens in new window) about optimistic states. These proofs can be verified by smart contracts on Ethereum. Optimism maintains a convenient cross-chain communication contract, L1CrossDomainMessenger   ( https://etherscan.io/address/0x25ace71c97B33Cc4729CF772ae268934F7ab5fA1 )**, which can verify these proofs on behalf of other contracts.

These proofs can be used to make verifiable statements about data stored in any contract at a specific block height on Optimism. This basic functionality can then be used to enable contracts on Optimism to send messages to contracts on Ethereum. L2ToL1MessagePasser  ( [https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000)Contracts]Contracts](https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000000 “https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000000”) on Optimism can use contracts (pre-deployed to the Optimism network) to store messages in Optimism state. The user can then prove to the contract on Ethereum that a given contract on Optimism is actually meant L2ToL1MessagePasserto send some given message by showing that the hash of that message is stored in the contract.

fault proof

In Optimistic Rollup, state commitments are published to Ethereum without any direct proof of the validity of those commitments. Instead, these commitments are considered pending for a period of time (called a “challenge window”). A proposed state commitment is considered final if it is not challenged during the challenge window (currently set to 7 days). Once a promise is considered final, smart contracts on Ethereum can safely accept a proof of optimistic state based on that promise.

When a state commitment is challenged, it can be invalidated through a “Proof of Fault” (previously called “Proof of Fraud”) (opens a new window to invalidate (opens in new window)”) ) process. If the promise is successfully challenged, it is removed from it and StateCommitmentChaineventually replaced by another proposed promise. It is important to note that a successful challenge does not roll back Optimism itself, only the published promises about the chain state. The order and optimistic state of transactions will not be altered by a proof-of-failure challenge.

The difference between L1 and L2 usage process:

  • L1-L2 Deposit about 5 minutes
  • L2-L1 withdraw takes 7 days (7 days time description, you can check from Optimism to Ethereum )
  • L2-L2 tranfer second level

Summarize:

Arbitrum, like Optimism, is an extended solution based on Optimistic Rollup. There is almost no difference between the two. The benefit of both is that they are easy to integrate with DApps, as they require few changes to the DApp’s underlying smart contracts. Because of this, these two solutions have become the first choice of many developers.

While the two solutions will directly compete for market share, for DApps there are only benefits to using both. Deploying on multiple platforms makes social consensus problems easier to manage. DApps that adopt parallel solutions to each other enable inter-protocol transactions to remain on L2. Uniswap’s adoption of Optimism and Arbitrum will increase the number of DApps it can conduct L2 to L2 transactions.

In theory, DApps should implement as many L2 scaling solutions as possible, but in practice this is impractical

You may also like...

Leave a Reply

Your email address will not be published.