Ethereum needs you!

Ethereum's next major upgrade is in development and -- for the first time -- ordinary, non-technical people like you and I can help create it. But, the time to help is running out. You have just days left left to make your contribution. So, if you want to get involved, you need to do it soon. I'll show you exactly what you need to do to take part in this historic opportunity. And, don't worry, the whole process is incredibly easy, costless, and risk-free. In fact, it's as simple as wiggling a mouse and clicking a few buttons. Sounds good, right?

But, before I show you what you need to do, I should probably explain why this is happening in the first place.

What you'll be contributing to is called the KZG Summoning Ceremony.

Now, I appreciate that's a bit of a weird and fancy name that probably doesn't mean anything to you. So, what is it?

The short answer is that it's a trust-minimised process for setting up a new cryptographic scheme that Ethereum will be using after its next update. That update is called Proto-Danksharding (or EIP-4844), and it's all about cutting the cost of data storage to make Ethereum a better foundation for Layer Two platforms.

Again, that may well sound like a load of gobbledygook. If so, stick with me. To really understand this we first need to establish a little background information.

If you paid any attention to crypto in the last bull run, then you probably heard a lot of people saying the same thing: "Ethereum sucks!" That's because, during times of high demand, Ethereum transactions are both slow and expensive -- especially when compared to competitors like Solana. You might assume this is because Ethereum is older than the cheaper blockchains and therefore has worse, outdated technology. However, that's not the case. In reality, Ethereum's poor performance and high fees are entirely intentional. You might think that's crazy. After all, why would anyone choose to provide a terrible user experience? In reality, it's because Ethereum is simply prioritising something else: decentralisation.

There's a lot that could be said here, but I'm going to save most of it for another time. What you need to know is that Ethereum is designed to minimise the barrier to entry for anyone wanting an active role in the network. In practice, that means the Ethereum software must be able to run on all sorts of computers -- including fairly cheap, low-powered ones. Therefore, Ethereum blocks cannot contain a large quantity of transactions or data because that would overwhelm the low-end computers in the network. As a result, it doesn't take a significant increase in transaction volume to saturate Ethereum's blocks. When that happens, users are forced to outbid one another to ensure their transaction is prioritised and included in a block. And that very quickly spirals into the sky-high transaction fees we all love to complain about.

Of course, Ethereans recognise the problem here. They certainly don't want to create a system that anyone can help run but only the rich can afford to use. And so they've come up with a plan. One that will allow them to retain the accessible, decentralised core of the system while also increasing capacity and reducing transaction fees. And that plan is called 'Layered Scaling'.

Layered scaling is ultimately about aggregating as much activity as possible into a small number of Ethereum transactions. The idea is to shift most day-to-day transactions away from Ethereum and onto new 'Layer Two' (L2) platforms. These platforms are built with performance in mind, ensuring transaction fees remain low even when demand is high. Then, every so often, all of the recent L2 transactions will be batched, compressed, and represented in a single transaction on Ethereum. In this way, all the activity still takes place on the Ethereum blockchain, just in a less direct manner. All the same, it means all of the L2 transactions are still verified and secured by Ethereum. That leads to the ultimate win-win scenario for end users. They still enjoy all the benefits of Ethereum and its robust, decentralised design but they don't suffer with its low throughput, slow transactions, and exorbitant fees.

Years of research have convinced Ethereans that this layered approach is the best way to build and scale a blockchain. The problem is, Ethereum wasn't built with this methodology in mind. So, some modifications are required to get the most out of a more modular design.

One of the biggest issues is storing data. Remember how Layer Twos aggregate all their recent transactions and represent them in a single Ethereum transaction. Well, that Ethereum transaction must contain a fair amount of data -- essentially a summary of all the L2's recent activity. And, here's the problem, Ethereum only has one kind of data storage: permanent. When an L2 -- or anyone else, for that matter -- posts a bunch of data to Ethereum, everyone in the Ethereum network must hold onto that data forever. That's not easy to do, and it places a significant burden on the computers in the network. So, this isn't good for Ethereum. Especially because its priority has always been minimising the burden on those computers to keep the network decentralised. The situation is also not good for the L2s. Ethereum doesn't want people filling blocks with data and overwhelming the low-end computers in the network, so it charges a high price for data storage. As a result, L2s must pay a lot of money to make their settlement transaction on Ethereum, and the L2's users must pay higher fees to account for that. Again, this is particularly silly when the whole point of the L2s is to provide a low-fee environment. So, we need a better solution for storing data. And, this is where Proto-Danksharding comes in.

Proto-Danksharding (officially named EIP-4844) will introduce a new type of transaction to Ethereum, and these transactions will unlock a new kind of short-term storage.

These new transactions are called 'blob-carrying transactions'. And, believe it or not, ‘blob’ is a technical term. It's short for Binary Large Object, which refers to an arbitrarily large chunk of data. So, when we say 'blob-carrying transaction', we just mean a transaction that is associated and travelling with some piece of data. Data that might, for example, summarise a whole bunch of L2 transactions. But, the word ‘blob’ is also quite appropriate here. I find it useful to think of these data chunks as literal sticky blobs that can cling to an Ethereum block like a barnacle on a boat. And, just as barnacles are scraped off of boats before they cause problems, these blobs will be scraped off of blocks and discarded before they overwhelm the network.

Yes, this is the big improvement that Proto-Danksharding will bring. Any data contained in a blob will only be stored on Ethereum for a few weeks. After that, anyone in the Ethereum network is free to delete and forget about that data forever, reducing the burden on all those devices. It's safe to do this because that information doesn't need to be stored for eternity. At least, not by all parties. The important thing is that the L2 data is distributed and made available to anyone who might need it. Sticking it onto the outside of an Ethereum block and distributing it across an un-censorable global network is a pretty good way to ensure all interested parties have access. After a few weeks, those parties should have had plenty of time to make permanent copies or do whatever they need to do with that data.

