Secure Protocol Upgrades: Lido V3

Transcript

different one. Okay, so let's start. Uh I'm here today to present you uh to present you a lighter v3 upgrade for I think one of the biggest upgrades in the protocols uh we have lately and um so let's start uh my name is Yurit Kachena. I'm a head of DIY engineering at Lido and also I'm a lido contributor and also I'm one of the developers behind the lido v3. So kind of multitasking guy and uh thank you for like listening to me. So uh let's start with uh what lido is. Uh Lido is a liquid staking protocol the biggest one in Ethereum. We currently have uh TVL of 8.6 six millions ease and

uh at the same time LAA is a middleware that connects people uh with funds to node operators that actually do the staking and uh one more thing that is very important that Lido is a DAO. So all the code and policies are controlled by Lido DAO and uh all the upgrades are done via Lido votes and so what is Lido V3 in compared to Lido V2? Uh it is a major upgrade and a major upgrade in the phil philosophy of LIDA because Lida becomes uh from middleware. Uh it grows into uh staking infrastructure allowing anyone to have its own like small lighter pool uh setup

that actually will benefit uh of uh using ste liquidity that is that is widely adopted among the DeFi. uh we plan to have like 2.5 million STES in those votes uh after the launch and uh uh yeah I think it's pretty impressive. Yeah. So uh what is with three uh in from the technical perspective uh it's not a separate uh deploy of protocol like in some defy protocols they just uh copy and do a new setup we uh had to evolve our setup because we are staking staking providers. So we keep laid v2 and right now it's called lighter core pool and uh it basically

stays the same providing this uh one to one battle tested staking like by one to one I mean ST is uh staking uh and we extend the protocol with a new layer uh called ST volts. Uh those vaults address uh uh things that actually um actually stop people from using like core pool um because sometimes they need like a uh ability to choose a node operator, ability to choose like DVT or uh the ability to have a compliance to have some specific uh setup uh on top of operators and uh maybe they want to

adjust some features like uh uh restaking or like some sidec cars like me or something else custom that we don't support in lighter poolool. So uh with with those ST volts we have like an ability to have uh custom strategies uh for custom configuration of the staking uh like infrastructure on demand. So we have an option to do uh different defy strategies like looping or uh uh farming incentives like something like this. Um and this brings us closer to institutional vaults uh because of uh comp better compliance and because of uh

providing uh top level liquidity we have in the defi. So uh just uh to understand how it all works uh this is the core mechanics uh behind the lighter v3. So staker comes to lighter right now and use only like lido v2 uh model and we'll be able to stake with like s volts marketplace where any like node operator can come and create its own world like node operator uh inst providers and anyone like can create all its own vault they permissionless and the same uh at the same moment not operators can share uh to be in a core pool or to be presented

in the marketplace. So they can have optionality to like participate in the different setups whatever is better for them. And now let's talk what's uh what's important about this update for Lido. So as I told you it's a uh evolution from middleware layer into staking infrastructure and uh Steve talking right now it's one one but it will be overallized because of the volts the because of the reserve ratio we have uh uh it is uh very important to know that vaults are isolated so they have all risk assessment framework for each like individual uh vault And uh they

don't affect Steve's uh holders from the pool. Uh the design of the vaults of the vaults like uh never affect one of the invariants we have like never affect the Steve uh holders on the core pool. Uh ST vaults are permissionless to create. So anyone can come do its own setup like agree with node operator uh bring like bring your own validators and so on and so on and uh work with vaults permissionlessly uh up to the moment when they want to to have a liquidity there is a like security issue I'll talk later about this but uh overall like it's permissionless and uh uh vaults are designed that way that uh um not like uh owners of the vault can uh at any time

disconnect and decify with the worlds to take their their collateral back without if they will like feel that DAO uh can affect them somehow. So they will like see malicious you know action or malicious uh proposal for DAO they can just uh immediately escape with all their funds so DA won't block them. This is one of the crucial designs because uh it's very important for uh our partners. So uh this is a pretty big update. You can see by the timeline it took like 17 months to develop. uh we have we had like started in June 24th and like uh we plan to to launch on December 25 uh but

