Network
Launch Date
Consensus
Note
Sepolia
Oct 2021
PoW
Like-for-like representation of Ethereum
Görli
Jan 2019
PoA
Proof-of-Authority
Kiln
Mar 2022
PoS
Post-Merge (for ETH2), shadow fork of the mainnet
Kintsugi
Dec 2021
PoS
DEPRECATED, use Kiln; post-Merge (for ETH2)
Ropsten
Nov 2016
PoW
DEPRECATED, use Sepolia; the Merge to happen on Jun 8, 2022
Rinkeby
Apr 2017
PoA
DEPRECATED, use Görli and Görli Faucet
Kovan
Mar 2017
PoA
DEPRECATED, use Sepolia or Görli
List of active and deprecated Ethereum testnets, including Kintsugi.
Features
Optimistic rollup 
ZK-rollup 
Proof
Uses fraud proofs to prove transaction validity. 
Uses validity (zero-knowledge) proofs to prove transaction validity. 
Capital efficiency
Requires waiting through a 1-week delay (dispute period) before withdrawing funds. 
Users can withdraw funds immediately because validity proofs provide incontrovertible evidence of the authenticity of off-chain transactions. 
Data compression
Publishes full transaction data as calldata to Ethereum Mainnet, which increases rollup costs. 
Doesn't need to publish transaction data on Ethereum because ZK-SNARKs and ZK-STARKs already guarantee the accuracy of the rollup state. 
EVM compatibility
Uses a simulation of the Ethereum Virtual Machine (EVM), which allows it to run arbitrary logic and support smart contracts. 
Doesn't widely support EVM computation, although a few EVM-compatible ZK-rollups have appeared. 
Rollup costs
Reduces costs since it publishes minimal data on Ethereum and doesn't have to post proofs for transactions, except in special circumstances. 
Faces higher overhead from costs involved in generating and verifying proofs for every transaction block. ZK proofs require specialized, expensive hardware to create and have high on-chain verification costs. 
Trust assumptions
Doesn't require a trusted setup. 
Requires a trusted setup to work. 
Liveness requirements
Verifiers are needed to keep tabs on the actual rollup state and the one referenced in the state root to detect fraud. 
Users don't need someone to watch the L2 chain to detect fraud. 
Security properties 
Relies on cryptoeconomic incentives to assure users of rollup security. 
Relies on cryptographic guarantees for security. 
Start building
on Alchemy.
Sign up for free
Start building on Optimism.
Sign up for free
Start building on Arbitrum.
Sign up for free
Start building on Ethereum.
Sign up for free
Start building on Polygon.
Sign up for free
Start building on Starknet.
Sign up for free
Start building on Flow.
Sign up for free
kiln faucet
Get free Kiln ETH.
Start building today
Goerli faucet
Get free Goerli ETH.
Start building today
mumbai faucet
Get free Mumbai Matic.
Start building today
rinkeby faucet
Get free Rinkeby
ETH.
Start building today
Start building on Ethereum.
Get started for free
Start building on Ethereum.
Get started for free
Start building on Flow.
Get started for free
Start building on Polygon.
Get started for free
Start building on Starknet.
Get started for free
Start building on Optimism.
Get started for free
Start building on Solana.
Get started for free
Start building on Solana.
Sign up for beta access
Start building on Solana.
Join the waitlist
Arbitrum logo
Start building on Arbitrum.
Get started for free
Learn
Solidity at
Alchemy
University
Get started today
curl 
https://release.solana.com/v1.10.32/solana-install-init-x86_64-pc-windows-msvc.exe 
--output 
C:\solana-install-tmp\solana-install-init.exe 
--create-dirs
Ethereum
DANKSHARDING OVERVIEW

What is danksharding?

A Thorough Guide to Understanding the Impact of EIP-4844
Last Updated:
June 22, 2022

A new sharding design called proto-danksharding has been introduced as part of the roadmap to full blockchain sharding.  Because it is so new, many people do not yet understand it. 

