Babylon Overview and Whitepaper - By Babylon Team

Disclaimer - This is part of our outside perspective series. Curious Cosmonaut Research is not the author we are simply highlighting some good threads and perspectives on the Cosmos ecosystem with their permission. We also, therefore, do not guarantee their accuracy.

Author: Babylon Team

Source: Blog

Babylon's Technical Paper can be seen here:

Babylonchain

Bringing Bitcoin Security to Cosmos & Beyond

BabylonchainBabylonchain

Babylon: Bitcoin Security for Cosmos and Beyond

Date: August 30, 2022

Babylon-101, blog 1

A bird's eye overview of the project

Babylon is a new Cosmos project whose vision is to leverage the security of Bitcoin for enhancing the security of Cosmos zones and other PoS chains. In this first post, we will give a bird’s eye view of the project and in the subsequent posts, we will delve deeper into its the various use cases.

Who are we?

Our team consists of consensus protocol researchers from Stanford and experienced layer 1 developers from all over the world. At our Stanford lab, our previous works include both basic research as well as collaborations with industry projects. For example, a recent work is a collaboration with Ethereum Foundation on improving the security of the Proof-of-Stake Ethereum beacon chain. We identified some critical attacks as well as designed optimal protocols to achieve the objectives of PoS Ethereum.

Bitcoin as a source of trust

Bitcoin is the most secure blockchain in the world, secured by the immense hash power of Bitcoin miners. Currently this security is used primarily to support one cryptocurrency: Bitcoin. The vision of the Babylon project is to leverage Bitcoin as a source of trust to benefit other blockchains in the broader ecosystem.

The value of this source of trust can be further broken down into two aspects

• Bitcoin is based on Proof-of-Work, while many other current and emerging blockchains are based on Proof-of-Stake. PoS chains as Cosmos zones have certain security limitations compared to PoW chains. A properly designed architecture leveraging Bitcoin can potentially remove these limitations. In fact, PoS and PoW have complementary strengths, and a properly designed architecture can obtain the best of both worlds.
• The security of a blockchain is determined in large part by the value of the resource that supports it. In a PoW chain, it is the cost of the hash power. In a Cosmos zone, it is the value of the cryptocurrency that is being staked. Viewed through this lens, there is a wide spectrum of blockchains at different security levels. Supported by the immense hash power of its miners, Bitcoin sits on one extreme of this spectrum. Smaller blockchains, such as Cosmos application-specific zones, sit near the other end of the spectrum. A properly designed architecture leveraging Bitcoin can enhance the security of these chains without compromising their autonomy.

Bitcoin as a reliable timestamping service

In Nakamoto’s whitepaper, the Bitcoin blockchain was introduced as a timestamping server powered by Proof-of-Work. It gives an irreversible time-ordering to events. In its native application, the events are the execution of various transactions on the Bitcoin ledger. In the present application of enhancing the security of other blockchains, Bitcoin can be used to timestamp events that occur in other blockchains as well. Each such event triggers a transaction that is sent to the miners, which subsequently inserts it into the Bitcoin ledger, thereby timestamping the event. These timestamps on Bitcoin can be used to resolve various security issues with the blockchain. The general idea of timestamping events in a child chain on a parent chain is called checkpointing, and the transactions that timestamp the events are called checkpoints.

The Babylon architecture

The Babylon architecture is shown above. It consists of three components with two levels of checkpointing:

1. Bitcoin, as the timestamping service.
2. The Babylon chain, a Cosmos zone, as the middle layer.
3. Other Cosmos zones, as the consumers of security.

An important design consideration is that Bitcoin has very limited capacity in carrying arbitrary data. In this context, the Babylon chain serves several functions:

1. It aggregates the checkpoint streams of many consumer zones so that only one checkpoint stream needs to be inserted into Bitcoin to simultaneously timestamp events in all the consumer zones.
2. Its checkpoints into Bitcoin can be made compact using cryptographic techniques such as aggregate signatures.
3. It receives checkpoints from the consumer zones via Inter Blockchain Communication (IBC).
4. It checks for the availability of the data behind the checkpoints of the consumer zones so that an attacker cannot timestamp unavailable data.

Use cases

1. Fast Stake Unbonding: Proof-of-stake chains require social consensus to thwart long range attacks and this leads to long unbonding periods. In Cosmos, this is typically 21 days. Bitcoin security replaces social consensus and reduces unbonding periods to 5 hours.
2. Bootstrapping new zones: Bitcoin security can be used to bootstrap new zones which have low token valuation.
3. Protecting important transactions: Bitcoin security can be used to protect important transactions while normal transactions get fast finality.
4. Censorship resistance: Transactions that are censored can use Babylon as a backup to enter the ledger.

