Ethereum is gradually moving towards the rollup-centric roadmap. One of the EIPs, which will help in scaling Ethereum is EIP-4844, popularly known as “Proto-Danksharding.” In this blog, we will dive into one pre-requisite of this EIP, the KZG Ceremony.
The Ethereum network, like most blockchain networks, currently faces limitations in terms of scalability. As more and more users join the network and the amount of data on the blockchain grows, the network's ability to process and validate transactions in a timely manner becomes increasingly constrained. This can lead to delays in confirmation times, high transaction fees, and a lack of overall network efficiency. To address these scalability concerns, the concept of sharding came around.
Sharding is a method to split data so that it is easier to handle that data. With time, the overall size of the blockchain increases because blocks keep getting added up to the existing chains. So, in Ethereum, the idea is to split up the amount of processed data into multiple concurrent chains. So as to increase the total throughput of the blockchain.
Initially, these shards would not just hold data but were also going to perform computation on that data set. Still, the approach introduced some other complexities, such as how cross-shard communication will work in the ecosystem. As the data could have been siloed so, how will the consensus work? So the idea of how to scale Ethereum was altered and now we have Proto-Danksharding, in which instead of having multiple chains, we have one chain, and the node operator is not responsible for the whole chain; he is responsible for part of the chain.
Furthermore, the computation won’t be taking place on these shards. Instead, rollups will take care of that, as per the rollup-centric roadmap.
Danksharding is the initial proposal that is too complex to discuss in this blog. So, let’s have a look at the main innovation that came with Danksharding, i.e., the merged fee market. According to this, “one” proposer node is responsible for choosing all transitions and the data to be added in the shards. This will increase the hardware requirements for the node operator. Hence, another concept of propose/builder separation was introduced.
This requires more time to implement as it has a lot more technical complexities, so now we have a more simplified version, Proto-Danksharding that will be upgraded to danksharding in the future. However, in the short term, this solution will still drastically help with the data constraints we currently have.
Proto-Danksharding is a forward-compatible implementation for smoothening the implementation of Danksharding. The use of rollups and the merged fee market can improve scalability by offloading computation and data storage to other entities.
With Proto-Danksharding, we will have a new type of transaction, i.e., “Shard Blob Transaction”, which is like a normal translation with the exception that it will have space for blobs. EVM cannot access the blob data, it can only access commitment to the blob. A blob is a collection of 4096 units of information, each consisting of 32 bytes. With Proto-Danksharding, a maximum of 16 blobs can be stored in each block. With Danksharding, this number increases to 256 blobs, which limits the total number of data transactions that can be processed in a block. This allows for a target block size of approximately 1 MB and a maximum of 2 MB.
Currently, In Ethereum, users pay a one-time fee for some data to be stored, and then the blockchain keeps the data on it forever. One of the ideas behind Danksharding is to give this responsibility to someone else so that the validator nodes don’t have to store this huge amount of data in perpetuity. So, what will happen is the validator will be assigned data that it must download and make it available for everyone. L2 solutions can access this data and download all the relevant portions that they need, and after a certain period, validators will discard this data.
Coming back to the validators, the important thing here is that individual validators won’t be worrying about this anymore. And as more scalability is added to the blockchain, the data that validators need to store will only increase. So, now entities who need the data are going to be responsible. But this is something rollups and protocols can take care of.
What about normal users? Normal users obviously have the option to trust the sequencers if they have their transactions on L2s. But in the case where they don’t trust the sequencer, they can store data locally. There are more options we can explore about this. On a side note, we will probably see different solutions coming forward to download and keep this data in their own archives nodes, and users will then be able to query data from those archive nodes.
KZG ceremony is a prerequisite for Proto-Danksharding. It will provide the cryptographic foundation via the trusted setup. The KZG ceremony is taking place to create a structured reference string for the Proto-Danksharding. The ceremony is to be held by the Ethereum community and will provide the necessary security for the network.
It uses multiparty computation, as different individuals first set their secret values, each mixed with some randomness. Then each contributor runs a computation to mix it with previous contributions. The output is made public and passed to the next contributor. The ceremony will be live for two months. Anyone can contribute in that time frame.
Why do we need commitment in Proto-Danksharding? So, we already know by now that the blob transaction types will have the data blob in it, which is kind of like a sidecar to the actual data block. To refer to this “sidecar,” Proto-Danksharding uses KZG commitments.
KZG commitment also enables erasure coding, which is useful in case a percentage of the data is lost.
The KZG ceremony is live for a duration of 2 months. In the KZG ceremony, we have an entity called the sequencer and as the name suggests, is literally to sequence who's next. So, if we have many people trying to contribute, how do we decide the sequence?
Since the computation is sequential and cannot be parallelized, so the sequencer sees if there is a free slot. Then the sequencer gives you the file, and then you add your secret value to the sequence. It combines your Randomness with the randomness of the people that came
before you, and then you send your file back to the sequencer, and then the sequencer checks that you didn't try to lead someone else's secret or do other inaccurate things. Then the file is sent to the next person.
The sequencer can basically see what the ceremony looked like after each contribution, but that is what everyone sees, so it's not like the sequencer has more access to data that could be used to break it. All sequencer has is more control over who goes next.
Sequencers can prevent someone from participating. But even that can be countered, as users can do their computation and send it back to the sequencer. But, again, the sequencer can reject the file by claiming that the file is not correctly computed. The sequencer has to send you the file back with their signature on it. Now, users can take the file to other sequencers and prove that the sequencer is censoring the user.
To avoid this, the Ethereum foundation put the sequencer through some audits.
The Ethereum community has several ways to participate in the creation of the Common Reference String (CRS) that is used to create zk-SNARKs for private transactions on the Ethereum blockchain, as proposed in EIP-4844. The methods for participation range in technical difficulty, from simple browser interfaces to writing your own implementation.
One of the easiest ways to participate is through a browser interface, such as ceremony.ethereum.org. To prevent spam contributions, participants will need to provide an Ethereum address (which has sent at least 4 transactions as of 2023/01/13) or GitHub account.
If you're comfortable using a command line, you can check out some of the CLI implementations to contribute from your local machine.
You can generate some randomness using a unique and creative method and use one of the above methods to add it to the ceremony.
For those who want to convince themselves that the secret hasn't been leaked, writing your own implementation using BLS12-381 for the ceremony is possible. There are resources available to make this process as simple as possible.
Note that the sequencer will reject wrong calculations.
If you participate through the browser method. There is no queue. There is a general lobby, and accounts are picked at random from the lobby. This makes it nicer that you just show up to participate. But, the trade-off is that you don't know exactly when you're going to get included. So, the lobby could have thousands of participants and you may have to wait for a while.
By being in the lobby what essentially happens is time to time, your computer asks a sequencer for the file, then the request is denied or accepted based on the file’s availability status. The file being unavailable just means that someone else is contributing.
The participation process is quite easy. The trust assumption of the ceremony is based on the concept of "1-of-N," where the security of the entire ceremony relies on the fact that only one participant is honest and hasn’t given out the secret. To compromise the ceremony, each and every participant would have to work together to extract and combine their secrets, or there would have to be a flaw in every single implementation.
In summary, Proto-Danksharding, as outlined in EIP-4844, is a promising solution for addressing scalability limitations on the Ethereum network. Its implementation will greatly improve the scalability and efficiency of the network by splitting data into multiple concurrent chains and utilizing rollups. You can participate in the KZG ceremony for the next 2 months since 13th January 2023.