OP-Stack: Most Simple Framework to Build Your Blockchain

Key Takeaways

• Launching your own blockchain or rollup has clear benefits like customization, and scalability, and from various options, OP-Stack is the most easy-to-deploy software.

• OP-Stack is composed of 4 node components and some smart contracts and various projects are being built around OP-Stack.

• However, there are limitations of OP-Stack: Fault-proof system, centralization, and lack of core innovations.

• Conclusion: OP-Stack has enabled the simpler creation of personal rollups, laying the ground for growth in the ecosystem and innovations in customized rollup space.

1. Launching a Blockchain with OP-Stack

As decentralized applications (dApps) continue to grow, and as more conventional businesses begin to engage in the blockchain, there's a clear trend emerging. There is a keen interest in constructing their own blockchain or rollup for a multitude of reasons.

Launching their own blockchain can provide some notable advantages. The question of why one should embark on such a venture with OP-Stack can be answered by examining key benefits:

1.1 Customizability

In terms of customization, creating your own rollup or blockchain opens the door to a world of possibilities. The freedom to tailor various aspects to meet specific provides multiple benefits. Whether you are looking at the governance model, transaction fees, or the functionality of smart contracts, you can alter these elements to suit your particular requirements.

The modularity inherent in OP-Stack's design encourages customization. The structure is deliberately crafted to enable adaptability, allowing components such as the execution client to be diversified. This means that you can tailor these elements to fit the unique requirements of your project, providing control and flexibility.

1.2 Scalability

Rollups and blockchains are fundamentally designed to address issues of scalability. When you take on the task of launching your own solution, you can use the resource only for your use cases resulting in high transaction throughput with lower cost. This allows for a level of scalability that often surpasses what is offered by existing platforms. Consider, for instance, the potential to maximize transaction speed by optimizing your own blockchain. This would enable faster, more efficient operations than those currently achievable on more congested platforms.

1.3 Resource Efficient

OP-Stack has the capability to utilize the security features of Data Availability layers and can be operated with a single sequencer. While specialized SDKs such as those provided by Cosmos or Polkadot offer various benefits like interoperability solutions and diverse core feature customization, they come with the high cost of operating separate sets of validators or the requirement of inclusion to utilize the shared security property. Furthermore, their development tools aren't as abundant as those in the Ethereum ecosystem. Conversely, OP-Stack can make use of the tools available in the Ethereum ecosystem and can tap into the security features of the underlying Data Availability layer, such as Ethereum.

2. About OP-Stack

OP-Stack is an open-source, modular methodology designed for constructing optimistic rollups. The Bedrock upgrade on June 6, 2023, was the initial mainnet release of the OP-Stack. As the Optimism network underwent a significant Bedrock upgrade, it lowered transaction fees, boosted security, and provided more customizability. The major specifics of improvements are like below.

This upgrade resulted in a 47% reduction in protocol costs on the Optimism Mainnet. Transaction fees were decreased by optimizing batch compression and utilizing Ethereum for data availability. Comprising 99% in state chain commitments and 20% in batch submission costs. In the future, OP-Stack aims to advance Optimism toward becoming a "Superchain" of interlinked blockchains, making OP-Stack based chains to be interconnected with a shared infrastrcture.

3. Architecture

3.1 Components

The OP-Stack solution encompasses four essential components: nodes (op-geth, op-node) and sequencer-specific components (op-batcher, op-proposer). Each plays a distinctive role in enabling the rollup process.

Nodes:

• op-geth sits at a key transaction process intersection, channeling user transactions to the Execution Layer, ensuring accurate and efficient network transactions. Additionally, op-geth adjusts the state based on the transaction, applying transactions to the preceding state to create the new one. It manages the state's storage and modification throughout the transaction process, thus accurately reflecting all state changes.

