Flash Depth Data

Search Extension

How does Optimism achieve a tiered handling fee

2022-03-12 21:05

Read this article in 21 Minutes

This article starts with an overview of the components of Optimism spending and then looks at how adjustments to these components affect transaction fees for users.

Slashing Fees By 30% The Road to Sub-Dollar Transactions Part 1, 2: Slashing Fees by 30%

How Optimistic PBC is

ETH Chinese wechat official account

In January, Fixed overhead for a Rollup update decreased from 2750 gas to 2100 gas, and Fee Scalar dropped from 1.5x to 1.24x. In March, it released an update that said it would perform a system-level compression of calldata for transactions. This series of adjustments and updates will significantly change the cost of Optimism, which in turn will affect transaction fees (by an average of 30% to 40%). What is the role of these elements in how Optimism operates? This article starts with an overview of the components of Optimism spending and then looks at how adjustments to these components affect transaction fees for users.

How often does a transaction cost an introduction

To understand how we reduce our spending, we need to understand the components of a Optimism transaction fee.A Rollup overhead: The cost of "rolling up" transactions into the transaction Batch and then submitting them to the Ethereum main network (L1); 2) L2 Execution overhead: The cost of running transactions on Optimism (L2). For an in-depth study, read the "How Optimism Works" document.

1) a Rollup overhead

In Optimism, users no longer need to pay L1 gas for the entire transaction execution, but only for the part of the transaction submitted to L1 through the transaction Batch. This fee includes the actual Calldata (input data) for your transaction and the cost of Fixed Overhead, which is the additional processing cost of adding a transaction to a larger batch of transactions.

Optimism also adds a dynamic cost (Fee Scalar, the cost ratio coefficient) as an additional cost. This gives us some extra money to act as a cushion in case L1 prices rise quickly, while the extra money is used to promote public goods. (This is promised in Retrospective PBC's Fundraising for Public Goods article, as well as in our series A Review.)

Calldata overhead and L1 gas prices are determined by Ethereum L1, howeverFixed Overhead And Fee Scalar & NBSP; It's a fancy number that can be adjusted by Optimism..

"L1 Gas charges" represent these rollup costs:

Layer 1 Gas Fee =Fee Scalar * L1 Gas Price * (Calldata + Fixed Overhead)

Currently, rollup costs account for about 99.6% of a transaction fee in Optimism, so we can significantly reduce transaction costs by optimizing this.

2) L2 execution overhead

A transaction in Optimism uses the same amount of gas as an equivalent transaction on Ethereum; However, the standard overhead for Gas in Optimism is 0.001 GWEI, which is many times cheaper than L1. This gas price increases slightly during periods of high usage, but on average accounts for only 0.4% of the total transaction fee.

The "L2 gas fee" represents the execution cost:

Layer 2 Gas Fee = L2 Gas Price * L2 Gas Used

Savings in transaction costs

Adding the rollup cost to the L2 execution cost gives us the total transaction cost. For simple transactions (such as ETH transfers), Optimism can be about five times cheaper than Ethereum, but for more complex interactions (such as conducting a perpetual swap or option transaction), Optimism can be more than 200 times cheaper than using Ethereum L1 directly.

Discover our new cost parameters

Before we reduced the fee, the fixed cost parameter was set at 2750 gas per transaction and the fee proportionality factor was set at 1.5 times. Some adjustments were made to both of them:

1. Lower cost structure: As Optimism was upgraded to EVM Equivalence on November 11 last year, less gas was required to submit the Batch of Optimism transactions to L1. Actual overhead decreased by nearly 25%, from 2,750 per transaction to 2,100 gas per transaction.

2. What to learn from experience: Although it's still very early stages of Optimism, in the months since we launched the main network, we've learned that we've been able to reduce our premium from a 35% margin to a 10% margin (margin = [COST of L2 collection - L1 submission cost]/ cost of L2 collection).

The cost gas decreases after EVM isostatic upgrade

Prediction and optimization

The next step is to translate lower overhead into cheaper handling fees for optimistic users. In order to properly adjust the two parameters of fixed expenses and expense proportionality, we must understand what affects our expenses:

1. Calldata: The amount of Calldata gas depends on the type of transaction (e.g. ETH transfer: 0 Calldata Gas, Chainlink Prophet Update: 890 Gas, Uniswap V3 transaction: 3200 gas). The average transaction uses 1100 Calldata gas, but this gas may be higher or lower as different apps in Optimism become widely adopted.

2. overhead: As the size of the total batch increases, the overhead of adding a transaction to a batch decreases. This is where L2 capacity expansion differs from L1 capacity expansion: the more transactions, the cheaper the transaction fee. The overhead has been reduced from 2750 gas to 2100 gas and will continue to decrease as Optimism increases.

3. L1 Gas prices: A transaction will be submitted to L1 a few minutes after it occurs in Optimism, and the L1 gas price will change considerably during this time. If L1 gas price increases, submitter will have to pay more gas than expected; If the price of L1 gas goes down, less gas is paid than expected. During gas price fluctuations, there can be a 10% gap.

The cost of gas that varies according to the batch size

