Original author: 0xSamo
Original source: LXDAO
In this article, 0xSamo, the author of LXDAO, explores Starknet's on-chain core components, optimistic/zk rollup fee structure, EIP-4844 blob mechanism, and SHARP system fees through the flexible use of EtherScan, showing that Starknet's fee fees have dropped by 99% The real reason is that the treasury has other sources of income after Starknet's issuance and no longer has to rely on fees to generate income, so the L2 Gas Price benchmark has been significantly lowered.
Preface
EIP-4844 has attracted enough attention as the biggest upgrade to Ethereum since The Merge. The temporary storage space of Blob introduced by this upgrade is equivalent to adding a side-mounted car to the Ethereum train, providing a cheaper DA space without affecting the original operating status of the train.
Layer 2 projects such as Optimism, StarkNet, and Arbitrum have all supported EIP-4844 in a short period of time and achieved significant fee reductions, and the following are the transactions generated by the LXDAO treasury when they pay payrolls to contributors on Optimism, and the difference in gas fees before and after EIP-4844 is 100 times.
But at the same time, we found that StarkNet, as a representative of ZK Rollup, actually achieved an amazing fee reduction effect, from the previous gas level of more than $1 at every turn, to $0.01.
Why can Starknet's fees be reduced so much?
OP Rollup与ZK Rollup对一层DA空间的需求不同
The degree of dependence of the two on the DA space is very different. OP Rollup will package and compress all the details of recent transactions, including user signatures and other data, and upload them to L1. It doesn't require too many calculation tasks on the L1 network, and almost all of the cost is in the DA space of the L1 network.
In contrast, ZK Rollup has a higher compression ratio for on-chain data. For example, it can rely on ZK Proof to ensure that the transaction is valid without uploading the digital signature of the Layer 2 transaction, and ZK Rollup does not need to package all the transaction details, but only needs to package the result of the state change on the chain.
For example, on the layer 2 network, there are 100 users who trade on the USDC/USDT trading pair, and the balance of USDC and USDT in the asset contract will change after each transaction. For OP Rollup, the DA data generated behind these transactions is 400 balance changes across 100 transactions and 200 accounts.
For ZK Rollup, the total of 200 changes in the asset contract can be compressed into 2 final state summary changes, which greatly reduces the size of DA data.
ZK Rollup验证ZKP消耗的额外Gas
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 know that before EIP-4844, the cost of ZK Rollups such as StarkNet and ZkSync is significantly higher than that of OP Rollups, 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 that of other Layer 2.
(L2 fee table for each time in 2023)
The reason why ZK Rollup didn't crush OP Rollup as soon as it went live is simple: although it has a higher compression ratio for transaction data and saves the cost of transmitting data to Layer 1, it needs to verify zero-knowledge proofs on Layer 1, which increases the computational cost.
Blob can only reduce DA fees, but does not help much in the calculation part, and compared to OP rollups, ZK rollups get fewer benefits on EIP-4844, so it is hard not to be surprised when we see Starknet quickly achieve cent-level gas fees from the state of expensive fees.
Explore Starknet's commission composition
ZK Rollups tend to be more complex than OP Rollups. The graph below shows the transaction records generated when the Optimism sequencer publishes DA data to L1, and anyone can understand why the OP's transaction fees dropped by two orders of magnitude after EIP-4844 was implemented.
However, when investigating the source of Starknet's fees, the authors of this article experienced considerable difficulties because the interaction between the different components of Starknet is more complex. Let's retrace the whole process.
Disappear a layer of DA
Because of the experience of exploring the fee structure of Optimism, it is natural for us to think that it is enough to find the contract address of Starknet to submit data to the mainnet, and this kind of key contract must be on the Etherscan gas consumption list, which should not be difficult to find, such as Scroll, which has not yet adapted to EIP-4844, and its contract is still hanging at the top of the gas consumption list.
When we search for Starknet keywords, we will find three related components on EtherScan: Operator, Core Contract, and Memory Page Fact Registry, but the third contract, which seems to be related to DA, was discontinued nearly two years ago.
At present, we can see that Starkent's Operator is constantly interacting with the Core Contract, constantly calling the "Update State" function.
If we flip to the on-chain records before and after the Cancun upgrade is activated, we will find that the "Update State" behavior of the Operator does have a detailed change, firstly, the function name is changed to "UpdateStateKzgDA", and secondly, the old state update function will send ProgramOutput, onchainDataHash and onchainDataSize, while the new version of the function uploads ProgramOutput and KzgProof.
KzgProof, commonly known as KZG Promise, plays a similar role to the datahash of a blob, and has a corresponding relationship with the data stored in the blob. It is worth noting that the new version of the state update function consumes more gas than the old version. So the question is, why is Starknet able to reduce fees so low, and why?
更多资料参考LXDAO旗下的Layer2科普网站MyOfferLayer2:
HTTPS://Layer2.MyFirst.io/z#3.3-Optimistic-Rollup
Analysis after the first frustration
Although the first exploration was less successful, we were still able to get some inferences and conjectures. Those of you who have read MyFirstLayer2 must know that the core problem of Rollup is the DA problem (data availability), and they are all about uploading key data to the mainnet to solve the data availability problem, so that everyone can easily access the data they need to obtain.
- Let's go back, OP Rollup simply compresses and summarizes all transaction instructions, packages and uploads them to the layer 1 network, and others can download the compressed data, and then unzip it, and replay each transaction to know the state change of the layer 2 network.
- ZK Rollup does not need to upload complete transaction details, but only needs to upload a State Diff (the amount of state change before and after each batch is executed). ZKRollup uses ZKP to ensure that the State Diff is valid and error-free, and others can directly overlay the State Diff on top of the Prev_GlobalState to know the latest state of the layer 2 network.
As we all know, the data in the blob is just a string of binary text like garbled characters, and the first-layer network only guarantees that the blob data will not be tampered with by some malicious nodes after uploading, but is not responsible for verifying the content of the data, and of course, the smart contract deployed in 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 fee reduction effect, which has little to do with ZKP, and must be caused by the change of the storage location of the State diff.
The next task is obviously to confirm where exactly did Starknet put the State diff, where did it be, and whether it is in the blob now.
In addition, the fact that only one StateRoot can be found in the input parameters of the UpdateState function makes one wonder if Starknet has instead sent the data that should have been uploaded directly to the mainnet to its own off-chain DAC (Data Availability Committee......
SHARP system
Fortunately, after discussing with @0xYandhii, I was enlightened that before Starknet was launched on the general-purpose mainnet, the first product was actually StarkEX, including the decentralized derivatives exchange dYdX, which was also a product of that period.
After the mainnet was launched, the original product was not abandoned, but instead shared a validator contract with the mainnet, namely the SHARP: Shared Proving and Verifying System, and then we found SHARP Blockchain Writer, SHARP Verifier and other related contracts.
Open the block explorer to query the relevant transactions, and you can find that the SHARP Blockchain Writer has performed the following four types of operations:
- 1. VerifyMerkle:验证默克尔树
- 2. VerifyFRI: Used to ensure that submitted data or computations follow specific rules and do not need to reveal the original image of the data.
- 3. Register Continuous Memory Page：疑似是向一层网络写入数据时调用的功能。
- 4. Verify Proof And Register: It is called once every 10 minutes and every 1 or 2 hours, which should be verified by Starknet after accumulating enough transactions to 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, while the third function, which is obviously the step to write data to the layer 1 network, is the most likely function related to State diff uploads.
We speculate that the call fees of the 1, 2, and 4 functions have not changed significantly before and after the blob upgrade, and the cost of using the third function should be significantly reduced, which can explain why Starknet's fee reduction effect is so significant.
So the author continued to flip through the block explorer, the penultimate version before EIP-4844, the penultimate version, and the latest version that has been upgraded take a verification cycle for each of the 3 periods, and count the gas consumed by each of the 4 functions when they are called.
The results are as follows, head-scratching.
The third function related to data publishing has its fee reduced by half, but in terms of its proportion of the fee in the whole round of ZK Proof verification, this DA fee reduction level does not support our previous hypothesis.
The author feels like a physicist sitting in front of a large particle collider in the three-body world, every brain cell screaming: This doesn't make sense! I even went to the Starknet community and posted a post to ask, but perhaps because the issue was too complicated, no one responded to the English community.
SHARP系统GasUsed探索
At this point, we still have one last little trick left, in the transaction data csv downloaded before, there is only ETH consumed by Gas fees, and there is no information such as GasPrice and Gaslimit, so it is impossible to rule out the impact of Gas unit price fluctuations on the statistical results. So the author wrote a script to count the GasUsed (the used part of the Gaslimit) actually consumed by each transaction involved before.
This time we've finally found the clue. It can be seen that before the Cancun upgrade, the function called Register Continuous Memory Page would trigger twice each time the DA data was uploaded, consuming 50,000 gas once and 300,000 gas at the other.
After the Cancun upgrade, almost all transactions that call the Register Continuous Memory Page function only consume 50,000 gas.
We had taken too few samples, and it happened that after that upgrade, it was a time when mainnet gas fees were skyrocketing, which affected our stats, leading us to believe that the cost of calling the Register Continuous Memory Page function didn't change much before and after the Cancun upgrade, and that the problem was quickly discovered when we adopted the statistics more broadly.
With this in mind, we rearranged the GasUsed data for 3 moments, which makes a lot more sense this time. So far, 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, which should be the original step to store the State Diff, and after the Cancun upgrade, the DA data is transferred to the blob.
Later, we found a schematic diagram of Starknet's product structure on the L2beat website, and we can find that the State diff is indeed stored on the Ethereum chain through the above functions.
(Source: L2BEAT)
In the end, based on the calculation of the number of GasUsed (broadly estimated with a small sample size currently randomly selected), we conclude that after the upgrade of Starknet in Cancun, the DA cost will change by about 4~10 times, which is slightly less than an order of magnitude.
This is in line with our initial guess: after the EIP-4844 upgrade, ZK Rollups do not get as many benefits as OP Rollups.
summary
After the above exploration, we have finally sorted out the reasons for the significant drop in Starnet's fees, and the conclusion is still a bit intriguing.
DA fees have dropped dramatically, but they can't explain the two-order of magnitude drop
It can be made clear that Starnet used to directly upload the state change data contained in each batch to the L1 network, but now it puts this part of the data in the blob, so it can get a slightly less than an order of magnitude reduction effect in the DA data part of the fee.
But how to explain the 99% drop in Starknet's fees? The only reasonable explanation is that Starknet did charge too many fees to users before the upgrade in Cancun. In addition to burning investors' money, setting a scissors difference between the ETH charged to users and the ETH actually consumed may be one of the ways for Starknet to maintain its operation, which makes Starknet's gas fee so high before.
Now that the STRK token issuance has brought enough money to Starknet, it's time to get Gas back to a reasonable level, and the sandbags tied to their feet were removed along with the Cancun upgrade, and the fee reduction effect shown by the Cancun upgrade has really surprised many people.
Historical data loss issues for rollups
After the OP Rollup is upgraded, the data originally stored in the transaction calldata is transferred to the temporary storage area of the blob, which actually sacrifices a little trustlessness.
Previously, the data in the Calldata space was stored permanently, meaning that anyone could download enough historical data from the Ethereum mainnet to verify and synchronize the current state of the OPR.
However, after the Cancun upgrade, the blob data has an expiration setting, and if there is no entity on the whole network to store the past blob data, the historical transaction records of OPR may be lost.
Although the latest Layer 2 state can still be protected - because the retention period of blobs exceeds the OP's 7-14 day challenge period, the corresponding Layer 2 state of each blob is still trusted until it is about to expire, and the latest 10-day transaction records maintain the security of OPR on a rolling basis.
If ZK Rollup wants to enjoy the benefits of blobs, it also needs to transfer important Layer 2 state data from the Calldata space to the Blob space. This means that after a while, we will no longer be able to replay the Layer 2 state by relying on the data provided by the L1 network as before.
Perhaps this will become the norm, and in the future, all layer 2 networks will rely on blobs to maintain the security of the latest state, and each L2 will also need to find its own way to solve the problem of storing historical transaction data, so as to achieve a better balance between security and efficiency.
Convergence trend of OP and ZK
In the past, the first-generation OP Rollup was the first to go online, and the first-generation ZK Rollup did not bring more competitive gas fees after it was launched. As for 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 a life-and-death competition, they will learn from each other and have a tendency to integrate, but this time it is a time for the "noble" ZK to learn from the "simple and rude" OP.
It's hard to imagine that layer 2 technology has evolved to such a point in just two or three years, and maybe that's the charm of the blockchain world.