Decentralized finance (DeFi) has been a driving force in the cryptocurrency space, and the evolution of Layer 2 solutions has brought about significant advancements. Among these, smart contract rollups have emerged as a promising approach to scaling blockchain networks while maintaining security and efficiency.
Rollups are essentially blockchains that post their blocks to an alternate blockchain, thus leveraging the consensus and data availability of that particular blockchain, often denoted as a "consensus and data availability layer".
A smart contract rollup mechanism is sustained by three principal components: sequencers, rollup full nodes, and rollup light clients. All rollups embody a state, which is the account addresses and token balances of rollup users at a specific point in time.
Sequencers in a rollup ecosystem are nodes that receive new rollup transactions from users. They bundle these transactions into a block and post it onto the consensus and data availability layer. A block is bifurcated into two parts: a block header and the actual transaction data. The block header, apart from other data, contains a cryptographic commitment to the chain's state, commonly expressed as a Merkle root.
Rollup full nodes represent a crucial element in the rollup process. These nodes download all rollup block headers and transaction data. They process and verify all transactions to calculate the state of the rollup and ensure the transactions are valid. If a full node encounters an invalid transaction within a rollup block, the node dismisses and ignores that block. This effectively curtails sequencers from creating valid blocks with invalid transactions, as these would be rejected by the nodes.
Conversely, rollup light clients download only the rollup block headers, steering clear of downloading and processing any transaction data. This means they cannot calculate the latest state or verify the state validity of the rollup independently. These clients learn about the latest state commitment from the most recent rollup block header and can request rollup full nodes for fragments of the state. They also indirectly assess the validity of the rollup transactions using methodologies like fraud proofs or validity proofs.
When rollup nodes synchronize the rollup chain, they employ the order imposed on the rollup blocks by the consensus and data availability layer. They finalize a rollup block if it is the first valid block at its height within the rollup to be published on the data availability layer—irrespective of whether the validity is checked directly (as with full nodes), or indirectly (as with light clients).
Smart contract rollups function by channeling users' funds through a rollup smart contract on the Layer 1 (L1) blockchain, which subsequently oversees transactions and state changes. At the heart of this process are Merkle trees, critical data structures that store the state of funds and transaction data, enabling the L1 to verify the state on the Layer 2 (L2) without the need to download the entire state. Essentially, users conduct transactions on the L2, affecting changes in the state, and the L2 periodically shares a Merkle root of the state with the L1 for verification.
However, alongside posting the Merkle root to the L1, the L2 must also provide enough Merkle tree change data to allow users to independently recreate the Merkle tree. This data becomes crucial in situations where the L2 encounters disruptions, as users would otherwise be stranded on the L2. To address this concern, L1 smart contracts incorporate "emergency functions" that enable users to withdraw their funds from the smart contract rollup if the L2 becomes unavailable for any reason.
EIP-4488
Rolling out a 100% complete version of danksharding is incredibly complex and will likely take 1,2,3+ years. Because of this, there are intermediary options being discussed, including EIP-4488 and EIP-4844 (proto-danksharding).
EIP-4488 is the simplest and quickest way to improve rollups and drive down costs. However, it also has the least amount of attention currently. So, what is it?
EIP-4488 attempts to reduce rollup costs (while mitigating storage bloat) through two primary factors:
- Reduce calldata cost from 16 gas per byte to 3 gas per byte
- A limit of 1 MB per block plus an extra 300 bytes per transaction (theoretical max: ~1.4 MB)
This change could be implemented in terms of months, not years, and could reduce rollup costs by
EIP-4844 (Proto-danksharding or PDS)
Proto-danksharding (PDS) is an alternative to EIP-4488 but is still a temporary stepping stone to the ultimate goal of “full” danksharding. However, even PDS is quite complex. Rather than rollups using "calldata" storage (permanently on-chain), under PDS, rollups could post bundles under a new “blob” transaction type which is much cheaper.
Rollup transactions would have their own “channel,” operating through a novel data blob market that uses its own fee structure and floating gas limits. This means that even with heightened demand and activity from DeFi or NFTs, data costs won’t go up for rollups. This creates two different gas markets - one for general computation and one specifically for data availability (DA), making the overall economic model more efficient than it was previously.
Data blobs are an entirely new transaction format, and only the blob’s hash can be accessed via a new opcode. This guarantees the data content will never be accessed by the EVM, reducing the gas cost of posting the data compared to with calldata. Blob transactions can enable up to ~1MB average per block for data storage as opposed to the 10KB currently with calldata. It also has been proposed that they could be pruned (removed) from the L1 after a ~month to reduce storage overhead requirements.
