Rollups: An overview

The process of transaction settlement on a roll-up like Optimism can be broken down into two separate flows:

1. Posting Compressed Transaction Data on L1: The transactions submitted to the sequencer are serialized and compressed together to create a rollup batch. This rollup batch is then posted on the data availability layer (which in this case is the Ethereum L1). This transaction batch is available for actors to verify and submit fraud proofs if needed.
2. Determination of the new state and settlement: The rollup execution client applies the transactions on the old state to calculate the new state. The new state root is then posted to L1 which is settled after a 7-day challenge period. In the absence of any valid fraud-proof, the transaction remains finalised.

https://docs.optimism.io/stack/protocol/transaction-flow‍

Transaction cost breakup on rollups

A typical Optimism Transaction https://optimistic.etherscan.io/tx/0x7534e14934a03020e92617b892908e2b9aa342ddaa0b890d950d5e24692a833e

Notice that of the total 0.000081759643163416 ETH transaction fee, 0.000079811368052244 ETH is paid to the L1. The L1 fee is approximately 97.61% of the total transaction fee, which is representative of all optimism transactions.

How to reduce transaction cost on rollups

1. Data compression
2. Proto Dank Sharding (EIP 4844)
3. Alternate DA solutions
4. Using wasm + evm

1. Data Compression

Data compression can save the overall transaction gas cost by reducing the number of bytes rollup sequencers posted on Ethereum hence resulting in low L1 calldata gas cost.

Rollups already do compression on transaction batches before posting it to Ethereum using a general-purpose algorithm (such as brotli). The amount of data being posted to the DA can be further reduced by applying application-specific compression on the transaction data. This can be achieved by decomposing the transaction data into a set of common patterns and instance-specific parameters, and then moving the information about the common patterns on-chain.

How does compression work in general?

Compression and decompression of data are fundamental processes in computer science and information technology, used to reduce the size of data (compression) and restore it to its original form (decompression). These processes work on the principle of eliminating redundancy in data and are essential for efficient storage and transmission.

L1 calldata depends on how much calldata is submitted on rollups while doing transactions on rollups. We can utilise compression/decompression techniques to reduce the number of bytes we put in rollup transactions and then decode the original data on some smart contract. This will increase the execution cost on rollups but will result in more reduction in L1 calldata cost resulting in the overall less costly transaction.

Compression + ERC 4337

The compression technique can be applied on top of ERC 4337 without changing any on-chain entity.

This begins by first compressing the UserOp on the client side by following a set of compression rules that relies on how data is structured in the UserOperation. Different approaches can be used to compress individual fields of a UserOperation.

Once we have a compressed UserOp, it is then sent to a decompressor contract that exists between bundlers and the EntryPoint contract. Bundlers post compressed UserOperation to this decompressor contract, which decompresses it by applying the rules of the pattern(s) isolated earlier, restoring the original UserOperation and then calling the EntryPoint contract and everything happens as usual.

‍

‍

On a high level, clients build UserOp, get it signed by the user, compress the UserOp using a set of compression rules, and send the compressed UserOp to the bundler via some different RPC method eg biconomy_sendCompressedUserOp.

Bundler then runs some validation rules on compressed UserOp, includes it in an alternate mempool, bundles compressed UserOps and calls the Middleware contract which restores the original userOps and calls the EntryPoint contract.

‍

2. Proto Dank Sharding (EIP 4844)

Ethereum has introduced rollups as a way to reduce transaction costs. In this system, users post their transactions on rollups at a much lower gas price than directly on the Ethereum mainnet. These rollups gather many transactions and then post them on Ethereum, serving both as a Data Availability (DA) layer and a settlement layer. This method significantly lowers the cost of individual transactions.

Though rollups have reduced the cost of transaction as compared to Ethereum, rollups are limited in how cheap they can make user transactions by the fact that they post their transactions on Ethereum in CALLDATA. This is expensive because it is processed by all Ethereum nodes and lives on the chain forever, even though rollups only need the data for a short time.

‍

EIP-4844: Implementing Proto-dank Sharding

EIP-4844 is a specific version of Dank Sharding designed to further lower transaction costs. It will implement a new transaction type that will hold an additional data field called a blob. These blobs are essentially large chunks of data (up to 125 kB in size) that can be added to Ethereum transactions.

So instead of submitting the transaction data to Ethereum as calldata, rollups submit this data as blobs in a more cost-effective way. Data in these blobs are not accessible to EVM and are automatically deleted after a fixed period (1 - 3 months).

How blobs will reduce transaction fees on rollups?

1. New Fee market for posting blobs on L1The addition of the blob in transactions will expose a new fee market that is separate from the gas market used to pay for transactions. This fee is expected to be much lower than existing transaction fees.
2. Less storage requirementBlobs will only persist in the consensus layer (aka Beacon nodes) and are not accessible to EVM. Also, these blobs will be automatically deleted after a fixed period (1 - 3 months) reducing the storage requirement on L1.
3. Less computation to validate data posted by rollupsThe blobs are committed to the network using a new cryptographic method KZG (a fixed-size vector commitment scheme). Using this method it is computationally less expensive to prove that the proposed state change is correct.

This efficiently reduces the amount of computational power and storage space needed, which in turn lowers the cost of transactions. As a result, transactions involving rollups become significantly cheaper, making the Ethereum network more accessible and affordable for users.

Full Dank Sharding and Further Cost Reduction

Danksharding is the full realization of the roll-up scaling that began with Proto-Danksharding. Danksharding will bring massive amounts of space on Ethereum for rollups to dump their compressed transaction data. This means Ethereum will be able to support hundreds of individual rollups with ease and make millions of transactions per second a reality.

The way this works is by expanding the blobs attached to blocks from 1 in Proto-Danksharding to 64 in full Danksharding.

‍

3. Alternate Data Availability solutions

Another solution to the problem of Data Availability for Rollups is by offloading this responsibility from the Ethereum blockchain. There are blockchain protocols like Celestia, Avail and EigenDA which help solve this problem. Unlike traditional blockchains where the execution of transactions and the availability of data are tied together, Data Availability protocols decouple these two aspects.

By separating the consensus mechanism from transaction execution, these protocols allow other blockchains or layer 2 solutions to leverage its data availability layer without being constrained by its execution rules.

This decoupling allows for greater scalability, as blockchains can process more transactions without being limited by the need to also handle data storage and availability. Thus potentially lowering transaction costs on the main chain (Ethereum).

‍

4. Using wasm + evm

Chains like Arbitrum Stylus provide a dual VM environment where contracts compiled to WASM can interact with EVM contracts and vice versa. Contracts written in Rust compiled to WASM tend to be much cheaper than their EVM counterparts, therefore common contracts such as the 4337 Entrypoint and Smart Account implementations can be re-written in Rust.

‍

References

https://www.quicknode.com/guides/ethereum-development/transactions/eip4844-explained

https://eips.ethereum.org/EIPS/eip-4844

https://ethereum.org/roadmap/danksharding

‍

‍