What is Stellar XLM? A Deep Dive into Stellar Consensus Protocol (SCP)

By Jay Fried

As everyday tasks become simplified in 2019, the way that we move money to pay for goods and services in a Global Economy is still very complicated. As other industries are working to simplify the buying experience. The banking and payments industries insist on complicating what could be a very simple process. Merchants are still stuck paying high fees to process credit cards, and they are forced to wait multiple days to receive the value for the goods and services that they supply immediately. The process of people exchanging cash is extremely simple and can involve as little as 2 people. However, when you bring a credit or debit card into the mix, a 2 person transaction now includes many others that will touch the payment before it goes from sender to receiver.

As we move into 2019, we should be able to move value in any form as easily as we can move data. Now you may be thinking, I can do this with Venmo, and you are right. But what happens when you leave the U.S or send money out of the U.S.? Or if you want to send over $10,000? And how about for the receiver, who has to pay 1.9% or wait 3-5 days to receive the funds? The movement of value from one person to another should be completed in near real-time and incur virtually no fees.

In this article, we will look at the Stellar Network, which is a hard fork of Ripple. The 2 protocols have some similarities but there are also key differences that we will explore. We will dive into Stellar and the Stellar Consensus Protocol, also known as SCP. We will also look briefly at how it compares with Ripple as well as other distributed ledger protocols.

What is Stellar XLM?

At a high level, Stellar is an open-source and decentralized financial platform with a native currency XLM. It is used to execute fast, secure, cross-border payments. The protocol is used for digital currency to fiat currency transfers which allow cross-border transactions between any pair of currencies.

History of Stellar

Stellar began in 2014 when it forked from Ripple. The fork occurred because Jed McCaleb (Ripple Co-Founder), had a differing financial philosophy and vision from other members of the Ripple team.

what is stellar Byzantine fault tolerance Stellar Lumens XLM proof of work federated byzantine agreement

The major difference between Stellar and Ripple is, Ripple is focused on providing financial solutions to banks and other financial institutions. In addition to that, Stellar also aims to provide a system that provides an easy platform for people to transfer value to one another. For more on Ripple and how it uses XRP to gain instant liquidity, check out this article.

Stellar Development Foundation (SDF)

The Stellar protocol is supported by the Stellar Development Foundation. SDF is a nonprofit organization that is incorporated in Delaware. The foundation was created to develop the Stellar Consensus Protocol (SCP), and create an open-source reference implementation that forms the Stellar Network. The Stellar Development Foundation is headed up by Chief Scientist and Stanford Professor, David Mazières.

Stellar vs Ripple

Initially, Stellar used the Ripple Consensus Protocol. A hard fork in the Stellar network gave the team an opportunity to come up with a proprietary consensus protocol, which is known as the Stellar Consensus Protocol (SCP).

Federated Byzantine Agreement (FBA)

After creating the new protocol, the Stellar Development Foundation also created a new consensus algorithm. The algorithm is known as, Federated Byzantine Agreement (FBA), and is based on completely new code from the Ripple protocol. The new code and white paper for the new algorithm were released in April 2015. The system went through a series of testing and upgrades before finally going live toward the end of 2015.

XLM | The Coin of the Natives

Originally the native coin of the Stellar network was called Stellar STR. After the network was upgraded in 2015, STR was changed to XLM to avoid confusion with the name of the network vs the name of the coin.

100 Billion Lumens (aka XLM) were initially created, and XLM is an inflationary coin. The Stellar network has built in a fixed inflationary mechanism, and new Lumens (XLM) are added to the network at the rate of 1% per year. The network also collects a base fee for each operation the transaction, the funds from the base fees are added to the inflationary pool. At the time of writing this article, the base fee is $0.000007 USD. The fee is designed to prevent an attacker from flooding the network with malicious transactions.

what is stellar Byzantine fault tolerance Stellar Lumens XLM proof of work federated byzantine agreement

Anyone can submit ideas for improvements to the network, anyone who holds Lumens can vote on where the funds in the pool should be distributed. Each week, the protocol will automatically distribute the appropriate amount of Lumens to any idea that receives at least 0.05% of the vote from all accounts on the network.

Stellar Consensus Protocol

You now have a basic understanding of the Stellar network and Stellar Development Foundation. Let’s dive deeper into the Stellar Consensus Protocol. As we’ve covered in previous articles, a consensus indicates achieving agreement across many validators within a network. Unlike a bank, that has a single centralized ledger of account balances, the validators must all agree on each new ledger of transactions they receive them.

The network must be tolerant of validators that lie or send incorrect messages to other validators. This process of coming to an agreement is called consensus and should solve the classic problem in cryptocurrency known as Double Spend.

Ways to Reach Consensus

Proof of Work (PoW)

There are several protocols for achieving consensus within a network. Bitcoin uses Proof of Work (PoW), as we have covered in our Deep Dive into the Byzantine Generals Problem and Consensus Algorithm Proof of Work. Proof of Work is a protocol in which nodes on the network compete with one another using computing power in order to solve cryptographic puzzles.

