Huge thank you to VΞΞR for providing the pictures of the event that are used within this blog post. And thank you to Trent Van Epps and Carl Beekhuizen for helping me in various ways throughout the contribution process.
Ethereum is moving towards the adoption of EIP-4844 (also known as "Proto-Danksharding") which would introduce a new data-carrying "blob" transaction type and significantly increase the amount of data that Ethereum can make available.
For reasons that I won't get into within this blog post, the Ethereum community came to the conclusion that the commitment scheme introduced by Kate, Zaverucha, and Goldberg (aka the "KZG commitment" scheme) was the best mechanism available for committing to the data within 4844 blob transactions. One of the most visible downsides to the KZG commitment is its reliance on a trusted setup. I think the following Vitalik quotes do a great job at explaining how a modern multi-party trusted setup works:
A trusted setup ceremony is a procedure that is done once to generate a piece of data that must then be used every time some cryptographic protocol is run.
... hundreds of people participate in generating the data together, and only one of them needs to be honest and not publish their secret for the final output to be secure. Well-executed setups like this are often considered "close enough to trustless" in practice.
You can basically think of a multi-party trusted setup like a community coming together to cook a special stew that should only be cooked once (else the stew gods smite the community for their soupy sins, or something). Each member of the community tosses in a secret ingredient and makes sure not to tell anyone else what they added to the pot. After all, someone who knows all of the ingredients can cook the stew again. Note that the recipe can't be reproduced as long as just a single person manages to keep their ingredient a secret.
Of course this isn't a perfect analogy but it's close enough to what's happening that I think it'll probably fly.
Back to KZG. Starting in January of 2023, the Ethereum community began to coordinate the KZG Ceremony. Because the security of the system only dependes on a single participant correctly concealing their secret from the rest of the world it's obviously ideal to get as many participants as possible. The Ethereum community absolutely demolished the previous record for the most contributions to a public trusted setup (XXXX held by YYYY) with a total of ZZZZ contributions over approximately three months.
Many of the contributions made during this "open" contribution period were carried out via the KZG Ceremony website which, to the best of my knowledge, pulled most of its entropy for each commitment from user mouse movements. Some contributions were likely also made via some of the various open source client implementations which allow users to supply their own entropy. The website significantly increased the accessibility of the KZG Ceremony.
The KZG Ceremony is a serial process, meaning only one contribution can be processed at a time. You must have access to the previous state of the system from the "coordinator" (aka the Sequencer) in order to generate the next contribution, which you then send back to this coordinator.
The serial nature of the KZG Ceremony introduces some annoying denial of service vectors. Users need to be given a certain amount of time to complete their contribution but users can't be given too much time or you'd risk malicious users essentially spamming the ceremony and dragging it out forever. You can mitigate this attack vector somewhat by (1) cutting the contribution time down to a minimum and (2) introducing some filtering on the users that are allowed to participate.
Unfortunately these mitigations introduce their own problems. Filtering users can potentially create a sense of unfairness or gatekeeping. I think the community handled this well by providing two reasonable options such that you could participate if:
- You held a private key that corresponded to an Ethereum address with at least three transactions or
- You had a GitHub account
Both of these options come with relatively low barriers to entry (especially the Ethereum address option) while still introducing a small cost to spam the system. I didn't see anyone complaining about these requirements. Sufficiently many people participated in the process that the line of people waiting to submit contributions was often hours or even days long. Certainly annoying but at least suggests that the requirements were not a significant barrier to entry. Gud job Ethereum!
Cutting down the contribution time also had an unforunate side-effect: it made interesting contributions more difficult. Contributions made on air-gapped machines require a back-and-forth shuttling of information in a reasonably secure way that can take longer than the allotted time window. Other contributions might take place in locations with little-to-no internet connectivity at all, like the now-famous contribution by Andrew Miller and Ryan Pierce to the Zcash Sapling ceremony that took place in a small airplane.
Besides being generally more secure, these sorts of "fun" contributions also help spread awareness about the KZG Ceremony to various parts of the internet because, well, they're cool. So it was decided that the KZG Ceremony would also have a "special contribution period" during which some selected participants would be given longer periods of time to make interesting contributions to the Ceremony.
I was very lucky to be the recipient of a grant from the Ethereum Foundation to create a "unique" form of entropy and participate in the "special contribution period" of the Ceremony.
My contribution was MR. MOLOCH'S EPHEMERAL ALBUM PARTY.
MR. MOLOCH'S EPHEMERAL ALBUM PARTY was a ~12 hour long endeavour in which a large group of people created an album, used a recording of that album as the entropy for a KZG Ceremony contribution, and then deleted the album (forever, forever, ever, forever, ever?).
MR. MOLOCH'S EPHEMERAL ALBUM PARTY was sort of meant to act something like a digital [[Sand Mandala]] — an exercise in virtual creation and destruction. You can only really get so far with an album in 12 hours but some of the songs were really good. We've done something like this twice so far (so this was technically MR. MOLOCH'S EPHEMERAL ALBUM PARTY, PART TWO) and there are always at least a few moments where people are incredibly tempted to save a song for future reference. This temptation is, of course, [[Moloch]] rearing its ugly head.
The name ("Moloch") is, obviously, a meaningful part of the exercise. It's heavily influenced by the vision of Moloch as presented by Scott Alexander in Meditations on Moloch which itself is an offshoot of the representation by Ginsberg in Howl. Alexander's Moloch is the beast that arises from human coordination failure at scale.
Solving these coordination problems and ultimately "slaying Moloch" is the stated goal of many projects within the cryptocurrency ecosystem (most famously the aptly named [[MolochDAO]]). We spend an enormous amount of time and energy pushing against what is essentially a demon-god that, if you take the problem seriously, really, actually exists within the world.
Challenging Moloch is fun. It is also immensely tiring. Sometimes we deserve to coordinate for fun, for the sake of producing mostly nothing. MR. MOLOCH'S EPHEMERAL ALBUM PARTY is human coordination designed to stick a finger up at the problem altogether. We will exert energy and the universe gets nothing.
The Ceremony
MR. MOLOCH'S EPHERMAL ALBUM PARTY began at ~10am and participants trickled in throughout the day. Album making began in earnest at ~noon.
We decided the album would be a bit of a meditation on AI and used a lot of ChatGPT to generate lyrics and themes. AI and Moloch are a good combo, clearly. We finished most of the album by about ~8pm.
Audio recording was strictly prohibited to prevent entropy leaks (as much as we could reasonably prevent them). We made a ~13 hour long recording of the entire process. It seems I can't upload videos that long to YouTube but I'm working on figuring out the right place to host it.
Once the album was ready, we played through the entire thing once and recorded it into four separate airgapped T400 laptops running USB-hosted Tails. We used the onboard microphones to add some extra entropy. The recordings were, as a result, highly lossy but also meant we got good variation in the recordings going into each machine.
After the album was played once and the recordings were complete, I generated four KZG commitments using the audio files as entropy. This process is a bit tedious and involves going back and forth between an internet-connected computer and each of the airgapped computers.
Aaaand once all of that was done, we went ahead and deleted the recordings from each of the USB devices hosting Tails and from the machines that were used to generate the music in the first place. To be really, super, extra sure that everything was gone from the USB sticks, we smashed them to pieces with a big hunk of concrete.
We also destroyed one of the laptops. That probably wasn't entirely necessary but you can never be too careful!
After the ceremony was complete, the whole thing turned into a more of a chill party than anything else. Things started winding down at around 11pm. A few people stayed until ~1am cleaning things up.
Closing Thoughts
MR. MOLOCH'S EPHEMERAL ALBUM PARTY was quite the experience. I'm very thankful to the Ethereum Foundation for providing me with a grant to help make this a reality. This is the sort of stuff that makes Ethereum such a fun environment to work within.
We took a lot of safety precautions with entropy leaks, so the contributions should be sound! I've uploaded the contribution receipts onto this site so you can download and inspect them if you want. See below.
We'll probably do something like this again in the future (sans KZG commitments). If you're in NYC and interested in coming to the next ephemeral album party, let me know!