Security Challenges of Aave Governance V3

Transcript

good morning everyone I'm Spencer from Spirit session share for session 12 vulnerabilities and exploits have a really diverse group of folks going to be talking over the next uh hour and a half or so so first I'm going to introduce Andre kozloff from bgd Labs he's going to talk about some security challenges on it uh good morning everyone it's not about most like our security challenges but yeah like more about our governance yeah my name is Andrei and I'm working last almost five years around our protocol originally I was the part of Iowa Genesis team and last year we created the bgd labs initiative and

now we engage directly by the Dao and we are trying to think mostly about the Dao itself and what will be the talk about I want to make a short like introduction which everybody aware of how our protocol was evolving but from a bit different perspective like initially a long time ago let's say around like four years we got rv1 it was a minute it was controlled by multi-seek and but on the early stage everybody was accepting it and it was fine but then over time it was not an option and we developed our governance which allowed us to control the pool completely uh through the voting system sure and it

was in a quite good spot good position but over time it was quite high demand of expansion to go to the different networks like to polygon then to Avalanche to some other also we grew and mainnet with some other components with a safety model and so on and very interesting question appear but how to expand because okay we can go to optimism which happened a bit later but security of the bridge on optimism is the same as the security of optimism itself so we can go there and it will be fine another option we can go to polygon and there is official Bridge but it's not the same security as

polygon itself and then we can talk about Avalanche where there's no official Bridge there is just some Bridge which just doing the mint in burning tokens and what to do because is not an option because we are going back to the same centralization point each which we had let's say one or two years ago on our everyone and the main pool no pool on ethereum then yeah we can choose one of these Bridges if it's not relapse but then we end in the same centralization problem because we fully depending on one particular bridge and we don't know anything about this bridge like yes for sure we can check the code

base we can check what detail about validators we can trust that all these validators are independent but then even one line of code can ruin everything completely it's quite fragile situation and also if you want to expand more like okay imagine we checked one Bridge it took for us let's say one month of the engineering work and now we want to go to another Network we need to spend another month and still we don't have full assurance that we will be living in peace we will be we'll have a good decentralization level and so on and so forth so what should we do and how to survive on this environment

because like it's more and more networks over time and that's actually what we were working in a bgd Labs last year we were thinking about this particular problem and now we are coming with our delivery infrastructure the main idea is you know what why we should depend on one particular Bridge provider why not to do aggregation on top of them because if we have three providers all of them have different community and it's quite remote to imagine that two out of three or three out of four will disappear in the same moment or will be hacked or like we'll go down whatever so with this thing we can have quite good level of

security and also we don't need to dig so deep into the every bridge like now for us more important question how reliable is it I mean in terms of availability also the cost for sure security is also very important question but if we fail once we can survive and yeah the high level architecture is that we create our own transaction let's say on our aggregation level which is completely Unchained we send it through three or four or whatever different Bridges and we accept it as confirmed only when we receive it multiple times

let's say two out of three on the destination Network before we think that it's proud or like we don't know what is it apart from this we like a bit go in the deeper in the technical we have couple of levels of abstraction inside the system to guarantee the delivery because if we lose the consensus maybe we will want to retry the message and maybe we will not be able to send a message to not Bridges from the beginning so yeah we have also some retry mechanisms for that because everything that it's very important if you send the message once it should be delivered like for sure but imagine what what will happen if it will really happen and two Bridges out

of three let's say will be misfunctional maybe they will not be malicious like nobody knows what can happen and for that we have emergency mode because we still have a garden in our system but in normal mode the guardian operates more like uh spam attack protection if you need to retry some transaction or if we need to execute some action receiving to not spend our funds on the bridge we have a guardian but in case of emergency and to activate an emergency we need to create the vote in a main net activate the specific Oracle which is like independent delivery channel to this network

then a guardian takes more or less full control and can reconfigure the system so here like if you want to screw the system you need to have control over a social guardian and you need to also have control over let's say Oracle of the like chain link level I mean which is also quite tricky so it's it's quite good but is it good enough already because it seems that we solved the problem of centralization and the crocheting Communication in a very simple way which I really like is the application Level developer because you don't need to to dig so much into how the roll up work or how the the communication of this particular Bridge working but

still we have some problems because originally when our governance was designed in the Google times the gas was one gig away there was no so much of a bull market so the voting was efficient we were able to vote with let's say one dollar per person and the participation was not the question at all it is still like debatable is it a problem or not so much but the the holders of let's say fifty dollars worth of have a token or one hundred dollars or even two thousand dollars to five maybe they will don't want to spend fifty dollars to to make a one particular vote because guys on ethereum is crazy

and in the same time we don't want to go again to a centralization point because we will be happy to move uh voting out from ethereum but what do we do we cannot just do it under some centralized entity and that's why we are coming with our governance we want V3 sorry and our main idea is to move voting out from ethereum but now because we have quite trustable infrastructure which we control from the both sides and we understand how it works completely we can move move it out and how to do it very simple it's the storage proofs because the current version of Davao governance is

