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.
- 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.
- A Centaurus cluster may serve as a trusted distributed custodian for other services like
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.
