 Thank you. Hi, my name is Dimitri. I'm working with the foundation for about three years and For a long time a serum testing was performed by one person Kristoff Jenj He initially invited me to the Ethereum foundation and then I continued his work So today I will describe you for you how the testing process goes in the serum and What we achieved for the last year science Shanghai So what we have is a yellow paper, which is a protocol Yellow paper describes the serum protocol what it doesn't make it easier to understand Actually, this picture represents yellow paper really well Nobody able to understand this unless we thought it may be and We have lots of implementation of this protocol written on different languages different clients and The testing problem is to make sure that every of their client is in consensus with each other and they Interpret they implemented this yellow paper rules In a way that there are no consensus issue between themselves, so to do that we have our testing sued Each test file is a Jason Instructions and coded in Jason file and We could select three main times of the test so first one is a VM test is basically Number of instruction for EVM by machine It's the most simple test in the whole test here. So if if there is any developers here you could If and if you're implementing EVM you could start with VM test is the most simple ones The next is a state test. It's a bit more complex and VM test. It has Accounts transactions and state changes state hashes and so it's a bit more complex and the most Sophisticated test is a blockchain. It has actual mining difficulty and other algorithms implemented Well and for a long time we required all the clients to implement Custom test tool so they had to read this Jason files and implement this and compare the results It was not so So good So we use a C++ client to run Test source which is my job is to keep those sources from test sources updated with the most recent issues discovered and What we are trying to achieve is to create lots of lots of different test source files describing all of the possible situation which we could Get in a EVM code execution and then C++ client execute those Instructions and it creates a final test final test is being processed by other clients and They compare their results to the C++ clients And that's how we see if everyone agrees with C++ client, which is a like a golden starter If there is an issue we open a dispute and discuss whether we have to make a change in the C++ client or other clients So we had a couple of problems The first problem is to create an ultimate test suit which covers all of the code or all of the possible situations Which we could run and possibly find all of the bugs and consensus issues The second problem is that Clients they should execute our tests and because before we are required to make their clients this custom tool I Had to manually ask every client developer. Have you run this test? Have you updated the test repository? Is it updated and one time I discovered that go client wasn't Running the recent test for about half of one year and there was a there was a hard fork already And they still not get notification up with the tests Not to mention that I don't know the status of other clients Okay So how we solve those issues To get the best code coverage first we have test cases list which could be found on Google documents This is a manual test cases if you came up with an idea for test case you could manually add this to this Also, I want to mention if you think you know how to make a consensus issue There's a reward for bug bounty from the foundation if you discover a consensus issue You could get money Okay, and So to cover even more cases you can you can possibly come up with every situation, but I think it's impossible. So we did some Tools that basically run a random code random even bite code on not really random like fast testing is Smart random code and this code hope we hope that it will find some consensus ratio and it did another approach will be to use a fancy tool that you'll analyze a source of a client and then run different bite code executions and Maybe some fancy algorithms and we'll produce a Very very good tests Okay to solve the next issue with the clients being updated last year I mentioned that we have a Hive tool in development and Now it's life and working now we no longer require every client to implement their custom test tool they just need to provide a client and an RPC interface and Then any client could be integrated in a hive tool and this hive to perform a test execution Automatically and we have results you could see on a hive stats page There is also also this execution on every client also clients have a continuous integration builds in a github each commits Executes this continuous integration test in a github which synced with our test repo is theorem tests and I still personally do Ask people on a skype or the channels versus a perform the most recent test executions And as our field of work which was performed by Casey He did standardization of Evian logs and by doing this we could now compare that not only we have the same hash after the test execution But the way we get to that hash is exactly the same on every client And for the past year we added some debugging for the test it still which I'm a developer of and This is basically a whole new field of work with those traces for them and better debugging Okay, and another update for the for this year will be my personal fork coverage by fork I mean Is there who has certain hard fork points like home stand and other proposals which We actually don't have a consensus about naming those folks. I called it like EAP 158 and others called some kind superiors dragons and Those points means that from this particular block The protocol has changed and we have to test that all the changes and all of the clients Implemented correctly But we have a test cases and there I Had many a lead to copy all of the test cases for each hard fork and Then I came up with an idea of a general test format So now I describe one single test case and then C++ convert this test and execute it on every fork and produces a couple of Output final tests which actually a Result of this particular test cases on every fork that that is what I call general tests and for the past year I realized State tests which is now general every state test being executed on every fork and in future All of the test cases that we have will be executed We I just have to run one comment and all the test cases will be Generated on the recent forks Same with blockchain tests and next will be the transaction test Also, thanks to Yoichi he did the awesome Documentation about how he learned because he has joined us this year He created a documentation of his steps when he Was learning the process of test generator Generating the test and then he created this documentation if you interested in Running the test execution yourself or if you're a developer and you need to know how this works There's now a updated documentation You could take the picture of the links and You could see that now our testing team is not a single person We have like lots of people joining and most of them joined us this year So special thanks to all of them working together on tests. Okay We still have time for questions Okay Yeah, not all of the tests are running on a hive unfortunately So general state tests are being converted in a blockchain test. This is another update So I just run a common and all of the general status being converted blockchain tests Which then will be run on hive. Okay. Thanks to me tree You