Validators are crucial participants in PoS networks. They are the ones responsible for validating transactions based on the network’s rules, and ensuring the security of the blockchain. In return for their work, validators receive rewards for their services.

Decentralization in the context of blockchain can mean many things. One may refer to decentralization at the software client-level, the infrastructure provider level, the geographical level, or the jurisdictional level. All of these facets are important, and we will go over each in this article.

Decentralization in general is crucial as it prevents concentration of power in any dimension and thereby enhances network security! You might even go as far as saying that the security of a chain is a function of its level of decentralization.

Geographical distribution of validators becomes important as a way to prevent a mass censorship of validators by governmental agencies or regions and in the event of a mass destruction of hardware in wars or natural disasters.

One of the best examples we have of censorship of networks from governmental agencies is when the Chinese government banned Bitcoin Mining. In January of 2021, China accounted for 21.1% of the global Bitcoin hashrate, ranking as the second-largest Bitcoin mining nation behind the United States, which led with 37.8%, as reported by the CCAF. However, following a series of aggressive crackdowns on mining, China's dominance in the global hashrate plummeted to zero in July and August. This decline culminated in a comprehensive ban on the crypto mining industry in September.

Source: Cambridge Centre for Alternative Finance

Any event, such as a war or a natural disaster, has the potential to take a large number of validators offline. If those validators are all located in the same region (or the same data centres), there is a higher likelihood of a network experiencing liveness / finalization issues. For example, taking a look at this sample of Ethereum execution layer nodes we can see that ~45% of them are located within the United States. If we assume that the geographical distribution of validators is similar, with 45% of these being in the USA - then, if the US should ban and shut down all validators within their borders, Ethereum would not be able to finalize blocks as >⅓ of the stake would be offline.

It is therefore imperative that each blockchain network has a diverse distribution of stake around specific jurisdictions and regions in order to always have a high participation rate.

Another aspect of decentralization and redundancy in a blockchain is on the software level, namely in client diversity.

Validator clients are used by validators to perform their duties, such as processing transactions and participating in consensus. Having multiple distinct clients used by validators improves the network's fault tolerance: if one client implementation experiences a bug, crash, or other issues, it won't bring down the entire network, because others will be using different clients too. This redundancy ensures that the majority of the network can continue to operate normally, preventing a large failure. With multiple clients, even if there was a bug in one client that leads to an invalid state transition, the overall network would remain on a valid state, preventing a split or fork of the chain.

A clear example of client diversity and how it can affect networks is Solana. Solana has encountered four block production halts in the past, which are often linked to failures within the validator client software. Currently, Solana's mainnet operates with two validator clients, one provided by Solana Labs and initially launched in March 2020, and the other introduced by Jito Labs in August 2022, which is a fork of Solana Labs' client.

There is also a third client in the works: Jump is actively developing Firedancer, a complete rewrite of the Solana validator client in C++. In addition, Firedancer has a modular architecture, offering the flexibility for targeted fixes and upgrades, with the aim of enhancing Solana's network stability and performance.

Comparatively, while Solana has 2 validator clients currently, Ethereum has 6 consensus clients (although only two of them, Prysm and Lighthouse, combined make up more than 70% of the market share) and 9 execution clients (but with geth being the most popular choice over 50% using it).

If we look to the Cosmos ecosystem, there will usually just be a single client implementation per chain. This gives less redundancy than e.g. Ethereum’s wide range of choices. The existence of a single validator client for Cosmos Hub poses a significant risk, given that if there was a bug, issue or crash in the Tendermint Core client, the Hub would not be able to operate normally. Additionally, the Hub has only 180 active validators as of January 2024, which is lower than both Solana (which has 1,944 validators on mainnet) and significantly lower than Ethereum (which has 7,422 validator nodes on mainnet).

Another issue that arises with low client diversity, as is the case with Cosmos and Solana, is that if one client dominates the network, it could lead to a central point of control, as that client and its developers would have significant influence over the network's operation. By encouraging different client implementations, no single implementation or team gains too much control over the network, preserving decentralization.

Cloud and bare-metal providers (such as AWS, Hetzner and GCP) are popular for node deployments due to their convenience and efficiency, as they simplify the process of running nodes by managing the underlying hardware. Self-hosting requires one to maintain the physical hardware, ensuring security and uptime yourself. Due to the complexity of self-hosting, many opt to instead use cloud providers. Unfortunately, the reliance on a small number of cloud providers introduces a centralization risk, since a significant portion of the network's infrastructure becomes dependent on these providers.

The network becomes vulnerable to the policies and stability of these providers. For example, if a major cloud provider faces issues and outages (such as AWS’s US-East-1 outages in July 2023) or decides to stop supporting blockchain activities (for example, Hetzner decided to ban crypto nodes which led to more than 20% of all Solana stake going offline back in February), it could have a cascading effect on the network.

So, what if AWS decided to ban crypto nodes? Or mass censorship or natural disasters affected validators in Germany or the US. Would your chain survive? Is it a resilient, decentralized network, safe from nation-state attacks if it can be taken down by  middle-management at GCP?

That’s where we come in. We run blockchain infrastructure: validators, RPCs, IBC relayers, DA nodes and other services from bare-metal in underrepresented jurisdictions and regions, such as Iceland, where no one else does. In this way, we aim to always be a healthy addition to any chain’s validator set.

