Deployment Validation and the Introduction of the DVF Standard: Enhancing the Security and Accountability of Blockchain Projects

Transcript

the big one okay um I'm very happy to be here for the first time for DSS last year at DSS Anton one of our Engineers was there to then present what is now known as read-only re-entrancy and I'm using this opportunity to present something new we have been working on also here for the first time to address more a practical problem and that is like to validate deployments so just very quickly about me I'm CTO at chain security

I've been in the space for some time right but the authors of what I'm presenting here especially Hubert has been in the space for a lot longer and the only time you'll hear the quick chain security thing so we are Auditors right we we work with all the big projects and have been doing this for for quite some time so far so uh now to the interesting part what challenges do we face with deployment validation what challenges do we face

if deployments go wrong so simple things like you can incorrectly configure your deployment right you can have wrong code deployed something you didn't intend or perhaps like something you didn't have audited you can even think of malicious deployers pretending to deploy one thing but really deploying something else right and then on etherscan you upload a code which actually doesn't reflect the reality we can have incomplete or broken deployments right deployments can go over multiple steps you need to make sure that in the end the system is consistent but you are deploying in a system like on ethereum which is public

everyone can interfere in between um and in some cases you might do an upgrade right and in this case you did have previous state and now with the new code um the previous state might interfere in ways which you didn't intend it now to those of you where you think wait okay that all sounds a little bit theoretical uh I don't know how many those are but there are many examples actually of how this really did go wrong now this is uh where the presentation doesn't go Slide by slide so you can't see all

the tweets sorry for that um so I'll just have some cases here like the most like perhaps one of the famous ones tornado cash governance takeover right so it was a case where someone deployed an upgrade and wasn't perhaps checked carefully not that there was a self-destruct inside of that coach and that allowed the person to like because it was declared it was create two right to redeploy other cases like of systems where actually the security and the code might be fine but it's secured by some multisig which is actually not a multi-stick at all right

we had several very big hacks which happened to be like that we had the why I earn I don't know if I pronounce it correctly case like the previous the predecessor to yearn which had a wrong USD token configured right and got exploited this way and so on so I can go on and for all of these cases there have actually be in exploits the thing is like this is not covered by Auditors so far right we we as Auditors we do focus on the code we do expand from there and this is a natural expansion so what if you could easily validate just for starters like which address contains audited code

right you can go and ether scan but you don't know has this code been audited it's very hard to figure out actually uh you have a git repo right where is that code is that the code which is live am I looking at a newer code which has been updated push domain whatever right very hard to figure out um as an auditor you do have some implicit idea of like a trust model but is it still valid is the system still behaving like that [Music] um how can I detect suspicious admin activity how can I warn for the tornado cache case of self-destruct and create two

can I make all of that not like a lot easier to validate and in the end a nice bonus if you know a system is insecure and you want to prevent people from using it just to warn them like be careful here right can't you somehow do that so there are some solutions for that but that's a nice side effect of what I'm going to show here so welcome to deployment validation we propose something we call deployment validation files so there's very simple files they describe a correct deployment they just State this is what it should be

there's one file per contract you can have them composable you can upgrade them and it's a system which is meant to be like trustless independent it's not controlled it's not something from chain security right we present a new standard here which can be used to achieve that we give a reference implementation but all of that is open and free to use so I'll give you a quick motivations like for these kind of files from the different perspectives so you are a project and you did write your code you got it audited or not but now it's time to deploy or it's time to upgrade right

depending on your use case but did it go correct like did the deployment work as expected you can have transaction record reordering you can have reverts in there some people might some Bots right might have seen something try to front your new front run your initialization are you now really the owner or not is are all the contracts you used which you set up the correct ones right and is it what you tested is that also what happened on chain right you might do the thing which we always suggest people to do like do Fork mainnet tests but also they depend on some historic state right

they seem to work now you deploy you want to make sure it's the same thing which I used to assume the cases from the auditor perspective why stop at just auditing the code right so you did order the code you do understand that system but deployment often is out of scope so now you can check it right you can say Constructor parameters are they what they should be but also are the follow-on config changes done in separate transactions are they what they should be and um as an auditor something which I also struggled with when creating that presentation is like you do have an

