StarkNet reduces fees 100 times after EIP-4844, but things are not that simple

Author: 0xSamo; Source: LXDAO

01 Preface

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

Layer 2 networks 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 LXDAO In the transaction where the treasury paid wages to contributors on Optimism, the gas fees before and after were actually 100 times different.

But while we were pleasantly surprised, we discovered that StarkNet, as a representative of ZK Rollup, has also achieved an amazing cost reduction effect. From the previous level of gas consumption that easily exceeded 1$, it has also dropped to 0.01$.

If you want to know more detailed technical principles, you are welcome to enter MyFirstLayer2 to learn.

02 Why is StarkNet’s fee reduction surprising?

The difference in one-level storage space requirements between OP Rollup and ZK Rollup

Because OP Rollup and ZK Rollup have different dependence on DA fees (Data Availability: data availability, including data storage and distribution services, so that third parties can obtain the data they want to obtain).

OP Rollup will package and compress all details of recent transactions, including user signatures and other information, and upload them to the first-tier network. It does not require too many verification tasks on the first-tier network, and almost all costs are in the storage space of the first-tier network.

ZK Rollup, in contrast, has a higher compression rate for data. For example, it can abandon user signature data and rely on zero-knowledge proof to ensure that transactions are legal; and it does not need to package all transaction details, only the changes in status are packaged and uploaded.

For example, on the second-layer network, 100 users have traded on the USDC / USDT trading pair. Each transaction user and the Swap contract have Both USDC and USDC balances will change. For OP Rollup, it is 100 transactions and 400 balance changes of 200 accounts; for ZK Rollup, there is not much difference involving changes in user balances, but for the Swap contract, its USDC and USDT balances A total of 200 changes can be compressed into 2 changes in the final balance, greatly reducing the data volume.

ZK Rollup verifies the extra Gas consumed by ZK Proof

After understanding the difference between the two, your first impression may be that the gas fee of ZK Rollup is generally lower. However, students who have practiced it should all know that the cost of L2 of ZK Rollup such as StarkNet and ZkSync is often significantly higher. It is higher than OP Rollup, especially StarkNet's STARK technology route, which is larger than the ZK Proof of other SNARK routes, and is often at the bottom of the rankings of L2 transfer fees.

Each L2 fee table at a certain time in 2023

The reason why ZK Rollup did not beat OP Rollup to the ground as soon as it went online is very simple. Although it has a higher compression rate for transaction data and saves the cost of transmitting data to a layer, it needs to verify the legitimacy of the zero-knowledge proof on a layer of network, which increases the cost of calculation.

Blob can only reduce the cost of the storage part, but does not help the calculation part. Therefore, the benefits that ZK Rollup can obtain from EIP-4844 are more There are few, so it's hard not to be surprised to see StarkNet progress from the bottom of the "underachievers" to the same level as the first and second place in the class.

03 Exploration of StarkNet Fees

I have to say that the mechanism of ZK Rollup is far more complicated than that of OP Rollup. For example, through the Optimism: Batcher contract, in terms of the cost of packaging data to the main network before and after the upgrade, anyone can fully understand why its transaction fees have dropped. Two orders of magnitude.

Learn more:

One final touch before upgrading Batch:

https://etherscan.io/tx/0x8d8a21aeb64a62c66bc1848c2f37c4ca266edc5d122dd287270bc6aa2c24f445

https://etherscan.io/tx/0xa3e36193ab5ca4e6e98848640b1896def4c419ce203e7bd8e876dd2d5eb77e6c

Fee for 6 blobs (total 0.00078 ETH):

https://blobscan.com/tx/0xaec6d2e65705632f869c02b9baf063822153e058c0da75723733b78b99242f35

However, in the process of exploring the cost of StarkNet Gas, the author experienced considerable difficulties and even encountered multiple plot reversals. This The process of exploration itself is also very enlightening, let us review it together with the article.

The disappeared L1DA

Because of the exploration of Optimism Based on Fei Mi’s experience, we naturally thought that all we need to do is find the contract in which StarkNet submitted data to the main network. This important contract must have been on Etherscan’s Gas consumption list at one time, and it should not be difficult to find. Scroll, which has not yet been adapted to Blob, is still among the best and stands at the dazzling top.

