 A short introduction about me. So I'm Weta. I'm a co-developer at Party Technologies. And I work on Ethereum and Ethereum 2.0. So in this talk, I'm going to talk about backward compatibility. So in different contexts, we have different definitions for backward compatibility. For example, in the context of system interface, it's mostly about inter-off-waste and 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 compatibility in a blockchain context. So we are really talking about smart contracts. And the definition here I give is if a smart contract works in the past, then it should continue to work in the future, no matter how many future upgrades we add. So the thing we talk about here today is that it's not so nice story about backward compatibility in Ethereum. So backward compatibility can be really easy to be broken for a lot of times, unintentionally or intentionally, as we demonstrated on Ethereum. So this is a huge issue because real-on-chain contracts are affected and also a lot of real money are involved. For unintentional backward compatibility breakage, we have the example of EIP1283, which is a change to decrease guest cost. But unfortunately, we find that if we do that, then there are some issues with backwardability because it can cause some contracts to have real entry attacks. And we also have 8084 in Istanbul, which is EIP to increase guest cost. We also figure out this can break backward compatibility because it can just cause some functions of some contract to be frozen. So those unintentional backward compatibility breakage are nearly missed in the whole EIP auditing process. We nearly found it for the last minutes. And it caused a lot of issues. So in the past, we also had debate about whether increasing guest cost or decreasing guest cost will be better. And it turns out both scenarios can break backward compatibility. So it's the same by scene. And in the future, we may also have intentional backward compatibility breakage. So for example, if now we know that guest cost break everything, so in the future, we might just go ahead with some guest cost changes if that's really pricing on. We want to reflect the real computation cost. And also the example for state rent, which is a, and I don't know whether we want to adopt it now, but we probably want to have some similar proposals to fix state loads, which can also break backward compatibility. And we also have the ETH 1.x to ETH 2.0 chart. In that case, some contracts can be broken as well. So this comes to a conversion. It's really about that we currently don't have really guard for backward compatibility that is so easy to be broken. So we probably want to do some similar things. So in this section, I'm going to talk about three different versions of account versioning from code prefix to special contracts to ROP fields. Just give you an idea about how this involves and the thing we finally settled on. So the earliest is probably the code prefix, which was in ETH 1.5.4 in 2016. So it's got in the context, so I didn't give us some support in theorem. So the idea is quite simple. We just add a small code prefix in every contract. And if the contract detects that prefix, then we just execute using that version. It's sort of the default version. So this is later expanded into EIT 70.07. So we did have some issues. So with code prefix alone, the issue is that we can deploy data on-chain currently. So some data might just accidentally have the prefix than what is the code on-chain. So this is a huge issue for VN that requires validation. So it's just really nice. And we can do something about this. So there's a way that we can just dissolve and use our code deployment so that we don't have those data on-chain that accidentally have the prefix. But the issue is that it's not backwardable. So the second variations we had was using a cloud training for special contracts. So this was EIT 81 in 2019. So basically, the idea is quite simple. We just start the version information of an account in a special contract that is starting a loan location. And then whenever we execute a contract, we just fetch the version from that special contract first and then decide which VM we use. So this is quite simple. It does not require any central state. The issue, however, is that we need an additional trade operation, which is kind of bad. Because each trade operation for all the accounts means we double the trade access. And even the current trade access is not really fast. So that's an issue. And finally, we have the account version in the RLP field. So this was originally the EIT 10.14 in 2017. The idea is quite simple. Also quite simple. So we have four RLP encoding, currently, non-spilance, star root, code hash. We just add another one version. And we use that to determine the VM we use. So later, this is expanded into 70.02. And this is actually quite robust and entirely backward compatible. So there's also strongly favored by the 6.15 team during the Istanbul discussion. We had less coaching than expected. So now, guest and party and, I believe, another ARTH all have a PR open for this conversion implementation. It's also slightly good for the star root proposal because now you can use this version field to determine what the rise of the ARTH you feel that star root might act means. So it provides some semantics for them. And it's the current selected account versioning solution. So for completeness, there's also one thing we need to talk about. It's about if using this version, what is the version, the child contracts that created by parent contracts. So in EIP 70.02, this is what called a contract family. And later, this contract family can be extended. So we can have some extensions to EIP 70.02 that allows different conversions to be created. But this is for completeness. So we can release this if you want. And then we have the version list, EVM. So what we are talking about here is really if we only have a conversion, the issue is every six months, we will want to deploy a new version. That for some teams, it's not sustainable. So that is a huge pushback during the Istanbul ARTH for discussion. Some people just think a conversion is good. But if we need to maintain too many conversions, then that is a huge maintenance cost. And they may not want to do that. So version list, EVM is fixed to try to address that. So what we do is we design things with forward capability in mind. And we remove some offenders that reach by property in the EVM. So in the end, we just have one new version. So the current EVM version will be the legacy version. And we just have one more version, which is a version list, EVM. And we can add new features, change gas goals on that new version. So talking about general things about interface design, there's something really important is cultural slow. It basically says that if you have a sufficient number of users, then it really doesn't matter what you promise in the API. All the observable behaviors in your system will be used by someone. So for Ethereum, it definitely has sufficient number of users. So here in slow definitely applies to us. And I mean, during the back for company discussion, many people, many quality developers were talking about the promise of Ethereum on EVM. The issue is that there will be someone that don't follow the promise. Or if something is 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 observable behaviors that we don't want smart contracts to absorb. So the biggest offender is basically gas costs. So we actually, I mean, a lot of core developers has expressed that smart contracts shouldn't make any assumptions about gas costs because gas costs can change a lot. And so we just remove any observable behavior within the EVM about gas costs. In detail, it's basically removing the gas outcodes. And for call code, delegate call, we just take the full gas. And if any call stack is out of gas, then we just reverse all of the call stacks. The third item is because we don't want to accidentally reveal the current gas life information for unapparent contracts if a child contract succeeds or fails. So we also deny any IEOS outcodes to be deployed. So this is basically adding an extremely simple validation process during contract deployment. So in this case, we can make future upgrades that add additional outcodes much more safer. So there are extra goodies. For example, we can have a high-feature probe, which makes some contract can be pre-deployed on Chan that can later take advantage of new feature upgrades. So using a conversion in an versionally CVM, we actually have a pretty robust, backward, compatible solutions for ethereal. So using this, we now can freely change gas cost because it's now an observable behavior and no contracts can depend on it. In the versionless CVM version. We can also freely add new outcodes because now we dissolve the deployment of IEOS outcodes. So the conflicts will not be an issue anymore. And for things like state rent, it's still removed contracts from the state. But for all the rest of the parts, the state execution, they can be backward compatible. It's not, the upgrade will not be totally hassle-free. There are some things we need to care about. For example, we need to change the solidity compiler a little bit so that we can use, because solidity compiler actually makes some assumptions about gas cost and we need to make the compiler not make 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 on Ethereum, then micro-culture really has to be broken because those attack contracts cannot exist on-chain. And the sixth thing is something actually is the event boundary. So in this section, we're basically talking about what upgrades will break and what will never break has never been really being communicated clearly. So the thing is no matter how we communicate it, the rule is quite complex currently. We need to make some assumption, not make other assumptions and the distinct between them is now that obvious. And many smart contract developers and even call developers misunderstood them. So this section is basically an actual propose that we may want to have a really clear both redesign for backward quality about what we can change in VM and what we cannot change. So all the contract developer knows that for each contract we have code, we have the related storage and also each contract can access extra contracts and pre-compiles. So this is a clear distinction. So what we can do is we just say that the code and the corresponding storage will never change but we allow change of anything that is in the state like external contracts or external pre-compiles. So this basically gives us a boundary and what we need to do right now is basically build on top of the version of CVM and then move those sub-codes that we might want to change in the future into a pre-compile. So for example, this basically is balanced those data access sub-codes and some of course that requires block information. So we just provide a pre-compile to access those information. So we can have a better design to communicate the backward quality model. And in that case, things like state branch or the migration from ETH 1.x to 2.0 can be much more clearly communicated and it would cause more much less surprise for contract developers. So in this talk, this is conclusion. So basically we are talking about nearly complete fix for our current backward capability model that consists of a conversion which allows smart contracts not to be affected by new versions and we also have the versionless CVM design which enables for our compatibility. I believe those two combined can provide a really good and robust backward quality model for us currently. And there's also a proposal that in the future we might want to do some additional change to also design the EVM for better programming and model communication. So we define a really clear EVM model about what we can change and what we definitely won't change. So it becomes harder to miss those things. And that's all. If you have any questions, feel free to ask me after the talk. So thank you.