Prysm in 2024 | Terence Tsao - Offchain Labs

[Music] hello test test good to go all right hey guys thanks for coming to my um little talk I am Terren I am from opch Labs I am a ethereum protocal developer and today I want to talk about what we are working on on 2024 and most of it on my personal opinion but yeah I'm happy to share with you so cre po who here runs an ethereum node whoa that's a lot of people that's awesome yeah I won't ask if you run a validator because I don't want to talk to you in public but I presume if you run a validator if you run a note you probably run a validator and you probably know what like prism get this and stuff like that so yeah so today I want to talk about like what are we making on the client side Improvement and what is ethereum upgrading to after DB so first I will start with client code Improvement that we are making on prism again some of this are my personal opinion doesn't reflect overall team but I think there's a high degree of chance that this happen in um 2024 so first what is prism so prism is a ethereum consensus L client return return in go so how etherum works today is that you have your sensus layer client like prism Lighthouse nimus teu and you have your execution layer client so as you know when you run a note you are essentially running two pieces of software and the both software communicate with each other using the engine API and if you run a validator if you're validating you also run a validator client on top of your bacon Noe for signing Val validated CLI are mostly lightweight and what and what is a beacon not what is this prism client right so it's this consensus client and um it has this P2P stack it has this R server for if you want to querry your Vala balance you want to sign block and then he has the Precision DB and for prism he also comes with a slasher but that's optional that's to detect cheating that's happening on the main net blah blah blah right so that is a very short form of what the prism is so what do you care about when you're running a node obviously like if you're running a validator you care about performance right because like it performs poorly that you lose money and losing money is not fun right and how do you lose money you could miss a block you could miss a testation and some of it may not be your fault just because of okay you may have a slower internet at that time or maybe you're sharing your prism note or your consens like client with different Services that's running on the same computer and then the memory spikes out blah blah blah right so there are a lot of factors that goes into running a node right so I will label the first one is performance the second one is that if you notice using so much resources that it's also not good right and the resources consist of bandwidth memory storage and compute and those are something that like as a client team we are always optimizing so today prism so this is captured on my maina setup right so I have a nuke I have CPU which is pretty decent I have 32 gigabyte of memory two terabyte of SSD you can purchase that today for about like $800 so it's not like very expensive and I have 100 megabytes of download upload bandwidth which is still reasonable right and to process a block meaning that for the block to arrive and then I process it it takes about worse worse worst case scenario it takes about 1 second and then on the GU this also takes about one second worst case scenario I'm talking about but then luckily both of them are processed in parallel so you typically when you when you process a block we say the worst case is one second right and what does this number matter because today a slot time is 12 second you receive the block you have about 4 second to verify the block if you exceed beyond that 4 second Mark it's likely that you will um miss the r you eventually vote the parent block or the current head that's not a block and likely chance you may vote for the Run block or you may try to reorder the block so it's just not ideal and U today prison takes about six six GB memory get takes about 3 GB memory and then the disc space usage is about 1.5 terab so now the question is can we do better the first Improvement that we should be sry seeing is that we have tons of caches and the when we started writing the codee in 2019 that I think like we did not foresee like what happens Five Years on the line right we don't have enough knowledge when we start writing a code so we we have a lot of caches that essentially serve the same purpose right and then bin State the state itself is by far the biggest object on on consensus L client so now you have different catches that may serve different purpose but there is overlapping responsibility that you may able to reuse it so I think the first like test that we should be focusing on is essentially to consolidate the caches to basically to the FI that we mandatary need and that this will significantly improve the memory allocation the second thing is that we want some sort of Conant siiz DB database because as us for now the DB Grows linearly Right we store every single block since the Genesis we don't store every single state but we store State at some checkpoint and with the block you can replay the state to any different time you want so that's the power of replaying the state through the blog right but do you really care about like some block that's like four years ago H probably not right so you kind of rely on this like um blockchain um altruistic identity that you only need one single honest not to serve you the old block right not every note has to keep every single block from the Genesis right and even today we have this our B and change spec that defines that we only need to serve peers that with a block that's four months old right so we can start actually doing that today prison note by default you can prune every single block um Beyond a four-month period And I you probably save a decent amount of storage that's something that we can done today and something that I think we probably will focus on this year then again this is um validator minimum slashing DB so right now we have our validator it signs things and then if you double something thing that's a slash of offense and that is really bad you don't want that have to happen so to protect that validator has this slashing DB and in the beginning that different client team implements their DB like differently they have their own slashing format right but then in the recent years there is this EIP to essentially Define a format make it interchangeable between client meaning that if today you're running rightous you want to switch to nbus you can actually import the valuator sling DB on on the fly so that they essentially reduces like the risk of you getting slash right so this is something that um prison team has been working on and then yeah and something that is really useful okay so this something that we get as probably the most is that when rest Bas Val their clients so in the beginning we spent a lot of time focusing on grpc as a protocol because of the rested standard wasn't defined and then the rested standard defined after we start implementing that so as of today prism F their clients only uses grpc and then it connects to Baker node using the grpc right but you can tell this kind of like hurts this inability because um a lot of the different client teams they all support rest which all of them support rest and they have their rest valed client right so it would be nice to have that same standard use the rest Val client so such that you can have this inability and then the performance should be as comparable to the Val to the um to to the performance should be comparable to the grpc that's the important part so once we switch to rest based um system we can actually decate grpc that's a lot of cod cleaning C Health Improvement right so we can defate GPC service we can replace all the Proto buff stuff reduce Upstream dependency and then some in some parts you also improve the performance as well that's something that like also the coase will be more welcoming per like per uh per outside contributor they just want to work on go they don't they don't really care about like protop they don't really care about grpc and then they just want to write go and that's also welcoming as well that's something that we are very much looking forwards towards again right without saying there be ux Improvement this year we'll have better lots better dots better monetary experience we're also working on simplify the web interface so everything above what I said was more of the client specific improvements so I want to talk more about like ethereum based Improvement which we actually implement the protocol so these are the protocol changes that most likely to come in the next hard work okay so here are some eips that were most more more bullish given the timeline is say Q4 2024 the first is the E trigger B exit Okay so let's go back to the beginning right so I said that when you run a node you run two pieces of software that you have your bon node you have your um e client get or whatever right so the separation concern is nice and we can actually take advantage of that right because now now running into pieces of software they they can allow to pass any mess message so as a b note I can learn what's happening on the evm world like really fast right so one thing I can do is that I can pass message for validator add it through the execution layer and this is very nice for the from the standpoints of say a staing service or or or a restating service right today to um add to your validator you have to sign something on the CL layer but your evm contract does not have access to that to to to signing that thing on the C layer that is a trusted operation between the operate between the operated node right and then and that kind of hurts that trust when you talk about igon layer when you talk about reaking so you'll be very nice to essentially to be able to trigger the exit on the E and I think this is a big win once we get this to the same thing that goes for deposit as well so I I was talking about Adit but now it's a also it's the same thing right you can have your e directly send the CL client what the ads should be so without currently how it works today is the CL are actually like listening to this like deposit contract through some E gear log event and they have this eight hours delay to for withdraw but this simplify the process right we can trust e just in time so El tells me that there is a deposit that's happening 10 minutes ago we can already import that and then it also allows us to clean up the code base a little bit so we we can we can uh deprecate the e one voting logic blah blah blah the the third one is that this is more on the attestation um um structure so attestations of votes they're abouted voting on what is the head of the chain so we can change the attestation structure to make it more aggregation friendly so this helps Network propagation it will save few bandwidth and then the happy case your validator May uh make less vote uh correctly so again there's this one is interesting this one's reusing the validator indexes right so today when a validator adds it the validator still exists in the big space right so that space is wasted you you basically have this like 50 bytes that just stuck there right and right now there are about like 200,000 uh quantities of out there here that's as it is so that space is just wasted forever it seems silly right so it would be nice to essentially repurposes those validator indices for the new validators so this seems to me like a no-brainer so there are some eips that's very interesting but then we want to do it but we're kind of like less confident giving the Q4 timeline but this may be more confident if today we say the next hard for is in q1 2025 or Q2 2025 right the the first one is p dust so we know the is coming that Ena some sort of um data scalability so now we can um have another data market for blob data so Pier does kind of taste it to another level right so instead of like every node stores everything that we essentially charge the data and now every node samples data so every node doesn't have to store everything so this is getting close to the end goal of what we want with the scalable data because we don't want every Noe to store everything right and this is so we're essentially uh take what we have in EIP 4844 we construct that into different columns and every note just have to simple different columns and then Force inclusion this so this is another interesting one that we want to address sooner or later it's currently like a number of blocks they're getting censored and then as a solo validator I have to make this Choice whether I want to use the Builder or i w to make I wanna build my local block but this choice is hard because it's saying that do I like money or do I not like money and most people would probably say that they like money but then they ended up using the Builder and the and then you basically have to build the blocks what the Builder gave you right so first inclusion this basically give validator this option that says that you can use the Builder still but you can still propose your own block but those block has to be included by the next validator so this improve censorship resistance over the network which is very important for the credible neutrality standpoint for for yeah for the long term then there's a bunch of proposals that me and my team have been working on that's uh in sh proposal Builder separation So currently you have your validator you have your Builder you have your relayer and relayer is this is trusted entities that's in between in the middle between the validator and the Builder and then we think there is a nice outcome that we could achieve by removing the relayer and then ensuring some trusty communication between the Builder and the validator itself and but this is um of course this is like at least a two-year project in my opinion it requires a lot of thoughts but I think this is pro this is the end goal that we should achieve because the current MB boost the real world may not be sustainable for the long term and I think this Vision um will serve us well finally right there are some initiative that we plan to explore such as max effective balance so today every validator 32 e and then you have 100 validators then you deposit um uh 3,200 e but you have 100 keys so you you're propagating 100 message over the network right but that's quite wasteful why can I just propag get one message uh presuming that I have 100 Keys that's what max effective balance is and something that we would love to explore the second one is veral tree veral tree is very interesting it's most it's mostly changes on the E client less changes on the CL client but we will be happy to support that this Ure ensures um this essentially ensures more trust like trustless ver verification on the E side uh we can increase the guest limit and then the lighter node can also verify um the block through some sort of proof so veral is definitely a future and then like client road map definitely like client has existed for a long long time now I think since 209 since 2021 and then we haven't made much progress for my team per se and then that's something that I think it's more important moving forward as we see more use cases that raise up yeah but if you have anything else that you want uh me and my team to look at yeah feel free to DM me so yeah that's all I have thank you for yeah thank you for thank you for U watching my talk yeah have a good [Applause] day