As usual, the crypto hate is strong to the point of going full-bore irrational from all the enlightened souls on this site, despite this ethereum event being far from a typical crypto bro crank job and instead being a sincere effort to improve the quality of something with plausible usability, that these people have invested lots of time in working on. This makes it different from so many other complex if imperfect programming projects how? Or perhaps now that Ether has shifted from the so lovingly hated PoW mechanism to PoS, some other thing has to be scorned, rational analysis be damned?
Might add that much of the crypto hate on HN comes from the same circle of people who more recently swallow nearly anything AI-related with absurdly wide eyed applause. People who actually insinuate that LLM systems are some genuine new form of intelligence, despite absolutely no factual signs of that and plenty of reasons for worry about perfectly human use-case dangers, which make the worst of crypto seem minor in comparison.
How can they claim 'it is secure as long as one person forgets their secret' and 'we need to protect against sybil attacks (so sign in with your github account)' ? If the first claim was true, why should they care if the same person takes part multiple times.
> How can they claim 'it is secure as long as one person forgets their secret' and 'we need to protect against sybil attacks (so sign in with your github account)' ? If the first claim was true, why should they care if the same person takes part multiple times.
> 'it is secure as long as one person forgets their secret'
This is from the 1-of-N security assumption of the cryptographic procedure, wherein at least 1 person is actually honest and destroys their own secret to ensure its security. With a large enough N, this security assumption is made guaranteed due to the non-zero probability of human nature for deviant behavior from the rest of the group, wherein at least 1 person will be honest and perform as specified.
> 'we need to protect against sybil attacks (so sign in with your github account)'
...this claim ignores the large visible button right above the 'or unlock with Github' link, that prompts the user to sign in with their Ethereum address.
The reason to provide some sibyl protection/spam protection mechanism is so that every one that wants to contribute can do so. The ceremony is secure if there is 1 out of N that correctly destroyed its secret. You individually, may not trust any one else, but then you should be allowed to contribute a secret and delete it, in order for you to trust the ceremony output. If you are prevented from contributing because there are bots filling up the queue then you won't be able to trust the ceremony. I think it's a sensible constraint from the crypto fetishists.
There is an upperbound to the amount of contributions due to how slow adding one is because of the computation needed. The goal of the ceremony is to have as many different people contribute as possible. Without protecting against Sybil attacks an attacker can reduce the number of contributors by hogging the limited number of contribution slots that are available during the ceremony.
You can imagine an extreme case of a ceremony only allowing for 5 contributions. Wouldn't you want to have some sort of protection against all 5 of those contributions being from the same person?
At this point, I'm willing to give the Ethereum developers the benefit of the doubt.
They've really knocked some major features out of the park over the last few years. Namely, they switched the entire consensus model out, while the plane was flying full of people and that went off pretty much without a hitch.
Don't forget that this also had the side effect of significantly cutting power usage not only for ETH, but also for every single other GPU mined PoW chain out there.
So yea... they made something creative out of the process of the next round of improvements, and invited you to join. Seems cool to me.
> At this point, I'm willing to give the Ethereum developers the benefit of the doubt.
Accidental* crypto developer here.
The most consistent behavior from Ethereum developers is designing “clever home-brewed mechanisms” because they are ”very smart”, and then it turns out this is yet another dirty hack that'll need more dirty hacks in the future to circumvent all its flaws.
It's 2023, stop giving the benefit of the doubt to arrogant cranks that have consistently proven over almost a decade that they really are arrogant cranks.
Well, the entirety of the “Web3” API is a pile of hacks, but my “favorite” is probably eip-1559 (and not for the “political” reasons, like “make eth deflationary”, it's just very annoying to work with).
This is like complaining about the HTTP protocol because you don't like the requests Python library. There is no "Web3" API as part of the Ethereum protocol. "Web3" APIs (in plural because there are multiple ones, in different programming languages) are externally built libraries that expose in an API details about the Ethereum blockchain (blocks, transactions, gas consumed in a block, base fee, etc...). If you don't like a particular library, you can use a different one, or build your own.
EIP-1559 has never been patched. It's still functioning as it was conceived. A minor clarification is that it was not introduced to make ETH deflationary, and in fact, it doesn't guarantee in any way that it will be deflationary. It's a side effect of demand for settling on Ethereum exceeding the current issuance of ETH. In much the same way the supply of oil may go down if demand for it is greater than its production.
In what ways is it annoying to work with EIP-1559? It's, I would argue, much simpler than it was in the past, as you now have a pre-defined base fee to pay to be included in a block. But perhaps you have something else in mind.
> This is like complaining about the HTTP protocol because you don't like the requests Python library. There is no "Web3" API as part of the Ethereum protocol. "Web3" APIs (in plural because there are multiple ones, in different programming languages) are externally built libraries that expose in an API details about the Ethereum blockchain (blocks, transactions, gas consumed in a block, base fee, etc...). If you don't like a particular library, you can use a different one, or build your own.
The Web3 API is the API exposed by the full node themselves, and it exposes the requirement of the ethereum protocol (example: the nonce, the encoding scheme for smart contracts, the primitives operation of the EVM, etc) . It is then wrapped inside libraries in different languages (and you can write your own) but the underlying stuff is constrained by the blockchain protocol itself (you cannot make the nonce mechanism less stupid no matter how hard you try, for instance, the nodes will just reject your transaction if you don't follow the dumb protocol).
> EIP-1559 has never been patched. It's still functioning as it was conceived.
Yes, it's the latest hack to have been added to the stack, but it's a hack that obsoleted the former hack, and will end up being obsoleted one day.
> In what ways is it annoying to work with EIP-1559? It's, I would argue, much simpler than it was in the past, as you now have a pre-defined base fee to pay to be included in a block.
Except if there's congestion, and the base fee isn't enough so you get your transaction rejected, and you have to guess which base fee to set given that it may have increased once more in the meantime. And so to make sure that your transaction get accepted and does not bounce again, you need to overpay (too bad for a change that was supposed to get rid of overpay…)
Many things in Ethereum stops working well as soon as you leave the full node itself and develop a third party service relying on its RPC endpoint (which is nonetheless the mainstream way to do it).
> the nodes will just reject your transaction if you don't follow the dumb protocol
Calling things dumb doesn't help your argument at all. It should reject your transaction if you don't follow the rules.
> Except if there's congestion, and the base fee isn't enough so you get your transaction rejected
Subtle, but important point: The transaction isn't rejected. It is not picked up out of the mempool and sits there until the congestion goes down. Again, this is supply/demand pricing and that's ok in a system like this.
> Subtle, but important point: The transaction isn't rejected. It is not picked up out of the mempool and sits there until the congestion goes down.
Not if you submit another transaction in the meantime, because then your initial transaction's nonce will have become invalid.
Now you start to get why I called the nonce system “dumb”, because it has emergent implications with lots of things like this, for no good reason (the requirement should be nonce's uniqueness, that's enough for transaction deduplication, but they felt smart and added the “monotonically increasing” as well, and boom, concurrent transaction processing is a nightmare now, well done).
> The Web3 API is the API exposed by the full node themselves, and it exposes the requirement of the ethereum protocol (example: the nonce, the encoding scheme for smart contracts, the primitives operation of the EVM, etc) . It is then wrapped inside libraries in different languages (and you can write your own) but the underlying stuff is constrained by the blockchain protocol itself (you cannot make the nonce mechanism less stupid no matter how hard you try, for instance, the nodes will just reject your transaction if you don't follow the dumb protocol).
Some execution client implementations also expose gRPC and GraphQL APIs, if you would prefer a differentcommunication protocol.
The Web3 APIs are built on top of these underlying APIs exposed by the nodes.
The nonce protocol is indeed rather dumb, but that's not a bad thing, sometimes things need to be specified to be as dumb as they can be. A transaction needs to have a nonce that is greater than the nonce of the last transaction to be included. I think that's pretty much it, if memory serves correct. Obviously nodes will reject transactions that do not meet the rules of the protocol, that's how protocols work.
> Yes, it's the latest hack to have been added to the stack, but it's a hack that obsoleted the former hack, and will end up being obsoleted one day.
EIP-1559 was introduced in 2021. Since then there have been several upgrades, to introduce Proof of Stake and withdrawals. The next upgrade, EIP-4844, will introduce blobspace and will use the same mechanism to price blobspace.
The only changes I have heard on the line regarding this are multi-dimensional EIP-1559 and MEV-burn. These do not alter the principles but keep building on an idea that is working rather well and extends it.
> Except if there's congestion, and the base fee isn't enough so you get your transaction rejected, and you have to guess which base fee to set given that it may have increased once more in the meantime. And so to make sure that your transaction get accepted and does not bounce again, you need to overpay (too bad for a change that was supposed to get rid of overpay…)
> The nonce protocol is indeed rather dumb, but that's not a bad thing, sometimes things need to be specified to be as dumb as they can be.
No, things should get as simple as they can be, the nonce mechanism isn't simple it's dumb: instead of just requiring uniqueness of the nonce, to make sure that there's no duplicate transaction, it attempts to be smart in order to “optimize” the nonce verification cost, and to do so it ads the monotonic increase requirement, and this additional* requirement is bad, because if you try to submit multiple transactions concurrently with the same wallet then you're are almost always going to face issues, with transactions being cancelled because they don't have a valid nonce (it was valid when you submitted it, but now it's not and your transaction is cancelled, sorry not sorry).
I had to switch back to bitcoin because Ehtereum just got way too bloated. I wish they'd focus some on making the software/protocol usable for a little while.
It's really the gnome of crypto: They're unconcerned about churn and feature creep and too focused on their own small culture.
I haven't kept up with the space in some time but if this is what I'm remembering, all that's needed is one participant in the ceremony to keep their secret forever/"lose" it for the security to be guaranteed. That's why as many participants as possible is a good thing.
all that said I'm a student/layman and not an expert in anything
What needs to go wrong for the safety of the Ceremony to break?
The ceremony has a "1-of-N" trust assumption, which means that only a single participant in the entire ceremony needs to destroy or otherwise forget their secret input for everything to be secure.
To break the Ceremony output, every participant would have to strip apart the software that they are using to contribute, get that software to give them the secret, and then collude with every single other participant to reconstruct the final secret.
A more realistic failure mode is a common bug which leaks the randomness. To combat this, this site has been audited and there are alternative implementations of the contribution software built on entirely different software stacks.
This is why there will be thousands of participants using different pieces of software on different operating systems to help prevent single points of failure both in the people and hardware/software.
What makes me think it is complicated is that a hash to all zeros would do this sort of a job, as no one could reverse this and find a key that would map to it. So whatever they are doing doesn’t have a natural “nothing up my sleeve” number and needs a social construct like this.
If I'm understanding you correctly, you're saying they don't need the social ceremony where everyone adds obfuscation, because there is some simple way for one user to derive the same security?
Does that not rely on us all trusting that initial user who "hashes to all zeroes" to maintain the secret? The goal here is not only to establish security but security anyone can participate in to add security, such that everyone trusts it, because anyone could have participated. Even if that's more complicated, it's more trustworthy.
Again though, I am not an expert in anything, I'm a student of computer science. I may be completely misunderstanding you and if I am, I apologize. It could be said though the social construct/contract is kind of the whole point of the decentralized protocols
Like you I am no expert. What I mean is you can construct a challenge that is provably very hard, such as a hash input that produces
zeros (translates to near infinite compute power in terms of mining, or some mathematical or quantum computing breakthrough that renders modern cryptography useless then this Ethereum thing is the least of your worries).
They don't need one number, they need two (or more) that are related in such a way they have cryptographic properties. And the math says to derive them from a seed. However the seed must be secret because it's a back-door.
Luckily everybody can generate their own seed and their contributions can be combined without knowing the seeds.
All zeros won't work because they don't have the properties.
"Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
So we just sweep basic accessibility and best practices under the rug because it’s common to screw it up? A little public shame should inspire the webmaster and comment readers to double-check their websites.
> > You need to enable JavaScript to run this app.
> What app? Why don’t folks do the bare minimum in their <noscript> elements to actually describe what it is that I’m missing out on.
Javascript is needed in order to generate random entropy client-side. This specific interface requires mouse movement, a secret phrase, & randomly generated entropy from the client itself.
1. Why aren’t they saying this in their <noscript>
2. There’s a lot of content on the page that should be purely static like the FAQs. We can see using a non-Google search like https://search.brave.com/search?q=kzg+ethereum+ceremony and see the SEO for all that data is missing because it requires JS without a good reason.
> 1. Why aren’t they saying this in their <noscript>
> 2. There’s a lot of content on the page that should be purely static like the FAQs. We can see using a non-Google search like https://search.brave.com/search?q=kzg+ethereum+ceremony and see the SEO for all that data is missing because it requires JS without a good reason.
Hanlon’s razor or ignornace is more likely than that. This message comes with the default framework and someone didn’t know they should check (and we should fault the framework for not throwing a build exception for missing noscript rather than inserting a useless one).
You can sum up what the site is and what’s missing in 1–3 sentences and have a massively better noscript experience, but this is the sort of thing that needs to be in project requirements. If you add these to your requirements to a project, you'll ultimately find the path of least resistance was to choose a framework/mindset that didn’t involve at unnecessary virtual DOM no 95% of the time render static (not dynamic) content. Adding a message to enable JS to add to the entropy gives users a simple, actionable message.
I ran the app and I see some countdown timer with 51 hours left which proposes me to do something I am struggling to understand. Also it has some plain-text faq but you know, nobody is storing just a plain text and it was made in such a way that every point is spoilered. There is indeed no reason to disallow seeing the faq for no-javascript users.
Well, the purpose of this site is to provide information and it’s not a web app. The goal of such site should be to make that info as accessible as possible with no reason to involve anything more complicated than absolutely necessary--not just towards users but also bots/scrapers for SEO. That generic <noscript> text is commonly from create-react-app or its ilk which should be reserved as technology for web apps. This is yet another example of a landing page that could+should be static pages with minimal JavaScript for progressive enhancement.
Might add that much of the crypto hate on HN comes from the same circle of people who more recently swallow nearly anything AI-related with absurdly wide eyed applause. People who actually insinuate that LLM systems are some genuine new form of intelligence, despite absolutely no factual signs of that and plenty of reasons for worry about perfectly human use-case dangers, which make the worst of crypto seem minor in comparison.
More doublespeak from crypto fetishists.
> 'it is secure as long as one person forgets their secret'
This is from the 1-of-N security assumption of the cryptographic procedure, wherein at least 1 person is actually honest and destroys their own secret to ensure its security. With a large enough N, this security assumption is made guaranteed due to the non-zero probability of human nature for deviant behavior from the rest of the group, wherein at least 1 person will be honest and perform as specified.
> 'we need to protect against sybil attacks (so sign in with your github account)'
...this claim ignores the large visible button right above the 'or unlock with Github' link, that prompts the user to sign in with their Ethereum address.
https://imgur.com/a/FkjcEQN
Aside from this, this is meant as one of the 2 methods of preventing bot spam, the other one being the sign in using an Ethereum address.
> More doublespeak from crypto fetishists.
Doublespeak is not present, joosters, as the two claims address different issues (1-of-N security of the KZG ceremony & bot spam).
You can imagine an extreme case of a ceremony only allowing for 5 contributions. Wouldn't you want to have some sort of protection against all 5 of those contributions being from the same person?
At this point, I'm willing to give the Ethereum developers the benefit of the doubt.
They've really knocked some major features out of the park over the last few years. Namely, they switched the entire consensus model out, while the plane was flying full of people and that went off pretty much without a hitch.
Don't forget that this also had the side effect of significantly cutting power usage not only for ETH, but also for every single other GPU mined PoW chain out there.
So yea... they made something creative out of the process of the next round of improvements, and invited you to join. Seems cool to me.
Accidental* crypto developer here.
The most consistent behavior from Ethereum developers is designing “clever home-brewed mechanisms” because they are ”very smart”, and then it turns out this is yet another dirty hack that'll need more dirty hacks in the future to circumvent all its flaws.
It's 2023, stop giving the benefit of the doubt to arrogant cranks that have consistently proven over almost a decade that they really are arrogant cranks.
[*]gotta pay the bills…
EIP-1559 has never been patched. It's still functioning as it was conceived. A minor clarification is that it was not introduced to make ETH deflationary, and in fact, it doesn't guarantee in any way that it will be deflationary. It's a side effect of demand for settling on Ethereum exceeding the current issuance of ETH. In much the same way the supply of oil may go down if demand for it is greater than its production. In what ways is it annoying to work with EIP-1559? It's, I would argue, much simpler than it was in the past, as you now have a pre-defined base fee to pay to be included in a block. But perhaps you have something else in mind.
The Web3 API is the API exposed by the full node themselves, and it exposes the requirement of the ethereum protocol (example: the nonce, the encoding scheme for smart contracts, the primitives operation of the EVM, etc) . It is then wrapped inside libraries in different languages (and you can write your own) but the underlying stuff is constrained by the blockchain protocol itself (you cannot make the nonce mechanism less stupid no matter how hard you try, for instance, the nodes will just reject your transaction if you don't follow the dumb protocol).
> EIP-1559 has never been patched. It's still functioning as it was conceived.
Yes, it's the latest hack to have been added to the stack, but it's a hack that obsoleted the former hack, and will end up being obsoleted one day.
> In what ways is it annoying to work with EIP-1559? It's, I would argue, much simpler than it was in the past, as you now have a pre-defined base fee to pay to be included in a block.
Except if there's congestion, and the base fee isn't enough so you get your transaction rejected, and you have to guess which base fee to set given that it may have increased once more in the meantime. And so to make sure that your transaction get accepted and does not bounce again, you need to overpay (too bad for a change that was supposed to get rid of overpay…)
Many things in Ethereum stops working well as soon as you leave the full node itself and develop a third party service relying on its RPC endpoint (which is nonetheless the mainstream way to do it).
Calling things dumb doesn't help your argument at all. It should reject your transaction if you don't follow the rules.
> Except if there's congestion, and the base fee isn't enough so you get your transaction rejected
Subtle, but important point: The transaction isn't rejected. It is not picked up out of the mempool and sits there until the congestion goes down. Again, this is supply/demand pricing and that's ok in a system like this.
> Many things in Ethereum stops working well
This is handwaving without actual examples.
Not if you submit another transaction in the meantime, because then your initial transaction's nonce will have become invalid.
Now you start to get why I called the nonce system “dumb”, because it has emergent implications with lots of things like this, for no good reason (the requirement should be nonce's uniqueness, that's enough for transaction deduplication, but they felt smart and added the “monotonically increasing” as well, and boom, concurrent transaction processing is a nightmare now, well done).
The nodes expose the JSON-RPC API, which is specified here: https://ethereum.github.io/execution-apis/api-documentation/
Some execution client implementations also expose gRPC and GraphQL APIs, if you would prefer a differentcommunication protocol.
The Web3 APIs are built on top of these underlying APIs exposed by the nodes.
The nonce protocol is indeed rather dumb, but that's not a bad thing, sometimes things need to be specified to be as dumb as they can be. A transaction needs to have a nonce that is greater than the nonce of the last transaction to be included. I think that's pretty much it, if memory serves correct. Obviously nodes will reject transactions that do not meet the rules of the protocol, that's how protocols work.
> Yes, it's the latest hack to have been added to the stack, but it's a hack that obsoleted the former hack, and will end up being obsoleted one day.
EIP-1559 was introduced in 2021. Since then there have been several upgrades, to introduce Proof of Stake and withdrawals. The next upgrade, EIP-4844, will introduce blobspace and will use the same mechanism to price blobspace.
The only changes I have heard on the line regarding this are multi-dimensional EIP-1559 and MEV-burn. These do not alter the principles but keep building on an idea that is working rather well and extends it.
> Except if there's congestion, and the base fee isn't enough so you get your transaction rejected, and you have to guess which base fee to set given that it may have increased once more in the meantime. And so to make sure that your transaction get accepted and does not bounce again, you need to overpay (too bad for a change that was supposed to get rid of overpay…)
https://arxiv.org/pdf/2201.05574.pdf
EIP-1559 reduced inclusion times and gas fees.
No, things should get as simple as they can be, the nonce mechanism isn't simple it's dumb: instead of just requiring uniqueness of the nonce, to make sure that there's no duplicate transaction, it attempts to be smart in order to “optimize” the nonce verification cost, and to do so it ads the monotonic increase requirement, and this additional* requirement is bad, because if you try to submit multiple transactions concurrently with the same wallet then you're are almost always going to face issues, with transactions being cancelled because they don't have a valid nonce (it was valid when you submitted it, but now it's not and your transaction is cancelled, sorry not sorry).
It's really the gnome of crypto: They're unconcerned about churn and feature creep and too focused on their own small culture.
all that said I'm a student/layman and not an expert in anything
Does that not rely on us all trusting that initial user who "hashes to all zeroes" to maintain the secret? The goal here is not only to establish security but security anyone can participate in to add security, such that everyone trusts it, because anyone could have participated. Even if that's more complicated, it's more trustworthy.
Again though, I am not an expert in anything, I'm a student of computer science. I may be completely misunderstanding you and if I am, I apologize. It could be said though the social construct/contract is kind of the whole point of the decentralized protocols
Luckily everybody can generate their own seed and their contributions can be combined without knowing the seeds.
All zeros won't work because they don't have the properties.
Just when I thought I couldn't hate crypto and the crypto community more I read this.
What app? Why don’t folks do the bare minimum in their <noscript> elements to actually describe what it is that I’m missing out on.
> What app? Why don’t folks do the bare minimum in their <noscript> elements to actually describe what it is that I’m missing out on.
Javascript is needed in order to generate random entropy client-side. This specific interface requires mouse movement, a secret phrase, & randomly generated entropy from the client itself.
> 2. There’s a lot of content on the page that should be purely static like the FAQs. We can see using a non-Google search like https://search.brave.com/search?q=kzg+ethereum+ceremony and see the SEO for all that data is missing because it requires JS without a good reason.
https://github.com/zkparty/trusted-setup-frontend
Occam's razor: Because they didn't think they'd need to put any additional message other than "Please enable JS", since almost everyone enables it.
It's likely they were "build the use case first" when going through with it, and that addressing "no JS" & SEO were not high on that priority list.
You can sum up what the site is and what’s missing in 1–3 sentences and have a massively better noscript experience, but this is the sort of thing that needs to be in project requirements. If you add these to your requirements to a project, you'll ultimately find the path of least resistance was to choose a framework/mindset that didn’t involve at unnecessary virtual DOM no 95% of the time render static (not dynamic) content. Adding a message to enable JS to add to the entropy gives users a simple, actionable message.
upd: I have discovered a link to off-the-app documentation: https://github.com/ethereum/kzg-ceremony