Blob-carrying transactions are a big win for Ethereum. The short-term storage minimises the strain placed on the Ethereum network and doesn't threaten its decentralisation in the way permanent storage might. It's also good for the L2s. Because short-term storage is less burdensome than permanent storage, a greater quantity can be offered at a much lower price. Therefore, Layer Twos won't need to pay anywhere near the costs they currently pay to settle on Ethereum, and they can pass those savings on to end users.

Overall, then, Proto-Danksharding and blob-carrying transactions represent a massive step forward for Ethereum and its layered scaling ambitions. But, you're probably wondering, what has any of this got to do with the whole KZG thing that we started with? Well, you're about to find out.

We've just seen that a 'blob-carrying transaction' is a transaction sent alongside and associated with some arbitrary piece of data. As well as travelling together, the transaction and blob are associated through a special reference or summary that is embedded in the transaction. It's worth noting, because it's part of a transaction and included in an Ethereum block, this reference does become a permanent part of Ethereum's history -- even after the blob itself is discarded.

The reference is something called a KZG Commitment to the blob. Well, more accurately it's a versioned hash of a KZG Commitment to the blob, but that's not super important to us here. KZG Commitments, and commitment schemes in general, can be used to prove ownership or knowledge of some information without revealing the information itself. Later, after the information is revealed, the commitment can be used to authenticate that information. That authentication would fail if there was even a single, tiny difference between the information committed to and the information revealed. In the case of Proto-Danksharding, KZG Commitments give users an efficient way to verify that blobs contain all the information they supposedly contain and that L2s aren't misbehaving. KZG Commitments can also be used to prove that a certain piece of data was contained in a blob. This is essential for a type of L2 called an Optimistic Rollup, as they rerun disputed transactions on Ethereum to verify the results. Of course, there's no point rerunning a transaction that never actually happened on the L2, which is where the KZG proof comes in. When someone raises a dispute, they must also provide a KZG proof to show the disputed transaction took place and was included in a blob.

KZG Commitments were chosen over alternative commitment schemes for several reasons. For starters, they're simpler to implement than the alternatives. That reduces the opportunity for errors or exploitable weaknesses to make it into the code. They're also fairly cheap and efficient to work with -- which helps Ethereum's drive for decentralisation. They work well with Zero Knowledge Proofs, which is essential for a type of L2 called a ZK Rollup. And, perhaps most importantly, they lay the foundations for another future upgrade called Data Availability Sampling. There are only two notable downsides to KZG Commitments. First, they're not quantum-resistant, so there could be security issues if someone develops a powerful quantum computer. Frankly, that's not worth worrying about today, and when it does happen there will be so many other things at risk it probably won't matter much then either. The second issue is more immediately concerning. KZG Commitments require something called a trusted setup. And, that's where the Summoning Ceremony comes in.

I don't want to get too bogged down in how KZG Commitments work for two reasons. One, I just don't have the maths skills to understand and explain them properly. And two, even if I did have those skills, you probably don't care much anyway. Still, I think it's useful to have at least a vague understanding of what's going on here. So, here goes.

To generate a KZG Commitment, the data being committed to is first converted into a polynomial. You'll probably remember these from maths class as equations that look something like:

In this case, the polynomial will be much bigger and scarier than anything you encountered at school, but it's essentially the same thing. That polynomial is then evaluated at certain points -- which is to say, some numbers are plugged in to see what comes out. And, that stuff that comes out is the KZG Commitment. When someone wants to verify the data later on, they can effectively repeat the process. By evaluating the polynomial at the same points, they can see if the output matches the original commitment. If it does, everything is fine and the data was the same. If it doesn't, then something has been changed.

Now, here's the bit that's most relevant to us. The numbers that are plugged into the equation should remain secret. Like, really secret. Not even the developers setting this whole thing up should know what they are. If someone did know the numbers, they could cheat the system by crafting a new polynomial that produced the same output. In other words, they could commit to one set of data, then change it entirely but still provide a valid proof. This would, quite obviously, undermine the entire system, so it cannot be allowed to happen.

This raises some questions. First, how can numbers be kept secret, but also passed around so everyone can commit to or verify the date? Second, how can anyone trust that t hose numbers are genuinely secret? After all, someone has to come up with those numbers, and surely they'd know what numbers they'd selected.

Let's start with the first question. How are the numbers kept secret? Well, for clever mathematicians, this is fairly easy. The answer is using something called an elliptic curve. Elliptic curves are a special family of curves defined by equations that look like:

If you plug some numbers into that equation and draw the results on a graph, the curve you see is an elliptic curve. These curves have some weird and unique properties that make them particularly useful in maths, computer science, and cryptography. In fact, a whole bunch of important cryptography -- including much of the cryptography in this industry -- relies on elliptic curves. The properties we care about most are that points on an elliptic curve can be added together to produce a third point that is also on the curve. When this is done, it's difficult to predict where the third point will be. And, when points are repeatedly added together, it's incredibly difficult to determine how many times the points were added. Mathematicians can use this to hide numbers inside an elliptic curve. Essentially, they take the 'secret' number and add elliptic curve points to themselves that many times. The output of this calculation is a list of elliptic curve points that appear totally random when plotted on a graph. This is called a Structured Reference String (SRS), and an attacker could study it to their heart's content without ever learning anything about the secrets held inside. However, quite amazingly, the SRS still contains enough information about the secret values to be useful in constructing KZG Commitments.

That answers the first question. Ethereum can keep its secret numbers secret by hiding them inside an elliptic curve. The secret can be represented and passed around in the form of elliptic curve points -- a long list of seemingly random, disconnected numbers called a Structured Reference String. These numbers contain enough information for the KZG scheme to work, but not enough for attackers to undermine the system. But where does the SRS come from? Who produces it, and how can they reassure others that they don't know the secrets held within?

