Project Centaurus

Project Centaurus is the second layer payment network, exchange, and scaling solution for Stellar.

It's a platform with very high throughput that allows a few independent organizations to create a protected decentralized segment on Stellar Network with a multisig vault account. Users can instantly transfer/trade tokens inside the cluster with zero fees.

Use cases: Remittance/settlement networks

CBDC currencies

Privacy-centric services

Decentralized custodian for cross-chain swaps

B2C services like loyalty programs, games, financial apps striving to provide the abstraction on top of blockchain

Features

Payments and trades with instant confirmation and 5 seconds finality.

Built-in assets exchange.

Decentralized consensus with the trust model resembling a simplified SCP protocol.

Funds secured directly on Stellar multisig account.

Designed to handle more than 10,000 tps per cluster.

Zero transaction fees.

Ready-to-use private networks backed by public Stellar ledger.

Open-source (because the best things in the world are free of charge).

Low hardware requirements.

Sounds good? But wait, the platform also allows to build even more fascinating things in the future:

Sharding and infinite scaling with cross-cluster communication.

2-hop path payments.

Base reserve sponsorship for enterprise accounts.

Sponsored accounts with reserved funds for seamless users on-boarding.

Margin trading and lending.

Dark pool and anonymous transactions.

Assets with custom precision, non-divisible assets, NFT tokens.

Cross-chain swaps.

Auctions.

Concept

A deployed cluster (constellation) consists of one leading server (alpha) and 5-19

auditor servers. All servers are deployed by independent organizations or business entities,

and each party publicly confirms its identity with a standard Stellar ed25519 public key.

The organizations forming the constellation (and their public keys) won't be changed frequently,

therefore it makes sense to ship public keys with client software to allow direct signature

verification on the client side.

Clients communicate directly with the alpha server by sending atomic operation requests (account

funding, payment, exchange order, or withdrawal request). Each operation (quantum) is processed

and acknowledged by alpha which assigns a sequence number (apex) based on a FIFO principle,

and then asynchronously verified by all auditors. Alpha maintains all account records, balances,

and orderbooks. When the new quantum arrives, it validates the client's signature, executes

operation, and broadcasts processed quantum to all auditors. Each auditor verifies and applies

the quantum, sending back a signature, which essentially means its approval.

When alpha receives the majority of auditors' signatures, it aggregates them and sends to

the client. The client checks all the signatures and acknowledges the finality of the operation.

Funds received from clients are stored in a single Stellar account (vault) protected by

M-of-N multisig, where N is the total number of independent servers forming a constellation,

and M is the majority of votes (>50%) plus 1. Any withdrawal operation requires the majority of

signatures from the quorum participants and ensured by the underlying Stellar ledger.

Every 5 seconds alpha initiates state reconciliation (checkpoint). It calculates the hash

of current internal status, including all balances and orderbooks, signs it and sends to auditors.

Each auditor also calculates the hash for the internal state and compares it with the value

received from the alpha server. If the hashes don't match, auditor immediately halts processing

operations queue and falls out of consensus.

When the alpha can't reach consensus with the constellation, it stops all operations, rollbacks

to the last quantum confirmed by the majority, and starts processing only withdrawal requests.

In case if alpha is down, auditors may choose to deploy a new alpha server and proceed from the

last checkpoint or initiate an emergency refund, returning all funds back to the client accounts.

Initial quantum acknowledgment takes only a fraction of a second. It guarantees that the account

state was updated on the alpha server, and can be viewed as final for all subsequent operations

inside the constellation (like trading, transfers, etc.)

The finality (100% confidence) is ensured within a maximum of 5 seconds (one snapshot period).

Typically it takes only 1-3 seconds to receive the final confirmation depending on the workload on

auditor servers. Finality means that the quantum has been acknowledged and processed by

the majority of the auditors, so a user will be able to withdraw funds even if the constellation

is not operational. A quantum without a final confirmation potentially can be lost in case of the

alpha server reboot or problems with consensus. Therefore it is strongly recommended to wait for

the final confirmation before releasing the liabilities (goods, services, bank transfers,

payments on the blockchain, etc.)

