Building Blockchain Bridges: A Stellar-Pendulum Bridge Case Study

In this blog post, we will give a general overview of different approaches to build blockchain bridges. We will also take a look at the bridge between Stellar and Pendulum, what special challenges such a bridge imposes and how we are going to address them.

A blockchain is a self-contained system that stores and processes information specific to itself. New information is usually only fed into this system by submitting transactions and committing them on chain. The purpose of bridges is to overcome these limits of isolated blockchains and allow multiple blockchains to exchange information and tokens.

In its most general sense, a token transmission from blockchain A to blockchain B involves a source account and source asset in blockchain A as well as a target account and target asset in blockchain B and works as follows:

1. Reduce the amount of source tokens in the source account. This either happens by burning source tokens or sending them to some other account or some smart contract within blockchain A.
2. Increase the amount of target tokens in the target account. This either happens by minting tokens or sending them from some other account or smart contract within blockchain B.

The main function of a bridge is to coordinate between these two actions and to make sure that they meet the following criteria:

• Consistency: Step 1 and 2 always happen in unison with consistent amounts,
• Liveness: Any user can use the bridge at any time,
• Auditability: Anyone can check that the bridge works correctly.

It is easy to achieve auditability: everyone can inspect the public ledgers of blockchains A and B and ensure that the consistency criterion is met. Therefore, we will focus on consistency and liveness in this blog post.

Let us first consider a simple but limited bridge model to illustrate these criteria.

Cross-chain atomic swaps

A cross-chain swap [1] involves two users: Alice and Bob. Each of them owns an account in blockchain A and an account in blockchain B, respectively. Alice intends to bridge some amount of source tokens in blockchain A to some amount of target tokens in blockchain B. To this end Alice and Bob execute the following two steps:

1. Alice transfers source tokens from her account in blockchain A to Bob’s account in blockchain A.
2. Bob transfers target tokens from his account in blockchain B to Alice’s account in blockchain B.

This clearly conforms to the two steps that define a bridging operation described in the introduction. Notice that this is a symmetric situation: at the same time also Bob is bridging target tokens from blockchain B to source tokens in blockchain A.

In order to satisfy the consistency condition, Alice and Bob need to ensure that either both steps happen or none of them — neither of the two parties can be guaranteed to be trustful. We say that such a swap is atomic. This is clearly in their best interest — otherwise, either Alice or Bob will lose tokens without receiving a reciprocal payment.

Cross-chain atomic swaps are practically useful because there are ways to achieve atomicity (and therefore consistency) through cryptographic means that do not require any dedicated involvement of either one of the two blockchains. Alice and Bob can use a payment channel-like protocol and communicate off-chain.

To be more specific, an atomic swap uses a hashed timelock contract [1], which functions as a two-way virtual safe. Such a contract exists in each one of the two blockchains. Alice and Bob do not transfer their tokens to the other user’s account directly but transfer to their respective blockchain’s contract as an intermediary. The contract introduces a time constraint such that transactions are reversed when either Alice or Bob do not fulfill their side of the trade within a predefined time frame. They use a cryptographic protocol to exchange the keys to unlock the tokens from each contract — this protocol will reveal the keys to both parties at the same time, which guarantees the atomicity condition.

Atomic swaps are a useful method of exchanging assets in a decentralized manner, however, they come with a few drawbacks:

• They require two parties. Expressed differently, atomic swaps do not guarantee liveness, as Alice is required to find some other user (Bob) before she can bridge her tokens.
• Both parties are required to be online and to actively cooperate throughout the swap.
• If one party does not continue with the procedure, then the other party has to wait for the refunding of the contract, which happens only once the atomic swap expires.

In the remainder of this article, we will consider bridges that can be used by a single party in order to overcome these limitations.

Tokenized Representation

Bridges that are usable by a single party typically have some directionality and allow for two distinct operations:

• Deposit: bridge the source asset in blockchain A to the target asset in blockchain B. The source tokens are transferred from the source account to some dedicated account in blockchain A; the purpose of this account is to lock the tokens and make them unusable in blockchain A. We will refer to this account as the bridge account. The bridge account is either a smart contract or it is an account that is controlled by a group of custodians associated with the bridge. The bridge then mints the target asset in blockchain B and transfers it to the target account.
• Withdrawal: bridge the target asset in blockchain B to the source asset in blockchain A. First, the user instructs the bridge to burn target tokens owned by the user in blockchain B. Afterwards, the bridge unlocks source tokens that are held in the bridge account and transfers them to some account in blockchain A.

Note that the bridge needs to be able to mint and burn the target asset in blockchain B, i.e., it is the unique issuer of that asset. In many cases such a bridge employs a one-to-one exchange rate between the source asset and the target asset for both deposits and withdrawals (minus some fees). In that sense, the target asset is an economically equivalent representation of the source asset on blockchain B. This is called tokenized representation [2] and the target token is a wrapped token (or cryptocurrency-backed token) of the source token. The wrapped token is one-to-one backed through the source tokens locked in the bridge account. We call blockchain A the backing chain and blockchain B the issuing chain. If we don’t distinguish between the original source asset and the wrapped token, then the bridge effectively moves tokens between the backing and issuing blockchains through deposits and withdrawals.

The way deposit and withdrawals are defined also ensures that there are always sufficient tokens in the bridge account for every withdrawal: the number of available wrapped tokens coincides with the number of tokens locked in the bridge account. This presupposes that the bridge does not use the tokens locked in the bridge account for any other purposes.

For such a bridge, the consistency condition can be broken down as follows:

• Whenever any user initiates a deposit and locks tokens in the bridge account, then an equivalent amount of wrapped tokens is minted and transferred to the target account.
• Whenever any user initiates a withdrawal and burns wrapped tokens, then an equivalent amount of source tokens is unlocked and transferred to the user’s account on blockchain A.

Let us focus on a situation where blockchain B is able to execute smart contracts, such as Pendulum. In this case, the part of the algorithm of the bridge that operates in blockchain B — minting and burning wrapped tokens — can be implemented as a smart contract. The advantage of this approach is that anyone can study and analyze the smart contract and ensure that it behaves as expected. Note that we build Pendulum using Substrate where crucial smart contracts can be directly built-in to the runtime in the form of a Substrate pallet. A pallet is a reusable building block of a Substrate chain but can also be thought of as a more efficient and lower-cost version of a smart contract and enjoys the same advantages, e.g., its behavior can be studied and audited.

The first condition then boils down to the following requirement: information about the state of blockchain A — namely whether a user-initiated a deposit — needs to be reliably conveyed to the bridge smart contract in blockchain B. The second condition similarly requires reliable information transmission about the state of blockchain B to the owner of the bridge account in blockchain A, whether it be another smart contract or a custodian.

Clearly, the last condition is the most crucial one: the bridge account can potentially hold and lock large amounts of tokens. If this account is governed by a smart contract, then anyone can study its behavior and ensure that it behaves as expected. However, firstly we need to be able to cope with situations where the backing chain does not support smart contracts, such as Stellar or Bitcoin. Secondly, even if the bridge account is controlled by a smart contract, then this smart contract relies on outside information about events on the issuing chain — we need to ensure that this outside information cannot be tampered with.

Chain Relays

Here we will discuss one approach that ensures that the bridge smart contract that operates on blockchain B always has reliable information about the activity on blockchain A. This ensures that it is able to react to any deposits to the bridge account in blockchain A by minting wrapped tokens and transferring them to the target account on blockchain B.

One naive idea is to present the signed transaction that transfers and locks tokens in blockchain A to the smart contract. How would the smart contract know whether this transaction has actually been incorporated into the ledger of blockchain A and is part of the currently valid state of that chain?

