Towards Verifiably Secure Governance

Transcript

um hi it's great to be here one girl um so I'm wanting to share some thoughts on what I think uh secure governance could look like and some tools that I believe are missing uh on our path towards this goal so I'm Nico I lead I've been leading for the past few years the smart contracts team at balancer labs product I used to work at open supplement mostly on the open sibling contracts which is actually where many of these ideas come from uh so first I'll address the elephant in the room why have governance right why not build permissionless decentralized systems why do we need to have privileged access uh and this that would be a goal worth striving for uh but I think as of today

the industry is way too immature to tackle that problem uh if you think of lending protocols right there's many values that are critical that need to be tuned if you think of emergency response that involves dealing with unforeseen scenarios so it's very hard to design automatic systems that can address all of this so I think for the foreseeable future privileged access will just be a thing and it also doesn't have to be like black and white there's a spectrum and you can actually Design Systems where you don't Grant like God powers to to some account I'm also going to be looking at this not through the lens stuff you know who's making decisions that can be a CEO with a ledger that can be a on-train voting what have you what I want to focus on is

the fact that at some point somewhere in the in the system there will be a human looking at transaction data and they'll need to understand the data and make a decision regarding is this okay or it is wrong and to some extent answer the question are we being hacked by accepting this data right is this problematic or not so with that out of the way let's build a permission system so the sort of very first design decision you'll have to deal with which might sound minor but this actually has important repercussions is are you going to have an addressed based system or a permissions based system by address based what I mean is something like open settling O Level like you have an owner and if that owner

calls you you can do things uh that's very simple which is it's great it's core strength it's very easy to follow it's very easy to figure out who the owner is but the issue you'll have is as you start having more and more complex Behavior you'll then have functions that look like set percentage fee which is simple but also shutdown system right and you don't want to Grant permission to shut down the system to the party that is setting up the percentage fees you need to have some level of granularity a way to do this would be to maybe say instead of just having an owner also have an operator right and they can deal with different parts of the system uh however now for every single change that you're making every single level

you know tier of permissions you need to introduce these changes in your circle and also all of your contracts start looking sort of different because they all have different requirements and what the owner means in one contract may have a very different meaning from what it means in a different contract um a way to work around this which some top D5 records actually do is you'll have the owner be a smart contract itself and then you set up the granularity right so the owner smart contract knows about its own owners uh but then that rapidly becomes very complicated right the Simplicity of the O Level pattern is lost and now you have this very complex chains of contracts that you need to follow so what is an alternative uh permissions by permission I simply mean anything

that has the rough shape of that's the caller have permission to do the thing right uh regardless of what permission really means it's just following this sort of pattern this means you'll have to Define what the thing is right what the action is like you need to figure out a way to map uh actions in the systems you say some action ID within the permissioning system but once you go through that hurdle what you end up is with a consistent system that always works the same because you're thinking about permissions right and you can have rules about how permissions work for example how are they granted how are they revoked and everything is now the same the system scales without having to add more code it's like you've traded

the code that you add when adding new addresses for just new systems for data essentially uh being able to reason About Properties you know that apply to the entire system is incredibly useful especially one of my favorites is renouncing permissions which simply means revoking your own permission uh we find that extremely useful when dealing with uh vulnerability disclosures where we find out of an incident that involves privilege access and we can just go very early in the thrier's phase and go hey you know party who has this permission we need for you to renounce it we cannot explain why but you need to announce it right away and now we've severely mitigated the potential impact because now that account no longer holds a

permission even though we didn't have to go through the entire governance process to revoke it and we've severely reduced the potential severity of the issue without it disclosing any or barely any secret information so more concretely what could a permission system look like uh what we have at balancer is we have a Singleton contract which we call the authorizer it has only one relevant function which is can some account perform some action in this contract and that's just a yes or no question that is what having a permission means of answer and the actions are simply based off of the function selectors of the solidity contracts right we also hash them with the address to make them unique in the

