In the most straightforward way, Ether is digital money on the Ethereum network. It is required when a user interacts with the network to pay network fees in the form of “gas.”

Gas is the allocative internal pricing mechanism in Ethereum used in transactions and can reach exceptionally high price levels during periods of network congestion. Gas is a derivative of Ether designed to mitigate spam attacks on the network and efficiently allocate computational resources. Transactions on the network must have some cost. Otherwise, malicious actors could send millions of transactions a day for free, congesting the network.

Users pay different amounts of gas depending on the type of transactions they are looking to execute. The more complex the transaction, the more gas is required. Sending 1 ETH to a friend (an ETH transfer) is far simpler (computationally-speaking) than minting an NFT. Thus, minting an NFT requires more gas and is more expensive. Below is a monthly chart of ETH gas fees.

At present, Ethereum's pricing mechanism is governed by EIP-1559, which seeks to optimize the utilization of the network's resources by introducing elastic block sizes that target an average usage of 50%. Currently, there is only one gas limit and fee market (single-dimensional). This means that all users, whether they are operating on the L1 layer or a rollup, are competing directly for the same shared resources.

To address this issue, research is underway to develop a multi-dimensional version of EIP-1559 that can implement different fee markets for different resources. The proposed EIP-4844 (discussed more below) would implement a two-dimensional version of EIP-1559 that consists of an Execution Layer and a DA (Data Availability) Layer.

The Execution Layer would remain unchanged under EIP-1559, while the DA Layer would only be used to post "data blobs" (with rollups using this instead of calldata). Let's dive in.

What is EIP-4844 (Proto-danksharding or PDS)?

Proto-danksharding (EIP-4844) is the initial proposal of Ethereum's two-step sharding roadmap. It will establish much of the infrastructure required for full danksharding. However, it will not implement data sharding, and validators will still be required to validate full data availability. PDS will incorporate the transaction formats, verification criteria, consensus and execution logic, and gas price modifications specified by Danksharding.

Proto-danksharding provides a temporary solution by utilizing the transaction format that will be used in sharding, but not actual sharded transactions. Post-PDS data will be in the form of “blobs” rather than data in the calldata field. L1 Ethereum block space will be expanded thanks to the new transaction format that also carries an additional piece of data called a blob.

Data Blobs

With blobs, the data is merely a component of the beacon chain and is downloaded by all consensus nodes on the L1. 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.

This is the idea behind blobs: huge blobs of data that are MUCH cheaper than calldata that remain inaccessible to the EVM. EIP-4844 will slash rollup fees by a factor of ten. This will inspire more decentralized applications to transition to rollups and increase developer awareness of modular blockchains.

PDS also reduces Ethereum L1's data requirement because the blob data need not be held indefinitely (discussed more below). The current line of thinking is the L1 need only retain it for a reasonably long enough time so that anyone can have it if needed (~4-8 weeks). This increases the amount of data that can be posted on L1 and hence reduces the data costs for rollups.

eth eip 4844 data blob tx cycle — Source: Galaxy Digital Research

Ethereum Fees Change with Proto-danksharding

After PDS, Ethereum will have two distinct fee markets that can adjust depending on its own EIP-1559 mechanism. One fee market will be for data availability and one for execution, making the overall economic model more efficient than it was previously. Rollup transactions would have their own “channel,” operating through a brand new 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.

It is important to note that these functions are far from set in stone and are considered an area of ongoing development and research. Different designs have been proposed, but none have been finalized for the Ethereum network.

Proto-danksharding Disadvantages

Blob transactions are a new way to store and move data on the Ethereum network, but they won't fix all the problems with Ethereum's scalability. As more data is added to the network, it will become harder to store and manage it all. This might lead to changes in how the network works, like how data is stored and shared between users. For example, as more people start using them, there will be more competition for data storage space. This may lead to lower prices for data storage, similar to how gas prices on Ethereum can change. There are also technical challenges to using blob transactions, like how to share them between users and how to handle them when the network is busy. There's ongoing research to address these issues and it will be interesting to see what solutions will be found. In the end, to keep the Ethereum network running smoothly, we may need to limit how much data is stored on it, either by renting out storage space or by removing old data.

ethereum state bloat problem dec 2022 — Source

There is a distinct disadvantage for PDS, however. The assumption of creating a different market for data blobs relies on the concept that nodes are not expected to maintain that data availability permanently. After blocks are published and nodes verify the data, the blob data is only expected to be held onto by the node for a specified amount of time, i.e., 30-60 days max. After this time period ends, the data can be discarded, i.e., pruned by the nodes, making it no longer "available." This, in theory, should help to lower the barrier to entry of running a node and decentralize validation on Ethereum. Of course, this proposal is far from finalized.

