Certain regulators and policymakers who seek to stifle the growth of decentralized networks assert that “ETH…is a speculative asset that relies on the efforts of third-party developers in order to provide profit to the holders of ETHs.” This assertion serves to underpin the necessity of applying legacy legal frameworks. The truth is, the Ethereum development community is a much richer, globally diverse, and complicated picture when you understand how open-source software is developed. Just as the web today is a product of the cumulative contributions from innumerable people working on a broad computer programming spectrum, so too is Ethereum a product of the disparate, sometimes contentious, but ultimately harmonious work of thousands of people working on different ideas.
A recent report by Electric Capital notes that Ethereum added 14,691 new contributors to its open-source projects in 2022, an all time high. In the first quarter of 2023 alone, there were 1.9M downloads of Ethereum Standard Development Kits (SDKs) like Ethers.js, Hardhat, Web3.js. There were another half-million Ethereum wallet SDKs downloaded, like MetaMask, Coinbase Wallet, Rainbow, and more. Put simply, millions of developers are building open-source tools, applications, and even simply enabling websites and business to connect to Ethereum via self-custody wallets.
Ethereum is designed to be this way — an open, interoperable computing platform for the entire world. So how does one contribute to Ethereum? In this post, we describe the four key areas of contribution to Ethereum: (i) protocol development; (ii) client development; (iii) infrastructure development and; (iv) application development. Through this, we hope to dispel any misconception that Ethereum is as organized, directed, and cohesive as a handful of loud voices are characterizing it to be. The truth is, open source ecosystem development is much messier than its centralized equivalent, and Ethereum would not function without its diverse set of contributors.
Protocol Development
Ethereum is, first and foremost, a protocol, just like the protocol the internet relies upon: TCP/IP. A protocol consists of a shared set of rules and specifications about how data is created, transmitted, and stored by a computer network. The very first specification of the Ethereum protocol was represented in the Ethereum Yellow Paper. That first specification has been steadily modified through the EIP process, short for Ethereum Improvement Proposals (EIPs). While EIPs can relate to any aspect of Ethereum, the EIPs focused on protocol development are what are known as “core.” Core proposals are the nuts and bolts of how Ethereum should be upgraded and, after such upgrades, how the Ethereum network technically works. For example, last September, a proposal was implemented when Ethereum switched to utilizing Proof of Stake from Proof of Work as a consensus mechanism in the protocol. That EIP can tell you today, in technical terms, how Ethereum Proof of Stake works.
So, who works on these proposals? Those involved with the EIPs that pertain to the base protocol itself are most commonly known as “protocol engineers” or “core developers.” Those terms can and are used interchangeably for the most part and are not official monikers but serve as shorthand for “this person works on protocol-focused EIPs.”
What is hard for most people to understand, especially those who have spent their entire lives in traditional, hierarchical organizations and/or who have no firsthand (or even academic) knowledge of computer programming, is that anyone with the technical know-how can become a core developer. How can there be no formalized vetting, certification, or initiation for core developers? Well, because there simply isn’t. There really is no prescribed process through which someone must proceed to rightfully call him or herself a core developer or do the work of a core developer. You simply choose to do this sort of work, and the descriptor of “core developer” generally applies. Whether that work ultimately impacts the protocol itself depends on the merit of the idea and whether the community coalesces around it.
Moreover, there’s no formal association or commitments among core developers. It’s an arrangement that is open-door, stay as long as you wish, and work on what you’d like. In fact, the very author of the Ethereum Yellow Paper, Gavin Wood, left Ethereum core development work to create an alternative protocol, all while Ethereum protocol development continued. The only condition of one’s involvement is that all work on the Ethereum protocol must be open-source, meaning that all source code must be susceptible to inspection, modification, and enhancement by anyone.
The chief goal of protocol development is to define the specification for how Ethereum should work. As a globally distributed computer network, adherence to core specifications allows the layers of Ethereum to interoperate and communicate with each other.
Collaboration among core protocol developers takes place largely in public, and there are currently two main forums that are open to all to observe. The first is the AllCoreDevs call, which is a weekly meeting held by the Ethereum development community to discuss technical issues and coordinate work on the Ethereum protocol. During the call, participants discuss potential protocol changes, testing and other related issues. These calls are live streamed and each individually saved on the EthereumProtocol YouTube channel. A list of every call, the agenda, and meeting notes can also be found publicly on the AllCoreDevs Meeting GitHub page. These calls have been taking place for nearly eight years.
The second is via technical discussions that largely occur on Eth R&D Discord server. This forum is open for all to discuss upcoming features, testing, and specifications.
There has been a funding body created called the Protocol Guild, that uses Ethereum-based smart contracts to help solve public goods funding. The protocol development community began to use Ethereum to help coordinate some of their funding precisely because core development is conducted by unaffiliated protocol developers and engineers crossing every populated continent and numbering in the hundreds. It is frankly a marvelous example of what blockchains can help accomplish that protocol development relies on the very technology it is working on to organize parties that don’t know each other or have exogenous reasons to trust each other.
Network Client Development
With fundamental rules of the system defined through the protocol specifications and the process to upgrade those specifications, you come to the first software layer built on top of those rules. This next layer of Ethereum is what is known as the “client” layer. Just as web browsers developed to serve the TCP/IP protocol, Ethereum clients serve to manifest the underlying specification into usable software.
A client is the program which is the building block of the computer network that constitutes the blockchain system. In simple terms, they keep track of network data and talk to each other to ensure they each agree as to what the state of the data is at any moment. You might have heard the term “node.” It is often used to describe a single instance of running a client program in support of the network.
Clients are not centrally conceived, coded, or operated. They are developed by independent teams. Some Ethereum clients are developed and maintained by private corporations, while others are developed and maintained by open source foundations, such as Hyperledger, which is owned by the Linux Foundation. There are currently five popular Ethereum consensus layer clients independently developed: Teku, Prysm, Lighthouse, Lodestar, and Nimbus. There are currently five popular Ethereum execution layer clients independently developed: Geth, Besu, Erigon, Nethermind, EthereumJS. There are likely more execution and consensus layer clients independently developed which are not accounted for here, and it is entirely foreseeable if not expected for there to be more as the network evolves.
Each client is different because they are developed independently, often in different programming languages. Some clients focus on different features to serve a particular end-user. The important thing is that, to be a functioning client, they all must follow the protocol specification. Failure to do so would cause a failure for a particular client to interoperate with other clients on the network, causing consensus failures (i.e. when different nodes cannot agree to the state of network data).
Far from the false depiction that Ethereum is dependent on a “small group of developers,” the diversity of clients described above demonstrates Ethereum’s core ethos of decentralization in actual practice. If any client stops development or suffers a bug, there are alternatives that can keep processing transactions and maintaining the ledger. And more importantly, there are no barriers to entry other than the technical know-how and hard work of developing one of these programs. Said simply, anyone can develop a client if they want to. You do not need someone else’s approval or permission, let alone any group of Ethereum developers.
How do these client development teams collaborate with other aspects of the Ethereum community? It’s important to note here that the flow of information and ideation within Ethereum’s development is more akin to a washing machine than a river: information flies back and forth across layers rather than only working downstream. As a result, Ethereum client teams (and the subsequent layers) can provide ideas and feedback to every other layer, including Layer 1 — the base protocol rules the clients eventually operate by.
Infrastructure Development
As we move away from the core protocol specification and client implementations of that specification, we begin to get closer to the end-users of these protocols — the application developers and the application users – and specifically how they make use of the network. Much like the internet depends on cloud providers and infrastructure service, Ethereum developers and users need infrastructure to connect with and communicate on the blockchain network. This infrastructure is not easy to build because Ethereum is a complex global network. Like all such networks, infrastructure providers have arisen to make accessing and utilizing that network easier for everyone else. The market for Ethereum infrastructure is vast, though we focus on two prominent aspects here, RPC providers and wallets.
In order to understand the state of the network and submit transactions for processing to it, one typically needs to run a client, keeping that client up to date and online. While anyone can run a client, to mitigate the need for this (for casual, infrequent, or mobile users at the very least), what is known as RPC (short for Remote Procedure Call) products have been developed. These RPC services allow any user to connect with a client and access the copy of the network data that client maintains, removing the need for that user to run a client locally.
The variety of RPC services less than 10 years from Ethereum’s genesis block is pretty impressive. There are over twenty major unaffiliated RPC services, including recent offerings by tech giants Google and Amazon and popular incumbents, Infura, Alchemy, QuickNode, Blockdaemon and many others. If you don’t want to trust a corporation to provide this service to you, there are many decentralized RPC upstarts, including POKT network. While technical in nature, the core service that RPC providers offer is not particularly specialized, so they are very interchangeable for nearly every user. If any RPC fails, or if a user in their discretion would like to choose a different RPC provider for any reason at all, a user can always designate another RPC service. There is always the additional option, of course, for any developer or user to run their own client if they do not wish to rely on a third-party RPC provider.
The second major piece of blockchain infrastructure one should understand is the “wallet.” In some sense, the term “wallet” is a misnomer, for it does not describe something that holds tokens. Instead, it is a software program akin to a web browser which can read blockchain data, including how tokens are allocated among all the public addresses across the system. It is also generally what is used to send specific instructions for processing, such as sending some number of tokens to another address.
Just like your typical web browser, wallets allow people who speak and think in everyday languages to seamlessly translate their request for information or their instruction into the native programming language, solidity, that the Ethereum network understands. This critical step is very often overlooked, but it is helpful to remember that, if a user attempted to submit instructions to Ethereum that said “send 1 ETH to Bob” in plain English, the Ethereum protocol would not know what to do with that message. Ethereum wallets have been developed to make the network accessible to people who do not have the time, expertise, or inclination to interact using a command line prompt that accepts only instructions in the solidity programming language.
Wallets not only are graphical user interfaces allowing an end user to generate network-compatible instructions, but also are the mechanism through which a user can control the process of encryption of their own data. With web2, you by and large rely on a third party to maintain on your behalf sensitive data and any authority you have over that data. Web3 is built the opposite way: the user herself maintains the sensitive data and authority over that data. Wallet software is generally how this is facilitated. It gives users a tool to encrypt, safeguard and use the private key associated with their blockchain public address, which is akin to a password the user needs to execute transactions on-chain. There are dozens of popular wallets all published by different teams including MetaMask, Safe, Coinbase Wallet. They take different approaches to how the user interface looks and feels, and to how the wallet safeguards the user’s private key. The diversity of approaches to the various factors affecting both user experience and security will likely continue to increase even while security best practices continue to mature.
Application Development
Now that we collectively understand the thousands of unrelated individuals who, in public, develop what’s described in the first three sections above, we can begin to address the part most users will interact with: Ethereum applications, most commonly referred to as “dapps” — short for decentralized applications. These are the web3 analog to your Netflix, Amazon, and Google, which themselves are all applications which ultimately make use of TCP/IP and related internet-era protocols and infrastructure. Dapps can be entirely Ethereum-based, or they can utilize Ethereum for some aspect of their functionality (e.g. a video game that is traditional, but has an Ethereum enabled marketplace for in-game items). Given that Ethereum is open and permissionless such that anyone can build and deploy applications to it, it is impossible to precisely measure the exact number of developers building applications on Ethereum. According to one statistic, we know the most popular Ethereum developer libraries were downloaded an excess of one and a half million times in the year 2022 alone. All signs point to the total number of developers interacting with Ethereum in some way to be in the millions and growing. These developers provide use cases for Ethereum. Ethereum adoption is increasing, and to-date Ethereum is utilized by Ethereum native organizations, such as those behind popular applications such as Uniswap and OpenSea, and is now being utilized more and more by non-Ethereum native companies for aspects of their business, ranging from consumer brands such as Porsche and Nike all the way to financial use cases from the European Investment Bank.
Application developers are also part of the Ethereum ideation washing machine, providing feature requests to others including to wallets, infrastructure providers, client teams, and protocol engineers as to features they would like to see in order to best provide useful applications to their user base.
A full understanding of Ethereum makes it clear that Ethereum isn’t reliant on a small group of developers, or a client, or an infrastructure service, or an app. It is reliant on the on-going efforts of the infinite many.