Technology

The Babylon technology which supports these use cases consists of 1) core primitives for writing timestamps onto Bitcoin by the consumer zones and reading the timestamps on Bitcoin by the consumer zones; 2) protocols that use the timestamp information to realize the various use cases. Both the core primitives and the protocols will be described in the following posts.

This article is also available on Substack: Babylon: Bitcoin Security for All (substack.com)

Why is Stake Unbonding so Slow?

Date: August 30, 2022|

Babylon-101, blog 2

Proof-of-Stake blockchains such as Cosmos zones allow fast confirmation of transactions but very slow unbonding of stake, with repercussions on user experience and liquidity of the blockchain. Why?

Proof-of-Stake Chains and the Unbonding Period

Proof-of-stake (PoS) blockchains have seen widespread interest due to their energy efficiency. To secure the system, PoS chains require the validators of the blockchain to stake tokens before they can propose or vote on blocks. This enables the PoS protocol to hold protocol violators accountable, and slash their staked, i.e., bonded, tokens as punishment. This gives another incentive for honest participation besides the block rewards.

In addition to energy efficiency, one important advantage of PoS chains is fast finality: transactions are confirmed fast, of the order of seconds. In contrast, stake unbonding is very slow, of the order of weeks (Table 1). Many PoS protocols require a lengthy unbonding period to elapse before a withdrawing validator can take back its staked funds. During the unbonding period, the validators cannot participate in the PoS protocol and do not accrue any block rewards or interest on their stake. They also cannot move the staked funds and use them for other purposes. The immobility of stake over a long unbonding period not only degrades user experience and creates financial friction, but also reduces the liquidity of the coins in the PoS system. Interestingly, Proof-of-Work chains are polar opposite: transactions are confirmed slowly but hash power can leave the network at will.

Table 1: Unbonding period on different Proof-of-Stake blockchains such as Cosmos zones, PoS Ethereum [1], Avalanche, Algorand and Cardano [2]

Can Liquid Staking Help?

Liquid staking aims to alleviate the problem of stake being locked up in a PoS chain. To engage in liquid staking, users deposit their funds in an escrow that stakes these funds on behalf of the user. In return, the users receive a tokenized version of their funds, which they can trade freely in the market. For instance, by staking Eth in a liquid staking contract, the user gets a ‘staked Eth’ (‘stEth’ for short), which it can put up as collateral for borrowing and yield farming.

Despite enabling new opportunities in DeFi, liquid staking has its drawbacks:

• The stake underlying a liquid token can be slashed due to network problems, or adversarial actions by the validators that have the custody of the stake. Such events that are beyond the control of the owner of the liquid token, can nevertheless reduce, and in the worst case, destroy the value of the token altogether.
• If liquid staking is handled by a smart contract, it can have bugs leading to the theft of the staked funds.
• The risks above might reflect in a price difference between the actual stake and the corresponding token. For instance, the price of stEth tokens offered by Lido has recently dropped as much as 8% of the Eth price due to market volatility and under-collateralization of the positions backed by stEth.
• Pooling of the stake deposited to large liquid staking services hurts the decentralization of the PoS chain, and reduces the sovereignty of the users over their funds. For instance, the largest liquid staking pool, Lido, holds 32.1% market share of all the staked Ethereum in the Ethereum beacon chain. This value is just below the 33% that would be sufficient for an adversary to double-spend or stall the chain. The risks such cartelization of stake implies for Ethereum continues to be a source of worry for the community.

Why Is the Unbonding Period So Long?

Risks of liquid staking underlines the importance of reducing the unbonding period itself rather than finding work-arounds for the liquidity problem. For this goal, we have to understand what purpose the unbonding period serves, and why it is so long in the first place. Thus, we first look into long range attacks, the reason why PoS chains such as Cosmos zones adopted long unbonding periods.

Long Range Attacks on Proof-of-Stake Chains

Figure 1: The canonical chain. Old validators are shown in dark green, and the new ones are shown in blue. Upon withdrawing their stake, the old, dark green, validators are replaced with the new, blue ones.

Figure 2: Long range attack on the canonical chain. After withdrawing their stake, old, dark green, validators, e.g., the founders of the chain, are corrupted by the adversary. They then build a conflicting chain that forks from the canonical chain at a past block. On the conflicting chain, they inaugurate a new, purple, set of validators that are under adversary’s controls. The two chains look equally valid to clients that observe the system at a later time.

