From the last Ewasm team sprint. Core developers are only allowed to code in font size 6.

While the exact definition of core developer is slightly contentious, the term typically refers to a developer that works on layer one blockchain technology such as the protocol itself or on the underlying cryptography, P2P technology, etc. In the case of Ethereum, in addition to the various client implementations, this means base layer infrastructure such as scaling technology (sharding, Plasma, etc.), protocols such as Whisper and Swarm and, in my case, the Ethereum virtual machine.

I’ve noticed that some community members tend to attach a certain degree of cachet and mystique to the term “core developer.” I suspect that it has something to do with cognitive biases such as confirmation bias and with human tendencies such as apophenia, the tendency to see patterns and connections where there are none. Together these tendencies cause some people to view core developers as somehow different, special, or all-powerful — and in the extreme case, to imagine that they comprise some sort of secret cabal that makes backroom decisions affecting the protocol. As nothing could be further from the truth, I’d like to attempt to set the record straight and demystify the occupation.

Note that I’m writing about my own experience with Ethereum. I cannot speak for core developers of Bitcoin or other platforms but I suspect much of the same applies.

How I became a core developer

I have an undergraduate degree in computer science and I’ve worked as a professional software developer for about 12 years. I’ve worked at both the top and the bottom of the stack: from quantitative data analysis at a hedge fund to DevOps (provisioning databases, VMs and containers, mail and DNS servers, etc.) to full-stack web and mobile apps. I cofounded a couple of tech startups but quit the last one to focus full-time on Ethereum after discovering the platform last year.

The Ewasm team hacks at ETHBuenosAires last month

I made some open source contributions to several projects before focusing on Ewasm, Ethereum-flavored WebAssembly, an initiative to replace the EVM (Ethereum Virtual Machine) with an upgraded, modern execution engine built on the WebAssembly VM. The project excites me because I’ve always been interested in compilers and systems though I haven’t had a chance to touch anything so low-level since college. I also want to understand Ethereum as deeply and thoroughly as possible and I believe in starting at the bottom of the stack and working my way up — and you don’t get any lower than assembly and virtual machines 🤓. Of course, the team matters a lot too. I met several members of the Ewasm team at DevCon III last year and joined one of the team’s sprints earlier this year. The rest is history.

What I actually do

A lot of the Ewasm infrastructure already existed when I joined the team, so I’ve helped write tests and detect and fix bugs to prepare the technology for prime time. I spend most of my time in the weeds, writing a lot of WAST (WebAssembly text) by hand, such as this test. I also work on JavaScript tools such as evm2wasm, a transpiler that allows legacy EVM bytecode to run in the Ewasm engine, and on Hera, the C++ “glue code” that connects the cpp-ethereum client to the Ewasm backend.

My typical dev environment: vim inside of tmux running on iTerm2 with zsh on my trusty, ancient Macbook Pro

As the technology has matured and become more stable and as we approach the launch of the public Ewasm testnet I’ve begun to think and work at a slightly higher level. Thanks to my years as a full-stack app developer I’m a big fan of JavaScript and I have a dream of writing Ethereum contracts in JavaScript or in something resembling it such as TypeScript. I took one step towards that goal by finishing my first working proof of concept contract written in AssemblyScript and will continue working on this toolchain and documentation.

Ewasm community meetup in Lisbon during our first team sprint, January 2018

In addition to coding, my job involves traveling to attend conferences to share our work and learn what other teams are working on, meeting my remote team for in-person sprints, and participating in Ethereum governance initiatives such as the all core devs calls, the Fellowship of Ethereum Magicians and #EIP0. I hope that it will increasingly include writing about the experience, like this, and helping recruit more core developers.

Governance, power and responsibility

Let me immediately dispel the myth that core developers have some undue influence on the Ethereum protocol. While much of Ethereum governance remains undocumented and informal, the EIP (Ethereum Improvement Proposal) process is well documented and reasonably institutionalized. Here’s the extremely short version: anyone is welcome to submit a proposal (as a PR against ethereum/EIPs) at any time, and proposals which are technically sound will be merged as Drafts (proposals which are not deemed technically sound may need to be amended or improved before being merged). This does not mean that the proposal will definitely be implemented, it just means that according to the judgment of the EIP reviewers the proposal is technically sound. After this, the proposal may be brought up on an all core devs call, the core developers may decide to approve and implement the proposal, and users may choose to download and run the updated client software with the proposal switched on.

Given the highly technical nature of this process, core developers play an important role in vetting proposals, making sure they are technically sound, and discussing implementation details and the implications of a given proposal. This process happens entirely in the open. All EIPs, their current status, and their discussion threads are visible in the ethereum/EIPs repository. Many proposals are debated publicly on the Fellowship of Ethereum Magicians forum. The recordings and notes from each core devs call are also available in ethereum/pm.