The answer here is to use something called a trusted setup, and the principle of it should be pretty familiar to anyone interested in cryptoassets. After all, this industry's entire purpose is to remove singular trusted entities and replace them with large, disparate networks of individual operators, thereby increasing overall trust in the system. Yes, the idea of a trusted setup is to involve as many people as possible in crafting the Structured Reference String. So, instead of one person contributing the entire secret, and then promising they don't know what that secret is, a trusted setup involves a large number of people each contributing a small portion of the overall secret. Each individual contribution is cleverly mixed in so that no one can determine what anyone else added. That way, even if someone knew exactly what they had entered, they wouldn't be any closer to discovering the ultimate, combined secret. In fact, the only way to discover the combined secret would be for every single participant to work together to recreate it. Put another way, provided the group contains at least one honest actor, the final secret can never be known. This is called a 1-of-N trust model. Alternatively, you might like to think of it like a Horecrux trust model -- an attacker must discover every single secret (like destroying every Horecrux) to beat the system. The larger the group of contributors, the more difficult that task becomes. It's like, if Voldemort had created 1000 Horecruxes, he probably wouldn't have lost. And, that's kind of intuitive, right? As the group gets larger, the probability that it contains at least one honest actor also increases. And so, the goal of a trusted setup is to maximise the number of honest, independent participants.

At some point, when enough different people contribute to the setup, the 'trusted' setup becomes effectively a 'trustless' setup. That's why some people prefer to use different, arguably less misleading, names for the process. For example, Ethereum's trusted setup is called a 'Summoning Ceremony'. Whatever you want to call them, trusted setups have been around for a while now. Zcash held the first high-profile setup in 2016. That was a fairly complicated and involved process, so the ceremony only included 6 very knowledgeable participants. Modern setups tend to be simpler and more accessible, enabling hundreds or even thousands of participants to take part. Ethereum's Summoning Ceremony will be the biggest trusted setup yet -- and by a massive margin. More than 120,000 contributions have been made so far, easily making this the most trustless trusted setup ever.

Now we understand the principle, but how does the Summoning Ceremony actually work? Well, it's kind of like a game of pass-the-parcel played backwards. In this case, the parcel is the set of elliptic curve points. By "played backwards", I mean each player adds something to the mix instead of removing something. And, as you can probably guess, the thing being added is the participant's secret random number. In the middle of all of this is a 'sequencer' or 'coordinator', who keeps everything organised and running smoothly. For the KZG Ceremony, the coordinator is a server run by the Ethereum Foundation. It keeps track of who wants to participate, orders participants, and verifies their contributions. If the ceremony is like a game of pass-the-parcel, then perhaps the coordinator is the parent overseeing the game and ensuring it's played properly. Of course, the idea of this special, powerful entity at the heart of the ceremony may concern you. If so, don't worry, we'll come back to this in the next section. For the moment I want to go a little deeper into how each participant in the ceremony adds their random number into the mix.

When a participant joins the Ceremony, they generate a secret random number. Later, when the coordinator says it's their turn, they will receive a long list of more than 4000 numbers. This is the set of elliptic curve points containing the combination of all previous participants' secrets. Now, the participant can mix their secret in as well, and they do this through multiplication. They take their secret number, and essentially just multiply each of the elliptic curve points by that number. OK, it's a little more complicated than that. In truth, they multiply by their number to a power according to where the point is in the list. So, it's to the power of 0 at the first point, the power of 1 at the second, the power of 2 at the third, and so on. Plus, importantly, this is all done over something called a finite field. These work a bit like a clock in that numbers reach some maximum value and then loop back around to a lower bound. That means two numbers could be multiplied together to produce a smaller number. Still, essentially just multiplication. Once they've done that, they discard their secret and send the updated list of numbers back to the coordinator. The coordinator performs a quick validation and then sends the list to the next participant to repeat the process.

I found it useful to see this written out a little more mathematically, but feel free to skip this paragraph if you're not into it. With some generic equations, the process looks like this. The participant receives a bunch of elliptic curve points that can be written like:

where G is some generic starting point for the elliptic curve being used and s is the combination of all previous participants' secrets (which our participant doesn't know). The participant has randomly created their own secret value t, which they can now multiply in:

Which is equivalent to:

From this, we can see that the final secret, produced at the very end of the Ceremony, is just a product of every individual participant's secrets. And, each elliptic curve point is related through those secrets, despite appearing as a random selection of numbers. As long as each individual keeps their secret to themselves, it would be extremely difficult to determine what numbers were multiplied together to produce the final set of elliptic curve points. In fact, because the finite field keeps everything looping around, it's impossible to work it out.

Participants in Ethereum's KZG Summoning Ceremony will be doing this for two sets of elliptic curve points each time. That's because the KZG Scheme requires two sets of related but slightly different points to work. They will also do the entire process four times over. As in, four entirely different setups with four different pairs of elliptic curve points, each with a different length. This is part of Ethereum's plan to future-proof things as much as possible. In the future, it may be desirable to make certain changes to blobs -- changes that would necessitate a longer set of elliptic curve points to produce secure commitments. If that happened, a new Ceremony would be required to produce those points, creating unnecessary delay and hassle. So, Ethereum's developers had an idea: why not run multiple setups at the same time? That way, everything is ready and waiting for if/when those changes are made.

Earlier we saw that the Summoning Ceremony relies on a special entity called the 'Coordinator' to keep things running smoothly. And, to someone interested in cryptoassets, that might raise an alarm. Doesn't the Coordinator sound like the kind of privileged central player that we want to eliminate?

