BRAID: Implementing Multiple Concurrent Proposers by Max Resnick | Devcon SEA

[Music] thanks I'm excited to present some of our latest work which is a extremely ambitious project to implement multiple concurrent proposers in ethereum this is early stage joint work with my serial co-author mes pie who works with me at SMG Alberto sanino who's at miston one of the co-authors of the M deti paper W new who's at a6z who's written a lot of the uh no more attacks on eth proof of stake papers and um goldfish and Joe Banu 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 it's duplicated we create an unordered set and 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 me so why do we think that this will help kill me because at the end of the day meev 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 meev 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 than one with a 10cent tip so going into our definition now that we know what a bulletin board is we can say let's describe this mapping fi 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 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 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 so so getting into braid this is the basic architecture so it kind of looks like a dag except that there's no cross subchain um 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 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 um 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 Gasper works so this is an extension of lmd ghost it also works for a bunch of other protocols uh I'll stop there because that's my time and take some questions okay thank you very much M can we give the mic to answer a question I have you considered or modeled the bandwidth impact of this um or um considered um proposals where you have uh multiple proposers but not every block maybe only every like X block yeah I mean the goal for this was really to solve me so we do want it every block um 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 uh increase in bandwidth because you have linear increase in blocks uh you can do some things with the messages where you comine all the vote messages on each of the individual chains into a single message from the testers uh that can reduce some of the overhead but it is obviously going to be higher overhead because you can't get something for nothing yeah hello um I I just wanted to to suggest that in the every eth block uh version uh it allows users to make that M tradeoff where they might have to wait a little bit longer if they want the M guarantee but they can still get it in a reasonable period of time if you have every X SWAT yeah the problem is that the me that we're worried about is not for the user it's not necessarily just sandwiching we're really worried about the me that the protocols leak themselves so stuff like Arbitrage and so Unis swap can't just necessarily turn off uh their contract I guess maybe they could if we gave them the tools to do that but 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 in fact or is how does this interact with the encrypted men poool specification that's being proposed right now right so I like have a controversial view that private transaction submission is basically inevitable and um encrypted mle is like 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 men poool because you know I just choose either to include or not- include and the decision problem is not like this huge napsack disgusting problem that we have today with the builders and then another thing like I didn't get to do it cuz 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 to be released basically simultaneously um that's a critical game theoretic property for the kind of Me 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 for more one question I'll say one more thing which is that uh I have a longer version of this talk later today at sequencing day at uh I think 1M 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 okay cool thank you very much Max [Applause]