it's not like finalized yet. So uh during the development like we it's pretty much waterfall stuff like usually like we have specs smart contract development tooling development and uh test nets running plus audits and plus upgrade preparation the part that's it's required by DAO because we cannot like just deploy we need to like wire everything to the DAO. Uh one interesting here you can see that we have like eight dev nets. The dev nets is is uh the custom protocol setup we have. It can be on like Ethereum test net like hoodie or haleski uh or it can be local also. I'll I'll come to it later a bit.

So just to for the curious uh people here it's the stats we have like 17 months 15k lines of code in smart contracts I think it's enormous amount to be it's just doesn't fit in my head three 3.5k tests uh 140 hours of internal like synchronous review so we it's not like when reviewing by one person when we collect together as a team and review the So uh again as I said priv eight private div nets three public test nets for auditors and we actually recently uh got this unicorn from 1 in.

Uh if you are like wondering where where unicorn from one in disappeared it came to our pull request because GitHub doesn't even open it. So you cannot see this request. It's like 55,000 lines of code added like 40,000 K uh deleted. So yeah it's huge. So let's it was like a marketing stuff. So now let's let's dive into the process. Uh and let's start exactly with the process because um if you don't have like a process of uh shipping the update upgrades, you will screw it up pretty much uh eventually. But with a solid process that actually battle tested, I'll tell

you a bit more about this. uh we can like uh guarantee that our approach uh to the upgrades is pretty secure. Uh we control all the like stages of of development, deployment and uh level verification of the upgrade. Uh so we have a special uh framework I would say uh in DAO that uh helps like it can be like adopted by any protocol uh to be used to uh do a secure upgrades. So more of this uh on this will be uh the Kate Kate will have a talk to tomorrow uh about this layer defense uh and how it saved uh Lido uh

from like if you know on door governant uh stuff uh so I'll move forward to the specs and research. So I I think all of you because you are researchers like uh security guys here you know that your spec should be resilient against attacks you should focus on main um like uh actors who could be malicious uh don't bring like a market inside pool uh but what I want to emphasize here most is that you need to focus on the uh on those uh scenarios and flaws that actually should never happen and you should like put a lot of effort uh to

protect your code against something that would probably never happen but it should be there to make it never happen like I I don't know if you got this but uh like design for failure not for the happy pass uh also the the key ideas we had during the spec design um were like Um we need to identify the places where the things can go wrong like really wrong. Uh if we like have extremely high amount of num of walls it can block our oracle for example. So we need to come up with some solution that will unlock it. So we we

came up with lazy oracle. If we have like mass slashing events on all the vaults in uh all the valtors in the vaults we need to internalize the the bad depth. If the if the vaults would uh deplete the core protocol, we need to have something like some lever to uh to work with it. It will be it is called redemptions. And uh another approach to this is a trust no one. So you you basically take all the actors in the system like uh whatever like uh not operators of vault owners uh or our own oracles uh our own DA and you don't trust them and you uh try to find the ways how they can be how

how they can bring some some malicious actions into the into the setup. So uh with this approach like you have uh like happy pass here is on liquidity and validators. It's very very easy. But then if you dive deeper uh into the iceberg you will get more and more stuff that actually uh comes up that you need to handle. Uh during the research phase it's crucial to keep an eye on what's going on with Ethereum itself. So because some of the EIPs will drastically reduce your work like uh EAP7002 is actually uh ex execution layer integraable withdrawals allow us uh be

not be involved owner to extract uh uh value from the beacon chain even if the node operator misbehaves or like we don't like it like acts malicious. So also like uh 7251 uh allowed us to shorten the validators because right now we have like a cap for 32 is for validator. Now it will be like two uh 2048 and also some things uh uh simplified our work with oracles like uh um pending deposit EIP6110 allowed us not to have like any uh workaround uh uh for TVL drop

validation when the validators are deposited. In the meantime, Ethereum not always uh ship very like what we want. Uh the main part of the not the main part but the big big part in in the vault's infrastructure like volts contracts is called PDG predeposit guarantee and DSM. Uh it's a core core logic. they only uh develop are developed to mitigate one thing the front running for uh validators and there is an EIP for this for fix exact this thing it's called 7684 but it's stagnant I think for two years and Ethereum foundation just don't do anything about it so if you have like