Of course, the answer is yes. The coordinator is certainly a privileged party, and I'm sure it would have been eliminated if that were possible. Unfortunately, it's quite essential to the Ceremony. However, the coordinator's powers are quite limited, and all its actions are published for everyone to inspect and verify. This should minimise the threat it poses. The worst thing the Sequencer could do is unfairly exclude a participant. For example, it could incorrectly reject their valid contribution. But, because its actions are published, everyone would see that happening and know the Ceremony was compromised. Additionally, there will be a validation process at the end of the Ceremony. Every participant will be able to verify that their contribution was genuinely included in the final product. This transparency is incredibly important. If anyone raises any genuine concerns at any point in the setup, the social consensus will be to reject the Ceremony and start over -- making any changes necessary to prevent the problem from happening again. As a result, I don't think the coordinator poses a real threat to the procedure.

Realistically, the only other threat to the Ceremony is some massive technical failure. For example, a bug might cause every participant's secret to leak. If that happened, then it would be possible to reconstruct the final secret, regardless of the number of honest participants. However, the chance of this happening is extraordinarily low -- especially because a lot of effort has gone into minimising the risk. For starters, there are multiple implementations of the contribution software, and they're all built using different technologies. For every contribution to leak, the same bug would have to be present across all of those different variations. It would need to work on every type of device, on every browser, every single time the process runs. In short, it's totally unrealistic. And yet, there are even more protections in place. In addition to allowing standard contributions through the browser, people have also been invited to make special contributions to the Ceremony. In special contributions, participants can generate their secret random number in all sorts of wacky and weird ways. For example, they might use a Geiger counter, a cat toy, or an explosion as a source of entropy -- though, presumably not all of them at once. The point is, however these numbers are generated, it's utterly inconceivable that they would all leak alongside all of the standard contributions. And, remember, that is exactly what would have to happen to truly undermine the ceremony. As long as a single number remains secret, the final output also remains secret. Therefore, I think it's pretty safe to say the Summoning Ceremony's secret is safe and sound.

Getting involved in the KZG Ceremony is extremely easy, and the requirements for entry are very low. You will need only three things:

1. A computer to contribute from. Unfortunately, mobile devices will not work here.

2. A valid browser (which seems to be anything other than Safari)

3. Either:

   • An Ethereum Account that had made at least 8 transactions before January 13th 2023

   • A GitHub account

These restrictions are to try and prevent massive Sybil attacks. When the Ceremony first opened, the lobby was frequently flooded with airdrop farmers each trying to contribute with multiple addresses. While that's not necessarily a problem, it was limiting the number of unique users that could take part. As a result, the rules were adjusted so that most participants are relatively unique humans and not tens of thousands of identical robots.

If you meet those criteria, then read on to see how you can contribute.

Head to https://ceremony.ethereum.org/ and click begin.

A new tab will open. This is where you generate your secret random number.

As the page explains, the randomness comes from three sources. The first is called the secret, which is whatever you type into the text box. This can be as long or short as you'd like. The only suggestion is that you try to add something a bit random into the mix so even you don't know what you've written. The second source is called the sigil, which is taken from your cursor's movements. The third source is called the sample, which your browser will generate in the background.

So, type something in the text box and squiggle your mouse around. You'll see the serpent's tail growing longer as you move your mouse. You need to keep jiggling until it eats itself. Then, click submit.

You'll be asked to sign in.

As mentioned earlier, you can either use Github or your Ethereum address. If you use your Ethereum address, it will ask you to sign a couple of messages from Sign In With Ethereum. Don't worry, this won't cost you anything or take any assets from your wallet, it's just signing a message. But, as you should every time you sign a message, just take a moment to double-check that everything looks legitimate.

The hard work is all done now, and all you need to do is wait. Just don't close the window or switch your computer off until you receive a confirmation message.

The screen will tell you how many others are in this waiting room with you. The coordinator will make random selections from this room when choosing who to go next, rather than selecting on any kind of first-come-first-served basis. That makes it impossible to know quite how long you'll have to wait.

When I initially contributed earlier in the year, it took several days before I was selected. But, at that time the waiting room generally contained several thousand people. The waiting room is much less full these days, so I'd imagine the waiting time will be measured in hours at worst. This time through, it took less than 10 minutes.

Eventually, the screen will change to let you know you have received the Structured Reference String -- here called the Powers of Tau -- and that your secrets are being mixed in.

The screen will change again once the calculations have completed and the Coordinator has received your updated SRS. When you see this, congratulations: you have just contributed to Ethereum's next upgrade!

At the time of writing, there is just over a day left to get your contributions in. The Ceremony will be open until the 23rd of July. At that point, I would imagine they will just close the lobby for new entrants, so anyone already inside will be allowed to complete their contributions. However, if you do want to contribute, it’s probably best to get in sooner rather than later to avoid disappointment.
And, if you are on the fence about whether to contribute or not, I would definitely recommend it. After all, it takes very little effort and you’ll be able to say you were a part of this special moment in Ethereum’s history.

If you want to do any further reading on KZG Commitments, I would recommend  this piece by Inevitable Ethereum or this blog post by Dankrad Feist (the Dank in Proto-Danksharding).

Follow Topic Crypto

• 📺 Youtube: https://www.youtube.com/c/TopicCrypto

• 🐦 Twitter: https://twitter.com/topiccrypto

• 📚 Medium: https://medium.com/topic-crypto

• 📚 Mirror: https://mirror.xyz/topiccrypto.eth

Disclaimer: Anything expressed here is my own opinion stated for informational and educational purposes; nothing I say should be taken as investment or financial advice. Many projects mentioned on this channel are highly experimental and therefore come with risks. Please evaluate your own risk tolerance before experimenting with these projects.

I may own some of the cryptoassets mentioned. At the time of upload (July 2021), I own: Bitcoin (BTC), Ether (ETH), and USDC

