 quickly overview the internals of the Ethereum client implementation. I am most of all familiar with the C++ client, but in fact there are many common ideas behind all of the clients and in this talk I'm not going to tell about C++ client in particular, but about the general view of what any client should consist of, the things that you would definitely need to implement as a part of any client. This talk might be interesting to anyone who is kind of new to this area and is wondering about some practical details of how Ethereum works under the hood, or maybe to someone who might be considering implementing a new Ethereum client with their favorite programming language and I could recommend that as a best way to get a deeper understanding of the protocol. So I'm sure everyone knows what a client is. It's a piece of software that allows you to connect to the Ethereum network, run a node and interact with Ethereum. Also, all of the teams working on the clients usually clearly separate any kind of user-friendly graphic interface from the back-end core part of the client and in this talk by the client I mean only this back-end part which doesn't necessarily have any intentions to be user-friendly. Essentially, a client is an implementation of the Ethereum protocol as specified by the yellow paper, the main formal specification of Ethereum, but not only that. This is a very high-level overview of more or less everything you can find in the client. The middle part in yellow is the implementation of the Ethereum protocol itself. This is the part specified by the yellow paper directly and this is where all of the client developers should be very careful in following this specification because if there is some disagreement about how the client should behave it could lead to an unintentional fork in the network. And all the rest is the parts where developers have some freedom in choosing the approach, strategy or technology of how to implement it or for some parts maybe whether to implement it at all. So let's go into some details about each of these parts starting from the lower-level components, the ones closer to hardware. The networking layer is essentially the implementation of the peer-to-peer protocol which specifies how the nodes in the Ethereum network can communicate with one another. In fact, it's not one single protocol but a family of protocols. One important of them is the node discovery protocol. That is the algorithm of how the nodes find one another in the network and all others are nicely designed as two levels of protocols or maybe three levels depending on how you look at it. So there is a lower level called the peer-to-peer and together with something even lower level called the LPX they together specify how the nodes can exchange the binary encoded messages. By the way, for the binary serialization Ethereum uses this cool format called the OP which stands for cursive length prefix. It's used not only in the networking but everywhere in the protocol. So basically the peer-to-peer specifies how the nodes can talk to one another with RLP encoded messages. And other protocols are based on the peer-to-peer and they specify which data exactly can be exchanged. So there's for example if protocol that specifies how the nodes exchange the mind blocks and the mind painting transactions. And there are other protocols for downloading the data during fast sync or warp sync and these protocols are also based on the peer-to-peer. Every client needs some persistent storage for the blockchain and the state data. Typically clients use some kind of key value storage database for that because this fits naturally all the needs of the Ethereum client. For example, CBP Ethereum and Go Ethereum and Python client as well all use level DB for that. What is the distinction between the blockchain and the state data? There can be in fact stored all in a single database or in separate databases but anyway these are pretty distant parts of the client data. So the blockchain obviously is the storage for all of the blocks, all of the transactions of the blocks and the state data is kind of orthogonal to that. It is the current information about all of the accounts and contracts currently existing in Ethereum. They are balanced as nonsense code of contract storage of contracts. Also clients typically implement some indexing and caching strategies on top of the database to make queries more efficient. Some clients also have the pruning of the state data that is compact in the state database by removing some older parts of it that are not normally needed. Synchronization is the process that allows us to get the latest blockchain and the state data from other nodes of the network. So we could say that it is built on top of both the networking and the database layers because it gets the data over the network through one of the network protocols and this data ends up in the database. So there currently exist at least three known methods to organize the synchronization. The oldest one, the one that appeared first in the theorem is full sync, also known currently as archive sync and it is basically just downloading all of the blocks one by one and executing each and every one of the transactions of all the blocks. And this way you calculate the full Ethereum state according to each block and in the end you have what is called an archive node that is you have all of the intermediate states and you can query any of them. In practice doing this for the whole blockchain is terribly inefficient nowadays and it will take ages to complete so almost no one currently uses this by itself. Fast sync also downloads the blocks and it downloads the full theorem state as well. So we are full sync calculates the state by executing all the transactions fast sync instead of this downloads the result of this of this calculation from other nodes and that's the main difference. Also for efficiency reasons fast sync keeps some proof of work verification for some blocks still trying to remain as secure as possible and in general this approach allows to make sync time pretty manageable. Snapshot sync also known as warp sync in the parity client is downloading the compressed snapshot of everything needed to start the node including the blocks at least some number of recent blocks and the state according to the last block. I should say that although as I said full sync is very inefficient and nevertheless it is very essential component of any client implementation. One reason for that is security even if I don't want to have an archive node I still it would still be a good idea for both fast sync and snapshot sync to switch at some point close to being complete to full sync mechanism and this way I can be sure that the latest state I have in the node is based on my local transaction execution and not something you get from the unjusted nodes at the network. And another reason is that if your node gets behind the current chain for some reason like if it was offline for some time then you would need to download these missing blocks that are mined during your downtime and usually the more efficient way to do that would be to download them through full sync mechanism. So to summarize to have a client that can be practically used in real Ethereum networks you would need to implement at least full sync and at least one of the fast sync or the snapshot sync. And there is also live client technology about it. People were talking about it in the main hall today in the morning. It's something completely different. It's not exactly the way to organize the synchronization but a way to run the client in such a way that the full state and the full blockchain is not needed locally and instead of having the full state in the local database the live client can request the parts, the needed parts of the state from other nodes and download them when needed and this way keep the local database very compact. Blockchain, this is the first one of consensus critical components specified directly by the yellow paper. And essentially it is the implementation of the number of rules around the data structures like the block, the transaction, like for example the rules for constructing the block, filling its fields, calculating the difficulty of the block, rules about signing the transactions with the accounts private key, rules about encoding all of this in RLP format, etc. This part I would say is not so complicated although it might seem that there are many difficult rules to implement here but anyway it is very precisely specified and all you need to do here as a developer is just to carefully follow the specification. Another important part of the client data is the state. As already mentioned this is the information about all of the currently existing accounts and contracts of Ethereum. So what is required from the client implementation here is also to carefully follow the specification regarding what constitutes the account. And another thing required from the client here is to implement these awesome tree data structure called Norco Patricia Tree which allows us to compact the store and efficiently query all of the state data. So this means that on the physical storage level the state database stores only the nodes of this tree and then the responsibility of this component is to provide a high level interface to the storage in the form of convenient access to accounts data. The Ethereum virtual machine is the component that executes the code of smart contracts. More exactly what it does is first it receives some input data and bytecode to execute. This bytecode is just the primary sequence of instruction codes and the operands. Note that EVM doesn't know anything about Solidity or any other high level programming language. So we don't have to deal with that here. So EVM just executes the instructions of the bytecode, calculates the gas consumption for this execution, performs the corresponding updates to the state like for example saving something into the contract storage and returns some result data or an error in the end. This component I would say is pretty complicated and challenging to implement. Well, implementing it according to the yellow paper specification itself may be not that difficult but making it work efficiently is an important challenge and typically clients have various kinds of optimizations around here. Also I should note that there exist two different approaches to implement in the EVM. The simpler one is interpreter that is executing the instructions one by one as we see them in the bytecode and another one is just in time compilation that is translating the bytecode into the hardware machine code and then executing it. This is the implementation of the proof of work algorithm still used in Ethereum. It is called ethash and the client needs it primarily for two reasons. One is to validate the blocks that we receive over the network and another one is if the client also supports mining we would need it to create a new blocks. Some clients also support some alternative setting algorithms like proof of authority for incubator or network. RPC is the primary way for the dApps to communicate with the client and as we might consider with dApps to be the main users of Ethereum clients in this sense RPC is the main interface of the client. If you are a dApp developer then you know that RPC is what underlies Web 3.js interface that is used in the dApp code to communicate with the node. So just RPC is used as an RPC protocol and not also that it can be used both with a locally run client or remotely through HTTP. And this link here is the API specs for any client that wants to be usable by the dApps should provide at least the methods listed in this document. Any client that expects the dApps using it to create and send the transactions should provide at least the very basic wall functionality. This again doesn't mean that we need any kind of graphic user interface for the wallet necessary because this is only the back end part we are talking about here. What is needed is just wall functionality and access to it through RPC. So the client typically should provide at least the way to manage accounts like create an account, import and export account data list accounts etc. and the ability to send transactions with the account's private key. And here are some features that are not so critical but are nice to have in the client since they can make the life of the user easier both for the human users and for the dApps. So these could be features like import and export of the blockchain data, interactive console supporting Web3JS calls, some tools useful for debugging like for example the tool for running EVM code and seamless results, compilers from high level languages like Solidity or LLL. Also I mentioned mining feature which is of course big and important feature but in fact it's not that indispensable part of the client. You don't necessarily need to have a mining support in your client for it to be usable by the dApps and it can be completely separated from the rest of the client and in fact that's what we do with CPP Ethereum having a GPU miner as a completely separate project. And here's the special mention about the tests Consensus tests are a comprehensive corpus of tests developed and maintained by our testing team. They are essentially these JSON files each one specifying some initial state of Ethereum some operations on it in the form of transactions or blocks and some expected state after that. So what is required from the client implementation here is to be able to parse these files around the tests and compare the final state and of course to pass on the tests. The tests are important topic by itself and Dimitri is giving a talk about it in an hour from now here in the breakout hall I think. So if you're interested you are welcome to attend. And this concludes my overview of the building blocks of the Ethereum client. If you're interested in getting into more details you are welcome to dive into code repositories, documentation or to join our developer GitHub channel. Thank you for your time. Alright so I get what happened. So the other research team members they were using my thing to factor very