Here’s How Bedrock will Bring Significantly Lower Fees to OP Mainnet

This post explores how the Bedrock upgrade will bring 47% reduction in protocol costs and security fees to Optimism Mainnet.

Here’s How Bedrock will Bring Significantly Lower Fees to OP Mainnet

Lower usage fees is a design principle that shapes a huge portion of the Bedrock release. It led to a complete re-architecting of how transactions are posted to L1 and vice versa.

Despite the outsized impact of this approach, it emerged from a very simple hypothesis: lower fees = good. We want our ecosystem to be the most accessible: the easiest, the most fun, and the most affordable to build and transact on.

In the end, the Bedrock upgrade will bring a 47% reduction in protocol costs and security fees to OP Mainnet. Read on to find out how we achieved this.

Where do Costs Come From?

There are two sources of cost when it comes to sending a transaction on OP Mainnet: the L2 execution fee and the L1 data/security fee.

The L2 execution fee is comparable to how regular transaction fees work on Ethereum, with the added bonus that execution gas prices on OP Mainnet are incredibly low because the network is not as congested the L1.

The L1 data fee occurs because all transactions on OP Mainnet are also published to Ethereum. This step is crucial to the security of OP Mainnet because it means that all of the data needed to sync an OP node is always publicly available on Ethereum. It's what makes OP Mainnet an L2. Users on OP Mainnet have to pay for the cost of submitting their transactions to Ethereum. Because the cost of gas is so expensive on Ethereum, the L1 data fee dominates much of the total cost of a transaction on OP Mainnet.

Identifying Improvements

Early on in Bedrock development, we were able to identify several areas that resulted in unnecessary costs for users. In particular, OP Mainnet’s legacy system was designed in a way that didn’t use L1 data space as efficiently as possible. For example, the pre-Bedrock system for posting data to Ethereum was simply to add as many transactions as possible to a compressed bunch of data that could fill up a single L1 transaction.

To fix this, the logical place to start was to try improving the efficiency of how the large amounts of data posted to Ethereum were compressed. We also identified that reorganizing the way data was sent to L1 from OP Mainnet could maximize the usage of available space for data on L1.

Iterating the Fix

Once we had a rudimentary proof of concept that submitting groups of transactions made up of compressed data moved us closer to our goal, we focused on optimizing this approach.

A key constraint that informed development was the need to split up the body of an L2 block across multiple L1 transactions. If someone submits a large transaction to L2, it probably needs to be split up to fit into L1 Calldata. Further, the algorithm we use to compress data yields a better ratio the more data you feed it. To address this constraint and maximize the compression ratio, we designed a system that takes advantage of these properties.

Batching and Compressing Data

The key building block of this system are batches. A batch is a wire format designed to minimize costs and software complexity for writing to the L1. Traditional blocks are transformed into batches that take away as much extra information as possible, retaining only essential, small amounts of metadata.

Next, lists of L2 transactions called sequencer batches are compressed together into something called a channel. Each channel has a maximum size (initially ~9.5Mb). these channels will be compressed using a compression algorithm before being submitted to L1. Compressing a lot of batches into each channel is where we gain the efficiency of a good compression ratio.

Channels are further broken down into channel frames. This is the piece that helps us address the key constraint defined above. Slicing channels into frames lets us handle very large L2 transactions by sending these transactions to the L1 in parallel, thus packing the corresponding L1 transaction as full as possible.

Compression Algorithm

When selecting a compression algorithm, we considered candidates like zstd, brotli, and LZW, but ultimately chose zlib because it offered good performance for our needs.

Good performance in this case means the right balance of good compression ratio vs. good compression and decompression speed for what we are trying to achieve. This reflects a typical trade-off in choosing compression algorithms: speed/compression ratio performance.

Minimized usage of Ethereum gas

The final piece contributing to fee reduction is that Bedrock removes all execution gas, reducing L1 data fees to the theoretical minimum.  We went into depth on this in our Bedrock Explainer.

Here’s an excerpt:

Bedrock removes all execution gas used by the L1 system from submitting channel data to the L1 in transactions called batcher transactions. All validation logic that was previously happening on smart contracts on the L1 is moved into the block derivation logic. Instead, batcher transactions are sent to a single EOA on Ethereum referred to as the batch inbox address.

Batches are still subject to validity checks (i.e. they have to be encoded correctly), and so are individual transactions within the batch (e.g. signatures have to be valid). Invalid batches and invalid individual transactions within an otherwise valid batch are considered to be discarded and irrelevant to the system.

Cost Reduction by the Numbers

Following the Bedrock upgrade, we are projecting a 47% reduction in protocol costs/security fees comprising 99% in state chain commitments and 20% in batch submission costs.

After the upgrade, we will release an update via the OP Labs Twitter account that includes post-Bedrock data (which will show how accurate our projections were), so keep an eye out for that.

Up Next: Fee Optimization & EIP-4844

We are really proud of the design and solution we built to lower fees for the Bedrock release. It is the result of our team leaning into solid engineering fundamentals and executing cleanly.

Our team is continuing to refine fee optimization to get L2 data fees lower, so be on the lookout for this in releases beyond Bedrock. One specific thing we can do is to time batch submission so that batches are guaranteed to be submitted in a particular window of time (10 minutes, say) and we can time the batches to submit when fees are lowest in those 10 minutes.

Even more exciting, EIP-4844 will soon be included in Ethereum. When that happens, the costs associated with posting data to an L1 will decrease further.

If this post got you excited about building on OP Mainnet, check out our docs to find out how to contribute to the community. Also, our Bedrock Explainer has much more detail on the many amazing features to come with the Bedrock release.