Using EtherScan to investigate the real reason why Starknet transaction fees dropped by 99%

In this article, 0xSamo, the author of LXDAO, uses EtherScan flexibly to analyze Starknet’s on-chain core components, optimistic/zk rollup fee structure, and EIP-4844’s blob mechanism. , SHARP system rates were explored, and revealed to everyone the truth behind the Starknet handling fee reduction of 99%: Cancun upgrade to reduce DA handling fees is only an auxiliary reason, the real reason is theStarknet currency issuance Later, the treasury had other sources of income and no longer had to rely on fees to generate income, so it significantly lowered the L2 Gas Price benchmark.

Foreword

EIP-4844 as The biggest upgrade of Ethereum after The Merge has attracted enough attention. The Blob temporary storage space introduced in this upgrade is equivalent to adding a side-mounted carriage to the Ethereum train, providing cheaper DA space without affecting the original operating status of the train.

Layer2 projects such as Optimism, StarkNet, and Arbitrum have all supported EIP-4844 in a short period of time and achieved significant cost reduction effects. The following is the LXDAO treasury For transactions generated when distributing wages to contributors on Optimism, the gas fees before and after EIP-4844 actually differed by 100 times.

But while we were pleasantly surprised, we discovered thatStarkNet, as the representative of ZK Rollup, has also achieved an amazing fee reduction effect. The gas level that used to exceed 1 US dollar has dropped to 0.01 US dollars .

Why can Starknet's handling fees be reduced so much

OP Rollup and ZK Rollup on the first-level DA space Different needs

The two have extremely different dependence on DA space. OP Rollup will package and compress all details of recent transactions, including user signatures and other data, and upload them all to the first-tier network. It does not require too many checking tasks on the first-layer network, and almost all costs are in the DA space of the first-layer network.

In contrast, ZK Rollup has a higher compression rate for on-chain data. For example, it does not need to upload the digital signature of Layer 2 transactions, and only relies on ZK Proof to ensure that the transaction is valid; moreover, ZK Rollup does not need to package all transaction details, but only needs to package the status change results on the chain.

For example, on the second-layer network, 100 users have traded on the USDC/USDT trading pair. After each transaction, the asset contract The balances of USDC and USDT will change. For OP Rollup, the DA data generated behind these trading behaviors is 100 transactions and 400 balance changes of 200 accounts;

And forFor ZK Rollup, a total of 200 changes to the asset contract can be compressed into 2 final state summary changes, greatly reducing the size of DA data.

ZK Rollup verifies the additional Gas consumed by ZKP

Understand After understanding the difference between the two, everyone's first impression may be that the gas fee of ZK Rollup will be relatively low, but students who have practiced it should all know thatBefore EIP-4844, ZK Rollup such as StarkNet and ZkSync, among others, The fee is significantly higher than OP Rollup, especially StarkNet. Because of the use of the STARK algorithm, the size of its zero-knowledge proof is larger, and the transfer fee is often higher than other Layer 2.

(L2 fee table at some point in 2023)

The reason why ZK Rollup did not crush OP Rollup as soon as it went online is simple: although it is good for transactions The data has a higher compression rate, which saves the cost of transmitting data to one layer, but it requires verifying the zero-knowledge proof on one layer of the network, which increases the computational cost.

Blob can only reduce DA fees and does not help much in the calculation part. Compared with OP Rollup, ZK Rollup has fewer benefits on EIP-4844. So it’s hard not to be surprised when we see that Starknet has quickly gone from a state of extremely expensive handling fees to a cent-level gas fee.

Explore Starknet’s fee composition

ZK Rollup often More complex than OP Rollup. The picture below is the transaction record generated when the Optimism sorter publishes DA data to the first-layer network. Anyone can understand why OP’s transaction fees dropped by two orders of magnitude after the implementation of EIP-4844.

But when investigating the source of Starknet handling fees, the author of this article experienced considerable difficulties, because the interaction between different components of Starknet is more complex. Let us retrace this entire process.

The disappearing layer of DA

Because of exploration Based on the experience of Optimism's fee structure, we naturally thought that just find the contract address where Starknet submits data to the main network. This kind of key contract must be on Etherscan's Gas consumption list, and it should be It’s not hard to find, such as Scroll, which has not yet adapted to EIP-4844, and its contract is still at the top of the gas consumption list.

When we search for Starknet keywords, we will find three related components: Operator, Core Contract, and Memory Page Fact Registry on EtherScan. However, the third contract that seems to be related to DA stopped using it nearly two years ago. .

Currently we can see that Starkent's Operator is constantly interacting with the Core Contract and constantly calling the "Update State" function.

If we turn to the on-chain records before and after the Cancun upgrade is activated, we will find that the Operator's "Update State" behavior has indeed undergone detailed changes. First, the function name is changed to "UpdateStateKzgDA". Secondly, the old state update function will be Core Contract transmits ProgramOutput, onchainDataHash and onchainDataSize, while the new version of the function uploads ProgramOutput and KzgProof.