Ethereum needs you!

Ethereum's next major upgrade is in development and -- for the first time -- ordinary, non-technical people like you and I can help create it. But, the time to help is running out. You have just days left left to make your contribution. So, if you want to get involved, you need to do it soon. I'll show you exactly what you need to do to take part in this historic opportunity. And, don't worry, the whole process is incredibly easy, costless, and risk-free. In fact, it's as simple as wiggling a mouse and clicking a few buttons. Sounds good, right?

But, before I show you what you need to do, I should probably explain why this is happening in the first place.

What you'll be contributing to is called the KZG Summoning Ceremony.

Now, I appreciate that's a bit of a weird and fancy name that probably doesn't mean anything to you. So, what is it?

The short answer is that it's a trust-minimised process for setting up a new cryptographic scheme that Ethereum will be using after its next update. That update is called Proto-Danksharding (or EIP-4844), and it's all about cutting the cost of data storage to make Ethereum a better foundation for Layer Two platforms.

Again, that may well sound like a load of gobbledygook. If so, stick with me. To really understand this we first need to establish a little background information.

If you paid any attention to crypto in the last bull run, then you probably heard a lot of people saying the same thing: "Ethereum sucks!" That's because, during times of high demand, Ethereum transactions are both slow and expensive -- especially when compared to competitors like Solana. You might assume this is because Ethereum is older than the cheaper blockchains and therefore has worse, outdated technology. However, that's not the case. In reality, Ethereum's poor performance and high fees are entirely intentional. You might think that's crazy. After all, why would anyone choose to provide a terrible user experience? In reality, it's because Ethereum is simply prioritising something else: decentralisation.

There's a lot that could be said here, but I'm going to save most of it for another time. What you need to know is that Ethereum is designed to minimise the barrier to entry for anyone wanting an active role in the network. In practice, that means the Ethereum software must be able to run on all sorts of computers -- including fairly cheap, low-powered ones. Therefore, Ethereum blocks cannot contain a large quantity of transactions or data because that would overwhelm the low-end computers in the network. As a result, it doesn't take a significant increase in transaction volume to saturate Ethereum's blocks. When that happens, users are forced to outbid one another to ensure their transaction is prioritised and included in a block. And that very quickly spirals into the sky-high transaction fees we all love to complain about.

Of course, Ethereans recognise the problem here. They certainly don't want to create a system that anyone can help run but only the rich can afford to use. And so they've come up with a plan. One that will allow them to retain the accessible, decentralised core of the system while also increasing capacity and reducing transaction fees. And that plan is called 'Layered Scaling'.

Layered scaling is ultimately about aggregating as much activity as possible into a small number of Ethereum transactions. The idea is to shift most day-to-day transactions away from Ethereum and onto new 'Layer Two' (L2) platforms. These platforms are built with performance in mind, ensuring transaction fees remain low even when demand is high. Then, every so often, all of the recent L2 transactions will be batched, compressed, and represented in a single transaction on Ethereum. In this way, all the activity still takes place on the Ethereum blockchain, just in a less direct manner. All the same, it means all of the L2 transactions are still verified and secured by Ethereum. That leads to the ultimate win-win scenario for end users. They still enjoy all the benefits of Ethereum and its robust, decentralised design but they don't suffer with its low throughput, slow transactions, and exorbitant fees.

Years of research have convinced Ethereans that this layered approach is the best way to build and scale a blockchain. The problem is, Ethereum wasn't built with this methodology in mind. So, some modifications are required to get the most out of a more modular design.

One of the biggest issues is storing data. Remember how Layer Twos aggregate all their recent transactions and represent them in a single Ethereum transaction. Well, that Ethereum transaction must contain a fair amount of data -- essentially a summary of all the L2's recent activity. And, here's the problem, Ethereum only has one kind of data storage: permanent. When an L2 -- or anyone else, for that matter -- posts a bunch of data to Ethereum, everyone in the Ethereum network must hold onto that data forever. That's not easy to do, and it places a significant burden on the computers in the network. So, this isn't good for Ethereum. Especially because its priority has always been minimising the burden on those computers to keep the network decentralised. The situation is also not good for the L2s. Ethereum doesn't want people filling blocks with data and overwhelming the low-end computers in the network, so it charges a high price for data storage. As a result, L2s must pay a lot of money to make their settlement transaction on Ethereum, and the L2's users must pay higher fees to account for that. Again, this is particularly silly when the whole point of the L2s is to provide a low-fee environment. So, we need a better solution for storing data. And, this is where Proto-Danksharding comes in.

Proto-Danksharding (officially named EIP-4844) will introduce a new type of transaction to Ethereum, and these transactions will unlock a new kind of short-term storage.

These new transactions are called 'blob-carrying transactions'. And, believe it or not, ‘blob’ is a technical term. It's short for Binary Large Object, which refers to an arbitrarily large chunk of data. So, when we say 'blob-carrying transaction', we just mean a transaction that is associated and travelling with some piece of data. Data that might, for example, summarise a whole bunch of L2 transactions. But, the word ‘blob’ is also quite appropriate here. I find it useful to think of these data chunks as literal sticky blobs that can cling to an Ethereum block like a barnacle on a boat. And, just as barnacles are scraped off of boats before they cause problems, these blobs will be scraped off of blocks and discarded before they overwhelm the network.

Yes, this is the big improvement that Proto-Danksharding will bring. Any data contained in a blob will only be stored on Ethereum for a few weeks. After that, anyone in the Ethereum network is free to delete and forget about that data forever, reducing the burden on all those devices. It's safe to do this because that information doesn't need to be stored for eternity. At least, not by all parties. The important thing is that the L2 data is distributed and made available to anyone who might need it. Sticking it onto the outside of an Ethereum block and distributing it across an un-censorable global network is a pretty good way to ensure all interested parties have access. After a few weeks, those parties should have had plenty of time to make permanent copies or do whatever they need to do with that data.

