Tomasz Stanczak & Marcello Bardus - The MEV in Nethermind in Eth2

Transcript

overwhelmed okay hi everyone welcome to mev nethermind in ev2 and we have marcelo vardus who is lt researcher at nethermind and myself thomas dante and i work on protocol engineering in nethermind so maybe as a quick introduction what is netermind network is ethereum client it supports mainnet it supports xdie sidechain poa energy webchain sidechains it supports all the test nets it supports all the latest forks in the

future forex i think as well um mev itself is the in famous miner extractable value so the way of uh introducing solutions for on-chain arbitrage but the one that is very naturally available to miners mostly because they are always the first ones to react like based on the the way the consensus is designed miners are always the first ones to get access to whatever information is in the manpower and will be included in the next block uh we show some of the tooling that we build around some other solutions available like flashbots that allow to use standard mind as a tool

improving mev and we also show the solutions for mev in ethereum too and tt room 2 itself let's introduce it once again so it's a proof of stake ethereum that will happen after the merge the merge itself being this big event of bringing ethereum one execution layer and etune to beacon chain consensus layer together the first devnet of the merge was done successfully around may this year during the if global hackathon it was the event called ryonis which was like side events today hackathon and we had multiple seven i think ethereum one ethereum two clients operating with this new approach this new very

very simple fast way of showing that there is some proof of concept for ethereum 1 and ethereum to clients working together and nethermind added this merge support as a plugin as a consensus plugin i will talk about it a bit more later so why mev in nethermind you need to because practically when nanomite was created a few years ago it started not really as a client implementation but it started as the as a vision of building set of tools for uh for d5 for experimenting with a extracting data from mample and so on and so on it ended up being much bigger project than just just what it was meant to be as a just

quick experiment of what what the clients do ended up being a full client but uh what stayed in uh in the head and in the culture of the company was that uh d5 will be a big thing and another mind should support efi and mev and arbitrage because this will be big on ethereum and the three big plugins that we'll talk about today that are available in nethermind are the mev plugins so the implementation of so the same thing that you know from mev gav for a flashback implementation of gaff that allows the bundles to be delivered the arbitrage bundles to be delivered to gaf

miners uh the same thing we built for netemite which is uh important in a way that it enables additional sidechains to to enable mev so for example xdia uses posdao consensus which is not supported by gaf which means that we've netted mined mev we have xdie enabled for mev um we also built a mev searcher plugin which is like work in progress buildup of a plugin that allows to execute some operations of pushing the bundles to the relayers and finally the merge plugin itself that i mentioned was built as a consensus plugin so all of those things come as external external implementations okay we build

them ourselves but you could easily build them just with the api that is available in that domain okay so in the context of mev it's really important to mention how a block is created so let me quickly remind how it happens now before the merge so basically the flow starts when a user sends a transaction that transaction ends up in the ethereum one client manpool then it's propagated through the network and then finally one of the clients creates a block and whenever it wins the proof of work that log together with transaction ends up in the chain so that's how it works now and how about after the merge it will be

similar so the flow will be that the user again will send the transaction that transaction will be propagated in the jira one client then it will be propagated across the network end up in a pool and a block will be created and that block will be passed to the ethereum to client and then it will be included in a bitcoin chain and a consensus would be done on top of it also what is important to mention that on interim 2.0 uh the next block reducer is is known okay having that set let me introduce one of the solutions for doing mev on ethereum 2.0 so this solution basically is copied from ethereum one and the design is really similar so we have searchers on one side

who find mvv opportunities send them to the to the relay and then the relay uh sends them filtered to to the network marketing one client and they dream uh one client creates a block and and sends to the ethereum 2.0 client and the block is created and what is important that the revenue is split across the ether etherium one operator the staking pool and the validators and that solution was created during the scaling ethereum hackathon together with netermind lido and and also there is another approach

and i will let thomas introduce it yeah so while in this solution one we have this equal split between the stakers validators and an odd operator it's it's a simplification but it's actually simplification of a very important concept something that's still in research so what we still think about is in ethereum 2 who exactly has the biggest power in this market of who gets the mev is it the searcher is it validator is it staker uh is it if one node operator is if one node operator the same actor as the validator or are they actually split so you would have maybe infured delivering notes for uh for bison trails or for lydo uh

so there's lots of questions here and uh this was our first exploration as marcelo said and the second thing is something quite new that was uh discussed with flashbacks uh and is based on uh on some ideas that were brought by jason bariani and then explored by alex abadia and then we arrived at this carrier transactions design carrier transaction design and what the carrier transaction is and the whole thing is how to use a mempool to distribute the bundles the mev bundles because if you are aware how the relay works nowadays with flashballs is you have to connect to

