In recent years, the Ethereum ecosystem has faced significant scalability challenges, driving the need for innovative solutions that can optimize operation costs while maintaining the integrity and decentralization of the network. Among these solutions, the OP Stack and Canon Fault Proofs Virtual Machine (VM) have become critical components in the ongoing efforts to enhance the performance and efficiency of Ethereum Layer 2 rollups.

In this context, the OPcity stack delves into the theoretical and practical aspects of the OP Stack and the Canon Fault Proofs VM, providing valuable insights into their implementation, performance benchmark, and potential future improvements. Additionally, it gathers the contributions and knowledge necessary to achieve the OP City milestones, compiling documents developed from December 2023 to 2024. Its purpose is to serve as a starting point for researchers and students to explore and test the implementation of OP Stack rollups, pushing its limits through the OP City stack.

1. OP Stack Theoretical Framework

Based on the OPcity repository

This section establishes the foundations for understanding the OP Stack and Fault Proofs, key elements in Ethereum’s scalability solutions. It begins by addressing Ethereum’s inherent scalability issues and how Layer 2 rollups offer strategies to address these challenges. It highlights how the evolution of the OP Stack, alongside the concept of the Superchain and fault proofs, is crucial for optimizing operational costs in decentralized technologies. This analysis is supported by academic references and relevant URLs, providing an overview of the theoretical foundations driving these advancements.

Ethereum Scalability

Ethereum has established itself as one of the most important blockchain platforms, transforming the development and functioning of applications. Unlike traditional systems, Ethereum is a decentralized, open-source computing network that allows developers to create and execute smart contracts, supporting a wide range of decentralized applications (dApps).

Ethereum functions as a state transition system, where transactions modify the global state of accounts and balances. This is driven by the Ethereum Virtual Machine (EVM), a flexible programming environment designed to execute smart contracts and complex dApps[1]. Smart contracts, a key feature of Ethereum, are self-executing agreements recorded on the blockchain that enable automated and trustless interactions. These contracts are widely used in cases such as custom tokens, financial products, Decentralized Autonomous Organizations (DAOs), and file storage solutions, among others. The immutability and irreversibility of blockchain ensure that these contracts function with high integrity, resilience, and transparency[2].

However, Ethereum faces the “blockchain trilemma,” a challenge of achieving scalability, decentralization, and security simultaneously, where improving one aspect often compromises another. Scalability is measured in transactions per second (TPS), decentralization distributes control across the network preventing censorship and manipulation, and security focuses on the system’s ability to resist attacks[3].

Rollups as Layer 2 solution

Traditional blockchains, like Bitcoin and Ethereum, are recognized for their security and decentralization but face significant scalability limitations. To address this challenge, Ethereum has explored "simple techniques" like Layer 2 solutions, which aim to increase network capacity by allowing different applications to operate on multiple interconnected chains through a crosschain communication protocol, thereby achieving interoperability. Although this approach is decentralized and scalable, it presents security vulnerabilities, as an attacker could compromise the main chain by gaining control of the majority of consensus nodes on a single chain, causing ripple effects on other interconnected chains[4].

One of the most important Layer 2 solutions is the rollup. Rollups aggregate multiple transactions off the main chain (Layer 1) and process them in batches, reducing the workload on Ethereum, allowing more transactions per second, and decreasing the gas fee, data, and computation required [1], without compromising security or decentralization. There are two main types of rollups:

1. Optimistic Rollups: These assume all transactions are valid by default and employ fraud proofs to identify false transactions within seven days.

2. Zero Knowledge ZK Rollups: These provide instant verification of transaction validity using validity proofs

The primary security weakness lies in the verification process of blocks generated by these Layer 2 technologies. Unlike Layer 1, where blocks are fully verified, Layer 2 blocks only contain the necessary state parts to process the block, along with some hashes that prove these provided parts represent the claimed state in the block. This solution involves verifying computation and data availability to ensure the system has performed computations correctly, assuming block validators have access to all necessary inputs and are stored accessibly for anyone to download if needed[5]

