DAPPCON 2018: Solidity Dapp Optimization Gonçalo Sá (ConsenSys Diligence)

Transcript

so my name is Gonzalo and I'm here to talk about solidity in between Alex and Christian so my only hope is that I do not make it full of myself aha yeah let's talk about optimization optimization is relative right if we think about cars we can optimize for the fastest car and that would probably be a Bugatti Chiron right or we can optimize for the biggest amount of Swarovski crystals on the surface of a car this is also optimization so main point here being that settings and constraints can turn things upside down

let's make better than just talking about this is showing it so let's make this a little bit more interactive bear with me here like let's pretend we're launching salt off would be the equivalent of like H star prefer solidity and I want you to guess which of these is better so in terms of resource spending anyone want to take a guess well right or left left why well to be honest like here we only can see like storage right so we can be good neighbors to the etherium tri-state and try not to waste more space than we need

so we'd probably go with that one sees those are tightly packed and they would only waste one slot in storage right but so this is the right one gives it actually way slash storage but what if I do this what about now [Applause] any guess no here we don't care anymore about storage right because we care about our clients we care about gas we carry that our clients don't pay is the minimum around a lot of gas possible so in this case the one that's best is the one on the left because if we go and see

what up cuz these two functions are compiled to you'd probably see that the one with the Ewing aid is coming out to a lot more opcodes because you need to mask it out of the storage slot so we turned the tables around right now what if I say this again we turn things around so the one that uses last gas is the one on the right because what they'll do is that here you actually have to use 3's store operations because these are allocated to each 132 right storage slot and the one on the right can feed only one and at the end of the

day we it will only be one as store at the end of the function what about this one yeah so this one you'll be surprised it's the one to the left because again we only make 1s load right the other one will actually fetch from storage twice in their costly up goods right if we do only one s load will be better off so get it into memory and then used it how many times you want yeah no this is this is this results are with the optimizer

turned on at EEP now when you're using constants make sure you use literals don't use constant expressions don't think that just because you're using the constant keyword if you're doing a cat track 256 hash it will not use the sha-3 opcode because it will it will be evaluated at at run time and the sha-3 opcode is costly and you should just recompute that and have it as a right 32 literal right so use literals wherever you can also make sure not to use public in every storage var because they are the ultimately they will clear the y code

with the getter that you probably won't meet the whole lesson taken from this is that you actually have to analyze each situation severally and carefully because you'll be different every time now if we think in a more architectural kind of way if you're deploying galore a lot of large the same large contracts over and over again then you probably can make use of adèle ago called proxy right I'm sure you all know about this a proxy would do a delegate call fetch the code from the large contract and you'd save a lot on deployment costs right the the full delegate called proxy back code

would be something like this and this might be a personal opinion but I believe that interface proxies should be as lean as possible they shouldn't have to deal with any logic at all so if you want a build upgradability don't do it in the interface foxes make sure that you have like another one to deal with that make sure that if the interfaces area is showing to your client are the most auditable most simple thing you can you can provide them now another thing that I was thinking about is that when you have a proxy you cannot make use of a constructor right

and since we're here hosted by gnosis I took the gnosis aphanitic as an example what you have now is that you have to have like a setup function that you can call within the same transaction and act as a constructor now the reason why this is not as good as an actual constructor is because you have to make sure that there are certain constraints to that function right that it can only run once because that's what constructors are supposed to do and relaying that those checks to the application part instead of just relying on the way the EVM is

supposed to work is maybe not the best option right so what we do is we can take the large contract that we just talked about could be no so safe we actually get the constructor right code out we get the run time by code out make both of these deployable and basically we have like a proxy that now makes to delegate calls one in its constructor and another one for its run time biker well this would mean is that we could probably just use a constructor in the nosy safe contracts and this is all guys

thank you so much