This overview will give a thorough, easy-to-understand analysis of everything you need to know about proto-danksharding and how it would help Layer 2s scale. Let’s dive in.

What is sharding?

Sharding refers to splitting a blockchain into smaller portions to enhance overall efficiency. 

For example: Instead of processing a transaction worth $100,000 on the Ethereum Mainnet, the transaction  can be broken into ten shards, each bearing the data of $10,000 worth of transactions. This is intended to reduce network congestion. 

Apart from speed, shard chains provide greater storage and reduce fees. 

It’s important to note that sharding is an implementation that will go through various phases before arriving at the final stage.

What is danksharding?

Danksharding is a sharding design that implements the concept of a merged market fee; unlike regular sharding, in which shards have both different block and block proposers, only one proposer exists in danksharding. 

The block builders have the duty of choosing the data and transactions that go into each slot of a block. 

Danksharding and sharding are interrelated, but they are different. While sharding is the overall design for the splitting of networks in an effort to scale Ethereum, danksharding is a step towards the actualization of this goal. 

Tim Beiko—one of the foremost Ethereum researchers—explained on the Bankless podcast the origin of the name Danksharding, which was named after another veteran Ethereum researcher, Dankrad Feist. 

How does danksharding work?

Block builders push a request to determine what goes into each slot that will later form a block, and then, it is left to the proposer to select the highest bidder. Once a builder has been chosen to oversee a slot, they have the onus of processing the entire block.

In some cases, it is possible that oracles can carry out the role of a block builder. According to the Ethereum team, the main reason behind this design is to curb the two unfair controls that the miners currently have – Maximum Extractable Value, or MEV. 

First, miners can show unfair preference by choosing their transactions or the ones of those they know. Secondly, miners can hand-pick transactions with the highest bidder, thereby leaving millions of other transactions in the mempool for hours or days. 

With danksharding, however, no one knows the contents of the ordered list of transactions that a builder submits. Therefore, the power of the miners—or proposers as they will be called after the Merge—is curtailed. 

What is the difference between block builders and proposers?

Block builders carry out the role of block construction, while block proposers select transaction headers that should be added to the block and broadcast them accordingly. These two work hand-in-hand. 

Block builders bundle up transactions into slots or chunks so they can be added to a block, and then builders submit them to the proposers for selection. After the proposer successfully selects a block, the block builders will process the block. 

Miners, in the present phase of Ethereum, are simply the block proposers. But after the Merge, miners will be more appropriately called validators. On the other hand, block builders are a new set of actors that will be created. 

Data Availability Sampling in Danksharding

A basic tenet of blockchain is transparency. If a mischievous or invalid block is added to a chain, it can be bad for the entire network. 

Usually, in the Ethereum ecosystem, full nodes can present fraud proofs to light clients—and the entire network at large—as evidence that a transaction is not valid. But this only works well with roll-ups and may not quite work for danksharding. 

Miners can verify danksharded blocks when they sample the available data. First of all, data availability connotes that the underlying data behind a particular hash has been published on-chain. At this year’s ETH Dubai, Protolambda explained data availability to mean the permissionless ability to reconstruct the state. 

In practice, this data availability sampling is implemented with the erasure codes. The erasure codes can be sampled to get the actual data that was added to the slot or block. 

After the transactions have been processed, there may be ongoing arguments concerning when the data should be deleted from the Ethereum blockchain to avoid bottlenecking the throughput. 

Presently, there are plans that the data will be deleted after a month. Nevertheless, even after the expiry date, the data will still be accessible  via various means such as Graph Protocol and block explorers. 

What is proto-danksharding (EIP-4844)?

As it stands, there are still a lot of things to be settled in the bid to actualize full danksharding. This led to the creation of the EIP-4844 proposal, which is a format that implements proto-danksharding.  

This proposal aims to implement core changes—particularly transaction format—that would be needed for full sharding. The name proto-danksharding was also coined from the name of another Ethereum researcher - Proto Lambda.

