# Hunt the Bug, Save the Chain: Uncovering Bugs in EIP Implementations | Devcon SEA

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 1:51:12
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-K0pQ7bRuJOk
- YouTube: https://www.youtube.com/watch?v=K0pQ7bRuJOk

## Description

In this workshop you can find a bug in an EIP implementation on a test network!

The Ethereum Foundation Testing Team oversees cross-client execution specification testing, which is critical to avoid consensus issues at the smart-contract execution level.

You'll implement tests for a new EIP from scratch using the ethereum/execution-spec-tests framework and execute them on a local test network with a faulty client. Anyone attending has the chance to find the issue and break the network!

Speaker(s): Mario Vega, danceratopz, Dimitry Kh, Spencer Taylor-Brown
Skill level: Intermediate
Track: Core Protocol
Keywords: Core Protocol, Security, Testing, python, pytest, specs

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] okay hi everyone um welcome to the session of today um we're going to be um breaking some chains today if possible uh thank you for coming and I hope you have a great time this is um let's try to be as like relaxed as possible this is going to be very interactive if you have questions uh please feel free to ask or stop me at any time turn on up like that hello hello oh perfect so yeah as as I was saying um let's make this um as interactive as possible if you have questions just let me know and stop me at anytime um the goal here is that um you guys are the ones that break the chain or implement the tests and run them on the live Network so for that to work we need uh to take it slow maybe and um and yeah if any questions just ask me or my my team over here u i I'll present them in a bit uh but yeah let's just get started um so yeah who we are so we are the execution spe testing team so it's comprised by Dan over there say hi Dan everyone um Spencer where Spencer all over there Dimitri and myself so we're the ones like um do implementations of the tests for the execution layer uh primarily um and we do it in and this is what is called uh the execution spec test it's a new repository we have been testing forks for the past uh year and a half or two years maybe um using this python framework and we're going to show it off today and we're going to share with you guys for you to write your own tests today um yeah as I said so we are responsible for coming up with the tests for every every Fork um uh there's like an extensive amount of test that have to be written and to do so we we um we Leverage The Power of python to do that and to make this the the chains safer before it actually Forks into an into into a new version of ethereum um we also help with tooling we also do a little bit of Hive um we do um U verification of the test we do we run the test on the clients to make sure that they are ready for the next next uh next fork and we help uh developers also run their tests and in in in well our tests in in in their to to their client um this is the main repository we're going to be using it a lot so if you can um uh access it and bookmark this this link is going to be extensively used throughout the session um so yeah what are we going to be doing today it's we're going to set up the testing repository we're going to uh add and analyze a very simple test the simplest one that you can IM imagine um we're going to run that test that you guys wrote on a live Network um we're going to implement a test for new EIP which is not tested and there not there are no tests anywhere because it's uh it hasn't been approved for or CFI how we call it um we're going to find edge cases in that dip and um hopefully if you guys find the edge cases that's that's even better and finally we're going to break the chain uh hopefully uh one of you can come up with a test that can break the chain um otherwise we're going to end up breaking it anyway yeah all right so uh this page here was prepared by Spencer it contains every link it contains every piece of information that you need so if we progress in the in the slides and you miss something please just refer to this to this link and just uh yeah you you can find all the instructions all the code everything is there um so yeah just please take your time just go into it and uh uh bookmark it um and actually I'm going to give some time in every slide so you guys have the time to uh make sure that you have everything in your laptop and everything is set up yeah also the the the slides are over there so you can you can actually see the presentation um you can pick ahead of course um but if you want to just go with the flow of the worklad that that's that's even better all right so um the presentation is designed assuming that you don't have basically anything installed um so right now what I'm going to do is present every single tool that we are going to use uh to run the tests um obviously uh there are different os's and different uh architecture that you guys should have in your laptops but if you have any trouble installing anything just uh let me or anyone in in in the team know and they should be able to help you out to install yeah just like just put your hand up if you want some help and we can come over and see how you're getting on y so yeah um the main the main tool that we're going to use today is the common line so this is very essential to run any any of the commands that we're going to use um this is assuming that uh you already know how to use or where is it located in your machine uh otherwise just uh let one of the team know how to open the common line in your in your uh in your PC um we're going to use a couple of commands um very simple ones curl git python are some of the ones um you don't have to have python installed already it's fine because we one of the steps is to install actually Python and there's an specific version that works with the repository so uh if you don't have it installed uh don't worry uh we'll get to that point eventually um yeah the tests are coded in Python but you don't have to know python you don't have to be an expert it's it's it's it's all we're going to give the examples here I'm going to explain every every single example that we that we see why why is a code like that everything is going to be explained here so you don't have to know know python the advantage of python is that it's very readable it's like easy to follow and anyone can basically just get the gist of what the code is doing that's why we chose it uh for the for the for the language of our tests um all right and we're going to use a little tool that is called UB this is basically like a a manager of versions in in in in Python it's very new and we just updated our repository to use it um so I think this is going to make it even easier for you guys to to to install everything that is needed it it should be like a simple common line and and should you should be ready to go um yeah git um the only reason that we need git is just to fetch the the the code from our repository so um right now you should most likely already have git installed in your in your PC but if not um you can check in the common line and you can check using git Das Das version um if you don't have G installed which is unlikely uh please refer to these links uh this is where you can install it um raise your hand who doesn't have G in in their computer or all right get if if if you refer to the any of those link you can just easily install it um yeah and we're going to use an IDE so this is not required um we use vs code a lot uh because we have like uh plugins and it's basically uh tailored to to use BS code the reposit I mean um and you can use whichever ID you want is not required but this make will make your life a little bit simpler um you can get it from from the from there that's the QR code um yeah it's recommended it's not mandatory um and yeah um there are some extensions that we use in our in our repository the main one that I recommend for you guys to install is the python one so if you are installing BS code uh you might want to check this one out because it really like highlights and everything and it corrects some of the code that you're writing so it's very helpful it makes things much more straightforward um yeah so there's that and yeah so yeah this is the main repository um this is what we're going to use basically for everything today it contains all of the tools to execute fill and generate tests in uh in in in in in what we do so please go ahead and just uh go up this link and just bookmark it because it's going to be used extensively um yeah another thing that we're going to use today um we have a live network uh it's a devet it's very small it's only two two notes and uh special thanks to the e panda Ops Team which is over there um thanks for helping us uh set up this this network uh the goal is to break it today this link over here it contains links to all the tools that uh are we're going to be using to explore the Shan uh it contains an Explorer it contains um um the fork visualizer if if that's the name um but yeah basically that's going that's going to be our our our goal and I will go into that link a little bit later in the talk uh to explain what what each of the tools is is doing uh but yeah please if you can please bookmark also this link is going to be also used extensively H and this link should also be in the in the docks in the in the in the doc that I shared at the start of the presentation um and yeah um I think this is the last yeah the finally um if you guys use metamask there is a possibility that you can add this uh devet to your metamask it will simplify sending transactions but it's not mandatory um basically um just install metamask if you want to if you want to send transactions on the network it's not necessary because our framework they it it also U creates transactions sends transactions makes everything for you but if you want to send other transactions to the network that's also possible here are the uh the the the characteristics of the network the name the RPC URL all of this is also in the notes that we share at the start of presentation so if you want to copy that just go into the link and just uh just you don't have to manually just type any any of that all right so yeah the theory so there's going to be a little bit of theory um just mainly to explain um what we do how we do it and go over the repository a little little bit uh just explain the parts of the repository the code and everything um but I guess I I should first ask is are there any questions so far um yeah yeah of course I think that link should be the session cor uhu yeah if someone can can please try it out and to see if it actually links to the the s that wece it's a different one okay m y great all right so yeah I'm gonna start a little bit with the theory and I'm going to go to the to the actual repository just to explain what we're doing um basically and there's there's going to be more information later Dan has a presentation today that's going to be very awesome it's going to go through all the details of the of the repository I'm just going to explain the basics and what do we do with this repository that creates the actual tests um yeah so um a couple of years ago basically we were creating tests using Jamal and this uh this is basically what we use to create the test that all the clients the different clients of ethereum consume to verify that they're they were consensus compliant um what is consensus compliant is whether you are ready or not to to be in consensus with another client if you're not you're probably going to be uh forked out of of the chain because of an issue so this uh the test that we write is just to basically make sure that all the clients if they as them they can be very with with high confidence they can be guaranteed that they're not going to Fork out out of the chain um so a couple of years ago we created this this repository uh the execution spectus is a new repository uh it uses Python and we use Python to programmatically create those tests so we're still filling um Json fixtures the Json fixtures are consumed by the clients but now what we what we have is uh basically the power of python and most most importantly the power of py test so pest is the main framework that we use to write uh basically every single test it allows us to um very programmatically create a lot of different scenarios very quickly so we have like this single for example let's let's imagine we have one test scenario and we want to create different variations of that that this is super simple with pyas and I will show you how how to do it in a little bit um so it requires um uh the the downside of the execution spec test is that we require an implementation of a client to be able to fill test and the reason why is that is because we cannot actually execute the state transition so the state transition is basically when you get a transaction you you you fit it into your evm it modifies something in the evm that is the C transition we don't have that code inside of of execution spectat but we rely on an external client to do so and Right Now the default client that we use to fil test is called Els is the execution specs uh it's the python implementation of the of the ethereum specification so this contains all of code and we use that to fill the test to to actually execute this transition um so yeah apart from that our our repository is capable of filling and verifying tests and running tests against clients or even live networks let me just open the link so you can see how is it like um so yeah so yeah from it's from the get-go we have um um this link over here this is the documentation so this is the the repository we also have a very comprehensive uh documentation that you can access here um I suggest that when you open the repository go to the documentation also and go here in the documentation and open the main the main version which is the most upto-date version of the documentation that we have uh but yeah going back to the repository um it's very simple we have two paths that are very important the first one is the source code uh basically this contains the framework itself the the the code of the framework itself this is used to fill tests um and it's it contains a lot a lot of the logic that we use for example it contains um the the one of the most important ones is that we have the definitions of of every single Fork uh that that has happened in eum and even the future Forks so if we go for example to to this file you can scroll down here and you will start looking into the into the actual Forks so the first one Frontier uh happened almost 10 years ago it this contains the definitions that we need for testing it doesn't contain the logic but contains what we need uh to to parameterize our tests um and you can scroll down all the way and you can see that everything is here we the the most recent Fork that is under development is PRACK this is the one and it contains definitions for all the I don't know pre-compile H it contains definitions for the system contract there's a lot of new system contracts in in prag those are all here because we need to know the addresses to actually test uh their their behavior um yeah basically and also we have an even more in the future Fork uh that is already defined here which is the one that we're going to be using today because it's the one that is uh running in the devet that is called Osaka it's a it's a dummy Osaka because it's not really what's going into Osaka but it's only contains one EAP um well it contains EF in here but that's that's uh that's that's not what we were going going to is today um yeah and what else is important here yeah okay so another another important part is that we Define fixtures for our code for for the test sorry this is basically where everything is defined for the output that the client will eventually consume we have different types of tests here and the definition for every single type of test is defined in this in in one of each of these files uh the main ones is the blockchain type this is uh basically just a test that contains a whole blockchain inside of it it's a it's a fixture and this is how we output it um in into into into into into a fixture that the client can consume um uh what else the BM is another important part um this is how basically how we write the code in here we don't use solidity we use uh an like sort of like an internal language which is very into the into the evm code and up codes um so be because solidity does optimizations when it tries to compile the code those optimizations hard hard the the way uh that we test so for example let's say that we're testing some a special up code and we writ or solid code and then we compile it and then it optimize out the the uput for some reason that is not helpful for us because it can lead us to to think that we are failing test but instead it was because of solidity um so what we do here is basically just we Define every single op code that we have and we use Python magic to basically create bite code itself so if you go to this file you can see all of the op codes that exist and even new ones that haven't been implemented yet um yeah you can you can take a look here um basically you can construct almost any type of uh bite code that that that can exist you can use the upcut here to to create it I'll show you in a bit how how they are used in a test um yeah any questions just out of interest is um three-hour sleep here someone called three-hour sleep so um I just wanted to say thanks to him because he added all the documentation for for the op codes he's an EPF fellow in cohort 5 yeah do you know him I don't know yeah um yeah so let's let's go and actually see some of the tests so everything um yeah from from the main from the main uh route directory you can see the tests here that's basically that's basically where every single test that has been created at least from uh from Shanghai up to now that's that's where every single test live and it's um sorted it's um sorry ordered by by directory which is the name of the fork so let's say that you want to see what we tested for for Shanghai let's just go into Shanghai and just see what is in there you can see four eips that those are all the eips that affect uh the evm behavior for Shanghai um we have only four here this uh the warm come AAS the push zero which is a new OP code um we have a limit for the init code and the withdrawal so there there are if you go inside of any of this let's go into U PIR I think is the easiest one you can see that we have some files but the main one is the test file so um if you go in here you can you can actually see the python code that generates the tests for the push zero um and it's um well this this one is not that simple but let me see yeah let me try another example M let me go to the easiest one Frontier um if you go to the the so this this is basically the easiest test that we have so if you go into Frontier up codes there's a test for the d d up code which is basically the easiest uh test that we can do is just duplicate something in the stack in the evm stack um and yeah this is how we generate it this is how a normal uh test looks like so basically we have definition for the function we have uh U this test do which is the main function that runs and generates these tests and we have a parameterization this is one of the best parts of py test it allows us to parameterize tests to do the same thing over with different up codes for example in this in this uh in this function what we do is we parameterize um every single dob code and then then we run basically the same code um I will go into more more detail of what uh what each of these lines represents in a little bit uh but just the main just to get the main idea is that this is what it looks like this is what we use and this is what almost every single test look like in the in the theorem uh test repository let me see all right so back to the presentation um yeah so I'm going to explain briefly because this is really important uh uh for anyone that that wants to write a test um so the main uh the main goal of the test is to do an action in the evm and this is this is composed of three parts um basically the first part is a setup we do something prev previous to the transaction we set up smart contracts we send we set up uh accounts with uh with ether that are going to send transactions we set up balances we set up announces um uh I I'll explain what the nons is a little bit um but basically the setup is how we set we we we lay the grounds of how our test is going to execute um the second part is the action H um basically the the the most simple action is the transaction so once you have set up your smart contracts on once you have set up your accounts something needs needs to take a a modification into the into the evm and this comes from the transaction uh ethereum is not like uh event based uh it's more like uh everything has to come in every action has to come from a transaction so this is the part that we use in the test we basically um make a transaction that is going to go potentially into the into the smart contract that we already created and it's going to exercise the action uh it's going to modify some code some some storage uh if creates more smart contracts um normally is for the simplest test that are only evm Centric these are a single transaction but it can get as complex as many blocks with many transactions each uh for today we're only going to use a single transaction uh for all the tests but if you want to see more more interesting tests we can we yeah we can go into the into the into one simple example and yeah and the last part is the verification so once you you create a smart SM contracts you send the transaction to them uh you want to see something happen in the in the in the evm and the most the most uh common thing that we check for is the storage so um and let me explain if if if not not everybody knows what the storage is basically is the permanent memory of the of the of ethereum so every contract has the storage which basically uh save information basically forever until until it touches it back to zero uh but this is what we check when when we send the transaction we check the storage we also check balances it's less common but we do that also and and we also check the code sometimes where we are testing for the deployment of a smart contract we also check the code but most importantly if you want to test something it has to go into the storage um even if it's like U something that happened in memory you have to somehow store it into storage for us to be for for it to be visible to us in in the test um um yeah yeah okay so let's let's get started um uh by the way how's everyone doing on the installs has everyone um anybody has any questions or just raise your hand yep the last thing you said how said [Music] everything so the events we don't we don't have tests for I mean we do have tests for event but there most of them if you want to write the test what what I meant is if you want to write the test you don't you wouldn't use events you have to is for let's say you test a new up code that makes uh I don't know addition or whatever you have to end up using the storage to save the output of the of the of the of the action but the events we don't we don't check them the way that they are checked is when you do the street transition you will have the the logs received you will have the the receive hash and everything so that that is implicitly tested but for us to be observable it has to go into storage basically yeah all right um yeah so let's get started um so the first thing that everyone wants to do uh should should should do is uh we're going to install this tool that is called UB it's going to allow us to very rapidly uh run uh the commands that we need um so that's that's the command that you need uh please go ahead and just run it if um if if to get to get U installed I already have this in my machine installed uh let me let me open up a common line here yeah so u u is already installed but um yeah please just go ahead and run this command um uh anywhere in your machine and you should should be able to to install UV um depending on on the the environment that you're using it's possible that you might need to run this second command but it will tell you so at at the end of running UB you can just run this command if if necessary and you will get the the um the the the environment setup correctly um so yeah I can I can just type anything and you can see that UV is already installed um in my machine oh by the way this this command should also be in the in the notes so if you want to just copy paste it just go to the to the notes um and and just copy paste it into into your common line uh if anyone has any issues just uh let us know all right the next thing next thing that we're going to do is that we need to fetch the repository um we're going to use the execution spec test as I said so this is the command to get it copied to your machine um run it anywhere where you where you want to download the the repository basically what it will do is just uh copy from GitHub it will it will copy entire repository into your local machine so you can start executing stuff um yeah and then the second one is just move to the execution spec test just to start running stuff in inside of there so I already got this here um so this is what it looks like once you have the um once you have the run the the the GitHub clone command clone yeah um this is what you should end up uh seeing in your machine after it's executed um it's it might take a while because the Wi-Fi it's not perfect here but yeah just try it out if anyone has any issues uh with this command just let let me know all right all right so next thing is these three commands um so the first one is just to set up um in case you don't have python this is the one that sets up uh python for you so if you run this um it will automatically download the correct version of python it will automatically set up everything and it should be U um it should be set up for you automatically um so just try that out let me just try to run it yeah there you go it seems like it does nothing but what you can do yeah people came in late so maybe just go back to perfect expenses yeah yeah yeah let me let me just rewind a little bit uh so the for the people that just came in this is the main link that you will be looking at um just to explain it again um this is a hackmd that contains every single link every single command everything that you need is going to be in there so so if you get uh you miss something in the presentation just go to here you can see it uh and also there's going to be a link to the presentation itself so if you miss anything just go in there and and just uh use that link I'm going to give it uh a couple uh time to just wait for everyone um if you stick around and hunt the bug then uh you can collect a PO app and if you're the lucky participant that breaks the chain there'll be a special pup for you too awesome so yeah let's go back to the to the current slide um yeah so yeah after you run the First Command um let's let's let's I I just run it so right after that you should be able to do something like U run Python and just the version uh basically just everything so basically everything that we run inside of the repository is going to be run using uh UV so the main this is basically what what you have to remember to run anything a repository U run is the prefix to everything basically and what I'm doing here right now is just I already created the environment and I said I need python 3.12 which is the version that is compatible with our framework I just want to make sure that that is what what we we're going to see so let's see if that work so yeah it's going to automatically do a lot of stuff for you and then then you can see that uh it worked uh it's very very nice to work with the because it sets everything up for you um you don't have to install anything not even python so as you can see UV run automatically um runs in the correct environment for you to to be able to work rapidly [Music] um yeah so yeah the next step is basically performing the initial sync what sync means is that UB has a lock file which basically every requirement that we need for a framework uh it's located inside of this file and UB sync what it does is basically okay just go ahead and download everything I need in the framework so let's just do that it's probably going to do nothing here because I already did it oh yeah it's going to don't lot a lot of stuff um it's basically just to prepare for us to run any command in the repository um so just going to take a while perfect so basically we are we are ready we're ready for to fill any test um um there's nothing there's basically nothing else that you need to do it's it's that simple and we we are going to verify that we actually can run um uh the tests so this is the main command this is one of the main commands we're going to use two commands today so the the first one is the fill command so filling the tests is one of the first steps where we deliver the tests to uh sorry one of the first steps to deliver the test to the client and what we're going to do right now is just make a collection this means inside of py test is basically just go inside of the test repository and just look for any test that you can find and if we just go ahead and do that let's see what happens it's going to collect everything sing okay it's going to install Sal C because um there are some test that use salc so it's going to automatically install and then it's going to collect and as you can see it's collecting every single test so we got around 18,800 tests in our repository and what you're seeing here is everything it's basically every single test for Every Fork that we have uh you can be a little bit more selective let's run only tests for the fork of uh Cancun and it's going to go down a little bit in the number number of tests but basically yeah um the nice thing about py test is that so when you write a test for example let's say that I wrote a test for Shanghai it's going to automatically update it for Cancun which is the next Fork so you're not only creating test for now you're creating test for the future also so it's a pretty cool feature that's automatically done for us because of byest and how we have configured the framework um so yeah it's working so let me know if if anyone had any trouble running it um yeah let's go ahead all right yeah the second step is just basically opening uh Visual Studio code so let me just do that um I already have the visual studio code open here um but if you want to open it just go code and Dot which means open the current folder in in Visual Studio code otherwise you can just go to visual studio code and just open folder and that's the same thing basically yeah how's um how's everyone doing do we need to take a moment just to get everyone up to speed like make sure they're all at the same level is anyone having problem cloning the repo or running UV for example does everyone managed to do that okay perhaps we just take a moment and get everyone up to speed yep I was wondering it took me a while thought I mean long all right hey um to the new new people arriving um we're basically setting up um I'm just going to go back to the to the first slide to um um if you want to rewind through the through the slides or see what we have already done please just go to the QR in there it contain all all of the information that you will need um we're just waiting on setups all right I think I think we can we can carry on um yeah so let's uh let's continue by um we're going to write the simple test that we can imagine um this is basically going to be the simplest example and I'm going to explain every little bit um so this is this QR code is a gist you can go inside and just uh copy basically copy paste the uh the code and you can paste it in under test Cancun that's going to be the folder where you want it it to be so let's let's open up the the gist basically just go inside um copy everything and we're going to create it under test Cancun and just just put it there um going to call it test simplest simplest thatp and just paste it here all right all right so I'm going to I'm going to go over the the all of the parts of the tests so if you want to just uh pause what you're doing and I'm going to just try to explain everything that is happening in this file all right so yeah every single test basically looks like this um we rely a lot on the on the framework that we have so that's what is uh basically the mo most of the Imports if you have used python before just an import is basically just a library that you have to import and most of the the important stuff it's happening here um then this line over here uh basically we can write tests for any of the forks um but some of the tests which are the newer tests they only can run in one of in the newer Forks so in this case we're going to write a test for Cancun this is the the test um this is what basically is telling P test to only fail this test for the for the for the canum fork and this is um yeah this method definition over here yeah yeah this is basically almost everything that you need so to define a test in Python the only thing that you need is create a new file which in this case we already did it's called test simplest and then inside of that that file we're going to create a method the method is basically a test um in this case it's going to do a couple of things um the first the first part is the parameters so what we need here is we're going to create a state test the state test is basically just a test with a single transaction to one or more contracts and that's it we have another variation that is called blockchain test which uh performs uh test over an an iteration of many blocks with many transactions but this is the simplest form that we use just one transaction one the setup transaction output and that's it um yeah and we also going to uh use uh this perameter is called the pre is basically the pre-state we're we're going to use that object to set up everything that we need for our test in this case we're only going to set up two things and these are uh what we seeing here this is this is the first thing that we need in basically every single test we need a smart contract so this is what's happening here in this line we are telling the pre the preate to deploy a contract for us uh and in this case you can see here this is not solidity this is uh this is something that we we created for the for the for the evm um testing um basically we're going to use two up codes here uh this is one of the most important up codes that you that you really need to know when you're writing an AVM test basically is the store save to storage because this is what we are going to observe in the output when we are verifying the tests so basically what this test does is just um please put a one in in the store Key number zero and that's it that's what this uh smart contract is doing and then stop stop execution that's everything so what's going to happen when we when this line of code runs is going to deploy a contract with only this in in the bite code and that's it um we're going to see a little bit later how the execution happens we're going to execute this in a live Network and we're going to try to match this to what we see in the blockchain U that's going to be pretty cool uh okay next the other part that we need is some EO EA stands for externally owned account it's basically just a wallet um and we need this because we're going to send a transaction so the transaction needs funds and this is what exactly what we're doing here just create a center for me with some funds in it and this is going to this is what what's going to send the main transaction um yeah so the transaction looks like this very simple uh so the destination of the transaction is the contract address which we just created here here so basically when we deploy the contract we get the address to it over here and that's is what we use to to to craft our transaction so we send the transaction to that address to exercise this code here all right and then also the second line is here is the sender so who is going to send the transaction this the account that we just funded over here so we just use that reuse that over here and two two more things is basically just uh how much gas it the transaction going to pay for for the execution um in ethereum we use the gas which is the minimal for a transaction is 21,000 but in this case we're ramping up a little bit because we're going to use the storage and that's expensive so we're going to give it 100,000 and basically any value that you want to use here is fine and the last thing that the transaction contains is the value we're sending one way it's not one e it's one way is one to the um Min one one power ofus 18 if sent with the transaction and yeah and the last part is going to is going to be the postate this is the verification part that we were talking about earlier today um we're going to verify that something happened in the blockchain and this is basically um check please this address to be this account and the account should have a balance of one which is the value that we're sending and it has to have a storage of one in the in the in the zero key and that's it that's everything that we're going to do to check um yeah and the last line is basically just this part over here is um the state test is please execute this this test with this pre pre-allocation this transaction and this post this that's it um so yeah let's try to fill that test um it's very easy so let let me show you the command to do it so yeah let's just let's just OB UV run Fork Cancun test there you go um so yeah this is going to f the test so as you can see just U Run field for fork ganun and just name of the of the file I just created so let's let's get that and see what happens um there you go that's it the the the test is filled at this point um what does that mean it doesn't mean that it's executed in a client it just means that it was it is now prepared um to be executed on a client so let me let me just redo that and just yeah yeah so now if you see the the the files in the in the in the folder that you have here you should see now this um this fixtures uh folder and basically this contains the test that we just created let's go into state test and then you can see that under Cancun and simplest which is basically what we created we can see this Json file file this Json file is the output that will be consumed by by the clients for them to to check their their their compliance to the consensus um it contains very simple stuff so you can see uh the environment is basically how the blockchain looks like at the moment of the transaction is executed it contains the pre-state here is the U the contract that we created so this contract over here um this one it's going to be depl deployed to this this address and it's going to have uh this code so if you see here you can see the push push one is over here right here the push zero is over here and and and that is the the the the first argument to the a store then the 55 that's the SS store over here and finally you have the stop which is a z0 and that's it so our the client when it's is uh this fixture it should know that the the storage at the start of the the execution of the test it should have this this uh this storage at that address the second the second um the second account that is created also is the center of the transaction so that's that is this one over here so the the pref fund EA and it's going to be pref funded with this amount of e um uh sorry this amount of uh way um yeah yeah that there's not not not that much to it um second um we have the transaction this is the description that we just created here so we have this this transaction over here and we have um the SEC the secret key to the sender which was generated by by this line so this line not only creates a an account in the state it also gives us this the private key which is going to be used to to send the transaction to sign the actual transaction and that's that's what we can see here um you have the address of the of the sender you have how much eth is going to be sent the data of the transaction the destination of the transaction the gas limit gas price and all that all that stuff um and finally what we're going to see here is um the post State this this post state it means that um the state route of the of the state of the blockchain it has to match this otherwise you are you're failing the test um this is a little bit harder to explain because um the the way that the storage is uh stored in the theorum is that you have this this tree this big tree that basically just end UPS being one hash um but we can see that a little bit clearer in the other we are generating multiple kinds of test also so the one that we are seeing here is the state test but we also generate blockchain test automatically which is basically we have like this entire blockchain in a uh we have the Genesis um it it it's basically the Genesis is the first block of the blockchain um but we also have the preate and everything uh and you can see here more clearly what we expect in the poit of this of this picture um this is not going to be super important but anyway I I wanted to take a look into how it looks um because this is what we end up giving to the clients um but yeah basically you can see that the the the the end state of what we expect to see you can see that the the contract the 1,000 contract it has to have a one in this in the in the in the zero key otherwise the test will not will not pass um so yeah I think I think that's that's it for uh fixture filling I want to jump into um oh yeah so you can see the command here that I just use in case you missed it um but think yep go for it sorry what's your question why why three different why are there three different uh test fixtures for this one single python test so um essentially we have different uh test formats that test on like a different granularity so we Define the test as a state test which is like a lower granularity than a blockchain test and but from a state test we have a benefit that we can wrap any trans like so state test is a testing on the transaction level so a single state change or I mean you can have multiple transactions but typically they're just one but the advantage is if you have a transaction you can always wrap it in a block in the environment From the Block and so we always generate a blockchain test from that state test uh so you get a blockchain test for free and that's valuable because um then we can run the tests in different environments where we can only apply blockchain uh like we can only pass blocks to the client um yeah so yeah sorry um just I saw some uh like requests exceptions like HTTP errors like when you would when people are trying to fill if that happens just try again it could just be a bit due to flaky internet because we need to download uh the version of eels from the execution specs repo and if the internet's a little bit uh flaky then this might time out so I think if people I've seen if they've tried it again it's generally worked so don't give up all right all right that that is uh fine and Dy but uh we want to see the actual tests running a live Network so we can do that um and it's a little bit more exciting that just filling the fixture because you're going to see outcome uh so yeah let's just jump jump into it and just run the the test in live Network so what what this the live Network that we're working on um this is the link uh that I showed earlier let's go over there and just see what's happening how's the network looking like um you will see a couple of links here so the first is the Json RPC this is basically an execution client that is running on the network and that can it can receive your transactions it can send transactions it can uh give you the state of the network and everything um but we also have Explorer we have two explorers actually um and then you can see here over here this is basically the state of the of the transaction right now okay someone's already sending transactions um Perfect all right so yeah um this this is what you're going to use when you're sending your your test to the network you you are going to need to come here and see that you're actually sending the trans actions to the network um right now there's a couple ones um but it's going to get a little bit more heavy the more that we get into the into the into the work workshop um what else we have we have foron and fory these two tools basically just tell us uh what's the health of the network how is it looking is every client following the same chain have they split and um basically what we want to see here is we have right now A a healthy net networ but there's um there's two versions of the client running in the network and one of them is faulty and I know it's because I the fault it myself in there but the the goal is to write the test that is going to make this go split all right um so hopefully at the end of the on the on the workship we're going to end up uh breaking this uh right now it's looking healthy so no one has broken anything yet that's fine um yeah what else okay okay we also have a faucet here um again thanks for the E Pand Ops Team for all of this they helped us a lot uh yesterday to set everything up they're over there thank you and yeah and we also have faet you can uh redeem um uh test it from here so if you have an address just put it in there and just start mining it's going to give you uh some e to test uh I will wait a little bit because I'm going to do the the uh um the execu the execute part myself I'm going show you how to do it and then you can try it out uh by yourselves all right yeah so the first thing that we have to do um uh we're going to use a command that is called execute it's pretty new we just created it a couple of months ago uh but it needs an account uh to send the transactions so this is a very Rim rudimentary um script to create a new private key and an address to it um basically it just generates a random number please do not use this to store anything valuable for you uh this is not safe this is not cre to Safe this is just for testing purposes it's going to use the the the python random uh generator which is basically no no safe nothing safe to use uh to store anything meaningful all right but we're going to use it just for testing purposes today um please just uh follow the QR code you can get the the the gist uh and you can copy it to the execution spec test folder all right so let's do that uhu let try it obviously you're going to see the the key that I'm going to hold so yeah please don't don't uh don't troll me and send anything from that um let's see let's see okay so on the on the root directory let's just create um toch YY thatp Let's uh paste everything here all right and then just U remember to use UV run to to run the command uh gen key let's go all right there you go it's pretty easy um it generated basically a private key it generated an address so this is where everything's going to come from in my in my in my test um I'm going to provide this to the execute command for it to be able to uh to execute test but first we need to take the address um take the address go to the go to the faucet that we were that we have in in this link uh over here just go here paste the address that it give you and just start mining see what happens which one that one yeah yeah okay so I think we have funds let's see just claim it all right it's processing and what we can do is just go into the um to the the uh devet U main page and just go to the Explorer and we're going to copy paste the address that we gave to the faucet and see if it actually has some money all right so it does uh we had 100 did which is uh that amount of USD I don't I don't think so but anyway um yeah so now we're ready to execute the test um let's just do that uh let's see yeah basically what I just explained we're going to use the execute command um you need the faucet to obtain the fonts uh here's the link to the faucet uh but it's also on the other page that I gave you um if not possible if you need uh for some reason the f faet is not working just let us know we can send you funds into the to your to your address um so yeah I just and also I already checked this uh in this page just um all right go to this page and go to Explorer paste your your address and you will see the same thing basically uh yeah just let's just do it um all right so this is the command to execute the the test on the live Network that we're going to use to run uh right now um you need uh you need to paste the private key that you generated over here and then the rest is basically the same so let's just do that and see what what happens I'm going to I'm going to keep an eye on my the address that I give me a second so so yeah to make it easier for me yeah M perfect um all right so yeah so again U run execute then just mod ify the private key just put the the key that the script gave you over here just copy paste it here and yeah let's just hit go and see what happens and let me explain a little bit of the of the um uh the parameters um so yeah the parameter over here is basically just how much e should I should the test take from your account in this case just take 10 e which should be sufficient to send the test um the the RPC chain ID which is the devnet um um DEET network ID the fork uh this is irrelevant we're going to use oaka eventually but for this for testing purposes it's fine whatever you put in there is it can be Cancun or prag or we're going to use Osaka eventually and then last uh but not least the name of the test so you can see right now that it's already running and you can see the Green Dot here which means that the test passed so let's see what that means let's go back to the Explorer you can see there's already transactions uh going on over here so there's one transaction out and there's one transaction back in so this is this is the account that I just generated um this is the the the the the E from the faucet and this is the transaction out that will uh um make uh that will fund the transaction that is actually running test so let's see what that that transa that account is doing so this is a new newly generated account that execute created for me just to run the the the test let's see how that let's see over here okay all right so yeah so the first the first transaction is just the the funding again but then it's going to create here over here it created a contract what is that so if we go back to the to the to the test the first step in the as you can see is the pre- deoy contract and that is exactly what we are seeing over here so the first step on the on the on the network is the contract creation and let's see let's see what how that contract looks like um we can open the link here and we can see that it was created and then it was called later but then let's let's focus on the code that the that this code uh sorry this contract contains so yeah as you can see it's the same basically the same code that we set saw earlier um let's go back to the code put it um side by side yeah yeah all right so yeah this is the code that we deployed so basically just two push operations this is the one over here this is the zero over here the SS store is the 55 over here and lastly the stop so as you can see we deploy the contract of the test in the live running Network work um it's it doesn't end there because we need to ex execute the code to actually see what uh what happens so let's let's see just that yeah yeah and okay so so the contract was created and then the next transaction is this one over here and that one is the the funding of the account so we need a sender for the transaction and that is how it was funded um we funded that transaction with uh one e only and that is the one that is that is the account that it actually sends the transaction to the contract so let's open that uh that account see what what it looks like all right so yeah it's funded and then it it called the contract so let's see how that looks like all right perfect so yeah as you can see this is the transaction that is defined over here in in our test so this transaction um we set up a couple of things so the contract address the sender is that the one that we just funded and most importantly you can see other other properties such as the gas limit is over here it's it's going to use the same gas limit um and it's also going to use the same value so the value is over here exactly so it's not one e it's um uh one to the to the power of minus 18 eth so it's basically nothing but that is what we sent over here um so yeah how the main question I think is how did the test pass how do we know that it passed um so what execute does in the background is basically uh execute the transaction but also go into the contract after it was executed to see to see this stuff uh to to to verify this so what we can do is actually just modify something in the code to see what it looks like when the transaction sorry the test doesn't pass so let's let's do that just now let's modify um say the the storage let's set set it to something else which is not going to match with the storage over here and let's just send the the the test again to see what happens yep no I it's executing again you don't have to fill any anything it's actually the execute command takes the python and it runs the the com the python lines into the into the light Network so the filling process is is is is not necessary in this case yeah yeah so yeah the reason why it's taking a little bit is because um it waits until the the contract is deployed the transaction is funded the sender is funded so all of that it has to be done done serly because everything has to be there uh for the transaction to to pass and as you can see it already failed um it's going to tell me why in a little bit uh but it first even if the test failed it tries to return the funds because imagine this is a Dev net it's the the the the if that we're sending doesn't matter but let's say that we're running in sepolia which is a little bit more limited so that's why even if the test failed the the execute command tries to get back the fun from all of the accounts that were involved with the the test so yeah it's complaining right now um basically what it's saying is that okay you told me that the value of this of zero at this address it had to be uh it had to be uh one but it actually came out as two and this is the modification that we did over here um yeah so you can you can this way verify um that the the the that the test is actually doing something and veryify stuff um so I so let's let's wait until um has anybody else uh executed something uh how did it work all right yeah yeah so basically it but it goes to the RPC and tells you okay how many how much e is left in the account just subtracts the cost of the of the refund transaction and then just sends everything everything back that's that's that's basically it yeah um let's let's do let's change it up um a little bit so let's create another contract um let's create another contract that calls into the into the first contract let's call it uh contract address number one contract address number two so let's do that call so the the let's let's make it so that the first contract calls The second contract um um so yes this call and then address is going to be oh it's going to be the way around so one all right and this is just to just to show how it can create multiple contracts in the same test so yeah basically the modifications that I just did is just let's create uh two contracts now instead of one let's the first one is going to the the first one is going to uh do the SS store the same thing that we did before and the second one is going to call into the first contract so it's going to be an internal call we should see that on Explorer if everything went went all right so um let me see if I didn't make a mistake sorry sorry ah yeah of course yeah that is very true yeah the balance is going to be incorrect thank you perfect all right um yeah let's just execute it and see how it goes and let's let's see let's see life um perfect y yeah so there you go so all right so yeah there there you can see um so we are now creating two contracts instead of one so this is the this this account is the test coordinator so the first thing is that it gets the the funds the second the second part is is going to create the contracts two of them this time um and lastly is going to um let's see lastly it's going to do a contract call and the contract call is going to go into the first contract that we created so this is ZX 827 let's see where is oh wait mhm yeah so yeah let's let's see by side side there you go so yeah so the first the first contract that we have is um the the the first contract creation this is going to do the SS store and the second one over here is going to be the the one that calls the first one that we created so this this one um no this one is going to call this one so let's see and then lastly the the third the third transaction we're going to see is Al also the the the the funding of of the cender so let's go to to the fun to see how the transaction went so because we we Al we Al going to see the contol call to the first contract let's see that and see how it goes um yeah of course so you can see right here um so the the transaction is mostly the same but what happened is that we're going into into the first contract and this first contract it made an internal call to the other contract so you can see this right here which is the um which is the um the the the is done because of the call uh up code that we're using on the on the other contract so now you can you can you can see that the two contracts were created and when we called into the contract the first contract the entry point contract it made an internal call to the other contract so let's see if the test passed actually there you go it passed um but now the verification is a little bit different because instead of verifying the first contract the one that is the entry point we are verifying another contract which is the one that's receiving the call and setting the SS store uh over here y was any anybody else uh able to execute yep cont comp and then when IUN it on the test it only shows like the back and forth transfers it doesn't show the contract so I'm not exactly see okay so because there's uh there must be a contract the sorry this one this one is the one that is doing everything basically oh okay it's not the key no yeah yeah so the key is only uh the key sends to the test coordinator and the test coordinator does everything that you define gotta very good so what what's happening is that um um the transactions that we are seeing over here they are not they're the the only the first one is sent from the private key that you're entering in the execute command the rest go to a test C ordinator what what we call it the test coordinator is the one that creates the contracts and sends transactions um so that's why you might not be seeing the the transactions in the in the in the in the in the account that you that you funded from the faucet let's see how how many how many transactions are we seeing so yeah there's a lot of movement all right um that's great so yeah all right so everyone's running the tests and luckily or unluckily we haven't seen any any any deviations in the in the chain so the chain is still healthy um let's let's let's try to test uh make another test and let's try to uh change uh the change this thing to see if we can uh figure out how to break it um yeah all right so we already did that um modifi the simple test is basically just we can change the smart contracts add U add more smart contracts our parameterization I didn't didn't uh do that but we uh we can we can do an example in the next next uh next test and yeah change expected outcomes that's another thing that we can do all right so let's let's see a little bit on how we can test a a new ethereum feature so what happens when we receive a new AAP and we want to test that uh this is the this is basically the work that we do um when we are uh preparing for a new Fork um so every every change that goes into ethereum happens because of an ethereum improvement proposal um they are uh they are basically the updates that go into the fork and that uh they get approved and U and then we Implement them and we have to implement test for this uh this is the repository uh that we can um that we basically we save everything the all the all the all the eips com into here and um and this and basically you can see the whole history of ethereum over here uh you can see from the very first EIP you can see the new CPS for prag and all that everything is here so today we're going to focus on a an out tested uh EIP which is the 5920 it introduces a new OP code and the goal here is to make a test that uses this op code that breaks the chain um so what what does this this thing do let me just go over the EIP it's very simple the idea is that um the idea is that in ethereum every time that you call from a smart contract into another contract you if you want to send ether you have to make a call which means that you're execute the code that leaves in the other smart contract so the thing uh the thing that this up code changes is that you can use this up code to basically just send ether to another account and do not execute anything which is very useful if you don't want to do like uh re-entry and c and you don't have to have any reentrancy problems and all that stuff this is the up code that you eventually in the future you could use to prevent all that stuff um just send e uh to another account don't don't execute any of the code yeah normally we use call and delegate call to call the other account send send some funds into it and just limit the amount of gas that the the contract receives just to make sure that it doesn't execute not anything that doesn't have to execute all right um um I'm going to stop a little bit is there any questions so far how's everyone doing um questions uh issues that you're seeing with the code or anything yes sorry oh sorry I didn't uh have we done already any other transactions uh not only minting or not on the meting no we we send theaction but no there was no meting was like us the to get oh F was not it's was it was the single transaction we so if I send an ether to an contract that doesn't Implement any fallbacks does it still work or would it revert so um I think I think with this you can work around the fallbacks because it will send if even if there's absolutely no code uh if there's a code that uh revers the transaction because it doesn't want to receive with this would basically just uh skip that so yeah it will render some of the fallbacks uh unusable that is that is that is true so yeah that's that's one of the reasons why this has not made it into the into the chain um because it's there there are some edge cases that exactly what you mentioned you can you can work around the fallbacks with this thing uh you can already do it if you use self-destruct you can basically send any amount of this to any contract even if it doesn't want to receive e yeah so yeah let's proceed so yeah um we're going to um we're going to assume that this uh EIP goes into Osaka it's not the case Osaka as it is right now it's only going to introduce the eof EIP but we're going to assume that it's going to in Osaka anyway um so for that matter we we need to add the Osaka Fork into this file uh for everything to work uh in in this case um let's see let's see in this specific case we already have Osaka in in in our definitions so it's not a problem we don't have to add it uh but in the case in in when you are implementing some EIP that goes in the future that is uh later than Osaka you would need to go into this file and create uh the new Fork but this is not the case it's not necessary Osaka is already there that's what we're going to use all right and lastly since we are creating a new up code we need to include this in in in our in our in our in our in our framework so the way we're going to do that is basically just this is the code that you need to add into into the ethereum um test evbm up code file so let's just go ahead and do that again this code is uh this link should be in the in the in the hackmd that is that was provided at the start um but otherwise uh yeah just feel free to to open this link and this we're just going to basically just copy the code I'm not actually there was an issue and it was fixed because of that all right so yeah let's let's go ahead just copy the code and let's just put it in the in the evm in and sorry the ebm uh up codes file um there you go so this is the thing that we're going to use uh to um actually use the the new up code into into our code so again uh just go to this link um copy the code come here to the up code. py and inside of the class up code just basically just copy paste it at the end as you can see here I'm going to give just one moment all right um and finally um we can write this a test from scratch but in this case we already have a template um for the simple St that it's going to use this sub code um so let me just uh open it up and and we we can just uh analyze what's happening over here um yeah so yeah this is basically the first test that we are going to create this is the simplest test that you can imagine for the EIP 5920 um it basically just tries to use the up code uh but the catch is that you're going to send money to a contract that executes some code in this case up as as a store as we did in the previous test you remember that that's the thing that we going to use to test storage um but you shouldn't see this change in the in the execution so what should happen is that from one contract that is going to pay the other contract it should not execute this code so instead of uh writing in the postate that we should see a one in the key in the zero key as the previous example we're going to expect that to see nothing here so that that would prove to us that the pay up code sent the E without executing any code so let's just do that let's just copy the code and we're gonna right now gonna paste paste it okay let me I I skip one bit um so yeah in the in the test repository um we normally when we are creating a new Fork we come here and create the new uh Osaka folder for example the the for the the fold folder for the new Fork um so in this case I've already created uh the the folder for the file so you can place it here so basically just create uh inside of the test OS SAA folder just create EIP 5920 pay and inside of that we're going to create uh first the the file that is required for python to recognize there's something in here which is the underscore underscore init uncore uncore dop and it can have nothing in it it's just going to be there but the other that we're going to create is the uh test pay testore pay thatp which is which is where we're going to paste the the new the new the new test um that we just creating um so again a very simple test just use the op code uh to a given recipient verify that it doesn't execute code um we actually can just go ahead and run it uh it's going to be the exact same command that we use the only that we're going to see is that we are going to execute this new file instead of instead of uh instead of the the other file that we were using so let's go ahead and just do it um see okay and another important difference is that um where is it okay okay instead of fork Cancun we are now actually using Osaka and the reason is that we need uh to make sure that there's U no compatibility issues so we're going to that's the only change that we're going to make so Fork Osaka and then also point to the new test and let's see what happens let me just copy the address that we are using for this just to follow up on the transactions all right Perfect all right so yeah the test is currently running um it's already passed but yeah let let me just again explain a little bit um it's um it's basically again just creating two contracts the one at let me let me open up the test side by side all right so is creating two contracts the first one is going to use the uh the s store um and this one is the one that is going to get paid um the second one is the one that uses the pay off code to pay to the first uh contract so um what we should see here actually is let's open up the the contract and see what happens um where's the value oh there I got it the other way around so yeah so yeah the first contract the first the first contract is this one it contains the SS store let's see the the code inside of the um wait yeah see for e h I think yeah I think I think it should work but um I'm not seeing the the balance change but ex yeah yeah yeah but the problem is that uh I'm not seeing that balance change here so it should be the balance should be one in here um because this is one that received the paay off code it might be that uh there's a problem with Explorer um what can we do yeah we can be yeah yeah sorry um all right let me let me just change the test a little bit so what happened was that the the two contracts were created and the problem is that I'm not seeing the balance change in here I as I I think that it might be a problem with explorer that it's not updating the balance or um or it might be some some other issue but what I want to do to verify that it works is maybe just change the value amount and just see that the recipient contract it should have the balance the New Balance um which is two let's see let's just run that again see what happens oh there you go Also let's see if the chain is still it's having no problem still all right so yeah basically it's working but I'm not seeing the updates in the in the Explorer it might be because it's not expecting some extra up code that is not called to change the balance balance of the of the of the account but it seems to be working here because we have this uh let's let's just change that to see to some other amount to see if it's it it should fail now then send it again yeah so now we're seeing the value that is it has to be two and I just hardcoded one just to make sure that it's it's actually detecting the the change correctly where is the recipient okay yeah there you go so yeah it's working it's just not in the Explorer for some reason um so yeah we I think we found a bug in in the in the Scout Explorer it's fine um yeah the the verification is working we are paying the contract we we saw that the Des pass when we were checking for the balance that is equal to the value amount so it was fine and when we modifi that amount it it failed so yeah it's working it's just not seen in the Explorer for some reason um yeah we found the bug not not the way that we wanted to find the bug but we found the bug anyway um all right let me go back to the presentation yeah um yeah so with that in mind um this is like the first very very first step when you are testing a new AIP um you basically do the simple test first just to make sure that everything is working but we can expand uh the testing and we must expand the test the the desk coverage to include many other different scenarios including Ed Cas scenarios that is very essential for us to see that the up code is working before it can actually uh reach mainnet um just some examples um of just very simple test that we that we would do if we were testing uh AIP 5920 just try sending for example more balance than you are actually have because you are paying yes but if you don't have that balance there should be an exception um what else try sending balance to pre-compiled which which is um important addresses in the ethereum blockchain we have precom for many things but just to make sure that it doesn't execute anything uh with the pay code you would uh try sending uh some some some e to that to that precompile U test running without any enough gas that's a very important one to make sure that uh that you you uh that it R actually runs out of gas it doesn't send the E uh try sending the balance to yourself that's another another option um and yeah basic up code stuff um we we saw that it needs two parameters just try to do a stack underflow by just putting one parameter and see that it fails correctly that's just one example um yeah um there are there are some things about 5920 is one of them is that it doesn't um specify a lot uh things um we normally when we are developing the test there are a lot of times when we read the specification and it's not clear enough so one of those those example is how um um how how should it behave when it doesn't have enough enough funds so that's one thing that we should definitely test and add add to the test cases um yeah all right so but another one is that um what should happen uh what should happen to the to the to the account when you are already doing a call and then you pay uh use the pay up code you shouldn't see any difference in in what it's called the return buffer um so that's that's what we're going to do right now we're going to write that test and see what happens all right so yeah very simple um Let's do let's do first a call and that let's store Perfect all right so let me just explain quickly what's happening here um so we have two contracts again uh the first the first one is just basically just returning information to the first contract all right and the second one is calling into it so uh what happens is that if we if we call a contract you're going to get what is called the return buffer so you will see in that buffer you you will see an one single bite because of the return uh the return property so what happens is that if we call and then we do the pay operation we shouldn't see any modifications to the return buffer right so because we are not executing any code we shouldn't there should be no reason why the return return buffer is like modified or even cleared or anything um so so and yeah let's um let's just do that this is this is an up code that is basically just gives me information about what is in the return buffer in this case it's going to give me the size of the return buffer I should see a one still because um because I'm calling first then I'm doing the the pay operation and there shouldn't be any modifications so let's see what what what happens when I uh when I try to store that and then um yeah let's let's see just what happens and the interesting thing mhm all right so the the test here ideally should pass but we already know that there's a consensus difference between the two clients so we're going to probably see the test pass here but let's see what happens with the network once we uh once we uh execute this it's taking longer than usual and that might be let's see there you go perfect all right it's not it's not as as clear as I would like to but you can see now that only one is following the Shan we just found the consensus book basically just by trying to follow the spec implementing the test sending it to the network and we can see that now exactly there you go we can see the split here this is a very simple test and this is why we we create these tests so this doesn't happen on Main net or even the test Nets um yeah one client is progressing the other one is not agreeing with what it saw just because one line of the op code was different and the result was different what from what it expected um yeah all right I'm just going to um continue with the presentation just try to wrap it up um so yeah what we can learn from this um so yeah um this shows the importance of the consensus test uh if we didn't have this basically this could happen on the on the on the live Network on Main net or on a test net uh we don't let it happen because we write the consensus tests and this is the importance of the consensus test all the clients before they they they join a a test net or or even a Dev net they must pass the consensus test that we create this is very important for them to not Fork out of the chain like we saw happen uh today um if one another important part is that um if a if a client they are running tests everything is passing but they are sure that they found a bug in their in their client and we didn't catch it that is feedback feedback that has to come back to us because we have to create more tests to make sure that their their Edge case or their scenario is properly tested so it doesn't happen in our client um and yeah also specs can sometimes be underspecified uh um it happens uh there's sometimes that when the EAP writer is thinking of the of the use case of the of the the feature they don't think of all the yes cases so it had happened that we are implementing a test and we don't know what the outcome should be we go back into the EAP we improve the E we specify the thing that was under specified and then we update the test um so yeah it's a it's a it's it's a it's a running process um it's it's never U It's never enough until we are already tested with most of the clients most of the kinds are passing and that's when we are sure that the um that we can hit the test Nets uh with with the with the new feature yeah um yeah one ex one great part of having uh uh the theorem open ecosystem is also that tests are also verifiable they are open and so I encourage everyone that if you feel uh there's a uh there's a new feature that you feel unsafe about we encourage you to go into tests they are open you can everyone can verify what we're writing what the test that we're writing so if you find something in the in the eips that you think that is under tested uh you can also be even legible if the feature already hit main net you can also be eligible for a bounty so uh it's good to write test it's better to receive money to write tests so there you go uh you can use a repository if you find something that you think is is critical one thing that you you should consider is that if you trigger such an issue on a on on on a main net or a test net you're no longer legible so basically if you find you think you found something by using your test or any other means go to this page but do not send a a a breaking transaction into into any test net because that will make you not eligible I think um for CR consensus critical tests or cons sorry consens critical issues you can get up to 250k which is a lot of money so uh do if you trigger it you lo you lose that so reach out uh uh explain us the problem and we are we're going to try to make sure that the clients fix everything before making everything public yeah that's basically it yeah you want yeah so if you enjoy today and enjoyed writing tests uh like I mean the main main message is uh reach out to us and like I mean if you want to work with us contribute with us get in touch um but also like you can find us if you go to the documentation um you can go to getting started getting help and then you can find all of our like details to get in touch with us and if you really enjoy it and you're at a bit of a loose end um then feel free to apply for the job that's on uh ethereum's lever as a protocol test test so we have a position open for execution spec testing and consensus spec testing of course um and I'm just going to show like for test so if you if you want to browse for test cases it may best best to not like browse the source code but go to our documentation make sure you're on Main and go to test case reference can can you show no where is it so you can find all of our contact details here and just feel free to reach out um and otherwise um you've really we covered a lot today in the workshop but uh if you'd like to see a little bit more under a little bit of a history then feel free to come to our talk today on stage 1 at 2:30 [Applause] and if you want the pup just grab me I've got the QR thank you everyone