The KzgProof here, commonly known as KZG Proof, plays a role similar to the datahash of the Blob and has a corresponding relationship with the data stored in the Blob. It is worth noting that the new version of the status update function consumes more gas than the old version. So the question is, why can Starknet reduce the handling fee so low? What is the reason?

For more information, please refer to the Layer2 popular science website MyFirstLayer2 under LXDAO:

https://layer2.myfirst.io/zh#3.3-optimistic-rollup

< strong>Analysis after the first failure

Although the first exploration was not successful, we can still get some inferences and conjectures. Friends who have watched MyFirstLayer2 must know that the core problem of Rollup is the DA problem (data availability), and they all upload key data to the main network to solve the data availability problem. In this way, all Everyone can easily access the data they need to obtain.

1. Let’s look back. OP Rollup simply and crudely compresses and summarizes all transaction instructions, packages and uploads them. To the first-tier network, others can download the compressed data, then decompress it, and replay each transaction to learn about the status changes of the second-tier network.

3. ZK Rollup does not need to upload complete transaction details, only State Diff needs to be uploaded (the amount of state change before and after each batch is executed). ZKRollup uses ZKP to ensure that the State Diff is valid and correct. Others can directly overlay the State Diff on Prev_GlobalState to know the latest status of the second-layer network.

We all know that the data inBlob is just a string of garbled binary text, and the first-layer network only ensures that the Blob data will not be tampered with by some malicious nodes after it is uploaded, but It is not responsible for verifying the content of these data. Of course, the smart contract deployed at the first layer cannot directly read the content of the Blob.

Therefore, if ZK Proof is still verified by one layer, then ZK Proof must not be placed in the Blob, so we can judge that Starknet can have such a significant The fee reduction effect has little to do with ZKP. It must be due to the change in the storage location of State diff.

The following task is obviously to confirm, where did Starknet put the State diff? Where was it placed in the past? Is it placed in the blob now?

In addition, only one StateRoot can be found in the input parameters of the UpdateState function, which makes people wonder whether Starknet uploaded the data that should have been directly uploaded to the main network. Instead, it is sent to its own off-chain DAC (Data Availability Committee). If this is really the case, then Starknet’s previous high charges are completely unreasonable and can only be explained as...

SHARP system

Fortunately, after discussing with @0xYandhii, I was enlightened. Before the launch of the universal mainnet, Starknet’s first product was actually StarkEX, including decentralization. Chemical derivatives exchange dYdX is also a product of that period.

After the main network went online, the original product was not abandoned, but instead shared a validator contract with the main network. That is SHARP: Shared Proving and Verifying System, and then we found related contracts such as SHARP Blockchain Writer and SHARP Verifier.

Open the block browser to query related transactions, you can find thatSHARP Blockchain Writer has performed the following 4 types of operations:

1. 1. VerifyMerkle:Verify Merkle tree

3. 2. VerifyFRI: Used to ensure that the submitted data or calculation results follow specific rules without revealing the original image of the data.

5. 3. Register Continuous Memory Page:It seems to be a function called when writing data to a layer of network.

7. 4. Verify Proof And Register:

   strong>It can be called once every ten minutes at the fastest time, or one or two hours at the slowest time. It should be that after Starknet has accumulated a large enough number of transactions, it will uniformly verify the validity of the ZKP of these transactions.

It is not difficult to see that 1, 2, and 4 are functions related to ZKProof, and the third function is obviously directed towards The step of writing data to the layer network is the function most likely related to State diff upload.

We speculate that the calling fees of functions 1, 2, and 4 did not change significantly before and after the Blob upgrade, while thethird function The cost of use should be significantly reduced, which can explain why Starknet’s fee reduction effect is so significant.

So the author continued to browse the block browser, and the second to last old version and the first to last version before EIP-4844 have been upgraded. Take one verification cycle for each of the three periods of the latest version, and count the Gas consumed by each of the four functions each time they are called.

The results are as follows, which makes people scratch their heads.

The cost of the third function related to data release has dropped by half, but judging from its proportion of the cost in the entire round of ZK Proof verification process, this level of DA cost reduction cannot prove our previous Hypotheses proposed.

The exploration has almost reached its end at this point. The author feels like a physicist sitting in front of the large particle collider in the three-body world. Every brain cell is screaming: This doesn't make sense! I even went to the Starknet community to post a post asking, but perhaps because the question is too complicated, no one in the English community responded.

SHARP system GasUsed exploration

At this point, we are left The last little trick is that in the previously downloaded transaction data csv, there is only the ETH consumed by gas fees, and there is no information such as GasPrice and Gaslimit, so the impact of gas unit price fluctuations on the statistical results cannot be ruled out. So the author wrote a script to count the GasUsed (the used part of the Gaslimit) actually consumed by each transaction involved.

