Toni Wahrstätter

Anti-Correlation Penalties is a proposal to allow the penalties for missed attestations to vary over slots, based on the number of missed attestations in the respective slots. This is great for non-correlated parties such as solo stakers and improves decentralization, fault tolerance and diversity in the validator set.

Stage 4

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.

https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6736d52974749a4b892bca29.vtt

Demonstrate how we collect data from the Ethereum network and how it's used for upgrades, research, and analytics. We'll then run through some examples of how to use the tools and public datasets yourself.

Classroom D

Reading Ethereum's Tea Leaves with Xatu data

 Hey, good morning everyone. Thank you for coming to our workshop today. Before we start, if you have any questions just throw your hand up. It'll be pretty relaxed, so yeah. Just look into the workshop overview. Introduction, that's us right now. We're going to go into Xar2 Genesis, see sort of how it happened, why it happened, and then we'll look into the data sets that have emerged since. We'll then progress into how we're using the data, how others are using the data. Leo over here will then present. He's from the Megalabs team. He'll present the big blocks test that happened last year, and then we'll have a live tutorial from Tony. He'll go through how he uses Paisa to run his analysis. Sweet. So a little intro on who we are. I'm Sam. That's Andrew. He's hiding. We've both been doing DevOps on the PandaOps team for the last few years. And we both have a deep appreciation for things like Ethereum and observability. As for our team, ETH Panda Ops, we started out in 2021, being thrown straight into the deep end with the merge. We're embedded in the F and do DevOps for the protocol. And we post blogs semi-frequently on our website. We try to keep them really high signal. They're the best way to keep up to date with us. Scan the QR code and it'll jump you straight there. Our team has a pretty wide range of projects cooking at all times. You've probably come across a couple of them. For example, if you've ever run a node, you've probably checkpoint synced from an endpoint that was running checkpoint Z. You may have also seen Parry and Barnabas whipping core devs in the core dev calls. Yeah, there's a lot of stuff going on. So let's move on to the workshop. To set the scene, it's late 2022 to the workshop. To set the scene, it's late 2022 and the merger's just happened. We've switched from proof of work to proof of stake, but in doing so, our consensus mechanism has become a lot more sensitive to time. Suddenly the when of things happening has become a lot more important. And this data at a global and network level doesn't really exist. It's easy to check that a block was seen, but it's much harder to see when that block was actually seen in Sydney compared to Berlin, for example. And now that we're clear from the merge, researchers start hacking away. They want to upgrade the beacon chain. But yeah, they need this timing data to validate their ideas. And they start capturing it themselves. Varying scales, different implementations. It's hard to expose, it's hard to validate. There's a bit of potential errors in there. So we started to brainstorm ideas on how to solve our problems. We needed to somehow integrate with existing beacon node implementations as neither of us were really too keen to implement a full beacon node. As DevOps engineers, we'd usually just implement a few Prometheus metrics, put the feet up and call it a day. But millisecond-level precision is pretty important, so that rules out Prometheus metrics. Log aggregation was also another option, but it's definitely a moving target. These things change all the time. It's not really something that the client devs really pay too much attention to. And we'd also just have to turn on debug-level logging. We'd be throwing the kitchen sink at our log aggregation pipeline, and it would potentially be an unreliable result anyway. So that rules out logs. So we started to look at other options. Turns out that the beacon API has this thing called the event stream. You can subscribe to it, and when the beacon node sees things or does things, it will emit an event. So blocks, attestations, voluntary exits, everything. It was all there. The beautiful thing is that the beacon node implementation all supported this endpoint in a standardized fashion. So what we landed on was Zatu. We used Go, gRPC, and we thought that it would be responsible for just collecting Ethereum timing data. It definitely wasn't going to be trying to store or query that data, but the plan was to derive events and ship them somewhere else. To do this, we initially created two modules. Zatu's server would create events from other modules, would collect events from other modules and send them somewhere else, and Zatu's Sentry was our first module. It would run as a sidecar next to every beacon node, modules and send them somewhere else. And Zartu Sentry was our first module. It would run as a sidecar next to every beacon node, subscribe to events, and send them off to Zartu server. We wanted to make sure that all of the events followed the same structure so that it was much easier to add new events into the future. And also, really importantly, since this is like a distributed system, we wanted to make it clear how much you could trust the data. So data coming from a client is not necessarily trusted, but if it's been derived by Xar2's server, something that we control, maybe you can trust it a bit more. This example event is for one of our Xaru sentry nodes running on mainnet, subscribing to a beacon node, and a new block has just come in. I've redacted a couple of the fields, but yeah, that's the general idea. That's all great, but we still hadn't really solved where to send the data. And it turns out it was a lot of data.

https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67358b949dbb7a90e19ee9d9.vtt