Architecture and logic of Stellar

Stellar is a decentralized platform for P2P currency transactions such as payments and exchange. Stellar’s goal is to bring banks, payment processors and people together for fast, cheap and secure transfers of funds. One of the main directions of Stellar is the exchange of Stellar-based assets using a built-in decentralized exchange.

The platform was created in 2014 by Jed McCaleb and Joyce Kim and initially operated on the Ripple protocol. Later on, a new original protocol was developed, the source code of which is publicly available. Work on the new protocol was launched in November 2015.

The main reason why Jed McCaleb had left Ripple and created Stellar was the accusation of the Ripple management that they are interested solely in increasing its own profits, that the payment system is centralized, and its management exploits it, among other things, by “swinging” the rate of the built-in currency of the XRP system. Thus, the platform was originally a “clone of Ripple”, eliminating its drawbacks related to the lack of transparency in financial flows, organizational structure, etc. Subsequently, the projects chose different development paths.

Stellar’s visibility has been boosted by the launch of several major projects in collaboration with IBM, a giant of IT.

Emission mechanisms and principles

The platform’s native token is Lumen. The ticker is XLM or STR. The more common ticker XLM will be used further in the text.

The coin is referred to by two tickers, since it was originally called Stellar, and not all exchanges have changed the designation. The name change occurred when the Stellar protocol was launched in 2015 in order to separate the name of the native cryptocurrency from the name of the platform and the non-profit organization that operates the platform.

100 billion Lumen tokens were issued when the platform was launched in 2014.

Tokens are generated weekly by the protocol to create an artificial inflation of 1% per year. Tokens are distributed to the address that receives more than 0.05% of the votes of the entire network. You can read more about voting on the official website . However, the situation in which one address on the network receives a sufficient number of votes is almost impossible. As a result a number of resources have appeared, which launch pools to collect votes and then distribute XLM among those who voted for the pool. Thus, the basic strategy for distributing inflationary tokens could be different, without requiring the use of third-party services to work.

The Stellar Foundation has developed a token ditribution program in order to diversify the distribution. Distribution of tokens:

50% – Direct Registration Program, which aims to distribute tokens to the largest number of people around the world. Programs are carried out in stages, while the methods of distribution may differ.
25% – distribution within the partner programs: for grants and various kinds of organizations that contribute to the development of the Stellar ecosystem.
20% – distribution among owners of BTC (19%) and XRP (1%).
5% to the Stellar Fund for operating expenses.

It is worth noting that much fewer tokens were distributed than originally planned. This is due to the fact that the owners of bitcoin wallets had to leave an application for participation. Unclaimed XLMs were sent to the Stellar Foundation and the Build Challenge. Stellar Build Challenge is a special reward program for development and integration within the Stellar ecosystem.

XLM is the native currency of the platform. To protect against transactional spam, a small fee of 0.00001 XLM applies to each transaction. XLM is also used as a “bridge” for multicurrency transactions (in case two assets are exchanged between which there is not sufficient liquidity but at the same time there is liquidity in a pair of each of them with XLM).

Starting with version 12 of the protocol, Stellar abolished the inflationary mechanism.

Consensus building mechanisms

The Stellar Consensus Protocol (SCP) works on the basis of the Byzantine Generals’ task. In distributed systems, the task of Byzantine generals is the task of reaching consensus in a network of unreliable calculators. It sounds something like this: the task of interaction between several remote nodes that received a message from one control center. Some of the nodes, including the center, can be compromised, but despite this, it is necessary to make the right decision.

SCP uses the Federated Byzantine Agreement ( FBA) model , which introduces the concepts of quorum and quorum slices to describe how it works. In a distributed system, a quorum is a set of nodes sufficient to reach consensus. The Federated Byzantine Agreement (FBA) introduces the concept of quorum slices (qourum slice) – a set of nodes, the opinion of which is enough to make a decision by one specific node.

The main difference of the Federated Byzantine Agreement (FBA) is that each individual node chooses quorum slices for itself, the solution of which it trusts. A node can select multiple trusted quorum slices and wait for them to approve the transaction. These nodes, in turn, also expect transaction approval from their quorum slices. In this way, a sufficient number of network votes are collected and a system-wide consensus is formed.

The intersection of quorum slices as an important parameter of the system’s performance and ability to lead to the final state. The protocol is only operational if any two quorum slices have an intersection. An illustration of the intersection is depicted below. In the first case, the groups of nodes have no intersection and, accordingly, the groups of nodes can come to different solutions. In the second case, the quorum intersection condition is met and the system will reach a system-wide consensus.

