DAPPCON 2024: Lido Goes To Permissionless: Under The Hood - Dmitry Gusakov

Transcript

hello hello everyone and uh today we going to talk about the fact that Lio goes permissionless and you will probably ask hey come on everyone can stti with Lio isn't it already permissionless uh technically yes but there's two sides of lier and the first one is stakers and the second one is note operators and from the not operator side lier is definitely not permissionless like not at all only curated operators but this thing is about to change by the end of this year and today I will tell you about the most exciting Parts maybe from the technical part that are under the

hood of Li going permissionless let me introduce myself my name is Dimitri I've been contributing to Lia since the very beginning of 2022 and since the middle of 2023 me and my small team we are working on the product called CSM or Community staking module a module to a staking router that will allow anyone to join lier as an not operator in a permissionless way with the best possible conditions on the market but how is it to be permissionless

when we think of permissionless staking in lier between lier contributors we have a permissionless trma in mind first of all a permissionless taking solution should be secure if it is not secure no one will use it at the same time it should be trustless because even if if for example you would let anyone enter without asking for permission but then would not allow them to exit and will say okay you need to ask for permission to exit this solution would not be permissionless and the last but not the least it should be attractive we have

such a big Market at the moment so many opportunities for not operators to become parts of different protocols like State WIS V3 for example rocket pool you name it so the solution should be attractive and the most complicated part that you cannot focus on one thing you cannot just make it attractive or you cannot just make it secure you need to have it all at the same time so let's try to find out how we tackle this issues with CSM and we will start with the first aspect the trustless and as you can see from the slide the main tool to ensure trustless within CSM is EAP 4788

have anyone of you heard of this EIP raise your hands oh not that much then I'll give you the gist so you guys probably heard that ethereum is actually made out of two parts execution layer and the consensus layer and the consensus layer is also known as Beacon chain and the weird thing about ethereum is that before EIP 747 88 the only connection that exists was between the beacon chain and execution layer so from Beacon chain you can access execution layer data but not vice versa however all the def applications all the smart contracts

they leave on the execution layer and if your defi application is a staking protocol for example you need to have this information about things going on with validators on the beacon chain so with EAP 4788 it now became possible but not in a very straightforward way so Bon chain data might be represented in the form of a simple Miracle tree so you can represent any data that ever exists on beon chain as a mirle tree and EIP 4788 allows you not to directly access this data but to prove that the data provided is indeed a part of of the

beacon chain data by by proving it against the root of the beacon block so CSM used this feature to prove two facts validator withdrawals and validator slashings in a permissionless way so we can stop here now okay we can prove it actually not all the things are that easy and there's several challenges the first of all the first challenge is when you want to request a beacon block header or beacon block rout beacon block rout from the execution layer you cannot request it by block number you can only

request it by a time Tim stamp because execution layer could not know beforehand if the slot was missed or not so it creates a bit of a challenge you need to operate time stamps which is not very typical in a blockchain second thing is that the dat data is arranged within this tree concerning so-called G indices or indices that shows that this particular data is located in this leaf and this particular data is located here and the problem is that with each hard fork or with I mean it can change not maybe not with each but it tend to change from hard Fork to hard Fork meaning that you need to solve this

issue somehow because the data that you rely on might might be here and in the next hard Fork it might be here the next thing is that you cannot prove simple data because this proofs might be gained you cannot just prove that okay in this particular leave there's you in I mean you can do it but in most cases it I would either be useless or it might be gameable and the last and probably the main issue is that roots of the blocks are only available for 27 hours so if you want to prove some event that is far far

back I mean you cannot do it explicitly sounds like a there should be Emoji here but it disappeared anyway we have solutions for it so first of all instead of proving uh instead of using this time stamps and trying to catch the correct block and guess if this is the correct block on the correct timestamp we prove beon block header first to be sure that we are dealing with the correct block second we maintain a trusted storage for the G indices so that with any hard Fork when new G indices arrive we can be sure that both previous data and the new data can be accepted in a trustless way the

next thing is that instead of proving simple data types like for example validator Bel balance on a withdrawal or the fact of the validator being slashed we prove the whole validator structure instead so that we can be sure that this is indeed the correct validator structure and all the data is included why it is important because it's way harder to fake the data if it is a structure than if it is a simple data type and the last uh there's even though these block headers are available only for 27 hours there's still such a thing as historical accumulators namely historical summaries that might be used to prove the data against

it okay so that was pretty boring I know but if you want to get it even more boring and get a hands- on experience on with SE with 4788 make sure to scan the C code that's a very handy example here and to be honest we spend a lot of time with the team trying to figure out all this pecularities and to find some useful examples so that's one definitely check it out moving on the next aspect security and Security in CSM is achieved by the thing called Bond but not a regular Bond but a bond with a curves with a special