Blob-carrying transactions are a big win for Ethereum. The short-term storage minimises the strain placed on the Ethereum network and doesn't threaten its decentralisation in the way permanent storage might. It's also good for the L2s. Because short-term storage is less burdensome than permanent storage, a greater quantity can be offered at a much lower price. Therefore, Layer Twos won't need to pay anywhere near the costs they currently pay to settle on Ethereum, and they can pass those savings on to end users.

Overall, then, Proto-Danksharding and blob-carrying transactions represent a massive step forward for Ethereum and its layered scaling ambitions. But, you're probably wondering, what has any of this got to do with the whole KZG thing that we started with? Well, you're about to find out.

We've just seen that a 'blob-carrying transaction' is a transaction sent alongside and associated with some arbitrary piece of data. As well as travelling together, the transaction and blob are associated through a special reference or summary that is embedded in the transaction. It's worth noting, because it's part of a transaction and included in an Ethereum block, this reference does become a permanent part of Ethereum's history -- even after the blob itself is discarded.

The reference is something called a KZG Commitment to the blob. Well, more accurately it's a versioned hash of a KZG Commitment to the blob, but that's not super important to us here. KZG Commitments, and commitment schemes in general, can be used to prove ownership or knowledge of some information without revealing the information itself. Later, after the information is revealed, the commitment can be used to authenticate that information. That authentication would fail if there was even a single, tiny difference between the information committed to and the information revealed. In the case of Proto-Danksharding, KZG Commitments give users an efficient way to verify that blobs contain all the information they supposedly contain and that L2s aren't misbehaving. KZG Commitments can also be used to prove that a certain piece of data was contained in a blob. This is essential for a type of L2 called an Optimistic Rollup, as they rerun disputed transactions on Ethereum to verify the results. Of course, there's no point rerunning a transaction that never actually happened on the L2, which is where the KZG proof comes in. When someone raises a dispute, they must also provide a KZG proof to show the disputed transaction took place and was included in a blob.

KZG Commitments were chosen over alternative commitment schemes for several reasons. For starters, they're simpler to implement than the alternatives. That reduces the opportunity for errors or exploitable weaknesses to make it into the code. They're also fairly cheap and efficient to work with -- which helps Ethereum's drive for decentralisation. They work well with Zero Knowledge Proofs, which is essential for a type of L2 called a ZK Rollup. And, perhaps most importantly, they lay the foundations for another future upgrade called Data Availability Sampling. There are only two notable downsides to KZG Commitments. First, they're not quantum-resistant, so there could be security issues if someone develops a powerful quantum computer. Frankly, that's not worth worrying about today, and when it does happen there will be so many other things at risk it probably won't matter much then either. The second issue is more immediately concerning. KZG Commitments require something called a trusted setup. And, that's where the Summoning Ceremony comes in.

I don't want to get too bogged down in how KZG Commitments work for two reasons. One, I just don't have the maths skills to understand and explain them properly. And two, even if I did have those skills, you probably don't care much anyway. Still, I think it's useful to have at least a vague understanding of what's going on here. So, here goes.

To generate a KZG Commitment, the data being committed to is first converted into a polynomial. You'll probably remember these from maths class as equations that look something like:

In this case, the polynomial will be much bigger and scarier than anything you encountered at school, but it's essentially the same thing. That polynomial is then evaluated at certain points -- which is to say, some numbers are plugged in to see what comes out. And, that stuff that comes out is the KZG Commitment. When someone wants to verify the data later on, they can effectively repeat the process. By evaluating the polynomial at the same points, they can see if the output matches the original commitment. If it does, everything is fine and the data was the same. If it doesn't, then something has been changed.

Now, here's the bit that's most relevant to us. The numbers that are plugged into the equation should remain secret. Like, really secret. Not even the developers setting this whole thing up should know what they are. If someone did know the numbers, they could cheat the system by crafting a new polynomial that produced the same output. In other words, they could commit to one set of data, then change it entirely but still provide a valid proof. This would, quite obviously, undermine the entire system, so it cannot be allowed to happen.

This raises some questions. First, how can numbers be kept secret, but also passed around so everyone can commit to or verify the date? Second, how can anyone trust that t hose numbers are genuinely secret? After all, someone has to come up with those numbers, and surely they'd know what numbers they'd selected.

Let's start with the first question. How are the numbers kept secret? Well, for clever mathematicians, this is fairly easy. The answer is using something called an elliptic curve. Elliptic curves are a special family of curves defined by equations that look like:

If you plug some numbers into that equation and draw the results on a graph, the curve you see is an elliptic curve. These curves have some weird and unique properties that make them particularly useful in maths, computer science, and cryptography. In fact, a whole bunch of important cryptography -- including much of the cryptography in this industry -- relies on elliptic curves. The properties we care about most are that points on an elliptic curve can be added together to produce a third point that is also on the curve. When this is done, it's difficult to predict where the third point will be. And, when points are repeatedly added together, it's incredibly difficult to determine how many times the points were added. Mathematicians can use this to hide numbers inside an elliptic curve. Essentially, they take the 'secret' number and add elliptic curve points to themselves that many times. The output of this calculation is a list of elliptic curve points that appear totally random when plotted on a graph. This is called a Structured Reference String (SRS), and an attacker could study it to their heart's content without ever learning anything about the secrets held inside. However, quite amazingly, the SRS still contains enough information about the secret values to be useful in constructing KZG Commitments.

That answers the first question. Ethereum can keep its secret numbers secret by hiding them inside an elliptic curve. The secret can be represented and passed around in the form of elliptic curve points -- a long list of seemingly random, disconnected numbers called a Structured Reference String. These numbers contain enough information for the KZG scheme to work, but not enough for attackers to undermine the system. But where does the SRS come from? Who produces it, and how can they reassure others that they don't know the secrets held within?