implicit or explicit trust model in your heart like assuming certain roles behave in a certain way but often that's not documented very few audit reports do say what the trust model is and then for users it's hard to say is it like safe to use right so all of this is from the auditor perspective now a simple perspective from the user like really you just want to use safe smart contracts right so how do you figure out has this code been audited how do you check if the deployment is still secure um did they do some upgrades or not did configuration changes break the project right I mean all of that happened

a very practical use case some of you might be delegates some of you might be in charge of having to sign off on an upgrade I myself am and that is too much work in that sense that you think it should be easy to check but it's not right it's really hard to figure out is is that upgrade what they really wanted to do did they set all the correct parameters very tedious work currently um so who audited it and who checked those values independently why does everyone have to do the same work over and over again

lastly integrators perspective this is another project like many people want to integrate with uni swap with Ave with all the big projects right and then you always need to make sure are you integrating with the version you are expecting what trust assumptions did that version have is it is the code I'm looking at the code which is on chain it can be pretty annoying right some projects do a good work but many it's very tedious to figure this out and lastly some assumptions might change over time right so famously you might read that in many audits reports right um transfer breaks your project but you say well I am not going to onboard any erc20 which has fion transfer but then

again like usdt has it like you can act they can activate it right another thing which sometimes happens like for uni swap lpps so the fees which like uni swap would get directly through LPs they were disabled right a big discussion and what happens if they get activated like these assumptions for integrators they are very important so I'm going to introduce this like so we we want to have that new format which if you come from the devops side of things think of it as terraform right it's a file which describes the state how it is supposed to be um it ensures that the starting point

what you have in your git repo is what's on chain pretty simple but it goes Way Beyond right so here like it documents the expected State the expected critical contract state um you for example proxies right the proxy should point to some implementation right and then if it changes you want to know but there are many other variables like it can detect if those things change and it can also make sure they didn't change and change back right you can imagine this case someone upgrades to a malicious implementation does some State changes updates back to one which you think is fine and you will

never notice right so it covers this by tracking the state divs over time and lastly it allows you to reference other deployments so you can say like I'm dependent on on that system and so on and that system has a certain assumption about the behavior and so on So You reference that in the files but I'll just quickly show you let's see how well this works what this would look like okay and just very quickly general idea project deploys contract at some point runs a lot of configuration transactions someone who creates that file would then

go ahead and later credit based on a snapshot after the configuration has done and then at any point in time later right usually much later user would validate is that file still valid is a deployment still what's expected to be okay so just to show you some some stuff how does it look like I picked kind of a random project we are not associated with um in this case that's um eigen layer right so all you need to do you need to say like this contract is at this address and then uh yeah version 1080

but but that's very simple right that's all you need to do then you start you see the command line here right so you say like hey my code is that I'm layer contracts this is a proxy you saw before like I was saying like it's a transparent upgraded proxy right so we tell it where's implementation um in this case it's an implementation strategy manager this is needed to resolve storage variables and then you just reference that file in this case I'm also giving the initial block and this is because by default if you don't provide it it will take the block right after the contract has been created but in this case a lot of config

settings were set in future blocks so that we see what happens there I have that so I might switch to my laptop because you did not see what was supposed to come here is that possible no okay um okay that's that's a little bit hard so um is there someone who can support this like what just keep going okay so you'd

see some output here which is not visible and it would tell you like the byte code has been verified and it would decode State variables um let's see so I assume this also doesn't work like this is a longer video on how how the thing works right um so that's unfortunate um the presentation will be online so you can check there and then all of that uh will be available so I'll just try to briefly explain uh some important parts in there um most importantly so it generates a Json file which describes the critical storage slots it decodes them in a way

