An accessible explanation of federated Byzantine agreement and quorum slices, the idea behind the Stellar Consensus Protocol, and how it differs from proof of work.
Quorum slices in a six-node example
The problem the paper starts with
The paper opens with a complaint about money: financial infrastructure is a patchwork of closed systems, the gaps between them make transactions expensive, and money moves slowly across borders. That friction keeps billions of people underserved. The author’s goal is a worldwide financial network that anyone can join, so new organisations can extend access to communities that are currently left out.
That goal creates a design tension. If joining is easy, users cannot count on providers to police themselves. If the network spans the world, providers will not all trust a single operator. The solution has to be a way for participants to agree on each other’s transactions without one boss, and that is a consensus problem.
Byzantine agreement in one paragraph
Consensus protocols let many computers agree on a single history even when some are faulty or malicious. Computer scientists call a malicious or arbitrarily faulty participant ‘Byzantine’. Classical Byzantine agreement protocols assume everyone agrees in advance on the exact membership list, which makes them hard to use on an open network. Bitcoin’s proof of work removes the membership list but at the price of heavy computing; proof of stake replaces computing with financial stake.
The federated idea: choose who you trust
In federated Byzantine agreement there is no global membership list. Instead, each node names the other nodes it considers important and will not treat a transaction as settled until a large majority of that group agrees. The set it relies on is its quorum slice. Those important nodes in turn wait for the nodes they rely on, and so on. Eventually enough of the network has accepted the transaction that rolling it back becomes infeasible, and only then do participants consider it settled.
A good analogy is how the internet is stitched together. No central body decides which networks connect; each operator makes its own peering and transit decisions, and those individual decisions add up to a global network. Quorum slices do the same for trust.
The safety condition is called quorum intersection: any two quorums, meaning groups that each satisfy every member’s slice, must share at least one honest node. If two groups could settle contradictory histories without overlapping, no protocol could keep the network consistent. The paper shows examples of networks that lack the property and explains that each node is responsible for picking slices conservatively, for example by making them large, so overlap is likely.
The four properties
The paper claims SCP is the first provably safe consensus mechanism to combine four properties:
Decentralised control. Anyone can take part and no central authority decides whose approval is needed.
Low latency. In practice nodes can agree in a few seconds at most, which suits payments.
Flexible trust. Users may trust any combination of parties. The author’s example is a small non-profit playing a key role in keeping much larger institutions honest.
Asymptotic security. Safety rests on digital signatures and hash functions whose parameters can be tuned to withstand adversaries with enormous computing power, rather than on an honest majority of mining power.
On safety, the author proves that SCP guarantees agreement under any node-failure scenario in which a guarantee is possible for an asynchronous protocol. On liveness, it avoids ‘blocked’ states unless failures make it impossible to satisfy the trust relationships the nodes themselves chose.
Costs and trade-offs
The model shifts a burden onto participants. In proof of work, nobody needs to decide whom to trust; the cost of computing does the work. In a federated system, each operator must choose slices wisely, and a careless choice can weaken safety for that node. The design also means the network’s resilience depends on the structure of those trust choices: if a few widely trusted nodes failed, many nodes could stall. The paper calls this a dependency on the trust relationships and treats it explicitly.
In exchange, it avoids the energy cost of mining and the capital lock-up of staking, which the author notes lowers the barrier to entry. That fits Stellar’s stated goal of connecting financial institutions and widening access.
Where to see it in practice
The protocol powers the Stellar network, which is one of the projects profiled on our ecosystem pages alongside the XRP Ledger and others that use different consensus designs. Comparing designs is a good way to learn what trade-offs each team chose. For a quite different approach to trust in a permissioned setting, see the Project Khokha article, which used IBFT.
Sources
- The Stellar Consensus Protocol: A Federated Model for Internet-level Consensus. David Mazières, Stellar Development Foundation (draft of 25 February 2016), 2016.
This article is our own summary and commentary. The reports remain the property of their authors and publishers; read the originals for full detail. Spotted an error? Tell us. See our editorial policy.