The actual change that Proto Lambda introduced to danksharding is called Binary Large Objects, often called “blobs” for short. Indeed, blobs aren’t new concepts in programming, as they exist in JavaScript and Python. What is new, however, is the possibility that blobs can be relevant in smart contracts. To understand that better, we need to ask the question, “What are blobs?”

What are blobs (Binary Large Objects)?

Blobs are proposed by block proposers and they are likened to big wraps or large portable bundles that can contain cheaper data. Each block can hold a limited size of these big wraps. In terms of structure, a typical blob has a body and a header. 

The body of a blob always stores the relevant pieces of data that relate directly to transactions. A header, on the other hand, contains lesser pieces of information, such as the signature of the proposer. 

In proto-danksharding, each transaction always has a blob twin, and the end goal of this is to make transactions cheaper.  To enhance scalability, each slot in proto-danksharding would mostly have 1 MB data bandwidth. 

Note: the Ethereum Virtual Machine can only access the cheaper data that is wrapped in a blob, and not the blobs themselves because transactions in danksharding will not be in the usual mempool, but instead a different one. 

What is the difference between EIP-4844 and EIP-4488?

This is the difference: EIP-4844 is providing solutions that align with—and even fast-track—the entire sharding roadmap, while EIP-4488 only attempts to solve problems for the time being. 

At its core, EIP-4488 attempts to drastically reduce the gas cost of call data. Although that can help for now, it would be irrelevant if there were full sharding, as shards would use blobs. On the other hand, EIP-4844 plans to use blobs in its transactional format. 

Nonetheless, we must also bear in mind that these two proposals do not need to be perceived as competitive or as trade-offs. While proto-danksharding might take time due to a couple of engineering technicalities, EIP-4488 can be implemented to solve interim cost problems using  roll-ups. 

Will proto-danksharding reduce gas fees

The answer to this is a clear “No.” Proto-danksharding won't reduce Ethereum gas fees, but it will reduce the transaction costs of Layer 2 protocols. 

Indeed, this question comes up a lot in conversations about proto-danksharding. This misconception is bound to happen because proto-danksharding will introduce blobs. 

Even then, blobs will only replace call data that roll-ups usually use. Therefore, the gas fees on the Ethereum protocol will still be the same. 

Indeed, developers who have been following the updates of the Ethereum ecosystem for years now will agree that most of the proposals out right now will not directly affect or significantly reduce the gas fees of the main Ethereum protocol, not even The Merge. 

The Current State of Proto-danksharding

Ever since the proto-danksharding improvement proposal was created earlier in February, there have been expectations concerning whether or not any progress is being made.y. 

While the Ethereum research team is still figuring out a couple of vital issues, proto-danksharding still has a long way to go in the bid to be the forerunner of full sharding. 

Foremost, data availability sampling is still theoretical and has not yet been implemented. Part of the reason for this is that the developers are still deciding whether or not the Ethereum Improvement Proposal should only implement point evaluation precompile and drop the idea of coupling it with blob verification precompile. 

Indeed, blob verification precompiling is self-achievable among Layer 2s. As a result, the Ethereum community is contemplating whether there is still a need to officially provide for it. 

The Ethereum team is looking into the most realistic architecture of blobs and the smartest security measures to put in place. 

The Future of Proto-danksharding

The Ethereum network has been battling the problems of relatively slow throughput and high gas fees for years, and Ethereum researchers have proposed various technical solutions, including sharding.

Proto-danksharding is a route to implementing the complete sharding roadmap, and its main aim is to reduce transaction costs for layer-2 protocols through a blob-centric transaction format. 

The Ethereum community has been keen on enhancing their modularity goal by providing Layer 2 blockchains with the needed architecture to build more scalably on the Ethereum protocol. 

ALCHEMY SUPERNODE - ETHEREUM NODE API

Scale to any size, without any errors

Alchemy Supernode finally makes it possible to scale blockchain applications without all the headaches. Plus, our legendary support will guide you every step of the way.

Get started for free
Supernode footer
Ethereum
DANKSHARDING OVERVIEW

What is danksharding?

