Toward Backward Compatible Ethereum Upgrades by Wei Tang (Devcon5)

a short introduction about me so I'm retime ecology well tonight party technologies and I worked on in serum and eye serum 2.0 so in this talk I'm going to talk about backward compatibility so in different contexts we have different definitions for backward ability for example in the context of system interface is mostly about internal with an older version of the interface and also for things that handle files and objects it's about handling those things produced by older versions so we're talking about backward ability in a blockchain context so we are really talking about smartphones smart contracts and the definition here I gave is if a smart contract works in the past they need to continue to work in the future no matter how many future upgrades we add so the scene we talked about here today is that is the not-so-nice lowry about died portability in science erm so Michael can really can be really easy to be broken for a lot of times I intentionally or intentionally as we demonstrated I assume so this is a huge issue because I'm 10 contracts are affected and also a lot of real money involved for unintentional background copy breakage we have the example of ERP 1283 which is to change to decrease guest host but unfortunately we found that if we do that and there are some issues with high probability because it can cause some contracts to have new entry attacks and we also have a ready for instant war which is VIP who increase cash flows we also figure out this country by probability because you can just call some functions of some contract to be frozen so those are intentional Packer have real breakage are nearly missed in the holy deity auditing process we nearly found it for the last minutes and it caused some a lot of issues so you know patch may also have debate about my very increasing guys thoughts or decreasing class codes will be better and it turns out both scenarios can break hydrography so is the same vaccine and in the future we may also have intentional pack of heavy breakage so for example if nobody knows that guys cause pre kerosene so in the future we might just go ahead with some some guys for changes if that's really pricing and we want to reflect the real computation computation cost and also the example for statement which is a I don't know my very well to adopting now but we probably want to have something there proposals to fix state floats which can also bring back workability and we also have to engage from conduct to ETH 200 chart in that case some comic rights can be broken as well so this forms to a conversion II it's really about that we currently don't have really card for a background LP that is so easy to be broken so we're probably about to do something with it so in this section I'm going to talk about three different versions of account versioning from code prefix to special contracts to arrow key fields just give you an idea about how this involves and the same we finally settled on so the earliest is probably the code prefix which was in yeah p.1154 in 2016 so it did a little scallion account resolving give us some support insurance so the idea is quite simple I'd add a small country fiction I read contracts and if the contract attack that that prefix and we just execute using that version nation of the default version so this is later expanded into year key 7007 so we did have some issues so this code prefix along the issue is that some we can deploy data internally so some that have match just accidentally have prefix and what is the Coulomb chance so this is a huge issue for me and that requires validation so it's just really light and we can do something about this so there's a way that we can discuss all I use up code deployments so that we don't have those data function that accidentally had the prefix but the issue is that is not back workable so the second variations we had was using Excel returning were special contacts so this was the FE 1891 in 2019 so basically the idea is pressing for we just store the version information of account you know special contract status starting a loan location and then whenever we execute a contract we just reach the version from that special contract first and then decide which for young widows so this is quite simple it does not require anything to state the issue however is that we need a different node tree operation which is kind of tired because I mean each trail fishing for all accounts is means we double the tree access and even the current free access is not really fast so just as I give you and late finally we have the conversion in we are field so this was originally CICS and 14 in 2017 the idea is quite simple also quite simple so we have for our P encoding currently lunge silenced or root code hash which aside another inversion and we use that to determine the words or three amigos so later this is expanded into 7002 and this is actually quite robust and entirely backward compatible so there is also strongly favored by the six one five team during the recent board discussion we had less culture in science right if so now cast and party and I believe another and AR th of Oh half of TR open for this conversion II implementation is also slightly good for the storage proposal because now you have used this version field to determine determine what the rest of the arc you feel that story might act means so if we provide some semantics for them and it's a current selected are conversing in solution so for completeness there's also one thing we need to talk about is about using this portion then how what is the version the child contracts that created five heart contracts so in yaki 7002 they speak what kind of Concord family and later we can discount Rama can be extended so we can have some extensions to Yankee from Teochew that allows different conversions to be created but it's easy for companies so we can release this if you want and then we have the version list evn so what we are talking about here is really if we only have a count versioning so issue is every six months we want to deploy a new version that for some teams is not so sensible so that that is a huge pushback during this time for discussion some people just think our conversion is cool but if we need to mention too many conversions and that is a huge maintenance cost and we may not want to do that so version is VM is fixed to try to authorize lads so what we do is we design design things ways for workability diamond and we remove some offenders that Greeks buy property in the VM so in the end we just have one inversion so so the current UV immersion will be the legacy version and we just have one more version which is a personalized evn and we can add new features change guys goes on that conversion so talking about like general things about interface design there's something really important it's called form so it basically said that if you have a sufficient number of users so it really doesn't matter what you promised in the API like all the observable behaviors in your system will be used by someone so so assume with definitely has sufficient number of users so here install definitely applied to us and I mean during the back recovery discussion many people man equality well first we're talking about the promise of million of your money via the issue is that there will be someone who that don't follow the promise or if something is bad practice in the past it may not be best practice in the future so what I'm saying here is that instead of doing all the social promising maybe you can just use some social engineering techniques to fix those issues so the fix is quite simple we just remove all those observed behavior that we don't want smart contracts to absorb so the biggest offender is recently gas cost so we actually I mean a lot of core developers has expired that smart comfort food make any assumptions about gas costs because cash cows can change a lot and so we just remove any observe observe behavior within the um about gas cost in detail is basically removing the gas of code and for calc alcohol delegate car we just take it take the fuel gas and if any cost act is out of gas and we just reverse all of the cows tax the third item is because we don't want to accidentally reveal the current gas information for an apparent contract if a child contracts succeed or fails so we also deny any use of codes to beatified so this is basically the idea idea extremely simple validation process between contract deployment so in this case we have made future upgrades that added additional of course much more safer so there are extra goodies for example we have a hash feature probe which makes some contract can be pretty fly dong Chan that can later take advantage of new feature upgrades so using a conversion inadvertently samia may actually have a pretty robust backward-compatible solutions for you serum so using this we now can freely change guys post because it's now an observable behavior and no contract can depend on it introversion listeria question we can also really add view of course because now it is throughout the deployment of a news of course so the coverage will not be an issue anymore and for since like statement I'd still really encounters from the state but for all the rest of the parts the state execution they can be back work avoidable it's not at the operate we will not be like totally hassle-free there are something we need to care about for example we need to change this already compeller a little bit so that we can use because so reading compeller actually make some assumptions about guys post and we need to make the compeller not make that those assumptions anymore the second issue is emergency hard work which I guess probably nobody can do anything about it if there is really a denial service attack I assumed and micro Calgary has to be broken because those attack contracts cannot exist on chat and the system is something actuaries you have boundaries so in this section we're basically talking about what a bridge will break and what will never break has never been really be communicated clearly so the thing is no matter how we come into it the loo is quite complex currently like we need to make assumption make some or something don't pick make other assumptions and the distinct between them is not yet obvious and many smart comfort developers and even called Cod rappers misunderstood them so this section is basically an actual propose that we may want to have a really clear thought redesign for backward ecology about what we can change the VM and what we cannot change so all the counter developer knows that for each contracts we have coped we had the relative stores and also each contract can oxidize extra contracts and three compounds so this is a clear distinction so what we can do is we just say that the cold and the crypt corresponding slot will never change but we are now change of anything that is in the in the state like external contracts or external three compounds so this basically gives us a boundary and what we need to do right now is basically build on top of the version a civilian and moves or some code that we might want to change in the future into a big compel for so for example this basically is balance those theta kind of sets of codes and some of course that requires both information so we just provide a free cocktail to outside source information so we can have a better design to communicate or backward heavily model and in that case seems like statement or the migration from ETH 100 to 200 can be much more clearly communicated and it would cause more much less surprise for contract developers so in this Hawk this is conclusion so basically we are talking about nearly complete complete fix for our current pack workability model that consists of a conversion which allows smart contracts not to be affected by new versions and we also have the version list EVM design which enables for work apology I believe those two combined can provide a really good and robust package of this model for us Curley and there's also a proposal that we in the future we might want to do some additional change to also design the UVM for better programming and model communication so we define a really clear model about what we can change and what we definitely won't change so it becomes harder to misuse those things and that's all if you have any questions feel free to ask me after the talk so thank you