Byzantine Fault Tolerance (BFT)

Many other protocols in the distributed ledger space have implemented some form of Byzantine Fault Tolerance (or BFT). Using BFT protocols, validators send messages back and forth to one another. They will also use a validator voting process, whereby a new ledger is confirmed if 66% of validators agree on the validity of the ledger. This method is significantly faster and cheaper, compared to Proof of Work. However, you give up some of the decentralization by having specific validators.

Professor Dave Introduces FBA

In 2015, Professor David Mazières introduced an alternative to BFT called the Federated Byzantine Agreement (FBA). It was an introduced as a truly decentralized version of BFT.

The best way to understand Stellar’s Federated Byzantine Agreement or FBA is to compare its features to PoW and BFT.

Open vs Closed Membership

The first feature we will look at is Open vs Closed Membership. This can also be thought of as who is allowed to participate in the consensus process?

Proof of Work

In proof of work, anyone with a node capable of mining can participate in the consensus process. Miners can also come and go as they please from the network without affecting the consensus. Think of them like Uber drivers, log in when they want to make some cash when they log out people can still get rides from other drivers.

Byzantine Fault Tolerance (BFT)

In a BFT environment, you have a recommended validator list. This list is usually defined by a central authority or a constitution that governs the system, this authority is usually the creator or company behind the protocol. Technically anyone could create a node as a validator, but you can only contribute to the consensus if you are added by the Central Authority. Validator election is handled differently depending on the protocol, however, it’s usually done in a democratic way amongst holders of the currency.

In the diagram below, the blue area is the area reserved for the Approved Validators on the network. The validators on the outside have not been eleceted as approved validators, the arrows indicate that they are rejected if they try to participate in consensus.what is stellar Byzantine fault tolerance Stellar Lumens XLM proof of work federated byzantine agreement

Federated Byzantine Agreement (FBA)

In Federated Byzantine Agreement, there is no recommended validator list chosen by a central authority. Instead, each validator is responsible to establish which other validators they trust. Their list of trusted validators becomes known as their Quorum Slice.

what is stellar Byzantine fault tolerance Stellar Lumens XLM proof of work federated byzantine agreement

The quorum slices of each validator will begin to overlap with one another, and this creates what is known as a Quorum. In FBA, a quorum is effectively a network-wide consensus on a transaction. Without the need for one centralized authority to decide on the validator list, an open membership network is created. Anyone can create a validator node and participate in the consensus. The only prerequisite is that one other validator adds you to their quorum slice as a trusted node.

what is stellar Byzantine fault tolerance Stellar Lumens XLM proof of work federated byzantine agreement

Because there is not a central authority deciding which nodes get to participate in consensus, the network’s construction allows for scalability and decentralization.

Safety Preference

According to the FLP Impossibility Proof. In distributed asynchronous systems like Stellar, a consensus mechanism can prefer at most 2 of the following 3 properties; Fault Tolerance, Safety, Liveness. This is a proven result and means that any distributed consensus system must sacrifice a preference for one of the three features.

FLP is named after Fischer, Lynch, and Paterson, who described this result in their 1985 paper; Impossibility of Distributed Consensus with One Faulty Process.what is stellar Byzantine fault tolerance Stellar Lumens XLM proof of work federated byzantine agreement

Fault Tolerance means that the system can survive if a validator on the network fails at any time. Many consensus protocols chose this as 1 of their 2 preferred properties. Protocols often differ when it comes to the decision of Safety vs Liveness. A fault-tolerant system can continue its defined purpose, maybe at a reduced level, rather than failing completely, when some part of the system fails.

Safety is basically a guarantee that something bad will never happen. In this example, the ‘bad thing’ would be an accidental fork. An accidental fork means that the network cannot agree on the ledger. With the safety property enabled, it will not accidentally fork, meaning the validators will not create transactions for 2 different ledgers. The network will essentially stop working, and no further progress will be made until the problem is resolved.

Liveness is basically a guarantee that something good will happen. In this example, the good thing is ledgers closing, or being accepted by the chain. This means that, despite any issues, a ledger will close to be live and accepting of future transactions.

This example accepts the possibility that validators may split into different ledgers. When you have multiple ledgers this is known as an accidental fork and opens up the possibility of double spending.

Safety vs Liveness

When we compare Safety and Liveness, we know that in a distributed ledger system you cannot have both safety and a system that will always continue to make progress regardless of the circumstance.

Proof of work favors liveness over safety. This means that if validators in a specific region of the world are cut off from the network for some reason, a fork in the Bitcoin blockchain would occur. Miners in the area that is off the network would begin building on one chain and miners everyone else would be using a universal chain. This would obviously open up the issue of double spend.

BFT protocols tend to vary in preference for safety vs liveness. However, the Stellar Consensus Protocol (SCP) of Federated Byzantine Agreement, favors Safety. In the event that an accidental fork occurs, the network will come to a halt until a consensus is achieved. This feature is key in attracting central banks and regular banks to their distributed ledger technology.

Latency