A Thorough Guide to Understanding the Impact of EIP-4844
Last Updated:
June 22, 2022
Don't miss an update
Sign up for our newsletter to get alpha, key insights, and killer resources.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

A new sharding design called proto-danksharding has been introduced as part of the roadmap to full blockchain sharding.  Because it is so new, many people do not yet understand it. 

This overview will give a thorough, easy-to-understand analysis of everything you need to know about proto-danksharding and how it would help Layer 2s scale. Let’s dive in.

What is sharding?

Sharding refers to splitting a blockchain into smaller portions to enhance overall efficiency. 

For example: Instead of processing a transaction worth $100,000 on the Ethereum Mainnet, the transaction  can be broken into ten shards, each bearing the data of $10,000 worth of transactions. This is intended to reduce network congestion. 

Apart from speed, shard chains provide greater storage and reduce fees. 

It’s important to note that sharding is an implementation that will go through various phases before arriving at the final stage.

What is danksharding?

Danksharding is a sharding design that implements the concept of a merged market fee; unlike regular sharding, in which shards have both different block and block proposers, only one proposer exists in danksharding. 

The block builders have the duty of choosing the data and transactions that go into each slot of a block. 

Danksharding and sharding are interrelated, but they are different. While sharding is the overall design for the splitting of networks in an effort to scale Ethereum, danksharding is a step towards the actualization of this goal. 

Tim Beiko—one of the foremost Ethereum researchers—explained on the Bankless podcast the origin of the name Danksharding, which was named after another veteran Ethereum researcher, Dankrad Feist. 

How does danksharding work?

Block builders push a request to determine what goes into each slot that will later form a block, and then, it is left to the proposer to select the highest bidder. Once a builder has been chosen to oversee a slot, they have the onus of processing the entire block.

In some cases, it is possible that oracles can carry out the role of a block builder. According to the Ethereum team, the main reason behind this design is to curb the two unfair controls that the miners currently have – Maximum Extractable Value, or MEV. 

First, miners can show unfair preference by choosing their transactions or the ones of those they know. Secondly, miners can hand-pick transactions with the highest bidder, thereby leaving millions of other transactions in the mempool for hours or days. 

With danksharding, however, no one knows the contents of the ordered list of transactions that a builder submits. Therefore, the power of the miners—or proposers as they will be called after the Merge—is curtailed. 

What is the difference between block builders and proposers?

Block builders carry out the role of block construction, while block proposers select transaction headers that should be added to the block and broadcast them accordingly. These two work hand-in-hand. 

Block builders bundle up transactions into slots or chunks so they can be added to a block, and then builders submit them to the proposers for selection. After the proposer successfully selects a block, the block builders will process the block. 

Miners, in the present phase of Ethereum, are simply the block proposers. But after the Merge, miners will be more appropriately called validators. On the other hand, block builders are a new set of actors that will be created. 

Data Availability Sampling in Danksharding

A basic tenet of blockchain is transparency. If a mischievous or invalid block is added to a chain, it can be bad for the entire network. 

Usually, in the Ethereum ecosystem, full nodes can present fraud proofs to light clients—and the entire network at large—as evidence that a transaction is not valid. But this only works well with roll-ups and may not quite work for danksharding. 

Miners can verify danksharded blocks when they sample the available data. First of all, data availability connotes that the underlying data behind a particular hash has been published on-chain. At this year’s ETH Dubai, Protolambda explained data availability to mean the permissionless ability to reconstruct the state. 

In practice, this data availability sampling is implemented with the erasure codes. The erasure codes can be sampled to get the actual data that was added to the slot or block. 

After the transactions have been processed, there may be ongoing arguments concerning when the data should be deleted from the Ethereum blockchain to avoid bottlenecking the throughput. 

Presently, there are plans that the data will be deleted after a month. Nevertheless, even after the expiry date, the data will still be accessible  via various means such as Graph Protocol and block explorers. 

What is proto-danksharding (EIP-4844)?