Cross-cluster and cluster-ledger communication can be implemented based on simple on-chain swaps

between clusters or using payment channels as it's much easier to organize payment channels

between a few highly available clusters.

With such a design, clusters will be able to trade p2p or execute arbitrage path payments on

Stellar DEX, crossing the open Stellar offers with internal orders.

Use cases

Combination of characteristics described above opens a wide range of possible use cases:

Remittance and settlement networks may use Centaurus for their services as a private settlement

layer secured by Stellar ledger. Instant acknowledgments and high throughput allow building

something like SWIFT with minimum efforts. Correspondent banks run auditor nodes while domestic

banks and other financial institutions operate as clients. The setup is flexible enough to

handle payments from tens of thousands of banks alongside with automatic currency conversion

through the built-in exchange. The ability to specify custom permissioned logic and extended

compliance rules on the auditor level is also an important feature for enterprise networks.

layer secured by Stellar ledger. Instant acknowledgments and high throughput allow building something like SWIFT with minimum efforts. Correspondent banks run auditor nodes while domestic banks and other financial institutions operate as clients. The setup is flexible enough to handle payments from tens of thousands of banks alongside with automatic currency conversion through the built-in exchange. The ability to specify custom permissioned logic and extended compliance rules on the auditor level is also an important feature for enterprise networks. One of the most common problems with Stellar adoption is the need to match the underlying

protocol requirements: trustlines, base reserve, transaction fees. Various B2C services

(like loyalty programs, games, financial apps) strive to provide the abstraction on top of

blockchain to simplify onboarding and UX. With Centaurus, companies can deploy their private

protected clusters without transaction fees or base reserve requirements.

Users will have a comfortable UX while performing regular tasks on the constellation backed by

Stellar pubnet. At the same time, they will be able to withdraw their tokens/community points

to any Stellar wallet and trade or use them outside the sandbox provided by the company.

protocol requirements: trustlines, base reserve, transaction fees. Various B2C services (like loyalty programs, games, financial apps) strive to provide the abstraction on top of blockchain to simplify onboarding and UX. With Centaurus, companies can deploy their private protected clusters without transaction fees or base reserve requirements. Users will have a comfortable UX while performing regular tasks on the constellation backed by Stellar pubnet. At the same time, they will be able to withdraw their tokens/community points to any Stellar wallet and trade or use them outside the sandbox provided by the company. A Centaurus cluster may serve as a trusted distributed custodian for other services like

cross-chain swaps, sidechains settlement, escrow, etc.

cross-chain swaps, sidechains settlement, escrow, etc. Finally, deploying one large multipurpose constellation supported by all current Stellar

validators opens the way to scale pubnet throughput well beyond the current level, especially in

cases that require instant payments and HFT trading. Trading user experience will be very similar

to the traditional centralized exchanges. As soon as only ASSET-XLM trades pairs allowed,

markets liquidity should be higher. Besides that, it will be much safer, as the majority of

auditors must agree on the new token listing before it will be added to the orderbooks.

Rationale

Stellar SCP protocol is brilliant, and it proved the ability to work perfectly under the high load.

However, we all can agree that we need a second layer sharding solution that will gradually

decrease the workload on the mainnet and provide the overall 100x throughput increase in order

to be able to compete with traditional payment systems and exchanges.

We conducted detailed research on state channels that recently become increasingly fashionable

thanks to Bitcoin Lightning network concept. This technology may be a breakthrough for direct

p2p payment channels with high volumes, but it does not allow building the payment/exchange

network out of the box. Besides that, the concept underneath the Lightning technology itself has

a lot of flaws.

After a series of experiments with Stellar payment channels, we decided to return to the core

principles of all blockchains and Stellar in particular. When we talk about ledger sharding,

the most straightforward approach that comes to mind is to deploy one more blockchain and operate

on it, periodically synchronizing account states with the mainnet. Despite the seeming simplicity

of such an approach, a shard will have the same problems: limited throughput (due to the very

nature of blockchain), discrete confirmation time (clients have to wait for the new block to

arrive), high resources overhead (fast synchronous consensus is expensive). An ideal solution

