Developers Forum for XinFin XDC Network: Jon McBee

Please Remove the Bot Accounts from xdc.dev

Jon McBee — Thu, 12 Jan 2023 18:44:50 +0000

This post is for discussion around a proposal I am creating using the new voting dApp. The proposal advocates for the removal of bot accounts that have begun posting on xdc.dev as of January 9, 2023. I believe that these bot accounts detract from the value of xdc.dev by adding more noise than signal to the forum.

Here is an example of a bot post: https://www.xdc.dev/xdc_technology_bot/exploring-the-benefits-of-xdc-networks-open-source-decentralized-global-blockchain-2604

Please use this post as host for discussion around the proposal.

XDC Voting dApp Preview

Jon McBee — Tue, 06 Dec 2022 18:18:00 +0000

XDC Community is working on an on-chain voting platform as mentioned in the proposal for funding. The voting dApp is under active development, and in order to keep cost and dev time at a minimum we have opted to focus on delivering an MVP. Taking the MVP approach has a built in benefit that once the dApp is deployed we can all use it to propose and vote on new features for the dApp.

As an introduction to the voting dApp I have created a short video stepping through a Figma created by the development team. You can see that video here. My goal with this post is to introduce you to the dApp via the video, and then use the comments section for discussion and Q&A.

In the video linked above you will see that we have introduced the notion of a "vote toll", I expect this feature to be a point of discussion with the community. The plan is for the proposal creator to have the ability to set the "vote toll" at between 0 and 1,000,000 XDC. Obviously a higher "vote toll" discourages bad actors from gaming the system (In the future we can introduce the concepts of white and black listing, and I have ideas for how to securely use this tool for masternode owner voting). The "vote toll" XDC will go to a wallet where it will accumulate and be used to fund future work on the voting dApp. The intent is for this to be transparent and act as a way to make the voting dApp self-sustainable.

The last thing I will mention, in the interest of transparency, the creation of the voting dApp MVP is being entirely funded by me (Jon McBee) with my personal funds. My goal was to bootstrap a starting point that could then be further developed using "vote toll" and XDC Community funds at the direction of the community.

I encourage and welcome questions, comments, and concerns in the comments.

Proposal for Interface Query Standard XIP

Jon McBee — Fri, 18 Nov 2022 21:33:44 +0000

This proposed XIP defines a standard to publish and detect what interfaces a smart contract implements. In smart contract development, a standard called EIP-165 often appears when contract to contract interaction is needed. This XIP proposes a standard that duplicates the functionality of EIP-165.

Since there is no clear way to find what functions are implemented in a contract, this XIP proposes a standard method to define and query interfaces in a contract. For example, if we define an interface identifier of XIP-8, we can easily determine a contract implements XIP-8 or not.

If a contract follows this standard, it will publish what interfaces it supports. Then, other contracts can utilize the published information to avoid calling unsupported functions.

How Interface Identifiers are Defined

An interface identifier is a combination of function selectors of a contract.
A function selector is four bytes of keccak256 hash of the signature of a function
(e.g., bytes4(keccak256('supportsInterface(bytes4)'))).
The signature is defined as the canonical expression of the basic prototype without parameter names and the return type.

We define the interface identifier as the XOR of all function selectors in the interface. This code example below shows how to calculate an interface identifier:

pragma solidity ^0.4.24;
interface Solidity101 {
    function hello() external pure;
    function world(int) external pure;
}
contract Selector {
    function calculateSelector() public pure returns (bytes4) {
        Solidity101 i;
        return i.hello.selector ^ i.world.selector;
    }
}

Note: interfaces do not permit optional functions, therefore, the interface identifier will not include them.

How a Contract Publishes the Interfaces it Implements

A contract that is compliant with this XIP shall implement the following interface (referred as InterfaceIdentifier.sol):

pragma solidity ^0.4.24;
interface InterfaceIdentifier {
    /// @notice Query if a contract implements an interface
    /// @param interfaceID The interface identifier, as defined in this XIP.
    /// @dev Interface identifier is defined in this XIP. This function
    ///  uses less than 30,000 gas.
    /// @return `true` if the contract implements `interfaceID` and
    ///  `interfaceID` is not 0xffffffff, `false` otherwise.
    function supportsInterface(bytes4 interfaceID) external view returns (bool);
}