In Optimistic Rollups, fraud or fault proofs come into play if a dispute arises, detecting and proving that a specific block or transaction is invalid using Merklized data. This allows network nodes to receive and verify block states without downloading the entire blockchain, assuming that at least one honest node is willing to generate these proofs[6]. This mechanism is also known as an interactive game [7], where a participant optimistically assumes that each proposed outcome is valid[8]. This approach enables faster and more cost-effective scalability by assuming transactions are valid by default[9]

Optimism and the OP stack

Optimism, a Layer 2 scalability solution for Ethereum, utilizes Optimistic Rollups to enhance scalability, reduce transaction time and costs, and maintain robust security [10]. At the core of this ecosystem is OP Mainnet, a Layer 2 blockchain equivalent to the Ethereum Virtual Machine (EVM), directly connected to Ethereum and very similar to its main network, with minor differences mainly related to the specification of different network endpoints[11].

OP Mainnet leverages the OP Stack, a modular open-source software stack that facilitates the creation of Optimistic Rollups and production-ready Layer 2 blockchains. This allows developers to independently customize and upgrade components like consensus, execution, and settlement layers, fostering innovation and ensuring long-term adaptability. Additionally, the OP Stack is compatible with the Optimism Superchain, a network of interoperable OP Stack chains with common standards and protocols. This modular design enables scalability, customization, interoperability, and innovation, helping to avoid the repetitive development of similar software from scratch [12].

The introduction of a fault-proof system in OP Mainnet has been a significant advancement toward total decentralization. This system eliminates reliance on privileged roles for withdrawals and allows users to challenge and verify transactions, reducing centralization and fostering greater network security.

As the OP Stack continues to evolve, additional functionalities are expected, such as more advanced Fault Proof systems and improved interoperability features. This will pave the way for a more robust and interconnected ecosystem of decentralized applications on Ethereum. The current version of the OP Stack, Optimism Bedrock, not only powers the OP Mainnet but also simplifies the deployment of Optimistic Rollups and supports the Superchain concept. This vision aims to build a scalable and interconnected blockchain ecosystem where multiple Layer 2 chains can interact seamlessly, leveraging shared security and development standards.

As the technology matures in terms of security and reliability, the plan is to extend these capabilities, including fraud proofs, to other networks within the optimism ecosystem, such as Base, Metal, Mode, and Zora. This expansion will reinforce the Superchain concept and push the boundaries of Layer 2 scalability and interoperability [13].

Layers of the OP Stack

Based on the *** Optimism Docs***

The OP Stack can be understood as a set of software components that define new layers or integrate as modules within the stack, enabling the construction of a Layer 2 blockchain ecosystem. Below is a detailed breakdown of its layers:

• 1 Data Availability

  The Data Availability Layer defines where the raw inputs of an OP Stack-based chain are published. An OP Stack chain can source input data from one or more data availability modules. These modules significantly impact the system's security model. The most used Data Availability module is Ethereum, allowing source data to come from any accessible information on the Ethereum blockchain, including Ethereum calldata, events, and 4844 data blobs.

• 2 Sequencing Layer

  The Sequencing Layer determines how user transactions on an OP Stack Chain are collected and published to the Data Availability modules in use. In the default OP Stack rollup configuration, sequencing is generally handled by a single dedicated sequencer. The rules defined in the Derivation Layer limit the sequencer's ability to withhold transactions beyond a specific time.

• 3 Derivation Layer

  The Derivation Layer defines how the raw data in the Data Availability Layer is processed to form the processed inputs that are sent to the Execution Layer via the standard Ethereum Engine API(opens in a new tab). The Derivation Layer may also use the current system state, as defined by the Execution Layer, to inform the parsing of raw input data. The Derivation Layer can be modified to derive Engine API inputs from many different data sources. The Derivation Layer is typically tied closely to the Data Availability Layer because it must understand how to parse any raw input data.

