What does "merge" look like?

Transcript

let's get started so um hello everyone thanks for coming to my talk i know it's quite late and you guys must be really tired so um i do apologize my original slide is testing the merge and as i made through the slides i realized man it's kind of like too deep in the weeds like i don't want to put people to sleep so um i yeah so i ended up changing the entire thing and now the new slides is um embrace the layers merge edition so yeah so hi i'm terence i work at prismatic labs my main work is on prism it's one of the five transistors layer client it's written in go and

i've been working on proof of stage since early 2019 for ethereum and that's known as the beacon chain nowadays i'm mostly working on the merge i'm looking at post-merge mev extraction and data sharding so yeah it's nice to be here so so this is roughly what we know emerged right you have this your consensus layer you have then you have your execution layer right you have two different layers so what is consensus layer consistency layer ensures that everyone on the consensus side comes to an agreement it tracks the head of the chain through some four choice rule and that's where the validators hands out

then what is execution there execution is where the evm is that's where you process user level transactions that's where the state tree is right so the separation of concern is very nice here because like they're both very like complicated piece of software and on the consensus layer side i don't really care so much on the verse on the situation on their side as long as like the only thing i care about is what this engine api provides right so you have this nice engine api basically encapsulate away the complexity of these two layers now what if you want a stake you want to

run validator you want to earn some free eve then more likely or not you will also run a validator client so what is availability client it's a lightweight pieces of software that manages your signing key it has a slashing protection db you make sure that he doesn't you don't get slash we don't double sign and then he has like an rpc client to get blocked get stations get duties through the beacon client right so here we're adding one more layer that is the validator client layer what if you are staking exchange you are staking pool you are managing thousands of signing keys that's a lot of money you obviously don't want to do this on

your laptop right you likely will have those keys unlike a remote vote then in this instance you're likely have a signer somewhere else that is extremely secure for example a remote team manager it's an open standard for that and there's a remote signer api right so you can see on the consensus layer side we are already like separating out two different layers so what's a trade-off here the trade-off here is that we're increasing the complexity but at the same time we're gaining security right so let's tie everything back to the original picture you have your chances there client you have your bitcoin node your validator client you have your remote signer those are optional and then you have your execution client right and then both have p2p open for

global team blogs shipping transactions then you have your user rest api on the bottom where users can query data so is this late are we done like can we go home is this like the merge right and uh probably not so let me give you a few more examples on like why we have to do a little bit more right so this is the mbv supply chain today you have your searcher which looks at private and probably mempool they look at transactions to its track value from send it to the builder do this into the miner miner competes on producing the block and then whoever miner solves the puzzle mine is to extend the block chain

by one that's nice let's replace proof of work with proof of stake now instead of minor competing you just have one validator right so this validator is pre-assigned you know when you're gonna propose a block six minutes beforehand so there's no more competition right this also opens up a very interesting question because like this enables before where you just have a few mining pools they're able to extract meb this enables this open competition right so not at home validator you can extract mev if you want right so we're going from just like a few miners to like potentially thousands or ten thousands

of valedictors that's able to extract mab so how do we ensure that the searcher and the builder and the validator they trust each other right how do we ensure trust so here's a new actor we introduced relayer okay this is relayer is essentially what governs trust before full pbs so what does the relay do relayer essentially make sure the searchers and builder and validator they don't screw each other over they essentially make sure that the block the builder build is valid the the block the builder build pays the correct amount to the validator it it's a data availability servicing

right and ideally you want more than one relay layer because like redundancy is important you also don't want to deal with censorship so you want some censorship resistance here so let's attach those two new adders back to our original diagram you have your consensus client you want to produce a block you can go through macbooks which is this gateway it's a proxy to then you call the relay through the relay api then you call the builder to the relay api to get the block and then pass it back to the validator and validator assign it and broadcast it so here you have a nice speaking block with mbv extracted

it's important to mention that like it's also we want some sort of fallback right so in the event where the relay is done the builder is down you still want to have some sort of backup so you can actually go through the engine api which is recommended to produce your own local block or even at the end right you can compare values like to see which block gets higher amount and stuff like that so having redundancy is very important right but as you can see from this diagram right where we are also adding one more layer and that's the block proposal blood builder layer um so relayer is this auditable piece of software