This time we finally found the clue. You can see thatBefore the Cancun upgrade, the function called Register Continuous Memory Page would be triggered twice every time DA data was uploaded, one time consuming 50,000 gas, and the other time consuming 300,000 gas.

After the Cancun upgrade, almost all transactions that call the Register Continuous Memory Page function only consume 50,000 gas.

We took too few samples before. After that upgrade, it was the period when the gas fee of the main network skyrocketed. This affected our statistical results and led us to believe that the cost of calling the Register Continuous Memory Page function was at a high level. Nothing changed before or after the Kun upgrade, and when we adopted the statistics more broadly, we quickly discovered the problem.

According to this idea, we reorganized the GasUsed data of three moments, which is much more reasonable this time. At this point, it can be confirmed that the Register Continuous Memory Page function related to DA data upload has indeed significantly reduced the handling fee after the Cancun upgrade. This should be the original step of storing State Diff, and the Cancun upgrade Finally, the DA data is transferred to the Blob.

Following up, we found the product structure diagram of Starknet on the L2beat website. We can find that State diff is indeed stored on the Ethereum chain through the above function.

(Picture source: L2BEAT)

Finally, we calculate based on the number of GasUsed (based on the current randomly selected smaller sample Based on a broad estimate based on volume), we came to the conclusion: After Starknet’s upgrade in Cancun, the DA fee has changed by about 4 to 10 times, which is slightly less than an order of magnitude.

This is also in line with our initial guess: After the EIP-4844 upgrade, the benefits obtained by ZK Rollup are not as good as OP Rollup many.

Summary

After the above exploration, We finally figured out the reason for the sharp drop in Starnet's handling fees, and the conclusion is still a bit intriguing.

DA fees have dropped significantly, but this cannot explain the drop of two orders of magnitude

It is clear that Starnet previously uploaded the state change data contained in each Batch directly to the first-layer network. Now it puts this part of the data in the Blob, so it can be used in the DA data part. In terms of handling fees, the fee reduction effect is slightly less than an order of magnitude.

But how to explain the 99% drop in Starknet fees? Simply relying on DA fee reduction is obviously not enough. The only reasonable explanation is that before the upgrade in Cancun, Starknet did charge too many fees from users. Before STRK is issued, all activities and community incentives of Starknet require funds. In addition to burning investors’ money, a scissors gap is set between the ETH charged to users and the actual ETH consumed. This may be the reason why Starknet maintains One of the methods of operation is why Starknet’s gas fee was so high before.

Now that the STRK token issuance has brought enough funds to Starknet, it is time to return Gas to a reasonable level and take advantage of the Cancun upgrade. When the sandbags on the feet are removed together, the fee reduction effect really surprised many people.

Rollup historical data loss problem

OP Rollup is being upgraded After that, after transferring the data originally stored in the transaction Calldata to the temporary storage area of ​​​​Blob, a little trustlessness is actually sacrificed.

Previously, the data in the Calldata space was permanently stored, which meant that anyone could download enough historical data from the Ethereum main network to verify and Synchronize the current status of OPR.

However, after the Cancun upgrade, Blob data is set to expire and be eliminated. If no entity in the entire network saves past Blob data, then the history of OPR Transaction records may be lost.

Although the latest Layer 2 network status can still be protected - because the Blob storage period exceeds the OP's 7-14 day challenge period, each Blob Before it expires, its corresponding second-level status is still credible, and the latest ten days of transaction records maintain the security of OPR on a rolling basis.

If ZK Rollup wants to enjoy the benefits brought by Blob, it also needs to transfer important second-layer status data from the Calldata space to the Blob space. This means that after a period of time, we can no longer rely on the data provided by the first-tier network to replay the status of the second-tier network as before.

Perhaps this will become the norm. In the future, all second-layer networks will rely on Blob to maintain the latest state of security, and each L2 also needs to think of its own. This method solves the problem of storing historical transaction data and achieves a better balance between security and efficiency.

The integration trend of OP and ZK

Past, no. The first generation of OP Rollup was the first to go online, but the first generation of ZK Rollup did not bring more competitive gas fees after it went online. With the subsequent modularization trend brought by OP Stack and Polygon SDK, OP Stack even plans to introduce ZK technology in the future to reduce the challenge period.

This undoubtedly points to the fact that the two technical routes of OP and ZK are not life-and-death competition. They will learn from each other and have a tendency to integrate. However, this is One time the "noble" ZK learned from the "simple and crude" OP.

It is hard to imagine that the technology of the second-layer network has evolved to such an extent in just two or three years. Perhaps this is the charm of the blockchain world.

References:

[1]FeedTheFed. Data availability with EIP4844[EB/OL]. (2024-02-11)[2024-04-16]   https://community.starknet.io/t/data-availability-with-eip4844/113065.h

[2] L2BEAT research team. Starknet[EB/OL]. [2024-04-16].   https: //l2beat.com/scaling/projects/starknet?selectedChart=activity#contracts.