Security of the Cosmos zones rely on their ability to hold protocol violators accountable, and slash their stake as punishment. For instance, if validators sign and finalize two conflicting blocks to cause confusion among the clients, they can be identified as protocol violators by showing the conflicting signatures as evidence, and can subsequently be slashed. However, once the validators unbond, i.e., withdraw their stake from the chain, they can no longer be punished for protocol violations. As a result, an adversary can incentivize these old validators to stage a long range attack (c.f. Figures 1 and 2). A prominent example of long range attacks is the founders’ attack described below.

Before the attack starts, founders of the chain, i.e., the initial validators, withdraw their stake. Then, using their old keys, they build a new chain that conflicts with the existing, canonical chain. The conflicting chain forks from the canonical chain at a past block, where the founders, i.e., the old validators, constituted a majority of the validator set (c.f. Figure 2). On the conflicting chain, these founders withdraw again, and transfer their voting power to new validators with different keys, that are in fact controlled by the adversary (which can be the founders themselves!). This enables the adversary to continue building on the conflicting chain after the supposed withdrawal of the founders.

Long range attacks pose a serious threat to security since they can confuse late-coming clients to adopt a chain different from the canonical one adopted by the earlier clients. Unfortunately, these attacks are inherent to PoS protocols, which suffer from the nothing-at-stake problem. This problem arises when the same stake can be used multiple times to produce multiple conflicting blocks, as is the case for a long range attack. In comparison, Proof-of-Work chains such as Bitcoin, are not vulnerable to nothing-at-stake or long range attacks since the attacker cannot use the ‘same’ computation to build multiple separate blocks.

Mitigating Long Range Attacks: Social Consensus?

For protection against long range attacks, many PoS chains ask new joining clients and validators to identify a checkpoint block on the canonical chain with the help of a trusted source. For example, the suggested sources for a bootstrapping Cosmos light client include trusted websites, Discord channels containing the list of checkpoint blocks, or the trusted peers used to download the client code. Upon receiving a checkpoint block, clients can safely ignore conflicting chains built by old validators (c.f. Figure 3).

The reliance of the clients on an external trusted source is called social consensus to emphasize the subjectivity of the process that identifies the canonical, correct chain. Indeed, different peers might easily disagree about the canonical chain as there is no ground truth for the ‘correctness’ of the chain, unlike in Bitcoin, which always selects the chain with the most computational work as the ‘correct’ chain.

Although social consensus is a first step towards mitigating long range attacks, it comes with its own problems:

• Social consensus does not specify how to identify the trusted peers. As these peers can be different for different validators, it is often difficult to quantify the trust placed on them.
• In the case of a public trust source such as a website, social consensus exposes a single point of failure to potential attackers. What if the website that lists checkpoints gets hacked?
• Social consensus introduces issues around transparency, and can lead to centralization of chain-wide decisions around strong players of the blockchain ecosystem.

How does the Unbonding Period Fit In All This?

Figure 3: New joining client asks its peers for weak subjectivity checkpoints (the blocks with the green checkmarks) on the canonical chain. Upon observing the checkpoints, client can distinguish the conflicting attack chain (bottom) from the canonical chain (top).

Among the drawbacks of social consensus, the most serious one is its dismal latency: It can take days or weeks for all the trusted peers to agree on a checkpoint. This is due to the subjective and social aspect of the agreement process. For instance, the peers might be communicating via Telegram (c.f. Figure 3), where agreements on the chain would take much longer than, for example, the confirmation latency of a consensus protocol. That is why the last checkpoint on the canonical chain in Figure 3 is much older than the tip of the chain.

If the old validators can withdraw and create a conflicting chain while social consensus is still ongoing, the peers that should serve as the trusted source might fail to agree on the checkpoints. That is indeed why many PoS chain including Cosmos zones impose long unbonding periods. A long unbonding period means that the old validators must wait until social consensus terminates and a block is checkpointed on the canonical chain, before they can take back their staked funds. This in turn prevents the malicious validators from confusing the clients, as the clients would immediately identify the conflicting, malicious chain (bottom chain in Figure 3) as the one without the checkpoints. Old validators of course have the option to build a conflicting chain before taking their stake back. However, their stake might get slashed in this case due to double-signatures, and makes this attack highly unlikely in practice.

Conclusion

Long unbonding period degrades the user experience and the liquidity in a PoS system. Although some unbonding period is necessary to mitigate long range attacks, its length would be much shorter if social consensus could make decisions faster. Thus, in the next post, we will look into whether we can achieve a shorter unbonding period by replacing social consensus with a faster source of trust.

[1] 13 days was calculated for 130,000 attesters with an average balance of 32 ETH to accurately model the targeted attester numbers of PoS Ethereum, using Table 1 in this weak subjectivity analysis.

