THORNode Stack

THORNode Stack

Each THORNode is comprised of 4 major components.

1. thornode - this is a daemon that runs the THORChain chain itself and a HTTP server, that gives a RESTful API to the chain.

2. bifrost - this daemon creates connections to remote chains (like Bitcoin, Ethereum, Binance, etc) to both observe activity on those chains (incoming/outgoing transactions), and also sign/broadcast outgoing transactions (moving funds on remote chains).

3. gateway: THORNode gateway proxy to get a single IP address for multiple deployments.

4. Full nodes - for every chain that is supported by the network, each THORNode operator will run their own full node of each chain (Bitcoin, Ethereum, Binance Smart Chain, Avalanche, etc).

THORNode operators may choose to run the following service:

• midgard - a layer 2 REST API that provides front-end consumers with semi real-time rolled up data and analytics of the THORChain network. Most requests to the network will come through Midgard. The Midgard API keeps the chain itself from fielding large quantities of requests, allowing THORNode to focus on validating and propagating blocks across the network. You can think of it as a “read-only slave” to the chain.

Endpoints can be accessed at Connecting to THORChain in the developer docs.

THORNode Endpoints

The THORNode daemon contains three endpoints that run on port 1317 or can be access via the public URL https://thornode.ninerealms.com/.

• <tc:1317>/thorchain:

  • This endpoint deals specifically with THORChain's native modules and functionality. It provides access to THORChain-specific data such as liquidity pools, nodes, and network configurations. This is where you'll find THORChain-specific operations and data that aren't part of the underlying Cosmos SDK but are unique to THORChain. thorchain/doc/ contains Swagger documentation for the thorchain endpont.

• <tc:1317>/cosmos:

  • This endpoint interfaces with the Cosmos SDK. It provides access to Cosmos SDK endpoints that THORChain inherits by being built on the Cosmos SDK. The endpoints are version specific and the CosmosSDK version THORChain uses can be found at here. Tendermint informaiton can also be accessed via cosmos/base/tendermint - node_info example.

• <tc:1317>/bank:

  • The bank module in Cosmos SDK handles token transfers and balances. The <tc:1317>/bank endpoint allows you to interact with accounts, check balances, and transfer assets. See example here.

THORNode Keys

There are three key-materials on a THORNode.

1. Your operator key, which sends BOND, UNBOND, LEAVE transactions, and you can run this in any THORChain wallet, asgardex, thorswap, vultisig. You can remotely manage your node and this can UNBOND to get funds out if you brick it. If you lose this key you will lose access to your BOND.

2. All key material related to the Cosmos validator, which does not hold funds, and signs off on blocks, as well as posting in messages to the state machine. These messages are gas-free; the state machine actually will give the node address a free gas-unit. If you delete this key you will brick your THORNode, stop sending observations and accrue slashpoints. You will then get churned out 3 days later for bad performance and will probably lose 3 days of rewards. make relay also uses it, as it proves it owns the node pubkey when signing.

3. TSS key-material, which does not hold funds, and simply signs TSS. If you delete this key you will accrue keySignSlashPoints and get churned out. This key is encrypted and backed up in the chain itself every 3 days. It is encrypted with point 2, so you should backup point 2. The reason for this is something really bad happening on kubernetes that causes TSS key material to be 0'd out globally, which would permanently brick the vaults. this allows the network to reboot by distributing software to THORNode to extract the stored key-material on-chain and decrypt using the mnemonic for each node.

Ensure you back up your node keys so it can be recovered.

• Backup documentation
• Node Validator Restore Validator Guide
• THORNode snapshot Recovery Guide

See the following references for more information

• ADR 004: Keyshare Backups
• Implementation of Keyshare MR
• Implementation of Backup Tools

It is critical backups are created matinaned, if there are any questions, reach out in the #bare-metal-nodes channel within the Dev Discord.

Hardforks

Every few years, THORChain conducts a hardfork. During a hardfork, THORChain's data is moved to an archive, and the chain begins running on a new chain ID. This process ensures that the blockchain continues to operate efficiently and scales with the network's growth.

• Chain ID: The current chainid can be accessed via https://rpc.ninerealms.com/status or by querying the <tc:26657>/status endpoint on a specific node.

Hardfork History:

• ChainId = thorchain: Blocks 0 - 4,786,559

• ChainId = thorchain-mainnet-v1: Blocks 4,786,560 - 17,562,000

• ChainId = thorchain-1: Blocks 17,562,001 - Current

To construct the full history of THORChain, data from all three of these chain IDs are required.

Full Nodes vs. Archive Nodes:

• Full Nodes: Full nodes only store the most recent blocks, including the latest block. They allow participation in the network and provide up-to-date data but do not maintain the complete historical data, this do not chain data form previous chains.

• Archive Nodes: Archive nodes store the entire history of the blockchain, including data from all past blocks and hardforks. These nodes are necessary for retrieving historical data and providing a comprehensive view of the blockchain's state over time.

Node Requirements:

• Separate Node for Each Chain ID: Each Chain ID requires its own node to be run. You cannot run multiple Chain IDs on a single node. To maintain or access the full history of THORChain, separate nodes must be configured for each of the historical chain IDs.

If you require the full archive node dataset, you will need to request it via THORChain's Discord community. Due to bandwidth costs and DDoS concerns, this data cannot be offered publicly.