Blog Article

Stellar Consensus Protocol: Proof and Code

Author

Stellar Development Foundation

Publishing date

Stellar concensus protocol

Proof-of-agreement

Today, as part of Stellar.org’s mission to expand financial access, we introduce our first white paper and new open-source codebase for a decentralized worldwide payment protocol.

The paper by Prof. David Mazières, Chief Scientist at Stellar.org, presents the Stellar Consensus Protocol (SCP), a construction for federated Byzantine agreement (FBA). SCP provides a way to reach consensus without relying on a closed system to accurately record financial transactions. SCP is the first provably safe consensus mechanism that simultaneously enjoys four key properties: decentralized control, low latency, flexible trust, and asymptotic security.

SCP is inspired by Bitcoin—we've taken our lessons from the space and added the ability to tolerate non-rational actors in an environment with low computing power.

This protocol is the basis of public infrastructure for money, making Stellar a blank canvas for people to design financial services that fit their lives.

Our goal is for SCP to make a profound difference in financial inclusion. Beyond our work at Stellar, however, we hope that SCP is a significant contribution to the distributed systems space. To get an understanding of consensus, read an overview of the white paper and explore other resources in our new Stellar Galaxy.

Here are the top ten highlights:

1. What is SCP?

SCP is the first provably safe construction for FBA. Unlike most existing approaches to consensus, it enjoys four key properties:

  • decentralized control
  • flexible trust
  • low latency
  • asymptotic security

As an FBA protocol, SCP guarantees safety in the face of non-rational behavior and requires only modest computing resources, lowering the barrier to entry.

Flexible trust means that users have the freedom to trust any combinations of parties they see fit. With asymptotic security, safety rests on digital signatures and hash families whose parameters can realistically be tuned to protect against adversaries with vast computing power. For illustration, imagine a password that can grow in character length as an attacker’s computational power increases.

2. How is the new code different?

We created an entirely new codebase designed with safety, minimalism, scalability, interoperability, and multiple implementations in mind. The core consensus server is as simple and economical as possible.

Live data is stored in standard SQL databases and served to clients from external web servers reading those databases. Long-term cryptographic data is written to commodity public storage service as flat files in standard XDR binary form, and can be freely downloaded or mirrored. Transactions are now collections of simple operations that can be composed in a variety of ways supporting multisig and other innovative arrangements.

The intention is to push innovation to the edges. We want local communities to have the infrastructure they need to build the products that work for them.

3. Where can I learn more about consensus?

Explore resources for all technical levels in our new Stellar Galaxy.

Beginner: If you’re new to consensus or just want to see it in a whole new way, browse the first chapter of our graphic novel.

Intermediate: Read a short technical summary of the white paper and create a test account with our developer tutorial.

Advanced: Explore the code and read the white paper.

All levels: Ask us questions and interact with others in the Stellar network on our public Slack channel.

4. What is (traditional, non-federated) Byzantine agreement?

Key characteristics include centralization and tolerance of arbitrary behavior.

The Byzantine agreement approach is to guarantee distributed consensus despite Byzantine failure. “Byzantine failure” describes arbitrary, including non-rational, behavior.

Non-federated Byzantine agreement requires unanimous agreement on system membership by all participants—it is a centralized system. Each node in the network must be known and verified ahead of time.

5. How does Bitcoin compare to non-federated Byzantine agreement?

Bitcoin assumes that rational actors control a majority of computational power and motivates would-be attackers to obey the protocol through coin distribution. Byzantine agreement withstands outside attackers with vast computing power but has closed membership.

6. What is federated Byzantine agreement (FBA)?

Key characteristics include decentralization and tolerance of arbitrary behavior.

FBA brings open membership and decentralized control to Byzantine agreement. Anyone can join. FBA determines quorums, or groups of nodes sufficient to reach agreement, in a distributed way. Each node decides which others to trust. Different nodes don’t need to rely on the same combination of trusted participants to reach consensus.

7. What is safety? What does it mean to guarantee safety?

A set of nodes enjoys safety if each node commits the same value for the same slot. For example, if I say x is the value for slot 5, and you say y is the value for slot 5, and x ≠ y, then we do not have safety.

Safety first! Guaranteeing safety means that even when nodes fail or misbehave, the system will prevent nodes from committing conflicting values for the same slot.

8.What safety guarantees does SCP provide?

SCP guarantees that as long as nodes maintain simple rules when choosing whom to trust, the system will protect them from Byzantine failures to the greatest extent mathematically possible.

In order to maximize the resilience of the SCP network, new nodes should establish connections that maximize the interconnectivity of the network. With a high level of interconnectivity, an attacker would have to compromise an unrealistic number of nodes to break the quorum intersection property underlying SCP’s safety guarantee.

Moreover, SCP guarantees that the safety of more established nodes is unaffected by the choices made by unestablished nodes.

9. Is the new system live?

Not yet. We wanted to open source the code for peer review and additional testing before we move the live network over. You can experiment and interact with our testnet or start your own. Sign up for our developer newsletter to be the first to know when the new system goes live.

Over the next week, we encourage people to send feedback on the white paper to [email protected]. We'll be publishing an updated version soon based on the feedback we receive.

10. Why is the spaceship in the graphic novel named the USS Hayashi?

Graydon Hoare, a Stellar Core developer, gave this project the codename Hayashi after the Hayashi track, which describes the stellar evolution path of the birth of a small star. We wanted to memorialize this pre-launch codename in our graphic novel.

Explore more at Stellar Galaxy.