• The op-node component is integral to converting raw data from the Data Availability Layer into processed inputs for the Execution Layer via the standard Ethereum Engine API. It sources inputs from Ethereum block data, Sequencer transaction batches, and Deposited transaction events, with the current system state guiding its parsing of raw input data. This mechanism ensures efficient and precise data processing. Functions include L2 deposit and withdrawal transactions submission to L1, failed transactions retry, L2 transaction statuses update, and L1 gas prices calculation based on recent tips.

Sequencer-specific:

• op-batcher mainly handles writing transactions to the L1 network (Ethereum), compressing transactions to optimize network efficiency and streamline data transmission and storage.

• Lastly, the op-proposer is crucial in finalizing state transitions. After op-geth has modified the state, op-proposer writes a commitment to the post-transaction state to L1, thereby recording the updated state. It proposes the new Merkle root of the updated state, utilizing Merkle roots to minimize the data written to L1, thereby reducing transaction costs. These state root proposals are posted to the L2OutputOracle on the L1 network. These output proposals must undergo a 7-day fault challenge period before gaining authority, facilitating potential disputes and challenges, which enhances network reliability and accountability.

3.2 Contracts

Several contracts need to be deployed for the operation of an OP-Stack rollup. Some of the primary contracts include the following:

3.2.1 OptimismPortal deployed on L1

The OptimismPortal is a contract that facilitates communication between L1 and L2. It serves as the primary gateway for cross-chain messaging within the Optimism system.

The contract enables several crucial functionalities. Firstly, it permits the depositing of L1 transactions that are slated for execution on L2. Secondly, it assists in verifying L2 withdrawals and withdrawing funds from L1. Thirdly, it has a built-in feature to pause cross-chain messaging, which is managed by the Guardian (an address that can pause deposits and withdrawals). Lastly, it keeps track of confirmed withdrawals and the l2Sender, facilitating the finalization of withdrawals.

In addition, the L2OutputOracle and SystemConfig contracts appear to have specific roles in this system. The L2OutputOracle assists in validating the L2 state, while the SystemConfig contract presumably helps in setting up system parameters.

3.2.2 L2OutputOracle deployed on L1

The L2OutputOracle is a contract that holds the resulting state root of L2 as submitted by the op-proposer. This contract allows other L1 contracts to authenticate information regarding the L2 state.

Several key functions are facilitated by this contract. It allows the proposer to submit new L2 outputs at a specific submission interval. Furthermore, it enables the challenger to remove any invalid L2 outputs. Additionally, it permits other contracts to validate information about the L2 state by scrutinizing the L2 outputs. Lastly, it is also capable of calculating timestamps and block numbers for L2 based on the L2 block time.

In essence, the L2OutputOracle contract serves as a reliable source of information about the state of the L2 chain for L1 contracts. By storing commitments to the L2 state, it facilitates the cross-chain verification of information.

3.2.3 L1Block deployed on L2

The L1Block is a contract that retains information about the most recent known L1 block.

This contract is likely a definitive source of information about the latest L1 block for L2 contracts. By archiving this data on L2, L2 contracts can access details about L1 without the need for cross-chain calls. The stored information can be used in various ways:

• It enables the computation of L1 gas prices for L2 transactions.

• It assists in verifying the L1 block data submitted by the sequencer.

• It allows L2 contracts to verify if a specific L1 transaction has been successfully mined.

The sequencer presumably manages the depositor address, which refreshes the contract's values each time a new L1 block reaches its finalized state.

More contracts can be found in this link.

3.3 Walkthrough

3.3.1 Transaction

The transaction is required to be recorded on L1 (Ethereum). Typically, op-batcher handles this process for L2 transaction, but any user has the option to send an L1 transaction to submit an L2 transaction, which bypasses op-batcher.

Then to modify the state, the transaction needs to be executed by op-geth. Subsequently, op-proposer generates a commitment to the post-transaction state and writes it to L1. It's worth noting that op-proposer doesn't need to create a commitment after every state transition.

The process of an L2 transaction involves several key steps:

Posting Transactions to L1

