The verge is (not) going to break your contracts! by Hadrien Croubois | Devcon SEA

yeah so Verge is not going to break our contracts that's good right so I work for open Zeppelin and at open zeppin we provide all kind of services to the community that obviously includes the open- source smart contract libraries but also Audits and so on and we do that because we want to provide a good a good context a good ground for developers like maybe like you to build the next trillion dollar economy that is going to be poured by smart contract and so in doing so we want to understand what's the environment you'll be working with how the evm works how the blockchain works and Sh that knowledge review through these talks and also through the the best practices that we apply to our contract and yeah just a few days maybe weeks ago I don't remember we deploy we released the last version of the smart contract Library the version 5.1 that's been in the making for quite a while and to me personally it's a big milestone because it's the first time that we put knowledge of up coming blockchain change like The Verge into the design of the contract we adopt a proactive approach that the contractor deployed today maybe more efficient in a few months so what is the Verge and how it's going to affect Dev so I was told to not talk of the merge too much but to rather mention the transition to a more stateless ethereum with stateless clients The Verge being one one of the approaches for that transition and what the Verge does and how it can achieve better statelessness a stateless client is by changing the storage layout to be more friendly to to to to ZK proving so right now what we have on ethereum is a storage layout where we have a Patricia Merkel tree that is divided in two section and the top section is basically the entire world of accounts and under accounts some accounts don't have storage and that's done but some accounts do have storage and then you have to go further down and do the ion storage tray and that's how it works and when you want to prove some storage you have to prove a miracle proof that goes all the way from the bottom to the top and that's that's kind of long that's kind of expensive that in Practical if you want to build a stateless client so what the Verge does is proposed to change this storage layout to use veral tree that contains all the data of all the accounts in a different pattern and basically there are still somehow two section there is a main tree that are the first 32 by of this better hash that is Computing using the address of the account and the offset offset being like the position in the storage that we we already have and then that gives you an extension and an extension contain 256 values and and then you use like the last last bite of of of your position of your of your offset to know where you're in the in the extension that means that an extension is owned by a single account but then all these extension of all these accounts are in the same same same veral tree and this is a radically different radically different vision from the previous slide because in the previous slide all slots were like identical slot one and Slot 20 were were basically the same object and warming one up was required when you wanted to agree or write to it and the same was true for for the other slot and all slots were like identical in the sense that you would have to warm them up individually but with the Verge what you're warming up uh and by warming up in the case of the Verge we don't really what we mean is put like in the in the in the proof sorry in the in the commitment I don't remember the name we come back uh but what we do is we we put this this extens complete extension and we prove it and this completely change the Paradigm because if you want to access two different slot if they are in the same extension you only pay once so it's way more efficient to access storage that is close to one another which was not the case before the ver which is not the case today and so this is a rough timeline we go from Denon that we passed to Petra that is coming soonish with a lot of great feature we have heard about it during Defcon two hopefully the Verge me this is changing there maybe faka before uh I'm sorry for for that but yeah I'm I'm really looking forward to to this as I hope many of you also are uh and this will impact our contract as we see like it will impact them in the sense that the gas cost will be measured differently and do has an impact so that's why I want to what I want to dive into today and disclaimer this is work in progress The Verge is not definitely final and those are the best numbers I could come up with with the help of Gom from the from the guest team from the EF but those are possibly not the final number but it's still a good idea so let's dive into this first graph there are going to be a few of these so please make sure we all understand what the color means uh here we're representing the gas prices of frequently done operation on tokens such as erc20 725 and 1155 and we have two type of operation there are the simple transfers that are in blue and there's a transfer from so transferring someone else's token using a permission that are in green and in both cases you have like a light blue a light green and a dark blue a dark green the lighter colors are the cost that apply today the darker colors are the cost that apply after The Verge and this color scheme will keep it like lighter is now darker is after The Verge and what we see here is that basically for all classical transfer operation on tokens it's going to be more expensive that's that's the bottom line but not but a by a lot so it will still continue to work unless you're crazy enough to hard cat gas prices somewhere in Europe but like it could continue to work but like RC 721 is going to be affected a lot the reason it's more affected than the other is like when you do a transfer from or a transfer in ERC 721 you are checking two type of approval because you can approve one token and you approve an OP can approve an operator and those two checks are two slots that are being warmed up and they are not in the same location so there are two extension so the price the over cost of of fing an extension is significant significantly more visible in the case of ERC 721 uh and then let's look at other contracts that are quite interesting there are governance contract I love governance and here we are looking at open Zeppelin contract in blue and compound Governor Bravo in green and we're looking at the different operation that are done in the life cycle of a of a governor proposal which is you propose you cast a vote you Quee and then you execute here in the execute we execute something small so that the actual cost of the execution is hidden what we only look is the cost of the of the governor part one thing that is quite interesting that we is that for governor open Zeppelin the price doesn't change that radically the execute is a bit more expensive but otherwise it stays pretty similar and there is a good reason for that is that in our governor we don't use storage that much to try to reduce it to a minimum on the other hand Compound uses a lot of storage because when you propose you store the proposal to the chain and then you refer to that proposal stored on chain through its identifier and what's good with compound Bravo is that that the the the proposal is sted in a structure that is very sequential so it turns out to be very efficient in the context of The Verge because like most of the of the proposal will be in the same extension so you are actually saving a lot of cost by warming up the entire extension water than warming up many many slots and that's what why the Verge is actually reducing the cost of the execution on on compound at least in the proposed part so the idea that The Verge is going to make all cont more expensive is is is wrong some contract can be made cheaper with the Verge and it all comes down to how the contracts are designed and while the practices of the developers are this is something I wanted to measure it's the cost of trading tokens on Unis swap so the x-axis is a number of hubs like the very left most points are just trading token a for token B and the right most point it's trading token a for token B for token C for token D all the way to like token G or something like that and so I want so it's scal basically linearly and in blue you have compound V2 in green you have compo V2 sorry Unis swap V2 in green you have Unis swap V3 and what we see is that Unis swap V2 is a bit less expensive than un V3 today because there is fewer logic less logic with the the like the narrowed down position and the and the capital efficiency and that will greatly like this additional storage will greatly be visible in in UNIS V3 so it's likely that unap V3 is still the better choice after the transition to to veral because it's just way more Capital efficient and the gas you pay will be uh saved elsewhere because of like you will have better prices on your token but something that interest me a lot is unis swap V4 because Unis swap V4 and unfortunately I was not able to run it in in veral we can go on that later but Unis web V4 doesn't use that much storage at least not on the to side because because of the single tone design there is no token transfer for the intermediary token it's just like the first token and the last token that are being transfer and the rest is just handled internally by by the single turn contract so I'm I'm curious I'm I'm sorry I could not get those number but whenever I get them I'll make sure to share them everywhere I can like on social media because I want to see how Unis V before do in verle I am expecting it to do pretty good maybe I'll be proven wrong but maybe there is a very strong case for unisab V4 here here and and again I think that using transient storage and doing the way un before does it is probably like the kind of good design that we may want to do right now because they are good but also in the long run because they they will be more veral friendly so small control design for a veral evm what you can do now so it's pretty simple like you want to avoid storage and you want to pack your storage together and that's something I did for my last to that was at atcc is taking erc721 the token and try to put stuff together in particular we discussed the fact that there is a token approval an operator approval an owner and a balance and thing is that the owner and the and the token approval are both mappings that go from two unit 256 which is a token ID to an address in both cases and rather than have two mapping let's have a single mapping Mo a structure and so when you load this structure you are likely that it fold in the same extension in some cases it will not because of randomness of of cash but but usually it should and so these are changes that you can apply today the reason we don't do it is be in the main contract is because it would break our storage layout and that has an impact on our upgradable contract but we could technically do it today and like when you run them on the test network of of veral and again the slide will be available online so the links here you will be able to click on them to to look at all the witnesses um but you can see that on the left it's the traditional r721 and on the right it's the one that is packed and you see that you have two s loads that are significantly cheaper those were pretty old numbers so I'm not sure the gas prices would be fully correct here but the the idea that the widness is smaller because of the packing that that remains valid and so this is measured with today's number you have erc721 from the main repo on the left and the packed version that is just my edit on the right that we don't ship yet and you see that the prices of running this two version today on on conun is basically the same like it's marginally different that's that's experimental error but after transition to to the to a Verge node like you see that the the ERC 721 pack really greatly reduces the overcost of of the of of like warming up the extension by about a third like we move from three extension to two extensions somehow so so that's basically what what we expected so there are design decision that you can make today that may not impact the optimization of your code right now but that may have consequences in a few months a few years uh if we do this transition to The Verge for for having a more stateless ethereum so the conclusion is The Verge is not going to break your contract you're safe it's at worse it will be a bit more expensive but most system should be able to work with that seamlessly but it will haveen affect the cost and you can make decent decision today to improve that eventual future and the decision you have to make are try to avoid storage and that's a general set of rule like avoid storage if you can and if you cannot avoid storage try to use continuous storage so use arrays instead of mapping if you are writing a compiler you can do a lot of work here like in the arrays in solidity and and Viper the lens of her array are stored at the pre-image of the array and then the value are stored at the hash of that pre-image you could decide to put the lens at the first St slot of like the image and not store something at not store anything at the pre-image you would just shift your arew by one and put the lens at the same location as the first item and it's likely that when you access low item in your array like it's one less extension you have to load so that that may be an optimization uh we I've discussed that at length in my previous ethcc talk so if you are able and you are interested have a look at it again this link to the slide will be at the end and yeah like we we we do have some vertical friendly design choices like in RC 7201 and hopefully like the compiler will take care of all of that at some point but for now it's not the case and it will be breaking the storage pattern so it's I'm not sure I mean something s has never done before so yeah if you are inventing a new language take take that into account okay thank you and link to the slides and if you just type share. Adrian kua.com then it's index you can get it from here amazing great job Adan all right so we're going to get started with the questions remember you can scan the QR code you can send your questions thank you for the person who just did you can also vote for the questions so they I don't get answer first so thanks for the great presentation so let's start with the first one a little of off topic do you also evaluate contract designs that optimize for eof not yet but eof is certainly something that is coming and likely sooner than than than veral so we we definitely we we carear a lot about ver about about e we want to make sure that it's not going to break our contract we hope that we are able to ship the same contract that work with eof uh it's unclear whether we are going to be able to do that or not maybe solidity will have a major update anyway but like we we worry about eof I just don't have any final result to give you today great great great great question yes keep sending the questions does open Zepp has an array lip that stores the length in the first slot no we don't have that kind of lowlevel libraries uh not yet at least uh so far we've tried to always work with the solidity layout and not modify it uh but other people are doing it and maybe we'll do that in the future why not that's a good idea we we'll have to discuss it yeah I think that you also mentioned a call to the compiler teams to just like start thinking about all these changes so if there's anyone here to listen or set to a friend I think that'll be useful when do you ECT that compilers oh very relevant solidity and Viper optimized for verles that's a very good question I really don't know and I'm not very optimistic uh one particular reason is that solidity never broke their storage uh representation uh and that would mean breaking something things they've never broken since 2015 2016 so definitely not in version 08 probably not I I expect solidity 09 will probably be e F or something like that uh my expectation is that solidity is moving to a completely different design of the compiler with standard libraries and the compiler will be smaller and maybe that's when like the standard Library maybe open zeppin I mean I'm counting that open zeppin build such standard Library solidity ever relies on them and that would be our job to do this kind of optimization so yeah working answer all right uh sorry let me Mark that okay let me ask this question does it make sense to implement a set of addresses like 70 7 21 approvals with an array instead of mapping maybe for a fun set or as a cache uh it really really depend on the length of the mapping and how you access it so it not as a as a general rule no maybe in some particular cases yes and that's what I want to encourage you to measure and to like maybe next year at Dev connect you give a talk about that great how does Co chunking cost affect deps I'm not sure I understand what code shanking cost so maybe we can discuss that after outside and you can give me more details because I I I cannot provide an answer s right now sorry yeah no no that's that's fair uh it seems like 20% more expensive transactions is a big deal even if it's 10K any idea why uh well I mean we're when you look at small transaction yes plus 10K it's 20% yes it may may not be a big deal I mean it really depends on the gas prices cuz like plus 20% if veral means that like we have better stateless client and we have a lot of crazy things and we have better l2s and things like that maybe having bit more cost on L1 is is acceptable um and any idea why so why it's more expensive so why is loading and extension so expensive I did not explain why the reason loading and extension is so expensive is because you have to do a person hash of your IC cont address with the first 31 by of the asset and a p hash is complicated to compute way more complex than aak and so the the the node have to account for that complexity when they execute the transaction that's why they're going to make you pay a lot for that that's also why we have extension we don't you don't want we don't want you to pay I mean the cord have don't want us to pay this person and hash for each slot we access so they give us 26 256 B bits I Me by slots extensions great answer um I think there's no more questions so Adrien thank you so much please give him a round of applause