As it stands, there are still a lot of things to be settled in the bid to actualize full danksharding. This led to the creation of the EIP-4844 proposal, which is a format that implements proto-danksharding.  

This proposal aims to implement core changes—particularly transaction format—that would be needed for full sharding. The name proto-danksharding was also coined from the name of another Ethereum researcher - Proto Lambda.

The actual change that Proto Lambda introduced to danksharding is called Binary Large Objects, often called “blobs” for short. Indeed, blobs aren’t new concepts in programming, as they exist in JavaScript and Python. What is new, however, is the possibility that blobs can be relevant in smart contracts. To understand that better, we need to ask the question, “What are blobs?”

What are blobs (Binary Large Objects)?

Blobs are proposed by block proposers and they are likened to big wraps or large portable bundles that can contain cheaper data. Each block can hold a limited size of these big wraps. In terms of structure, a typical blob has a body and a header. 

The body of a blob always stores the relevant pieces of data that relate directly to transactions. A header, on the other hand, contains lesser pieces of information, such as the signature of the proposer. 

In proto-danksharding, each transaction always has a blob twin, and the end goal of this is to make transactions cheaper.  To enhance scalability, each slot in proto-danksharding would mostly have 1 MB data bandwidth. 

Note: the Ethereum Virtual Machine can only access the cheaper data that is wrapped in a blob, and not the blobs themselves because transactions in danksharding will not be in the usual mempool, but instead a different one. 

What is the difference between EIP-4844 and EIP-4488?

This is the difference: EIP-4844 is providing solutions that align with—and even fast-track—the entire sharding roadmap, while EIP-4488 only attempts to solve problems for the time being. 

At its core, EIP-4488 attempts to drastically reduce the gas cost of call data. Although that can help for now, it would be irrelevant if there were full sharding, as shards would use blobs. On the other hand, EIP-4844 plans to use blobs in its transactional format. 

Nonetheless, we must also bear in mind that these two proposals do not need to be perceived as competitive or as trade-offs. While proto-danksharding might take time due to a couple of engineering technicalities, EIP-4488 can be implemented to solve interim cost problems using  roll-ups. 

Will proto-danksharding reduce gas fees

The answer to this is a clear “No.” Proto-danksharding won't reduce Ethereum gas fees, but it will reduce the transaction costs of Layer 2 protocols. 

Indeed, this question comes up a lot in conversations about proto-danksharding. This misconception is bound to happen because proto-danksharding will introduce blobs. 

Even then, blobs will only replace call data that roll-ups usually use. Therefore, the gas fees on the Ethereum protocol will still be the same. 

Indeed, developers who have been following the updates of the Ethereum ecosystem for years now will agree that most of the proposals out right now will not directly affect or significantly reduce the gas fees of the main Ethereum protocol, not even The Merge. 

The Current State of Proto-danksharding

Ever since the proto-danksharding improvement proposal was created earlier in February, there have been expectations concerning whether or not any progress is being made.y. 

While the Ethereum research team is still figuring out a couple of vital issues, proto-danksharding still has a long way to go in the bid to be the forerunner of full sharding. 

Foremost, data availability sampling is still theoretical and has not yet been implemented. Part of the reason for this is that the developers are still deciding whether or not the Ethereum Improvement Proposal should only implement point evaluation precompile and drop the idea of coupling it with blob verification precompile. 

Indeed, blob verification precompiling is self-achievable among Layer 2s. As a result, the Ethereum community is contemplating whether there is still a need to officially provide for it. 

The Ethereum team is looking into the most realistic architecture of blobs and the smartest security measures to put in place. 

The Future of Proto-danksharding

The Ethereum network has been battling the problems of relatively slow throughput and high gas fees for years, and Ethereum researchers have proposed various technical solutions, including sharding.

Proto-danksharding is a route to implementing the complete sharding roadmap, and its main aim is to reduce transaction costs for layer-2 protocols through a blob-centric transaction format. 

The Ethereum community has been keen on enhancing their modularity goal by providing Layer 2 blockchains with the needed architecture to build more scalably on the Ethereum protocol. 