Firstly, the transaction is written to L1. This includes two sub-steps: compression and posting to L1. During compression, the op-batcher divides sequencer batches into channels to maximize the compression ratio. Channels, once filled or timed out, are compressed and transcribed.

Following compression, the transaction is posted to L1. When a channel is saturated, it's dispatched to L1 as either a single or multiple transactions, depending on the data size. An L2 transaction can occupy three states: unsafe (processed but not yet written to L1), safe (processed and written to L1, but might be discarded due to an L1 reorganization), and finalized (written to L1 in an adequately mature block). Once a transaction reaches the 'finalized' state, it is irrevocable.

Execution

The state processing phase involves two major steps: applying transactions to the existing state to yield a new state and proposing the new Merkle root that represents the state. This is undertaken by two components: op-geth and op-proposer.

In the initial phase, op-geth applies the transactions to the current state. This action results in an altered state as the transactions are applied. op-geth is a minimal modification of ethereum geth.

Proposing State Root

In the subsequent step, the op-proposer steps in and proposes the new Merkle root of the state, and stores the root to an L2OutputOracle contract in L1. Rather than directly transcribing the entire state to L1, which would be resource-intensive due to its large size, a Merkle root is used as a compact representation. This root encapsulates critical information about the state alterations and enables effective verification.

3.2.2 Block Production

Before the Bedrock upgrade, a block was produced for each transaction. However, post-upgrade, a block is generated every 2 seconds, where transactions in this period and the altered state root are included. Also, Every block has a system transaction called L1 Attributes Deposited Transaction that encapsulates the latest information of an L1 block. Then op-geth receives the transactions and applies them to the previous state.

L1 Attributes Deposited Transaction serves two critical roles. Firstly, it equips L2 contracts with the latest updates about the most recent L1 block, eliminating the need for separate cross-chain calls. Secondly, it enables L2 contracts to authenticate the correctness of the information regarding L1 blocks provided by the sequencer.

The L1 Attributes Deposited Transaction comes with a unique set of features. The rollup node from L1 blocks generates it during block derivation. This transaction contain valuable information, including the L1 block number, timestamp, base fee, hash, and other pertinent details. They originate from the L1 Attributes Depositor account and do not carry any ETH value nor interact with the L2 gas pool. Regardless of their validity, they are always incorporated in the block to ensure seamless block construction. The L1 Attributes Predeployed Contract stores and makes this information accessible.

The standard workflow for L1 Attributes Deposited Transactions is as follows:

• The op-node makes an L1 Attributes Deposited Transaction containing the most recent L1 block details in an L2 block.

• This transaction is carried out on L2, which then initiates the L1 Attributes predeployed Contract.

• The predeployed contract holds onto the L1 block data and triggers an event.

• Other L2 contracts can now engage with the predeployed contract to fetch the latest L1 block information.

In summary, L1 Attributes Deposited Transactions serve as a trustworthy reference for L1 blocks for L2 contracts. By embedding this information directly into L2 blocks, L2 contracts can effortlessly access up-to-date L1 data, thereby eliminating the need for cross-chain calls.

4. Related Projects

4.1 OP-Stack Chains

As the launch of OP-Stack, multiple projects have been building a rollup using the OP-Stack codebase. Base by coinbase, opBNB on BNB, and ZORA chain is an example and is currently in the testnet phase. This can lead to more tools and experiments. Here are some example cases.

4.1.1 OP-Clave

(Source: Opclave | ETHGlobal)

Ethereum supports Elliptic Curve Digital Signature Algorithm (ECDSA) on the elliptic curve secp256k1. However, this necessitates that the verification of other elliptic curves be processed through a newly deployed smart contract, consequently leading to a substantial verification cost. This is an inherent challenge considering the broad potential applications and benefits that diverse elliptic curves can offer.