entire network and avoid collisions in hindsight we should have added also the 1080 to have even cross-network non-collisions alas uh so this is just very simple right you go okay this makes sense this is a sensible way to do things so we built this we deploy this and then we set up a notification system right we went hey we want to know when permissions are being granted and we want to be notified of that and then we got a message in slack that looks sort of like this and we go okay the permission was granted it's permission 0x12 F9 e0 what is that right nobody knows because that's a hash so this sort of hints at what the first problem we're introducing is which is there's now a layer of obscurity right it's now harder

to understand the reason about the system because even though it's more consistent there's this extra complexity but like okay you know this is far from the end of the world all we need to do is set up a list with all of the contracts all of their functions all of their permissions we go Ctrl F what the f is this permission oh it's change type weight on the gauge controller very easy right not only that you can also we also Host this on the repository and we have CI check on every single run that all of this is correct so it's not been tampered with it reflect what the on-chain contracts say their permissions are so this is fantastic we can reference it in governance proposals and life is good right um

and at this point you may ask yourself okay we built all of this right we have now permissions and we have this system to find out what they are did the security of the system as a whole change in any way right did we change anything in particular can we be hacked more or less than we could be hacked before uh uniably you might go well no because malicious Keys sorry keys can still be compromised by malicious actors that didn't change at all uh but I would argue that compromise Keys is not only the only issue but perhaps not even the most important War you should have and we've increased the severity of a recent uh attack Vector so

by revising what our thread model looked like we identified that now there's a number of avenues that can result in clinical failure for example what if someone goes and says hey I'm Nico messages someone on Telegram and goes we deployed this new contract would you please sign this permission send this action granting this permission to this address uh trust me I'm Nico right I'm leading the team so surely I know what I'm doing and I'm going to go on a limb and say that most multi-stick signers are not going to check that what I'm saying is correct I think that it's just a reality of how systems are operated if unfortunate that is how things often go so this is now made worse because the permission itself is very obscure right it's this

weird hash so it's hard for this party to realize that this is going on not only that what if they try to check but they are sent to the wrong website they're sent to a fake version of the balancer site and they don't notice that it's not the right side so they don't realize that they're looking at a tempered version of the Json file with the permissions so again now they have an issue because they're granting the wrong permission and what if even worse all of this goes fine they're very cautious like they check that everything goes well but you know random internet hygiings you know the DNS cache gets poison or like I don't understand how the internet works this is very weird but like you can be looking at the wrong website essentially but that's like that's really the point

I'm building a smart contract system I shouldn't have to worry about the name server of the Forum being configured correctly to prevent my signers from being tricked into doing the wrong thing so is there anything I can do in my job to make this a non-issue or to at least mitigate severity and I think there is something that all of these scenarios have in common which is after some short period of time The Jig Is up right someone will notice hey you know the DNS looks weird like I'm accessing a wrong website like something is off or they may go hey it's weird that Nico message me on telegram because we often talk BS lag so I'll ask him what's up and if it wasn't really him like you'll you'll

have this worrying in the back of your mind so if by just waiting some time this is sort of fixed right because you notice that something weird happened then what if we just force right everything to go readily and this is something that's been talked about for a long time you know delays or time blocks just in general avoiding immediate execution right you go this very important action can no longer be trigger immediately you instead commit to an execution it is scheduled to happen in the future after some minimum time and critically it can be canceled so what this gives you is now there's a minimum time window during which you can audit what's going to happen and you can reason about it and

you can go hey you know I think this is wrong and I think we need to you know deal with the solution we need to better this execution because it's it's bad uh this greatly reduces signer burden because now what the signers sign that it's not the act the final they don't have the final say anymore as to what's going to happen and this doesn't just mean that they're protected from being you know subject of phishing attacks but also from honest mistakes maybe they control C control V the wrong permission and now when they created the transaction it's wrong that's fine because all of these things can be caught in this minimum time window now this is not a Panacea it has some issues most obviously if you have delays then your system is now delayed and you