A new sharding design called proto-danksharding has been introduced as part of the roadmap to full blockchain sharding.  Because it is so new, many people do not yet understand it. 

This overview will give a thorough, easy-to-understand analysis of everything you need to know about proto-danksharding and how it would help Layer 2s scale. Let’s dive in.

What is sharding?

Sharding refers to splitting a blockchain into smaller portions to enhance overall efficiency. 

For example: Instead of processing a transaction worth $100,000 on the Ethereum Mainnet, the transaction  can be broken into ten shards, each bearing the data of $10,000 worth of transactions. This is intended to reduce network congestion. 

Apart from speed, shard chains provide greater storage and reduce fees. 

It’s important to note that sharding is an implementation that will go through various phases before arriving at the final stage.

What is danksharding?

Danksharding is a sharding design that implements the concept of a merged market fee; unlike regular sharding, in which shards have both different block and block proposers, only one proposer exists in danksharding. 

The block builders have the duty of choosing the data and transactions that go into each slot of a block. 

Danksharding and sharding are interrelated, but they are different. While sharding is the overall design for the splitting of networks in an effort to scale Ethereum, danksharding is a step towards the actualization of this goal. 

Tim Beiko—one of the foremost Ethereum researchers—explained on the Bankless podcast the origin of the name Danksharding, which was named after another veteran Ethereum researcher, Dankrad Feist. 

How does danksharding work?

Block builders push a request to determine what goes into each slot that will later form a block, and then, it is left to the proposer to select the highest bidder. Once a builder has been chosen to oversee a slot, they have the onus of processing the entire block.

In some cases, it is possible that oracles can carry out the role of a block builder. According to the Ethereum team, the main reason behind this design is to curb the two unfair controls that the miners currently have – Maximum Extractable Value, or MEV. 

First, miners can show unfair preference by choosing their transactions or the ones of those they know. Secondly, miners can hand-pick transactions with the highest bidder, thereby leaving millions of other transactions in the mempool for hours or days. 

With danksharding, however, no one knows the contents of the ordered list of transactions that a builder submits. Therefore, the power of the miners—or proposers as they will be called after the Merge—is curtailed. 

What is the difference between block builders and proposers?

Block builders carry out the role of block construction, while block proposers select transaction headers that should be added to the block and broadcast them accordingly. These two work hand-in-hand. 

Block builders bundle up transactions into slots or chunks so they can be added to a block, and then builders submit them to the proposers for selection. After the proposer successfully selects a block, the block builders will process the block. 

Miners, in the present phase of Ethereum, are simply the block proposers. But after the Merge, miners will be more appropriately called validators. On the other hand, block builders are a new set of actors that will be created. 

Data Availability Sampling in Danksharding

A basic tenet of blockchain is transparency. If a mischievous or invalid block is added to a chain, it can be bad for the entire network. 

Usually, in the Ethereum ecosystem, full nodes can present fraud proofs to light clients—and the entire network at large—as evidence that a transaction is not valid. But this only works well with roll-ups and may not quite work for danksharding. 

Miners can verify danksharded blocks when they sample the available data. First of all, data availability connotes that the underlying data behind a particular hash has been published on-chain. At this year’s ETH Dubai, Protolambda explained data availability to mean the permissionless ability to reconstruct the state. 

In practice, this data availability sampling is implemented with the erasure codes. The erasure codes can be sampled to get the actual data that was added to the slot or block. 

After the transactions have been processed, there may be ongoing arguments concerning when the data should be deleted from the Ethereum blockchain to avoid bottlenecking the throughput. 

Presently, there are plans that the data will be deleted after a month. Nevertheless, even after the expiry date, the data will still be accessible  via various means such as Graph Protocol and block explorers. 

What is proto-danksharding (EIP-4844)?

As it stands, there are still a lot of things to be settled in the bid to actualize full danksharding. This led to the creation of the EIP-4844 proposal, which is a format that implements proto-danksharding.  