The answer here is to use something called a trusted setup, and the principle of it should be pretty familiar to anyone interested in cryptoassets. After all, this industry's entire purpose is to remove singular trusted entities and replace them with large, disparate networks of individual operators, thereby increasing overall trust in the system. Yes, the idea of a trusted setup is to involve as many people as possible in crafting the Structured Reference String. So, instead of one person contributing the entire secret, and then promising they don't know what that secret is, a trusted setup involves a large number of people each contributing a small portion of the overall secret. Each individual contribution is cleverly mixed in so that no one can determine what anyone else added. That way, even if someone knew exactly what they had entered, they wouldn't be any closer to discovering the ultimate, combined secret. In fact, the only way to discover the combined secret would be for every single participant to work together to recreate it. Put another way, provided the group contains at least one honest actor, the final secret can never be known. This is called a 1-of-N trust model. Alternatively, you might like to think of it like a Horecrux trust model -- an attacker must discover every single secret (like destroying every Horecrux) to beat the system. The larger the group of contributors, the more difficult that task becomes. It's like, if Voldemort had created 1000 Horecruxes, he probably wouldn't have lost. And, that's kind of intuitive, right? As the group gets larger, the probability that it contains at least one honest actor also increases. And so, the goal of a trusted setup is to maximise the number of honest, independent participants.

At some point, when enough different people contribute to the setup, the 'trusted' setup becomes effectively a 'trustless' setup. That's why some people prefer to use different, arguably less misleading, names for the process. For example, Ethereum's trusted setup is called a 'Summoning Ceremony'. Whatever you want to call them, trusted setups have been around for a while now. Zcash held the first high-profile setup in 2016. That was a fairly complicated and involved process, so the ceremony only included 6 very knowledgeable participants. Modern setups tend to be simpler and more accessible, enabling hundreds or even thousands of participants to take part. Ethereum's Summoning Ceremony will be the biggest trusted setup yet -- and by a massive margin. More than 120,000 contributions have been made so far, easily making this the most trustless trusted setup ever.

Now we understand the principle, but how does the Summoning Ceremony actually work? Well, it's kind of like a game of pass-the-parcel played backwards. In this case, the parcel is the set of elliptic curve points. By "played backwards", I mean each player adds something to the mix instead of removing something. And, as you can probably guess, the thing being added is the participant's secret random number. In the middle of all of this is a 'sequencer' or 'coordinator', who keeps everything organised and running smoothly. For the KZG Ceremony, the coordinator is a server run by the Ethereum Foundation. It keeps track of who wants to participate, orders participants, and verifies their contributions. If the ceremony is like a game of pass-the-parcel, then perhaps the coordinator is the parent overseeing the game and ensuring it's played properly. Of course, the idea of this special, powerful entity at the heart of the ceremony may concern you. If so, don't worry, we'll come back to this in the next section. For the moment I want to go a little deeper into how each participant in the ceremony adds their random number into the mix.

When a participant joins the Ceremony, they generate a secret random number. Later, when the coordinator says it's their turn, they will receive a long list of more than 4000 numbers. This is the set of elliptic curve points containing the combination of all previous participants' secrets. Now, the participant can mix their secret in as well, and they do this through multiplication. They take their secret number, and essentially just multiply each of the elliptic curve points by that number. OK, it's a little more complicated than that. In truth, they multiply by their number to a power according to where the point is in the list. So, it's to the power of 0 at the first point, the power of 1 at the second, the power of 2 at the third, and so on. Plus, importantly, this is all done over something called a finite field. These work a bit like a clock in that numbers reach some maximum value and then loop back around to a lower bound. That means two numbers could be multiplied together to produce a smaller number. Still, essentially just multiplication. Once they've done that, they discard their secret and send the updated list of numbers back to the coordinator. The coordinator performs a quick validation and then sends the list to the next participant to repeat the process.

I found it useful to see this written out a little more mathematically, but feel free to skip this paragraph if you're not into it. With some generic equations, the process looks like this. The participant receives a bunch of elliptic curve points that can be written like:

where G is some generic starting point for the elliptic curve being used and s is the combination of all previous participants' secrets (which our participant doesn't know). The participant has randomly created their own secret value t, which they can now multiply in:

Which is equivalent to:

From this, we can see that the final secret, produced at the very end of the Ceremony, is just a product of every individual participant's secrets. And, each elliptic curve point is related through those secrets, despite appearing as a random selection of numbers. As long as each individual keeps their secret to themselves, it would be extremely difficult to determine what numbers were multiplied together to produce the final set of elliptic curve points. In fact, because the finite field keeps everything looping around, it's impossible to work it out.

Participants in Ethereum's KZG Summoning Ceremony will be doing this for two sets of elliptic curve points each time. That's because the KZG Scheme requires two sets of related but slightly different points to work. They will also do the entire process four times over. As in, four entirely different setups with four different pairs of elliptic curve points, each with a different length. This is part of Ethereum's plan to future-proof things as much as possible. In the future, it may be desirable to make certain changes to blobs -- changes that would necessitate a longer set of elliptic curve points to produce secure commitments. If that happened, a new Ceremony would be required to produce those points, creating unnecessary delay and hassle. So, Ethereum's developers had an idea: why not run multiple setups at the same time? That way, everything is ready and waiting for if/when those changes are made.

Earlier we saw that the Summoning Ceremony relies on a special entity called the 'Coordinator' to keep things running smoothly. And, to someone interested in cryptoassets, that might raise an alarm. Doesn't the Coordinator sound like the kind of privileged central player that we want to eliminate?

