### Ethereum Protocol Design Derived from the concepts presented in its [Whitepaper](https://ethereum.org/en/whitepaper/#ethereum-whitepaper), Ethereum derives influence from Bitcoin and its historical context (as elaborated earlier) to establish a versatile blockchain-driven computational platform. The technical specifications were meticulously detailed in the [Yellowpaper](https://ethereum.github.io/yellowpaper/paper.pdf) and have since undergone iterative development. These modifications are monitored through the community-driven process of [EIPs](https://eips.ethereum.org/), with the current specifications being realized in Python as follows 1. [Execution specs](https://github.com/ethereum/execution-specs) 2. [Consesus specs](https://https://github.com/ethereum/consensus-specs) For non-tech better read [this](https://eth2book.info/) ### Design principles The protocol changes over time, with each network upgrade bringing new improvements. Despite its constant changes, the architecture evolution reflects certain fundamental principles. These can be summarized as follows: **Simplicity, Universality, Modularity, Non-discrimination, Agility** check [this](https://web.archive.org/web/20220815014507/https://ethereumbuilders.gitbooks.io/guide/content/en/design_philosophy.html) for more details Ethereum network leverage decentralization to become permissionless, credible neutral and censorship resistant. It continues evolving to address the latest research, new and always present challenges. To maintain security and decentralization, blockchain technology has certain limits, mainly its scalability. Because Ethereum needs to always adhere to its principles, it motivates us to find clever for these problems rather than accepting trade-offs. The current research and development is summarized by the [roadmap](https://twitter.com/VitalikButerin/status/1741190491578810445) overview, however cannot be fully accurate. There is no single path for Ethereum R&D, the [roadmap](https://ethroadmap.com/) only sums up its current landscape. The core ecosystem is an always growing infinite garden. However, with more and more progress, Ethereum might slowly approach its ossification. > Simplified overview of the current Ethereum design can be found documentation on [node architecture](https://ethereum.org/en/developers/docs/nodes-and-clients/node-architecture/) and in the week 1 presentation As hinted above, the main high level components of Ethereum are execution and consensus layer. These are 2 networks which are connected and dependent on each other. Execution layer provides the execution engine, handles user transaction and all state (address, contract data) while consensus implements the proof-of-stake mechanism ensuring security and fault tolerance. ### implementations and development Everything mentioned above - the ideas, design and specifications comes down to the actual application here, in its implementation. An implementation of the execution layer (EL) or consensus layer (CL) is called a client. A computer running this client and connecting to the network is called a node. A node is therefore a pair of EL and CL clients actively participating in the network. Since Ethereum is formally specified, it can be implemented in different ways in any language. This results in a variety of implementations throughout the years with some already deprecated and some just being developed. The current list of production ready implementations can be found in the [docs on Nodes and clients](https://ethereum.org/en/developers/docs/nodes-and-clients#execution-clients) > This strategy is called [client diversity](https://ethereum.org/en/developers/docs/nodes-and-clients/client-diversity/). Ethereum does not rely on a single 'official' implementation but users can choose any client and be sure it does the job. If an issue occurs within a single client implementation, it doesn't affect the rest of the network. ### Testing With regular changes and multiple client implementations, testing is fundamental to the network security. There are a variety of testing tools and scenarios which are all heavily utilized before any network upgrade. Tests are generated based on specifications and create various scenarios. Some are testing clients individually, some are simulating a testnet with all client pairs. There are different testing tools used for different parts of development cycles and parts of clients. This includes state transition testing, fuzzing, shadow forks, RPC tests, client unit tests and CI/CD, etc. > Here is a short list of repositories dedicated to testing: > > https://github.com/ethereum/tests > https://github.com/ethereum/retesteth > https://github.com/ethereum/execution-spec-tests > https://github.com/ethereum/hive > https://github.com/kurtosis-tech/kurtosis > https://github.com/MariusVanDerWijden/FuzzyVM > https://github.com/lightclient/rpctestgen ### Coordination The Ethereum development is very different to a traditional, corporate kind of, projects. First of all, it's all open and public, anybody can review it or contribute. And second, there are many different teams working on different parts. All together, there are around 20 different teams from various organizations working on Ethereum. Unlike in proprietary tech, Ethereum developers are not competing but rather working together. With the complexity always growing, there are basically no people who would be experts in all of Ethereum. Instead, people develop expertise in specific domains and collaborate with others. This is possible thanks to the modularity of Ethereum and allows developers to focus on challenges they personally prefer. > The traditional development cycle for new features or changes is Idea - Research - Development - Testing - Adoption. However, problems might arise at any moment of this cycle resulting in iterating again from the beginning. To be able to ship network upgrades and agree on the current development focus, there needs to be a certain coordination. All of it is also public and can be followed by anyone interested in learning about the core protocol. The coordination mainly happens via regular calls which are scheduled in the [PM repo](https://https://github.com/ethereum/pm). There are different kinds of developer calls with the biggest one being All Core Devs (ACD). This is where representatives of all involved teams come to discuss the current development of the consensus or execution layer. The ideas and proposed changes from the community are coordinated using [EIP process](https://eips.ethereum.org/EIPS/eip-1). Additionally, there are a few discussion forums. The biggest one discussing core upgrades is https://ethresear.ch. Another forum which is connected to the EIP process and serves for discussion about specific proposals is Ethereum Magicians. Lots of important discussion is also happening on the R&D Discord server (ping us in EPFsg discord to get an invite) and in client team groups. There are also offsites or workshops where many core developers meet in person to speed up the process face to face.