Ethereum Ceremony – Add your randomness to prepare the way for EIP-4844
ceremony.ethereum.org
ceremony.ethereum.org
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.
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
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.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.
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