connections anywhere like push them to to to to do something uh other APs we would like to have and I think they will be beneficial for like everyone is uh 70 688 uh when the u upgrades hardwork upgrades won't affect G- indexes and uh what this one is very very heavy one uh 7907 uh the limitation of uh contract size with 24 kilobytes this just insane we have like two contracts that constantly went over it and we have to come up with some non-trivial stuff to to just optimize the size.

Uh yeah, also there are some weird weird weird issues with consensus layer stuff that uh should be fixed but they are not. So I'll probably skip the development part here because I'm out of time but just basically use like best practices or all resources you can get to write a more secure code. Um the thing that we had problem with is that we use uh very old solidity because of the because lido is a very uh old protocol comp by by of course crypto standards and we use solidity 0.4.24 24 for uh because we are connected to Aragon and uh we had to

keep a keep our tooling uh in a way it will also work with this uh old version. Uh but heads up uh Hara tree is coming to uh fix all all the issues for you and also uh Sirra is working on the bite code equivalence checker to allow uh secure contract upgrades uh from like old version. It's actually like from like just secure contact upgrades or at least uh but we will use it probably to upgrade latest solidity.

So you have like a doc uh you have a spec you have code now uh about testing. So we uh suggest you do the do this first do a lot of internal synchronous reviews because they are very beneficial like you you can come you can like work in a team you just if someone has some idea they can like share and like or wrap it and uh find some findings. Uh another thing that we do is according review we have a oh it's called actually I have a two here it's pro uh protocol security committee uh so they they do the it's a it's a separate uh team of people that do a review uh

they never have like this tunnel vision that we have as a developers they have an u external uh to the developer team so but they are very uh they have a good knowledge about the protocol itself. So they they know how to identify issues and they actually identify a lot of stuff that sometimes missed by our auditors even. Uh so just add bunch of tests whatever you can do like unit tests integration acceptance for uh formal verification if you can if you can't just ask someone who can do this.

uh I wouldn't tail you. You all know who can do this add fuzzing and solveny tests. One one very interesting thing that actually uh I like suggest you to do is to have a integration test setup that will actually run not only like on fork for example but also if you have like a if you would like deploy absolutely pure copy of protocol try to run this test also there to see what will blow like what will uh be u broken. Um again DevNets why we had so many uh we divets is like a milestone. you can just uh uh fix the code at some level,

reflect, see where the problems are uh how to solve them, maybe uh find a better approaches to the like to change architecture sometime. And uh if official test nets will be like broken like we had with Khaleski and Cipolia that's why we have hoodie right now. local dev nets are here to save you because we needed to test the pectra stuff before pectra came actually and uh we used our own uh like uh thing that helped us to develop oracles um oops uh same with test nets it's just pop the difference is it's just public and we

can have a feedback from our integrators like of partners and the same like uh and collect feedback So you did the spec, you did the code tests. Now it's time to bring some like a second pair of eye to see that everything go is okay. In our case, we worked with Certora uh and they did a formal verification for us. Uh we worked with mixes because of their very extended knowledge of the protocol of light the protocol itself. Consensus made a fuzzing test for us and also a general audit and composible security made of offchain audit. We also try to work with AI agents like uh nethermind and savanchad.

Uh so the takeaway there not ready yet don't go there like okay you can try but don't uh rely much on them. Uh okay here is only one thing is important like actually this picture you see this is from our internal chat uh how how much like uh findings do we have uh we we wanted to u to uh bring all all the uh auditors into one place uh into GitHub and I think uh for us it was a good very a very good experiment but they probably don't like it like not all of them we have on top of the auditing process we have the commun 25 bounty program. I need one minute. Okay. No.

Okay. Um just from these slides. Okay. Then you need to understand that you uh should verify the deployment as uh the verification of deployment is very important was as much important as uh uh as audit itself. So then like you need to add monitoring and the one the one thing that actually very important here if you unsure just don't deploy anything because here the uh the the price of the narrower is too high. Sorry for for been too long.

Thank you, Yui. [Applause]