 Hello, yeah, hi everyone. It's so exciting to be talking to all of you here at DevCon and especially talking after Geordie and all the Incredible efforts that they have been doing with the Y-Hats So yeah, I'm Jorge. I'm from the Argon team and kind of to start framing the talk I will talk a little bit about what what Argon is So Argon is basically a decentralized organizations platform built on Ethereum 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 have heard about Ethereum as our user 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 is 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 dam contracts are the best mark contracts and the what this means is like The easiest and the clear than a smart contract is like the better for because everyone will know what are the implications of every action And also it decreases the 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 the minimum amount necessary for the system to work And this is also because this this cat this cost will be paid by your users And this will be the baseline for cost for using our agon 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 smart contracts need to be upgraded and This is kind of like a controversial point because there are many things that could go wrong with smart contracts have great ability The first thing is like we're building these awesome like trustless systems But if we put one entity that can arbitrarily change the rules of the game while everyone is doing it We're basically having like these trustful Contracts again, but of course we would see like what what the path to upgrading is And also there's this interesting attack vector that could happen in which Someone could front-run like a very important transaction to add to a smart contract by doing an upgrade What this means here is like you might be doing a transaction expecting that the system works in one way But before the transaction is mined an upgrade to a smart 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 junk 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 that we will be probably need to upgrade our contracts for adding features that our users request in the future Doing upgrades 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 smart contract operates 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 before doing an upgrade is very important So in this road of doing like this better like an future proof smart contracts 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 contract might have but something that we found is like The problem with libraries is that they're linked at compile time. So you cannot really upgrade them After doing the after after deploying your contract So we work with the sampling guys on kind of doing these approach to operating solely like Solidity libraries What how it basically works is that instead of linking to a specific version of one library We would link it to a proxy library that would then dispatch the the library call to a to the 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 mark on track AVI once it was deployed So it is not possible to add new 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 packs But it isn't as flexible as we would like like it to be So with this in mind we were to we went to an easy and simpler approach that we call the delegate proxy But like how it basically works is like instead of having your your contract logic in your contract You delegate this contract logic to a different contract by using a delegate call This got especially better with the with after the Byzantium hard for it by when the EIP 211 got got included because right now it allows us to by using the return data size and return data copy new Upcodes 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 That return dynamic data types. This wasn't really a a good idea And Using this technique there are 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 in one ready post back in back in the summer And it's this idea of static static forwarder So it doesn't really solve the upgradability feature But the idea is like we can deploy these very very cheap contracts. This is actually an implementation They are so simple that this implementation was done directly in EVM code So this allows us to redeploy like to deploy clump contracts of one contract for a very tiny amount of of gas And this actually the dissolated implementation down with the from the code that that we that we saw it before So these are like very very cheap to deploy contracts and it's like as you can see it's very trivial The problem 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 token contract that gets interacted with in many instances The gas cost is like 700 gas for every additional delegate call that we have to pay in every in every call But in the flip side we get very very cheap contract deployment costs so for example for a Contract that takes one million gas to deploy the moment that we do more than 1300 contracts called to this contract it will no longer be worth it in gas wise to do it But for example an example of a contract that I think it's a perfect example to how this can be used It's with the ENST contract that gets basically created every time any NSB is done So with this contract If instead of creating a full contract with with its code that gets it stored into the blockchain every time we created Approxied contract like this. This would have been the gas savings would have been very very significant And I think this is the perfect example for this because it's a contract that gets deployed many times But gets used individually very little times So with this same idea we can like if instead of these Attries 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 in the same way So here is like an implementation of how these how this would look like as you can see This is also like using the code that we presented before but here instead of doing the the code But the same constant address every time we're doing it to a to a not to an address that we can change So basically calling the upgrade 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 code here. I want to delegate this to this other address We need to make sure that the storage like we're in the correct version of the storage So for example in the in the previous slide we see that both contracts like inherit the same The same storage contract that's because they won't need to know where the where the storage 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 storing or or data So Basically the the it's a very simple idea It starts counting like how many like storage slots you have in your contract is starting 40 from the most basic contract So it will start like counting like this would be stored at the at the zero at the zero slot We're talking about the these contract storage, but it inherits from this one So these would be stored at the zero slot 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 this track like quote-unquote didn't say said all The case of the case of ira is a little bit more complex for static length arrays Like this behaves exactly in the same way as as a strike does and it just puts it in line But for a dynamically length array it would put this story the array length in the storage slot that it would be But then these the array values are restored in the in the hash of the of the pointer there In the case of mappings is actually a bit simpler It just stores the value at the hash of the of the key and the position So the warnings from this is if you're like upgrading from one contract to another It's it's better to like not add storage in the middle because like as we saw the all the storage Depends on what the position is inside the contract So if we had something in the middle all these 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 these storage will be broken So an example of an upgrade that that goes wrong is this one So because of how the how these tracks get stored in arrays We have this initial contract in which which we we are storing an extract of of employee And then we create like a couple employees here with with their salary If after this we upgrade this contract to this payroll to Contract in which we had a new a new member to distract what this will 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 joined it is So it will turn its salary into zero and the salary will be in the joint date But if for example, we use the mapping to store this information Because mapping store and store the values subsequently value from value But there in the hash if we do this exact same thing when after upgrading to these second This second contract in which the we track the the employee here both salaries would be correct But both joint dates would be zero because we never we never said them So we've with all these we we are using this upgrade ability Paradigm in our in our own contracts We call it are I gonna was and the the implementation is actually very very simple We have these 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 all the important business logic in an organization is stored in In apps that are at the at the edges of the system and this way we can keep the kernel very very simple So this is like kind of the life cycle for every for a new call a contract call that gets done to an hour OS contract so we will have the the initial call here This will go to to the upgrade up to an upgradable proxy contract But instead of like knowing what this code is it just as the kernel whether there has been an upgrade and like what what is it? Decode implementation for this app when it gets it It does a delegate call to the to reveal implementation of the app in this case It would be at 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 performed right now? So with this system of the AC of the access control is and the and the 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 upgrade should happen So we are protecting all the upgrades to the kernels and apps to like this So how would like how would an app look like it's it's very simple By by running this app in top of your organization Let's say you're running this counter app to check how many ICOs there were today So we have these these kind of roles 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 out modifier What this will do is like this will plug into the organ the the organization ACL and basically any Governance mechanism that the organization has can decide who can perform this and their work condition And by doing this we can actually upgrade the app 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 upgrade Everyone that is in the app will be will be using this easily 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 app that you can write very very simply and plug it into your organization And use it with all the all the other features that that are gone has Yeah, that's everything for us. If you are curious about this, you can contact us there. Thank you