Issues in EVM Equivalence

Transcript

[Applause] [Music] [Applause] so when I first submitted the talk I called it issues in evm equivalents but then I realized issues are forever Adventures have conclusions so all these things I'm going to talk about there are solutions to all of these various problems in evm equivalents so quick quick agenda um this looked a lot better on Google Slides I'm going to talk about what is evm equivalence then I'm going to talk about rpcs consensus data pre-compiled and then accounts and I could spend an hour talking about all the various issues but these are just

the top four issues that I'm going to talk about so the first question though is what even is evm equivalence I mean it's a big old buzzword that's going around and everybody wants it and it's very important but he try and get a standard onto what people mean when they say evm equivalence it's a lot harder to figure out and so I'm going to look at it from two perspectives one is the top- down perspective and one is the bottom up perspective and the top- down perspective I think splits into a number of different facets that you might look into the evm um if you're just using metamask all you care about is that your Wallet transaction goes through and it works um if you're writing a smart contract language all that you care is that it executes the same way on every chain and if you're running like a Mev

operation or a DEX operation you need to be able to access the evm reliably and have it do the same things in the contracts you deploy in all cases and finally there's the actual execution when you write a series of bite codes you want those bite codes to mean the same thing the same places and those are four different perspectives onto what evm equivalence means that really have four conflicting different views as to what you get out of it now most of us here in this seminar probably talking about the lower right quadrant smart contract execution but all four of these are relevant the second approach I want to talk about is coming from the bottom up and that is where do these EVMS come from and I've broken it into three different um categories of EVMS the

first one is what I call consensus derivatives these are chains that are driven off of a variation of a core client um for example they'll take gu and they'll change the way the consensus Works um and that's just a derivative of the evm the stuff that they're not concerned about the consensus things um are are going to be the same so you're going to get a lot easier experiences there the second form is the ZK evm and this is where they take the definition of the evm and they reimplement it in context of what they're going to get of what they want to execute within the evm and within their ZK proving systems so they need to re-execute everything from the beginning but they also got a lot of different problems relating to things that are easy in ZK that are hard in in

regular program and regular programming that are hard in things like C and Java and go um versus things that are easy in see in job and go that are really hard in ZK evm like doing kachak um is as as a cryptography and then there's an important third category and this I think is the more interesting one for evm equivalence and these are the independent implementations these are blockchains that didn't start out as evm equivalent but later on or maybe from the beginning they added it on and they brought it in not because they wanted to have um because they wanted to have Smart contract compatibility with the ecosystem so they've got to map things on to their system that didn't derive directly from an evm system and make it behave the the same and that's where some of the more interesting challenges

lie so to start off with how would you do evm equivalents surprisingly we need to talk about RPC RPC is the Gateway by which you approach the the ethereum virtual machine if you want to use any sort of a of an evm program or transaction you want to use all the available tooling they all go through Json RPC so if you're going to be building a system that evm equivalent you have to support the standard rpcs even though that has nothing to do with B codes it's how all the tools interact with it and the tools that do debugging the tools that help you write the code the tools that help you deploy it all go through jsonrpc now the funny thing about jsonrpc is if you have an independent implementation that has a native token system you can make it act

like it has erc20 tokens without executing a single line of evm code you can you can create that front to some people that's all they care about evm equivalents when you start doing things like deploying contracts and um do doing create two uh Dex implementations with Unis swap suddenly things get really really complex really quick so it's an iceberg the surface may be really simple but the more and more that you develop the harder and harder it gets and one of the problems as a former front-end developer all bugs are ux bugs until proven otherwise that's one of the the bad news for the people doing the rpcs is when they get something that doesn't work very quickly they need to say it's like oh no no no no this is something that the evm is executing wrong it's no longer an RPC code so when you get these

errors and they'll have bad messages they look like RPC errors when they're actually deep evm equivalence problems the next area of concern is consensus data and I'm talking about the op codes where you get data from the Block structure and you bring it into your evm experience um but first I want to talk about um to frame it something that I learned at Google and this is uh one of those software development laws that that you hate because it's 100% true and that is Ham's law um and what Ham's law states is that when you implement something the side effects are forever and I'll just you know read it because I can't phrase it any better than than ham wrote it says with a sufficient number of users of an API and

he's talking about software it does not matter what you promise in the contract and this isn't like a smart contract this is like your documentation all observable behaviors of your system will be dependent upon by somebody so even though you didn't intend for the difficulty op code to become an excellent source of pseudo random numbers if you're only relying on the low bytes even if you say don't use this because someday difficult is going away it's going to be set to zero somebody's going to use it and they're going to depend upon it for pseudo random numbers so here's a set of strategies of how people were handling um equivalents for some of these block values the values on the left here are just listing some of the easier ways um the how you

can map some of the systems there are systems that have blocks that are they don't have blocks that have sequences of transactions so there's ways you can emulate it by using your transaction position to create a hash um and also the time stamp of the number but some of the more interesting ones are on the right one example is what ethereum did with the difficulty op code they replac it with another piece of data from the consensus headers called preand Dow which solved a lot of Lottery contract problems because preand Dow is actually a better source of pseudo random numbers than difficulty was but if you really want random numbers don't use anything that's coming from the evm use an external service like an oracle that's where you can get your real reliable Randomness because anything that's in the evm can be gained a lot easier than

