Introduction to Stellar Network and Stellar Lumens XLM. Part 4

Federated Byzantine Agreement Protocol on the Stellar Network.

Federated Byzantine Agreement or FBA is a kind of Byzantine Agreement in which all participants know of other participants that they deem important.

It is easy to see how and why Federated Byzantine Agreement applies perfectly as a solution to existing financial infrastructure. Regular banks today exist in a heavily regulated environment and they have specific requirements to the partners that they deal with. For example, these requirements may include a registration of a third-party institution with authorities, compliance with insurance requirements and so on. Because of this, Federated Byzantine Agreement is a consensus algorithm suitable for worldwide usage.

A network that uses Federated Byzantine Agreement waits for the majority of parties to agree on the validity of a transaction before deeming the transaction valid. Some participants may not give their opinion on the transaction until they hear back from the participants they consider important and so on. Essentially, this means that when the majority of the participants on the network agrees on the validity of the transaction, it is not feasible for hackers to roll the transaction back.

This is what Stellar Consensus Protocol (SCP) is based on.

The protocol has four main advantages. First, it brings decentralized control to the network because any party can participate in decision making and no central authority needs to give approval for consensus to occur. Secondly, the network has low latency and can function extremely quickly and efficiently. Third, the trust on the network is extremely flexible. Stellar users can trust any user or set of users that they choose. This means that a bank or other heavily regulated institution can decide what parties it will interact with based on its own set of criteria. It also means that banks or other commercial organizations can choose to include a non-profit in a list of users that need to agree on a validity of an operation. This way, a non-profit can help keep other players honest. Finally, SCP offers asymptotic security, meaning that the network can protect itself from attackers with extremely vast computing resources.


Membership in a Byzantine Agreement Network

There are several ways for a network that runs on Byzantine Agreement consensus to give membership to users. One obvious scenario is for a central authority to grant membership to a number of users. Ripple published an initial membership list that participants could later edit on their own. SCP is the first protocol that gives users maximum flexibility in choosing whom to trust.


FBA Quorum Slices. Behavior of nodes on the Stellar Network

One of the challenges that the creators of the Stellar network had to solve was the issue of attackers joining the network multiple times and outnumbering the honest users. In this scenario, traditional majority-based voting approaches do not work because a malicious party can join the network multiple times and get a majority of votes by doing so.

The Stellar network solved the issue by allowing each node on the network chose a quorum slice.

Here’s how this works: the network assumes that after a certain number of votes on a statement no properly functioning node will contradict the statement. This number of votes is called quorum slice or simply slice.

From a high-level view, the Stellar network consists of groups of nodes each of which participates in one or more slices.

Nodes on the Stellar network can be well-behaved or bad-behaved. A well-behaved node prefers sensible slices and follows the protocol, including responses to all requests that it receives. A bad-behaved node may not respond to any and all the requests that it gets. Bad-behaved nodes can behave arbitrarily, which in terms of Byzantine Agreement means that they suffer Byzantine failure. When a node is not well-behaved, it may be compromised. It is possible that it is suffering from a malfunction or that attackers have maliciously modified the software of the node.


Federated Voting on the Stellar Network

In essence, federated voting consists of nodes on a network exchanging two sets of messages. First, nodes vote about a message M. Then, after the voting occurs, nodes confirm the message M, effectively voting for the second time about the validity of the first round of voting.

From the viewpoint of a node on the Stellar network, there are three phases in this two-stage voting process when it comes to the status of a message. These phases are unknown, accepted and confirmed.

Initially, a node knows nothing about message M. From the perspective of Boolean logic, the message could be true, false or perpetually stuck in the unknown state.  If the first round of voting goes through successfully, the node may accept message M as true. Because nodes only accept statements that they agree on with other nodes, if A is a well-behaved node and it accepts message M as true, then M can’t be false.

There are two reasons as to why one round of voting is not enough. First, the fact that node A accepted message M doesn’t mean that other nodes on the network can do the same. The message could be accepted by node A and stuck for all other nodes. Secondly, if A makes a mistake, then accepting M doesn’t mean anything because well-behaved nodes on the network will reject M as false.