Anti-Correlation Penalties

Thanks, I'm excited to present some of our latest work, which is an extremely ambitious project to implement multiple concurrent proposers in Ethereum. This is early stage joint work with my serial co-author, Melesh Pai, who works with me at SMG, Alberto Cendino, who's at Miston, one of the co-authors of the Mistaseti paper, Wakim Ngu, who's at A16Z, who's written a lot of the NoMoreAttacks on ETH proof-of-stake papers, and Goldfish, and Joe Bonu, who's a cryptographer at NYU, who's written a lot about VDFs and other kind of delay cryptography. So why do we get the Avengers together? Because we want to change how Ethereum works fundamentally to be a system of execution consensus separation. So let's see if this clicker plays the video.

Here's how execution consensus separation works. We have multiple proposers. We submit transactions to each of them. Each of those transactions goes into an unordered list, and we union them all together. Here, transaction two was submitted to proposer one and four.

It's deduplicated. We create an unordered set, and then we apply the terministic ordering function, which is O here. In this case, in reverse priority order. So this is the basic idea of how execution consensus separation works. And the main reason we want to do it is to kill MEV.

So why do we think that this will help kill MEV? Because at the end of the day, MEV is about two things, reordering and censorship. So you can choose which transactions go into the block, and you can choose which order they go in. And one of the critical primitives for building MEV-resistant applications is an auction. And it turns out that running an auction on Chain today in Ethereum's current architecture is very hard because there's a single proposer who can include bids.

That proposer has an outsized amount of economic impact on what goes into the block, and they end up extracting a ton of rent. So that's why you see these numbers like $600 million a year of PBS revenue to proposers, all due to that proposer monopoly. So here's a formal definition of censorship, starting with what object could be censorship resistant. So a public bulletin board is an abstraction of a blockchain that has two operations, write and read. The write operation has two inputs, a message and a tip.

Critically, the tip is very important here. You look at other definitions of censorship resistance, they don't necessarily incorporate the tip, but of course if you have a tornado cash transaction with a $100 tip, it's going to be a lot easier to include it than one with a $0.10 tip. So going into our definition, now that we know what a bulletin board is, we can say, let's describe this mapping phi, which says, given a tip, what is the minimum cost it would take a motivated adversary to censor that transaction? And that depends on the architecture of the blockchain.

So since I only have five minutes, we'll skip to a theorem about this, which says currently in a blockchain like Ethereum today, which is leader-driven, we have a censorship resistance of just T, the identity function. You put in $1, you get $1 of censorship security. But if we have multiple concurrent proposers, there's multiple people who can include you, and so we get to the point where we have more censorship resistance, and in particular we can get a linear increase or even more. You can see some more details in the paper. Intuition being more people, you have to bribe them all to exclude the transaction.

Getting into Braid, this is the basic architecture. It kind of looks like a DAG, except that there's no cross sub-chain votes here. All votes are on the same thread. We have multiple parallel chains running something like an LMD ghost. And then we take the union of all the transactions in all of the blocks in slot three, for example.

And then we take the union of all the transactions in all of the blocks in slot three, for example. And then we apply the deterministic ordering rule. So it inherits a lot of the properties from a traditional LMD ghost. So liveness inherited from LMD ghost and eventual consistency inherited from LMD ghost because if one chain is eventually consistent, then the whole system is eventually consistent at the pace of the slowest chain. What does it mean to be eventually consistent?

It means everybody agrees on what the state of the chain looks like. All the local replicas that are honest have that agreement eventually. And once you have that eventually thing, you can apply Byzantine agreement protocol, and you can say all of the honest inputs know what the chain looks like, now we can finalize and that's how basically Asper works. So this is an extension of LMD Ghost, it also works for a bunch of other protocols. I'll stop there because that's my time and take some questions.

Okay, thank you very much. Can we give the mic to answer questions? Hi, have you considered or modeled the bandwidth impact of this or considered proposals where you have multiple proposers but not every block, maybe only every X block? Yeah, I mean, the goal for this was really to solve MEB, so we do want it every block. On your second question, on the first question, what are the bandwidth implications?

There's, like, naively if you implement this, you get a linear increase in bandwidth because you have linear increase in blocks. You can do some things with the messages where you combine all the vote messages on each of the individual chains into a single message from the attesters. That can reduce some of the overhead, but it is obviously going to be higher overhead because you can't get something for nothing. Hello? for nothing.

Hello. I just wanted to suggest that in the every block version, it allows users to make that MEV trade-off where they might have to wait a little bit longer if they want the MEV guarantee, but they can still get it in a reasonable period of time if you have every X block. Yeah, the problem is that the MEV that we're worried about is not for the user. It's not necessarily just sandwiching. We're really worried about the MEV that the protocols leak themselves, so stuff like arbitrage.

And so Uniswap can't just necessarily turn off their contract. I guess maybe they could if we gave them the tools to do that. But the problem is you might have some arbitrage opportunity available, and it's available in the single proposer slot, and you don't have time to wait because the game theory says you're just going to take it right away. How does this interact with the encrypted mempool specification that's being proposed right now? Right, so I have a controversial view that private transaction submission is basically inevitable, and encrypted mempool is one way to do that.

One nice thing about this property, like this proposal, is that the interface for inclusion goes from I have a set of transactions and an order that I execute them in to I only include a set of transactions. So that's a lot more compatible with encrypted mempool because, you know, I just choose either to include or not include. And the decision problem is not like this huge knapsack disgusting problem that we have today with the builders. And then another thing, like I didn't get to do it because I didn't have time, but we have a bunch of things about how do we keep the blocks sealed long enough for all of the blocks sealed long enough for all of the blocks to be released basically simultaneously. That's a critical game theoretic property for the kind of MEV properties that we want to achieve, and that's why we brought in Joe on the cryptography side.

We've been working. There's tons of, there's like four different proposals, commit reveal, commit reveal force open, threshold encryption, and delay encryption, kind of in order of complexity that we're working on them all. We have time for more one question. I'll say one more thing, which is that I have a longer version of this talk later today at sequencing day at, I think, 1 p.m.

on the research stage there so if you're interested in seeing more of those details about the encryption, about some more of the consensus stuff, come there and I'll share some more details. Cool, thank you very much Max.