When we search for StarkNet keywords, we will find 3 related contracts: Operator, Core Contract, and Memory Page Fact Registry. However, the third contract that seems to be related to storage space has been discontinued nearly two years ago. .

So we can only see that the Operator is constantly interacting with the Core Contract and constantly updating the latest status.

And if we turn to the front and back of the adaptation blob, we find that the Operator's Update State transaction has indeed been upgraded, but it is just a hash pointing to another data packet. Even the later updateStateKzgDA consumes more Gas, which cannot explain the reason for StarkNet's fee reduction at all.

This later update is just a KZG polynomial commitment, used to prove that the data in the Blob and its corresponding Batch The data packet is corresponding and is just a "State Root". This state root corresponds to the "small ledger" that records all the states of all contracts on the second-tier network. This small ledger theoretically also exists on the first-tier network.

Then the question is, why is there only one root left? Where did that thick little ledger go?

Analysis after the first failure

Although the first An exploration was less successful, but we were still able to get some inferences and conjectures. Friends who have watched MyFirstLayer2 must know that the core issue discussed by Rollup is the DA issue (data availability), and the solutions they adopt are to upload key data to the main network to solve the data availability problem, so that everyone can easily access it required data.

1. OP Rollup is actually a simple and crude way to compress and package each transaction and upload it to a layer of network , then others can obtain the full picture of the second-layer small ledger by decompressing and replaying each transaction to verify whether the transaction was executed correctly.

2. ZK Rollup does not need to upload all transaction details, only the State Diff (the state change part of each batch) needs to be uploaded. Yes, zero-knowledge proof is used to ensure that all transactions have been correctly executed on the second layer. Others can restore the full picture of the second-layer small ledger by replaying the results of multiple state changes.

And we know that the data in the Blob is just a string of binary text for one layer, and the first layer only protects the data in the Blob The accuracy of the ZK Proof cannot be verified without verifying its legality, and the smart contract of one layer cannot read and verify the contents of the Blob. Therefore, if the ZK Proof is still verified by the first layer, the ZK Proof itself cannot be placed in the Blob, so StarkNet To achieve a certain cost reduction effect, the State diff of each batch must be placed in the Blob.

So our next task is obviously to figure out where StarkNet puts the State diff? Where was it placed in the past? Is it placed in the Blob now?

In addition, the fact that only one state root can be found also makes people wonder whether StarkNet quietly uploaded state change data to the mainnet a long time ago. , it was changed to be the responsibility of its own 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...

Related links:

https://layer2.myfirst.io/zh#2.4-rollup

SHARP system

Fortunately, after discussing with @0xYandhii, a new At the dawn of , StarkNet before the universal mainnet was launched, the first product was actually StarkEX, including the decentralized derivatives exchange DYDX, which was also a product of that period. After the mainnet went online, the original product was not abandoned, but instead shared a verification system with the mainnet.

That is, SHARP: Shared Proving and Verifying System, and then we found related contracts such as SHARP Blockchain Writer and Starkware: SHARP Verifier.

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

1. Verify Merkle: Verify Merkle tree

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

3. Register Continuous Memory Page: Uploaded more than a hundred times in a cycle, registering a continuous memory space, suspected to be a layer The part of the network where data is written.

4. Verify Proof And Register: once a cycle, as fast as ten minutes, as slow as one or two hours, it should be enough Multiple transactions are verified in one batch.

It is not difficult to see that steps 1, 2, and 4 are steps related to zero-knowledge proof, and the third step is registration The memory space is obviously the step of writing data to a layer of network, and is the most likely place to store State diff.

It is reasonable to speculate that the costs of the three verification steps have not changed significantly before and after the Blob upgrade, and the cost of the third step should be able to explain the two steps of StarkNet. Order of magnitude fee reduction effect.

So the author continued to browse the block browser, and found the second to last old version before EIP-4844, the first to last version, and the latest version 3 that has been upgraded. Take one verification cycle for each period, and count the Gas consumed by the four steps.

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

Memory costs have dropped by half, but judging from its proportion of costs in the entire ZK Proof verification process, this level of DA decline does not explain any problems.

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 to ask, but maybe because the question is too complicated, no one in the English community responded.