To answer this fundamental question, the smart contract can itself be programmed to work as a validator of blockchain A. A validator keeps track of the current blockchain state by listening to the blockchain network and storing a collection of all blocks that have been created in the network. The validator checks whether every block is valid and adheres to the rules of the blockchain (e.g., whether it contains sufficient proof of work in a proof-of-work blockchain) and assembles all blocks into a chain or tree of chains according to their logical order. By employing the rules of the blockchain the validator can then determine what subchain represents the currently valid state of the network.

A smart contract that operates like a validator is called a chain relay [3]. However, a smart contract in blockchain B cannot simply listen to the network of blockchain A — instead, users that support the relay can feed it the required information by executing smart contract calls. In a blockchain-based on Substrate, such as Pendulum, this can also be accomplished automatically through off-chain workers. As long as there is at least one honest supporter that ensures that the relay has complete information, then it can reliably construct the current state of blockchain A. Invalid information given to the smart contract would not be able to corrupt this construction because of the security guarantees of blockchain A itself. Otherwise, actual validators of blockchain A would be able to end up in inconsistent states, too.

This system works well and guarantees the first condition stated above. Similarly, we can run a state relay for blockchain B on blockchain A if blockchain A supports smart contracts as well. This would ensure that also the second condition holds: the smart contract can reliably react to any user burning wrapped tokens on blockchain B and unlock according tokens from the bridge account.

There is one caveat: running a normal validator as a smart contract is computationally expensive and would require high gas fees. Moreover, if we run two chain relays, one for blockchain A on blockchain B and one for blockchain B on blockchain A, then A would have to run the relay smart contract that re-runs blockchain B which itself re-runs blockchain A and so forth. This is clearly impossible — it would be like two boxes that contain each other.

For that reason, a chain relay is a light validator instead: it will not keep track of complete blocks but only of block headers. Block headers contain sufficient information to order them logically into chains or trees of chains and to decide what sub-chain represents the currently valid state. In contrast to a full validator, the relay will not validate the body of the block, i.e, the transactions it contains. For that reason, the relay in blockchain B does not have immediate knowledge of the actual transactions that take place on blockchain A and is not able to automatically react to a user locking funds in the bridge account.

Instead, any user locking tokens needs to prove to the relay that the transaction that locked the tokens has been incorporated into the ledger of blockchain A. This can be done efficiently: transactions in a block are arranged as a Merkle tree. The user specifies (1) the header of the block that contains the transaction and (2) the path of the Merkle tree of this block that leads to the user’s transaction. This is sufficient information for any light validator to cryptographically verify that the transaction is part of the valid blockchain state.

Lastly, we point out that a chain relay needs to calculate computationally expensive cryptographic primitives, such as hash functions. This is only viable if the smart contract system in blockchain B has native support for the cryptographic algorithms used in blockchain A — otherwise, gas fees would become prohibitive. Luckily this limitation does not apply if blockchain B is implemented in Substrate: core smart contracts can be implemented as Substrate pallets directly in the run-time, which makes them more efficient and low cost.

Stellar-Pendulum Bridge

In the remainder of this article, we consider the situation where the backing blockchain A is Stellar and the issuing blockchain B is Pendulum; this will be the first major bridge implemented in Pendulum. In the previous section, we discussed that it is possible to build a bridge between two blockchains that meets all required criteria if we can create a relay smart contract in either one of the blockchains. However, Stellar is not smart contract capable and for that reason does not allow for the construction of a relay for Pendulum. Hence, the following consistency criterion still remains to be solved through some other means:

• Whenever any user initiates a withdrawal and burns wrapped tokens in Pendulum, then an equivalent amount of source tokens is unlocked and transferred to the user’s account in Stellar.

Since there are no smart contracts in Stellar, the bridge account is owned and controlled by a custodian or group of custodians. Our overall design goal is to ensure that no single entity or a restricted group of entities acting as a group is able to seize control of the bridge. Stellar’s built-in support for multisignature accounts allows for up to 20 cosigners of the bridge account. In order to allow for the bridge to be decentralized and trustless we have to address the following two issues:

• How to enable the group of cosigners to evolve dynamically, grow beyond the limitation of 20 cosigners and be open for any party to join and leave freely?
• How to incentivize the cosigners to respect the two consistency criteria?

One approach is to propose an extension to the Stellar consensus protocol to lift the limit of 20 cosigners. However, an arbitrary number of cosigners could become computationally expensive and would pose only a partial solution to these two issues.

We will now discuss four approaches that address some or all these issues.

XCLAIM

XCLAIM (pronounced cross-claim) [4] is a framework that enables the trustless exchange of cryptocurrencies across blockchains. It is well-suited for bridging between pairs of blockchains where only the issuing chain is smart-contract capable and is recommended by the Polkadot community for this use case [5]. This makes XCLAIM perfectly suitable for the Stellar-Pendulum bridge.

In XCLAIM, the bridge account is called a vault. XCLAIM is based on the following four core features:

• Implement a chain relay for the backing chain in the issuing chain
• Employ collateralization in order to ensure that the vault exhibits good behavior
• Ensure that the economic value of the collateral exceeds the value of the vault
• Enable a decentralized network of vaults

We will discuss these features in sequence. We already explained above how a chain relay works. Note that the issuing chain Pendulum can implement such a chain relay because it supports smart contracts or, alternatively, Substrate pallets.

Collateralization means that the vault needs to lock some amount of a collateral asset in the bridge smart contract in the issuing chain (otherwise known as “staking”). This is usually the native asset, i.e., PEN in the case of Pendulum.

The vault needs to cooperate with the bridge smart contract and prove that it behaves correctly whenever a user initiates a withdrawal. This proof technique is based on the fact that the bridge smart contract is a relay for the backing chain. If the vault fails to do so within a certain amount of time, then the smart contract will slash the collateral of the vault and reimburse the user with an economically equivalent amount of the collateral asset.

For this to work properly the economic value of the total collateral of the vault needs to exceed the economic value of the total assets locked in the vault. As this condition depends on the exchange rate between the collateral asset and the assets in the vault, the bridge smart contract constantly monitors fluctuations in the exchange rate (using some oracle). If the value of the funds in the vault are critically close to the value of the collateral, then either the vault has to increase the collateral or the bridge will execute a forced withdrawal: it will liquidate the collateral, burn wrapped tokens and redeem users that hold wrapped tokens using tokens of the collateral asset.

The final core feature of XCLAIM is that any user can join the network and become a vault by providing collateral. This makes the network of vaults dynamic, permissionless, and decentralized. The downside of this approach is that XCLAIM needs to track wrapped tokens back to the vault that holds their according backing tokens, which makes the wrapped tokens non-fungible.

XCLAIM is currently being implemented by the two projects InterBTC and Kintsugi by Interlay.

RenVM

RenVM is an alternative approach to replace the role of the trusted custodian with a decentralised custodian. RenVM is powered by thousands of independently operated machines, known as Darknodes, which require bonds (collateral) of 100K REN tokens to run. The bond of every Darknode represents a commitment to good behaviour and can be slashed if 1) the Darknode behaves maliciously or 2) if it is responsible for the loss of assets. This works similarly to XCLAIM.

Darknodes are organized into non-overlapping groups called shards. Each shard uses multi-party computation (MPC) in order to generate a secret key. This secret key is unknown to any single Darknode in the shard. However, through the MPC algorithm a sufficient number of the Darknodes can cooperate to sign transactions for the bridge account. This enables each shard to securely lock assets into its custody.

Shards contain at least one hundred Darknodes and they are randomly shuffled once per day. This makes Sybil attacks difficult, as an attacker needs to own a large portion of the entire network to have a chance at corrupting any one shard. This also makes bribery attacks extremely difficult, requiring an attacker to collude with a large number of anonymous Darknodes in a short period of time, with minimal trust.

Musig

Musig [6] is a cryptographic alternative to the MPC approach in RenVM. It circumvents the limit of twenty cosigners for Stellar’s multisignature accounts through a principle called key aggregation: an arbitrary number of custodians, each having their own keypair, can act as though they have a single common keypair.

