Transaction Level Hinting Considered Helpful - Rick Dudley

hi folks can you uh hear me okay [Music] yep all right great so uh not gonna really describe myself at all but i am this is not my domain of expertise mev i mean it's interesting me and phil talked about it many years ago um now which is sad because we're all aging and dying but um but yeah i mean this is not really my area of expertise a lot of the talks have been really good really interesting um so i i don't want to pretend to be i'm an expert all right i'm already accidentally clicking things all right great so transaction level hinting is considered helpful um yeah it'll be a while uh before i actually get to um what that actually means so you know take some time relax we're gonna go down memory lane a little bit here um you know ethereum has an identity problem and it's sort of come up in some of these discussions and i'm glad i made a slide about it um you know some people uh you know a lot of people um in this space make their living and make quite a good living uh because ethereum is a casino and then there are some of us who uh you know are foolish and uh believe that maybe we should be you know making a system for uh you know crypt verifiable cryptographic attestations of simple and safe computations which doesn't sound much like a casino right i mean it sounds like they're kind of opposites but that is kind of like a lot of the people in the space is one or the other and then of course there's people who think it's you know alien communication or whatever right um and so really uh you know why isn't it both i mean we can do both so we probably should do both given uh where we are in the space um and so here's the thing about mev if you think ethereum is like the house of a casino like it's like operating a set of casino games for people to gamble then you may think that like exploiting mev is breaking the rules like you're the house and you're supposed to be fair and you're not really being fair you're letting some people cheat and that's not cool but if you think ethereum should be safe then you must also want it to be predictable and what i mean by predictable is um so so just very briefly a secure in my definition means that other people can't tamper with it safe means that it does what you expect it to do and that it has predictable behavior and so the the problem that we really have well mev is contentious because it forces us to to recognize that ethereum has problems on like both of these axes right so um what we're going to get into here is some of these uh some of these broken zany models and and you know uh with all due respect to the to to gavin wood and the other people who were instrumental in the development of the system and the time crunch and the economic crunch and what have you uh that being said let's still go through some of the weirdness of the model right so one of the weirdest things hit that button again one of the weirdest things about um about ethereum is that by default which is very unsafe and very unusual in any sort of computer system and with all of the respective computer scientists that have spoken before me i'm a little confused as to why people don't bring this up more often but we have a transaction transaction contention as the default so in pretty much you know any toy system where you have multiple users they can't just muck around with each other's state information they can't just muck around with each other's memory you know windows 3 1 didn't have this problem right um well whatever so uh you know so then we have this other thing that's related to to this which is just broadly speaking um ethereum is a state machine right we use this term all the time we talk about it all the time the when we talk about ethereum as a world computer what we're talking about is we're talking about globally shared state and and that is actually where mev in my opinion there's a lot of different types of mev obviously people given a lot of different different definitions but ultimately the thing that we're trying to minimize are the problems that are created by users being able to muck around with each other's state when they shouldn't or when they don't expect to so maybe they maybe they're actually playing a game where part of the game is who can you know flip this bit first but then there's times where there's other games that people are playing and they don't realize that another player can come in and flip the bit out from underneath them and so uh a lot of problems in ethereum come through come from the way that we handle this merklized data structure which is kind of what i struggle with and wrestle with as a large part of my day job is is dealing with these stated difficulties so um and these will actually come into play uh later so keep them in mind because any time that you're trying to verify a block or generate a new block you're going to run into all of these stated difficulties so it's very difficult to read the data out of them the merkle tree that's that's going to be very difficult it's also very difficult to write data uh for similar reasons it's impossible to pre-fetch because all of your keys are random right so there's no way that you can you can cache data at all um totally random extremely uh frustrating your caching is like okay just throw like 120 gigs of data into ram that's not really awesome um the caching that does exist in the existing clients is almost entirely focused on consensus not on not on proof generation or general retrieval and so uh again if we're using ethereum we're using it because of proof right we're using it because consensus provides us a type of proof so if we're not leveraging that proof generation then why are we even using ethereum in the first place why don't we just use a centralized database as people love to say um and i think that that's a totally valid concern and you know the other thing that's pretty obvious is like we can't scale storage forever right so we have all this state we have all these weird things that are going on in state that are these weird side effects and at some point uh you know we're going to run out of disk space we have to have a way of truncating the chain and so when we talk about state rent and and uh whatever it's called now and regenesis and there's a whole bunch of things in the ethereum research community around how do we prune state and this is going to be very relevant um to the activity of of um block building and block production and so um and so right now we have a reality where if you use ethereum you can't get the summary if you're using uniswap.info you're relying on the graph to provide you the summary of the ethereum state that you use to transact with so like if you're making uh investment decisions based on uniswap.info you're actually trusting the graph to tell you what the state of ethereum is and there's no way for you to verify that and um ideally uh that graph entity uh the graph uh index or what have you would be um an entity within the ethereum consensus model they're people that you could slash within ethereum natively it would be you know a native part of the protocol and right now there's really no way to do that so you know if you want to keep it running you have to address some of these broken models right so the stated difficulties you know the issues with ethereum state i think absolutely uh are super high priority that's actually why i started working on 1559 which is a weird historic aside but like we have to start addressing these uh state issues anyway so and we have to address these mev issues anyway so we're going to address them together so these are a list of eips that are starting to get at the mechanisms that i'm describing um so the first one most important one transaction envelopes we can make new transaction types this is insanely important this is like a superpower for ethereum uh i'll just put a little plug here cosmos sdk has obviously supported this for a very long time but to have transaction types in ethereum is a significant improvement obviously no new transaction types no 1559 1559 will have a huge impact on on the mempool which no one else has brought up yet and that will in in turn have a huge impact on mev um i as an aside for anyone who may happen to know and can send me a message somewhere i don't know how we actually like have multiple you know these different trends we're putting each new feature in a new transaction and i don't know how we like unify those so that we have one transaction type like i don't know if anyone's actually described that yet um optional access lists so this is a list of addresses and storage keys that the transaction plans to access excesses outside the list are possible but become more expensive so this is basically a way of hinting the block builder which is currently the block producer and giving them some clue about what the memory access pattern needs to be when they see the transaction in the mempool so they can start pre-loading some information before they actually have to go build the block um and and again this is because there's just you know there's some runtime brutality in the ethereum system that's unavoidable right so because of how state works we have to start giving these hints because we're not going to be able to build blocks otherwise period and then a block access list just takes those access lists of the transactions and puts them all into the block and you know makes a little field for them in the block and then and then hashes that just like you know you have transactions and then and then the transaction hash or you have receipts and receipt receipts hash and again this is for the purposes of facilitating statelessness so this is absolutely um there's a there's a similarity here there's a there's a relationship between um statelessness and the reduction of mev um and so my suggestion here is that um you know because tina sort of again this isn't really my area of expertise and tina asked me to give a talk and i'm happy to give talks um and so i i kind of just threw this thing together just sort of based on some conversations i've been having with people frankly over the years um and so my basic suggestion is is a new transaction type which adds two predicates um very simple predicates only apply this transaction against these merkle leaves so you know you reference the ethereum state as merkle leaves that you want this transaction applied against that's the first one and the second one is only include the transaction um if this set of merkle leaves has these values i'm sorry there's some lines missing at the end of the block right so basically if um if this transaction results in me having a bunch of money at the end run it if it doesn't don't run it um these are very very simple this is very much like this is not a steel man argument right this is just to sort of get our foot in the door and sort of start to understand the power of some of these concepts so so these are pretty tricky predicates to use but they're they're sort of like a generalized solution to um to like slippage in uniswap right it's like well can we actually get all transactions to just sort of have that property and this is a way that we can do that um these are the these are pretty easy to implement uh but they're pretty difficult to use we could make more complex comparators uh you know sort of more traditional ones uh that actually somehow inspect the value and know the value and and that's theoretically possible with something like a homomorphic encryption or um some sort of weird merklization homomorphic hashing where you can assert that a greater value has a greater hash or some zany thing but like that's way out of my field of expertise like i'm sure it's theoretically possible but i have no idea how you would start to do that um and i and we're already mucking around a lot with merkellization that's also another one of my hats is messing around with merkellization on the cosmos sdk side i think that there's a lot of opportunities there uh so we probably could do this um one of the benefits of so the benefits of these uh of this system is um now block producers slash builders and other transactors uh know which transactions will be contentious without needing to execute them right if you trust if you trust the the statement in there but you can even do a light verification with each call that will verify um will verify the uh hint that was provided with the transaction and that's uh very powerful right because you may you may know because you can't just look at the two and the from of a transaction and know if it's going to mutate the state that you care about that's that's the important piece that's sort of missing from the slide you you need these hints because of the way that internal transactions quote work um and ultimately the goal of these types of additions to ethereum is to just remove like get us out of a contentious first mentality right and i could go on and rant about this forever when we were working on super early eth2 like you know super early me vlad uh vitalik and um and uh greg meredith and occasionally guest stars would show up but like we were always talking about you know removing the uh you know having asynchronous transactions on the chain right it's this synchronicity that's a problem which has also been talked about during this conference as well as the shared memory um and the two of them together is just like a lethal combination and so we can work towards removing those things by adding new transaction types over time that move us closer um you know iteratively move us closer to the correct solution and do so in a relatively quick pace without necessarily having to make uh l2 changes or or things of this sort um yeah and so uh i've kind of already uh hinted at this um so um phil mentioned this uh this blog post um uh or this uh thread in uh in his talk it's from vitalik he's basically explaining how we can separate block proposers from block builders uh the highlighted part is sort of the important thing um you know the the the idea is that we have an outside market of actors that we call block builders produce bundles which is basically like an mev bundler uh consisting of uh complete block contents and a fee for the proposer right so we're basically saying well let's generalize how flashbots works today and what i'm suggesting is let's actually offload some of that computation in the block building to the users themselves um ultimately with the goal of you know well if this new transaction type is used block builders should charge less for these transactions to be included which is an interesting aside right because the users are doing computation on behalf of the block builder somehow they should get a rebate for that um and that's a significant uh discount um to the actual block producer so they should get a rebate for that as well um uh okay i will wrap it up in two minutes all right so um pipeline so the perfect block creation has these properties uh pipeline data access uh constant time construction and verification in relation to bytes included this is important because it actually provides it solves some pricing problems that we have that are theoretical that i won't have time to get into um and then the goal is that we want to achieve like bitcoin level mev right like bitcoin has mev but like no one really talks about it because it's an application specific chain so um so we should be able to achieve that by actually you know reducing the amount of state computation that block producers need to do also like many ethereum killers separate transaction ordering from execution and um they do that for scaling purposes but we're doing it for similar reason and we'll also achieve a scaling benefit as well um also worth noting um there's some new clients on ethereum that by again um sort of addressing how merkelization is done uh they can greatly expand the amount of gas that can fit into a block and so it's all related right all these things you know have some intersection have some relation all right so next steps someone write an eip someone implement it that's easier said than done it should be really easy to get this on the main net because it's a new transaction type it doesn't have to really interfere with things some of the features we may want to add to the system is we may want to modify each call to generate the uh to generate the um the hints that we need and we may want to build services that make it easier to uh extract state from the existing chain which is something that i'm already working on and there's a link provided in the slide uh and that's it i'd like to give thanks to the you know amyv pirate ship tina phil edgar love et cetera and you know over the years i've talked about this idea to a lot of different people and you know i can't really name them all and thank them all but uh thanks those people for listening to me as well and uh thank you