It is no secret that the Ethereum network has been troubled by congestion and scalability issues, inducing exorbitant gas fees and other unfavorable user conditions. Although these problems cannot be attributed to a single source, two prominent examples include increased adoption and the maximum extractable value (MEV) dynamic, enabling validators to arbitrarily exclude, include, and re-order transactions at the expense of users. Nevertheless, the fact that there are scalability issues is quite evident. However, the million-dollar question is, how should we tackle these unfavorable conditions? Well, one, among several answers to this question, is danksharding. But what is danksharding, and how does it work? These are two questions we set out to answer in this article. If this excites you, join us as we dive deeper into the intricacies of danksharding!
However, before covering the ins and outs of danksharding, the article will lay the foundation by covering the basics of sharding in general. From there, we jump straight into the main topic, introducing danksharding and how it works. Then, to top things off, the article covers EIP-4844, also known as proto-danksharding.
What’s more, if you are already familiar with the concept of danksharding, consider checking out other Moralis content here at the Web3 blog. For instance, read about the intricacies of the Goerli testnet or explore ethers.js dapp development. Also, you can learn how to get all NFT transfers from any wallet using Moralis’ NFT API! Plus, explore our tutorial on how to get token metadata!
The aforementioned application programming interface is one of many Web3 APIs from Moralis. If you want access to all of them and enjoy a significantly more seamless developer experience, sign up with Moralis now! Doing so is free, and with an account, you can fully leverage the power of blockchain technology!
What is Sharding?
Centralized database management commonly uses the sharding technique. Furthermore, it refers to splitting an extensive database into less significant parts or ”shards”. In doing so, developers can increase efficiency and scalability by distributing a database across multiple machines working in parallel.
Whenever an application or platform experiences increased adoption, it generally increases the amount of stored data. As you can imagine, an overloaded database negatively impacts the performance of an application/platform, harming the user experience. However, through sharding, it is possible to alleviate a database’s overload to reduce redundant load time.
Nevertheless, with a brief overview of sharding in general, what does it entail in a Web3 context? The fundamental principles remain the same, and sharding a blockchain means splitting the network into distinct shards. Each shard is responsible for storing a portion of the chain’s data and handling a unique subset of transactions. What’s more, like sharding in traditional databases, it can potentially increase the network’s scalability and latency capabilities.
Moreover, a common concept you might want to familiarize yourself with is ”shard chains”. Shard chains are components containing the fractions of the data that handle the subset of transaction processing responsibilities. In short, shard chains are smaller blockchains operating separately and independently from the main network. However, each shard chain submits a record to its main chain at frequent intervals.
Since all shard chains have unique transaction histories and their own set of nodes validating transactions, it is possible to have various shard chains run simultaneously. This can increase network latency and boost throughput via parallel processing.
Now that you have a better understanding of what sharding entails, both within traditional development and in a Web3 context, let us further explore the problem sharding in blockchain networks aims to solve in the next section!
Why is Sharding in Blockchain Networks Necessary?
In most blockchain networks, most nodes need to reach a consensus to validate transactions. A drawback of this is that the networks can only process a small number of transactions simultaneously. Moreover, nodes are generally required to store the entire history of a blockchain. This is vital to how blockchains such as Bitcoin and Ethereum remain decentralized and can prevent fraudulent behavior. However, with the notions of decentralization and high security, these networks are forced to sacrifice their scalability capabilities.
So, how are blockchain networks going to solve these issues without going back on security and decentralization? This is where sharding enters the equation to alleviate this issue. Through sharding, nodes can forgo the requirement of downloading the entire history of the chain and avoid the need to validate all network transactions. As a result, networks become more efficient and scalable, positively impacting the user experience as demand increases!
So, now that you have a more profound understanding of what sharding is and why it is important, let us dive into the central part of this guide and explore the intricacies of danksharding!
Danksharding Explained
Now that you are more familiar with sharding in general, it is time for the guide’s main topic: danksharding. So, what is it? Danksharding is a newer type of sharding architecture proposed for the Ethereum network and gets its name from the researcher Dankrad Feist. This new design introduces some prominent simplifications compared to earlier alternatives. In previous sharding frameworks, the aim has generally been to increase the space for transactions. In contrast, danksharding takes a rollup-centric approach by providing more space for ”blobs” (more on “blobs” below) of data, which the Ethereum protocol itself does not try to interpret.
”Blobs” is an abbreviation for ”binary large objects”, and they are generally quite extensive. However, they are relatively cheap to transact with as the consensus layer stores them rather than Ethereum’s computation-heavy execution layer. Consequently, the computation layer does not need to worry about the details of the data. Furthermore, it can instead focus on the commitments of the data blobs.
Additionally, danksharding implements the ”merged fee market” concept, which is one of the central underlying innovations behind this sharding design. However, what does this mean, and how does it work?
How Does Danksharding Work?
As touched on briefly, one of the central underlying innovative concepts behind danksharding is the merged fee market; however, what does this mean? Well, instead of having a specified number of shards, each having its own distinct blocks and block proposers, in danksharding, it is a single proposer choosing all data and all transactions that go into a particular slot.
Moreover, in order to ensure that the merged fee market design does not force significant system requirements on validators, Ethereum introduced ”proposer/builder separation”, or PBS. In a PBS-based system, a new specialized class of actors known as block builders bids for the right to choose the contents of a slot, and proposers only need to choose the valid header with the highest bid. As such, only the block builder is required to process the entire block; meanwhile, other users and validators can verify blocks more efficiently via data availability sampling.
Through data availability sampling, nodes can verify larger quantities of data through a sample. As a result, since nodes can avoid processing all data, the Ethereum network can handle larger quantities of data, providing a cheaper and faster network more suited for scaling and rollup optimization!
However, danksharding is somewhat complicated and relatively confusing. In addition, due to this complexity, it can take quite some time before the Ethereum network is ripe for danksharding, which is where EIP-4844 enters the picture to introduce proto-danksharding!
What is Proto-Danksharding? – EIP-4844
With the current state of Ethereum, many things need to be settled before the network is ready to adopt complete danksharding. Here is where EIP-4844 enters the picture – a proposal for implementing proto-danksharding. EIP stands for ”Ethereum Improvement Proposal”, and EIP-4844 aims to implement most of the logic and lay the groundwork for full danksharding specifications.
However, the proposal does not yet include any actual implementation of sharding. Consequently, in proto-danksharding, validations and users still have to validate the availability of the complete data directly.
The proto-danksharding proposal’s most prominent feature is a new transaction type: ”blob-carrying transactions”. These are quite similar to traditional transactions, only that they carry an additional piece of data blobs. Blobs are generally quite extensive but can be cheaper than equal amounts of call data. Moreover, this data type is not accessible for EVM (Ethereum Virtual Machine) execution, and the virtual machine can only view commitments to these objects.
Since clients and validators are still required to download the entire contents of the blobs, the bandwidth in proto-danksharding is aimed at 1 MB/slot instead of the total 16 MB. However, there are still significant scalability gains to be made since the data is not competing with the conventional gas usage of existing blockchain transactions.
That briefly covers the intricacies of proto-danksharding/EIP-4844. In the following section, we will compare proto-danksharding with EIP-4488, which is an earlier and simplified proposal aiming to solve the same issue.
What is EIP-4488? – EIP-4844 vs EIP-4488
Now that you have familiarized yourself with EIP-4844 (also known as proto-danksharding), let us take a closer look at a somewhat similar improvement protocol: EIP-4488. EIP-4488 is an earlier and more straightforward attempt to solve the same issue. However, this improvement protocol aims to do it through the following two rules:
A limit of 10 MB/block, plus an extra 300 bytes/transactionReducing call data gas costs from 16 gas/byte to 3 gas/byte
The hard limit is one of the most straightforward methods of ensuring that a significant increase in the average caseload does not lead to an increase in worse caseload. As such, EIP-4844 attempts to reduce the gas costs of call data. However, this is a short-term solution that would prove irrelevant if there was full sharding, as shards would utilize blobs.
To briefly summarize, the main difference is that EIP-4844 aligns with the entire sharding roadmap. Meanwhile, EIP-4488 aims to solve the issue for the time being. However, this does not mean we must perceive the two improvement protocols as trade-offs or competitive. As proto-danksharding might take some time to implement due to engineering technicalities, EIP-4488 can help solve high costs using rollups.
That covers this tutorial on danksharding. If you have followed along this far, you now hopefully know what danksharding is and how it works. In the next section, we will provide a brief summary in combination with other articles that you might find interesting!
Summary – What is Danksharding? – EIP-4844 and Danksharding Explained
When it comes to the Web3 space, sharding refers to the process of splitting up a blockchain into smaller ”shards”. Each shard is responsible for handling a portion of the chain’s transactions, along with storing a selection of its data. Furthermore, sharding can bring many benefits, such as increased scalability and higher throughput.
One type of sharding method that has received an abundance of attention lately is danksharding, which takes a rollup-centric approach to sharding. However, even though danksharding might be a valid solution to Ethereum’s scalability issues in the future, the network is not ready to adopt this sharding design. But this is where EIP-4844 or proto-danksharding enters the picture!
Proto-danksharding is an EIP (Ethereum Improvement Proposal) aiming to implement the fundamental principles and lay the groundwork for danksharding. The main feature of EIP-4844 is a new transaction type called blob-carrying transactions. However, proto-danksharding still requires validators and clients to download the entire contents of the blobs. As such, bandwidth is somewhat limited and aimed at 1 MB/slot. However, it still presents opportunities for significant scalability gains.
Nevertheless, if you found this tutorial on danksharding helpful, consider reading other articles here on the Moralis blog. For instance, check out our tutorial on Web3 py and explore Ethereum Python implementation. In addition, learn how to listen to smart contact events using ethers.js or read up on the Sepolia testnet!
What’s more, if you want to become a more proficient Web3 developer, enroll in Moralis Academy today! The academy offers industry-leading blockchain courses for both new and more experienced developers. For instance, learn the basics with the course on Ethereum fundamentals.
Lastly, remember to sign up with Moralis to access a more seamless workflow for all your future blockchain development endeavors!
