Stellar network: growth and decentralisation

The Stellar network is a decentralised peer-to-peer network of validator nodes. These nodes run the Stellar Core software that validates incoming transactions and applies them to the last ledger to form the next one. For reaching global consensus with other nodes Stellar Core runs the Stellar Consensus Protocol (SCP). In contrast to proof-of-work-based blockchains (e.g., Bitcoin), SCP does not consume enormous amounts of energy. Instead, each validator node explicitly defines sets of other nodes that it needs to agree with. These sets are called quorum slices and when you look at the quorum slices of all validator nodes they define a global network of trust relationships between these nodes. Every five seconds the validator nodes hold a vote in this global network about which transactions are applied to the current ledger. For avoiding ledger forks (safety) and for guaranteeing a functioning network (liveness) each validator node must choose its quorum slices carefully.

The issue: centralised quorum slices

A couple of months ago, the Stellar network was very centralised. The three nodes of the Stellar Development Foundation (SDF) were the only nodes commonly contained in the quorum slices of almost all other nodes. For example, the quorum slices of the SatoshiPay DE node were defined as four out of the following nodes:

This means that an outage of all SDF nodes or a network disruption between SatoshiPay and SDF would have brought our nodes to a halt. Other nodes were configured similarly with a strong reliance on the SDF nodes — including the SDF nodes themselves. The situation was also described here recently.

Joint community effort

If nodes come to a halt, then this is fine from a safety point of view because we don’t end up with ledger forks. However, a halted network is of use to nobody. The way to prevent this is clear and was the goal of the Stellar network right from the start: add more validator nodes and use decentralised quorum slices.

A growing network

In January we launched three full validator nodes around the globe in the Stellar network and opened up our fast API for querying the ledger. Our motivation was not only to provide a solid base for the community and for SatoshiPay’s products. We also want to serve as a role model for how to run a validator in the Stellar network so others can build on our expertise and run their own validators (see also parallel catchup script).

In the last 6 months, we have seen many new professionally maintained validator nodes join the network and others who improved their setup by publishing a history archive: LOBSTR, Coinqvest, Wirex, Sakkex, Eno, and there are more coming up.

Decentralised quorum slices

At SatoshiPay, we have a strict policy of only adding a validator to our quorum slices if it meets all of the following criteria:

• Publishes a history archive
• Sensible quorum slices
• Direct and verified contact with the node’s operator(s)
• Announce quorum slice changes 24h in advance

The new situation with more full validator nodes that match those criteria allows us to address the issue described above. The current quorum slices of the SatoshiPay DE node are defined as 5 out of the following nodes and sub-quorum slices (see live data in Stellarbeat):

With this configuration, no single entity can bring our nodes to a halt anymore and because all nodes in our quorum slices have chosen diverse and reasonable quorum slices as well we do not sacrifice safety either.

One might wonder why we only picked one Coinqvest node and one Lobstr node even though they both run two. The reason is that if we’d use a sub-quorum slice with two out of two then the failure probability of our node would actually increase compared to the one-node situation.

The road ahead

We are happy that the Stellar community took the next step and professionalised further over the last few months. In a community effort, the network structure was decentralised and made more resilient. New validators join the network and the network gets more decentralised constantly. SDF intends to turn their full validators into watcher nodes now that the ecosystem grows — instead, they want to advance the technology and support the community with the ongoing decentralisation and growth of the network. In the future it will become even more important that validator nodes coordinate their configurations. Together with other validator operators and the SDF we are going to work on guidelines for this coordination.

Our experience with quorum slice definitions shows how complex they can become as the network grows and we are conducting research and are working on tools to facilitate the configuration of validator nodes.

Let us know if you run a validator node that meets our requirements or if you plan to spin up a new one. You can also meet us at Blockchain Week / Consensus 2019 in NYC.