relay via like some kind of json rpc interface and the relay then passes it again to the miner so there has to be this kind of centralized managed connection between the miners and the relayer uh and the bundles go there this way so how could we decentralize it and prepare for ethereum ii the direct delivery from the searcher to particular validator that we know in advance will be creating the the next block and uh the well the initial the idea was there that we can use the mempool the question was how and and first we thought we should create a special transaction type there is eip2718 in ethereum and it allows you to build

new transaction types but even as we design the new transaction type there is a requirement for a consensus change so all the clients have to support this realization of those transactions have to recognize those transactions inside the blocks and so on and so on so can we do that without any changes and the answer is yes with this simple design of carrier transactions that are entirely normal they have the from sender address they have the nonce that is the valid nodes the next nodes for a given sender they have whatever the two recipient address is in the in the transaction and then they include a call data or like data field inside the transaction that contains the encrypted serialized bundle of other

transactions so they are carriers of this content of the mev bundle internally and why is it encrypted because we were thinking about the solution that is targeted at particular validators and let's see how the architecture of this looks here so a very important part of this solution that was suggested by alex abadia was the validator to the blog builder registry so we could require the encryption with the validator keys but maybe it wouldn't be the the nicest thing to reuse the validator keys to decrypt the messages uh just not so neat so instead the

validator can delegate a blog builder of their choice and it doesn't have to be a single blog builder it can be many of the blog builders that are approved by the given validator so we can look at who is producing the next block on ethereum 2 network is it this particular validator then check out a checkup in the registry what block builders are available and then also analyze how does blog builders behave and then as a searcher i can encrypt with their keys and then distribute over the network and i know that it will be delivered to those block builders and i don't have to have direct connection with those block builders so from the registry i don't have to collect information about the node on

the network that i have to connect to i say okay this is what i encrypted with and i distribute it using the standard p2p mechanism so why this pdp delivery is guaranteed because if we include the valid from address valid nonce and valid payment with the proper gas price then this is a transaction like any other transaction if we start thinking of potentially censoring this transaction there is nothing that restricts us in trying to hide it the same as any other transaction and censoring on the peer-to-peer network simply shouldn't work because there is enough of like various paths and disconnected sub-paths sub-networks sub-graphs that can deliver anything that you want to censor

why the block builder is constrained construction is important apart from the fact that we we simply want to use the fp2p because validators already mentioned that they would like to have ability to define a bit more in details how the block is constructed like the validator operators are quite big now and they're already planning how they monetize those solutions uh how they actually deliver blocks that satisfy their requirements and those requirements might be not necessarily a simple standard blog but maybe they want to include some transactions of their partners maybe they want to include mev maybe they want to include more mvv less mev blocks and so on and so on

and yeah that's what i wanted to show first so we can define the block builder recipe like the definition very simple definition of how given block builder constructs the block and we can say there are simple sections inside the block space that tell us there will be mev and it will be on the second position just after some partner of hours maybe some layer two transactions batches that come and have to be guaranteed that come in the block then maybe there is a standard public member set of transactions and maybe another layer of for example flashbots private which is not necessarily mev the one that is front running everything else but the flashbacks transactions that are or any other relay transactions

that want to be private but but they don't want to pay for being first in the queue and this is just an example that can be expanded and we can start saying okay we build a market and a set of definitions that allow searchers to check if they want to work with the given block builder validator to define if they accept the given block builder block builders competing on who is the most efficient one so they are being actually approved selected and sometimes this connection between the block builder and validator might be very strong in a way this may maybe the same entity and i may want to say oh this is my validator this is my block builder and i want to capture the amv myself and suddenly as a reasonably weak validator i can actually build any mev capturing but i can also

delegate this to to some stronger operator and if you go back so there are really two ways of providing support for sending those carrier transactions so this simpler one like the more obvious one it's not here it's something that would be built into the ethers.js provider for flashbus and you simply have the way of sending carrier transactions you provide the bundle you provide the account that you want to send it with and you say send it as a carrier transaction and here we've got here we have an example of how it would look inside netmine in our prototype that we have

with publishing it over json rpc so if we don't send it as a raw transaction already signed we can say send it for this particular validator or like this registry validator block builder uh this is my transaction representation of a carrier transaction to carry information about the sender nonce and so on and there is a bundle to encode and then we simply encode this as rfp we use some potentially like the asymmetric cipher to encrypt then we construct the carrier transaction and send it and and send it whatever way we normally send transactions to the mempo so it doesn't really differ much from publishing the standard transaction on the member and from the perspective of the node