• 4 Execution Layer

  The Execution Layer defines the state structure within an OP Stack system and establishes the state transition function that modifies this state. State transitions are triggered when inputs are received from the Derivation Layer via the Engine API. The abstraction of this layer allows modifications in the EVM or different underlying virtual machines.

  EVM
  The EVM is a module within the Execution Layer that uses the same state representation and state transition function as the Ethereum Virtual Machine. The EVM module in the OP Stack´s Ethereum rollup configuration is a slightly modified version that supports Layer 2 transactions initiated on Ethereum and adds an L1 data fee to each transaction to cover the cost of publishing transactions on Ethereum.

  5 Settlement Layer

  The Settlement Layer is a mechanism found in external blockchains that establishes a view of the state of an OP Stack chain on those chains (including other OP Stack chains). For each OP Stack chain, there may be one or more Settlement mechanisms on one or more external chains. The mechanisms of this layer are read-only and allow external parties to make decisions based on the state of an OP Stack chain.

  The term "Settlement Layer" originates from the fact that Settlement Layer mechanisms are often used to handle withdrawals of ETH and tokens from a blockchain. This withdrawal process involves first verifying the target blockchain's state on a third-party chain and then processing the withdrawal based on that state. Essentially, the Settlement Layer allows a third-party chain to be aware of the target chain's state.

  A Fault Proof mechanism based on attestations uses an optimistic protocol to establish a view of the state of an OP Stack chain. In optimistic settlement mechanisms, proposers can suggest what they consider the current valid state of the OP Stack chain. If these proposals are not invalidated within a specific period (the "challenge period"), then the mechanism assumes the proposals are correct. Specifically, in the Attestation Proof mechanism, a proposal can be invalidated if a certain threshold of predefined participants provides attestations of a valid state that differs from the proposed state. This assumes trust in the honesty of at least a threshold number of these predefined participants.

• 6 Governance Layer

  The Governance Layer refers to the general tools and processes utilized to manage system configuration, updates, and design decisions. It is a relatively abstract layer that can include a wide range of mechanisms on a target OP Stack chain and third-party chains, impacting many other layers of the OP Stack.

  From OPcity Repository:

2. Node & Rollup Setup

From OPcity repository:

This section comprehensively explains our experience setting up and running a node and deploying a rollup using the OP Stack. We carried out the setup process using two Intel NUC 13 PRO NUC13ANHi7 Arena Canyon devices, each equipped with an Intel Core i7-1360P 13th generation CPU, 32GB of RAM, and a 4TB SSD running Linux (Ubuntu).

In the test conducted in December, we used a remote VM and a third-party RPC service. However, this configuration presented significant challenges, mainly related to the limitations of RPC calls and restrictions imposed by proprietary hardware. Additionally, using third-party RPC services generated timeouts and raised security concerns, negatively affecting the overall performance of our testing environment. The reliance on a remote VM limited our control over the hardware, leading to scalability and reliability issues during the testing phase.

To overcome these challenges, we migrated to a local environment configuration using the Intel NUC devices. This transition allowed us to eliminate the limitations of third-party RPC services and gain full control over the hardware, resulting in a more reliable and efficient testing environment. We documented the entire setup process in our GitHub repository, including commands and screenshots to guide other developers in deploying a rollup, divided into two main stages for implementation in the Holesky testnet.

A. Spin up a L1 Node (Holesky Testnet):

• Geth (Execution Layer) setup instructions

• Prysm (Consensus Layer) setup instructions

This stage details the steps to configure an L1 node, starting with acquiring the necessary hardware. The Intel NUC devices provided adequate computing power for installing Linux (Ubuntu) and setting up the Geth and Prysm dependencies. Subsequently, we installed and ran Geth, which forms the base layer of the Ethereum network, followed by installing and initializing Prysm, facilitating the execution of the proof-of-stake consensus mechanism. This resulted in a robust L1 node capable of supporting subsequent rollup deployments.

B. Deploy a L2 rollup from the OP stack

• OPstack setup and deployment instructions

• OPstack Data Visualisation Dashboard setup

Building on the L1 node infrastructure, we documented the process of deploying an L2 rollup using the OP Stack. We began by installing the necessary Optimism dependencies and compiling the source code. Subsequently, we deployed contracts on L1 and initiated the OP-GETH instance, which involved setting up and running key components such as op-geth and op-node. The process culminated in obtaining Holesky ETH on the L2 network and sending test transactions, demonstrating the successful deployment of a rollup in a controlled local environment.

