XRouter Configuration Guide¶
This guide explains how to setup and configure your Service Node to support XRouter. If you have not yet setup your Service Node, start with the Service Node Setup Guide.
Note: XRouter requires a static IP
For XRouter services, your Service Node Computer IP address must remain unchanged (static IP) and use port 41412 . If using a VPN with an IP that changes, it will impact your ability to provide XRouter services.
XRouter makes direct connections and you'll need a WAN IP as your Service Node IP address and if it's behind a router you'll need to port-forward to it.
XRouter is a decentralized interoperability protocol with an SPV client backend supported by Service Nodes that allows users to validate transactions and ensure transactions are in a block. These calls are supported by default if XRouter is enabled with no additional settings. For example, if you have a fully synced Bitcoin node with txindex on, you can use XRouter to sell transaction information on Bitcoin's blockchain. So if a user doesn't want to download the full chain, but needs to know information about a transaction, they could query your XRouter node and you can charge them a fee to do so.
You have the option to offer these services for free or to charge a fee for each call. Fees can be set to be specific for each individual call.
To setup XRouter, follow these steps:
- Enable XRouter
- Configure XRouter
- Deploy SPV Wallets
- Additional Information
- Setup XCloud (option): XCloud is a decentralized microservice cloud network that allows you to monetize any microservice, blockchain, API, or cloud tech on your own hardware, many cases without having to write any code.
XRouter is turned off by default. To turn it on, add
blocknetdx.conf. Changing this to
xrouter=0 will turn off XRouter. Upon enabling XRouter, SPV calls will also be enabled and free by default. See Configure XRouter for further configuration.
listen=1 server=1 rpcallowip=127.0.0.1 rpcuser=username rpcpassword=password port=41412 rpcport=41414 xrouter=1 enableexchange=1 servicenode=1 servicenodeaddr=22.214.171.124:41412 servicenodeprivkey=922m1YhfTRK6oLnSXGptbqjbSSSqXrktzAiybQBWJeQimHiHoU2 rpcthreads=8 # equal to number of supported wallets, set to no less than 8
Tip: For best performance...
maxconnections=setting should not be specified.
rpcthreads=should be set to the number of blockchains you are supporting (if running 24 blockchains, set
rpcthreads=24). If you are running less than 8 blockchains then it should remain
rpcthreads=8as the minimum.
After making these changes you will need to restart your Service Node Blocknet wallet.
When starting the wallet, an
xrouter.conf file is automatically created in the Blocknet wallet data directory if not already present. The
xrouter.conf file is used to specify all your general XRouter settings and SPV call settings.
Note: SPV support also require xbridge.conf configuration.
To support SPV calls, you must also have your
xbridge.conf file setup for the chains you wish to support.
xbridge.conf, the general XRouter settings are specified under a
|wallets||The wallets you'd like to support XRouter calls on. All commands are on by default for all supported wallets listed in
|plugins||The XCloud services you are supporting, see XCloud Configuration.|
|fee||The fee (in BLOCK) you require for calls. A value of
|clientrequestlimit||The minimum time allowed between calls in milliseconds. A value of
|disabled*||Used to disable a call. A value of
|fetchlimit||The maximum number of records returned. This pertains to calls such as
* Only for subsection settings, not supported under
Note: Setting values use hierarchy priority.
Values set under
[Main] override the default values and become the new default settings for all subsections that don't have the respective setting specified. Subsection settings override
[Main] and default settings. Wallet-specific subsections have the highest priority and override all other settings.
The setting hierarchy from highiest priority to lowest priority is as follows: [BTC::xrGetBlockCount] > [BTC] > [xrGetBlockCount] > [Main] > default. The higher priority settings override the lower priority settings.
[Main] wallets=BLOCK,SYS,BTC plugins= fee=0 paymentaddress= clientrequestlimit=50 [xrGetBlockCount] fee=0.01 [xrGetBlockHash] fee=0.01 [xrGetTransaction] fee=0.1 clientrequestlimit=20 [BTC::xrGetTransactions] fee=0.5 timeout=50 fetchlimit=20 [BTC::xrGetBlocks] fee=0.3 timeout=30 fetchlimit=20 [xrGetBlocks] disabled=1 fetchlimit=50
Here is a list of current SPV calls:
|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|
Deploy SPV Wallets¶
- Add the chains you want to support SPV calls for in the
xrouter.conf, denoted by the chain's asset's ticker. Separate each wallet name with a comma.
- If you added or removed blockchain support, make sure to also update the
rpcthreads=value in the
xrReloadConfigsto load your newly configured settings to
xrouter.confwithout needing to restart your Service Node.
sendservicepingto propogate these new settings to the network immediately or wait up to 10 minutes for this to happen automatically.
- You can view your configs using
While Service Nodes can set their own fees, users can also set the max fee they will pay. Any Service Node's with a fee that is higher than a user's max fee will not be used. It is recommended to offer free calls for any call that are not computationally intesive. Lower fees will help encourage an ecosystem to build around the network. A healthy ecosystem will lead to much more usage of the network and receiving a lot of small fees will be more beneficial than receiving a few high fees. Granted, some calls may actually take computational time and will therefore require a higher fee.
Clients keep a score of each Service Node. 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
|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|
These values are subject to change in future releases. Join the Service Node mailing list to stay updated.