Lido V2 Upgrade from a Security Perspective

Transcript

uh hello good morning uh maybe I'm gonna use this microphone uh good morning everyone um so uh my name is Eugene I'm from lied on ethereum protocol and today I'm going to talk about uh V2 upgrade and from security perspective and I'm mostly doing Engineering Management so like one controversial take in the beginning of my presentation I wouldn't talk too much about about like how to write secure code how to avoid putting vulnerabilities in your code and something like that um it's actually because of two reasons

for us because today I think that it would be a lot of very good security talk about code and the second one that I want to share my personal Lessons Learned From V2 upgrade and my role is mostly about Engineering Management code review organizing process and I would try to talk about things that beyond the core security check and um if you're just asking me for example give me just one resource or article or whatever to to help to get better in a good security I would share with you only one

uh I guess that a lot of you of you know this website it's actually the digest of biggest defy hacks and we need to work hard to not get featured there and so here is agenda for my talk I'm starting with a small introduction into lighter V2 after that I would share some cases or stories around security but not code security I picked these stories because I think that it's I want to share some maybe unique parts of our processes because really uh one like our goal was to

to might be to upgrade as secure as possible but it's it was like a lot of things that might go wrong and our goal was to mitigate This and like all these cases so it's really based on how like experience here and challenges that we made during this V2 upgrade and in the end of my talk I would share you uh my way of thinking about protocol security as a layered cake so yeah I'll show you uh so let's start with the stats um so uh Lida is a largest liquid sticking protocol in space

and as you can see from the stats it's a biggest possibility for the team uh like the second row it's about code size so even from this from these numbers you can understand that it's a lot of complexity in development and like all upgrades took seven months of development we have in like in lighter Dev team something like 25 contributors so um and uh here is how upgrades online look like

um two things to note for example uh things like spec smart contact development test net and security audits normally should go sequentially right and on this timeline it's really uh more like parallel that's happened because our goal was to try to deploy this upgrade uh close uh after Chapala card Fork because enabled enabled withdrawals and our goal as a liquid taking protocol was to follow this upgrade to enable withdrawals as soon as we can for our

users so our goal was try to follow uh ethereum network card for timeline and the second one it's you can see upgrade preparation stage that tooks a little bit more than one month so like from the beginning of April to middle of May when which was upgraded I will talk about this like later in my talk um from feature perspective V2 had free uh like epic features um and this require us to completely rewrite a protocol from ve1 um the first one with Javas is the most

important feature because uh yeah it's actually if you if you stake in a like liquid stacking protocol you you expect that you can unstake and withdrawals and before Chapala had Fork it wasn't possible but uh once hard Fork was enabled and we just implement this in code and the stake enclosure and scale it oracles it's a feature related to scaling and decentralizing validator set which is very important direction for us because we're striving to because right now we have only created set and we're striving to decentralize it um yeah here is like uh to have like perspective of what the difference

between V1 and V2 to understand like complexity of this upgrades let's dive into V1 context so it's a pretty straightforward actually like it's a free smart contracts Lido staff Oracle and not a no the parators registry and it's written using um Aragon framework on top of Oregon framework and Aragon framework was written on solidity 0.4 and this requires us also to use solidity 0.4 uh which is not great uh so and here is a V2 contract landscape uh it's uh like three times bigger in code

size in a smart contract amount yeah all blue contracts there is a newly introduced to newly um like created uh contract and um all new contract is written on a modern solidity uh 0.8 and um basically every every single contract that you see on this slide has been upgraded except one so it's like big scope and okay how to upgrade Lido yeah uh we didn't have an option to deploy V2 as a separate protocol instance and for

example great liquidity after that uh the only option was upgrade on a flight uh with one transaction because yeah you need to like do it like you need to keep continuation of operation right and since the protocol is controlled by by the Dao by Lido Dao the only Aragon voting has permissions to do that to upgrade it uh so in order to upgrade smart contracts uh one needs to initiate to initiate transaction to the proxy and change implementation from old one to new one uh plus like some configuration cable management and so on

um and like to to do anything around voting has to have evam scripts it's an array of triplets uh like who who who to call which function to call and what params to use and you can take a look on a picture so it's basically like a list of actions it needs to be done and if the Java votes for this proposal the array can be executed on behalf of Aragon voting contract um so which you vote it's like actually even script plus a special template contract which we put like a lot of cable management to make upgrade more

verifiable and interesting fact that executing the upgrade took about 8 million of gas and it was front ranked by it withdrawal in the T Hunter so you can take a look on if interesting you can go to the link and read his blog post um so leader which upgrade is a complex process and what did we do to reduce the risk um first I want to share like our perspective how to write good spec good spec from my perspective should be first of all resilient against economical

attacks taking an account sophisticated actors and [Music] um number three it's very important to not try to set price on assets but use Market Force to do that also covers all edge cases even if it takes a lot of resources and a good specs should be derived from frost principles starting with problem and constraints and after that go to like solution um and yeah so Prospect and like this story about with you the first stack of this spec we put together for one week that actually described happy pass but we typically realize it's the most

