Author: 0xSamo

Reviewed by: Shanni、Tiao

TD;LR

EIP-4844, the biggest upgrade to Ethereum since The Merge, has attracted significant attention throughout the network. This upgrade introduced a temporary storage space called "Blob," which is akin to adding sidecars to a train. It provides cheaper data availability space without affecting the original operating condition of the train (Ethereum).

Layer 2 networks such as Optimism, StarkNet, and Arbitrum all supported EIP-4844 in a short time and achieved significant reductions in fees. For example, transactions made by LXDAO on Optimism to pay contributors saw a 100-fold difference in gas fees before and after the upgrade.

But while this was a pleasant surprise, we discovered that StarkNet, a representative of ZK Rollups, also achieved an astonishing reduction in fees. The cost of gas, which used to easily exceed $1, has now dropped to $0.01.

For those interested in understanding the detailed technical principles, everyone is welcome to join the "MY FIRST LAYER 2" learning program.

Why is StarkNet's Fee Reduction Surprising?

Differences in Storage Space Needs Between OP Rollup and ZK Rollup

This is because OP Rollup and ZK Rollup have different levels of reliance on DA costs (Data Availability: includes storage and distribution services for data to make it accessible to third parties who wish to retrieve it).

• OP Rollup packs and uploads all the details of recent transactions, including user signatures, to the L1 network. It does not require much verification work on the L1 network, and almost all of its costs are related to using the storage space of the L1 network.

• ZK Rollup, in contrast, achieves a higher compression rate for data. For example, it can discard user signature data and rely on zero-knowledge proofs to ensure the legality of transactions; it does not need to package all transaction details but only needs to package and upload changes in the state.

For instance, on a L2 network, if 100 users trade on the USDC/USDT trading pair, each transaction and the balances of USDC and USDT in the Swap contract change with each transaction. For OP Rollup, this means 100 transactions and 400 balance changes across 200 accounts. For ZK Rollup, the difference in user balance changes isn't significant, but for the Swap contract, 200 balance changes can be compressed into just 2 final balance changes, significantly reducing the data volume.

ZK Rollup's Additional Gas Costs for Verifying ZK Proofs

After understanding the differences between OP Rollup and ZK Rollup, the initial impression might be that ZK Rollup would generally have lower gas fees. However, those who have practical experience, such as with StarkNet or ZkSync's ZK Rollups, would know that their costs are often significantly higher than those of OP Rollups. Particularly, StarkNet's STARK technology route results in larger ZK Proof sizes compared to other SNARK-based routes, often placing it at the bottom of the fee rankings for L2 transfers.

The reason ZK Rollup didn't immediately outperform OP Rollup upon launch is straightforward. Although ZK Rollup achieves a higher compression rate for transaction data, saving costs on data transmission to the L1, it requires the verification of zero-knowledge proofs on the L1 network, which adds computational costs.

Blob technology only reduces the cost of storage, not computation. Therefore, the benefits ZK Rollup can gain from EIP-4844 are less significant. Thus, seeing StarkNet progress from being one of the lowest-ranked to matching the top performers is undeniably surprising.

Exploring StarkNet's Costs

It must be noted that the mechanism of ZK Rollup is far more complex than that of OP Rollup. For example, looking at the cost of packing data to the mainnet through the Optimism: Batcher contract before and after upgrades, anyone can fully understand why its transaction fees dropped by two orders of magnitude.

Related Links:

1. Last Batch transaction before the upgrade

2. First new Batch transaction after the upgrade (including Blob costs totaling 0.0011 ETH)

3. Costs for 6 Blobs (totaling 0.00078 ETH)

However, in the process of exploring StarkNet gas costs, the author encountered considerable difficulties and even multiple plot twists. This exploration itself was very enlightening. Let us revisit this journey together through the article.

The Missing L1DA

Given our experience with investigating how Optimism reduced its fees, it seemed natural to try to find the contract through which StarkNet initially submitted data to the mainnet. Such an important contract would surely have once been prominent on the Etherscan gas consumption leaderboard, and therefore should not be hard to find. Scroll, which has not yet adapted Blob, is still prominently at the top, shining brightly.

When we searched using the keyword "StarkNet," we found three relevant contracts: Operator, Core Contract, and Memory Page Fact Registry. However, the third contract, which appears to be related to storage space, has not been used for nearly two years.

Consequently, we could only observe the Operator continuously interacting with the Core Contract, constantly updating the latest state.