that is a minor or validator node the one that constructs uh constructs the blocks the incoming bundles can come either from relay or from the mempo and after they are processed and go together to the same pool of bundles of mev opportunities they're treated exactly the same there's no difference in how the transactions the bundles arrive to the node what happens next is the standard scoring like ordering by the which is the best mev opportunity for me as a minor validator uh how much am i paid how much my revenue is increased by the fact that i'm in including those those bundles inside my blog and whether it comes

through relay maple or some direct creation from my local mev doesn't matter and why for us the mev and x die is particularly important so we are now uh finalizing the work on preparing mev relay to deliver the messages to xdi validators we run our own xi validators as that in mind and there are also other nanomine nodes being used as validators on the xdi and since this is a proof of stake network it acts as a fantastic testing ground for a proof-of-stake approach for mev like okay how it will behave if you know

validator or x seconds x minutes in advance at the moment i think sdi has some something over 20 validators generating blocks every five seconds so you have around two minutes before the block happens to know that particular validator most likely will be creating the block and then you can use all these encryption mechanisms and you can test and since we already have prototype and another one should be coming soon in gaf it will be a nice playing ground for testing both the carrier transactions and mev in side chain and since when we think about mev and f2 we think about sharding that's coming after the merge

and we think that the side chains will actually be natural candidates for the shards so any testing of the mev in particular side chains leads to potentially cross chart mev in the future okay also as roll-ups are known to be a scaling solution for ethereum two we'll introduce them and describe what kind of mev can happen there so let me quickly introduce what a rollup is okay yeah so rollups are a way of executing transactions outside of layer one but the the data is posted on layer one and by having that said the data is available in everyone so also

the state of uh the rollup can be recreated even if the operator turns off and what is also important uh rollups have an operator all which are also called sequencers and uh those roll up have have a contract and basically that state transition of the roll-up is secure but they contract either by um proof in case of zero knowledge zika roll ups either by fraud rules in case of optimistic roll ups so optimism is obviously the most known optimistic roll-up and there are various ways of mitigating mvv for example by mev

auctions and using froutros it's for proving that the transactions are valid and also the transactions are posted on on layer one and there is a way to speed up the execution by passing it directly instead of going to through the sequencer instead starknet relies on validity proofs and basically whenever something happens on the on the rollup a validity proof is posted on on day one and on day one there is a contract that relies on different knowledge proof uh knowledge groups that revised that the state

transition was uh was valid and all all of that happens uh on only one but trans the the blocks the layer two blocks are proven on uh by the sequencer and we when you think about layer two side chains and if two this is this is how we see network is actually combining or gluing all the different direction where ethereum ecosystem is going so we see nethermine is a bit more than the mainnet if sidechain is based on ethereum if layer 2 is interoperating with ethereum if ethereum 2 is the next step for ethereum then this is what we want to have

interoperating for efficient mev but for efficient execution in general so whatever actually constructs the new defined markets we'll be using in the future all of those components working together so if we think about ethereum to scaling and there is interesting realization that when we were going first towards ethereum 2 we were asking questions eternity will provide sharding it will scale the system it will provide proof of stake uh it will provide finality and so on and so on and then we realized okay but what if scaling is not the biggest problem to solve by ethereum 2 what if scaling is solved by actually using the layer two solutions then layer two solutions may make the problem of transition ethereum

two much much simpler right and i think this is the direction that we see now like use the optimistic roll-ups rely on the the zk roll ups for scaling initially start working on shorting the sharing will be coming as a next step in the meantime transition to much safer and much desired and much anticipated proof of stake on ethereum and then introduce the uh like when we think about nethermine just use the fact that we are positioned in all of those different side chains that we're working also with the layer 2 providers together and that all of those solutions can together provide potentially either multi-chain

mev or cross-layer mev and all of that can come with the additional tooling okay let me also introduce the sequencer rule as a set so basically on layer twos the block is produced by those sequencers and they either accept the transactions directly using like json or pc or any other kind of api but either by posting the transactions later too and very often for example optimism the must include the transaction in the in the layer 2 block otherwise a penalty will be given to it and also right now most of rollups operate either

in the single sequencer model either in the multi-sequencer model and any kind of mev that creates it happens on on layer 2 can can happen by posting l2 batches on on layer one and those actions can be front run or yeah any kind of mv can happen there so to your point yeah so like when you think about a sequencer so there was a big exploration of the sequencers for like what how do you how do you prevent mvv in sequencers how do you use sequencers for mev and different layer two solutions have