In response to this issue, OP-Clave has been introduced. It is a custom rollup that incorporates a "secp256r1 verifier" as a precompiled contract, conforming to the standards of Optimism's Bedrock Release. This integration has paved the way for an environment in which Face-Id and Touch-Id verified transactions can be applied. The OP-Clave's unique approach optimizes efficiency and affordability while ensuring secure and reliable transactions.

4.1.2 Celestia OP-Stack

(Source: Celestia)

Celestia has unveiled a demo codebase that allows the operation of OP-stack-based rollups using Celestia as a data availability layer. Given that the bulk of OP-stack's operating expenses come from storing transactions on Ethereum, this implementation enables the rollup to store transaction data on Celestia, while only a reference link to the transaction data is stored on Ethereum. Consequently, this leads to a reduction in operating costs.

4.1.3 RaaS that supports OP-Stack

Rollup as a Service (RaaS) is a growing field that provides tools to deploy and manage rollups. Companies such as Conduit and Caldera are the solutions supporting OP-Stack. Their services aid in simplifying the management and deployment of rollups, supporting the growth and development of OP-Stack applications. The recent announcement by Zora of its own rollup chain is also built using Caldera.

4.2 Infra Tooling

A significant benefit of OP-Stack is its ability to utilize the toolings used in the Ethereum ecosystem. This allows for the use of a wide range of Ethereum tools.

(Source: DappCamp)

4.2.1 op-erigon

Developed by Test in Prod, op-erigon is an alternative execution client for op-geth, modeled as a variant of the erigon implementation. Currently, only op-geth is the only execution client used in the production. However, as the second alternative execution client, this has been deployed to the mainnet and is expected to improve the execution client diversity.

4.2.2 Magi

Developed by a16z, Magi is an alternative rollup client for op-node to enhance client diversity within the rollup. Written in Rust, Magi is compatible with execution clients such as Geth and Besu. While it shares the same functionality as op-node, it is projected to become a viable alternative to it with additional months of development.

5. Limitations

5.1 Limitation of Fault Proof

Optimistic rollup has undergone extensive testing in production with millions of transactions. However, it needs to store input data (transaction) and output to an expensive data availability layer, and the 7-day finality is too long. This is why the zkEVM is gaining attention. Despite the recent RFP (request for proposal) to implement zk on OP-Stack, integrating zero-knowledge into OP-Stack might take substantial time. Furthermore, the fault-proof system currently involves only a handful of participants, indicating a need for enhancement in both efficiency and decentralization. Yet, with the upcoming milestone in the OP-Stack focused on this fault-proof system, I anticipate significant advancements in the near future.

5.2 Decentralization

One of the main drawbacks of the current OP-Stack system is the centralized nature of the sequencer. The sequencer is operated by a single entity and post-Bedrock upgrade, blocks are produced every 2 seconds, as opposed to a block per transaction, opening a possibility for bad MEV like front-running. Currently, to prevent Miner Extractable Value (MEV), the mempool is kept private. However, the Optimism team has plans for decentralization on their roadmap and expects to achieve this in the near future.

5.3 Core Implementation

While the Ethereum ecosystem boasts a vibrant developer community, core-side experimentation is minimal. Instead of application-specific core changes, most implemented features are more generalized. Ethereum Improvement Proposals (EIPs) required for specific applications often struggle to be included in Ethereum core upgrades. Thus, most of these implementations occur on the smart contract side. This also applies to the Optimism ecosystem.

6. Conclusion

OP-Stack has paved the way for easily constructing one's own rollup, with numerous projects being built within this ecosystem. As the ecosystem continues to grow and thrive, the deployment of rollups will become as straightforward as deploying a smart contract.

In my opinion, building applications solely with smart contracts has definite constraints. Despite the myriad of innovations and experiments conducted in the smart contract-based dApps, I believe a surge in more intriguing advancements within these customized rollup spaces. This has been made possible by a framework like OP-Stack, which requires fewer resources to launch one's own rollup.

Thanks to Kate for designing the graphics for this article.