It is important to note that data availability does not refer to the block's downloadability after publication; that is data storage and retrieval. There are many potential problems to address here, one being that it assumes at least one honest party will be willing and able to provide access to the latest state while the full history of the blockchain is stored externally. The good news is that data storage and retrieval are simple, as only one entity in the world is required to keep and serve the data once it has been made accessible. Whether or not this data is saved by Ethereum full nodes and retrieved through the Ethereum peer-to-peer network is a minor technical detail.

This data can be saved and retrieved anywhere and by anybody, including on BitTorrent, on IPFS with Filecoin, and even on centralized servers held by explorers, exchanges, rollup operators, archivists, etc. Therefore, just one entity is required to maintain and serve the Ethereum history for long-term retrieval.

It is essential to note that EIP-4844 precedes full-Danksharding. It will boost the data capacity of the base layer temporarily, however, each node will continue to store the entire data set. Consequently, EIP-4844 does not include data availability sampling, the fundamental technology that enables genuine scalability. Danksharding will introduce data availability sampling (discussed below), in which nodes will store data fragments.

eth proto danksharding vs full danksharding — Source

Proposer-Builder Separation (PBS)

MEV refers to the maximum amount of value that can be extracted by deciding the transaction order of any given block. As discussed previously, a block proposer (or miner) in a traditional blockchain can choose which transactions to include from the memepool into the next block based on the highest transaction fees. This essentially opens up the possibility of coordinated censoring of transactions and promotes an increasing degree of centralization within the Ethereum ecosystem.

This also negatively impacts users in some pretty damaging ways. For instance, MEV instigates the concept of gas bidding wars as users attempt to outduel one another to get transactions confirmed on the blockchain. This can create significant spikes in gas costs for users and price out everyday users from accessing the Ethereum network.

To circumvent this problem, DS relies on a concept called Proposer-Builder Separation (PBS).

There are three entities in the new PBS Ethereum:

1. Builders - highly sophisticated actors that physically build the blocks maximizing for MEV and then bid them out to validators

2. Relayers- known middle-men with reputational risk to receive blocks from Builders, hash it, and relay on to the validators

3. Validators -simply accept the block with the highest bid and block rewards (without knowing the contents)

To combat the risks of consensus networks getting centralized due to the economics of maximal extractable value (MEV), a solution like Proposal-builder separation (PBS) is needed. PBS also prevents transactions from being censored by validators.

How PBS Works

Currently, the block proposer (validator) chooses which transactions to include in the next block. Proposers include those transactions first in the block that pays the highest priority fees. Proposers also choose transactions that allow them to maximize their profits by using sophisticated MEV strategies. This can threaten decentralization on Ethereum network as large staking pools can implement advanced MEV strategies to generate profits. Seeing this, solo stakers would also like to join staking pools to earn more staking rewards. PBS fixes issues with MEV. After implementing PBS, solo stakers will have an equal opportunity to generate more staking rewards.

Under PBS, the block building and block proposing practices will be assigned to two different actors in the network. Block builders create exec block bodies (an ordered list of transactions) and submit bids for the blocks. The proposer will accept the block with the highest bid. The proposer will be aware of the content of the exec block once they select the header that wins the auction. Before selecting the header, the content of the exec block will not be revealed to the proposer, to prevent the proposer from copying the builder strategy without compensating the builder.

Currently, MEV-Boost, an implementation of PBS built by Flashbots, is being used by many validators to combat the negative effects of MEV. It is playing a critical role in the Ethereum ecosystem since in-Protocol PBS is not implemented yet. A large actor or builder can still censor a particular transaction. For a builder to censor a transaction, they can raise the priority fees for their transactions to such a high amount that builders will prefer only their transactions for inclusion in the block. Builders control the power not to include your transaction if they don't like it or maybe for some other reason.

What are crLists?

Implementing the Censorship Resistance List (crList) is required to prevent censorship of transactions. This potential “hybrid PBS” design prevents the censoring of transactions to an extent.

The crList works as follows:

Proposer publishes a crList and crList summary, which includes all the eligible transactions. The builder must include these transactions in the block unless the block is full.
If the block is not full, the builder submits a bid that includes a hash of crList summary in the block. Ordering of transactions in the block will still be by the builder's choice.
The proposer accepts the highest bid block., and the block header.
Builder publishes the proof of inclusion of all transactions mentioned in crList. Block won’t be accepted by the fork-choice rule if the builder fails to publish the proof.
Attestors (Randomly selected validators) check the validity of the published block’s body.
Block gets included in the blockchain after the proposed block receives the required minimum vote from attestors.

The crList allows proposers to keep the power of builders in check. It maintains the decentralization of proposers while at the same time doesn't let the centralized building market censor the transactions. Currently, there are various open designs of PBS in the discussion. The final design of PBS still needs to be selected.

Loading...