You know regular Ethereum but what about the much-anticipated Ethereum Upgrade? But what does that mean? Developed in partnership with Coinsider, this piece explores Rollups, sharding, Polygon, and much more. Dive into the ether here.
If you want more cryptocurrency analysis including full-length research reports, trading signals, and social media sentiment analysis, use the code "Publish0x" when subscribing to CryptoEQ.io to make your first month of CryptoEQ just $10! Or simply click the button above!
The Calldata Issue
As previously mentioned, rollups post their compressed L2 batched transactions as calldata onto mainnet Ethereum. But what does that mean and what is calldata?
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. 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.
Posting the calldata onchain is what allows Ethereum and its robust, decentralized network of nodes to “check the work” done off-chain. Instead of doing the computation, the calldata enables the Ethereum mainnet to quickly and easily verify that everything done off-chain was valid and accept the state changes i.e. double-check the work. Additionally, the availability of data on the Ethereum 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.
This ability to reconstruct the chain is critical. It provides security guarantees for the users (don’t have to trust the Sequencer, check for yourself!) and removes catastrophic risk due to Sequencer issues.
If a Sequencer suddenly disappeared, a new Sequencer could retrieve all the L2 data from mainnet, reconstruct the latest rollup state, and continue processing transactions. This is because transactions are compressed to only the necessary components (the to/from addresses, transaction value, network fee, and nonce) for reconstruction.
Currently, the cost of posting calldata to L1 Ethereum is 16 gas/byte. EIP-4488 proposed lowering the cost of calldata to 3 gas per byte, while EIP-4844 is a separate proposal to create a new data format specifically designed to lower the cost for rollups of posting data on Ethereum.
Rollups must find operators willing to expend the computational resources to process the rollup data, i.e., maintain a transaction pool, sequence batches, compute state roots/state diffs/validity proofs, etc. This is a tangible cost, quantifying the dollars and cents necessary to run the infrastructure behind operators.
Rollups look to improve already!
Reducing calldata costs
Current implementations of rollups use calldata. However, the EVM is not optimized to process rollup data in a cost-efficient manner. This is because rollups were not even an idea when the EVM was built! Regardless, the EVM assumes data in a transaction will be processed by a smart contract and charges for it accordingly (more expensive). Unfortunately, this approach does not do rollups any favors.
In the future, rollups will evolve to using sharded data (also called “blobs”) because sharded data will be that much cheaper. A new upgrade to Ethereum which targets rollups (EIP-4488) is currently being considered by the Ethereum community and would reduce the cost of posting this calldata onto the mainnet.
Rollups offer many-to-many transactions, smart-contract capabilities, and significantly-reduced total L1 block space requirements, all while extending Ethereum’s security assurance to the L2.
Technically speaking, a rollup is a single contract on the main L1 that holds all funds and a cryptographic commitment to a “sidechain” state. The sidechain/rollup is maintained by a small set of operators off-chain without significantly impacting L1 storage. The reason this “small set” does not introduce centralization is because a rollup’s block producer could attempt to act nefariously, but if it does, the Ethereum L1 will simply reject the “bad batch” and financially penalize the bad actor.
EIP-4844 is a proposal for a temporary solution until a more permanent solution entitled “danksharding” is fully ready to be implemented. EIP-4844 introduces “blob-carrying” transactions as a means of storage for rollups. It is 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 reduces 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 and it has been proposed that they could be pruned (removed) from the L1 after a ~month to reduce storage overhead requirements. Blob transactions are compatible with all rollups, Optimistic and ZK.
Danksharding, from Ethereum core developer @dankrad, is a long-term solution for optimizing rollups with a sharded architecture. Danksharding is designed to circumvent Maximal Extracted Value (MEV) by introducing two new roles into the Ethereum ecosystem: builder and proposer.
As discussed previously, a block proposer (or miner) in a traditional blockchain (like Ethereum currently) can choose which transactions to include from the memepool into the next block based on the highest transaction fees.
PBS Danksharding looks to fix this by dividing the block proposer role into two separate roles: builders and proposers. The builder does not get to choose which transactions to include, rather, it is fed a list of transactions from the proposers in the form of a special list called a crList. “crList” forces the builders to include certain transactions, eliminating their potential to censor transactions. By forcing builders to be honest, the protocol stays trustless.
While crList specifies which transactions the builder is forced to include, it does not specify the order of the transactions. Builders can then reorder the transactions within the crList to maximize their MEV. This essentially optimizes MEV benefits for miners, while precluding builders from censoring transactions.
Danksharding results in execution blocks and shard blocks being built together. This means there will be no delays in shard blocks confirmation and all data will be immediately available to L1. Because there are no separate shards specifically for transactions, the L1 mainnet can serve as both a settlement and data availability layer, reducing complexity in the system. This has been estimated to improve L1 throughput ~6400x.