3. OP stack version benchmark

From OPcity repository:

This section presents the results of three test deployments, one in December 2023 and two in June 2024. The analyses show a significant reduction in operational costs for the batcher and proposer from the test deployment with the OP Stack V4.0.0 Canyon in December compared to the deployments with OP Stack V7.0.0 Fjord, conducted in June 2024.

The most notable difference between these versions is the reduction in the total gas fees used by the rollup with V7.0.0 , reducing ~75% of the operation cost, approximately 75% less than operational costs with V4.0.0. Additionally, the June deployments compared the use of calldata methods versus data blobs for registering data in Layer 1, revealing that data blobs consume approximately 60% fewer resources than call data.

Test Deployment 1 (OP stack V4.0.0 / December 2023)

From December 4 to 11, 2023, we conducted an exploratory evaluation of operational cost performance for OP Stack in a testnet environment, focusing on gas expenditure for the batcher and proposer. This testing phase was strategically scheduled before updates Dencun, Ecotone, and Fjord to prepare for implementing advanced features such as span batches, data blobs, and fault proofs, that were not yet implemented. During the 7-day deployment of the OP Stack on Testnet Sepolia, the batcher generated significant transactions (~27,000), resulting in substantial gas expenditure (~9.5 ETH) despite the absence of additional user or contract interactions

We have used a Virtual Machine in Google Cloud to deploy an OP rollup with the following configuration:

Machine type: e2-standard-2 Cores: 2 vCPU Memory: 8 GB

After connecting to a Sepolia node through Alchemy, installing dependencies, and building the Optimism Monorepo and op-geth, we created the four accounts that manage the rollup operation:

• The Admin (0x…92D5) account can upgrade contracts.

• The Batcher(0x…898ce) account, which publishes Sequencer transaction data to L1.

• The Proposer(0x…B561) account which publishes L2 transaction results to L1.

• The Sequencer(0x…3868) account signs blocks on the p2p network.

Additionally, a Bridge contract was created to transfer funds to the rollup.

Key Findings

During this initial deployment, we faced several limitations related to operational costs for the batcher and proposer and restrictions stemming from RPC service usage. These challenges became evident during a 7-day deployment of OP Stack rollup on the Testnet Sepolia, where the batcher generated significant transactions (~27,000) with considerable gas consumption (~9.5 ETH). As mentioned earlier, this activity was exclusively the default operation of the rollup, without additional user or contract interactions. This expenditure was attributed to limitations in RPC calls from our provider (Alchemy), causing empty blockchain chains from sequencer to batcher increasing transaction rates and gas expenditure. This behavior highlighted the need to address scalability within OP Stack to support efficiently high performance and diverse user interactions.

Comparing the data with the OP Sepolia batcher, we observed a significant difference in transaction numbers during similar dates (~11,000, equivalent to 40% of the 7-day reference period) but not in higher gas consumption (~12 ETH). This is attributable to testnet usage by a significant number of real users and contracts; however, this circumstance could jeopardize Superchain's vision, which aims to sustain multiple derived chains from OP Stack that may not necessarily have similar user volumes or performance—especially those intended for non-DeFi applications that do not rely on sequencer income for profitability.

Test Deployment 2 (OP stack V7.0.0 - Call Data) / June 2024

From OPcity repository:

Following issues detected with using an RPC provider during our first deployment, we decided to set up a local node that would provide a reliable source of RPC calls. This allowed us to observe and measure impacts on transaction numbers and associated gas fees for each one; details of this setup process are outlined in previous sections, just as in the OP City repository.

With our node configured, we deployed a rollup from the OP Stack on Holesky testnet using version 7.0.0 Fjord and calldata method to publish transactions from Batcher and Proposer. This test deployment lasted 20 days following multiple network updates, including the span batches, compatibility of data blobs, and other optimizations that notably impacted the rollup operation cost from the December test. Using the same data posting method from the December test, during the first seven days, the Total Gas Fees used on the default rollup operation transactions were reduced by ~75%, from 10.63 to 2.59 ETH, while the cost per day fell from 1.5 down to 0.37 ETH.

