Decentralization and the XIP Process

Decentralization

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

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.

Growth

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 Process

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.

Programmatic Decentralization

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.

Summary

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.