In-depth analysis of how Optimism realizes US grading fees
Translator's Note: In January, Optimism tweeted to update its Rollup fixed overhead (Fixed overhead) from 2750 gas to 2100 gas, and dynamic overhead (Fee Scalar) from 1.5 times to 1.24 times; in March, an update was released, saying that the Perform a system-level compression on the calldata of the transaction. This series of adjustments and updates will bring great changes to Optimism's expenses, which in turn will affect users' transaction fees (transaction fees will be reduced by an average of 30%-40%). What role do these fee components play in the operation of Optimism? This article first introduces the components of Optimism overhead as a whole, and then analyzes how adjustments to these components affect users' transaction fees.
Introducing Optimism Transaction Fees
To understand how we reduce overhead, we first need to understand the components of Optimism transaction fees:1) Rollup overhead: The cost of "rollup" (packaging) the transaction into the transaction batch and then submit it to the Ethereum mainnet (L1);2) L2 execution overhead: The overhead of running transactions on Optimism (L2). For an in-depth look, read"How Optimism Works"document.
1) Rollup overhead
In Optimism, users no longer need to pay the L1 gas fee for the entire transaction execution, but only need to pay the part of the fee generated by submitting your transaction data to L1 through the transaction batch. This fee includes the actual Calldata (input data) of your transaction and the fixed overhead (Fixed Overhead), which is the additional processing fee required to add a transaction to a larger transaction batch.
Optimism also adds a dynamic overhead (Fee Scalar, cost proportional coefficient) as an additional fee. This gives us some extra funds to use as a buffer in case the L1 price rises rapidly, and the excess funds to promote the development of public goods. (This is promised in the Optimism PBC article on "Retrospective Public Goods Fundraising", and also read our recap article on the first round of fundraising)
Calldata overhead and L1 gas price are determined by Ethereum L1,But Fixed Overhead and Fee Scalar are "fancy numbers" that can be adjusted by Optimism.
"L1 gas fee" represents these rollup costs:
Layer 1 Gas Fee =Fee Scalar * L1 Gas Price * (Calldata + Fixed Overhead)
At present, the rollup overhead accounts for about 99.6% of a transaction fee in Optimism, so we can greatly reduce the transaction fee by optimizing this part.
2) L2 execution overhead
A transaction on Optimism uses the same amount of gas as an equivalent transaction on Ethereum; however, the standard overhead of gas on Optimism is only 0.001 gwei, which is many times cheaper than L1. This gas price increases slightly during periods of high usage, but averages only 0.4% of total transaction fees.
"L2 gas fee" represents execution overhead:
Layer 2 Gas Fee = L2 Gas Price * L2 Gas Used
Transaction Fee Savings
Adding the rollup overhead and the L2 execution overhead, we get the total transaction fee. For simple transactions (such as ETH transfers), the cost on Optimism is about 5 times cheaper than Ethereum, but for more complex interactions (such as a perpetual swap transaction or option transaction), Optimism can outperform Ethereum L1 directly. Over 200 times cheaper.
Discover our new fee parameters
Before we lowered the fee, the fixed overhead parameter was set at 2750 gas per transaction, and the fee scaling factor was set at 1.5x. Afterwards some adjustments were made to both of them:
1. Lower overhead structure: Since Optimism upgraded the EVM Equivalence (EVM Equivalence) on November 11 last year, less gas is required to submit Optimism transaction batches to L1. The actual overhead has been reduced by almost 25%, from 2750 gas per transaction to 2100 gas per transaction.
2. Lessons from experience: While it is still very early days for Optimism, we have known in the few months since our mainnet launch that we have the ability to reduce the premium from 35% profit margin to 10% profit Ratio (Profit Ratio = [L2 Collection Fee - L1 Commit Overhead]/L2 Collection Fee).
Reduced overhead gas after EVM equivalence upgrade
forecasting and optimization
The next step is to convert the lower overhead into cheaper fees for Optimism users. In order to properly tune the two parameters of Fixed Overhead and Fee Scale Factor, we must understand what affects our fees:
1. Calldata：The amount of Calldata gas is determined by the transaction type (for example, ETH transfer: 0 calldata gas, Chainlink oracle update: 890 gas, Uniswap V3 transaction: 3200 gas). An average transaction uses 1100 calldata gas, but this gas may become higher or lower as different apps on Optimism are widely adopted.
2. Overhead:As the total batch size becomes larger, the overhead of adding a transaction in a batch decreases. This is where L2 scaling differs from L1 scaling: the more transactions there are, the cheaper the transaction fees. The overhead has been reduced from 2750 gas to 2100 gas and will continue to decrease as Optimism usage increases.
3. L1 Gas price:image description
Overhead gas costs that vary based on batch size
Now we know what those factors look like, but once we lower the fee, expect usage to change (eg, more transactions, use more calldata). Therefore, we made some assumptions, proposed a series of scenarios, and then simulated 5000 random days within these ranges (refer to Monte Carlo method, Monte Carlo method). Then we get a simple optimization problem: by adjusting the fixed overhead and the expense ratio coefficient, we get as close as possible to the goal of 10% profit.
The conclusion is: adjust the fixed cost to 2100 gas, and adjust the cost ratio factor to 1.24 times.
Want to know the latest data? Please see our transaction overhead dashboard
Optimistic rollups are rapidly maturing. After we have passed the "0 to 1" stage, the next step is to start "optimization"-the most real optimization is the optimization of overhead. Within the next month, we will deploy the first system-level calldata compression on any production ORU network, achieving a 30-40% cost reduction.
In the future, we have other plans to save more gas fees, and this summer will launch the next major version: Bedrock. This post dives into the details of calldata compression: in particular, how we evaluate various compression algorithms and leverage them to achieve our sub-dollar level charges.
Calldata overview
Optimism uses Ethereum as its data availability layer. This means that every transaction executed on Optimism is stored (but not executed) on Ethereum. Currently we store Optimism transactions in calldata. Multiple L2 transactions are batched into a single binary blob, and this blob (plus other information) is stored in the transaction's data field. To retrieve that data, we need to look back at the transaction body itself (stored in the block). Because Ethereum blocks are preserved, transactions on the Optimism chain can always be reconstructed with the help of Ethereum.
While storing data in blocks is much cheaper than storing data in contract states, perpetuating historical blocks does impose costs on node operators. Therefore, Ethereum charges for calldata. Each 0-byte calldata consumes 4 gas, and each non-zero-byte calldata consumes 16 gas (the 0-byte class accounts for about 40% of the bytes submitted to Optimism).
Although publishing calldata to L1 is an important part of rollup to save gas fees, this fee is also the main cost of transactions for Layer 2 users. In other words, the more we can reduce the amount of data published by calldata, the cheaper the transaction fee of rollup can be. Into Compression: The Art of Reducing Data Size! The following will provide an in-depth analysis of the actual data compression:
Compression overview and results
We studied 22,000 batches (nearly 3 million individual transactions) submitted by Optimism to Ethereum and compressed them in different configurations to determine how best to perform the compression and to experiment with what was possible.
We also looked at various compression algorithms and calculated compression ratios (compressed data size as a percentage of uncompressed size) and estimated savings (assuming 40% of bytes in transactions are 0 bytes).
One configuration option to be aware of is the dictionary. Create a dictionary ahead of time to show algorithmic data chunking commonly used in real-world 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 the compression ratio when compressing single transactions and transaction batches.
Since most fields in Ethereum transactions are random (addresses and function selectors are hashes, signatures should all be random), the compression ratio of a single Ethereum transaction is not high. Because 0 bytes on Ethereum itself saves gas, and the compression algorithm will quickly remove these bytes, the cost savings will not be as much as the compression rate. Therefore, to save the most money, we need to run an advanced algorithm on as much data as possible.
Here is the result of compressing the transaction itself:
As you can see, compressing the single transaction itself only saves us 10-15%. Note that the transaction size reduction is larger than this, but the savings are smaller - this is due to the cheaper 0 bytes discussed above.
The zstandard algorithm with a dictionary performs significantly better because there is something in common between each transaction and the transactions stored in the dictionary. However, zstd still performs better when compressing large amounts of data at once.
The other extreme is to compress all individual transactions at once. This is not possible in practice, but can be studied as an example of the maximum compression ratio.
So, in this example, we can save 10%-50% overhead through compression. But in practice, what can we achieve?
When looking at compressed batches of transactions (hundreds of transactions), they compress significantly better than compressing a single transaction, but slightly lower than compressing all transactions at once. This is because users tend to interact with certain contracts. Also, certain fields such as chain ID and gas price tend to be similar across transactions. Compression algorithms rely on these similarities to do their work.
When comparing different compression algorithms, we found that zlib, zstd, and brotli were the algorithms with the highest compression ratios. We excluded Brotli because it is much slower than zstd or zlib at comparable compression ratios. Generally speaking, the higher the compression ratio of an algorithm (or the higher the compression ratio of an algorithm), the slower the algorithm will run. In common benchmarks, zstd tends to perform better than other compression algorithms across a range of compression speeds/ratio. Note also that Ethereum transactions have different characteristics than the data in the benchmark.
Summarize
Summarize
To sum up: If this historical trend continues, we expect to be able to reduce costs by 30%-40% by introducing the compression method mentioned above.
Batches using the Zlib compression algorithm will be available on Optimism soon.
3/17 launched the Kovan test network 3/24 launched the main network
Zstd-based compression (with dictionaries) is in Optimism's future upgrade roadmap: Bedrock, to be released later this year.
In addition to reducing fees for users through compression, Optimism is also researching how to improve Ethereum's ability to serve as a data availability layer through EIP-4844 and similar methods to further reduce overhead.
Appendix: Algorithm Summary
Original link