Moreover, if we look at the transactions before and after the adaptation of Blob, we find that the Operator's Update State transactions indeed underwent an upgrade. However, these were merely pointing to the hash of another data packet. Even later, the updateStateKzgDA transactions consumed more gas, which cannot explain the reason for StarkNet's reduction in fees.

This later update was simply a KZG polynomial commitment, used to prove that the data in the Blob and its corresponding Batch packet match, and was merely a "state root." This state root corresponds to a "mini-ledger" that records all the states of all contracts on the L network, which, in theory, also exists on the L1 network.

This raises the question: why is there only a root left? Where did the thick mini-ledger go?

Analysis After the First Setback

Although the first exploration wasn't very successful, we can still draw some inferences and guesses. Friends who have read MyFirstLayer2 must know that the core issue discussed by Rollups is the DA (Data Availability) problem, and their adopted solution is to upload the key data to the mainnet to resolve the issue of data availability, making it easy for everyone to access the required data.

1. OP Rollup simply compresses and uploads every transaction to the L1 network, allowing others to decompress and replay each transaction to obtain a complete view of the L's mini-ledger, to verify whether the transactions have been executed correctly.

2. ZK Rollup, on the other hand, does not need to upload all the transaction details, but only needs to upload the State Diff (the part of each batch that has changed state), with zero-knowledge proofs ensuring that all transactions have been correctly executed on the L2 Others can then recreate the full picture of the L2's mini-ledger by replaying the results of multiple state changes.

Moreover, we know that the data in Blob is just a string of binary text to the L1, which only protects the accuracy of the data in Blob without verifying its legality. The smart contracts of the L1 cannot read and verify the content in Blob, so if the L1 is still to verify the ZK Proof, then the ZK Proof itself certainly cannot be placed in Blob. Therefore, if StarkNet is able to reduce fees to some extent, it must be by placing each batch's State diff into Blob.

So, our next task is clearly to figure out where exactly StarkNet has placed the State diff. Where it was placed in the past and whether it is indeed placed inside Blob now.

Additionally, the reality of only finding a state root inevitably leads to speculation: could it be that StarkNet had quietly shifted the responsibility of uploading state change data to the mainnet to its own DAC (Data Availability Committee) a long time ago? If that's really the case, then the previous high fees charged by StarkNet would be completely unjustifiable, only to be explained as...

SHARP System

Fortunately, after discussing with another researcher colleague (X@0xYandhii), a new dawn arrived. Before the general mainnet launch of StarkNet, the first product was actually StarkEX, which includes the decentralized derivatives exchange DYDX, also a product of that period. After the mainnet launch, the original products were not abandoned but shared a verification system with the mainnet.

This system is known as SHARP: Shared Proving and Verifying System. We then found related contracts like SHARP Blockchain Writer and Starkware: SHARP Verifier.

By looking up related transactions on the blockchain explorer, you can see that the SHARP Blockchain Writer performs the following four types of operations:

1. Verify Merkle: Verify the Merkle tree

2. Verify FRI: Fast Reed-Solomon Interactive Oracle Proof of Proximity, used to ensure that submitted data or computation results follow specific rules or constraints without revealing the content of the data itself.

3. Register Continuous Memory Page: More than a hundred uploads in one cycle, registering continuous memory space, seemingly part of writing data to a layer-one network.

4. Verify Proof And Register: Once a cycle, as quick as ten minutes, and as slow as an hour or two, probably accumulating enough transactions for a batch verification.

It's apparent that steps 1, 2, and 4 are related to zero-knowledge proofs, while step 3, registering memory space, is clearly a step in writing data to a layer-one network, and is the most likely place to store State diffs.

It's reasonable to speculate that the costs of these three verification steps did not change significantly before and after the Blob upgrade, while the cost of step 3 could explain the two orders of magnitude in fee reduction experienced by StarkNet.

Thus, the author continued to review the blockchain explorer, taking a verification cycle from the penultimate old version before EIP-4844, the last old version, and the latest upgraded version, to analyze how gas consumption varied across these four steps.

The results were puzzling.

The cost of memory has dropped by half, but in terms of its proportion of the total costs during a full round of ZK Proof verification, this decline in DA doesn't explain anything.

At this point, my exploration nearly reached a dead end. I felt like a physicist sitting in front of a large particle collider in the Three-Body Problem, every brain cell screaming: This doesn't make sense! I even posted a question in the StarkNet community, but perhaps because the issue was too complex, there was no response from the English-speaking community.

SHARP System GasUsed Exploration

Thus, we are left with one last small trick. The transaction data csv file I downloaded earlier only contained information on the ETH cost of gas used, without any details like Gaslimit, making it impossible to exclude the impact of fluctuations in the unit price of gas. Therefore, I wrote a script to calculate the actual GasUsed (the portion used from the Gaslimit) for each transaction involved.

