Thread by @mt_1466

1/ A follow-on 🧵 from yesterday's post about the #ArbitrumOdyssey fee spike.

This thread will discuss, in more detail,:
- the nuances around Optimistic rollups (ORs)
- what are the primary costs associated with ORs
- why there's hope
- @OffchainLabs roadmap

https://twitter.com/mt_1466/status/1545173562914480128

2/ In the case of ORs, no computation is actually done.

They “optimistically” assume all state changes are valid & post the off-chain txs to #ETH’s L1 as calldata.
To counter any potentially fraudulent txs, a dispute period is put in place for ~one week after posting to L1.

3/ During this time, any 3rd party can publish a fraud proof to verify the validity of the txs across L1 and L2.
If the txs are found to be invalid, the invalid txs and all affected txs will be reverted.

@ArbitrumDailyTK , @optimismPBC , @bobanetwork , and @fuellabs_ are ORs

4/ However, posting this calldata to L1 is still expensive, and, for the moment, many rollups have not optimized their settings to reduce this function.

Today, the primary cost associated with a rollup is the cost to post calldata (discussed further below) to L1 Ethereum.

5/ Optimism posts data to the ETH L1 for every transaction.

However, some #ZKR implementations, like @dYdX (RIP), only post to the L1 to reflect every account balance. Because of this, #dYdX interacts with L1 only ~20% as much as $OP, meaning ~90% reduction in fees.

6/ These decisions have trade-off but, essentially, how much the rollup interacts with the L1 is going to play a huge roll in the costs. As seen by this chart from @jonwu_

7/ #Calldata is a specific form of read-only memory data used by smart contracts to call external functions.

Once a rollup has batched enough transactions, it is expected to post this state transition change in a compressed form to the L1 via calldata.

8/ Rollups currently utilize L1 calldata for data storage, which is limited to ~10KB per block. They do this so that anyone has the ability to reconstruct the chain and verify the latest state.
(apologies but cannot find image source. looks like @kermankohli but unsure)

9/ Posting the calldata onchain enables $ETH nodes to “check the work” done off-chain.

Instead of doing the computation, the calldata enables the ETH L1 to quickly & easily verify that everything done off-chain was valid & accept the state changes.

10/ Additionally, the availability of data on the ETH L1 means that any computation completed on a rollup can be redone by the Ethereum base layer if needed.
Without sufficient data availability, transaction execution becomes opaque/ a black box that cannot be audited by the L1.

11/ Currently, the cost of posting calldata to L1 ETH is 16 gas/byte.

#EIP4844 is a proposal for a temporary solution until a more permanent solution entitled “#danksharding” is fully ready to be implemented.

12/ EIP-4844 introduces “blob-carrying” txs as a means of storage for RUs.
It is a new tx format & only the blob’s hash can be accessed via a new opcode
This guarantees the data will never be accessed by the #EVM, reducing the gas cost of posting the data compared to calldata

13/ Blob transactions can enable up to ~1MB average per block for data storage as opposed to the 10KB currently with calldata and it has been proposed that they could be pruned (removed) from the L1 after a ~month to reduce storage overhead requirements.

14/ End. If you liked or thought this was helpful, please share around. The education around #Ethereum technology and scaling quite poor at the moment. Every bit helps. And the full article can be found here.

cryptoeq.io/articles/layer…