The data from the rollup addresses are available here:

• Sequencer Address

• Batcher Address

• Proposer Address

• Admin Address

Test Deployment 3 (OP stack V7.0.0 - Data Blobs) / June 2024

From OPcity repository:

While the reduction in the Total Gas Fees using Calldata is significant, the implementation of data blobs as a data posting method enables an alternative that can significantly impact the rollup operation cost. To prove it, we deployed a third testnet rollup a week later using the same V7.0.0.0 and data blobs as the data posting method to compare with. By comparing the performance of both configurations, we identified the following:

1. A notable reduction in the number of transactions made by the Batcher and Proposer addresses with around 50% less activity (+100k txn with calldata vs 50k txn with data blobs)

2. ~65% fewer gas fees used by the rollup (2.59 from calldata vs 0.64 ETH from data blobs per 7-days operation and 0.37 vs 0.09 ETH per day, respectively)

The data from the rollup addresses are available here:

• Sequencer address (0x...414E)

• Batcher address (0x...1c84)

• Proposer address (0x...F093)

• Admin address (0x...AABC)

4. Proposed changes to Fault Proofs

Proposed during the OP Governance Season 5 and grant finalist during cycle 22

In addition to benchmarking two versions of the OP Stack, OP City also integrates research on the compatibility of the OP Stack’s Canon Fault Proof Virtual Machine (FPVM) with the opML Multiphase Fault Proof protocol. The objective is to implement a customized Fault Dispute Game that addresses challenges related to data availability in L2 rollups and the computational outcomes of Deep Neural Networks (DNN) from the opML multi-phase. This will be possible through an incentive mechanism for node validators who resolve disputes in both technologies.

Proposed Modifications:

OpML uses a multiphase fraud proof to ensure the accuracy of on-chain machine learning results. This mechanism is similar to the experimental Canon Fault Proofs of the OP Stack. Both technologies utilize a Fault Dispute Game for validators to resolve challenges in a game tree. We aim to expand the merklized data in the OP Stack’s FPVM to include state transitions in the opML Multiphase Dispute Game. By doing so, we pursue a unified framework capable of natively processing machine learning inferences on-chain, enhancing or replacing the current FPVM specifications.

A. State Transition Function Modeling

The FPVM functions as a state transition system where a function f maps a pre-state$Spre$ to a post-state $Spost$ based on an executed instruction: $𝑓(𝑆𝑝𝑟𝑒)→𝑆𝑝𝑜𝑠𝑡$

For integration:

• Proposed Framework Modification: Introduce an additional layer that handles complex decision trees or neural network outputs, which adjusts how the state transitions are computed, especially in handling error states or exceptions.

• Consider a modified state transition $𝑓(𝑆𝑝𝑟𝑒,D)$ function where $D$ represents data or decisions derived from opML processes, impacting the transition to $Spost$.

• Modified Function: $f(Spre,D)→Spost$

• Define a new state component that includes neural network inference results, which influences the transition process, particularly in how exceptions are handled.

B. Memory Management Analysis

Given the detailed memory specifications:

• Heap and Memory Operations: Analyze the implications of integrating a mechanism for handling large datasets required by machine learning models directly within the memory structure of FPVM.

• Suppose $M(S)$ is the memory utilization state function. Introduce *$M'(S, D)$*to handle additional data structures or caching mechanisms to optimize ML data handling.

Memory Function: $M(S) → M(S,D)$

C. Syscalls and I/O Enhancements

The proposed framework could potentially extend the syscall and I/O functionalities to better support ML-driven data processing:

• Extended Syscalls for ML: Introduce new syscalls specific to ML operations, such as data batching or model loading.

• I/O Modeling: Adjust the I/O model to handle larger data streams efficiently, crucial for ML processes. Propose modifications like enhanced buffer management or asynchronous I/O operations.

D. Formal Verification and Error Analysis

Given the complexity of ML integrations and the critical role of fault-proofing:

• Model how errors in the ML phase could propagate through the system, influencing state transitions and memory states.

• Utilize formal methods to verify the correctness of the integrated system under various operational conditions, ensuring that the modifications do not introduce new vulnerabilities.

