People tend to talk about decentralization (and centralization) of a blockchain network in binary terms, but I think it's more of a spectrum. This is important to recognize because it is extremely difficult for a blockchain network to reach complete decentralization.
Centralization, the opposite of Decentralization, exists when the concentration of control of an activity, or organization, or blockchain, is under a single authority. Centralization is natural because there is usually a necessary level of centralization required to bring a new activity, or organization, or blockchain into existence. The thing being created needs a group of prime movers to keep it moving, gaining momentum and growing a critical mass of interested outside parties (read “community members”) whose collective needs, interests, and efforts are sufficient to sustain the project independently .
While some measure of centralization may be required to start something new, reaching a tipping point where decentralization begins to become a requirement is a strong sign of growth.
In the context of blockchain I propose four pillars of decentralization:
1. Geographic: One jurisdiction controls the majority of nodes on the network
2. Programmatic: One entity controls the source code for the consensus algorithm
3. Economic: One entity controls the majority of the supply of tokens
4. Public: One group of people holds an inordinate amount of influence over the network
Geographic decentralization is what most people associate with the term 'decentralization', and it is the easiest and most beneficial to achieve. Geographic decentralization is achieved when nodes on a network are distributed across multiple jurisdictions, making it impossible for a single jurisdiction to bring down the network.
Programmatic decentralization is much more difficult in practice than most people think, or at least more difficult than most people make it sound when they talk about it. Programmatic decentralization is achieved when the ability to fix issues, add features, and define standards for the network exists outside of the group that created the network.
Economic decentralization has a strong dependency on whether the network's mainnet was launched with pre-mined tokens. Pre-mined tokens can serve a pivotal role in the creation of a blockchain by accelerating development and adoption of the network at the direction of the core group or entity that created the network. Economic decentralization is achieved when the mechanism that determines how the majority of the token supply is used exists outside of the core group or entity that created the network.
Public decentralization is a hallmark of growth in the community of people that exists around a blockchain network. When a blockchain is created it will primarily attract innovators and extreme early adopters. These groups will have the ability to interact with the core group of people who created the blockchain, which gives them a louder voice in the community than new members. Public decentralization is achieved when this group of innovators and early adopters cease to have the loudest voice in the community.
While it may be beneficial for a newly created blockchain to lean towards Geographic, Programmatic, Economic, and Public centralization, as the blockchain matures all four pillars should lean towards decentralization.
Growth necessitates decentralization.
XIP stands for XDC Network Improvement Proposal. An XIP is a design document providing information to the XDC community, or describing a new feature for the XDC Network or its processes or environment. A properly written XIP provides a concise technical specification of the feature and a rationale for the feature. The XIP author is responsible for building consensus within the community and documenting dissenting opinions.
XIPs are the primary mechanisms for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into the XDC Network. Because XIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
It is important to note that the XIP Process is strictly a process for creating and reaching consensus on accepting or rejecting proposals pertaining to the Network. XIPs are akin to the creation of blueprints; blueprints are created and validated before buildings are erected, and the existence of a blueprint does not require the existence of the building it defines. On the XDC Network the XDC core developers or stakeholders are responsible for reaching consensus on the acceptance or rejection of XIPs. Once accepted, if an XIP is implemented masternode operators cast their vote for acceptance or rejection of the XIP by deciding to either adopt and run the update on their node or not.
The XIP Process aims to increase Programmatic Decentralization of the XDC Network by enabling anyone to champion an update to the network. This type of improvement proposal process is a prerequisite for adoption of the XDC Network by industry. For example, without formal standards like XIP-8, which defines the XRC20 token, it would be possible for multiple projects building on the XDC Network to each choose their own implementation for XRC20. The existence of multiple XRC20 standards on the network would dramatically increase the complexity of adding support for XRC20 to network infrastructure and for cross-chain interoperability.
Championing an XIP
Parties involved in the process are the champion or XIP author, the XIP editors, and the XDC Core Developers. Before the champion begins writing a formal XIP, they should vet the idea. The champion should ask the XDC community first if an idea is original to avoid wasting time on something that will be rejected based on prior research. It is thus recommended that the champion open a discussion thread on XDC.dev, or the XDC Community Developer Discord to do this.
Once the idea has been vetted, the champion's next responsibility is to present (by means of an XIP) the idea to the reviewers and all interested parties and invite editors, developers, and the community to give feedback on the aforementioned channels (xdc.dev and/or the XDC Community Developer Discord). The champion should gauge whether the interest in the XIP is commensurate with both the work involved in implementing it and how many parties will have to conform to it. For example, the work required for implementing a Core XIP will be much greater than for an XRC and the XIP will need sufficient interest from the XDC Network client teams. Negative community feedback will be taken into consideration and may prevent the XIP from moving past the Draft stage.
If an XIP makes it out of Draft stage into Review, a meeting will be held via Discord Stage where promotion of the XIP to the Last Call stage will be discussed by XDC Core Developers. This meeting will be announced with an agenda via the creation of an issue on the PM repository in the XDC Community GitHub Organization. If consensus is reached by the XDC Core Developers during the meeting then the XIP will be promoted to Last Call stage, where it will sit for 14 days before being promoted to Final stage absent any change requests that would revert the XIP to Review.
While the entire XDC Community is encouraged to openly participate in the Idea and Draft stages of the XIP process it is left to the XDC Core Developers to reach consensus on promoting the XIP from Review to either Last Call or Withdrawn.
At this point it would be fair to ask, "Who are the XDC Core Developers?" and, "How do they reach consensus?" It is important to note that the answers to those questions are rooted in the decision to lean towards Public Decentralization.
Who are the XDC Core Developers? How is consensus reached?
While all XIP meetings are promoted across all social media channels, the XDC Core Developers are currently identified as people present on xdc.dev and/or the XDC Community Developer Discord. Borrowing from the Ethereum Magicians we can define XDC Core Developers as those who share this vision:
- The Goal: To keep the XDC Network the best it can technically be.
- The Mission: To nurture community consensus on the technical direction and specification of the XDC Network.
- The Work: Primarily, high-quality XDC Network Improvement Proposals (XIPs), accepted by consensus of the community.
We can further define XDC Core Developers as those who share these principles:
Open Process Any interested person can participate in the work, know what is being decided, and make his or her voice heard on the issue.
Individual Participation Membership is not formal. We are a group of individuals rather than organizations, companies, governments or interest groups.
Technical Responsibility XDC Core Developers accept responsibility for all aspects of the XDC Network protocol specification.
Technical Competence XDC Core Developers seek consensus on proposals where we have the necessary competence. XDC Core Developers are willing to listen to technically competent input from any source.
"Rough Consensus and Running Code" Consensus is not unanimity or majority vote. Rather, it is based on the combined technical judgement of our participants and our real-world experience in implementing and deploying our specifications.
For context, the term "Rough Consensus" was first used by the Internet Engineering Task Force (IETF) in describing its procedures for working groups meant to establish the standards for the internet. The means to establish rough consensus was described by the IETF as follows:
Working groups make decisions through a "rough consensus" process. IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail. (However, "dominance" is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement). Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached (IETF Working Group Guidelines and Procedures).
The phrase is often extended into the saying "rough consensus and running code", to make it clear that the IETF is interested in practical, working systems that can be quickly implemented. There is some debate as to whether running code leads to rough consensus or vice versa. There is also caution about whether percentages are a good measure for rough consensus. The IETF published a subsequent document pointing out that supporting percentage is less important for determining "rough consensus" than ensuring opposing views are addressed.
The XDC Network is growing and an increased importance must be placed on leaning the four pillars (Geographic Centralization, Programmatic Centralization, Economic Centralization, and Public Centralization) towards decentralization. The XIP process is pushing the pillar of Programmatic Centralization strongly in the direction of decentralization. The XIP process is a prerequisite for the continued adoption of the XDC Network by industry participants. In order for the XIP process to function we must also lean the pillar of Public Decentralization by adopting established principles and practices for reaching consensus that are rooted in technical competence and an unyielding desire to keep the XDC Network the best it can technically be.
I will also add that this process can change and be modified if the community wishes it. The whole purpose of this is to increase the ability of the many to make improvements to the network. This process and initiative is a great start in the right direction. Very good write up and explanation of the process and decentralization.
Thank you Lance, and you raise a great point. This whole process is outlined in XIP-1, which is a living XIP that can be forked and updated via pull request by anyone with ideas on how to improve the process.
I believe a real public blockchain network would act as a trust between counter-parties. But for that to happen, there needs to a a real decentralised community effort.
Use cases from Trade Finance, Payments and many others purely work on network effect and industry is looking at a real decentralised way of implementing these as these use cases run across borders.
We get a lot of developer requests and industry queries and after initial years of working with them. I feel now they do understand decentralisation and a public network better. This initiative would allow Industry partners to present use cases and improvements with XIPs and the community will make it happen.
Frankly I see limitless possibilities to this initiative!
Hi Jon, thanks for sharing your ideas on decentralization.
I partially agree, everything regarding decentralization is on point. But i partially agree with the "rough consensus", it is good for small dev teams working on code improvements/new implementations, but brings up some questions for the XIP voting. The Ethereum Magicians is a Community of Individuals collaborating on improving the Ethereum Protocol. ethereum-magicians.org/. Basically a pre-discussion forum to fix and improve possible implementation ideas.
Some questions arise with this consensus, who is the working group and who decides that? "It is up to the Chair to determine if rough consensus has been reached", In XDC Network's case, who would determine if the rough consensus has been reached?
"Dominant view of the working group shall prevail" - The developers bringing up the new implementations have generally good reasons for bringing it up, with logical cause, each one participating in the vote will agree. I don't see a need to manifest a consensus in that a "working group" view should prevail, while its "dominant view" is bound to as determined by its chairperson, which sounds centralized.
The best ideas and implementations will prevail in an open and decentralized network.
"The IETF published a subsequent document pointing out that supporting percentage is less important for determining "rough consensus" than ensuring opposing views are addressed." This is not clear to me with how many and what kind of votes (the agreement) the vote will be accepted and with how many or what kind of votes it won't be accepted. In my opinion, it is not clear enough at this stage.
For XDC - simple majority vote or 2/3 vote should be implemented of those participating in the XIP vote. If 20 Participate in the Vote, 11 should be agreeing.
Furthermore, we should expand the eligible Voters for the XIP process and include Masternode holders. As those are keeping the network up and need to upgrade or decline a software upgrade. Which could be a cause for potential hard fork/chain split. To prevent this, integrating the MN holders in the voting process is crucial in my opinion.
This is a different case than Ethereum, as XDC Network has a limited number of core Masternode holders.
As implementations, be it technical or else, have not just an effect on the tech side but bring various more changes to the whole network. To ensure any changes to XDC Network are secure and widely supported by the community, it is important to include MN.
This has been proven to be a real good and working process. In the long run, it will bring credibility to the process, and an ability for the existing expert technical members to steer governance decisions in a way that can be beneficial for the network as a whole and all of its participants.
One last point I want to mention, maybe we can even call it the 5.th pillar of decentralization is transparency. Session recordings, voting and outcome need to be easily accessible for the whole community. Transparency in all aspects of this process is key to include the community in the process.
Great write up. Thought provoking. Fascinating breakdown.
This post and process outline is a great service to the XDC Community.