Designing Future-proof Smart Contract Systems

hello yeah hi everyone it's so exciting to be talking to all of you here at Def Con I'm especially talking after dirty and all the incredible efforts that they have been doing with UI hat so yeah I'm Jorge I'm from the Argonne team and kind of to start framing the talk I will talk a little bit about what with Aragon is so Aragon is basically a decentralized organizations platform built on a theorem we build the software and the infrastructure so running decentralized organizations can become a reality and we are doing this with like focusing on like non-technical users or people that might not have heard about the theorem as our users so we're very careful that they will be able to use it and also it's very important for us that the system is extendable enough so it can be used for very like large-scale systems but also for like more tiny things so when we talk about like future-proof smart contracts what we really mean it's like how can we make sure that the contracts that we're building today for these organizations are going to stand the test of time and can be used by organizations for many years so these are kind of like three very obvious points but the the first one is like the damn contracts are the best buy contracts and the what this means is like the easiest and the clear Edina smart contract is that better for because everyone will know what are the implications of every action and also it decreases the the attack vector for for it also something very important for us is like to make sure that we only do in the smart contracts the minimum amount necessary for the system to work and this is also because this this course will be paid by your users and this will be the baseline for costs for usin Aragon and also the Third Point and the one that I will spend more time during the talk talking about it's like we really feel very strongly that's my contracts need to be upgraded and this is kind of like a controversial point because there many things I could go wrong with my contract separate ability the first thing is like we're building this awesome like trustless systems but if we put one entity that can arbitrarily change the rules of the game well everyone is doing it we're basically having like these trans folk on contracts again but of course we would see like what were two paths to upgrading is and also there's this interesting attack vector that could happen in which someone could front van like a very important transaction to a smart contract by doing an upgrade what this means here is like you may be doing a transaction expecting that the system works in one way but before the transaction is mined and half way to is my contract happens so this is something to take care of so anyway why do we need smart contract operators it's because like as we all know this is an extremely young technology and there will be probably backs that are better solved at the contract level than at the protocol level and also like we're very young so there will be probably need to upgrade our contracts for adding features either users requests in the future doing average right is something that we are very passionate about at our gun and I think these are also like very obvious points but it's very important that these my contact cap rates are not controlled by just one entity and a very important point is if they are time-delayed people can then explore the new contract and decide what to do with it and also having an efficient governance process we before doing an upgrade this is very important so in this road of doing like this better like and future prismatic contrast we kind of started early this year focusing a lot on the solidity libraries approach the solidity libraries are great because they allow you to really isolate different logic domains that your contracting I have but something that we found is like the problem with libraries is that they're linked at compile time so you cannot really operate them after doing the after after deploying your contract so we work with the sapling guys on doing this approach to operate in solid like solidity libraries what how it basically works is that instead of linking to a specific version of when library we would link it to a proxy library that would then dispatch the delivery call to a to T correct my contract this was interesting because it allowed us to change the business logic after the contract was deployed by the problem with it is like it didn't allow us to modify this my contract avi1 see what's avoid so it's not possible to add any functions to the contract or to like change one of the function parameters and also the data structures that you have are going to be fixed forever so this is very interesting for solving business logic PACs but it isn't as flexible as we would like like it to be so with this in mind we were - we went to even simpler approach that we call the delegate proxy but like how it basically works it's like instead of having your contract logic in your contract you delegate this contract logic to a different contract by using a delegate call this code is specially better with the with after device and Jim Hartford by when the EIP 211 good code included because right now it allows us to by using the return data size and return date a cop in Europe codes we can check after doing a delegate call or whatever call we can see how many bytes did the underlying call return and then return that many data because before this you kind of had to specify how many bytes you were expecting from the call and for function calls every turn dynamic data types this wasn't really a good idea and using this technique they're like two things that we can do here which we call like flavors but they're like based on the on this same idea the first one is like this was introduced by Vitalik and we're ready post back in back in the summer and it's a div of stagger D is static forwarders so it doesn't really solve the availability feature but the idea is like we can deploy these very very cheap contracts this is actually an implementation it they are so simple that this plantation Western directly Navy m-code so this allows us to really put like to deploy clone contracts of one contract for a very tiny amount of of gas and this is actually the desolated implementation done with the from the code that that we before so these are like very very cheap to deploy contracts and it's like as you can see it's very trivial deploying with this is like for every call to these contracts we add an overhead of gas because we need to do this this delegate call so for example this is not a good idea for a talking contract that gets interacted with in many instances the gas course is like 700 gas for every additional delegate call that we have to pay in every in every call but in the flipside we get very very cheap contract deployment costs so for example for a contract that takes 1 million guys to deploy the moment that we do more than 1300 contracts called duties contract it will no longer be worth it in gas wise to do it but for example and an example of a contract that I think it's a perfect example to how these can be used is with the en STD contract that gets basically created every time an SPD is done so with this contract if instead of creating a full contract with with its code that gets stored into the blockchain every time we created a proxy contract like this this would have been the biggest savings would have been very very significant and I think this is the perfect example for this because the contractor gets deployed many times but gets used individually very little times so with this same idea we can like if instead of these at Rice that we're doing the call is being a constant if we make it flexible and variable we can actually do a great ability in this indecent way so here is like an implementation of how these how this could look like as you can see this is also like using the code that we presented before but here instead of doing the dakotas the same constant address every time we're doing it to to add an add to an address that we can change so basically calling the average function here would change the code where the where the contract is using the problem with this is like because we're using delegate calls which is basically telling the contract okay don't run my code my contract out here I want to tell achates to tease order address we need to make sure that this storage like we're in the correct version of the storage so for example in the previous slide we see that both contracts like inherit the same the same storage contract that's because they both need to know where the where the story is and for more more complex cases in which you introducing inheritance and all that you need to be very careful with how you add the the storage so this is actually important to understand how solid it is historian or or data so basically the the the it's a very simple idea it starts counting like how many men like storage slots do you have in your contract starting for the from the most basic contract so it would start like counting like this would be stored at the at the 0th at the cereal slot we're talking about the these contact storage but either inherits from this one so these would be stored at the zeros cloud these would be stored at the at the first slot of the of the contract and so on and so forth but for example in the case of an extract this would be like as if we put this in line right here and distract like quote-unquote in exercise at all the case of the case of I race is a little bit more complex for static length arrays like this behaves exactly the same way but for a dynamically length array it would put history the the array length in the storage slug that it would be but then these DeRay values are stored in the in the hash of the of the pointer in the case of mappings is actually a bit simpler it stores the value at the hash of the of the key and the position so the warnings from these is if you're like a braiding from one contract to another it's it's better to like know that storage in the middle because I guess we saw the oldest storage depends on what the position is inside the contract so if we add something in the middle all the storage would be broken and the problem with this is like this failing will be silent so it won't like if you don't do it like nothing will say this is going to break your contract but whenever you start using the contract all the storage will be broken so an example of an operate that that goes wrong is this one so because of howdy how these tracks get starting raised we have this initial contracting which which we are storing instead of employee and then we create like a couple employees here with with their salary if after this we operate this contract to the spiral to contract in which we had a new a new member to distract with this what will happen when we try to fetch the first the second employee salary is that it will be stored where the employees first with the first employees join that is so it will turn its salary into zero and the salary will be in to join date but if for example we use some mapping to store this information because mapping stones 30 values subsequently body from value but they're in the hash if we do this exact same thing when after upgrading to this second or the second contract in which see we track the DD employee here both salaries would be correct but both joined edge will be 0 because we never we never set them so with with all these we we are using this upgradability paradigm in our in our own contracts we call it Aragon OS and the implementation is actually very very simple we have this tiny kernel contract which actually keeps track of all what the how all the contracts that depend on that organization gets stored and we basically store all the old important business logic in an organization is stored in in apps that are at the at the edges of the system in this way we can keep the kernel very very simple so this is like kind of the lifecycle for a repo for a new contract call that gets done to an hour ago os contract so we will have the the initial call here this will go to the upgrade to an available proxy contract but instead of like knowing where this code is it just has the kernel whether there has been an upgrade and like what what is it the code implementation for this app when it gets it it doesn't delegate call duty to reveal implementation of the app in this case it would be app zero version one after that the app if the if it's a productive function that it's being performed this will ask the the contract the kernel again oh hey can this action be perform right now so with this system of the AC of the access control is in the NT kernel what we can do is we can use these complex governance mechanisms that you could have in your in your organization to decide whether or not an app which should happen so we are protecting all the average to kernel synapse to like this so how would that like how would an app look like it's it's very simple by running this app on top of the organization let's say you're running this county rap to check how many icos there were today so we have these these kind of rolls inside the the app that define what are the different actions that can happen inside the app and then we just protect them here with the alt modifier what this will do is like this will plug in to the organ the organization ACL and basically any governance mechanism that the organization has can decide who can perform these and their work condition and by doing this we can actually up with the very simple and add a new and a new storage a new storage value and like a couple new functions and this will work and after performing the operate everyone that's using the app will be and this is actually how it's going to going to look like this by making these very very tiny app you can plug this counter out that you can write very very simply and plug it into your organization and use it with all the all the other features that the Aragon has yeah that's everything for us if you are curious about this you can contact us here thank you [Applause] [Music]