Introducing the Stellar Oracle
Our newly developed piece of infrastructure brings Spacewalk bridge one step closer to decentralization
As a follow up to the Spacewalk bridge concept that we presented a while ago, we are happy to announce the conclusion of an important and innovative piece of infrastructure that brings us closer to the vision of a truly decentralized bridge: the Stellar oracle.
Stellar is a popular blockchain focused on fiat currencies. With a market cap of over 2.8 billion USD, it aims to allow low-cost transactions and borderless worldwide payments. We emphasize the importance of Stellar for Polkadot and Pendulum because it has an abundance of diverse fiat-backed stablecoins that can provide great value for the DotSama ecosystem.
The problem
Bridging a token between two blockchains requires concerted actions on both chains: a token needs to be burnt or locked on one side and simultaneously an equivalent token needs to minted on the other side. A blockchain can usually only see its own state and therefore every bridge requires a reliable mechanism to exchange information between chains.
One of the caveats of bridging from and to the Stellar network, is how to prove that a transaction actually happened, avoiding the double-spending problem, among others. If inclusion proofs are not reliable, then an attacker could trick the target blockchain to mint tokens that are not backed on the source chain for example.
For blockchains whose consensus algorithm is based on Proof-of-Work (PoW) there is one standard method for implementing inclusion proofs: the target blockchain implements a light client that stores block headers of the source blockchain and how they are linked to each other. The longest chain rule allows us to reliably identify what block headers reflect the mutually agreed state of the source chain. Since the light client only stores block headers, it has no knowledge about transactions contained in each block. In order to prove that a transaction is contained in a block, one would usually employ a Merkle inclusion proof, like what is done in Ethereum and other blockchains that use Merkle trees to store the state of the chain. In this case, one would not need to provide all the information in the tree, but only the relevant pieces needed to traverse from the root to the desired leaf. This is a very efficient way to prove that a transaction is included in a block.
Stellar does not use PoW as its consensus algorithm. Instead, they have a specially crafted method called SCP (Stellar Consensus Protocol). SCP is fundamentally different to PoW as is based on the groundbreaking Paxos consensus algorithm and provides immediate finality. Unfortunately, it does not allow for use of the longest chain rule to prove to model inclusion proofs. Furthermore, Stellar does not use Merkle trees and therefore Merkle proofs are not possible either.
How the Stellar Oracle works
The Stellar Oracle uses special properties of the above-mentioned SCP, to build a mechanism that can reliably verify if a transaction was executed on the Stellar network. This means, in practice, that it allows third parties to prove to any Substrate chain that a certain transaction was included in a finalized block in Stellar.
The goal is for the bridged blockchain to be as certain as possible that a Stellar transaction was executed to be able to then act upon this information (e.g. by minting or burning tokens). We built our Stellar oracle to be as secure as the consensus protocol itself.
Inside SCP: organizations, quorum sets and tiers
To better understand how the Stellar oracle works, let’s first try to understand the important parts of the consensus protocol. Stellar validator nodes are organized and categorized into tiers, with Tier 1 being the most important one. The organizations that run the tier 1 validators are the most reliable and advanced Stellar teams, and the consensus decisions of their validators are weighted the highest. This set currently consists of a total of 23 validator nodes that are continuously exchanging messages to find consensus.
The validators are organized into quorum sets or slices, i.e. small collections of peers that a node trusts to convey information about the state of voting in the rest of the network. The quorum sets are defined in such a way that between two different quorums, there is always at least one Tier 1 node that is in both quorum slices (you can read more about this process here). Every 5 seconds, the validator nodes in Stellar vote on finalizing a new block (which contains a set of transactions that are to be executed on the Stellar network). This process of finding consensus on which block to finalize happens in different phases: voting, accepting and confirming on a common value and committing to it. This requires the validators to exchange lots of messages. Once nodes confirm that a value is committed, they ‘externalize’ this value, meaning that all validators agree that this is the outcome of consensus.
We utilize these messages containing ‘externalized’ statements to build a proof mechanism for our Stellar Oracle. If there is a quorum of Tier 1 validators that vote unanimously, then all non-faulty nodes in the Stellar network will eventually externalize/agree on the same vote.
Agents
The agents are the client applications responsible for two main activities: fetch and store the transaction hashes that Tier 1 validators gossip, and send proofs of validity of the transactions of our interest to Spacewalk.
The Spacewalk pallet has all the information about the set of Tier 1 Stellar nodes, their public keys, and all Tier 1 quorums. The agents will forward the relevant signed externalized messages from Tier 1 nodes to the Spacewalk pallet. Every Stellar validator signs its consensus messages so that signatures of such messages can be checked for their integrity. Remember that the public addresses of the 23 nodes in Tier 1 are well known. The Spacewalk pallet will then validate the signatures and can conclude that a specific block is final whenever it identifies that any Tier 1 quorum voted on that block.
For the reasons stated above, the Stellar oracle is, by design, at least as secure as the Stellar Consensus Protocol. And this means that it uses the same mechanism that SCP uses to decide that a block is final.
It’s worth mentioning that the set of nodes in the Tier 1 set, their quorum structure and signing keys are not constant, but they rarely ever change. And when they do, they need to first agree upon that through governance. When that happens, Spacewalk will also react to that and, via governance, update to the latest state of Tier 1 validators in Stellar.
You can check our project’s codebase here: https://github.com/pendulum-chain/spacewalk, and watch a full demo of the Oracle in action on our YouTube channel:
If you have any questions or contributions, feel free to reach out to us and also check our docs https://docs.pendulumchain.org/.