Finally, dawn breaks! It can be seen that before the upgrade, transactions for registering memory space were actually sent in pairs: one transaction used a minimal 50,000 gas, while the other typically used around 300,000 Gas.

After the upgrade, almost all transactions for registering memory space became low-cost transactions consuming only 50,000 gas.

The strange conclusion from last time is likely due to our having too few samples. It just so happened that the verification cycle after that upgrade coincided with a period of sharp increases in mainnet gas prices, causing the many Register Continuous Memory Page transactions, which lasted a longer time, to consume more gas, thus skewing the statistical results.

Following this line of reasoning, we reorganized the GasUsed data for three different moments, and this time the results made much more sense. From this, we can confirm that the size of the Memory Page indeed significantly reduced after the upgrade. This should be the location where the State Diff data, representing changes in state, is stored, and after the upgrade, this data was transferred to the Blob.

Furthermore, we found StarkNet's technical diagram on l2beat.com, which confirmed, as we suspected, that the State Diff is indeed stored in the Memory Page.

Thus, in the end, based on the quantity of GasUsed (estimated broadly with the current randomly selected smaller sample size), the actual cost for StarkNet's L1DA could be reduced by about 4 to 10 times, which is slightly less than an order of magnitude. This is also consistent with theoretical deductions: in the EIP-4844 upgrade, ZK Rollups do not benefit as much as OP Rollups.

Summary

Through the explorations outlined above, we have finally clarified the reasons and extent of the cost reductions for StarNet, and the conclusions are somewhat intriguing.

Significant Reduction in L1DA Costs, But Not Enough to Explain Two Orders of Magnitude

It is clear that previously, StarNet wrote each batch of state change data into a layer-one network, but now this data is stored in the Blob. Therefore, a reduction in costs of just under an order of magnitude is achievable in the behavior of registering memory space.

However, the idea that StarkNet, from being one of the worst in terms of costs, has achieved a cost reduction on par with the top OP Rollups, and even surpassed all OP Rollups in terms of relative progress, is clearly impossible.

The only reasonable explanation is that previously, they were indeed "greedy" in charging too high. Before the issuance of the STRK token, all of StarkNet's development and community incentives needed funding. Besides burning investors' money, setting a higher L2 to L1 gas price difference might have been one of their ways to sustain development, which led to the previously embarrassing situation with StarNet's Gas costs.

Now, with the issuance of STRK tokens providing them with sufficient liquidity and ecosystem incentives, it is time to bring gas prices back to a reasonable level. Taking advantage of this Blob upgrade to shed the sandbags tied to their feet, the cost reduction effect displayed has indeed dazzled many.

The OP-ization of ZK

After the upgrade, OP Rollups, which moved the data originally stored in Ethereum's mainnet Calldata to a temporary storage area, sacrificed a bit of security.

Previously, data in Calldata space was permanently stored, meaning anyone could retrieve enough data from the Ethereum mainnet to recreate the current state of all transactions on OP L2.

However, after the upgrade, Blob data will expire. If no entity in the network saves past Blob data, the historical transaction records of OP L2 could be lost. Although the current latest state of the L2 is still protected—because the lifespan of a Blob exceeds the 7-14 day challenge period of OP, each Blob is trustworthy until just before it expires, maintaining the security of OP L2 with a rolling record of the latest transactions.

If ZK Rollups want to enjoy the benefits brought by Blob, they also need to move important L2 state data from the permanent Calldata space to Blob space. This means that after a while, we can no longer rely on data provided by the L1 to replay the L's state as before.

This may become a new norm where all L2 networks rely on Blob to maintain the security of the latest state, and each L2 must find its own way to ensure the availability of historical transaction data, thus achieving a better balance between security and efficiency.

The Convergence Trend Between OP and ZK

In the past, the first generation of OP Rollups was launched first, and the first generation of ZK Rollups did not bring more competitive gas costs upon launch. Subsequent trends of modularity brought by OP Stack and Polygon SDK, and OP Stack's plan to introduce ZK technology in the future to reduce the challenge period, all point to one fact: The technological paths of OP and ZK are not in a life-or-death competition. They will learn from each other and tend towards convergence, albeit this time it's the "noble" ZK learning from the "brutally simple" OP.

It's hard to imagine how the technology of L2 networks has evolved to such an extent in just a few short years. Perhaps this is the charm of the blockchain world.

Reference Materials:

[1] Data availability with EIP4844

[2] l2beat.com