Under the Hood: Nodes

THORChain, being built with the Cosmos SDK Tendermint Byzantine Fault Tolerant (BFT) design, is a sovereign Proof of Stake (PoS) blockchain, but with its own unique twist.

Node Count

First of all, any blockchain needs validating nodes to validate transactions, and to create and append blocks. In a BFT blockchain, all the nodes are in constant communication with each other, and there is a close correlation between the number of nodes vs the blocktime (or average time between each block). Practically, the current maximum node count is around 150–250 nodes. In THORChain’s case, the maximum allowable node count is Mimir controlled and set at 120 currently, aiming to keep average block time around six seconds. This number of nodes is lower than some other blockchains, but this is a limitation of BFT, and there are other designs that THORChain implements aiming to be as decentralized as possible.

2. Node Voting Power

In many Cosmos SDK PoS blockchains, each node’s voting power is determined by its share of staked tokens vs the rest of the other nodes. For example, if a total of 100 tokens were staked by all the nodes, a node with 40 tokens staked would have 40% voting power. In a BFT blockchain, nodes with combined voting power of two thirds or more are needed to reach consensus. So there are many cases where just a few nodes have >67% and can fully control the chain, even if the total node count is in the hundreds.

A related concept is the Nakamoto coefficient, which is the number of nodes with combined >33% of voting power, thus able to prevent consensus. Again, there are many cases where this is just a few nodes.

In contrast, THORChain implements equal voting power among all nodes, irrespective of their stake, or bond, as is known in THORChain. In other words, it’s a one node one vote design. Thus, with 100 nodes, it actually takes 67 nodes to agree to any transaction or block, and the Nakamoto coefficient is 34 nodes.

3. Node Bonding

THORChain places utmost importance on economic security, especially for the exogeneous assets that it secures, which are all the native L1 assets of other chains. The bonds pledged by validator nodes, are not just to allocate voting power to validate the chain, but also slashable if the nodes are attempting to be malicious. There is a direct relation between the maximum non-RUNE TVL that THORChain can accepts, in relation to the total RUNE bonded by the nodes, as detailed here. Finally, an integral part of the design is the Incentive Pendulum, which targets a balanced state of 2x RUNE value bonded to 1x non-RUNE TVL.

Running a THORChain node is both an expensive and profitable endeavor. They are securing valuable assets and need to ensure their node is running all the time. They are also binding a lot of their own capital, but the yield from swaps and block rewards (via the Incentive Pendulum) is there to reward their efforts.

In contrast, there are multiple other protocol/bridges, where the validators have much less at stake, compared to their TVL. This is always a misaligned incentive where malicious actors can more easily try to steal funds without bearing too much risk.

4. Node Delegation

In most Delegated PoS (dPoS) blockchains, most of the nodes are doxxed, and they actively promote their services so that other users will delegate tokens to them. This is so that the node operator can get a cut of the validation rewards, based on the quantity staked. There are also little restrictions for users to delegate to any node that they so wish. This can exacerbate the imbalance of voting power, as per point 2 above.

THORChain practices a more limited node delegation design, known as pooled bonding: https://docs.thorchain.org/thornodes/pooled-thornodes. In brief, there is a limited number of delegation slots per node (currently set to a hundred). Users need to be whitelisted by the specific node operator, before they can delegate, to encourage off-chain research and communication between the users and operators. Again, related to point 2 above, THORChain is a one node one vote design, thus preventing a popular node operator to easily obtain imbalanced voting power.

5. Node Churning

One of the unique designs of THORChain is the concept of node churning, which was briefly explained here: https://crypto-university.medium.com/under-the-hood-asgard-vaults-tss-and-node-churns-4767f3a5624b. Since every node will eventually be churned out (due to being the oldest, or lowest bonded, or least performing, or non-updated node), this reduces the risk of long range protocol capture. Also, fresh nodes are in constant “bond war”, since only the highest bonded nodes are churned in every round.

Want to keep updated with THORChain’s node status? Try: https://thorchain.net/nodes

Feel free to hop into the TC University Discord to chat about this, or any other THORChain questions that you may have.

Explore THORChain: Website, X, Telegram, Developer Discord.

Explore Maya Protocol, the first friendly fork of THORChain: Website, X, Discord, Telegram.

Decentralized, permissionless, non-custodial, trust-minimized, open-sourced, economic-secured, non-wrapped, native-to-native cross-chain swaps, savings and now, lending!