curves but before we start talking about special curves let's first talk about the bond in general so in in a case of a vanilla staking all the Stak associated with the validator is just a single pile it might be either provided by the validator itself or by a third party but there's no split in it with CSM validator stake is split into two parts delegated stake and not operators Bond and the main difference between them is that not operator bond is slashed first and only when there's no not operators Bond the delegated stake is slashed so it's just a security tool to ensure that

not operator will be will behave okay or even better than okay and will not put user funds at risk because he also have some skin and a game now let's take a look at example imagine you have a not operator within CSM operating four validators each of them has Bond each of them has delegated part of stake now something bad happening for example huge slushing but for for just a single for the very first validator or huge me has been stolen by this validator and the amount of penalty in this case exceeds the amount of bond what we will see we will see that now it's not only

validator bond which is affected by this penalty but also delegated stake however we still have these three validators with the bond provided by the same te not operator that remained untouched that doesn't seems to be okay so let's try to fix it instead of using a separate bond for a separate validator we can now use a concept of a continuous Bond so if you have 10 validators or four validators like in this example all the bond provided will be treated as a single security collateral and in this case even if a single panel to exceeds

the amount of bond required for a single validator user funds would still be out of risk so it drastically reduces the risk but can we reduce this risk further and at the same time make it appealing for the not operators to use this technology let's try to think about it a bit first of all major penalties are associated with the block proposed Duty so there's basically two things when you propose a block you can either steal me or execution air rewards from the liquid staking protocol you operate with or you can be a subject of a proposer slashing if you for example propose two different

blocks however slashings are likely to be correlated for a single operator because slashing might also happen due to double attestation and if you run for example this four validators on a single machine and you have a backup machine machine and for some reason your backup machine launches without you knowing and now both of them perform different attestations and most likely all of your validators are slashed however even though this slashings are likely to be correlated for a single operator there are very few operators in the whole world all of them are absolute professionals who are capable of flipping the midterm penalty

the most dangerous penalty within a eum slashing from0 eth to 1 e meaning that for absolute majority of CSM operators or I would say for most of them for for all of them even if the slashing will be correlated the midterm penalty would still be zero and there would be no difference in absolute values between individual and correlated slashing so what would we going to do with all this information with all this information we can introduce this curves or concept of nonlinear Bond so the bond would not only be a common feature for the nod operator so no matter how many validators you have

all the bond is used as a single collateral but also the bond will be reduced the more validators you have because this common pile will be bigger and bigger and you can add a bit less a bit less a bit less and the final value here would definitely be the minimal value required to cover for the minimal possible slashing penalty at the end of the day it makes it beneficial for both it makes it way more secure for stakers and pretty attractive for not operators okay let's move on to the final part attractiveness and that's the trickiest part actually because with all these

Solutions on the market with things like volts from Stak wise with cool features provided by rocket pool with amazing features provided by other staking providers it is really hard to compete and it is really hard to offer something new but we do believe that CSM performance Oracle is indeed one of the unique features that might be a game changer in terms of attractiveness but before we dive into the performance Oracle itself let's first talk about why we need it and now let's take a look at rewards rewards on

for ethereum validators actually came from two sources the first one is simple beon chain rewards so you fulfill your validator duties you get your rewards in a form of reward skimming all of them are accumulated on laa withdrawal credentials a single contract for all Lia validators at the same time time when you got lucky enough to produce a block you will also get some form some part of execution layer rewards either only priority fees or in case of using me boost you will also get me rewards and all of them would still land at the same W on the same within the same huge pile

and the second part is actually really volatile so if this Vault was only for you you would see the graph of this of the balance of this world like slightly slightly slightly changing increase slightly slightly slight increase or maybe no increase because you were not lucky enough and slightly slightly change and again slightly slightly change so how to distribute this pile this whole pile and the first thing that comes in mind when we talk about a big big staking protocol as big as lier for example example or as big as any other like protocol on the market is reward smoothing we all heard a lot about am

smoothing pools about smoothing rewards in general because the system itself is not made to be beneficial for small stakers for people running couple validators it is made to be some apparently it turn turned out that it is made for big operators so why not to let small stakers benefit from being a part of a big protocol but there's an issue and the issue is if we build a permissionless system we cannot just say that okay we have 100,000

participants and we will evenly split rewards between them that would not be true that would would never work because you never know how people would perform since the entry is permissionless so it would be beneficial only for people actually performing bad because they will get more rewards than they would get when performing on their own right but reward smoothing is still a cool feature now let's try to figure out how we can combine the two facts imagine we have five validators each of them performing individually as a performance metrix we would use the simplest

possible thing attestation rate ratio between successful attestations and total number of attestations assigned to this validator then we will draw a line we will call it threshold and what it would mean that any validator with the performance above the threshold is now called good performer and any validator below the threshold is called bad performer but what it has to do with rewords and that's the the most interesting part so if you are a good performer you will get these socialized rewards but if you are a bad performer you will get no rewards at all on a

