EthCC 2: Richard Meissner

so hello i'm richard i'm working on the safe project at Knossos and today i want to talk about a little bit about how we deploy smart contracts and how we want to improve that using create tool so let's start out with our motivation why are we developing that not safe and one of our most important things that we want to do is we want to provide a secure and convenient way for users to manage and store their funds and it should not matter how much you know about blockchain or that you know how it works it should be easy for everyone to to make use of the world regardless of your is your and another very important part was is that we provide a nice way to recover your funds because currently everything is tied to your recovery phrases but we want to go beyond that that's why we decided to build a mobile first smart contract-based is your own wallet so as we see here right like the essential part is it's smart contract based so obviously we do care about how do we provide the smart contract or how do we deploy the smart contract for the user so if we think about how would we want to deploy a smart entrepreneur just come new to serum so I don't have any let's assume I don't have any either I just want to deploy a smart contract if not so safe so okay first I go to a centralized exchange I buy some ether then I need to create so then I create myself in the theorem account I funds us a serum account with an ass pants to generate and configure my transaction and deploy it to the serial network so that it creates a safe contract and once this safe contract is created then we could send all our funds that we still have left on our centralized exchange to this new smart contract so thinking about that that is obviously not easy to use for everyone serum knowledge case so how would we imagine that to go right like in our case how we have it currently is in our applications that we educate the user a little bit like what is happening in the flow like what do you need to provide and where are your funds toward it's pretty similar to this when you go to my crypto that you have these pop up some of the beginnings that explain you what to do then the next would be yeah that you have to configure a little bit like your two-factor authentication and maybe some recovery methods and only in the last step we actually provides the user with an address that you should fund and to us it's important here that we don't have to prioritize it's three different addresses or two different addresses that he first has to find the internet account used in the app to deploy something we only want that user has to think about one single address and that is his own address that he will control so this is where counterfactual contract deployment comes into play but what does counterfactual actually mean right counterfactual means a hypothetical state of the world used to assess the impact of an edge so that is really nice so I copied that from Wikimedia and it doesn't really happen like so looking at that we can try to translate it into our assumed term so the hypothetical state of the world would be a certain state of the serum that we assume to assess how the certain transaction would behave so in our case we assume that what we want to have is a very deterministic contract address so no matter how what we execute we are assuming that a contractor sets a specific address because under this assumption we can we can make certain changes or certain transaction and know the outcome so how does it help us understand like it's very important because we can immediately tell the user what is this address because no matter what we do the user should always get the same address and therefore can already use it without actually the deployment transaction being fulfilled the next thing is since we know the address we can then use it for a refund by duress when the user deploys or executes transaction or we execute the transaction to deploy to save we can say the user should send some fancier so that they are refunded to us so there are quite a lot of nice things you can do a set and on the universal log in SDK actually there is a issue where a lot of these cases are discussed so if you are more interested in what else you can do but these two cases are the most important files so now that we know what card effects it is and that we know that we want to use it let's take a look how we do it with out create two because when we started developing the safe there was no constant in open right that's life for one week so how did we do it right now or how how did we do it before clear so we used a little trick so basically we have our service and the client which is a mobile app together they generate a random signature we use this random signature and apply it to our deployment transactions that creates a save from this we can derive the sender since this is an also random sender we know always said we can always use non zero to derive the safe contract address and this safe contract address we can then present to the user in our screen so then the user can fund it because this safe contract address is counterfactual it will never change under no circumstances and as soon as our service sees that that the safe contract has enough funds to refund us we then submit the creation transaction and in the end we get refunded so this is really nice it's a very trust less process so because the client and the service work together and and any information in this process can be validated and it's very transparent also since the refund is managed in the Constructicons contract we can use either payment we can use token payments for the refund so it's not even required that the user owns any ether to create a contract and it's pretty universal since it's using proxy so we can apply it to you a lot of different contract a tree but this flow is by no means perfect so first of all another hood they are still three transactions right even so the user onliest from one transaction which is funding or sending funds to his new safe to activate it the server still needs to fund such random sender and then deploys the actual creation also since we generate this random or since we generate the creation transaction which we use a random signature for ahead of time this is a gas price and the gas limit on all these the serum specific parameters are fixed so if in any case the gas price spikes and goes really high up it might happen that actually this creation transaction is stuck and gwinnett or like or will take a very long time to be executed and another or the last problem is that for this refund since we're using a random sender we cannot just refund the person that submits or pays for the trended creation transaction because at the random sender who would refund that so those funds would be lost so we have to specify ahead of time which dress should receives a refund which normally is our service but theoretically it's possible that our service does also set up it tells even the user what is the transaction but in the end doesn't submit the transaction so or doesn't fund the random sender in this case so then the user himself has to fund this random sender he pays basically the feed but we still would get refunded so this is a little bit where it's a small risk which should not a cure or well not a cure but it is something that is not like the distilled and educates that we would like please so this is a lot of these problems actually could already be solved before create two with a proxy factory so what is the proxy factory I think the easiest way to understand it is the fee splits it up a little bit is what is the proxy and what is a factory and then combine them so a proxy is a contract that forwards like it has its own storage but for what it should do and what logic it should do to change its storage or it state it forwards all that to a different contract which we call so this allows us to really reduce the gas cost for deployment because a proxy is normally a very small contract compared to our you know the safe contract which is like basically because like the gas of a whole block to deploy it and also we have the possibility to actually upgrade to contract logic by pointing to a new master copy a factory is a contract which allows us to create other contracts so um this is also again a mechanisms to save gas since you pay for all the data that you sent to the blockchain and sending the contract data or the logic of a contract is actually quite a lot but since all those data is now in the factory we can save on this gas post so if you combine them we get a proxy factory but there's one additional things that the proxy factory is doing and that is initializing the proxy the proxy has a disadvantage that it cannot make use of a constructor of the master copy so there must always be a separate message that you need to call to put your proxy in the correct State in the beginning and you want that to happen in an atomic transaction because what could theoretically happen is you deploy a proxy at points to a nice master copy but it's not initialized and anybody else could then initialize this proxy but with different parameters of the ones that you would like to have and not initializing and therefore they your proxy could be hydrate right or in the worst case even the master copy could be hydrate which could lead to even bigger problems so let's take a look at a at our normal proxy Factory so it's pretty simple we have a method which creates a proxy which takes the master copies that we want to use and it takes some data to initialize this proxy so first we create our oops our master our proxy this one this command who basically deploy it to a new address on on the CEO blockchain and then if we have an initializer we call our proxy versus initializer data to set it up in the correct state we can see here if either the deployment fails or if there's calls as initializer call fails we will so we can always be sure that it has been set up and it has been successfully deployed of this transaction was successful so if it's so nice and easy to use this proxy Factory why are we using our really complicated flow with all these random signatures and random senders so the problem is actually how do we calculate the address of this proxy it is we take the at the sender and the nonce and the sender in this case would be the proxy Factory and the month of the proctor factory to derive the address so what would that mean let's assume our proxy Factory is at this address so the first proxy we created was his proxy factory would always end up at 0 X e 5c and so on the second one would end up the second proxy would end up with 0 X 3 1 and the third one and 0 DAF like you could continue calculating like deriving the addresses that would come but this is independent of the configuration and the parameter is a master copy so let's assume our flow again that we had before in our app that was where we display the address to the user so let's say we displayed to the user hey this is your new safe address please find the savior's so he sends fancier but suddenly somebody else triggers the proxy factory first so then with the different configuration so the users would lose his funds because somebody else could take over this address basically this is where creates two camps comes into place so create 2 allows us to use the proxy factory again without having this risk but what exactly is created right so create 2 is a new assume operation that can be used from smart contracts but it's pretty low level and currently if you want to use it in solidity you have to use assembly and it basically allows us to create contracts from contracts so this is nothing really new right we saw before we can do that but important changes that the new address that is calculated is not based on a nonce more of the contract but it's based on a salt that can be freely defined it could be defined by the contract or by the user so with this we can now adjust our factories so that we circumvent the mentioned problems so let's take a look at our adjusted factory so since so we added the salt to our method signature so that we can specify that freely so since we have to use assembly we have to do some metrics so we have to create our deployment data but solidity provides some nice helper methods for that so we can get our creation code for the proxy and then we concatenated with all the constructor parameters which is a master copy for the proxy and then we use to create two assembly code to actually deploy the contract create two takes for parameters the first one is the value you want to send to the newly created contract so faster that's always zero the second one is how long is your deployment data and this and the last one is no actually the other way around so it's the point that was the deployment data and that is how long this your deployment data and the last one is the sole that is used to if you have the same deployment data that would always be the same address so the salt allows you to randomize a little dress so let's take a little bit closer how this is addressed populated there's the EIP 1014 that specifies it and we basically what it says is we concatenate the FF pide with address a sold and the hash of the init code hash that whole thing again and then takes the Lord 20 bytes for the address so in our case for the newly generated dress so in our cases address is a proxy factory so sold is some random data and init code is our this deployment data code what we had so our contract code plus the constructor parameters so now that we have adjusted our proxy factory we can let the client and the server and negotiate some random data and everything is perfect right like everything is simple and actually there's one more thing that we really have to pay attention to and that is this initializer part so as we have seen this the address of so create data only depends on the soul so the deployment data so no matter what initialize our data we use it would always result into the same address so assuming our case from before again we now show the address to the user then the user function safe now it would be possible that somebody else triggers this factory but uses different deployment data and then takes over again the address but this is luckily pretty easy to fix so what we have to do is we just adjust the method to take a nonce or some other random data and then combine this with all of the data that is important for creation and initialization of the proxy so in this case we generate the competiveness initializer data with the nonce and just hash the whole thing and use this hash as a salt so in this case it means if any single issue in the initializer changes we can be sure that also the address changes and this is very important not only for the client but also for us when we deploy the safe because let's take a look at what actually we use for the canosa safe has an initializer - under standard right like so first we have the owners and the threshold which is obviously the client wouldn't want such as different owners or different threshold and sorry plural saved and the other one has actually the informations about the refunds or about the payment so our service still would love to get refunded and we want to make sure that that is always the case and that's why we want to make sure that these parameters cannot be changed by anyone and we don't get refunded right so let's summarize this so now instead of having three transactions for our whole deployment flow we only need two transactions so you either need to fund to save and the service then triggers a factory and deploys a safe also the gas price and the gas limit are not tight anymore to the whole deployment process so we can change it at any time and transaction cannot be stuck anymore and also we don't need to specify the refunds receiver ahead of time because we can just use TX origin to refund the person who actually submitted the transaction to the Shane so it's not depending anymore on just pre-specified so this is just a small part of what we are doing right if you're interested in more details how do we use token payments how do we do other technically that's feel free to visit our website or look at our repositories everything we do is open source and we are happy to inform you about everything we also want to support projects that integrate with a safe or any other Knossos project and drive forward a serum so if you're interested check out our noses ecosystem fund and I would say if you have questions ask me questions but I know that I'm short on time so if you have questions we have a booth outside or find me and in the Gregory room [Applause] it's actually the like [Music] yes