should combine the reliability and decentralization of blockchain with performance and

responsiveness of centralized systems.

Async consensus principle

The cornerstone principle of the async consensus paradigm based on the assumption that consensus

participants may safely delay the operation validation if the assets are securely locked on the

account balance in the trusted system. Stellar provides the trusted environment and all required

security primitives out of the box: transactions, multi-sig accounts, configurable thresholds.

With such an approach, we need to get the majority of signatures from the vault account signers

to process deposits and withdrawals while the inter-cluster operations (like trading, internal

transfers) may be confirmed and processed by the alpha server almost in real-time and then

verified by auditors post-factum.

In most cases, the 99.99% confidence provided after the first confirmation from the alpha server

is enough, and clients may enjoy ultra-fast operations and user experience that can be achieved

only with centralized systems. Bad actors cannot manipulate operations or steal user's funds

unless they have the quorum majority. Of course, independent organizations that deploy auditor

nodes and establish a constellation are crucial for the overall system security.

This part closely resembles Stellar consensus model.

In the case of constellation crash or quorum conflicts, the client acknowledges unconfirmed

operations and recognizes them as failed. In the worst case, a few most recent operations may

be lost after the constellation cluster recovery, but it's not a problem since the balances are

preserved on Stellar ledger. Сonsidering the fact that 100% finality (confirmation from the

majority of auditors) can be reached in 1-3 seconds, the client may choose to wait for

the operation finality or treat the first confirmation as final depending on preconditions,

which is essential for enterprise-grade systems.

Simplicity principle

The simplicity is another basic principle of the proposed concept. It supports only basic atomic

operations, namely deposits/withdrawals, trades (submit or cancel order), and payments.

Due to the absence of preconditions, transactions, and fees, the operation flow is quite simple

and straightforward. The engine executes payments and trades strictly sequentially, following

the natural first-arrived-first-processed order. Account balances and orderbooks reside entirely

in memory to provide the maximum possible performance. The state can be easily restored from

checkpoint snapshots after the node restart or unexpected crash.

Auditors communicate directly with the alpha server, which means that they can be deployed behind

the firewall without public IP, and thus automatically protected from DDoS and flooding attacks.

In a setup with a single leading node, there is no nomination/voting/flooding network overhead.

Auditors simply agree or disagree with the next arrived operation sent by the alpha.

In the latter case, an auditor node just falls out of consensus and stops validating.

We aim to make auditor nodes deployment and administration as effortless as possible, ideally –

deploy and forget.

Binary XDR format used for communication and a superset of Stellar XDR data contracts ensures

maximum compatibility with Stellar Network and Stellar SDKs. The communication protocol itself

is minimalistic, as well as a FIFO matching engine. Fundamentally, all components are designed

to be plain and straightforward to provide reliability and predictable performance while exposing

minimal attack surface.

Supported platforms

Serverside code is implemented on .NET Core, so Alpha and auditors can be deployed on any server platform.

Clients can interact with the constellation using web interface (we are working on it right now), or use API directly from any platform that supports WebSockets (which is ubiquitous).

Roadmap

Team

We started working on this idea as a side project with @hawthorne-abendsen about half a year ago. It is still a prototype as we were fully concentrated on the development of StellarExpert and related tools. However, we make it to the point where we finally can share the project with the community, as we implemented minimal proof-of-concept functionality, verified our assumptions, and received some close to reality test results.

Our orderbook and matching engine can handle ~ 1,000,000 trades per second on a single processor core. We implemented snapshots logic and basic tests for on-chain deposits/withdrawals. So now we are almost 100% sure that the proposed concept is viable.

It's a huge project, and a challenging one, but it can really make a difference for Stellar Network. We invite community developers to join us and build it together. If this project makes it to the SCF winners list, we'll reserve most of the awarded lumens for the community project contributors. We can't offer a paid position, but we promise that we'll share the rewards and any future profits with those who help us to turn this prototype into the working product.

Project links

Code repository (open source): https://github.com/centaurus-project/centaurus

We are preparing a series of articles that will describe core concepts of the Centaurus project in depth. If you are interested, stay tuned, we have some exciting ideas to share.