Each node is responsible for maintaining quorum slice intersections. The primary method is to responsibly select large quorum slices by a node whose members are authoritative enough to risk their reputation. Removing malicious nodes from a quorum slice does not lead to a loss of its integrity. Thus, the main parameter of the finiteness of reaching consensus is the establishment of trust links between the selected node quorum slices.

The process of reaching consensus takes the form of multi-stage voting: nodes propose transactions, vote for them and confirm the vote with a special ballot when the quorum threshold is reached. The confirmed results are then recorded and spread over the network. If the network does not come to one decision within the allotted time, voting goes to a higher round and the nodes vote again, while they can cancel their votes using a special function (abort) and vote for a different value.

A technical description of SCP is available on the official Stellar website at the link . It is worth noting once again that in order to reach consensus, there must be an intersection between quorum slices. In the current implementation, this is mainly achieved due to the fact that the nodes launched by the Stellar foundation are considered “trusted” and users add them to their quorum slices. This creates a risk in case of failures in the operation of these nodes, leading to a shutdown of the network.

It is worth noting that the algorithm does not include any reward mechanisms for validators, which can negatively affect an increase in their number and expansion of geography and, accordingly, at the level of project decentralization.

Architectural benefits and risks

The architecture of the Stellar protocol is based on the concept of registry (a ledger). The registry reflects the current state of the system: a list of all accounts, balances, orders of the built-in decentralized exchange, etc. The first register in history is called the genesis register (by analogy with the genesis block,). Each ledger is cryptographically linked to a unique previous state of the ledger, forming a chain. Updating the state of the registry occurs through the execution of rounds of the consensus algorithm.

One of the main features of Stellar is the ability for users to use any assets, create their own assets and exchange assets among themselves. All transactions with assets in Stellar, with the exception of XLM, are carried out on the basis of a system of credits. To implement these capabilities, Stellar has created special entities – anchors.

Anchors are trusted organizations that release assets in the Stellar network. The role of anchors can be performed, for example, by banks or payment systems. The participant chooses the anchor they trust in themselves, while trust in other system participants is not required. Each anchor has its own account.

Anchors perform the following functions:

Accept network member deposits and issue appropriate credits to the member’s Stellar registry address. Credit corresponds to some currency, for example, USD.
Allow you to withdraw funds through an issued credit.

Algorithm of user interaction with gateways:

The user makes a cash deposit to the anchor account.
The gateway issues a credit for the funds that ended up in the deposit account.
A user can send a credit to any user who has an account in the system.
The recipient of the credit can convert it into real currency by transferring the credits to the anchor account.

Thus, Stellar implements the ability to link digital assets with real assets. At the same time, additional restrictions are not imposed on the transfer of credits among users, for example, when the credit is linked to fiat currency, the user will be able to make cross-border payments quickly and with a minimum commission.

In order to protect the network from congestion by creating a huge number of addresses (malicious spam), there is a requirement according to which at least 0.5 XLM must always be on each balance sheet. It also helps to clean up the registry from abandoned addresses.

Licensing and legal aspects

In 2014, the Stellar Development Foundation was created. It is a non-profit foundation whose creators can benefit neither from its work, nor the sale of stocks. The Foundation is registered in the state of Delaware, USA. The fund’s initial funding of $ 3,000,000 was received from Stripe and subsequently redeemed with 2 billion lumen tokens (XLM). Also, 5% of the initial issue of tokens is traded on exchanges and used for operating expenses such as employee salaries, office expenses, educational and affiliate programs, etc.

Additional items of income for the foundation are annual contributions from its members and charitable contributions from third-party companies or individuals. The creation of the fund was primarily motivated by the desire to avoid criticism of the project, similar to criticism of Ripple, where executives were blamed for exploiting the system to make income for themselves.

In May 2017, the creation of a commercial organization Lightyear.io was revealed. It was supposed to focus on expanding the system of services based on Stellar, attracting partners, etc. Later the company was renamed to “Interstellar”.

All project software is licensed under the Apache license version 2.0. This license allows commercial use, modification and / or distribution.

Stellar is a middleware for integration between financial products and institutions. Stellar is not a licensed financial institution / operator. If an organization plans to accept deposits and make credits in the Stellar network, then it may need to obtain a specialized license, such as a Financial Services Provider (MSP) license. Integrators are responsible for meeting all KYC / AML authentication requirements themselves. However, Stellar has released tools to help organizations verify KYC / AML compliance.