[2] Algorand and Cardano use key-evolving signatures, thus under an honest majority assumption, they can theoretically enable instant unbonding of stake. However, key-evolving signatures require bonded validators to willingly forget their old signing keys. This is not incentive-compatible as there might be a strong incentive for the validators to remember the old keys in case they later become useful. For this reason, Algorand still uses social consensus for checkpointing besides key-evolving signatures.

Bitcoin Security Beyond Unbonding

Date: September 1, 2022

Babylon-101, blog 5

PoS chains such as Cosmos zones can achieve Bitcoin-level safety for their transactions by using Babylon with a slow finality rule. To confirm a transaction via the slow finality rule, clients of the PoS chain wait until the timestamp of the PoS block containing the transaction becomes k-deep on Bitcoin. This way, clients can preserve the safety of high value transactions against double-spend attacks. Possibility of securing high-value transactions with Bitcoin enables Cosmos zones to support high value trades even at a low token valuation, thus facilitating the adoption of new zones for high value use-cases such as NFT transfers. By aggregating the Bitcoin timestamps of many Cosmos zones, Babylon enables these zones to simultaneously enjoy the same Bitcoin-level security provided by the slow finality rule.

Slow finality for Bitcoin safety

In the previous blog post, we have seen how Babylon helps reduce the unbonding period by timestamping unbonding requests on Bitcoin. Once a Bitcoin block timestamping an unbonding request is confirmed, i.e., becomes k-deep in the longest chain of Bitcoin, an attacker cannot overwrite the timestamp of the PoS block carrying the unbonding request by forking Bitcoin. PoS chains can thus grant unbonding requests as soon as they are confirmed on Bitcoin, without exposing themselves to posterior corruption attacks.

Unbonding request can be considered as an important transaction which is endowed with Bitcoin security through the timestamping process. Generalizing this process, we can attain a stronger notion of finality for certain important transactions: If a client waits until the timestamp of a PoS block becomes k-deep on Bitcoin, then that timestamp cannot be replaced by any conflicting block (unless Bitcoin itself loses security). This notion enables the client to obtain Bitcoin-level safety for transactions within such blocks, at the cost of a longer delay, lending it the name slow finality. This delay comes from the confirmation latency for the Bitcoin block (time to be k-deep) timestamping the PoS transactions.

Use cases of slow finality

Protecting important transactions

Clients of a Cosmos zone have the option to use slow finality to attain Bitcoin-level safety for crucial, high-value transactions. Consider the purchase of an expensive car. If the merchant waits until the payment is timestamped by a k-deep block on Bitcoin before the shipment, it can avoid any double-spend risk by the buyer. This is because such an attack would require the buyer to fork not only the underlying Tendermint chain at the risk of getting slashed, but also Bitcoin itself to remove the timestamp of the Tendermint block containing the payment transaction.

Bootstrapping new chains

An important use-case of slow finality is supporting high-value trades (e.g., NFT transfers) on new, bootstrapping Cosmos zones that initially have low token valuation. In the double-spend example above, an adversarial buyer might not hesitate to bribe the validators to fork the zone; since the financial impact of slashing would be small when the token has a low initial value. This results in the bootstrapping dilemma: the low initial valuation of the chain discourages users from high-value trades due to the safety attack risk, which in turn hampers any increase in the token value due to the low trade volume. With Babylon and slow finality, a double-spending adversary also incurs the cost of forking Bitcoin, which requires the purchase of tremendous amounts of hash power. Deterring the adversary from double-spend attacks, slow finality can thus break the bootstrapping dilemma by secure high value assets on the chain, and in turn, driving up the token value.

Bitcoin security for all

Via slow finality, Cosmos zones can provide Bitcoin-level safety to important transactions. However, this requires timestamping blocks from many zones on Bitcoin, with a prohibitive bandwidth requirement if these chains opt to send timestamps directly to Bitcoin. In this context, by aggregating and sending checkpoints on behalf of many zones, Babylon enables the whole Cosmos ecosystem to share the security offered by Bitcoin.

Checkpointing Consumer Zones to Babylon via IBC

Date: September 23, 2022

In the previous blog post Babylon: Bitcoin Security for Cosmos and beyond, we described the general architecture of Babylon.  In this post series, we give a deeper dive into how this architecture is implemented in the Cosmos ecosystem. This post explains how Inter Blockchain Communication (IBC) can be used as a natural mechanism for checkpointing a consumer zone to Babylon. We also ruminate on a generalization of this observation: an IBC connection between two zones effectively checkpoints the zones to each other and can potentially be a vehicle for sharing security.