delegated part of a stake and even though validators below the threshold would still get some rewards for the common pool they would not get any share of it just because of the fact that they are below the threshold and these rewards will be distributed between well performers making this system a very very good incentive for people not to be bad performers but to be good performers and to get this smooth piece of pie I would say so that brings us to the overall concept of the CSM performance Oracle first of all it uses adest stations as

the main performance metrix and it utilizes the performance threshold concept to distinguish bad performers and good performers to calculate the rewards distribution but as you might have noticed we are talking about individual validators and this calculations are impossible to be done on chain it will be enormous in terms of gas so that's why a miracle tree is used to submit this rewards Distribution on chain and on only a root of a miracle tree is submitted and then the rewards might be claimed okay now let's move back to the initial permissionless trma it turns out that we have just addressed all three

aspects of this concept by introducing you a new product called CSM and for me CSM is the best fit for this trma but if you want to learn more technical details again as I've mentioned last time if this talk was not boring enough and you want to get into even more boring stuff then go check it out the discussion uh about CSM on lier research for that was basically it I'm always available on telegram for any questions suggestions and the final thing CSM is still under development but we are about to launch testet probably within less

than a month and the one last thing some say that if someone of you guys sitting in the audience or probably watching a stream is really interested in joining CSM but a small but very pleasant benefit some say that you need to scan this QR code and get yourself o it is some analog of PO for some reason called a no matter anyway go scan it if you want to join both CSM testet and AET with a little benefit and that's it from my side thank you thank you dri uh we have a time for

some questions yeah please yeah thanks for the great presentation um was very interesting just a question regarding the attractiveness you as I understand correctly you basically classify between two groups right The Operators not good enough kind of not going beyond the threshold and the ones kind of Performing better than than this threshold is there any incentive in kind of Performing even better like I I imagine there's a group then kind of of of operators performing maybe good good enough and some maybe have a setup like

put a lot lot of effort in performing really really well is is there any incentive to to or is there the idea of an incentive to also reward those who who are even better than than the average good performers thank you for your question that's a really good question and the simple answer is no there is no incentive to perform either at the very bottom like a bit above the threshold or or at the very top but the thing is that it is extremely hard to actually maintain your performance on not at the very top level but on some level like

97% precisely it's really hard so the reality is that especi especially solo stickers they all try to perform as well as possible they try to maintain their setup and if they face some issues some small issues they should not be penalized for it however if they perform really bad if a participant perform really bad he should be penalized but we understand as as as people who design this module that incentivizing the very top performance is it might might be a good thing but for CSM we propose another idea we propose the idea that you need

to be okay and if you if you can perform better you can perform better you will it will be beneficial for the common pool and all of you guys will get more rewards and we believe that it is extremely hard to keep like at the very bottom like just technically so no there's no incentive to be at the very top there's a incentive to be at the top batch but not at the very top any other questions hey there um you mentioned something that uh the validators or The Operators that can tip the scale that have uh enough power enough e to tip the scale

um to turn the penalty system into like into the red yes those are not the target of CSM um therefore they they just won't opt into this system that makes me think is it like if they are not incentivized to join CSM is it because the permission set is more um gives more rewards to The Operators than the CSM that's a great question thank you Paul uh it is really hard to compare CSM with a permission set why because to

join permission said on one hand you don't need to put any bond any bond I mean in terms of in a form of a e but you need to put your reputation at stake and you need to pass all this process at the same time with CSM you don't need to ask permission you can simply add funds so there's two separate ways and I would say that if you as a no operator is actually capable of running that much validators at at the current state of the network it is something around uh 12 12 12,000 or more validators then you would probably apply to be a professional operator or you

would maintain the business on your own you don't need this staking protocol so for CSM we are not saying that you are not allowed to enter if you're a big operator and we are saying that huge operators would most likely follow the other path or their participation within CSM would not be that significant thank you Paul uh do we have time for one last question one last questions yeah um how do you see the CSM meaningfully contributing to Lido's uh decentralization since only 0.5% will be allocated to it wow where did you get

this number of 05% probably you you are thinking of simple DVT at the moment let me clear the the picture for you so from the very start it is assumed again it is to be decided by the liod I'm not the person to decide but it is assumed that CSM will start with 1% however again as you can see from the initial proposal this cap would be gradually raised or will be proposed to raised up to 10% even with the very first version of the code and the security assumptions but I can assure you that even though CSM version one is not released yet we are already working on CSM version 1.5

or version two so this is just the very first step and I mean if you have if you are standing on top of the mountain and you want to get to the bottom of the mountain or vice versa you cannot do it with one step you do it with gradual steps so what you see now is the very first step in a multiple step steps so multiple steps would follow and I do believe that again I'm this is my personal opinion I do believe that the end game for for lioc core protocol might look like multiple versions of CSM with different parameters so that even curated operators might probably be offered an

opportunity to join like not not ACC created operators but Pro operators larger operators might also be offered with the opportunity to join for example CSM like module with a bond so I would say that in terms of uh decentralization this is a very important step still a very small step but a very first step in a row of a multiple steps thank you for the participation and thank you