Informal Ethereum governance in action at EthCC, Paris, March 2018

This process has worked reasonably well up to now. As the importance of Ethereum increases and the number of people, businesses, and applications relying on the network increase, there will doubtless be more contentious issues involving ethical, philosophical, economic, and legal questions (I wrote about one such issue, and I discuss the topic in this video). Core developers are not “in charge of” Ethereum in any legal sense but they are stewards in the sense that they collectively have a veto over technical proposals. This responsibility will grow and become more complex as Ethereum matures and there is an ongoing dialog about the evolving role of core developers.

How to become a core developer

Let me be very upfront about one thing: being a core developer is not glamorous and it’s not everyone’s cup of tea. You’re building extremely low-level infrastructure that the average person will never notice nor understand. (Good luck explaining to your parents and friends what you actually do.) The pay kinda sucks, other people will get rich and famous on the back of your work, you likely won’t receive any credit, and you kind of have to be okay with that. We do very little interface work, and while DX (developer experience) is extremely important, we don’t get much opportunity to think about UX (user experience) since end users will never interact directly with our software. It’s the sort of job that requires a good deal of intrinsic motivation. If solving complex, fundamental problems, writing good, maintainable code, and building a platform that millions of people may someday use sounds like your idea of fun, that’s a good start.

There is no secret and no trick to becoming a core developer. First things first, it helps enormously to both understand and love computer science and software engineering. Core developers get to work on important, fascinating, fundamental problems of computer science such as designing better virtual machines, scaling, cryptography, and peer to peer protocols. Software engineering best practices such as comprehensive design, testing, and documentation are absolutely essential to writing bulletproof code that will become the future base layer of Ethereum.

A computer science degree is not strictly required — there is, after all, no formal job application process — but experience with and understanding of low-level concepts such as memory management, networking, multithreading, etc. as well as familiarity with software design patterns help enormously.

If you have the basics in place, find an existing open source project to contribute to. There is a large number of Ethereum clients, some more and some less mature, including geth, Parity, cpp-ethereum, Trinity, ethereumJ, ethereumjs, and nimbus. There are other core projects such as Casper, sharding, geth-sharding, and Ewasm. To the best of my knowledge, all of these projects are fully open source and welcome new contributors. What’s more, thanks to the emergence of projects such as Gitcoin you can earn bounties for many of these contributions.

Each project has a slightly different contribution workflow and different requirements that contributors must follow. Make sure you review and understand these guidelines before attempting to contribute. Look for a README.md (example) or CONTRIBUTING.md file (example) in the repository root for information on these guidelines, and see this fantastic collection of guidelines put together by Piper Merriam and the EF Python team as an example. Don’t be shy about asking questions if anything is unclear! In addition to communicating via Github issues and pull requests, most of these projects and communities have very active Gitter or Riot channels where you can seek help.

Issues marked Good First Issue in the py-evm repository

Once you’ve reviewed the contributor guidelines, start by looking for an open issue marked “Good First Issue” such as these issues in the py-evm (Trinity) repository or these “easy” tasks in Parity.

Many of these projects and organizations are also hiring full-time developers and tend to hire people who have already contributed on GitHub, so that’s by far the best way to get started.

Finally, keep in mind that, rather than contributing to an existing project, you can also build your own core stack, especially if you disagree with some aspect of the existing stack or simply want to experiment with a different stack. Recent examples of projects of this nature include ConsenSys’s PegaSys, the Mana client, nimbus, and Prysmatic Labs.

We need many, many more core developers. Ethereum may seem reasonably mature but in fact there are only around 50–100 Ethereum core developers in the world today building this essential layer one technology, supporting a community of application developers that’s 100x larger and a user base that’s at least 1000x larger. We aim to build a system for billions of humans, so we need people from all walks of life to contribute. Join the conversation in the AllCoreDevs channel. You can also find me and the rest of the Ewasm team on Gitter if you’re interested in contributing to the Ewasm project. We’re still in the process of improving our documentation and preparing to work with a broader community of contributors, so apologies as we get our house in order.

About the author: Lane Rettig is an independent Ethereum core developer and a member of the Ewasm team. He participates in and helps organize the Ethereum All Core Devs meetings. He also founded and helps run Crypto NYC, a Manhattan-based co-working space and community that strives to make blockchain and other distributed consensus technology accessible to all humans. Find him on Twitter at @lrettig.

Special thanks to Casey Detrio, Erich Grant, Fredrik Harryson and Afri Schoeden for valuable feedback on this article.