Related links:

SHARP Blockchain Writer:

https://etherscan.io/address/0x16d5783a96ab20c9157d7933ac236646b29589a4

Starkware: SHARP Verifier:

https://etherscan.io/address/0x47312450b3ac8b5b8e247a6bb6d523e7605bdb60

SHARP System GasUsed Explore< /strong>

At this point, we have the last little trick left. In the transaction data csv downloaded before, there is only the ETH consumed by Gas fees, and there is no information such as Gaslimit. Therefore, the impact of Gas unit price fluctuations on statistics 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.

Finally, the light appears! It can be seen that before the upgrade, the transactions for registering memory space were actually sent in groups of 2. One gas cost was a minimum of 50,000, while the other one was generally around 300,000 gas.

After the upgrade, almost all registered memory transactions have become low-cost transactions of 50,000.

The strange conclusion last time was probably that we took too few samples. It happened that the verification cycle after the upgrade caught up with a large period of mainnet Gas surge, making it last for a long time, hundreds of times. Register Continuous Memory Page transactions cost higher Gas, which skews the statistical results.

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 size of the Memory Page has indeed been significantly reduced after the upgrade. This should be the place where the State Diff state change data is stored. After the upgrade, this part of the data was transferred to the Blob.

And later we found the technical diagram of StarkNet on l2beat.com and found that the State diff is indeed stored in the Memory Page as we expected.

In the end, based on our calculation based on the number of GasUsed (a broad estimate based on the currently small randomly selected sample size), the actual cost of L1DA for StarkNet has about 4-10 times of reduction, which is slightly less than an order of magnitude. . This is also consistent with theoretical deduction: in the EIP-4844 upgrade, ZK Rollup does not gain as much benefit as OP Rollup.

04 Summary

After the above exploration, we finally clarified the reasons and extent of StarNet's fee reduction, and the conclusion is still somewhat intriguing.

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

It is clear that StarNet used to write the data of each batch of state changes into a layer of network. Now it puts this part of the data in Blob, so in the act of registering the memory space, it can get slightly less than An order of magnitude fee reduction effect.

However, StarkNet has risen from the last or second place to a level with the top students in the OP department. In terms of relative progress, He even defeated the entire OP Rollup, which is obviously impossible.

Then the only reasonable explanation is that the "black-hearted" income was indeed too high before. Before the issuance of STRK tokens, all development and community incentives of StarkNet require funds. In addition to burning investors' money, setting a higher L2 L1 Gas price difference may be one of their ways to maintain development, which caused the previous StarNet Embarrassing gas bill situation.

Now that the STRK token issuance has brought them enough liquidity and ecological incentives, it is time to return Gas to a reasonable level. With this wave of Blob upgrades, the sandbags tied to the feet were removed, and the cost reduction effect demonstrated by it really surprised many people.

OPization of ZK

OP Rollup after upgrade , after transferring the data originally stored in Calldata of the Ethereum main network to the temporary storage area, a little bit of security is actually sacrificed.

Previously, the data in the Calldata space was permanently stored, which meant that anyone could obtain enough data from the Ethereum main network to restore OP L2. All current statuses.

But after the upgrade, the Blob data will expire. If no entity in the entire network saves the past Blob data, then OP L2’s historical transaction records may will be lost. Although the latest Layer 2 network state can still be protected - because the Blob's storage period exceeds the OP's 7-14 day challenge period, so before each Blob is about to expire, its corresponding Layer 2 state is still credible. , these latest ten days of transaction records maintain the security of OP L2 on a rolling basis.

ZK Rollup If you want to enjoy the benefits of Blob, you also need to transfer important second-layer status data from the permanent 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 a new normal. In the future, all second-layer networks will rely on Blob to maintain the latest state of security, and each L2 also needs its own additional Find ways to address the availability of historical transaction data to achieve a better balance between security and efficiency.

The integration trend of OP and ZK

Past, no. The first generation of OP Rollup was launched first, but the first generation of ZK Rollup did not bring more competitive gas fees after it went online. With the subsequent modularization trend brought about by the emergence of 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, but this is This is a time when 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.