Cheatcalls EIP - My (dev)node is my castle - krzkaczor

uh hi uh I'm Chris Cater and today I want to talk about ethereum development nodes and a ethereum Improvement proposal that we've been working on so first few sentences about me so I guess one could say that my hobby is working on dev tools so uh some time ago I created pretty popular tool called type chain which uh provides provided because now there are better to but it provided years ago like a reasonable typ safe interface for typescript developers interacting with it smart contracts I also created Dev node which uh sorry Dev code which allows to uh browse uh deployed smart contracts in Visual Studio code uh directly from ether scam uh I co-funded uh l2b so I I worked on layer twos and now I'm back in Def EOS stem working on uh spark Dow which is part of Sky uh which was previously known as maker do uh so I'm working at Phoenix apps uh and yes before we talk about ethereum nodes development node uh development nodes I wanted to talk about ethereum main net nodes so what happens when you know there's a new uh block on uh mainnet so what happen s is that there's a ton of different uh checks basically the consensus rules the etherum note makes sure that makes sure sure that the new block follows the consensus uh rules so for example in the block there's a list of transactions so we make sure that all the signatures uh are signed properly by the sender um then the transactions are getting re-executed and the the state in the block is asserted against the state that you know was the outcome of the of the execution uh you know there there's like lots of different checks for balance like did someone send the the the the if that actually existed right uh then there are like Pro of work pro of stake uh checks and turns out that when we develop smart contracts we don't care about any of that uh like when we develop smart contracts it's very important to be able to put the State the system that we uh test in a certain state so that's why sometimes we need to uh you know mean tokens out of tin a like obviously this wouldn't be possible on uh eum mainnet node but this is very useful when you develop and test your smart contracts so uh for example in Foundry we have this notion of cheat codes which allow us to basically violate the consensus rules of the virtual machine so for example we can warp at the time which means moving the the block time stamp that we're currently operating on so this this is useful when our smart contracts has some kind of you know uh locking mechanism that know something happens only after a certain uh date right so we can do that we can deal tokens which means like mean tokens out of ther it it applies both to ec2s and like native token balance balance like if uh then finally we can prank uh accounts so this means that we impersonate an account which we don't know private key off so this is extremely useful for things like for example you have an Oracle and you want to push new price you just impersonate some kind of relayer and you interact with the Oracle contract as you are its owner so you know we do things like this in test environments and every single test environment uh that allows to to you know right test for smart contracts has some similar notion of cheat codes uh now finally let's talk about development node so by development node I mean a simplified version of etherum node which is not like you know fully capable of uh mining or uh you know following even some some of the more uh like uh like fully verifying even the the the the main uh blocks but it's more suited for development needs so uh you know obviously it has the same virtual machine but some some of the uh you know uh Corners were cut let's put it like this so I'm talking here about things like Anvil part of The Foundry or hard Hut network uh so these are the the most popular like local uh notes there were there was also ganash or OG's out there like this this is this was kind of like uh older uh older node out there uh so these are local development nodes the ones that we run on on our machine um but there are also similar tools run in the cloud so things like tender or build bear they basically do the same thing but they get you like a sharable RPC link that you can send to your co co co-workers or and and basically you know they see the same state so this these are like pretty useful tools and basically um what are the the the the exact use cases so first of all all of these tools allow us to Fork main net so instead of like starting with a clean you know empty uh state of this development node we start from Main it from a certain block and we just keep on adding our own blocks on top of that chain so this is awesome because we have access to every single contract that was deployed on mainnet and you just keep on you know building on top of that um so in uh spark we use uh quite heavily different development nodes so for example where we test uh when we test governance spells so governance spells are basically uh a governance spell is a smart contract that uh is being voted on by some you know decentralized autonomous organization governance system that after it's like voted on the smart contract can change uh basically like this this decentralized protocol so it introduces some changes to the to the def prot for example so um we write these uh governance spells and we have this bot in the repository of the uh with the governance spells that executes every single spell in like a this in in in tenderly basically in like you know sandbox and then it gives us link to front end with you know changes from the spell applied so this allows to you know see how this spell is going to impact like our you know the the the the the the user view of the protocol so this is kind of useful and allows us to catch like quickly some you know problems with the UI and basically like you know visually inspect the state of the protocol after we execute some uh governance spell uh the other thing is that we have a ton of uh tests so both like end to end tests for the front end but also some integration tests for backend systems they use standardly to um or could use something like Anvil but basically uh you know they uh like these development nodes allow us to test the integration between smart contracts and some other components of the Brer system uh and we also have uh you know bunch of this ENT test using tender so development nodes similarly to testing environments they are pretty adjustable like there are these special Json RPC calls that allow us to do similar things that with cheat codes in in fundry so things like we can use hard cutor set balance to change etherum balance of a certain account in hard Hut no or there like you know unv specific cheat codes uh so uh the problem here is the lack of standardization of G of this special Json RPC code so um some of these methods only exist in one of these uh development noes so for example there's this extremely useful thing called set ear C20 token balance which I again mentioned I mentioned that it even exists in in in Foundry but it doesn't exist in an so if if you want to quickly set like mean erc20 tokens out of tinr which is by the way not trivial problem we're going to talk about it in a second like you cannot do it easily on any anything other than tenderly and buber so this is like very painful um then again if we use tenderly then on the other hand evm set next block time stamp doesn't work as it should so we're going to dive into in a second what this uh method exactly does but basically the behavior between different development nodes differ uh it's not standardized furthermore like you know these methods have different prefixes some of them don't exist in different nodes uh so this all of this results in Vendor locking if you start using one development node basically you cannot switch to other development node uh because you're already using some you know specific features of a given uh software and on top of that documentation just doesn't exist like it's funny because like years ago ganach figured out some of these cheat codes they implemented them like this not cheat codes but rather like special Json RPC methods we're going to have a better name for that in a second H and you know they introduced them they didn't elaborate uh and people just use them uh up to this day and no one still wrote any documentation about exactly what happens because like some of the behaviors like edge cases are totally not trivial so the solution is cheit etherum Improvement proposal proposal and of course there's obligatory XKCD on this case uh luckily we don't have 14 competing standards there is basically zero standards around that so maybe we're going to be more lucky with introducing this change but basically the idea is to normalize is this uh this this interface for for quote unquote special Json RPC uh methods and we simply call them cheat calls because they are like cheat codes but you call them you call the the method in uh for for for the noes so basically you know as I described it follows this Mantra of my development node is my castle like you should be able to do whatever you want in your on your own like you know development node should be able to put it into certain state to test certain uh certain uh scenarios and you know uh the the software should should help you with that uh we use standardized cheat uh prefix um and basically on the right you can see bunch of uh example uh cheat calls we're going to get to them in a second but what's pretty cool is that we want to have a uh not only like you know written spec but also tests for that spec so we can really you know have like automated test if is this uh node like you know conforming to the spec um and this is all like pretty working progress this is the first time I talk about it publicly uh so you know things can change uh but we're going to talk about it at the very end so let's go through some of this cheat call so for example time management I already mentioned that you know so like speaking we don't reinvent the wheel here we just rather standardize things that exist in one one one way or another so for example here cheat increase time it's like evm increase time but it's like properly documented at to test and then we had this another thing cheat set next block timestamp so here the idea is that you call this and it doesn't mind new block but when you send a some kind of transaction that makes a development node to uh to my new block then this block is going to have the time stamp that you wanted it to have so this is very important when you do some deterministic tests and and basically like you know it allows you to write very deterministic test and the problem here is that you know developers of different development node uh nodes without any docks they needed to figure out what this should do and get guess what they don't agree exactly on the details on what it should do so for example on Anvil uh it more or less does I mean it does what what it's described here but for example 10er it does things slightly in a different way and in and in some other um uh development Noe it doesn't exist at all I I'm talking about evm set next block times right so here we try to standardize that um oh and also by the way you can call this the same uh cheat with null and then you unset this value which is sometimes useful um then we have bunch of cheats to have a proper mining control so um you can call cheat mining mode to set a mining mode so for example you can use Auto the mining mode which is default which means basically with every single transaction you mind a new block uh this is this is the default behavior for something like Anvil then we have manual mode uh which means that you need to explicitly call cheat mine to to M new blog um and there's like ordering of the transaction in the mol so basically a node maintains a mol and you can specify if the mol should work like first in first out or are there transactions by fee so this is this is what you know main net nodes usually do um and then finally it's like interval mining so kind of similar to to mainnet where you specify some interval and and ordering so all of these are extremely important and useful when you want to test some weird scenarios where you stand transaction but there's a network partition happening and the transaction never gets to actual Meo and you know gets dropped so we can use cheat drop transaction to drop transaction from Theo before you mine a new block so you can you know test all of these we behaviors and see how your you know back end system or front end system behaves uh then we have snapshots so this is more or less the same as uh as already exist in in in development no so we have cheat snapshot which creates a internally a like a dump of the whole state of the of the node and gives you anide D representing that that dump and then you can revert to that snapshot so this is very useful when you do some costly time consuming initialization of uh of some smart contract system like you know deploy a bunch of smart contracts uh send some transactions to set some you know admin rights or whatever um and then we get to chitos about imperson impersonation so basically it allows you to act as a address that you don't know private key of and here we're like debating like should we support uh impersonating a single account which is the case for for many development nodes now or is just easier to impersonate all accounts like from my experience impersonating all is just much more useful because you don't need to worry about like you know impersonating every single account that we want to uh impersonate uh so yeah this is like open question should we read this like uh singular in impersonification um and you might be wondering how does it work under the hood uh you know when node knows if it should impersonate an address or shouldn't so basically the the uh the client side code uh executes different Json RPC methods when you send transaction with a private key or don't so this is something that you need to configure is something like VM like for example when you don't know the private key uh you need to configure it slightly different and then it sends uh I think it's called if uh send transaction call which sends like you know information about the transaction in like a Json form like an object with few Fields but on the other hand if you have a private key what happens under the hood that the client Side Library is going to sign the transaction setion and it's going to and it's going to send like ass signed uh blob uh using a different uh RPC method I think it's called if uh send sign transaction or something like this so basically this is how node knows if you wanted to impersonate an address or not um and then uh with treat calls you you should be able to um do introspection on the state of the node so like we have this uh meta uh cheat call called cheat info which returns basically the state of the other cheat codes like you know are you in personating go accounts or are you did you did you set the next block time stamp all of that uh but also what's interesting it it returns like a version of the spec that node follows so so this might be useful to realize you know what's available what's not but also it returns bite code verification info so here like if you're if you were ever you know verifying uh smart contracts on test Nets or on mayet like you know that it's like pain in the out and one of the reasons that it's more difficult than it should be is that you don't know which URL you should actually send the you know request to verify your pite code so here we could return that c return that information directly through the uh for the Json RPC uh interface to make this process automatic so uh yeah this is like you know DX Improvement then finally we getting to the more powerful cheat calls like setting balance and uh storage management so uh you like setting the balance of etherum uh accounts it's like pretty straightforward you just provide address and and balance that you want to set but also we want to support set erc20 token balance so meaning uh tokens of uh meaning basically arbitrary erc20 uh tokens which we're going to talk about in a second so this is like best effort implementation because you cannot guarantee this in in any case because we don't know the exact implementation of the erc20 token it's just like know interface standardized uh but with the other code with with the other uh cheat code called set storage at we can basically manipulate any storage slot uh that node has and now let's go on the tangent and talk a little bit about how we can actually implement this set here C20 token uh balance so um like you know just the reminder like this is a standard so you know we don't say exactly how it should be implemented we just specifi the behavior but this is I think the best way to implement it so the problem is that we want to tweak basically an arbitrary story slot um but we don't know which slot holds a balance uh of a particular user in a particular ec20 token so you know evm storage uh is just like a huge map of U in 256 to U in 256 basically any any you know um like a slot in this map can be set and uh so how does it work under the hood if we have a uh if you have a solidity contract basically solidity follows this rule that it every single property in the in your smart contract has an index so for example here oh here no does it work no okay I'm not going to try to use the pointer here but basically at the bottom of the screen you see a total Supply which is a first property in this contract so it has index zero for simple types like you know uin or you know basic scalar types this um index is a storage slot index that compiler is going to you know uh write and read from so basically if you would read the storage slot of a zero index we would get a a total Supply in like a raw uh un uh unparsed form but then it gets more changing with mappings so mappings like all of these properties have like you know increasing indexes so the index of balance of is like one uh but of course we wouldn't be able to put all balances of all the users into one slot u u 256 slot so what happens under the hood is that compiler takes an index of this uh variable and it takes Keys um in the mappings and hashes them together and this is the storage SL location so it's like seemingly random slot in the in the whole uh storage layout um so now we need to figure out how to guess this slot and keep in mind that balance off here is just a simple uh getter right but it could be like a function that does bunch of checks reading from storage locations different slots it could also read a balance of of some different uh token and for example multiply it by some you know constant or variable whatever like it can have you know arbit logic so how to deal with that so the idea would be to trace this balance of read tracing means basically like inspecting the the state of the virtual machine for every single op code so here we could find op codes that read from Storage uh um from from etherum sto storage so these are like s s loads uh we could find like a list of them and basically iterate through them and we would see that okay this SL Lo accesses some uh you know storage slot and we put there a random value and we redo the whole thing we recall balance off and if that random call if that random value gets returned and with this approach we could uh we could actually find the storage s that should be balanced if it exist because it could happen that it doesn't exist because it's multiplied by some some constant so this is like best effort uh implementation but in practice this is what Forge actually does under the hood when you do deal with erc20 token uh so this is actually very interesting that this algorithm can be expressed in solidity using uh using some uh cheat codes in Foundry to access uh list of uh you know hot storage locations so this was a tangent but but basically this is how you can uh Implement under the put some of these cheat cods and what's the what's the status of this whole thing so uh this is very early on like we're talking with hardcut uh uh thems and and build bir teams and I'm also reaching out to F and tender so we can you know agree on the shape of the standard and hopefully you know make it uh make it work uh you're all invited to get involved uh there's going to be some know R work because turns out that now every single development Noe open source development note is written in Rust um and uh and you know I'm thinking that this is kind of challenging problem because it's like you know coordination of different teams that don't necessarily want to talk with each other so I'm not sure if you're going to succeed with that but the worst case scenario is that we're going to implement the missing uh cheat codes in uh that are that are present in like close Source software but are missing in open source software like set2 second balance and you know worst case it's going to be still unstandardized but at least it's going to be less unstandardized which is now uh which is now which I consider a win uh so that's it the the EIP is open source it's like you know draft it's not submitted to the fors yet but you can find it on GitHub or just SC this QR code to to get it you can reach to me on Twitter reach out to me on Twitter it's car cure uh and that's it thank you Chris will be around if you have any further questions CU we're going to dive