Put differently, Musig makes it possible to create multi-signatures that look like a single-key signature. This signature can be validated through a single public key that is aggregated from all the participants’ public keys. This means that verifiers don’t actually need to know the original participants’ public keys anymore — they can just be given the aggregated key instead.

There is no limit to the number of signers: any Stellar transaction will only use a single signature and an extension to the Stellar protocol is not required. There is already an implementation of Musig for Stellar, however, it currently only covers m-of-m signatures instead of the more general n-of-m signatures. A bridge needs to use the latter signature scheme, otherwise it would lack liveness if a single cosigner becomes unavailable.

The main downside of Musig is that it requires some elaborate effort of all cosigners in order to sign a single transaction: they need to execute three rounds of communication where they need to exchange pieces of cryptographic information.

Stellar Turrets

Stellar Turrets (also known as Turing Signing Servers) is a protocol that allows for the implementation of smart contracts directly in Stellar. It is more limited and less decentralized than an actual smart contract capable blockchain but we will show that some of these limitations can be overcome.

Usually, a multisignature account in Stellar is owned by multiple users — each of them having one cosigning keypair. If a certain threshold of these cosigners can be trusted, then this trust carries over to the account. In the Stellar Turrets system the cosigners are not other users but servers. Each server stores one keypair whose secret key is unknown to the public. Together they can cosign transactions for the Stellar account they are responsible for.

The behavior of the Stellar Turret servers is governed by a publicly visible algorithm, which determines what kind of transactions they can cosign. This characteristic makes them akin to smart contracts. Similarly to users that are the co-owners of an account also a certain threshold of Stellar Turret servers needs to be trusted. Moreover, the maximal number of servers for one account is limited to the maximal number of account cosigners in Stellar, i.e., twenty. One can combine Stellar Turrets with Musig to overcome this constraint.

One limitation of Stellar Turrets is that for each account they can only cosign one transaction per Stellar ledger (we point out that there is an early proposal to overcome this issue in the future). We can use Stellar channels in order to lift this limitation. This works because the bridge account always has sufficient funds for each withdrawal as there is a one-to-one correspondence between locked tokens in Stellar and wrapped tokens in Pendulum.

Conclusion

We presented four approaches that serve as a (partial) solution to the issues a Stellar Pendulum bridge needs to solve. We will adopt a hybrid approach or a combination of these approaches in order to fully address these issues.

Pendulum is an open-source project that is developed together with our community. Get involved and discuss or improve our concept for the Stellar Pendulum bridge:

Twitter: @pendulum_chain
Medium: @pendulum_chain
Telegram: t.me/pendulum_chain
Discord: discord.gg/ACVmQ4hg
Newsletter: https://pendulumchain.org/newsletter

Join Pendulum as a developer: https://pendulumchain.org/jobs

References

[1] Maurice Herlihy. 2018. Atomic Cross-Chain Swaps. In Proceedings of the 2018 ACM Symposium on Principles of Distributed Computing (PODC ‘18). Association for Computing Machinery, New York, NY, USA, 245–254. DOI:https://doi.org/10.1145/3212734.3212736

[2] https://github.com/renproject/ren/wiki#related-work

[3] Buterin, Vitalik. “Chain interoperability.” R3 Research Paper (2016).

[4] A. Zamyatin, D. Harz, J. Lind, P. Panayiotou, A. Gervais and W. Knottenbelt, “XCLAIM: Trustless, Interoperable, Cryptocurrency-Backed Assets,” 2019 IEEE Symposium on Security and Privacy (SP), 2019, pp. 193–210, doi: 10.1109/SP.2019.00085.

[5] https://wiki.polkadot.network/docs/learn-bridges#via-higher-order-protocols

[6] Maxwell, G., Poelstra, A., Seurin, Y., & Wuille, P. (2019). Simple schnorr multi-signatures with applications to bitcoin. Designs, Codes and Cryptography, 87(9), 2139–2164.