E. Simulation and Evaluation Metrics

Develop simulations that mimic real-world operational conditions to evaluate the effectiveness of the proposed modifications:

• Create scenarios where traditional and ML-modified FPVMs are subjected to typical and atypical loads, measuring performance metrics like throughput, error rate, and response time.

• Define specific metrics to evaluate improvements or regressions in system behavior due to the integration, such as memory efficiency, fault detection accuracy, and computational overhead.

Additionally, with the implementation of this framework, we aim to provide the necessary infrastructure for on-chain processing of high volumes of public data generated in cities and utilize on-chain models to make ML inferences from those datasets. To protect the privacy of sensitive citizen data, we will explore implementing zkML through ORA's oppAI framework. This extension strategically balances trade-offs between privacy and computational efficiency. By combining the strengths of zkML privacy-preserving techniques with opML efficiency, oppAI enables a hybrid model to optimize both aspects for on-chain AI applications.

Conclusions

OP City, through its research on the OP Stack and the Canon Fault Proofs VM (FPVM), reveals a significant advancement in scalability and efficiency for Layer 2 solutions in the Ethereum ecosystem:

• Comparing versions 4.0.0 and 7.0.0 of the OP Stack has shown improvements in code, new functionalities, and a substantial reduction in transaction costs and gas consumption for both the batcher and proposer.

• The implementation of data blobs in version 7.0.0 demonstrated an additional 65% reduction in operational costs, underscoring the importance of continuous innovation in Optimism’s infrastructure architecture.

• Practical deployment and benchmarking exercises have empirically validated theoretical improvements, identified additional optimization areas, provided concrete data to guide future decisions, and created a set of best practices.

• Integration of Canon Fault Proofs VM with the opML Multiphase Fault Proof protocol opens new possibilities for expanding Layer 2 infrastructure capabilities, such as implementing a customized Fault Dispute Game and exploring zkML through the oppAI framework.

• Proposed modifications, such as introducing additional layers for handling decision trees and memory management analysis, demonstrate a commitment to continuous improvement and adaptability to emerging needs in deep neural networks.

In conclusion, OP City not only demonstrates that as versions of the OP Stack evolve, transaction efficiency improves and operational gas costs decrease, but it also enables optimized management of public data generated in cities. Through the infrastructure provided by this framework, we aim to process large volumes of on-chain data and utilize machine learning models (opML) to make inferences from these datasets. At the same time, citizen privacy will be protected through zkML, offering secure and effective artificial intelligence solutions on-chain.

References

Ethereum and Fault Proofs

[1] Buterin, V. (2015). A Next Generation Smart Contract & Decentralized Application Platform.

[2] Karbasi, A.H., Shahpasand, S. A post-quantum end-to-end encryption over smart contract-based blockchain for defeating man-in-the-middle and interception attacks. Peer-to-Peer Netw. Appl. 13, 1423–1441 (2020).

[3] Werth, J., Hajian Berenjestanaki, M., Barzegar, H. R., El Ioini, N., & Pahl, C. (2023). A review of blockchain platforms based on the scalability, security and decentralization trilemma. Proceedings of the 19th International Conference on Web Information Systems and Technologies (WEBIST 2023).

[4] Buterin, V. (2021). Why sharding is great: demystifying the technical properties.

[5] Buterin, V. (2018). A note on data availability and erasure coding.

[6] Mustafa Al-Bassam, Alberto Sonnino, Vitalik Buterin: Fraud Proofs and Data Availability: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities. CoRRabs/1809.09044 (2018)

[7] Optimism. OP stack Specification.

[8] Conway, KD., So, C., Yu, X., & Wong, K. (2024). opML: Optimistic Machine Learning on Blockchain

OP Stack

[9] Poon, J., & Buterin, V. (2016). Plasma: Scalable Autonomous Smart Contracts.

[10] Buterin, v. (2021) An Incomplete Guide to Rollups.

[11] Optimism documents: Glossary.

[12] Getting started: OP Mainnet.

[13] Optimism Developer Blog. Protocol Development: The Fault Proof System is available for the OP Stack.