The Big Picture of Ethereum Governance
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from
Ethereum enthusiasts (ID: ethfans)
Ethereum enthusiasts (ID: ethfans)
, Author: Boris Mann, translation: A Jian, reprinted by Odaily with authorization.
In this article, I try to summarize the different layers of Ethereum's governance approach. The core concept was published on the Ethereum Magicians forum and sparked some discussion.
If you want to know a little bit about my background, you can check out my entry into the Ethereum community at the end of this article. I'm still new to the Ethereum community, but I already have a lot of open source collaboration experience, including helping to form the Drupal Association to support the Drupal CMS.
The term "Ethereum" has several connotations:
The Ethereum Foundation, also known as "Stiftung Ethereum", is a foundation based in Switzerland that was established with the mission of running crowdfunding and launching the network. The foundation also holds the ethereum trademark. They also manage a lot of infrastructure for the community, and have hired/outsourced multiple teams to develop Ethereum's main software, from testing frameworks to Geth clients, and more. Now, the foundation also hires or invests researchers and teams to engage in important cryptography/blockchain research, currently focusing on ETH2 research1. The Foundation also hosts an annual "official" developer conference (aka "DevCon"). But the Ethereum Foundation does not control the technical direction of the network. (Author's note 1: Thanks to Tim Beiko for suggesting that research is also a fundamental activity of EF. It is a very interesting discussion to clearly explain how the whole community sees the nature and work of EF. But it is not the core of this article. )
The Ethereum main network is also a global public blockchain, which is jointly operated by thousands of nodes around the world. The transaction processing function and security are provided by the "miners" who run the proof-of-work algorithm, and the miners can get block rewards in return . The core cryptocurrency circulating on the Ethereum blockchain is often referred to as "ETH". This currency can be used to pay transaction and contract execution fees, and it is also a recognized value in the network. Both the chain ID and the network ID of the Ethereum mainnet are 1 2. (Author's Note 2: For information on all blockchains running the Ethereum protocol and their corresponding IDs, see chainid.network. I also help maintain this site.)
Ethereum is also a community, referring to groups that want to do things on top of the Ethereum protocol, distributed applications on the Ethereum blockchain, and related decentralized network protocols. Everyone's development is mainly concentrated on the main network, but as time goes by, more and more people are developing side chains, Layer-2 protocols, and so on.
Now that we have some basic concepts, let's look at the hierarchy of governance. The order listed below is somewhat crude, but higher levels do cycle back to lower levels.
secondary title
open source collaboration
"Open source" is actually an acronym, and it also has many meanings: it can refer to a nature of licensing, a way of working, or a philosophy; Its meaning is discussed in the article. The "Open-based Co-production of Peers" I wrote later uses a more detailed definition, using open source to refer to the management of computer code that allows open source use: code base administrators, unresolved issues (issues), code participation requests (pull request), replication (fork), and a global community of users and contributors.
There is a list of ETH1 clients on the Ethereum Wiki page3 - as you can see, most of them today are managed by the Ethereum Foundation, although in practice it is the individual teams and their contributors who manage the projects themselves. are independent of each other, although everyone is paid by the Ethereum Foundation (EF), whether employed or outsourced. Two exceptions are the Parity Ethereum client (the project is controlled by the company Parity Technologies) and the PegaSys Pantheon client (controlled by the company ConsesnSys). These two clients are also considered "main" clients, since the project is still active and the software is used to run nodes and connect to the mainnet. A Nimbus client for Status is also in development, and we can see the diversity of code control is increasing. An early list of ETH2 beacon chain implementations also highlights this. (Author's Note 3: I'm helping maintain this page, but everything is open for editing, and the code is maintained by Virgil Griffith @virgilgr, who works in the research department of the Ethereum Foundation.) (Translator's Note: Author's article Written March 2019. Now Parity Technologies has abandoned the Parity client project and Parity Ethereum has turned into the Open Ethereum project.)
All Ethereum client software is managed as an open source project, with varying numbers of contributors contributing code. When we say "managed as an open source project", we mean that bugs or feature requests expressed as issues can be resolved and fulfilled by anyone, and anyone can use code contribution requests to submit code fixes and new features , which are then managed by a group of administrators. Admins are those who have write access to the codebase and/or can help manage the issue queue. Administrators may be paid by an organization or they may be volunteers.
My suggestion in this regard is to move to the Apache2 license, as it is very permissive, compatible with commercial organisations, and includes patent protection.
In many ways, those of us who have been involved in open source collaboration for a long time have "won"—Microsoft bought GitHub and committed to being the most open company in the world—but at the same time, many of the core norms of open source collaboration are no longer recognized. Mention, even developers are no exception. I think we can do more, and I really hope to guide more new developers to become engineers of the Ethereum core technology stack, and at the same time let the ETH2 technology stack train the next generation of technical experts.
To sum up, if you are a businessman and do not engage in technology, then it is critical to understand a series of norms and processes surrounding open source software development. Open source software not only underpins almost all blockchain technologies, but is also the foundation of most software running in the world today.
secondary title
Governance of Protocol Standards
The Ethereum Improvement Proposal (EIP) process is the process we use to propose and reach consensus on standards. Broadly speaking, this is the governance of protocol standards. These standards may be applied at the Ethereum software level (i.e. requiring some changes in clients implementing interoperable software), or at the network level. This network layer refers to both the Ethereum main network and other blockchains running the Ethereum protocol. Other networks may follow the Ethereum mainnet to incorporate and accept the EIP (which is most of the time now), or they may go through their own upgrade process.
Let's think of the EIP process for a moment as designing standards primarily for the Ethereum mainnet. As for whether the participant is a developer or not, and whether the proposal will be deployed on the mainnet, that’s another matter.
……
You can see all published EIPs at eips.ethereum.org. EIP-1 specifies the core layer EIP (changes that will change the network consensus rules and require everyone's unanimous consent to deploy) and other types of EIP submission and review processes.
……
There is also a standard in the EIP library for the application layer, also called "Ethereum Request for Comment (ERC)". These ERCs may be split into an independent code base and process (I prefer this form myself).
I think the EIP process is working very well and it's improving. Of course, the more education (especially for technical experts who can add value to the network), the better.
The purpose of the EIP process is standardization -- that is, to ensure that the same software can be developed by multiple groups, and that everyone's software is interoperable. And Ethereum has multiple clients, which is very critical. In fact, this is much more important than the license to use the software. If there is a good standard, anyone can implement it and know that implementations are interoperable.
There is a movement just beginning to have dedicated administrators and codebases for different parts of the ethereum tech stack — EVM, devp2p, JSON-RPC interface, and so on. This means that more collaborators can work together, even across the boundaries of the Ethereum mainnet, to improve and ensure the interoperability of Ethereum.
secondary title
Core Developer Collaboration
AllCoreDev videoconferencing is a way for developers of major client implementations to collaborate. Video conferences are held every two weeks and are moderated by Hudson Jamieson, a full-time employee of the Ethereum Foundation.
Similarly, the agenda of the core developer meeting is also published as an issue in a GitHub code repository ethereum/PM. Anyone can comment on the issue page to indicate that they have time to attend, can ask a question, or share an opinion.
Overall, the entire process is designed to be technology-focused. Things that the core developers consider are the technical soundness of a particular EIP, but also certain "network health" properties in the larger context. Of course, every technical decision has some extra-technical impact, and this ambiguity is at the root of many problems.
After talking to the various client teams, the feedback I got was that code implementation really didn't take much time; further progress was limited by non-technical decisions and roadmap disputes.
What process does the core developer use to make decisions? Well, kind of like a "live" version of the EIP process, except there's a real-time discussion every two weeks. I mean, IETF (Internet Engineering Task Force) style, rough consensus and working code, is the heart of the process. Recent discussions have pointed to the need for some additional formality - requiring consensus and documenting discussions - perhaps to remove uncertainty.
A useful tool for understanding the EIP and core developer review process is the flowchart drawn by Dan Finlay. I just shot it here:
secondary title
network governance
I use the term "network governance" to refer to governance decisions that are made throughout the Ethereum ecosystem. This is much bigger than "just a technical decision".
All of the approaches above—from open source collaboration, to protocol standards governance, to core developer collaboration—are often only about technology. If you don't write code, raise money, and hire developers, there's very little you can do.
So what exactly is the Ethereum network responsible for stakeholder engagement? What can we do if "we" want wider stakeholder engagement?
Notice, what is "we"? I myself would define "we" as a broad group of people who consider themselves part of the Ethereum ecosystem and care about the functioning and further evolution of this group. So far, all interaction methods have been formed on the basis of voluntary participation, self-set goals and self-achievement (this is very natural in the open source community). As far as I know, Hudson Jamieson is the only full-time paid person in the entire ecosystem who contributes to community organizations. Even so, most of his time is spent collaborating with the core developers.
Many recent controversies revolve around how to understand the position of network governance in the governance process, how to implement network governance, how to participate/how to make voices heard, and so on.
One view is that "stakeholders should organize themselves". I believe this, but I also believe that we should welcome everyone to use the infrastructure and channels that already exist.
I don't think it makes sense to put network governance ahead of protocol standards or core developer collaboration. They are more like a synchronous process. We, as a technical community, could do a better job of pointing out the substance of these upcoming core EIPs, which the broader stakeholder group can then inform themselves. ...
As far as I can see, network governance is mainly triggered by raising doubts in the consciousness of core developers. Because core developers care about the health of the network — including not wanting to trigger a contentious hard fork — they can speak out and break consensus. However, this may be mainly due to the fact that the relevant EIP has not yet been implemented: it will be more difficult to say "yes" at this time.
Nodes running client software
……
Ethereum Roadmap
Ultimately, the decentralization of the blockchain network depends on everyone being able to run nodes, and anyone being able to choose different versions of the open source client software to run, including being able to copy the client code base to develop their own client, or Running an older and patched version than most people.
secondary title
Ethereum Roadmap
Another key outside of the EIP is Ethereum's roadmap. This question was first brought up at the Ethereum Magicians conference in Berlin, and there are a growing number of events and online meetings discussing the long-term roadmap.
No one is "in full control" of the Ethereum roadmap, as it is repeatedly assembled from all previous projects.
However, it is worth highlighting the so-called "ETH 1.x" and "ETH 2".
The next version of the Ethereum network, abbreviated as ETH2, hopes to be entirely based on the proof-of-stake protocol (rather than the miners running the proof-of-work algorithm); A network that provides a much greater overall throughput of the network. ETH2 is still primarily driven by researchers funded by the Ethereum Foundation. The preliminary implementation plan is divided into three phases, which have not been written into the EIP, and now the technical specifications are produced mainly by the collaboration of implementers and researchers.
A fundamental upcoming discussion is: should we plan more small hard forks, or fewer but larger hard forks. Now, everyone seems to prefer frequent but small forks.
How to participate?
For more information, see the Ethereum Wiki roadmap page.
secondary title
How to participate?
If you read all of the above, you might want to get involved in the Ethereum community.
I spend a lot of time on the Ethereum Magician forum, the nice thing about the forum is that there are long paragraphs and sub-post discussions. The forum has also become a hub for EIP discussions - as GitHub's Issue page is not as accessible and does not support threaded discussions.