different approaches right so the uh when we think about uh stark nets dark words so they were working on vdf solutions uh to to ensure that the ordering of is predefined and that there is no shenanigans on reordering transactions just for better mev extraction post factum so so all the transactions will be ordered based on some vdf defined numbers hashing and then you can no longer change it when something new arrives and this for now i think it's it's uh just on the side and that will come back probably so look at this video vdf solutions inside startnet as for the optimize they the current sequencer solution there it's

centralized right so the we know that practically all the mev goes to layer two operator because they run the and i think this will be happening for the foreseeable future for all the l2 why we think so because the l2 mostly will care about delivery of the the main business of scaling and delivering the the solutions that are verifiable in layer one and only then we'll transition to democratizing sequencers and solving those issues that are there somewhere on the edges of their domain and those uh sequencers that can be that can be further democratized will probably use some of the tooling that uh the teams like flashballs the teams that

work on mev nowadays will be working on solving but in the meantime i think that recently we had the announcement from optimis saying okay our sequencer will be centralized at the beginning but we'll just use this as an opportunity to uh this this retroactive public goods funding right so uh i think that layer two solutions are aware that there is a big question about how what they will do with mev like are you are you doing clear two thinking that this is the monetization solution is it centralizing all this value extraction how much value will be flowing through layer two um so big questions to come also when you like sometimes we have those questions about uh side chains

layer two is the mev they're much larger in scale than on mainnet like obviously no but would it be larger or will it be large enough and we think that everything grows together the scale so mainnet will always carry the biggest value and maybe not because volatility the biggest value transactions and it will actually lead to huge mev opportunities whenever the markets get more volatile but as for the for the layer 2 and side chains they'll keep growing and at some point they'll be more and more significant for more searchers more bot operators and we already see things uh some bot operators working uh on polygon starting to work on x die probably preparing for the cross chain

cross layers fantastic thank you thank you so much these are our handles and then we'll be very happy to hear questions from the audience [Applause] whoever has questions yes

so with this carrier transaction does the searcher run the risk of just having a transaction be inserted on chain and just pay the price without actually getting you know the real transaction inserted hello yeah yeah so this is a valid question right so will you as a searcher end up paying and the answer is yes and we also say one of the reasons why it was not possible to decentralize the relayers properly so far was that there is this denial of service attack vector when you're sending too many bundles and nobody is paying for them but they require simulation they require scoring and you don't know upfront how expensive they are if they're using some tricks

and so on and so on with this solution you you can establish some level of trust that if you deliver this transaction directly to okay so you can use rely you can use the p2p layer and on ptp layer the block creator can either discard the shell of the carrier transactions and just include whatever is inside or they can always include the shell as well and you end up paying for your for your bundles that you deliver so so you have a payment model might be quite expensive to deliver mev but usually for efficient mev you'll be expecting that the content will be much much more valuable and then the shell itself when you start competing with other searchers for similar opportunities

then you may end up paying a lot for for the same thing and losing to others but not necessarily you can have uh miners or validators uh trying to uh like to punish you for that and always include those carrier transactions uh the shells themselves because uh maybe there might be some kind of social consensus that we know it was just a shell that was not malicious behavior we have it as a potential slashing uh punishment of like okay you didn't send anything valuable or the bundle was was trying to make us process too long and then and then you end up paying so so that's the expected mechanic and dynamic

behind so um will it form to mitigate in any way the layer 2 transactions and censoring can you repeat my reason yeah yeah like um with if2 will it mitigate in any way the l2 transaction sensor censoring

yeah censorship that depends because as on ethereum 2.0 the validator is known but also there are validators are choosing randomly it's harder to organize such a censorship okay i think also one more thing that i forgot to mention was a bit of an answer to the question before so we were asking about inclusion of the carrier transactions in the block so when they include it then they disappear from the mempool but they but it still can be read by the

by the validator creating the next block so we think that actually like this two two sources of delivery of transaction on bundles become like three sources really one is from memple the encrypted ones then there is a relay like direct json or pc connection and the third way is by extracting it from some of the previous blocks because they may have been included as valid transactions so we just see that oh the data data content of this transaction we can extract from them the mev bundle that is addressed addressed to us and we do that with this with this encoding of the prefix telling this is mev transaction and then the validator public key so i know it's for

me and then i can decrypt it so i don't waste decryption time on the on the keys that do not belong to me any more questions don't be shy yeah thank you thank you so much everyone thank you you