This proposal aims to implement core changes—particularly transaction format—that would be needed for full sharding. The name proto-danksharding was also coined from the name of another Ethereum researcher - Proto Lambda.

The actual change that Proto Lambda introduced to danksharding is called Binary Large Objects, often called “blobs” for short. Indeed, blobs aren’t new concepts in programming, as they exist in JavaScript and Python. What is new, however, is the possibility that blobs can be relevant in smart contracts. To understand that better, we need to ask the question, “What are blobs?”

What are blobs (Binary Large Objects)?

Blobs are proposed by block proposers and they are likened to big wraps or large portable bundles that can contain cheaper data. Each block can hold a limited size of these big wraps. In terms of structure, a typical blob has a body and a header. 

The body of a blob always stores the relevant pieces of data that relate directly to transactions. A header, on the other hand, contains lesser pieces of information, such as the signature of the proposer. 

In proto-danksharding, each transaction always has a blob twin, and the end goal of this is to make transactions cheaper.  To enhance scalability, each slot in proto-danksharding would mostly have 1 MB data bandwidth. 

Note: the Ethereum Virtual Machine can only access the cheaper data that is wrapped in a blob, and not the blobs themselves because transactions in danksharding will not be in the usual mempool, but instead a different one. 

What is the difference between EIP-4844 and EIP-4488?

This is the difference: EIP-4844 is providing solutions that align with—and even fast-track—the entire sharding roadmap, while EIP-4488 only attempts to solve problems for the time being. 

At its core, EIP-4488 attempts to drastically reduce the gas cost of call data. Although that can help for now, it would be irrelevant if there were full sharding, as shards would use blobs. On the other hand, EIP-4844 plans to use blobs in its transactional format. 

Nonetheless, we must also bear in mind that these two proposals do not need to be perceived as competitive or as trade-offs. While proto-danksharding might take time due to a couple of engineering technicalities, EIP-4488 can be implemented to solve interim cost problems using  roll-ups. 

Will proto-danksharding reduce gas fees

The answer to this is a clear “No.” Proto-danksharding won't reduce Ethereum gas fees, but it will reduce the transaction costs of Layer 2 protocols. 

Indeed, this question comes up a lot in conversations about proto-danksharding. This misconception is bound to happen because proto-danksharding will introduce blobs. 

Even then, blobs will only replace call data that roll-ups usually use. Therefore, the gas fees on the Ethereum protocol will still be the same. 

Indeed, developers who have been following the updates of the Ethereum ecosystem for years now will agree that most of the proposals out right now will not directly affect or significantly reduce the gas fees of the main Ethereum protocol, not even The Merge. 

The Current State of Proto-danksharding

Ever since the proto-danksharding improvement proposal was created earlier in February, there have been expectations concerning whether or not any progress is being made.y. 

While the Ethereum research team is still figuring out a couple of vital issues, proto-danksharding still has a long way to go in the bid to be the forerunner of full sharding. 

Foremost, data availability sampling is still theoretical and has not yet been implemented. Part of the reason for this is that the developers are still deciding whether or not the Ethereum Improvement Proposal should only implement point evaluation precompile and drop the idea of coupling it with blob verification precompile. 

Indeed, blob verification precompiling is self-achievable among Layer 2s. As a result, the Ethereum community is contemplating whether there is still a need to officially provide for it. 

The Ethereum team is looking into the most realistic architecture of blobs and the smartest security measures to put in place. 

The Future of Proto-danksharding

The Ethereum network has been battling the problems of relatively slow throughput and high gas fees for years, and Ethereum researchers have proposed various technical solutions, including sharding.

Proto-danksharding is a route to implementing the complete sharding roadmap, and its main aim is to reduce transaction costs for layer-2 protocols through a blob-centric transaction format. 

The Ethereum community has been keen on enhancing their modularity goal by providing Layer 2 blockchains with the needed architecture to build more scalably on the Ethereum protocol. 

Build web3 with Alchemy

Alchemy combines the most powerful web3 developer products and tools with resources, community and legendary support.

Get started for free