that means that we layer performance matters layers cannot be shady because it needs to be trusted right so wouldn't it be nice to have a committee of monitors that monitor the relay performance right so here we're adding one more layer we're saying hey let's monitor the relayer to make sure that readers are not playing nice with the builder and the validator right and i can just keep going on with this right so i hope you guys get the message what i'm doing here i'm just keep adding more actors to this picture to gain security to get more features with the trade-off of complexity right so in this picture like what like why don't we add the

multiplexer between the consensus client and the execution client so in the event one of the transistor client fails we can fall back to a different implementation or what if we use something like dvt ssv like some validators share technology to split 32e so therefore that like if like one of my friends they're sending his doesn't work or it's offline like ours single validator could still perform well so it's like the meme right so which one is it do you just prefer the one on the top or do you just prefer the one on the bottom right the one on the top is more elegant it's easier to implement it's simple to reason the one on the bottom is definitely more future rich right but

there's a lot more risk that goes into it because there's so many apis there's so many timing constraints but it enables a lot more like future completeness right it's like the meme right mom say hey can we have the merch and mom said no we have the mercury home but mercury at home turns out to be this beast right that right now we're dealing with so are we down here like is this the end right this is the end for all right i mean probably not because like we're heading towards a modular future right we're separating consensus with execution now we're separating um association with a blog proposal and with this um rob central roadmap we're separating data availability with execution then were with the eip444 was

separating the long-term data storage with everything else right so we're heading towards this more modular future and this ties into the title of my slides right it's like we like we should embrace layering right we should embrace that all good things coming later whether it's your fairy bakery your favorite cake like your favorite lasagna like layer often goes like beyond your imagination just at the bottom it's a social layer that's me and you we form some sort of governance and then there's also like infrared and hardware that's likely where people run notes on right and then there's within the hardware there's also cpu os kernel and then there is also like your signing layer your cryptography layer

then then your consensus execution name therapies which we know a lot about so it's important that we encapsulate complexity because everything we have done so far is extremely complicated right but it doesn't matter because like components and components they don't need to know about each other we just need to like have strong api that allow them to communicate nicely right so we want clean separation of concerns we don't want the heat right so as a human i think that we're like exceptional at dealing with complexity since we are always able to find new abstraction to solve problems in a creative way

but how many apis is enough right like to get that previous diagram to work like there are so many apis from bitcoin to execution to eth1 to builder to relay right doesn't matter we have so many api right now right so between the api right i think it's important to have very strong api like between two components you want this integration to look like that right you want api that's followed to standard it's readable it's testable it has the highest security right this is we want to build like integration like this we don't want to build integration like that right that just means leakage that just means bad integration that's just that that that just means there may be a

category like bug that's happening in the future what about ux right as a developer that's something that i deeply care about like today to um participate on the vision chain you have to run two clients two software and then to run validator you have to run three to extra mev you potentially have to run for right it's like are we doing the best we can at solving this problem right is at home stage here um the enthusiast my mom my dad are they going to be able to run those that's something that we really should improve on and we should be really tough on so this is the landscape today as you can see many awesome team

companies individuals are solving this problem i am just one of the many and um so shout out to every person that's been working on this and um please yeah please if there's anything that interests you like talk to the team there so what i didn't cover in depth like there's so many things that i haven't covered for example like exception sorry execution like client layer 2 bridges those are those are very complicated modules on their own they each have their own complexity but it's also encapsulated nicely so but they all have their own layers

so this is all i have for today if you guys are interested in any of the work that we're doing such as the merch such as med extraction feel free to dm me i'll be here after so yeah it's my first ecc so thank you so much for having me so questions yeah questions so we can take questions if anyone has questions hello on the slide i think it was on take four you were showing that there are basically two ways to reach block builders through amiv boost and

relayers but what is the point of having mov boost and relayers if searchers with bundles can still make their business directly with builders because my understanding of that left system is to allow everyone to benefit of the med but if searchers can still bypass the system then what's the whole point well that's probably a bad diagram i'm just assuming that like they both are listening to different mempool they're they're like transtracting block differently so on the top you'll likely have a more profitable block right but on the bottom you probably have a less profitable block right and then it just the slide illustrates some fallback mechanism just in the event when the top

block fails you can always use the bottom block okay thank you so much guys [Applause]