Recall that the goal of Babylon is to checkpoint Cosmos consumer zones into Bitcoin, which functions as a secure timestamping service. At a high level, this checkpointing is performed in three steps:

1. Consumer zones send checkpoints to Babylon
2. Babylon sends checkpoints to Bitcoin
3. Consumer zones read checkpoints from Bitcoin

In this post, we focus on Step-1. We will cover the remaining steps in separate posts.

Remind me why checkpoints?

In our previous Babylon 101 series post,  we explained how consumer zone checkpoints can replace weak subjectivity by providing secure and objective timestamps. Such timestamps protect the zone against forks due to long-range attacks, and can bring many benefits, such as reducing stake unbonding period from a few weeks to a few hours, and beyond.

Why checkpoint via Babylon?

We showed that direct checkpointing from consumer zones to Bitcoin is not scalable. To address this issue, we presented Babylon – a checkpoint aggregation service. Babylon is designed to facilitate communication between consumer zones and Bitcoin. In this post, we focus on how consumer zones send checkpoints to Babylon.

What to checkpoint to Babylon?

The checkpoint data should be an immutable snapshot of the zone at a certain block height and must carry a proof of consensus, which proves that this snapshot has been committed by the majority (2/3) of the zone’s validators at this height.

Cosmos zone’s block header is a potential checkpoint since it is an immutable snapshot. The question is then how to add proof of consensus to it and communicate it from the consumer zone to Babylon.

Inter Blockchain Communication

There are multiple ways to implement communication between Babylon and other zones. However, Cosmos already provides a powerful tool for that: the Inter Blockchain Communication protocol (IBC).

IBC enables a relayer between two zones. It has two layers: the transport layer and the application layer. The transport layer establishes secure communication between the two zones, while the application layer interprets the messages (carried by IBC packets) sent between the two zones.

The transport layer is very important to us. This layer essentially establishes a light client of each zone inside the other. The light client of the sender zone maintains a header chain of the sender zone inside the receiver zone. The headers are downloaded from the sender zone (by an IBC relayer that connects to a full node of the sender zone) whenever there is an IBC packet from the sender zone. Most importantly, these headers are attached with the signatures of the majority of the validators of the sender zone, meaning that such signatures are exactly the proof of consensus we required above. Therefore, a working transport layer between a consumer zone and Babylon already allows the consumer zone to checkpoint its entire header chain to Babylon in a verifiable way.

This verified header chain carries a commitment to the state of the sender zone. It thus allows the receiver zone to verify the message carried by an IBC packet by verifying its inclusion in the sender zone’s state. Verified messages will then be processed by the application layer of IBC. This allows Babylon to send verifiable acknowledgments of the consumer zone’s checkpoints back to the consumer zone as verifiable timestamps.

Checkpointing via IBC is trustless. The clients that submit IBC packets are known as relayers. There are no trust assumptions on these relayers except existential honesty: As long as there is at least one honest relayer, IBC communication is possible. This makes IBC trustless: its security only depends on the security of the participating blockchains rather than any third party (contrary to most of today’s bridges).

Checkpointing via IBC

So how exactly do we use IBC for checkpointing? First, we establish a bidirectional IBC connection between the consumer zone and Babylon. This is already provided by the IBC transport layer. Once the IBC connection is set up, the consumer zone has an on-chain light client of Babylon and Babylon has an on-chain light client of the consumer zone.

Checkpointing to Babylon consists of three steps (Figure 2):

1. The consumer zone on a regular basis ping Babylon by sending IBC packets. Since IBC takes care of sending signed consumer zone block headers, the checkpoint is submitted automatically, and the message itself can be an arbitrary string. This checkpoint can be submitted by anyone in the consumer Zone. The checkpoint is published on the ledger and submitted to Babylon’s mempool by an IBC relayer.
2. Babylon records the checkpoint in its ledger.
3. Babylon writes an acknowledgment message and sends it back to the consumer zone as an IBC packet. This acknowledgment includes a proof of the checkpoint inclusion into a Babylon block. Again, this is submitted to the consumer zone mempool by an IBC relayer.
   

IBC as a general vehicle for security sharing

We use IBC as a natural mechanism for checkpointing a consumer zone to Babylon. More generally, an IBC connection between two Cosmos zones can be viewed as a checkpointing mechanism between the two zones. The fact that IBC connections already exist between many Cosmos zones, therefore, means that there is in fact a lot of checkpointing across the zones in the Cosmos universe. It does not escape our notice that these IBC connections can potentially be a basis for security sharing in the Cosmos ecosystem.