The interface identifier for this interface is 0x01ffc9a7.
You can calculate this by running bytes4(keccak256('supportsInterface(bytes4)')); or using the Selector contract above.

The implementing contract will have a supportsInterface function, and it returns:

true when interfaceID is 0x01ffc9a7 (supportsInterface itself)
false when interfaceID is 0xffffffff
true for interfaceID this contract implements
false for any other interfaceID

This function must return a bool and use at most 30,000 gas.

Implementation note: there are several logical ways to implement this function. Please see the example implementations and the discussion on gas usage.

How to Query if a Contract Implements This XIP

The source contract makes a STATICCALL to the destination address with input data: 0x01ffc9a701ffc9a700000000000000000000000000000000000000000000000000000000 and gas 30,000. This corresponds to contract.supportsInterface(0x01ffc9a7).
If the call fails or return false, the destination contract does not implement this XIP.
If the call returns true, a second call is made with input data 0x01ffc9a7ffffffff00000000000000000000000000000000000000000000000000000000. This corresponds to contract.supportsInterface(0xffffffff).
If the second call fails or returns true, the destination contract does not implement this XIP.
Otherwise it implements this XIP.

How to Query if a Contract Implements any Given Interface

If you are not sure if the contract implements this XIP, use the above procedure to confirm.
If it does not implement this XIP, then you will have to see what methods it uses in other way.
If it implements this XIP then just call supportsInterface(interfaceID) to determine if it implements an interface you can use.

Now we have a way to calculate the interface ID. However, you might still have a few questions:

Why using a bytes4 value as the interface ID, instead of something like a string or a bytes32 value?
What is a function selector?
Why do we use XOR to calculate the interface ID?

For question 1, a string or bytes32 value could distinguish interfaces, but the problem is they would take way more than 4 bytes to store, which is too costly. Note that an Ethereum full node needs to store all the data, including interface IDs for all interface defined. A standard needs to balance both the cost of storage and the chance of collision. The chance of collision means the chance for two different interfaces having the same interface ID. So bytes4 was chosen with the consideration of such balance.

For question 2, function selector is a bytes4 value that allows you to perform dynamic invocation of a function, based on the name of the function and the type of each one of the input arguments. You can think of it as the identifier of a function. In solidity, we can get a function selector by reading the selector property of a function. For example, we can make a Selector contract as below to print the function selector:

/// Selector.sol
pragma solidity 0.5.8;
import "./StoreInterface.sol";
contract Selector {
  /// 0x20965255
  function getValueSelector() external pure returns (bytes4) {
    StoreInterface i;
    return i.getValue.selector;
  }
}

For question 3, XOR has a nice property that any change to the function defined in the interface (i.e, function name, or arguments type) will result the calculated interface ID to be changed, and meanwhile the length of the total bytes stays unchanged, no matter how many functions are included in the interface.

Please read through the proposed XIP and leave comments here on this post. If the developer community supports it I will shepherd it through the process.

Decentralization and the XIP Process

Jon McBee — Sun, 30 Oct 2022 00:25:19 +0000

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.

XDC Developer Meeting 10.21.2022

Jon McBee — Fri, 21 Oct 2022 14:32:37 +0000

This is an announcement of the upcoming XDC Developer meeting on 10.21.2022 at 11 AM EDT (UTC-4). We will be discussing the adoption of XIP-8, as well as the creation of XIPs correlating to EIP-165, EIP-721, and EIP-1155.

You can join through the developer discord: https://discord.gg/MFeHJ6C5gn

XDC Network Issue Reporting Process

Jon McBee — Fri, 23 Sep 2022 14:03:29 +0000

I would like to establish a formalized process for reporting issues for the XDC Network and it's supporting infrastructure such as SDKs, Testnets, Block Explorers etc... I have created a new document at the XDC Community Developer Portal documentation site that outlines the issue reporting process and provides links to different repository issue trackers, you can find it here.

This is a two step process that involves first opening an issue on the issue tracker for the appropriate GitHub repository, and secondly creating a post on xdc.dev that provides further context for the issue. Developers working on the codebase will see the issue raised in GitHub and will use it to track progress against the issue. The developer community will see the post on xdc.dev and will be able to comment with feedback, or follow the discussion for updates.

