Why did costs drop so much after EIP-4844?

🙏 Help and Support
1

I am so happy to see StarkNet’s swift support for EIP-4844 and the significant reduction in costs. However, as someone with a background in mathematics (and not in development) who understands the details of Rollup technology to some extent, I find this quite puzzling:
ZK Rollups require proof verification on L1, where a large part of the gas consumption is due to computation rather than storage. The computational part should not benefit from the Blob’s advantages, especially since STARK proofs are larger than SNARK proofs. It seems a considerable portion of gas is spent on zkProof verification rather than state storage.
I roughly verified this by looking at the transaction records of StarkNet: Operator—the gas limit for proofs did not significantly decrease after EIP-4844.

My guess is that the L1DA costs for zk might be higher than I imagined, so moving DA into Blobs resulted in sufficient cost reduction. I hope the community can provide more information:
Question 1: What is the approximate ratio of DA costs to proof verification costs (Before and After EIP-4844)?
Question 2: Is the data currently put into Blobs state diff? Only this approach would have a sufficient reason for the significant cost reduction.
Question 3: If the answer to question 2 is yes, it means that after the Blob expires, the data obtained on L1 cannot be used to reconstruct the L2 World state through Replay , Correct?

Additionally, I discovered the SHARP system (Shared Proving and Verifying System), which seems to be a verification system shared by StarkNet mainnet and StarkEX. From what I observed, they perform four actions:

  1. Verify Merkle
  2. Verify FRI
  3. Register Continuous Memory Page every one to two minutes, which happens very frequently and seems like writing data needed for verification to L1, but it’s unclear if it’s related to state diff or state-related.
  4. Verify Proof And Register, which happens every ten minutes to a couple of hours, likely verifying a batch of transactions after accumulating them. Starkware: SHARP Verifier | Address 0x47312450b3ac8b5b8e247a6bb6d523e7605bdb60 | Etherscan

Among these, Register Continuous Memory Page seems the most likely way to write L2 STATE into L1. However, it did not significantly decrease after EIP-4844, so it might also be providing space for zkproof verification data rather than layer 2 state?

Question 4: What exactly is Continuous Memory Page used for?

1

Old SHARP Blockchain Writer:

New SHARP Blockchain Writer:

2

Hi, I think I can answer a couple of these questions:

  1. before EIP-4844, about 95-99% of sequencer costs to L1 were due to the cost of posting DA. Execution costs were the other 1-5% of costs. After EIP-4844, kinda hard to say bc they’ve been volatile while in price discovery. People are playing around with things like blobscriptions and L2 sequencers are doing a lot of frequency testing with blob postings

  2. Yes the DA posted to blobs is only state differentials, not full tx calldata.

  3. State diffs are the minimum amount of data needed to transition from one block to the next (one snapshot of the state of Starknet to the next). Full tx calldata offers no additional benefits in this context.
    As for blob expiration, DA is really meant to be ephemeral as it’s only needed for the length of time it takes to reach consensus on a block. Once you have block X and block Y confirmed and committed to the chain, you no longer need the DA to get from X to Y, as at this point you should have sufficient trust that state Y is valid. You do need the DA to get from Y to a future, unconfirmed block/state (Z). The few weeks it takes for expiration is intended to be enough to handle a short term reorg or downtime.
    Think of a github repo. A block’s DA is the set of edits (a commit) that get you from one version to the next. Every validator only needs to keep track of the most recent version and not all the edits(commits) that got you from V1 to the current version/state. Each version is like a snapshot of state. When it’s time to merge a new commit, all the nodes on a DA layer must validate the state transition ie the code edits. But you can always just reference the most recent reviewed and confirmed version rather than replaying the commits to the code from every single edit/update along the way

  4. Not sure on this one!