Of course, the answer is yes. The coordinator is certainly a privileged party, and I'm sure it would have been eliminated if that were possible. Unfortunately, it's quite essential to the Ceremony. However, the coordinator's powers are quite limited, and all its actions are published for everyone to inspect and verify. This should minimise the threat it poses. The worst thing the Sequencer could do is unfairly exclude a participant. For example, it could incorrectly reject their valid contribution. But, because its actions are published, everyone would see that happening and know the Ceremony was compromised. Additionally, there will be a validation process at the end of the Ceremony. Every participant will be able to verify that their contribution was genuinely included in the final product. This transparency is incredibly important. If anyone raises any genuine concerns at any point in the setup, the social consensus will be to reject the Ceremony and start over -- making any changes necessary to prevent the problem from happening again. As a result, I don't think the coordinator poses a real threat to the procedure.

Realistically, the only other threat to the Ceremony is some massive technical failure. For example, a bug might cause every participant's secret to leak. If that happened, then it would be possible to reconstruct the final secret, regardless of the number of honest participants. However, the chance of this happening is extraordinarily low -- especially because a lot of effort has gone into minimising the risk. For starters, there are multiple implementations of the contribution software, and they're all built using different technologies. For every contribution to leak, the same bug would have to be present across all of those different variations. It would need to work on every type of device, on every browser, every single time the process runs. In short, it's totally unrealistic. And yet, there are even more protections in place. In addition to allowing standard contributions through the browser, people have also been invited to make special contributions to the Ceremony. In special contributions, participants can generate their secret random number in all sorts of wacky and weird ways. For example, they might use a Geiger counter, a cat toy, or an explosion as a source of entropy -- though, presumably not all of them at once. The point is, however these numbers are generated, it's utterly inconceivable that they would all leak alongside all of the standard contributions. And, remember, that is exactly what would have to happen to truly undermine the ceremony. As long as a single number remains secret, the final output also remains secret. Therefore, I think it's pretty safe to say the Summoning Ceremony's secret is safe and sound.

Getting involved in the KZG Ceremony is extremely easy, and the requirements for entry are very low. You will need only three things:

1. A computer to contribute from. Unfortunately, mobile devices will not work here.

2. A valid browser (which seems to be anything other than Safari)

3. Either:

   • An Ethereum Account that had made at least 8 transactions before January 13th 2023

   • A GitHub account

These restrictions are to try and prevent massive Sybil attacks. When the Ceremony first opened, the lobby was frequently flooded with airdrop farmers each trying to contribute with multiple addresses. While that's not necessarily a problem, it was limiting the number of unique users that could take part. As a result, the rules were adjusted so that most participants are relatively unique humans and not tens of thousands of identical robots.

If you meet those criteria, then read on to see how you can contribute.

Head to https://ceremony.ethereum.org/ and click begin.

A new tab will open. This is where you generate your secret random number.

As the page explains, the randomness comes from three sources. The first is called the secret, which is whatever you type into the text box. This can be as long or short as you'd like. The only suggestion is that you try to add something a bit random into the mix so even you don't know what you've written. The second source is called the sigil, which is taken from your cursor's movements. The third source is called the sample, which your browser will generate in the background.

So, type something in the text box and squiggle your mouse around. You'll see the serpent's tail growing longer as you move your mouse. You need to keep jiggling until it eats itself. Then, click submit.

You'll be asked to sign in.

As mentioned earlier, you can either use Github or your Ethereum address. If you use your Ethereum address, it will ask you to sign a couple of messages from Sign In With Ethereum. Don't worry, this won't cost you anything or take any assets from your wallet, it's just signing a message. But, as you should every time you sign a message, just take a moment to double-check that everything looks legitimate.

The hard work is all done now, and all you need to do is wait. Just don't close the window or switch your computer off until you receive a confirmation message.

The screen will tell you how many others are in this waiting room with you. The coordinator will make random selections from this room when choosing who to go next, rather than selecting on any kind of first-come-first-served basis. That makes it impossible to know quite how long you'll have to wait.

When I initially contributed earlier in the year, it took several days before I was selected. But, at that time the waiting room generally contained several thousand people. The waiting room is much less full these days, so I'd imagine the waiting time will be measured in hours at worst. This time through, it took less than 10 minutes.

Eventually, the screen will change to let you know you have received the Structured Reference String -- here called the Powers of Tau -- and that your secrets are being mixed in.

The screen will change again once the calculations have completed and the Coordinator has received your updated SRS. When you see this, congratulations: you have just contributed to Ethereum's next upgrade!

At the time of writing, there is just over a day left to get your contributions in. The Ceremony will be open until the 23rd of July. At that point, I would imagine they will just close the lobby for new entrants, so anyone already inside will be allowed to complete their contributions. However, if you do want to contribute, it’s probably best to get in sooner rather than later to avoid disappointment.
And, if you are on the fence about whether to contribute or not, I would definitely recommend it. After all, it takes very little effort and you’ll be able to say you were a part of this special moment in Ethereum’s history.

If you want to do any further reading on KZG Commitments, I would recommend  this piece by Inevitable Ethereum or this blog post by Dankrad Feist (the Dank in Proto-Danksharding).

Follow Topic Crypto

• 📺 Youtube: https://www.youtube.com/c/TopicCrypto

• 🐦 Twitter: https://twitter.com/topiccrypto

• 📚 Medium: https://medium.com/topic-crypto

• 📚 Mirror: https://mirror.xyz/topiccrypto.eth

Disclaimer: Anything expressed here is my own opinion stated for informational and educational purposes; nothing I say should be taken as investment or financial advice. Many projects mentioned on this channel are highly experimental and therefore come with risks. Please evaluate your own risk tolerance before experimenting with these projects.

I may own some of the cryptoassets mentioned. At the time of upload (July 2021), I own: Bitcoin (BTC), Ether (ETH), and USDC