As a note, this process is intended for a specific set of issues related to the XDPoS protocol, test networks, APIs, SDKs; effectively the core code and dependencies that XDC Network developers rely on. If you have an issue with a second layer project or dApp you are encouraged to reach out to that team directly. If that team investigates the issue and decides that the root cause is related to core code or dependencies then they can follow this process for issue reporting.

Please provide any feedback to the proposed Issue Reporting process here in this document, or feel free to edit the page in the docs site and submit a pull request.

Documentation Bounties Live on Gitcoin

Jon McBee — Fri, 09 Sep 2022 21:04:28 +0000

XDC Community is pleased to announce the kickoff of a community bounty program, sponsored by the XDC Foundation, geared towards generating documentation for the open source developer portal.

If you are interested in participating in the bounty program you can find open bounties on the XDC Community Gitcoin page. Be sure to filter appropriately on the left hand pane of the Gitcoin UI to see all bounties.

We are also looking for community suggestions on topics for documentation bounties. If you have an idea for a how-to article, a tutorial, or a snippet of sample code that you would find valuable please suggest it on the XDC Community github discussion, or in the comments below.

Our goal is to engage with the developer community so that we can work together to fill any gaps and lower the barrier to entry for development on the XDC Network. Together we can continue to grow a decentralized XDC Network developer community.

Soulbound Tokens on XDC Network

Jon McBee — Thu, 08 Sep 2022 16:50:10 +0000

I am creating this post to engage the XDC community and gauge interest in the creation of an XIP specifying the addition of Soulbound Tokens as an extension to the XRC-721 token standard.

For context on Soulbound Tokens on the Ethereum Network I recommend reading Vitalik Buterin's blogpost where he introduced the idea.

For context on implementation details I recommend reading EIP-5192, which outlines how Ethereum structured their proposal.

If you believe that extending the XRC-721 standard to include support for Soulbound Tokens would be either a good or bad thing for the XDC Network please comment below. If you are passionate about Soulbound Tokens and want to champion them please consider authoring an XIP on the topic.

If you have questions on mechanics of XIP creation please ask questions either here or on Discord.

XIP Process Proposal: XIP-1

Jon McBee — Fri, 19 Aug 2022 17:40:29 +0000

I would like to propose the adoption of an XDC Network Improvement Proposal (XIP) process as outlined in XIP-1.

We intend for XIPs to be 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 the XIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.

The idea behind the XIP process is not unique or novel. XIPs are derived heavily from Ethereum Improvement Proposals (EIPs), which are in turn derived heavily from Bitcoin Improvement Proposals (BIPs), which were derived from Python Enhancement Proposals (PEPs).

While anyone can propose an XIP, the technical bar is quite high. Initially XIPs are reviewed by XIP editors, who ensure that XIP submissions adhere to formatting and style guidelines. For this program to be successful we need qualified members of the developer community to become XIP editors. XIP editors will be made collaborators on the XIPs GitHub repository.

Once uploaded to GitHub, XIPs are scrutinized by XDC community members who decide whether they are to be implemented in a future upgrade. This discussion can take place on the XDC.dev thread announcing the XIP. This post is an example, and the discussion related to this post will drive consensus for adoption of XIP-1, and as this is a decentralized process we will collectively need to define what "consensus" means to us.

In an effort to promote decentralization I have created a new XDC Community GitHub Organization that hosts the XIPs repository. In that organization you will find two other repositories; one is "xdc-community" and the other is "pm". I elected to create a brand new GitHub Organization unaffiliated with any other XDC Network entity so that it could be completely handed off to the community in the interest of true decentralization.

The "xdc-community" repository is the beginning of a GitHub pages hosted developer portal, which will hold documentation, sample code, tutorials, and more in a public repository that will enable a fork->update->pull request workflow so that anyone in the community can update the content of the developer portal. For those not comfortable updating the content an issue can be raised in the repositories GitHub issue tracker, or a comment can be made on the repositories GitHub discussion board. More on this in a future post as https://www.xdc.community/ is in a forkable but rough draft.

The "pm" repository is intended to act as a repository for protocol level discussions around protocol level XIPs so that all XDC Network protocol level decisions can be documented in a transparent fashion. The goal is for regular protocol level meetings to be held by protocol level developers, which will require buy-in and adoption by these developers. This change is prerequisite for true decentralization of the XDC Network.

This is a call to action to the XDC Community, XDC Network Developers, and XDC Network Core Protocol Developers to discuss adoption of XIP-1, and join in growing the decentralization of the XDC Network.