problematic Edge case that might happen during massage when sophisticated actors can can be in in better positions in regular Staker which is not good yeah so and uh next month months we uh just try to mitigate in this case so we're introducing two protocol modes Turbo Modes is a duffel fan and bunker mode for uh mustache and Convention which is Delight withdrawals until penalties are would be socialized um okay um so um another story it's about testing yeah so

how how okay we just did good spec we did write code and how to make sure that you like I mean like the coach is in develop an environment right and uh production environment it's always like a little bit different from deaf environment so how to make sure that cotton production performs at as intended yeah uh to achieve this we create a test suit uh acceptance statute and I will cover all scenarios in each case is there and next we take the actual script that was used to upgrade the protocol and run everything in a on a

local manage heart local my network of the chain to make sure that things uh like things go in the right way so in this environment we run real script uh simulate the voting process by impersonating accounting and voting from like our like big lgo holders and after that simulate upgrade and after that run test suit um acceptance test is uh test ensures that the protocol function as expected but snapshot test can check that some scenarios behave the same before and after upgrade

yeah so for example stake in one F in Lido before V2 and after V2 should get in your hands exactly the same amount of stuff exactly the same amount of token and this can be checked with snapshot tests um okay so you tested your protocol in a proper way and you always need some external external security you need like some like another pair of eyes to check that everything is correct um so it's obvious like everyone doing like security audits but if we wanted to and we wanted to be sure that upgrade is

correct so we naturally wanted more than one audit yeah and like due to the timing uh we run like this audience in parallel and this required us to have like special coordination process uh we have like dedicated dedicated person and it was a mess I mean like it's do it if you have time just do it sequentially and just have some gaps in between of audits yeah because to handle all findings uh you will need this time um but this helps a lot to get the two

upgrade on time and finding sets by different Auditors what's different so it was definitely worth it and a little bit about satura approach certora also did for us uh security audit but with formal verification and on top of all this bonuses that formal verification gives you from Engineering Management perspective for me it was surprising that our developers started to think uh like invariant based in invariant basic way so it's uh like yeah it's like it was surprised for me

uh yeah I see five minutes um um okay so you did audit after that you you need to make sure that you deploy it properly right and we have like special Department in our Dev team called the Ops that basically ensures two things um ensuring that any upgrade is externally verifiable so like all params and configuration published and ensuring compliance with those security uh practices and um especially for v2 upgrade uh we had like these like four things on top of this the most interesting that we introduced bug bounty to not yet to be

deployed code we also had like additional audits that actually checked that pre-deployed contracts and templates are matched to um that version that was audited by another Auditors and yeah we created some fun tool called diviscon um and yeah and the last stories it's about uh emergency stops so two sometimes you need you need to address unexpected issue right so for example um we cannot anticipate every scenario yeah and it's essential to have safety levels and usually what people do is create kind of multi-seek that have permissions

to do emergency stop of your protocol right but um this introduced additional risk so um to address this we develop like gate seal that that has three advantages over like regular multi-seek it's limited it's limited any time so you can stop only for six days uh to allow Dow to react and it's like one one time um so I guess I guess I need one extra minute to wrap it up yeah so um protocol security from my perspective is a layered code and

yeah you you should always start with the code because you need to ensure that God is secure but like you want to make sure that Angela and spec is also safe yeah and also you need to test it um like on top of all this like snapshot tests and testing I definitely recommend to go in a test net public one um you also like need to think about external security things um if you have all this underlying you need to make sure that you deploy it in Secure way and you always need to expect unexpected things because things might go wrong in

production and you need to address these challenges right and like all the stuff it's based on people because it's actually people driving courses think yeah and you need to ensure that your team is good enough so you need to hire right people you need to educate them you need to build culture and this is very important of and very uh underrated aspect of security and I think this is my main message to you that security starting with the with people and you need to think about it um yeah and this is the last slide we're like looking for master of security to

light a team so um if you're interested in or you just know like right person just send me jam on Twitter and please subscribe on my crypto Twitter that I recently started so thank you awesome uh if there's one question we have almost like 30 seconds here so you said it's better to do sequential reviews than to have them all come in in

parallel and and I can see there's a trade-off there like when you when you have two parallel reviews you might get different answers when you have sequential reviews as as you said there's a lot of benefit in being able to answer that getting your new work checked as well as the old work would you do both if you had the time and money um if I have time I would go with less stressed uh option to have it sequentially because you can properly address all findings to like uh fix the protocol get some posts to thinking about it and

after that go to next auditor and if you do it in in parallel you need to really like apply patch send to everyone that is working on uh on your code right now communicate it and it's really and sometimes uh like like another auditor also found this bug and also reports you these findings like with another suggestion and it's becoming a little bit mess you know like it's it just but yeah we was forced to do it because uh like our idea to was to deploy a sub after chappella hard Fork so I think it's it's not about a choice it's uh

yeah it's uh it's a trade-off cool thank you thank you Regine I think we we need to stop now um yes thank you I will I will be here for a whole day you can catch me yeah there foreign