 What is blockchain? In the blockchain we have one state and some transition rules from one state to another. Those states are represented by blocks and transition rules are basically a protocol. In case of Ethereum, these are the rules for calculating the difficulty, gas payment, and other parameters of zero. And the question is how would we pay to consensus in case of different client's implementation on different languages all of them should get to the same state and be in consensus with each other. And to do that we created tests. We had a transition from one state to another. And they divided the most major ones used blockchain tests, transactions, state, VM, and we created thousands of such tests. And I begin with a more simple test. It's state tests. Most common example. They are encoded in JSON files. The link down below to the test repository. No, to the document. In such JSON tests, the most important part is a post state that would be created by the client while creating an environment with some pre-state and the transaction that would be executed in this pre-state. They would create such environment by executing this test and execute a transaction and get their own post state. Then they compare this post state to the ones that describe it in test file, blockchain tests. Basically like state test. But in this test you have not a single transaction, but a series of blocks. And each block could have different transactions. Some blocks might be invalid and each client should read such test from a JSON and try to import it in its own blockchain. And as a result it also gets a post state and last block hash. These are important values. Clients check such values against the ones that described in the tests. This is an example of invalid blocks. They are represented by empty LLP bytecode. As you could compare, a valid block have different parameters that are also encoded into LLP. So what clients should do, they read such blocks from a test file, decode LLP function and compare parameters of a block to the one described in the test file. That's for valid blocks. And for invalid blocks we have just LLP. That means that such block should be considered invalid. If a client considers such block valid, then something is wrong. A lot of questions was to the blockchain test folders that are also in our GitHub repository. We have blockchain test folder with subfolders for homestead folder and the test network. And now I will answer your questions about how tests work in such folders. So in blockchain test folder we have tests that have blocks that are from frontier network only. And in a homestead subfolder all blocks starting from zero and so on are from homestead rules. And the test network is a special one. Because in such network we have eight, ten blocks in one test file. And starting from five blocks a homestead rule applied and then recently added from block eight DAO hardfog should occur and we have such test to test the DAO for transition. And maybe we would have another addition to these rules for test network and you can find on the link down below. There's a documentation about such tests. Like the state test we have VM tests. Basically the same but the sole purpose is to test the VM. It basically executes a code for VM and not concerning about blockchain properties or something. And next we have more simple tests like transaction tests. Just describe how transaction should be imported or whether it could be recognized as a wrong RLP for wrong transaction. So in a JSON file we have this description where the block number indicates whether this is a transaction from frontier network or homestead. And other values are also present if a transaction is valid. If transaction is not valid also you have just RLP field. That means the transaction is invalid and when you implement such test in your client you should check against this. And how these tests are created. We're creating those tests through the CPP client special test tool called TestEase. And for each test or most of them we have TestFiller file. This file like a source code for the test it executes on such a file and creating a destination test. This was originally designed by Christoph Jench and now we have like all tests working the same. But sometimes I have a request to the Ethereum test repository to add some more tests and this is not really a correct way to add some. Because these tests are going to be recreated by this test fillers. So if you want to add a new test case you first want to experience what are the test fillers. Or basically just open an issue for the test repository not the test. So what do we have? We have documentation and help created by Bob Summable on this Ethereum doc site. Here is a link for the tests. We have test repository containing thousands of tests in adjacent files. And recently we started a new project like Hive Implementation. In which you just provide your client executable and the bar script to run inside Hive and Hive would be the test framework that would execute different kind of tests on your client. And all you have to do is just to provide your client setup or deployment script and RPC IP for your client. And we also have a Gita channel where I could ask questions for concerning development and testing you could find me there. So basically that's a quick overview of our testing the Ethereum clients. Thank you. Thank you Dimitri.