# Effectivity of proxies - Radek Švarz | BeerFi#2

- Channel: [BeerFi Prague - Web3 Builders Meetup](https://streameth.org/beerfi-prague-web3-builders-meetup)
- Date: 2022-10-07
- Duration: 35:35
- Watch: https://streameth.org/watch/yt-9ouYqVe0dOo
- YouTube: https://www.youtube.com/watch?v=9ouYqVe0dOo

## Description

Slides: https://github.com/gweicz/beerfi/blob/master/events/2022-07-26-beerfi2/slides/Effectivity%20of%20proxies%20-%20Radek%20%C5%A0varz.pdf

https://beerfi.gwei.cz/
#ethereum #solidity #proxies #smartcontracts

## Transcript

um this is the about the proxies um how many how many people over here are actually doing the stuff in solidity or viper or yule or something yeah yeah i will explain it here so now i know better too that it's needed to explain um so uh this is one of the architectures of of the one of the projects which we did lately uh we did this architecture together with naim that's the fourth person who actually established this meetup and uh it solved a few things for or from the i don't know can i move this um there is the uh external person here who interacts with the interfacing contract over here the reason is that uh we wanted to provide like a really understandable uh interface on the inter scan ether scan level for the persons who really want to interact directly with the contract and which calls a proxy that's the yellow one over here the proxy is actually keeping so-called storage so it's keeping the state of whatever that person is owning because he's the owner of the proxy and that proxima x delegate call into the like heavy contract which like executes some something which needs to be done across a different d5 protocols um so that's basically where the the things over around here those are like uh some supporting contracts and so on uh it's not that important um the why we have chosen this is uh due to the fact that we didn't want to actually implement this proxy ourselves this this yellow one at that time uh that was due to the audits because we knew that the maker dial the the ds proxy from maker dow that has been audited several times it's quite proven because the whole day actually went through it uh do you do you guys know what's daily who doesn't know daily raise your hand because that's really who doesn't know who doesn't know just to make sure as a usd stable coin right so one of the biggest decentralized usd stable coins that's day and that's actually when you use it or when uh when it's being minted it has to go through this maker dell proxy so that's for several years that has been proven this piece of code or piece of contract which is actually deployed for every person there who means who literally prints those the those resistable coins so we were like trying to reuse something which is already there on the blockchain that's one thing which i would like to urge the rest of the coding people not to reuse the code from the like templates or the you know libraries and to deploy it again again again but rather to reuse the code which is already there on the blockchain because otherwise we are blowing up the blockchain um anyway uh so this is the kind of architecture and what we will be talking about is this yellow yellow piece of the code over here and the problem which is there is that this proxy creation for the user it's quite heavy on on the gas when you as a user you want to create this this proxy for yourself because it's for every and each person each user is a separate one you spend almost or a little more than half a million of the gas then you have times the gas price so you you might spend something like 30 usd when the gas price is like 50 gray i think or even huh that is never the case that's what that's never the case like it's usually more expensive yeah well no it's cheaper it's a better market so it's good it's cheaper but i do remember that you know when it was a gas price like 150 which was quite common for quite some time in the past you know it's it you just spent like five times more so even like 150 uh no three times more so 90 90 dollars you spend or 100 dollars you spend just to create a proxy which would keep your storage which would keep your assets basically so that's expands uh really expensive uh the question is whether we can do better so we do have some requirements on that um and those requirements are we would like to have a small byte bytecode footprint to save gas on deploy we want to have some minimum gas for passing execution so it means when a pr when the person really wants to use that proxy and do something they pass the execution through the delegate court whereas that heavy contract which i mentioned before towards the green one and uh the other one uh which is not that common among the contracts developers is actually to try to really reveal target contract methods that's again uh for the user to trying to avoid the blind signing i don't know are you guys familiar with the blind signing yeah yeah yeah the auditor is yeah the blind sign is that when you when you sign the transaction even on the hardware wallet you are literally do not know what you are signing because there is something like a um like a t you know you you just see some some some bytes and you don't know what you are saying but when you are assigned a transaction uh when the contract started the the the dogma was that or the action was that what you are saying you know what you are saying so you are then legally alright you know and there is like a even like a legal aspect to it that you know what you are saying so what you sign is final and typically today when you are interacting with the smart contracts you literally do not know what you are saying so that's the blind signing um [Music] and yeah so those were like the requirements and the second requirement was that we we want to have this interaction over here through the proxy which is doing the delegate call and that does the call over here someone might ask the question why don't we allow the user going directly interacting with the heavy contract typical reasons are upgradability that's one of the reasons what is there the other and this is the reason over here is that those contracts over here those d5 protocols they expect to return or assign the things towards the message sender the message center uh would then become the green one and you do not want to keep that assets or inter you know those things uh the results and the storage on the on the grid one you want to keep it for the user on his particle separated isolated space i would say so that's the reason why this architecture uh does it make sense so far a few things to clarify so you need this proxy in order to optimize the way user will get the information about that yeah uh can we get acquired here with that thanks yeah i can repeat so uh if i understood correctly the main reason to have this proxy is to allocate some space inside the the network to store some part of user data for the particle user okay okay and we need this proxy to basically to speed up the way user interacts with the system so the user don't need to recover the state from the blockchain but rather need to go to this specific problem it's not about speeding up it's really about isolation it's it's it's about that fact that uh my assets do not mix with your assets okay so it's about isolation for that particular and every every isolation you mean physical isolation or what kind of isolation you're yeah or almost physically yeah it's a bit more complicated but yeah i'm just trying to you know put all things together so basically does it mean that other users has no access to my proxy okay so exactly it's your proxy you created probably some sort of yeah you i want to you i'm going to proxy that's what you mean here that there is like ownership of that okay so i can store some private data in this proxy and it's in under any circumstances circumstances it wouldn't be accessible by other users yeah okay now it's clear that's that isolation okay cool um okay so that's the architecture what we wanted to achieve while saving the gas and now then we go to the uh ethereum standards uh is here anyone who doesn't know over the eips or ethereum standards who does not know who knows about eips who was not bathing hands ethan okay we have about 15 minutes uh 15 minutes left so uh the point is that uh you know when i mentioned that the previous proxy was like almost 600 000 gas that's really like significantly heavy uh there is a standard for so-called minimal proxy and in minimal proxy uh is described in this standard 1167. the great thing is that is 45 bytes long so deployment of those 45 bytes is like um i don't have that measure now right here but instead of 30 doors what was the heavy one this is like seven dollars or five dollars it's really almost three so like 10 uh yeah 10 10 times less uh that's for the deployment and so if the heavy one with the really high guy uh gas price is 100 this is like ten dollars instead so you can see a significant saving here for the users um uh typically it was used for the unisrap version one for the amm boos uh somehow and strangely opens a plane called them clones uh i mentioned here the question why do they call them clones they call them for the reason that you have like a heavy contract and they want to um that have a contract also including the storage they want to like clone it for the other person so instead of deploying that heavy contract which would be also like two million gas they just deployed this small clock they call it clone but it literally is proxy and uh instead of two million it's only like 70 000 or something like that i think uh did they continue to use it for uh unison week 2 and we three i don't know i don't know because we won this i don't know i don't know um this is the byte code this is what you can see on the right side and now the deep technical stuff what did that what that bytecode does because it doesn't have a solidity counterpart you cannot write this optimization in solidity you have to write it in assembly or directly in the bytecode so this is basically the uh the parts of the bytecode at the beginning you receive some data the request from the user uh then you forward then you forward the data uh to the implementation contract using so-called delegate call then you get the you know whatever that contact does so you get that result of that heavy contact and then you return or revert towards the user that's the logic there this is the first start so what you see so these are the steps that happens when i'm interacting or when i i'm creating the interacting interacting yeah yeah yeah you create it once and and then when and for every every interaction everything which you call towards that heavy contract it goes through these four steps and these are basically the steps and this is underlined by code what what what is you know mentioned there so first uh if if you read this bytecode it doesn't make sense much but you can even read it on the ether scan and everywhere and then uh the beauty is that you have here one step this is called a copy so this means that it takes those arguments what what you are calling uh that's these one two three four or four uh bytecode actions um then actually you do the delegate call it does sorry that proxy does the delegate call to the heavy contract which are these bytes and uh this part that bbb that's actually the address of the uh of the heavy contract um so this is just doing that welcome that address is mentioned over here and then you get the result uh from that heavy contract which is which which are these four bytes over here and you you grab that uh then you need to decide whether there was some error and you need to do a revert so reverting the transaction or doing the return and that's oh actually this this finish over here and those are all those 45 bytes so this is how to understand it that basically using the codes and the the codes of the evm uh what it does those are only four steps and this is how it's implemented uh you might you can see the link over here where it is explained uh there are some optimalizations for that this is more minimal proxy which for the deployment even it's less gas uh even less gas for the call just to mention this one over here this is standardized this byte code over this one this is really a standard this optimized one this is non-standard and there is no willingness to do it as a standard for because it was too late um and um then there is the some extension i would say this this already made as a standard it's called metaproxy which basically uses a similar approach like what we described before but you can add any arbitrary data so for instance my application deploys for you a proxy this one and add some specific for you for you and and for you it adds some other specifics as that arbitrary data and that heavy contract which is being called afterwards can like reach those specifics and understand ah it's you or it's you it's your specific data and those data are stored in that deployment and it's cheaper than do it like afterwards in the storage and so on so this is like cool hack how to add something really specific for the particular present but it's immutable afterwards the the only issue of these clones or these minimal proxies is that they have fixed target address something which which we saw over here this is the address where to call that heavy contract uh over here it was this one that bbb over here as the address where to call and um that's really an issue uh because it means that those heavy contracts you don't have any upgradeability on that and in certain situations you really want to have that upgradeability uh or if you want to have that you either need to ask all the people to actually redeploy their proxies and actually change and transfer the storage to their new proxies then you make a mistake the users do not do it and so on so that's really a hull so you won't rather to upgrade something more central i would say even though we are trying to be decentralized in these cases the centralization might be like the better approach how to centralize this well first of all we tried was like to chain those proxies so we had like a very light one that cloned proxy that 45 bytes and then we chained uh like upgradability proxy behind it and then there was a heavy contract this actually created other issues um on the issue was that that chaining really failed in that methods visibility for eater scan and so on so if you go to eta scan you can on a certain context you can where there are proxies you can you can say read as proxy or write as proxy which means that it tries to reach towards the heavy contracts through that proxy and really read those methods and a lot enabling you to interact with that heavy contracts through that proxy this actually phase when you when you change several proxies you know one after each other uh so that was a problem uh so the the conclusion is that we need a proxy with a mutable target address effective one so still keeping those requirements and this is one of the ways how to do that it's also standard it's called the 1822 um and this is the approach when you can like change the target address pointer within the storage of that proxy it use it uses a defined storage position so there are like no within the proxy there is like no implementation of the changing of that you basically of that logic of that heavy contract you're like setting up the storage for the proxy so you had to have that that management aspect there which says look you are pointing to me but next time you need to point somewhere else um and this this is called uh or this storage position is defined in this way in order not to uh not to uh conflict with other storages which are there on the proxy uh the disadvantages of that the first the advantage look uh what you can see here uh i know do you know how to zoom it ah it's like this right uh if we would compare it to those bytecodes which you saw before this is actually the same approach what we saw before there's a delegate called and there is a you know written data and so on first there is a call later copy meaning copying the parameters so so these steps are the same as in this very small one 45 bytes proxy these red underline things are added first you need to load it from that storage that's one thing and then you need to apply that address which you get from here and use it for the delegate call so there are a few bite calls or you know operations uh at it so it eats a little bit more gas but not significantly more that's good the disadvantage is that the delegated contract can literally kill your proxy because you're appointing here and if you do the mistake or there is some you know footed delegation somewhere else they can literally change the storage over here and they could they could change this storage position meaning that that they couldn't like the point they can change the target to some somewhere else without any you know meaningful targeting heavy heavy contract which kills that proxy afterwards and kills all the assets which are there you will not be able to interact with that anymore and for all users as well and for all users as well no no for that so you have always for the particular user okay so uh every user have to has to like change the contract logic themselves basically yeah that's another disadvantage over here that when you do the upgrade of that heavy contract the target has to be upgraded in each instance so you need to ask that every user please go ahead and do this interaction or you bundle it with some other interaction when the user wants to do something that actually the pointer towards the target heavy contract is changed um so that's disadvantage the other approach is that the mutability you ensure outside of the proxy um one one way how to do it is the open zeppelin starters they have a beacon contract that's a beacon proxy this is a piece of code from that if you just use this become proxy and we tried it into in in the chaining um it's very heavy the implementation you know since it's like uh since it's uh bundling these uh these contracts over here uh and deriving from that uh it's really you know for the deployment is heavy so it doesn't pass the requirement for being light now however overall the approach is is quite good um do you understand what a beacon is no not beacon chain uh beacon as the pattern like signaling system yeah yeah basically it's signaling that's that's over here uh this is the way how to do it that you have the user that does the interaction with the proxy the proxy calls the beacon and we can just you know emits back the information where is the target heavy contract so you have like a center point with some dowel you know management uh ways how to do that and you just say okay it's not you know the implementation what you want to execute it's not here it's somewhere else and you do the change on one one place over here and every proxy interaction is just asking there or always um so that's the way how to how to do that basically it can be done in a way that's similar to minimum proxy design those 45 bytes code and also similarly to beacon proxy standard of the open zeppelin for this part over here uh what are the how it would look like basically from the previous one which you mentioned the only change would be here at the beginning instead of loading from them from the storage we would need to make a call towards the beacon that call is not expensive if i measure that it's only like two 2500 gas so for that kind of the flexibility is very cheap contrary to that regular you know proxy designs of of the opens airplane and so on uh of course you would not need to do the slot the storage loading and um the the advantage which we mentioned that that beacon is centrally manageable it means that you need to do just one track transaction to do the upgrade for all the users uh simultaneously the question and and the strange thing is most of the proxies which we talked today about uh they are like those implementations are like three four years old even the standards you can find in there like 2018 2019 and so on the strange thing is that this is not a standard yet i really couldn't find it um i don't know why because obviously you know the gas is being spent like you know heavily um so that's one thing the other thing is uh we haven't tried it yet so we are not sure whether eater scan and so on uh they will be really passing those methods to you know to to reveal them towards the end user and the other thing is that they're we might have some answer over there i do not know whether if we did it in the bytecode like that but it would uh be easy to pass the audits not sure so that's uh that's it right at the end of 25 minutes you might have a questions on that question uh so you spent a huge amount of time on optimization of of the contracts and the question is have you considered using some layer 2 solution like optimism or polygon or something like that yeah yeah make it like way easier to call yeah with it the point is uh if you look at the architecture which we had here somewhere in the beginning the problem is that some of the protocols which we want to interact with are only under layer one and for instance we have here the interaction with liquidity and the liquidity is on the layer one and uh also the the things which you the the those positions or the assets which you want to keep towards the liquidity you want to keep it on the layer one so yeah otherwise uh when you mentioned the layer 2 and when someone would mention the polygon so like a side chains if you look at the spending of the gas uh try to think what we experienced several years ago you know at that time gas was like three way or something um i do remember in 2017 and and it was in u.s doors it was very cheap so we're like experiencing with something what i did spend on the gas at that time today has a value of several thousands of dollars the spanish of the gas of that time so the same i really predict for the polygon and and the other like low cost you know because everyone is wishing that that that medic or or anything else would really grow up in the value it might be also the case for solana if they are here once it will raise in the value several hundred thousand times you will see what was the gas penetrator in the past okay it's fun to look at old interesting transactions yeah yeah so you didn't still find the idle solution for your program no well i think the ideal solution is this one and then there is a question is just to implement it and using that byte code you cannot implement it in the solidity that's what i mentioned you have to use the as you will assembly or literally bytecode which is good uh but then there are those questions regarding your audits more questions yeah i actually have two questions so number one if you so you make the proxy but the proxy is mutable doesn't like i mean like i guess it's like that automatically makes a security risk and it automatically makes like this signing where you authorize the owner of the centralized contract to modify your proxy it's actually not modifying the proxy with the beacon you are just changing the those center entity is just changing or dial basically you know what one place where you are changing that target pointer so you are not changing the proxy this okay so but and that doesn't require like any like special authorization or signing by the user so what that doesn't require like any authorization by user or like for user to sign something you like you can do exactly exactly okay you are the beacon i am the proxy and i'm almost asking you do i go there or do i go there and you will always answer me and what would you answer me there i go okay okay okay yeah it makes sense who has control over this beacon so what who has control over this beacon it's up to you how do how you design it that's why there is a standard for the beacon proxy and you have like the whole management you know uh functions around that so there is the like ownership of that beacon and so on that's pretty common standards typically it's dull or or some multisig at least so if you need some new version like unispot 3 or whatever you can just open it and point it somewhere else for example and you don't have to force users to deploy new proxy that will cause them extra tokens all right so that's our advantage of like yeah yeah i got it yeah what what audit how would you look at that what about auditing um no i mean most most audit firms won't give you a problem with auto uh assembly like if the problem isn't necessarily an auditing assembly it's just like uh probably there's just no eip because like yeah for eips like the main thing is that you have like someone who's actually got like pushing through and like during the process so there's like a peer review right when there is the eip most people think it's a huge pain in the ass so like a lot of people will just develop the code before actually making it like a standard especially these days so uh like the reason that i mean i'm sure something like if this is in production code it's been audited but like for an auditor like uh you would have to have like the team like write write off like hey this has been audited like this implementation has been audited by someone else or it's been added in this other audit so just like assume that it works so don't end up in the scope because otherwise like yeah you don't want to be putting in like code like this into like every new audit because it gets re-audited we got it ready yeah huge waste of money so what you need is basically someone to like yeah somebody just need one person to pay for an audit from like a reputable firm and be like hey it's audited and then like auditors like if you just tell them it's out of scope they won't look at it yeah so that's that's why there's no [Laughter] okay there was someone else yeah yeah the other question so it's about bytecode so you said it you cannot write it in solidity so you can either write it in assembly or directly in bytecode which is like super weird for me like i worked with bytecode before and especially apple they use it like super heavily and actually if you look at swift like it's compiled like to buy code like one by one you can take scripts and make bicone and then make binary directly or you can take bytecode and make swift you can even like for example apple did it when they changed the architecture much less like when they changed like the 64 bit they actually took the bytecode of all the apps in the app store and they injected a new architecture in the by code and then recompile the icon into binary and redeploy the update of all the apps like on the app store without actually doing anything so like it's like super weird for me like to hear that so that they cannot go to white code no no no here's that that's actually snippet that's like an assembly slip within salinity and the problem with rewriting this in solidity isn't that it can't be done absolutely can be done it just can't be done with these gas advantages like you can't like optimize every single byte code in solidity because you've got like a compiler like step right it's doing the optimization for you so if you want to write like the most optimized smart contract ever then you have to do it in like yeah disassembly snippets are just like mule or like straight assembly oh okay yeah so it's like it's possible it's just it would cost like a solidity compiler would add more instructions that are necessary so we'll end up like costing more that's why we're talking about minimal proxies yeah okay okay that makes sense to put it yes okay we're done so thanks if you would have more questions would like talk more about that and the bytecode let's just chat after our other presentation so i would add i would really appreciate it because i've been thinking about trying to pushing it out as the standard so that would be more like you know peer-reviewed and and more accessible or more uh um for the auditors more uh not accountable i cannot find a word now but uh next generation minimum system yeah well i i try to call it like minimal beacon proxies that it's just using a beacon yeah i would try to get it into something like opens up when if it's possible like like have you tried uh like no no i haven't tried it because i was still researching whether there might be some solutions on that and these are all iphones uh even though i found a few more whatever like literally have it like 700 000 gas you know just for and some of the construction which you could see in the solutions when you have like like eight proxies doing some things or the diamonds you might be aware of the diamonds that very very heavy you know so uh and i think we need to go with the blockchain development since those are immutable deployments we need to try and we need to try to optimize more and finding the solutions which are more optimized okay thanks a lot and let's have a short break and then we will have our next speech right [Applause]