so it's clear for you what you are actually doing like it's it's balances and not some random hash and so on it tells you where these things are right and then you can edit that file it dumps the full state but for us it's important to define the critical state so basically your job as someone who creates those files is to delete a lot of stuff out of them where you say like look that's not a critical State it's supposed to change it will dump all the events which happened and then you will delete everything which you say it's not important to stay the same but some critical events like upgraded and so on you would want to keep it so now the big thing is like how how does

it all work right and most importantly because we are in blockchain who do you need to trust to make this thing work um so the idea is no one right so anyone can create that there is an on-train registry where you can say I am someone who creates these dvf files you can register there but in the end the user is in power to say where they want to pull it from the DVA files can be signed right you can sign them as Ledger or with private keys or whatever and users would generally say look I trust certain perhaps Auditors certain providers to give me good information to to delegate trust to them to some degree

but also you make it very easy to inspect what did they actually sign off on um so some hard things we faced while doing that obviously how do you make it pretty smooth to decode those values you can like a slot uh ethereum storage slot looks like that right so that's a mapping in this case and you need to tell someone what it really is right in this case balance is the owner and the value is not 246 D hash whatever but it's 42 times 10 to the power of 18 a lot more easy to understand if someone put in state you didn't expect it will not be able to decode it

it will warn you about it so you can say like hey what has been going on here we have versioning included so because contracts do upgrade over time right and so on so you can do all of these things what works already is if you have a Foundry project and like a big shout out to Ether RS and the things all of that is built on top of of that system then you can run it already then we can validate them we can do upgrades create new files based on New State

they can already be decentralized distributed and fetched and so on all of that is working you can sign them with and so far either you have a private key on your disk right or you do have a letter to sign off so all of that is working as a quick summary take home message in this case like deployment validation enables like projects to show that their product has been deployed correctly both to them and to others Auditors can document what deployment states are safe users now have a very easy way to check

if that code has been audited if it is still uh what they intend like Dow voters have it much easier to see like what I'm actually signing off on was the intended changes and lastly integrators and then obviously we like build us this is very important they can really ensure that they are interacting with the right system make that much easier and also they get the trust assumptions around this then um they're very like you would have seen it before but they're very easy to generate right and then very understandable like much easier than anything which I have

seen before where you had to go to multiple websites to do this kind of things and my message here of course you should start using them now using them currently um something which we wanna enable the first people to do it like we we never brought this out so we want to get feedback so uh please if you are interested to try this to use that go to GitHub chain security deployment validation and say you're interested we before we make it public like open source we want to get some initial feedback from everyone to fine-tune it to to incorporate that feedback

and we have an idea of future features um like uh there should be an Erp which describes that file format that should be like perhaps hard hat support to support older projects and so on right or ones which use Hardware today many of these ideas very welcome for input from your end what you would need for this kind of stuff and then obviously collaborate like this will be an open source project so okay the video nice um I I know I'm out of time with the speaking time here but yeah sure okay yeah I think that's it

um yeah so you see this file which was created like contract name right where it's at the code hash which has been deployed these are the important parts and now the list of the critical storage variables like it has been initialized initially I was very confused when I did it for the first time because it wasn't initialized you see the owner you will check is that the intended owner you have some other other variables like for example the status here you might say like okay status is not a critical one right you get rid of it you delete it um then we we check all the others implementation and so on generally very critical storage slots we go down and see that there are critical events like

the admin has been changed right what happened here you will want to reason about what happened here um like the beacon upgraded it did never happen but you want a document that it never happened like because when it changed when it would change you would want to make that this file becomes invalid and here you do see that actually this contract has been upgraded twice right and and actually it first was upgraded to empty contract and later to the implementation contract so these kind of things you you can very easily see here we still work a little bit on like making it even easier to to decode and then in the end you can also say a little bit like who you are you

can sign off on this you can describe what you are seeing and the idea is this file will live in the project repo so people have it very easy to say like hey this is where things are deployed this is what it describes but it will also live inside Auditors like Auditors or other trust providers will give this out and then give their ID idea of what they think the system is safe and then you can compare right so yeah this is how the file currently looks like thanks for making this possible give it up for Matthias thank you very much