How open is too open?
On transparency, governance, and the challenge of keeping Ethereum alive
A political storm is brewing in Ethereum over the question of transparency. How are decisions about the protocol made? Who is responsible for those decisions? What obligation do those decision makers have to be transparent about the processes that go into that decision making, and how much of that process needs to be transparent?
This is my attempt to put things in a broader context and to explain what happened, why it matters, and where we should go from here.
What happened?
At the recent DevCon IV conference in Prague, a group of stakeholders held a series of meetings to discuss the Ethereum roadmap. One of the outcomes of these meetings was a proposal to invest more aggressively in the existing Ethereum mainnet infrastructure in parallel to the Ethereum 2.0 “Serenity” roadmap, an initiative dubbed “Ethereum 1.x” (#Eth1x for short). Several working groups were formed to further develop the proposal. I was present for several of these meetings. Here’s what happened from my perspective.
As Martin Köppelmann and Péter Szilágyi have pointed out, these “meetings” began as a series of ad hoc conversations on the sidelines of DevCon — which, I would argue, is one of the main purposes of an industry conference like DevCon: to get stakeholders who wouldn’t otherwise meet face-to-face into the same room to discuss topics they might not ordinarily discuss in their day-to-day work.
On Day One of DevCon I was chatting with some ConsenSys folks about an unrelated topic and they casually mentioned that they were planning to meet with EF research team member Danny Ryan later that day to discuss the Ethereum 2.0 roadmap and its implications for the new Pantheon client and its productization. They invited me to join and I accepted since the topic is relevant for our work on Ewasm. I invited Casey and Alex from the Ewasm team to join the meeting. There were around 14 attendees at this first meeting, at least half of whom are ConsenSys team members (the partial-but-mostly-complete list of attendees at each meeting is in the published notes).
The topic quickly turned from the Serenity roadmap to the health of the current Ethereum network and concerns that Péter raised about the growth of the state size. We had less than an hour to chat before the venue closed and we were forced to leave, but we decided to reconvene at the same time the following day.
On Day Two, around 20 people gathered (around half from ConsenSys) to continue the conversation. At this second meeting, Péter proposed a three-prong approach to address the concerns he had previously raised which the group regarded as a reasonable action plan and which has since become known as the “Ethereum 1.x” proposal — outlined in more detail below. Again we ran out of time, and again we decided to reconvene once more to continue the important conversation.
Finally, on the morning of the last day of DevCon, the group met one more time. It was largely the same group as the previous day, with a handful of subtractions and a handful of additions, approximately 25 people total. The focus of this meeting was concrete next steps: we established four working groups, three to explore the technical proposals on the table (more below) and one to collect data. We agreed that each working group would produce a proposal by Nov. 26, that we’d reconvene on a call on Nov. 30, that we’d aim to meet again in person around the Stanford Blockchain Conference in late January, and that we’d aim to publish a series of EIPs based on our research around that time. We set June 1, 2019 as a target date for getting some of these changes deployed on mainnet.
Feel free to share
The organizer of the meetings, Daniel Heyman, a program director at PegaSys, circulated a set of notes he took during the meetings, with the header “Please feel free to share.” The original intent was to continue the conversation, then to draw up a set of proposals and share those publicly for comment. Someone shared the notes with Coindesk who subsequently published an article about the series of meetings and the roadmap, and others who had not been at the meeting expressed frustration that the process had not been more inclusive and transparent.
We held a very productive follow-up call on Nov. 30 as planned. The meeting was open to all core developers but at the request of some participants it was not recorded or livestreamed, which also annoyed some people. Detailed, unattributed notes were released. The group still plans to meet in person in San Francisco at the end of January.
Open doors and closed doors
Who should’ve been in the room? Should we have somehow made an effort to include more people?
It’s my nature to be transparent and inclusive. There are many people I would’ve liked to have included in these meetings. Nevertheless I didn’t invite more for three reasons: 1. As far as I was concerned, the meeting was organized by someone else (ConsenSys), and I was an invited guest. It’s poor form to bring other people to an event that you, yourself, were invited to, without very good reason. (I brought Alex and Casey along because I cannot singlehandedly speak for the Ewasm team, but I didn’t broadcast that invitation more widely.) 2. DevCon is all about ad hoc, serendipitous encounters. I was invited to this meeting because I happened to be chatting with some ConsenSys folks earlier in the day about an unrelated topic. Many others who ended up in the room were there for other serendipitous reasons. Sometimes you have to let serendipity do its thing and I didn’t want to take away from anyone else’s DevCon experience by suggesting that they should attend yet another meeting, when the output of that meeting would be public anyway. 3. There quite literally wasn’t enough room for everyone. The spare breakout rooms at DevCon were designed for 10–15 people, and we had already brought in extra chairs to fit 20+.
I’ll come back to the topic of transparency in a moment, but first I want to spend a moment talking about “Ethereum 1.x” to put everything in context.
What is Ethereum 1.x and why does it matter?
A long time ago, the Ethereum roadmap was divided into four overarching phases: Frontier, Homestead, Metropolis, and Serenity. My personal interpretation of the phases are as follows. Frontier was an early proof of concept “alpha” release. Homestead could be thought of as “beta” Ethereum: mostly working and stable but lacking robust security, still rough around the edges, and feature-incomplete. Metropolis is “Ethereum 1.0”: secure and reasonably feature-complete but not yet scalable. Serenity, a.k.a. “Ethereum 2.0,” is the “promised land” for Ethereum: a network that can scale to handle an arbitrarily large number of transactions. There are rumors of a fabled “Ethereum 3.0” in the far future but the roadmap becomes fuzzy at this point. (The astute reader should note that, by this logic, Ethereum has not yet reached a 1.0 release. We’re around 0.9 today. As such, Ethereum should still be considered beta software. Caveat emptor.)
The second phase of Metropolis, dubbed Constantinople, has been finalized and tested, and is scheduled to be released in mid-January 2019. Meanwhile, most attention and energy for the past year or two has been focused on the Ethereum 2.0 “Serenity” roadmap. This is understandable since Serenity brings major changes to Ethereum, most notably proof of stake (Casper) and sharding.
For a long time, the consensus in the Ethereum community was that we should focus on Serenity, which was previously expected to begin deployment in 2018, and not attempt to make any breaking changes as part of Metropolis.
Where did that consensus emerge from? That’s hard to say, and it was before my time. While there are many more stakeholders today who have considerable sway, historically the roadmap was driven by a very small number of people. Figuring out how to adjust to this new, diverse, multi-stakeholder world is part of the central thrust of this article.
The situation changed in June when the decision was made to combine the hitherto distinct sharding and Casper workstreams (hence, “Shasper,” a tongue-in-cheek reference to Serenity). One result of this change is that the most aggressive estimates suggest Serenity won’t begin deployment until 2019.
This leads to two related but distinct challenges.
The technical challenge
Making Ethereum work today is extraordinarily challenging. Keeping up with Ethereum mainnet is a constantly, rapidly moving target. The state size continues to grow, requiring cleverer and cleverer engineering to maintain it. Commodity hardware struggles and, these days, mostly fails to keep up with the head of the chain.
At this point it is unclear where the trajectories of state growth, the number of active Ethereum nodes, the size and cost of commodity storage hardware, and the impact of scaling intersect. There is a fear among some core developers that state growth is getting out of hand and needs to be bounded in the not-too-distant future or the existing Ethereum chain may not live to see the light of Serenity’s day.
I can speak to the cost personally as I’ve been running a couple of full nodes for the past few months, and I just shut one down because I can no longer afford it. Here’s the breakdown of the AWS charges for running two nodes, one full and one an archival node, for one recent month. If the requirements and cost of running a node continue to exceed the rate at which commodity hardware improves and cheapens, Ethereum will collapse down to a small, relatively centralized core of nodes run by economically incentivized participants such as Infura and Etherscan. The total node count has declined from 30,000 at the start of 2018 to around 9,500 today and it continues to drop. There are multiple reasons for this decline, but the cost and difficulty of running a full node today is doubtless one, if not the main reason.
As the transaction volume and overall state size continue their steep ascent, pressure continues to mount on client software to keep up. At present there are only two production clients that are able to sync and reliably keep up with the mainnet, making up around 90% of all Ethereum nodes, and between them there are maybe ten core developers who are responsible for the bulk of the research and code required to make this possible. These developers understandably feel an enormous burden and an increasing degree of frustration.
[EDIT 2019–01–12: I’ll leave the original text intact, above, but I want to add a clarification on these numbers since I understand that they may have caused some confusion. The cost highlighted here is for running multiple nodes, including an archival node (for research purposes), which most people do not and never will need to do. The size of a pruned Ethereum full node, which still contains all chain data, is much smaller. I posted more specific numbers here: it looks like you can run a full node on AWS today for around $50–70 per month, and perhaps less on other cloud providers. As has been pointed out in the responses to this article, you can also run nodes very cheaply at home. However, my primary point remains: the Ethereum node count has fallen precipitously in recent months.]
The social challenge
The second challenge is more social than technical. As more and more attention and resources have been directed towards Ethereum 2.0, and as the road to Serenity has lengthened, many current Ethereum 1.0 teams have been left wondering what this means for them and their projects.
One of the biggest challenges in a permissionless ecosystem, where developers are free to work on whatever they find most interesting with little to no top-down oversight, is maintenance. If more core developers are interested in “building the future” by contributing to Serenity or layer two applications, who is responsible for maintaining the existing Ethereum mainnet, and how are those maintainers incentivized, socially as well as economically?
Ethereum core developers today are under enormous pressure and many feel overworked and under-appreciated. They fulfill an essential role in the community but get very little credit since the best engineering tends to be invisible. To cite an oft-used example, we remember the names of the explorers who sailed around the world and discovered new lands, such as Henry Hudson and James Cook, but by and large not the names of the engineers who made those journeys possible, such as John Harrison, the Yorkshire carpenter who spent decades perfecting a chronograph reliable enough to tell time at sea.
The “1.x or 2.0” question is also a serious challenge for teams such as Nimbus and Pantheon that are implementing new Ethereum clients from scratch. Should they work towards the existing Constantinople spec, or should they attempt to build Ethereum 2.0 today, a moving target? Should they build an EVM execution engine, or should they go straight to Ewasm?
The Ethereum 1.x proposal
All of this leads us to the Ethereum 1.x proposal, which represents a renewed effort to invest in the existing Ethereum 1.0 network and ensure that it can survive and thrive indefinitely, or as long as necessary until Ethereum 2.0 is ready to take its place. It addresses the technical challenge of unbounded state growth through pruning and the introduction of storage rent, and the decision to continue investing in Ethereum 1.x goes a long way towards addressing the social concerns as well.
Casey Detrio already shared a great writeup of the technical details of the proposal, so I won’t repeat them here. The four working groups have all published their proposals, which are open for discussion on the Fellowship of Ethereum Magicians forum.
It’s important to note that Ethereum 1.x is not a monolithic plan so much as a bundle of disparate-but-somewhat-related proposals to improve Ethereum today while waiting for Serenity. The most aggressive estimates suggest that Ethereum 1.x could theoretically achieve a dramatic increase in throughput through a combination of a reduced uncle rate, state pruning, parallelization, Ewasm, and several other ideas, although in practice it’s likely that such an increase would be limited to 1.5–5x to limit sync time, state growth, and the effects of centralization, to have a safety valve for the next Cryptokitties, and due to fundamental I/O limits.
Why didn’t we attempt to scale Ethereum 1.x previously? Many of these ideas are not new and have been around as long as Serenity, if not longer. My personal belief is that it’s a combination of three factors: 1. Until very recently, Ethereum was a “science experiment” and no one was really using it anyway, so scaling simply wasn’t a question. 2. Until very recently, it was easy to believe that Serenity would be a panacea that would solve all scaling problems, now and forever, and that it would be here soon enough that it didn’t make sense to invest in other scaling technologies. 3. State growth has recently become a serious issue, and any attempt to scale Ethereum today without a solution would only exacerbate the problem.
Two sides to the story
Back to the question of transparency, which was very much on our minds as we met in Prague. While everyone agreed that the output of the initiative would be a series of public EIPs, opinions differed on how much transparency was needed at each stage. Some felt that the entire process should be transparent from the start. Others felt that we should iterate a bit more to produce reasonable proposals and, in particular, that we should test our assumptions against real data and release proposed solutions alongside the problem statement, lest it be perceived as apocalyptic.
Some expressed a desire for a more private forum where core devs and researchers could communicate openly beyond the public spotlight, but Vitalik and others argued convincingly against any form of “institutionalized privacy” such as private calls or a private forum.
There are two sides to this story and I want to explain both.
Why transparency is good
This is sort of a no-brainer. Other things being equal, more transparency is always desirable because it minimizes corruption and maximizes the number of stakeholders whose interests are represented. Lack of transparency inevitably leads to backroom deals, corruption, distrust, and, in the extreme case, capture. Ethereum, by contrast, is a fundamentally open platform: all stakeholders in the platform, be they core developers, researchers, app developers, miners, exchanges, traders, hodlers, or users, have the right to observe and participate in governance. The EIP process is designed to facilitate this.
Policy aside, there’s something even deeper at play here: Ethereum simply cannot exist without the support of a broad contingent of stakeholders. Due to the open nature of the code and data, any sufficiently large subset of stakeholders has the power to fork Ethereum at any time. The fork is our superpower. It’s what sets us apart from default world governance and it’s a powerful coordination mechanism that acts as our safety valve of last resort: if all else fails, if the current governance mechanisms were ever to fail or become corrupt, any subset of the community would always have the option of forking and installing different governance mechanisms.
In fact, it’s even easier than coordinating a fork: it only requires inaction, e.g., the decision not to upgrade the software and participate in a sanctioned hard fork. Witness the birth of Ethereum Classic.
This mechanism is called exit or voice. If a sufficiently large set of stakeholders were to become disenfranchised or were to feel that their interests were not being represented — in other words, if they felt that they didn’t have a voice — they could choose to exit. This mechanism keeps the core developers honest. Transparency is key for enfranchisement.
Where transparency is challenging
As described under Social Challenge, above, Ethereum core developers today are under enormous pressure and many feel overworked and under-appreciated.
Many core developers feel antagonized by the media: they are often misquoted and their words taken out of context to push some particular agenda. They feel that they are overly scrutinized. What’s more, they feel that the ones doing the criticizing do not appreciate how much pressure they are under and in many cases are people who haven’t themselves added any value to the project. Like engineers everywhere, they want to be left alone to do good work in the way that they see fit.
There is growing frustration with how difficult it is to “get anything done” in Ethereum since even seemingly small changes can take months of back-and-forth political wrangling. This is, of course, by design and it’s one of Ethereum’s great strengths — that no individual or organization can unilaterally push through a protocol change without broad support. But software developers are not naturally inclined to enjoy politics.
Coordinating political dialogue among dozens of core developers and attempting to factor in the sentiment of thousands of others in the community, all the while feeling under attack by the media and the public, leads to a lot of stress and enormous cognitive burden. The Ethereum 1.x initiative and the meetings in Prague happened in response to this frustration. A subgroup of core developers came together out of love for Ethereum and a desire to improve the protocol. They wanted to put their heads together and write up a series of proposals that would be released to the public and flow into the existing, open EIP process.
We can turn to more mature industries for inspiration. The best designers include both a public, open component and a private, closed component in the design process. Design thinking is a well-understood process which involves successive stages that alternate between external, customer focus (empathize, define, test) and internal, private focus (ideate, prototype). I think a similar process of iterating between public (seeking to understand problems, testing proposed solutions, collecting feedback) and private (drawing up proposals, prototyping) is an effective way to develop strong technical proposals as well. It also offers developers some respite from the burden of operating under the public gaze.
The most important point to make is that no decisions were being made in these meetings, just discussion and coordination leading towards open proposals.
The bigger picture
I want to zoom out from Ethereum for a moment to explore the broader context to the questions we’re discussing here: transparency, radical participation, and technocracy. To be clear, none of these are new ideas and in many ways we are rehashing struggles that humans have been facing for millennia. We must recognize this and we should seek to learn from past examples and prior scholarship on these topics.
Ethereum governance today is mostly informal and it happens off-chain in the realm of humans and egos. The EIP process is the one regular, formal governance mechanism, and even it is rough around the edges: no one has ever formally defined “core dev” (here’s Hudson’s most recent takes on this: one two), nor been able to articulate precisely who is invited to the All Core Devs calls nor the precise magic needed to get an EIP brought up in the call. To be clear, I consider this a good thing and one of Ethereum’s greatest strengths since a more formalized governance mechanism risks capture, corruption, or losing the discretion of node operators who must proactively opt into forks.
However, there is a downside to highly informal governance mechanisms: they tend towards backroom deals and a lack of transparency. This is a classic challenge of governance known as the Tyranny of Structurelessness. Tl;dr version: there is no such thing as a lack of structure. In its absence, humans organize themselves in an ad hoc, social fashion and the result, lacking transparency or formal participation mechanisms, may be worse than a more structured approach to begin with.
The EIP process is our stopgap transparency mechanism but there are many, many conversations and much research leading up to EIPs that belongs in the public domain as well — and that would benefit from the input of a larger, more diverse body of stakeholders. For this reason, and given our informal system of governance, it is incumbent upon stakeholders such as core developers to act as transparently as possible at all times, and to choose transparency as a default, restricting it only when the circumstances call for it, and then only narrowly (such as via use of Chatham House, more on which in a moment).
Technocracy
I also want to briefly address the question of technocracy, since it came up as part of the Ethereum 1.x conversation. The argument goes something like this: The challenges (such as lack of rent) that Ethereum is facing today are highly technical and only a very small number of people in the world understand them well enough to make an informed decision about them. Therefore, it doesn’t matter what the uninformed public thinks. We technologists need to make an informed decision that’s in everybody’s best interest.
This question — technocracy vs. democracy — is as old as human civilization. Technocracy is appealing to those in charge but it’s extraordinarily dangerous. The rise in populism globally in recent years and the ongoing protests in France over the past few weeks are in many ways an expression of public anger at the perception of a distant elite making paternalistic, technocratic decisions on their behalf — including removing fuel subsidies, which hits frighteningly close to home for us.
Taken to the extreme, technocracy becomes extreme paternalism, authoritarianism, even apartheid (in the non-racial sense), as it involves dividing the community into two groups, those who (by some arbitrary criteria) “get it” and those who “don’t,” and allowing those who “get it” to make decisions on behalf of those who “don’t.”
It shouldn’t take too much reflection to realize that technocracy is in fact antithetical to the values of Ethereum and to the world we are trying to build — a world that enfranchises all humans everywhere, a permissionless world free of gatekeepers, a world where you can self-identify as a core developer (or any other class of stakeholder) if you so desire.
Humans are silly and fallible and sometimes we make decisions that are against our self-interest or the self-interest of our community, but we need to respect these decisions, too, and let people be free to make these mistakes. I believe that the voice of the community in Ethereum is sacrosanct and inviolable. Instead of lamenting poor decisions, and instead of building a technocracy, we should seek to educate and enfranchise a larger and larger portion of the community — including the press, which should help alleviate some of the concerns about misrepresentation.
And, if you disagree, you are also free to fork away to your own private technocratic paradise chain (Techthereum?). Exit or voice!
I’ll leave you with this powerful quote from Brave New World, and ask you to contemplate what it means for Ethereum:
‘But I don’t want comfort. I want God, I want poetry, I want real danger, I want freedom, I want goodness, I want sin.’
‘In fact,’ said Mustapha Mond, ‘you’re claiming the right to be unhappy.’
‘All right then,’ said the Savage defiantly, ‘I’m claiming the right to be unhappy.’
‘Not to mention the right to grow old and ugly and impotent; the right to have syphilis and cancer; the right to have too little to eat; the right to be lousy; the right to live in constant apprehension of what may happen tomorrow; the right to catch typhoid; the right to be tortured by unspeakable pains of every kind.’ There was a long silence.
‘I claim them all,’ said the Savage at last.
Keeping governance open
To wrap up the question of transparency, I’d like to share some lessons that I learned about open governance while organizing an unrelated event earlier this year.
#EIP0
We struggled mightily with the question of openness when we organized the #EIP0 summit, a non-technical governance initiative held in May 2018. On the one hand, we wanted to bring together a group of professional stakeholders to have extremely open and honest dialog about the philosophical, social, economic, and ethical challenges facing Ethereum governance, and about controversial topics such as fund recovery. On the other hand, we wanted to document and share our findings with the public and invite everyone, including the media, to ask questions. The guiding principle was that we wanted to be as open as possible while also ensuring that the participants had a safe space where they could speak openly and candidly about extremely sensitive, controversial topics.
We ended up settling on three compromises.
Chatham House Rule
Chatham House Rule is a very simple idea which says that everything discussed will be recorded and shared but that the notes will not be attributed to any particular speaker. I believe that it’s a reasonable compromise since it simultaneously achieves both goals: it allows speakers to speak very candidly without fear of retribution or of being misquoted while also maintaining transparency.
More and less open spaces
We had three or four different rooms at the #EIP0 venue. We set up recording and live-streaming in the main space only. Breakout sessions happened in other spaces under the Chatham House Rule. At the end of each breakout session we reconvened in the main space and the findings of the breakout session were shared with the larger group, as well as on the livestream. Participants agreed that what they shared in the breakout rooms was strictly under the Chatham House Rule, and that what they shared in the main room was public. Again, I feel strongly that this compromise allowed us to achieve both of our goals.
Public-private
Finally, while the event was invite-only, we nevertheless wanted to engage directly with the larger community to share our thoughts and findings and to answer questions. We accomplished this in several ways. We hosted a public meetup on the final evening of the event and invited reporters. At the public meetup, we shared our findings, hosted a panel, and took questions. We also did a live-streamed AMA session on Reddit for a portion of the event. Finally, we published all of our notes.
Whither to?
As I said before, I believe that openness in Ethereum is sacrosanct and inviolable. However, I also believe that core developers, like other members of the community, have a right to privacy and that it’s unrealistic and unfair to expect that 100% of their interactions should be subject to public scrutiny. While private conversations among core developers do not all need to be public, to some extent, this right to privacy is forfeit due to the nature of the Ethereum project: for instance, core developers must acknowledge and accept that our work product, e.g., our code, will be visible to and largely owned by the public domain. Folks who aren’t comfortable with this bargain should, as Greg Colvin put it, “find another project to work on.”
I propose that, as a community, we reach consensus on a set of ground rules that we can all respect.
First things first: the EIP process is and must always remain transparent. This means that the fortnightly All Core Devs calls where EIPs are discussed and decisions are made about hard forks must remain transparent: they will be live-streamed and recorded, and notes will be taken whenever possible. With this safeguard in place, we can discuss what leads up to the EIP process.
I believe that any set of community members should be free at any time to collaborate in private to produce an EIP or another proposal. These conversations need not be broadcast or recorded, since their output will be.
This still leaves the question of how to handle initiatives like Ethereum 1.x which fall somewhere in between these two: they do not involve making decisions and their output will be public, but they also involve a critical mass of stakeholders and core developers and involve meta-decisions such as where resources will be allocated and which topics will be researched for possible inclusion into an EIP. We must appreciate that defaults are powerful and that, by the time an EIP has been written with input from and the blessing of the Ethereum Foundation, ConsenSys, and Parity (to name but three stakeholders present in the Prague meetings), the default behavior for many others may be to accept it as a done deal.
Exactly where this “gray area” begins and ends is highly subjective but we should know it when we see it. Relevant factors include the number of people in the room, the number of organizations represented, the scope of the topics being discussed, whether and how many resources are being allocated, how far in advance the meeting was planned, etc. In this gray area, I believe the right thing to do is to announce the fact that the meeting is happening, share the list of attendees/stakeholders present, and share the notes from the meeting, although those notes may be unattributed. I commit to upholding this principle going forward and I invite you to do the same.
The role of the Magicians
In a few short months, the Fellowship of Ethereum Magicians has grown from a silly-sounding meme and a small group of nerds into a force to be reckoned with. It sent shivers down my spine seeing a room full of hundreds of eager participants at the most recent Council of Prague. Contributors have already formed working groups (dubbed “rings”) to explore tokens, signals, dev tools, education, and many more topics.
While I think many of us would like to stick our heads in the sand and believe that we are still a group of nerds who also happen to be friends, building a piece of technology together because it’s fun and challenging, it’s probably time to recognize that this thing that we’ve designed and built is out of our hands. We can’t control who builds on Ethereum, nor what they build, which is sort of the whole point in the first place, but it also means that reputations, private companies, other people’s data, and billions of dollars of value are being built on Ethereum today. To the extent that Ethereum ever works (however you want to define that), we need to be extraordinarily mindful of which governance and power structures we install in our community today to ensure that Ethereum matures into a platform that factors in the needs of, and becomes useful to, all sorts of people. The Magicians, along with initiatives such as #EIP0, have large role to play in this process.
My hope from the beginning has been that the Magicians are able to play an increasingly large, mature role in the technical governance of the Ethereum protocol and relieve some of the burden felt by the core devs. However, we are still figuring out that role and how it fits into existing governance mechanisms, formal and informal. We must also recognize that the Magicians initiative was created in true permissionless, grassroots fashion, without the buy-in or support of the majority of the core developers. Core developers are already inundated with inbound questions, requests, ideas, complaints, and communications more generally. As the Magicians initiative matures, it’s important that it understand these constraints and that it build open, trusted, bidirectional lines of communication with other stakeholders, but today this is very much a work in progress. As genuinely moving as it is to see 300 eager Magicians in a room debating Ethereum technology and wanting to contribute, for some core developers, it’s 300 more voices they’re somehow expected to listen to and be accountable to.
I helped organize a core R&D x EthMagicians Q&A panel at the Council of Prague as a first step, and I commit to working more closely with all stakeholders to foster better collaboration.
Diversity and inclusion
Last but absolutely not least, I want to address a topic that is near and dear to my heart, and one which I think is extraordinarily relevant as we consider the future of Ethereum. As I sat in the Ethereum 1.x discussions in Prague — shortly after attending the Society & Systems breakout session on Diversity & Inclusion — I made a point of noticing the other people in the room. Of 20–30 stakeholders present, there was only one woman in the room, and only one person of color. The demographics are similar throughout the broader core dev community.
There is so much more to be said about this topic and there’s no way I can do it justice in this space, nor can I, as a cisgender, privileged, white American male, hope to do it justice on my own, but the very least I can do is point to a lack of diversity when I see it and say, “This is wrong.”
My vision of Ethereum is that it matures into a platform for humans everywhere to build, transact, and participate in the technology and economy of the future. Despite our best intentions, there is simply no way that a room full of privileged, Western, white men can envision, design, or build such a platform without a much broader set of stakeholders.
There is a role here for the Ethereum Magicians, should they choose to accept it (time for a diversity ring?). There is a role for organizations such as Black Girls Code, which has been engaged in Ethereum events in locations such as Atlanta, Oakland, and at DevCon IV in Prague, and initiatives such as ConsenSys Social Impact, which developed this relationship.
Diversity and inclusion initiatives need to be active if they are to be effective. I commit to doing everything in my power to promote diversity and inclusion in Ethereum at every level, but I am not an expert and I need your help to do it.
Get involved!
If you’re interested in joining the conversation, now is a great time to help out with Ethereum governance. We are a permissionless, open, transparent community and welcome all voices. Listen to the fortnightly All Core Devs calls, participate in the EIP process, and join the conversation on Gitter. The Fellowship of Ethereum Magicians forum is an excellent place to get started!
Remember: there is no governing body in Ethereum. There is no “them.” Only us. We are all in this together. ✌️
Special thanks to Alexey Akhunov, Olivier Begassat, Joseph Chow, Greg Colvin, Daniel Heyman, Shahan Khatchadourian, Boris Mann, and Jamie Pitts for extremely helpful feedback, and to Alexey Akhunov and Fred Harrysson for helping me understand the various ways we might scale Ethereum 1.x.
