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

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

A growing network

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

  • 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

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.

Connecting the world through instant payments