Now we know what these factors look like, but once we reduce fees, expect usage to change (e.g., more transactions, more calldata usage). So, we made some assumptions, proposed a series of scenarios, and then simulated 5000 random days in these ranges (see Monte Carlo method, Monte Carlo method). Then we had a simple optimization problem: get as close to the 10% margin goal as possible by adjusting fixed overhead and expense ratio coefficients.

The conclusion is: set fixed cost to 2100 gas and cost ratio factor to 1.24.

Want to know the latest numbers? Take a look at our transaction overhead.

Optimistic Rollup is rapidly maturing. Once we get past the "0 to 1" phase, it's time to start tuning -- the most realistic tuning is on the overhead side. Within the next month, we will deploy the first system-level Calldata compression on any production-level ORU network, achieving a 30-40% reduction in cost.

We have other plans to save even more gas in the future, with the next major release coming out this summer: Bedrock. This article delved into the details of CallData compression: specifically, how we evaluate the various compression algorithms and leverage them to achieve our sub-dollar billing.

An overview of the Calldata

Optimism uses Ethereum as its data availability layer. This means that every transaction executed in Optimism is stored on Ethereum (but not executed on it). Currently we store the Optimism transactions in callData. Multiple L2 transactions are packaged in batches into a binary BLOB, and the BLOB (plus other information) is stored in the data fields of the transaction. To retrieve that data, we need to look back at the transaction body itself (stored in the block). Because ethereum blocks are preserved, transactions in a Optimism chain can always be reconstructed with Ethereum.

While it is much cheaper to store data in blocks than in contract state, perpetuating historical blocks does impose costs on node runners. So ethereum charges for calldata. Each 0 byte of Calldata consumes 4 gas, and each non-0 byte of calldata consumes 16 gas (0 byte classes account for about 40% of the bytes of transactions submitted to Optimism).

While publishing Calldata to L1 is an important part of rollup's gas savings, it is also a major transaction cost for layer 2 users. In other words, we can reduce the amount of data that CallData publishes, the cheaper rollup transaction fees can be. Step into compression: The Art of Shrinking Data size! Here's an in-depth look at data compression in action:

An overview and results of compression

We looked at Optimism and compressed 22,000 batches (nearly 3 million individual transactions) submitted to Ethereum in different configurations to determine how best to perform compression and to experiment with possible scenarios.

We also looked at various compression algorithms and calculated the compression rate (the compressed data size as a percentage of the uncompressed size) and the estimated cost savings (assuming that 40% of the bytes in the transaction are zero bytes).

One configuration option you need to know about is dictionary. Create a dictionary ahead of time to show blocks of algorithmic data commonly used in real data. Compression algorithms use dictionaries to better compress data, especially when compressing small amounts of data at once. By randomly sampling transactions, we can create a dictionary for Zlib and ZSTD, which can improve compression rates when compressing individual and batch transactions.

Since most fields in ethereum transactions are random (addresses and function selectors are hashes, and the signatures should all be random), the compression rate for individual Ethereum transactions is not high. Since zero bytes on Ethereum are inherently gas efficient, and the compression algorithm quickly removes those bytes, the savings are not as large as the compression rate. Therefore, to save the most money, we need to run an advanced algorithm on as much data as possible.

Here's what happens when you compress the transaction itself:

As you can see, squeezing a single transaction by itself only saves us 10-15%. Note that the reduction in transaction size is larger than this, but the savings are smaller -- this is due to the cheaper 0 bytes discussed above.

The ZStandard algorithm with the dictionary performs significantly better because each transaction has something in common with the transaction stored in the dictionary. However, ZSTD still performs better when compressing large amounts of data at once.

At the other extreme is to compress all single transactions at once. This is impossible to achieve in practice, but can be studied as an example of maximum compression ratios.

So, in this example, we can save 10-50% by compression. But what can we achieve in practice?

When looking at the compression batch of transactions (hundreds of transactions), their compression rate is significantly higher than that of a single transaction, but slightly lower than that of all transactions at once. This is because users tend to interact with certain contracts. In addition, certain fields, such as chain ID and gas price, tend to be similar in transactions. Compression algorithms rely on these similarities to do their job.

When comparing different compression algorithms, we find that Zlib, ZSTD and Brotli are the algorithms with the highest compression rate. We excluded Brotli because it is much slower than ZSTD or Zlib at similar compression rates. In general, the higher the compression rate of an algorithm (or the higher the compression rate set for an algorithm), the slower the algorithm will run. In common benchmarking, ZSTD tends to perform better than other compression algorithms after comparing a range of compression speeds/rates. Also note that Ethereum transactions have different characteristics than the data in the benchmark.

Zlib is very close to ZSTD, and we will be releasing Zlib compression (without dictionaries) in the near future because it has good results, speed and usability in different programming languages. In the long term, we expect ZSTD to help achieve the highest possible compression rate and lowest possible user fees.

conclusion

To sum up: If this historical trend continues, we expect to be able to reduce costs by 30-40% by introducing the compression method described above.

Batch using the Zlib compression algorithm will soon be applied on Optimism.

The Kovan test network was launched on 3/17 and the main network was launched on 3/24

Zstd-based compression (with dictionary) is in Optimism's future upgrade route planning: Bedrock, to be released later this year.

In addition to reducing user costs through compression, Optimism is also looking at ways to improve Ethereum's capabilities as a data availability layer through IP-4844 and similar approaches to further reduce overhead.