anything else but then there's a couple of other things that you need to worry about does your system Implement something like EIP 1559 for transaction pricing um because with future versions of the evm you have to support an OP code if you don't there sensible values you can return from base fee just say zero another thing that's going to be happening sometime next year is the Cancun upgrade UPG grade does your blockchain system support blobs maybe it does maybe it doesn't but there's new OP codes that you need to support to provide reasonable values um it's really easy with these two just say zero for blob hashes there's no blob hashes attached and zero for blob Bas fee because you're not supporting blobs um but that brings us into um another

subject they added another pre-compile in Cancun that I think is the best way for promiles going for which we dealt with uh the 47 8 precompile is they just put it out in a they defined it in evm and they brought it in and every client implementing it by hand but you could do it through evm so I want to talk about the next issue which is pre- compiles but first I want to talk about some language changes that I think we probably should adopt in the industry I think there's two kinds of pre-compiled that people generally talk about and they deserve two different names the first kind of a pre-compile is genuinely pre-compiled evm code modu low gas prices if you can express your cryptography in evm but you can do it

faster and more efficiently in native code that's a pre-compile that's when they started writing the pre- compiles that's what they intended but if you're accessing something else within your system like layer 2 messaging data like if you have a native token implementation in your system um or if you need to access special privileges for transferring money in the system that may not be exposed on evm they look like pre-compiled contracts they look like contracts but I think the phrase we should actually start using is system contracts because these are contracts that interact with the system in ways that the evm does not allow you to do and I think this is the best way for us to get at the system rather than adding op codes in fact for for more of these um block header values that are going to start coming in the evm I really think

in mainnet the next time we do this it should come through a through a pre-compiled contract because that'll make it a lot easier for evm implementers going forward to implement this through a system contract and if they don't support that particular block value they just don't expose that system contract so the standard pre-compiled contracts are kind of an interesting story if you are a um a con if you're a consensus derivative or an independent implementation implementing these is relatively easy because he just linked in a native Library the zkm however have an incredibly difficult time with a lot of these pre-compiled um maybe mod exp will be implemented but all the others will throw errors and won't allow execute them um so ZK EVMS have the hardest time with these promiles because

they just are completely opposite for what zks need to do and they're also a lot more expensive to do in zks um it creates you know just like some of these hashing algorithms are just incredibly difficult for them and so they take a variety of approaches in solving these um some of them um don't support them and another group they'll support them but they won't put the data into the ZK validity proofs um we'll see how that approach works out system contracts however I think are the future of integrating with consent census in the evm um one example that we have that's going to show up today is the 4788 uh Beacon route contract of how we're exposing all the data through a stateful pre-compile um a system

contract that has special privileges that accesses data outside the system some other common things you might do with it is accessing a native token system Layer Two messaging perhaps you have some weird things going on with your fee schedules um a P&G you might have a even better solution of pgs than pre randow um but these are going to be the best way to provide custom access to your system without breaking EV equivalents um in my opinion if you add a system contract that is not breaking evm equivalents and if you don't have a system contract that main that specifies I also wouldn't say that you break evm equivalence as opposed to say not implementing an OP code um because you know return data size is the old push zero so again Ham's law strikes there if

you expose something as an OP code people are going to use it in ways you don't want to use it you can't just get rid of it but a pre-compiled contract it's like the account's not there and everyone should be able to handle situations like that and the last thing I want to talk about for evm equivalence is accounts and this is where things get really deep really really quick um the amount semant the account semantics are subtle if you're a consensus derivative this is going to be free for you and easy if you're a ZK system it's probably going to be easy because you're not mapping on to an existing system but if you have a account abstraction if you add new features it's it's going to get harder but if you're doing an independent implementation that has its own blockchain structure with its own

account rules and you're trying to layer the evm into it it's going to get really difficult this is an awesome AI generated image I said you know give you square pegs and round holes and I think this is just the best expression of what it's like as an independent implementation trying to get the evm to treat your account just like an evm account there's just so many ways that just doesn't quite fit so um here's just kind of a la list of some of the issues that I had um account addresses are the first one some systems don't use hash assigned addresses near gives you names hia starts counting from a thousand um so if you want to Port something in like Unis swap in you're in trouble because Unis swap absolutely depends upon create two generated addresses so you need to

create a system in there that'll map your Alias these these short account numbers into the hash derivative numbers um apologies for the formatting I I don't know what happened when these slides went through the system um the next issue is noce management like it or not you have to have noces little things like the number of decimals I know mam mask says there's an API that says your blockchain can support any number of decimals but it ignores it and everything's 18 decimals so if you want quality evm equivalents you need to support 18 decimals for your native token um and then the final one ones we had all sorts of funds with in hedera is non-existent accounts in ethereum it's fine calling non-existent accounts and creating non-existent accounts out of thin air that's easy

um in in hadera and near in other systems this is really hard to deal with um and it makes things like counterfactual contracts really difficult so you need to have some sort of a solution to address that um and finally this was mentioned in another talk um delegate calls to system contracts it's a great way to bring uh uh concurrent vulnerabilities uh common vulnerability exceptions notices into your system um there have been many exploits that have have done with these if you allowed your system contracts to be delegate called so the simp answer there is refuse to execute if you notice your a delegate call in ass system contract so those are the uh the issues that I have found in trying to bring evm equipment to the systems and as you see

it's just a lot of little fine details if you have any questions you can get a hold of me on Twitter at Shemon or on warcast shaman. eth thanks [Applause]