The 3rd feature we will look at is low latency, also known as transaction speed. When we look at Bitcoin’s proof of work, the computational puzzles involved in mining a block take approximately 10 minutes to complete. Since Bitcoin favors liveness over safety, 6 blocks must be confirmed to confirm your transaction is included on the primary chain. This causes true transaction times in the range of 60 minutes.

Unlike with proof of work, there is no mining process in BFT or FBA, it is just message passing with a voting process. Because of this, the transactions process much faster, generally every 3-5 seconds. In addition, because SCP favors safety over liveness, you do not need to wait for several ledgers to be confirmed. This preference for safety shortens the transaction by over 12x. To help illustrate this process more have a review of the article on The Longest Blockchain.

Asymptotic Security

The last feature we will explore is Asymptotic Security. It sounds like a mouthful, but at the core what it means is that no amount of computing power can overtake the network.

By comparison, proof of work does not employ asymptotic security principles. We have discussed in previous articles the possibility (especially with large mining pools) that a group or groups could control 51% of the network and thus create a double spend issue.

When you look at BFT and FBA,  an attack using computing power is not possible. This is because transactions are not approved using computing power to solve cryptographic puzzles. Instead, validators sign their approvals for new ledgers using their encrypted private keys.

Since BFT and FBA are asymptotically secure, there is no known amount of computing power that can break these protocols. Bad actors would be forced to collude in order to sabotage the network.

Forced to Collude

In BFT, over 66% of validators would need to collude in order to take over a consensus. This is highly unlikely when you consider that a central authority has control over which validators are allowed on the validator list.

In FBA, there is a complex web of overlapping quorum slices. This makes it near impossible for even a supermajority of nodes to collude and control consensus. An attacker could create 1 million validators. However, unless a majority of other validators add the rogue validators into their quorum slices they will be unable to affect consensus.

A Stellar User Experience

Now that you have a thorough understanding of Stellar and their consensus protocol. Let’s look at how money moves in a real-life user experience.

For this example, we will look at a simple transaction. Laura is a customer of ABC Remittance Company in the U.S. Laura works with many vendors all over the world and has to send regular payments to Jesse in Nigeria. Jesse is the receiver in this transaction, he is a customer at the Domestic Bank of Nigeria.

Now that we understand how Laura and Jesse fit into this scenario let’s bring in Stellar. Stellar is an open platform that connects banks, payment systems and people. In this example, both ABC Remittance Company and Domestic Bank of Nigeria have already integrated into the Stellar network.

what is stellar Byzantine fault tolerance Stellar Lumens XLM proof of work federated byzantine agreement

Laura sends a payment for $10 to Jesse through her remittance companies mobile app. Within fractions of a second, a message is exchanged with Domestic Bank of Nigeria to make sure that Jesse’s account is in good standing. If Jesse’s account is compliant a message will be delivered back to ABC that the payment can move forward.

what is stellar Byzantine fault tolerance Stellar Lumens XLM proof of work federated byzantine agreementABC Remittance is an Anchor on the Stellar network. This means that it can accept deposits and issue credits on the Stellar network. The remittance company will then deduct the funds being sent from the account that has been specified. The deducted funds are immediately moved over to ABC Remittance Pool Account. The money is then moved from the Pool Account into the Stellar Network by issuing credits in the amount of the dollars that Laura is sending to Jesse.what is stellar Byzantine fault tolerance Stellar Lumens XLM proof of work federated byzantine agreement

Once the system receives the credit from ABC’s pool account, the network searches for the best possible exchange rate amongst all the market makers on the network. Once the exchange is complete, Domestic Bank of Nigeria receives the $10 in the native Nigerian currency of Naira into their Base Account. Domestic Bank will receive the digital credits for Naira from the Stellar network. Domestic Bank will then credit Jesse’s personal account. This example assumes that $10 USD equates to 4,000 Naira.

what is stellar Byzantine fault tolerance Stellar Lumens XLM proof of work federated byzantine agreement

This is how $1 US Dollar can convert to any number of 180+ available currencies worldwide. The transaction is completed in 5 seconds or less. And it is all done for a fraction of a fraction of a penny.

Stellar Conclusion

In conclusion, Federated Byzantine Agreement (FBA) and the Stellar Consensus Protocol (SCP) provide an open membership, and therefore a decentralized alternative to BFT. The network has a very low latency, which closes transactions in 3-5 seconds. The network prefers safety over liveness, which makes it a favored protocol amongst banking standards. It is also asymptotically secure and not subject to a 51% attack like Bitcoin and other proof of work consensus models.

Currency Value:

At the time of publishing this article here are the values of the relevant currencies referenced in this article:
Bitcoin: $3,315
XRP: $0.30
XLM: $0.11
Bitcoin Dominance: 54.9%

References:
https://medium.com/@alexandratran/a-cursory-introduction-to-byzantine-fault-tolerance-and-alternative-consensus-1155a5594f18
https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf
https://en.wikipedia.org/wiki/Stellar_(payment_network)
https://www.stellar.org/blog/safety_liveness_and_fault_tolerance_consensus_choice/