Over the past few years, an important innovation colloquially known as the “Blockchain” has emerged as a potentially disruptive technology. The core of the innovation is built around the concept of a distributed cryptographic database. The database, also referred to as the ledger, is maintained by a network of computers. The ledger makes it possible for the entire network to create, evolve and keep track of an immutable record of transactions. The most successful blockchain application thus far has been Satoshi Nakamoto’ s cryptocurrency known as Bitcoin, which he outlined in his seminal paper, “Bitcoin: A Peer-to-Peer Electronic Cash System” in 2008. This powerful technology has so far been implicated in the numerous cryptocurrencies that exist online. Financial institutions are only beginning to understand the potential applications of blockchain in conventionally regulated industries.
At a fundamental level the blockchain is a data structure that cryptographically links blocks of transactions or any potential transfers of value. As a paradigm, the blockchain allows for true privacy to exist between those involved in a transaction. This characteristic of the blockchain that makes its most significant implementation in the financial industry. Its structure allows for automation, immutability, and decentralization. These characteristics were carefully chosen by Nakamoto in order to create a digital mechanism of trust.
For the financial world this would result in a more limited reliance on third party trust mechanisms enabling a direct contractual interface between two parties involved in any transfer of value. This technology has the power make such exchanges safer, faster, and cost-effective. Ownership of value stored in the blockchain is established through asymmetrical cryptography. Digital keys, wallet addresses, and digital signatures are all created cryptographically to ensure total privacy in transmission of transactional data.
Every transaction on the blockchain needs to be 'signed' using digital keys. Whoever owns these keys, owns access to the value stored in the wallet. All keys generated by the wallet software come in pairs; a private key, which is kept secret and a public key. The public key is akin to a bank account number and the private key is like the secret pin used to control the account. The idea behind digital signatures is that private and public key pair shares a mathematical relationship such that a message (transaction) signed by a private key can be verified by a public key without revealing the private key.
The Bitcoin's blockchain network is structured as a peer-to-peer network architecture. In this network implementation, all nodes are equal or symmetric. There is no server, no centralized service, and no hierarchy in the Bitcoin's network. blockchain implementations for the financial industry however, cannot allow for such an open and symmetric network structure. Bitcoin enthusiasts advocate, therefore, that the blockchain and Bitcoin are fundamentally linked. This is a short sighted view taking into consideration that the Bitcoin technology stack exists to solve the problem of an unregulated digital currency. The same stack can be evolved to solve similar transfers of value over an asymmetric network.
The development of the Ethereum blockchain was a major milestone in the blockchain ecosystem. The focus shifted onto system state and virtual machines that could run smart contracts across the network. With the availability of Turing complete smart contracts, the limited functionality of the Bitcoin scripting language was overcome and a number of different applications became possible.
Private blockchains came into prominence with the Hyperledger Project that saw participation from IBM and Intel in 2016. Another major private blockchain developed by R3 called Corda also raised significant amounts of money. Since then, R3 has also joined the Hyperledger Project. Fully private blockchains make the case that centralized and trusted implementation of the core data structure of the blockchain along with significant changes to the consensus mechanism are meaningful value propositions for enterprise applications.
Hybrid blockchains are fairly unexplored and only few implementations exist; even in development. Quorum developed by JP Morgan is designed to be the hybrid blockchain in a fully permissioned environment. Truly Hybrid blockchain must necessarily be able to connect public blockchain with a private blockchain implementation running in a fully permissioned environment. The XDC hybrid blockchain aims to be exactly that, leveraging the power of both the public and private blockchain paradigms.
| Parameters | Public Blockchain | Private Blockchain | Hybrid Blockchain |
|---|---|---|---|
| Transactional Visibility | Fully visible | Not visible | Both; subject to use case |
| Auditability | Low | Low to High | High |
| Network | Decentralized | Centralized | Hybrid |
| Security | Compromised | High | High |
| Throughput | Low(3-4 s-1 Bitcoin; 15 s-1 Ethereum) | Very high | Very High |
| Membership | Open to all | Restricted | Participation Open, Hosting Restricted |
| Interoperability | No | No | Yes |
The public blockchain implementations, including Ethereum, serve an important purpose but are woefully inadequate for financial and other use cases. There are entire industries that would benefit greatly from blockchain technology but cannot implement an Ethereum based solution.
All industries have stringent data security needs. A fully public blockchain that stores transaction data, even in encrypted form, can be compromised as in the case of the Bitcoin blockchain. In addition to data security, institutions also have auditability requirements. This balance between data security and data auditability is an important consideration and the XDC protocol is equipped to satisfy both.
The nature of public blockchain is such that transactional data is visible to all participants in the network. This means almost anybody can track any transactions. While public key cryptography theoretically provides some level of anonymity, entire industries exist to de-anonymize the Bitcoin and Ethereum blockchain. This is wholly unacceptable for sensitive financial data and makes the public blockchain paradigm unsuitable for enterprise applications.
Data visibility concerns go hand in hand with auditability requirements. Different institutions and different levels of participants within an institution require ways of easily accessing data. Inability of requisite participants to access data without compromising any benefits of public key cryptography makes the application of public blockchains like Ethereum to financial use cases impossible.
The XDC blockchain runs it’s full and reference nodes on the infrastructure of its consortium members. The blockchain contents are not available on any public network such that it’s possible to brute force the relationships between transactions and associated public keys. Consortium members will undergo stringent vetting and will be able to run ‘gerent’ nodes which have the entire blockchain stored on their infrastructure. These nodes will also be ‘bootnodes’ in the Ethereum paradigm. The different kinds of nodes that will perform different functions are described in section 2.6.
A very important aspect of a distributed databases is the network architecture. While much has been written about Public and Private blockchain architectures, consortium blockchains have been somewhat ignored. This is unfortunate because consortium blockchain architectures tread an important middle ground between the low trust ecosystem of public blockchains and the high trust member entities of private blockchains.
Fully public blockchains like Bitcoin and Ethereum rely on a certain number of long term stable nodes. Consortium blockchains are similarly structured but with more selective inclusion clauses and centralization is a not an inherently undesirable quality in blockchain architectures. Enterprises depend heavily on centralization and it may be hard to make a blanket case for decentralization across regulated fiduciary institutions.
The XDC blockchain is built upon the paradigm of consortium blockchains. The architecture differs from conventional private/permissioned blockchains as well as public blockchains. Built upon the Ethereum codebase, the XDC blockchain also deals with the system state rather than blocks of transactions. There are two different kinds of networks that can exist within the XDC ecosystem. Firstly, the public network that all constituents are part of and a private/permissioned network that restricts participation. And secondly, the private network state is maintained in its respective network but a record (hash) of transactions and smart contracts is stored on the public state of the blockchain. As depicted in Figure 1, various institutions will have different relationships with other participants. The public state of the XDC blockchain is shared by all participating nodes that are owned by different kinds of constituents. Groups of nodes can further form fully permissioned networks with their own private state that is accessible only to authorized members. For instance let us assume that a private marketplace for goods and services is set up in Network 1. The specifics of the trade between parties is not accessible to Network 2. But the record of individual trades are stored as hashes on the public state that is shared by all such that even in the private network there is an immutable record of transactions.
The previous section outlines how private and public states on the XDC blockchain can co-exist and provide the benefits of both. The 'hybrid' nature of the XDC blockchain extends to interoperability with public blockchains like Ethereum and Bitcoin. Transactions that are marked as hybrid on the XDC blockchain can be transmitted to and executed on the Ethereum public blockchain without the need of external wallets or exchanges. The XDC protocol seeks to create a truly decentralized cryptocurrency space through interoperability
Consortium membership here refers to the relationship different institutions and individuals can have with the XDC blockchain.
The XDC blockchain has three kinds of membership. The first is the most accessible. If an individual or institution owns the XDC tokens, they are part of Tier 1 membership by default. These tokens can be bought by interested individuals or institutions through the planned crowdsale. Tier 2 and Tier 3 memberships are both obtained by holding a certain amount of the XDC subject to requisite vetting. These tiers allow institutions to host the XDC nodes and participate in the consensus mechanism of the XDC blockchain.
Private/permissioned blockchains are usually very resistant to possible forks to their blockchain. The XDC blockchain is no exception. Only Tier 2 and Tier 3 consortium members are allowed to run the XDC nodes. There are asset forfeiture rules written into the protocol that seize the XDC holdings of unscrupulous consortium members looking to undermine the integrity of the XDC blockchain. Furthermore, each block is signed by the node that creates the block. Fraudulent additions to the XDC blockchain are, therefore, very easily prevented.
The asset forfeiture and close vigilance on additions to the XDC blockchain mimic the legal responsibilities that financial institutions have in the real world. Public blockchains have no mechanisms of exacting personal cost from ill-intentioned participants which introduces a lawlessness that is not conducive for enterprise applications.
This section outlines the individual components of the XDC protocol. In the following sections, we have outlined the different components of the protocol that make up different type of nodes on the XDC blockchain. Certain nodes will require fewer components from the protocol than other depending on the functionality necessary.
The Administration Manager lives in the heart of the XDC protocol. The activity of the Administration Manager can be divided conceptually into three sections. It is the location for the definition of the Data Model, Messaging, and carries out State manipulation. The Administration Manager is equipped with a Java script CLI that can be used to define Data Models, create Messaging frames, and alter the State of the system. The Administration Manager, in summary, allows for the definition of Data models, their initialization, instance creation, creating messaging frames, and the lifecycle of all state changes.
The Data Model is the part of the Administration Manager where the structure of the data that is to be stored on the blockchain is defined. The public state of blockchain has a predefined data model that is stored in here. The private state of the blockchain can inherit this data model extant, make changes to it, or create an entire new structure according to the use case.
The Messaging section within the Administration Manager interfaces with the Conduit service to transfer the different kinds of messages across the constituent parts of the protocol. Using the JS CLI, the default messaging structure can also be altered for private state use cases.
The Administration Manager carries out state transitions across the private and public states of the blockchain. The Conduit Services and the Network Manager connect the Administration Manager to different parts of the protocol, local storage, and the XDC ecosystem in general in order to define, initiate, and execute different classes of transactions.
The Smart Contract Manager executes the appropriate contracts at the right time. It is deeply connected with the Resource Manager and Augur Services in order to ensure that the conditions stipulated in the contracts are met. Highly audited smart contracts are available to be inherited by the public state participants with private networks having the ability to make further customizations according to the needs of the use case.
The Message Conduit connects the various parts of the protocol with each other. It connects the Augur Service and the Resource Manager with the Smart Contract Manager to ensure external conditions critical to execution of smart contracts are securely transmitted and that they are executed correctly. It also connects the Network Manager with the Administration Manager to carry out a number of state modification tasks including transactions.
The Network Manager connects the various nodes of the XDC ecosystem. It is responsible in creating a permissioned subnetwork that has its own private state and in connecting to other nodes for modifying the public state.
The Chain Manager is implicated in the consensus mechanism that resolves BFT (Byzantine Fault Tolerance) issues that can arise during state transitions. The Chain Manager maintains the private state for permissioned sub-networks in local storage and takes part in the voting mechanism to maintain the public state.
###2.4.6 Resource Manager
The Resource Manager is the part of the protocol that connects to the equipment or resource monitoring ecosystem that is part of the fiduciary arrangements. For instance an IoT based resource monitoring ecosystem might be set up to make sure equipment purchased through a loan is being utilized within the terms of the agreement. It is the Resource Manager’s job to connect to IoT like devices that are tied to corresponding resources. The XDC protocol comes with inbuilt support for Arduino, Raspberry Pi, Intel Edison, and the ESP2866. More IoT device support is planned for as well.
###2.4.7 Augur Service
The Augur Service communicates with the Smart Contract manager as a highly secure oracle service. Smart contracts that depend on external variables, such as market conditions, get their data from the Augur Service. The Augur Service will contain highly vetted and controlled connections to the pertinent external sources. For smart contracts or transactions that deal solely with the private state of a permissioned network, oracle data from the Augur Services can be augmented with mutually agreed upon sources.
The XDC blockchain is built upon Quorum, a private/permissioned blockchain developed by J.P. Morgan. Quorum has been developed as a layer upon the Go implementation of the Ethereum protocol. There are few but significant changes made to the protocol. The consensus mechanism has been entirely reworked, replacing proof of work with a consensus mechanism called QuorumChain. This new consensus mechanism allows for new blocks be created in a two-step process. In the first step, the transactions to be included in the new block are voted upon by all participating nodes. In the second step, one node is selected as the leader or block maker randomly. The block maker node then creates the new block.
The XDC blockchain is forked from Quorum. There are a number of reasons behind this decision. Firstly, the powerful smart contract functionality that exists in the Ethereum protocol is easily accessible through in Quorum. Secondly, the consensus mechanism is implemented as a smart contract in QuorumChain. Additional changes to this method of achieving consensus are easy to implement. Thirdly, the hybrid nature of the Quorum blockchain is ideal for a large number of enterprise use-cases. Fourthly, the fairly high throughput compared to public blockchains is essential for any scaling needs for high volume businesses. Finally, the ability to reuse the substantial development dedicated to the Ethereum protocol makes the choice of Quorum as our base implementation very appropriate.
In addition to the above, our fork includes a number of improvements to the Quorum protocol. The throughput of transactions is significantly increased in our test environment. We've developed a smart contract manager that allows for interoperability between the XDC blockchain and public blockchains. We've added punitive smart contracts that connect to the QuorumChain consensus smart contracts to ensure those who stake the XDCs to run network infrastructure remain honest. We're also in the process of developing a light client built for the Quorum protocol that would connect natively with the XDC ecosystem.
The XDC network hosts four different kinds of nodes. Many nodes don't require the functionality of or have the resources to run full nodes. Nodes that only write to the private state of a sub-network don't require all components of the XDC protocol. Furthermore, the ability to run full nodes will also be restricted to institutions that meet the criteria for it.
The consensus architecture for the XDC protocol is divided into two parts. The first is the XDC consortium membership requirements. In order to participate in the XDC network, institutions must belong to one of the three tiers. The tiers, in part, correspond to the XDC token holdings. Any fraudulent activity results in seizure of the XDC tokens that are staked to gain membership and host network infrastructure.
The second is the actual process of achieving consensus. Once the network topology is stable, nodes come together to vote on transactions that can be put on a new block. Then a new leader is selected from among the validator nodes at random. This leader creates a new block with the transactions that have been voted on by the other full nodes. Described below are the different kinds of nodes that exist on the XDC network and their purpose.
Full nodes will possess the entire XDC protocol. Certain Full nodes will possess even the transaction history of the entire network in addition to the state. These nodes will be controlled by consortium members and come with a number of caveats. Full nodes will have to purchase (and hold) a fixed equity of the XDC to be able to host the full XDC protocol. One major advantage to this design choice is that no Full Node or groups of Full Nodes can gain control over the network. In order to possess more than 51% of the public network, Full Nodes must acquire more and more XDC. This drives up the price of the XDC and ensures that it is financially impossible for a Full node cartel to control a majority of the network.
The second kind of nodes are Reference nodes which exist to transfer transactions to the transaction pool. These nodes do not have access to the entire blockchain and play only a minor verification role in that they ensure the structure of the transaction is according to protocol. The transactions are verified and added to the blockchain by the Full nodes.
The third kind of node is a Light Node. A Light node is implemented in the private networks that don’t participate in achieving consensus through the voting process. They store the relevant private state in their local storage and can access the public state and the transaction history from Full Nodes.
The fourth kind of node is an Auditing Node. This node has other parts of the protocol, other than the Chain Manager, but they are very limited in their functionality. The Auditing Node allows for the access to the public and private state of the blockchain for the purposes of regulation, auditing, or reconciliation with legacy systems.
The XDC token is built upon the ERC20 token standard. This design decision was taken to ensure a fundamental compatibility with the multitude of emerging Ethereum Dapps. With a view at future interoperability with the Ethereum blockchain, the choice of using the ERC20 standard was straightforward. This compatibility extends to smart contracts written for the Ethereum blockchain.
While we all claim to be proud participants in a movement for decentralization, we are tied to centralized exchanges. True decentralization will evade the blockchain ecosystem till there is meaningful interoperability. Our design choice was also taken with this perspective in mind. We envision a future where all kinds of tokens can be exchanged and smart contracts are not limited to the architecture of individual organizations.
Online wallets often seem to be a convenient way of storing cryptocurrency tokens but could actually be very insecure. Certain implementations of online wallets are simply web applications with access to wallets running on a full node. It is extremely insecure to share private and public keys, something that is inevitable with most online wallet implementations. An added concern is the accidental or planned shutting down of the node hosting the wallet. In that case all tokens are lost or stolen. These incidents are not only financially damaging but also hurt the general reputation of the blockchain ecosystem.
The XDC ecosystem will provide easily accessible light wallets that will connect securely to full nodes. Each light wallet will have unique keys that are used to sign transactions from their associated account. Since the light wallet is a standalone application that serves only one account, the possibility of being hacked or losing the XDC tokens becomes highly unlikely.
One major problem with using the ECR20 standard in designing custom tokens is that transfers from Ethereum wallets will result in a loss of ether. This is a design challenge that a lot of custom coins face. We at XinFin are going to be using specialized functions that call on the token’s contract rather than sending them from a wallet, preventing loss of tokens.
We plan to release a token standard of our own that will ensure users on the XDC blockchain cannot accidentally send their tokens to an incompatible ERC20 based blockchain. We plan to build the XDC01 standard on top of the ERC20 standard to ensure future compatibility when interoperability allows for such kinds of transfer.
There are 10 farmers in Ghana that want to procure a certain kind of harvester from an Indian manufacturer. Without delving too far into the financial relationships that need to be facilitated, the acquisition of the equipment, functioning, and repayment of the loan can be carried out over the XDC protocol.
Actors involved: Party A (the farmers), Party B (the equipment manufacturers), Party C (various institutions involved)
Party A accesses the marketplace where service providers, Party B advertises its wares. This communication can happen on a Dapp marketplace or initiated through a more conventional method.
-
Dapp connects Party A, Party B, and Party C. After terms are agreed upon smart contracts are written, initialized, and implemented through the Smart Contract Manager.
-
Dapp sends the transaction data frame to the Administration Manager.
-
The Administration Manager invokes the appropriate smart contracts through the Smart Contract Manager.
-
The Smart Contract Manager initializes a monitoring service via the Resource Manager and the Augur Service. The XDC that is being used to the purchase the equipment is transferred to Party B. In the case that a loan is required for the purchase, the required amount of XDC is transferred from Party C (the financiers) to Party B as depicted in Figure 9.
-
The state of the blockchain is updated through the Administration Manager by sending the transaction details through the Conduit Service to the Chain Manager and the Network Manager. If necessary, the Network Manager intimates the remaining network that the public state needs to be updated or the Chain Manager updates the private state and updates the public state through the Network Manager.
-
The Network Manager broadcasts the pertinent information to the relevant actors across the network. An Escrow smart contract is initiated by the Smart Contract Manager and a percentage of XDC are stored in its account in order to underwrite the investment to protect against non-payment or term violations as depicted in Figure 10.
-
The Smart Contract Manager sends the escrow details to the Administration Manager.
-
The Administration Manager updates the private state, broadcasts the public state update through the Network Manager, and to the actors involved in the private state transaction. A further service is started in the Resource Manager that monitors the physical location and activity of the equipment purchased. In the face of terms violation preventive smart contracts, in this case the Escrow smart contract, initiate payout to the financiers according to the terms of the agreement as depicted in Figure 11.
-
The Resource Manager updates the Smart Contract Manager with conditions being fulfilled or violated. Which in turn updates the Administration Manager.
-
The value generated by the equipment is recorded on the XDC blockchain.
-
The loan amount is repaid and the Smart Contract terminates after all the payouts are distributed amongst the constituents as depicted in Figure 12.
Generally asset valuation is a tedious process for financial institutions. Certain assets, like real estate, are easier to value than assets that depreciate in value, like airplanes. Instead of holding collateral to finance or refinance assets, it might make sense to constantly assess the asset in question itself. Unfortunately because of opaque and outdated processes, asset valuation becomes impossible for financial institutions. The XDC blockchain will allow for asset valuation from procurement to financing at a later part of its lifecycle. Monitoring services will constantly evaluate the 'health' of an asset and make that information quickly available to relevant authorities.
Let us assume that an airlines has financed a number of airplanes as part of its fleet. The asset valuation, in this case of the airplane, will be recorded on the XDC blockchain. Standard formulas for value depreciation resulting from the use of the airplane, the age of the asset, repairs and maintenance, or traditional refinancing, can be coded in smart contracts to monitor the value of assets in a transparent and standardized format.
When the airline needs to trim part of the fleet, a cryptographically signed record of its history is available readily and in a standardized format. The aforementioned opacity no longer prevents asset valuation.
Section 3 outlines the procurement and monitoring of assets in a trade finance context. The innovation supported by the XDC protocol is the ability to finance and operate assets on value ascribed to the asset itself. In the example, farmers were able to procure farming equipment that was financed against the value that they would produce. In order to calculate the value produced and record on the XDC blockchain, mechanisms for resource monitoring must be put into place. IoT enabled resource monitors that connect securely to the XDC protocol allow for such monitoring.
Smart contracts are the truly innovative invention in the blockchain paradigm. We plan to build a large community of developers and enthusiasts who will design and make innovative smart contracts. We at XinFin are nonetheless cautiously optimistic about smart contracts. The DAO hack is undeniable proof that even with the Ethereum protocol having robust security, smart contracts can be compromised without the right kind of oversight.
Our solution to this problem is straightforward. Since the XDC ecosystem belongs to the consortium blockchain paradigm, we plan to allow only comprehensively audited smart contracts. This will ensure not just the security of the XDC ecosystem, but also create a standardization that has secondary benefits in a number of fiduciary use cases.
As the XDC blockchain gains maturity, we envision a regulated marketplace with a well-defined process of security auditability. Smart contract writing firms will undertake creation of standardized contracts for general financial use cases but will also cater to more customized applications. Entirely separate auditing firms will ensure the infallibility of these smart contracts. Our aim is to ensure hacks like the DAO don't happen on the XDC blockchain.
The XinFin Hybrid blockchain’s underlying token is called the XDC or XinFin Digital Contract. The XDC token can be traded freely on the public state of the XinFin blockchain. Retail users or institutions can operate accounts that can buy, sell, or trade XDCs through the wallet application.
The XinFin blockchain also has advanced smart contracting capabilities and highly customizable private sub-networks that act as permissioned blockchains. While the XDC token can be integrated with private or public DApps(to act as a settlement layer), the team here at XinFin believes that interoperability with other blockchains is a very real need in an ecosystem rife with monolithic cryptocurrencies and tokens.
Our version of interoperability includes the ability for institutions or individuals to create DApps, smart contracts, or custom tokens, while accepting or paying in the cryptocurrency of their choice. What this means is that a DApp or smart contract created on the XinFin Hybrid blockchain can make use of highly liquid existing cryptocurrencies like Bitcoin(and Bitcoin forks), Ethereum, Ripple, etc.
There are significant advantages to this relationship between the XDC blockchain and public cryptocurrencies. For Bitcoin, Bitcoin Cash, or Ripple, the absence of a smart contracting layer makes possible usecases very limited. By plugging into the XDC blockchain, holders of these cryptocurrencies can leverage fast, secure, and scalable smart contracts(and DApps) for their more involved usecases.
Even for cryptocurrencies like Ethereum that have built in smart contracting capabilities, running the DApps on the XDC blockchain is a wiser choice. This is because the Ethereum blockchain, like most other popular cryptocurrencies, have become victims of their rampant success. Their networks are getting bogged down by more transactions than they can handle and rising costs make high frequency transactions impossible. For example, IoT based applications are impossible to run on the Ethereum public blockchain due to the high cost per transaction and the low throughput(~15 tps) of the network.
By using the highly secure(hybrid-permissioned), scalable(~300 tps), fast(<1 sec block creation time) XinFin blockchain, these cryptocurrencies can be used to provide the liquidity for various use cases while the XDC network acts as a smart contracting and settlement layer.
The cryptocurrencies we will be supporting will be revealed shortly. We plan to integrate all major public cryptocurrencies with the XDC blockchain to allow for a kind of interoperability that is sorely needed to realize the decentralized utopia that blockchain technology offers.
Page Break
Enterprise application requirements are difficult to fulfill under normal circumstances. Implementing new technologies therefore comes with significant risk. Industry vetting of the popular public blockchains has not been favorable. The visibility of transactions, the rigidity of development paradigms (Bitcoin block size debate), the lack of permissioned infrastructure, and the energy intensive consensus are some of the gaps that make enterprise applications built on public blockchains difficult for real world applications.
The Bitcoin protocol brought with it grand visions of a decentralized and secure world to facilitate transactions. The cryptocurrency ecosystem that has since developed has ironically resulted in monolithic silos with no interoperability. Centralized exchanges are necessary to carry out conversions between cryptocurrency pairs that are suspect to exactly the same kinds of security problems that the Bitcoin protocol set out to solve.
The XDC blockchain attempts to solve this problem of secluded ecosystems with highly secure and robust interoperability powered by the protocol described in this paper. Interoperability here refers to both within the XDC protocol and outside of it. Within the XDC ecosystem, public and private states interact with each other in specific ways. Outside of XDC ecosystem, interoperability with public blockchains allows for the exchange of XDC tokens from within the protocol itself.
The XDC blockchain aims to bring together the significant advantages of public blockchains and the necessary restrictions of permissioned blockchains to create an ecosystem that is enterprise ready. The tiered membership rules for participation in the XDC network allows for robust mechanisms in maintaining network integrity. In addition, controlling network participation, creates an environment of standardized relationships that allow for the focus to be on what is important: business.
- Nakamoto, Satoshi. Bitcoin: A Peer-to-Peer Electronic Cash System: Cryptography Mailing List, 2008.
- Swan, Melanie. Blockchain: Blueprint For a New Economy: Sebastopol, O’Reilly, 2015.
- Copeland, Christopher and Zhong, Hongxia. Tangaroa: a Byzantine Fault Tolerant Raft: Stanford, 2015.
- Buterin, Vitalik. Ethereum: Platform Review, Opportunities and Challenges for Private and Consortium Blockchains. 2016.
- Voell, David and Nielsen, Patrick: Quorum whitepaper v0.1: https://github.com/jpmorganchase, 2016.