based on the on-chain proofs so on every transfer the same is uniform compound and all like mainstream governance on every token transfer you create a snapshot to understand how was the balance of the guy but it's good bad and it's not so gas efficient but the ethereum like native mechanism is the block hash because block hash kind of contains all information about the blockchain in the moment of time so all we need to do we just need to bridge this block hash on another Network which is cheap and to start vote from there and it's yeah it's very simple as simple as as this but yeah I I will give just a little picture so

we've reached the storage proof and then any user just go into the normal RPC of ethereum you don't need to bridge any funds you don't need to do anything you just take the the proof and you deliver it there and that's it and also because we are on the cheap Network we can improve the user experience because we can add relayer in the in between and say you know what governance we're going to pay because every vote will cost let's say 20 30 cents so whoever can participate even not having polygon and Avalanche and even don't have any any funds at all just our tokens uh why our delivery

infrastructure is also very efficient in the case of the governance because governance is very slow system and when we send the message through like three or four different Bridge providers it can be slow it can be expensive but if you're working with a governance system and you want something now it means that you're in the big troubles and you're in the wrong place because our government like vote takes five days and then you have time logs and so on and so forth and for that like to have another half of our delay on the bridge one hour it doesn't matter at all so we have here multiple phases we create the proposal then there is like some time log to before activating the vote

in uh to for people to prepare their balances then when we deliver results we also have another time lock because still even if we trust our cross chain infrastructure there can be some malicious action so also we try to design crocheting independently from the Dow itself so that we don't trust anyone even own crushing so the guardian can cancel if something and then yeah you deliver to the destination Network and there you have another time lock and you you can execute it uh another key features of our governance apart from Storage groups now we can have multiple voting machines like also we not depend just on polygon

for example if we will put a voting machine there we can put our voting machine on Avalanche we can put it on optimistic roll up unfortunately we cannot put it on ZK at the moment because kitchen costs too much money and I think many people noticed it in the last year of development also we have a mainnet backup which guarantees us that even every even if all side chains will go down still we can vote for proposals and and make them work and another quite important thing which is sounds a bit smaller but we think this is very important because last year we were working a lot on improving the uh how is the name of on simulation of the governance

proposals because it's hard to predict what will happen if you'll just be checking code it's good if you can check all state transitions which will happen in the transaction you can understand what exactly happened so in the current governance system we Bridge the full payload and the buy codes would say and the byte code through the bridge but it's not efficient because you don't know what you will receive on another side of the bridge yeah you expect that it will be this but maybe some extra IDs will appear maybe some other stuff so now we have payloads controllers like the place where we create our payloads on every particular Network and we bring just IDs so in terms of simulation for us it's very simple we just say Okay

id15 appear and all the code and all like information is already there we can say how it will be in the end quite in advance okay and what we learned during this development Pro process uh we was like heavily using properties and formal verification and for me at least I understand that it's the best debugging because when you're trying to define the properties on the system like cross chain communication or like or Dao it's very very important because many things you think that you thought but you actually didn't and then formal verification

explains you very very fast and another thing that the basic blockchain mechanisms are very underutilized on the application layer because for sure like when you hear something about Roll-Ups when you hear about like core mechanisms of chains or you know some circuits you hear a lot of them but when the when you when you go and check at least like how it was a year ago when we wanted to find at least simple example of with the good code base just to make a test with the stories proves that was nothing like it was some examples but they was not working and we think that it's still like quite undiscovered and interesting Direction

just the point like how to find good application of it and yeah that the communication protocols uh very very hard because when you dig into them then you see and when you see all the hacks around it's very tough story and this is inter decentralization is even harder so now we think that when we're in a good shape but it's hard to imagine it actually how to make it still perfect okay that's all I wanted to say thank you questions thank you [Applause]

any questions hi um you mentioned that you potentially will have different voting machines across different chains um would they be happening at the same time and aggregate it back to mainnet for the decision or do they exist only one at a time um of course they exist only one at a time as the backup mechanism because you can take decision based on the gas cost and everything like where to vote right now because when we start going this direction that we want to aggregate some

data across multiple chains it becomes very very complicated like originally we had also high demand people were saying oh guys but we want our tokens on polygon voting because there is also important Supply but when we go into the synchronization topic how to understand and which particular moment of time will lock both networks it's impossible so that's why the the same thing is also impossible to have voting on two machines you need to have exclusion I mean possible but useless what was your approach to testing did you attempt to automate it the testing

communication protocols especially across chain are difficult to test just curious how did you approach that because in our case we accept some parts as the Black Box I mean the bridge in the middle itself we cannot test it uh so in our case testing is way way much simpler system because we have a color chain like uh sender and First Chain receiver and they are quite isolated between each other it's very simple system so we were using apart from formal verification the test but it was mostly like unit test because then like I send the message and I can be sure on another side that this message is from there

but why I can be sure because I received it from the multiple Bridge providers where they have like big Community behind and we we cannot consider that all of them will disappear in the same moment in the same hack if we consider it then it's different story thank you very much [Applause]