Validators are crucial participants in PoS networks. They are the ones responsible for validating transactions based on the network’s rules, and ensuring the security of the blockchain. In return for their work, validators receive rewards for their services.

Decentralization in the context of blockchain can mean many things. One may refer to decentralization at the software client-level, the infrastructure provider level, the geographical level, or the jurisdictional level. All of these facets are important, and we will go over each in this article.

Decentralization in general is crucial as it prevents concentration of power in any dimension and thereby enhances network security! You might even go as far as saying that the security of a chain is a function of its level of decentralization.

Geographical distribution of validators becomes important as a way to prevent a mass censorship of validators by governmental agencies or regions and in the event of a mass destruction of hardware in wars or natural disasters.

One of the best examples we have of censorship of networks from governmental agencies is when the Chinese government banned Bitcoin Mining. In January of 2021, China accounted for 21.1% of the global Bitcoin hashrate, ranking as the second-largest Bitcoin mining nation behind the United States, which led with 37.8%, as reported by the CCAF. However, following a series of aggressive crackdowns on mining, China's dominance in the global hashrate plummeted to zero in July and August. This decline culminated in a comprehensive ban on the crypto mining industry in September.

Source: Cambridge Centre for Alternative Finance

Any event, such as a war or a natural disaster, has the potential to take a large number of validators offline. If those validators are all located in the same region (or the same data centres), there is a higher likelihood of a network experiencing liveness / finalization issues. For example, taking a look at this sample of Ethereum execution layer nodes we can see that ~45% of them are located within the United States. If we assume that the geographical distribution of validators is similar, with 45% of these being in the USA - then, if the US should ban and shut down all validators within their borders, Ethereum would not be able to finalize blocks as >⅓ of the stake would be offline.

It is therefore imperative that each blockchain network has a diverse distribution of stake around specific jurisdictions and regions in order to always have a high participation rate.

Another aspect of decentralization and redundancy in a blockchain is on the software level, namely in client diversity.

Validator clients are used by validators to perform their duties, such as processing transactions and participating in consensus. Having multiple distinct clients used by validators improves the network's fault tolerance: if one client implementation experiences a bug, crash, or other issues, it won't bring down the entire network, because others will be using different clients too. This redundancy ensures that the majority of the network can continue to operate normally, preventing a large failure. With multiple clients, even if there was a bug in one client that leads to an invalid state transition, the overall network would remain on a valid state, preventing a split or fork of the chain.

A clear example of client diversity and how it can affect networks is Solana. Solana has encountered four block production halts in the past, which are often linked to failures within the validator client software. Currently, Solana's mainnet operates with two validator clients, one provided by Solana Labs and initially launched in March 2020, and the other introduced by Jito Labs in August 2022, which is a fork of Solana Labs' client.

There is also a third client in the works: Jump is actively developing Firedancer, a complete rewrite of the Solana validator client in C++. In addition, Firedancer has a modular architecture, offering the flexibility for targeted fixes and upgrades, with the aim of enhancing Solana's network stability and performance.

Comparatively, while Solana has 2 validator clients currently, Ethereum has 6 consensus clients (although only two of them, Prysm and Lighthouse, combined make up more than 70% of the market share) and 9 execution clients (but with geth being the most popular choice over 50% using it).

If we look to the Cosmos ecosystem, there will usually just be a single client implementation per chain. This gives less redundancy than e.g. Ethereum’s wide range of choices. The existence of a single validator client for Cosmos Hub poses a significant risk, given that if there was a bug, issue or crash in the Tendermint Core client, the Hub would not be able to operate normally. Additionally, the Hub has only 180 active validators as of January 2024, which is lower than both Solana (which has 1,944 validators on mainnet) and significantly lower than Ethereum (which has 7,422 validator nodes on mainnet).

Another issue that arises with low client diversity, as is the case with Cosmos and Solana, is that if one client dominates the network, it could lead to a central point of control, as that client and its developers would have significant influence over the network's operation. By encouraging different client implementations, no single implementation or team gains too much control over the network, preserving decentralization.

Cloud and bare-metal providers (such as AWS, Hetzner and GCP) are popular for node deployments due to their convenience and efficiency, as they simplify the process of running nodes by managing the underlying hardware. Self-hosting requires one to maintain the physical hardware, ensuring security and uptime yourself. Due to the complexity of self-hosting, many opt to instead use cloud providers. Unfortunately, the reliance on a small number of cloud providers introduces a centralization risk, since a significant portion of the network's infrastructure becomes dependent on these providers.

The network becomes vulnerable to the policies and stability of these providers. For example, if a major cloud provider faces issues and outages (such as AWS’s US-East-1 outages in July 2023) or decides to stop supporting blockchain activities (for example, Hetzner decided to ban crypto nodes which led to more than 20% of all Solana stake going offline back in February), it could have a cascading effect on the network.

So, what if AWS decided to ban crypto nodes? Or mass censorship or natural disasters affected validators in Germany or the US. Would your chain survive? Is it a resilient, decentralized network, safe from nation-state attacks if it can be taken down by  middle-management at GCP?

That’s where we come in. We run blockchain infrastructure: validators, RPCs, IBC relayers, DA nodes and other services from bare-metal in underrepresented jurisdictions and regions, such as Iceland, where no one else does. In this way, we aim to always be a healthy addition to any chain’s validator set.