XRouter¶
Introduction¶
XRouter provides blockchain interoperability for the Blocknet Protocol with a communication layer consisting of an inter-blockchain SPV client backend, enabling the verification of blockchain records without requiring users to download the full blockchain. This empowers development of lightweight microservice architectures that harness contracts, protocols, and services from other blockchains, laying a foundation for a decentralized API ecosystem.
Since XRouter functions on the TCP/IP level, it is compatible with any network. This includes public and private DLT's, such as Bitcoin, Ethereum, IOTA, and Hyperledger.
Here is a list of current SPV calls:
| Call | Description |
|---|---|
| xrGetBlockCount | Returns a blockchain's block height |
| xrGetBlockHash | Returns a block number's hash |
| xrGetBlock | Returns a block hash's block number |
| xrGetBlocks | Returns block hashes for multiple block numbers |
| xrDecodeRawTransaction | Returns decoded transaction HEX |
| xrGetTransaction | Returns transaction data for transaction ID |
| xrGetTransactions | Returns transaction data for multiple transaction IDs |
| xrSendTransaction | Submit a signed transaction to the network |
To use XRouter, see the XRouter API and Setup Guide.
Service Nodes earn 100% of fees from XBridge, XRouter, and XCloud services. If you'd like to operate your own Service Node, see the Service Node Setup Guide.
Design¶
The XRouter system utilizes the Service Node network to route calls from the client directly to the respective blockchain. There are 2 types of XRouter calls: submissions and queries.
XRouter submissions are calls that involve interactions with a blockchain, such as xrSendTransaction. With submissions, the packets are routed from the client to the respective blockchain and a response, if any, is routed back to the client.
XRouter queries are calls requesting information from a blockchain, such as xrGetBlockCount. With queries, the packets are also routed from the client to the respective blockchain and the response of the information queried is routed back to the client. XRouter queries can require a specific amount of Service Nodes to receive a response from in order to achieve consensus on the final answer.
(view full size image)
The following diagrams depict the events of an XRouter query and submission. As seen in the diagrams, a "client" refers to software utilizing the Blocknet Protocol, which can be a blockchain, microservice, dApp, mobile app, website, etc.
(view full size image)
The flow of the diagram is top-to-bottom:
- The client dispatches a packet for a query via API call to the Service Node network.
- The Service Nodes supporting the queried blockchain receive the packet.
- The Service Nodes route the packet of the query to the blockchain.
- The Service Nodes route the response from the blockchain back to the client.
- The client receives all responses, as well as a response for a majority consensus on the answer.
(view full size image)
- The client dispatches a packet for a submission via API call to the Service Node network.
- The Service Nodes supporting the desired blockchain receive the packet.
- The Service Nodes route the packet of the query to the blockchain.
- If there is a response from the blockchain, the Service Nodes route the response back to the client.
Namespace¶
XRouter SPV wallets utlize the xr:: namespace while XCloud services utilize the xrs:: namespace. A list of the SPV wallets and services can be viewed using xrGetNetworkServices and you can pre-connect to the nodes with xrConnect.
Node Scoring¶
Clients keep a local score of each Service Node (network-wide repuation system is planned). When a Service Node reaches a score of -200, the Service Node will be banned by the client for a 24hr period. After this 24hr period, the Service Node will start with a score of -25. The ban score threshold can be adjusted using the xrouterbanscore setting in blocknet.conf (see setup). This scoring used for both XRouter and XCloud.
| Action | Change in Score |
|---|---|
| Failure to respond to call within 30s | -25 |
| Failure to meet majority consensus | -5 |
| Matching consensus | correct_nodes * 2 |
| Sending bad XRouter config | -10 |
| Sending bad XCloud config | -2 |
This mechanism and values are subject to change in future releases. Join the Developer mailing list to stay updated.
Fees¶
With XRouter, and subsequently XCloud, fees are determined by a free market. Service Nodes can specify the fee that they wish to charge for a call and client can specify the max fee they are willing to pay for calls.
Note about IP sharing and Fees.
When testing and enhancing XRouter, we encountered a bit of IP-sharing between snodes. This is bad practice, because it's evidently a case of one entity voting twice in an XRouter proof. As such go-xrouter filters out duplicate nodes per IP address, so the second node won't get any fees.
Use Cases¶
The applications for XRouter are as vast and imaginative as the internet. Below are a few examples of use cases:
-
Supply Chain - In supply chain there will be multiple blockchains being used at various steps of the process much like there is today with traditional software stacks. The Blocknet Protocol and XRouter would allow information to be accessible between these different blockchains. For Example, pharmaceutical manufacturers have strict regulations to follow and need to provide certain information and assurances. Being able to access batch information from the raw materials being consumed, temperature and humidity information during transportation, and final destinations are all important. A smart contract utilizing XRouter to gather this information from each respective chain and write it to the pharmaceutical’s blockchain along with the batch code. XRouter would enable this communication to occur in a trustless way, which is important to ensure validity of the information.
-
Storage and Hosting - If creating a dApp on Ethereum, you may require storage functionality. Ethereum doesn’t intrinsically handle file storage very efficiently. In this scenario, XRouter can be used to interact with other blockchains such as Storj, Filecoin, Sia, or Swarm to utilize their storage services.
-
Media and Content - For content creation, a creator has the option of publishing to the LBRY Credits or Alexandria blockchains. Similar to HootSuite, which is a tool that allows posting to multiple social media platforms simultaneously, a dApp can be created using XRouter that offers the same benefit. The user can post their content once, whether it’s audio, video, literature, or art, and have it published to Alexandria’s and LBRY Credit’s blockchain platform simultaneously.
-
Markets - There are many blockchains creating decentralized marketplaces including Origami, District0x, OpenBazaar, and Syscoin’s marketplace, but the offering of products are relatively low on each independent platform. A dApp that utilizes XRouter to aggregate all the products into a single hub would offer a lot more options to users and a fuller marketplace. It can also make publishing products easier by publishing to all platforms simultaneously through a single form, offering more exposure than posting to a single marketplace while saving time.
-
Business and Industry - There are many dApps and blockchains that will end up using health data. Rather than submitting health data to each application, a universal EHR (Electronic Health Record) blockchain can be created to manage personal medical data and accessibility of data by each application. The health data on this EHR ledger can be shared amongst healthcare providers, hospitals, and insurance blockchains, dApps, and applications via XRouter.
-
Certifications - Certifications and licensing records can be stored on a dedicated blockchain where they could be verified by a dApp built on the Blocknet Protocol. These records can be used to confirm qualifications and grant access or permissions.