need to not only is it slower but you also need to choose for each action what is the delay there's many things to consider here I think the most important three are how urgently do you need to execute this action right is this your first line of defense then likely maybe you just pause the system likely you don't want to delay at all how impactful is it if you're operating the system then surely have at least some relatively large delay on your action otherwise uh malicious uh an attack will immediately break your system and something that I think is sometimes uh not given much thought who is going to cancel the action in the event of an attack and how fast can you get those

people together in the room and address the issue because if your counselor is a 10 out of 10 multisig odds are you're not going to get them together within say 48 hours so you need to be realistic about how fast you're going to be able to react to these things interestingly thinking about delays and you know this metrics of your system will inform often Your Design so for example if you find that you that you have actions that are both urgent but very impactful right say youth say you treat your mitigation for issues as just being will upgrade the system then likely that that's hinting at maybe try to split those maybe have an urgent action that is not very impactful and

try to separate that and have the actual fix happen more slowly uh there may also be space for asymmetry so for example passing is often like not an issue but unboxing likely means that the system was compromised in some way and therefore was buzzed so you want to be 100 sure that you have fixed the issue thoroughly before you on pause so what does this get asked like we now have a system we have permissions they have you know the wrinkles but whatever we fix that with the file we have delays so we're no longer subject to phishing attacks to DNS is the system secure I think the system is reasonable and is to some extent as reasonable as can be

designed on chain but the issue is it's very complicated the system we built is now has a lot of moving pieces and there's a lot of information that is spread over multiple places but all of that information needs to be accessed to properly use the system and if we cannot properly use the system then what really happening is we cannot securely use the system which sort of defeats the purpose of the entire exercise so and this is my conclusion what I think we need and we lack in the industry as a whole this is not something that one single team I think is able to to tackle is some sort of comprehensive tool that can look at all of this data that is fair you know the threat model the different actions the design like

why why did the sections exist in the first place and it's able to then provide information to designers so they can figure it out does this make sense there's some effort uh in this direction uh the uni swap team built the governance seat belt which as Emilia mentioned Ave is now also using these tools perform a couple simple checks such as checking for example that all of the users can sorry all the contracts involve in the transaction have been verified which is like yeah that's a basic standard for uh what's acceptable and also try to produce you know a human readable report such as informing in the case of this action you know that the liquidation threshold for that is changing from 1800 to 8 500. and that's great that's very useful and that's much

better than transactional data but it's still severely lacking because I don't know what a liquidation threshold is right I don't know wonder which conditions the liquidation threshold should be changed I don't even know if this is a sensible value for the liquidation threshold but someone knows these things right someone whomever designed the system thought about all of these questions and they do have the responses for those questions but I don't see that data here and it's very hard to get all of that together and to be able to again have it uh help me make informative sessions so what I'm looking is for something that we can take and fitted all of that information and have it be able to respond to questions such as what actions are currently in flight and need to be reviewed which is not as trivial

as it might seem uh what are the risks associated with whatever this thing is doing what happens if it goes wrong you know how careful should we be in analyzing this if it has a delay why did we choose a delay in the first place right should I be worried about it having a delay does that mean that this is impactful uh if the liquidation threshold is being increased by 500 is that a sensible increase do we expect to increase maybe in smaller increments or not like again these are questions that have answers they are just not here uh and even though like I started talking about different ways you can Implement permissions you know address versus permissions even though each protocol has its own different Kinks and like they're all slightly different

what I'm talking about here is much more higher level much more you know broader perspective and I think surely it'd be easy to build some middleware layer that can just adapt the different protocols to tackle these purposes and therefore build a tool that is able to that is just useful for all projects in all of the FI and the entire ecosystem in general without having to worry about those low level details uh so that's my free BC idea for you please go build this uh when you're done reach out so you can hire you uh and yeah thank you that's it um there's a QR code for the flights if you want to check them out though it seems to be slightly cropped but hopefully it'll be able to deal with that So yeah

thank you