Explaining Babylon: How to Unlock the Security Value of Bitcoin?

Author: YBB Capital Researcher Zeke

Preface

In the modular era led by Ethereum, providing security services by connecting the DA (Data Availability) layer is nothing new. The concept of Staking now brings a new dimension to the modular track, using the potential of “digital gold and silver” to provide security for many protocols and public chains in the blockchain from Bitcoin or Ethereum. In narrative terms, it can be said to be quite grand. It not only releases the liquidity of trillions of market capitalization, but also is the key core of the future expansion. Taking the recent Bitcoin staking protocol Babylon and the Ethereum re-staking (ReStaking) protocol EigenLayer, which have respectively won massive financing of 70 million USD and 100 million USD, as examples. It is also not difficult to see that the top VC is very supportive of this track.

But with it came a lot of questioning, if modularity is the ultimate expansion, the two as a key member will inevitably lock in large amounts of BTC and ETH, so is the security of the protocol itself worth questioning? Will the crazy ‘nesting dolls’ formed by many LSD and LRT protocols become the biggest black swan in the future of blockchain? Is its business logic reasonable? Since we have already analyzed EigenLayer in previous articles, the following text will mainly discuss the above issues through Babylon.

Extend Security Consensus

The most valuable public chains in the development of the blockchain world are undoubtedly Bitcoin and Ethereum. The security, decentralization, and consensus of these two chains, which have been accumulated over the years, are the key cores that ensure their long-standing position at the top of the public chain. They also possess scarce characteristics that are difficult to replicate by other heterogeneous chains. The core of modular thinking is to ‘rent’ these characteristics to the demanders. At this stage of modular thinking, it can be mainly divided into two factions:

• The first type is to use a Layer1 (usually Ethereum) with sufficient security as the lower three layers or partial functional layers of Rollups. This solution has the highest security, orthodoxy, and can also absorb resources from the mainchain ecosystem. However, in terms of throughput and cost, it is not particularly friendly for specific Rollups (application chains, long-tail chains, etc.).
• The second option is to create a new entity with similar security to Bitcoin and Ethereum, but with better cost performance. For example, Celestia, which we are familiar with, achieves this by using a pure DA function architecture, minimizing the hardware requirements for nodes, and reducing gas costs, etc. In the shortest time possible, it aims to create a DA layer that is comparable to Ethereum in terms of security, decentralization, and strong performance. The disadvantage of this approach is that it will take some time to improve security and decentralization, and it lacks legitimacy and is in direct competition with Ethereum, which has caused it to be rejected by the Ethereum community.

And another faction in this category is Babylon and Eigenlayer, which create shared security services by using the asset value of Bitcoin or Ethereum through the core idea of PoS (Proof of Stake). Compared to the first two, it is a more neutral existence. Its advantage lies in inheriting orthodoxy and security while giving more value to mainchain assets and being more flexible.

The Potential of Digital Gold

Regardless of the underlying logic of any consensus mechanism, the security of the blockchain largely depends on how much resources it has to support it. A PoW chain requires a large amount of hardware and electricity, while PoS relies on the value of staked assets. Bitcoin itself is supported by an extremely large PoW computing power network, making it the most secure presence in the entire blockchain. However, as a public chain with a circulation market capitalization of 1.39 trillion US dollars, it only has two main use cases, which are transfer and payment of Gas.

For the other half of the blockchain, especially after Ethereum Shanghai upgraded to PoS, it can be said that the majority of public chains default to using different architectures of PoS to achieve consensus. However, due to the fact that the new heterogeneous chain itself cannot attract a large amount of capital staking, its security is highly questionable. In the current modular era, although Cosmos zone and various Layer2 can also use various DA layers to make up for it, they also lose their autonomy. For most old public chains or consortium chains that use the POS mechanism, it is basically impossible to use Ethereum or Celestia as DA, and the value of Babylon is to fill this gap and stake BTC to provide protection for PoS chains. Just as humans used gold to support the value of paper money in the past, BTC is indeed suitable to play this role in the blockchain world.

From 0 to 1

Releasing the ‘digital gold’ has always been the grandest and most difficult narrative in the blockchain. From the early sidechains, Lightning Network, bridging wrapped tokens to today’s Runes and BTC Layer2, it can be said that no matter which solution, there are inherent flaws. If Babylon wants to implement the security of Bitcoin, naturally, the centralized solution with the introduction of third-party trust assumptions should be the first to be excluded. Among the remaining solutions, Runes and Lightning Network (limited by extremely slow development) currently only have the ability to issue assets, which also means that Babylon needs to design its own ‘scaling solution’ to enable Bitcoin’s native staking from 0 to 1.

The basic elements that can be used to deconstruct Bitcoin are as follows: 1. UTXO model, 2. Timestamp, 3. Multiple signature methods, 4. Basic operation codes. The solution given by Babylon is based on the weak programmability and data carrying capacity of Bitcoin. Adhering to the principle of minimization, only the necessary functions for staking contracts need to be completed on Bitcoin, that is, BTC staking, slashing, rewards, and withdrawals are all completed on the mainchain. After achieving this from 0 to 1, the complex demands are handed over to the Cosmos zone for processing. However, there is still a key question here: how to record the data of the PoS chain on the mainchain?

Remote Staking

UTXO (Unspent Transaction Output model), designed by Satoshi Nakamoto for Bitcoin, its core idea is extremely concise. Transactions are nothing more than the inflow and outflow of funds, so the entire transaction system only needs to express these two forms: input and output. The so-called UTXO is when funds come in but not all of them are spent, the remaining part is the unspent transaction output (i.e. unspent bitcoins). The entire ledger of Bitcoin is actually a collection of UTXOs. By recording the status of each UTXO, it manages the ownership and circulation of Bitcoin. Each transaction will spend the old UTXO and generate new UTXOs. Due to its potential for scalability, it naturally became the starting point for many native scaling solution ideas. For example, using UTXO and multi-signature to create a penalty mechanism and the Lightning Network of state channels, or binding UTXO to realize inscriptions, runes, etc. for SFT (semi-fungible tokens). All of these are based on this critical starting point in order to become a reality.

And Babylon naturally also needs to use UTXO to implement staking contracts (Babylon is called remote staking, that is, the security of BTC is passed to the PoS chain through an intermediate layer), while ingeniously combining existing opcodes in thinking. In fact, the specific steps of implementing the contract can be broken down into the following four steps:

• Locking funds

Users send funds to an address controlled by a multi-signature. Through OP_CTV (OP_CHECKTEMPLATEVERIFY, allowing the creation of predefined transaction templates to ensure that transactions can only be executed according to specific structures and conditions), the contract can specify that the funds can only be spent when specific conditions are met. After the funds are locked, a new UTXO is generated to indicate that the funds have been staked;

• Conditional Verification

Calling OP_CSV (OP_CHECKSEQUENCEVERIFY, which allows setting a relative time lock based on the transaction’s sequence number, indicating that UTXO can only be spent after a certain relative time or number of blocks) can achieve time locking, which ensures that funds cannot be withdrawn within a certain period of time. Combined with the mentioned OP_CTV, it is possible to stake, unstake (after the staking time requirement is met, the staker can spend the locked UTXO), and slashing (when the staker behaves maliciously, the UTXO will be forcibly spent to a locking address and restricted to an unspendable state, similar to a burn address).

• Status Update

Whenever users stake or withdraw their staked funds, the creation and spending of UTXOs are involved. A new transaction output generates a new UTXO, while old UTXOs are marked as spent. This way, every transaction and fund flow is accurately recorded on the blockchain, ensuring transparency and security.

• Income Distribution

Based on the stake amount and stake time, the contract will calculate the corresponding rewards and distribute them by generating new UTXOs. These rewards can be unlocked and spent through script conditions after meeting specific conditions.

Timestamp

After having a native stake contract, it is natural to think about the problem of historical event recording of external chains. In Satoshi Nakamoto’s White Paper, Bitcoin Blockchain introduced a Timestamp concept powered by PoW, a mechanism that provides an irreversible chronology of events. In the native use case of Bitcoin, these events refer to the various transactions performed on the ledger. Nowadays, to enhance the security of other PoS chains, Bitcoin can also be used to timestamp events on external blockchains. Each time such an event occurs, a transaction sent to the Miner is triggered, Miner then inserted into Bitcoin ledger, adding a Timestamp to the event. These Timestamps can be used to address various security issues of the Blockchain. The general concept of timestamping events in a child chain on the parent on-chain is called “checkpointing”, while the transactions used to add timestamps are called checkpoint transactions. Specifically, the Timestamp in the Bitcoin Blockchain has the following important features:

1. Time format: The timestamp records the number of seconds since 00:00:00 UTC on January 1, 1970, and this format is called Unix timestamp or POSIX time;
2. Function: The main function of a timestamp is to identify the generation time of a block, assist nodes in determining the order of blocks, and assist the network in difficulty retargeting mechanism;
3. Timestamp and Difficulty Retargeting: The Bitcoin network undergoes a difficulty retargeting every 2016 blocks (approximately every two weeks). The timestamp plays a crucial role in this process, as the network adjusts the mining difficulty based on the total generation time of the most recent 2016 blocks, aiming to achieve a new block generation speed of approximately one every 10 minutes.
4. Validity Check: When a node receives a new block, it will verify the timestamp. The timestamp of a new block must be greater than the median time of several previous blocks, and cannot exceed the network time by 120 minutes (i.e., 2 hours into the future).

The timestamp server is a new primitive defined by Babylon, which allocates Bitcoin timestamps through Babylon checkpoints in PoS blocks to ensure the accuracy of the time series and prevent tampering. This server is at the top of the entire Babylon architecture and is the core source of trust requirements.

Three-tier Architecture of Babylon

As shown in the above figure, the overall architecture of Babylon can be divided into three layers: Bitcoin (as a timestamp server), Babylon (a Cosmos Zone) as the middle layer, and the PoS chain demand layer. Babylon refers to the latter two as Control Plane (the control plane, namely Babylon itself) and Data Plane (the data demand plane, namely various PoS consumption chains).

After understanding the basic implementation of the trustless protocol, let’s take a look at how Babylon itself connects the two ends using the Cosmos zone. According to the detailed explanation of Babylon by Stanford Tse Lab “1”, Babylon can receive checkpoint flows from multiple PoS chains and merge these checkpoints before publishing them to Bitcoin. By using the aggregated signatures of Babylon validators, the size of the checkpoints can be minimized, and the frequency of these checkpoints is controlled by allowing Babylon validators to change only once per Epoch.

Validators of each PoS chain download the Babylon block and observe whether their PoS checkpoints are included in the Babylon block checked by Bitcoin. This allows the PoS chain to detect differences, for example, if Babylon validators create an unavailable block checked by Bitcoin and lie about the PoS checkpoints included in the unavailable block. The main components of the protocol are as follows:

• Checkpoint: Only the last block of the Babylon Epoch is checked against Bitcoin. The checkpoint consists of the hash of the block and a single aggregated BLS signature, which corresponds to the signature of the 2/3 validator set that has signed the block for finalization. The Babylon checkpoint also includes the Epoch number. PoS blocks can be assigned the timestamp of a Bitcoin block through the Babylon checkpoint. For example, the first two PoS blocks are set checkpoints by the Babylon block, and the Babylon block is set checkpoints by the Bitcoin block with timestamp t_3. Therefore, these PoS blocks are assigned the Bitcoin timestamp t_3.

• Standard PoS Chain: When there is a fork on the PoS chain, the chain with the earlier timestamp is considered the standard PoS chain. If two forks have the same timestamp, the tie is broken in favor of the PoS block with an earlier checkpoint on Babylon.

• Withdrawal rules: To withdraw, validators send a withdrawal request to the PoS chain. The PoS block containing the withdrawal request is checked by Babylon and then by Bitcoin, and a timestamp t_1 is assigned. Once the Bitcoin block with a timestamp of t_1 reaches a depth of k, the withdrawal is granted on the PoS chain. At this point, if validators who have already withdrawn their stake perform a long-range attack, the blocks on the attacking chain can only be assigned a Bitcoin timestamp later than t_1. This is because once the Bitcoin block with a timestamp of t_1 reaches a depth of k, it cannot be rolled back. Then, by observing the order of these checkpoints on Bitcoin, the PoS client can distinguish between the canonical chain and the attacking chain, and subsequently ignore the attacking chain.

• Slashing rule: If a validator fails to withdraw their stake upon detection of an attack, they can be slashed for producing conflicting PoS blocks with double signatures. Malicious PoS validators know that if they wait until a withdrawal request is approved before launching a long-range attack, they cannot deceive the client, as the client can reference Bitcoin to identify the canonical chain. Therefore, they may fork the PoS chain when allocating Bitcoin timestamps to blocks on the canonical PoS chain. These PoS validators collaborate with malicious Babylon validators and Bitcoin miners to fork Babylon and Bitcoin, replacing the Bitcoin block with timestamp t_2 with another block at timestamp t_3. To later PoS clients, this changes the canonical PoS chain from the top chain to the bottom chain. While this is a successful security attack, it results in the slashing of the malicious PoS validators’ stake, as they have conflicting blocks with double signatures but have not yet withdrawn their stake.

• Stop rules for unavailable PoS checkpoints: PoS validators must pause their PoS chains when they observe unavailable PoS checkpoints on Babylon. Here, an unavailable PoS checkpoint is a hash signed by 2/3 of PoS validators, assumed to correspond to a PoS block that cannot be observed. If PoS validators do not stop their PoS chains when they observe unavailable checkpoints, an attacker can reveal previously unavailable attack chains and change the canonical chain in later client views. This is because the checkpoints of the shadow chain displayed later appear in the early stages of Babylon. The above pause rules reveal the reason why we require the PoS block hashes sent as checkpoints to be signed by the set of PoS validators. If these checkpoints are not signed, any attacker can send arbitrary hashes and claim them to be the hashes of unavailable PoS block checkpoints on Babylon. Then, PoS validators will have to pause checkpoints. Note that creating an unavailable PoS chain is difficult: it requires compromising at least 2/3 of PoS validators so that they complete PoS blocks with signatures without providing data to honest validators. However, in the assumed attack above, the malicious adversary stopped the PoS chain without attacking any validators. To prevent such attacks, we require PoS checkpoints to be validated by 2/3 of PoS validators. Therefore, Babylon will only have unavailable PoS checkpoints if 2/3 of PoS validators are indeed controlled by attackers. Due to the cost of compromising PoS validators, such attacks are highly unlikely to occur and will not affect other PoS chains or Babylon itself.
• Suspension rules for unavailable Babylon checkpoints: PoS and Babylon validators must suspend the blockchain when the Babylon checkpoint that is unavailable on Bitcoin is observed. Here, the unavailable Babylon checkpoint is the hash of the aggregate BLS signature of 2/3 Babylon validators, which is speculated to correspond to a Babylon block that cannot be observed. If the Babylon validators do not stop the Babylon blockchain, then an attacker can reveal a previously unavailable Babylon chain, thereby altering the canonical Babylon chain in the view of later clients. Similarly, if the PoS validators do not stop the PoS chain, then an attacker can reveal the previously unavailable PoS attack chain and the previously unavailable Babylon chain, thereby canonicalizing the PoS chain in the view of later clients. This is because the subsequently revealed dark Babylon chain has an earlier timestamp on Bitcoin and contains a checkpoint of the subsequently revealed PoS attack chain. Just like the suspension rules for unavailable PoS checkpoints, the above rules reveal why we require the Babylon block hash sent as a checkpoint to be accompanied by an aggregate BLS signature to prove the signatures of 2/3 Babylon validators. If the Babylon checkpoint is not signed, then any adversary can send any hash and claim it as the hash of the unavailable Babylon block checkpoint on Bitcoin. Then, PoS validators and Babylon validators will have to wait for a checkpoint in their image that has no unavailable Babylon or PoS chains! Creating an unavailable Babylon chain requires the compromise of at least 2/3 Babylon validators. However, in the assumed attack above, the attacker stopped all chains in the system without compromising a single Babylon or PoS validator. To prevent such attacks, we require Babylon checkpoints to be proven by aggregate signatures; thus, an unavailable Babylon checkpoint will only occur when indeed 2/3 validators are compromised. Due to the cost of compromising Babylon validators, such data availability attacks are highly unlikely to occur. But in extreme cases, it will impact all PoS chains by forcing them to stop.

Eigenlayer in BTC

From the perspective of its purpose, although Babylon is no different from Eigenlayer, it is definitely not a simple fork of Eigenlayer. In the current situation where DA cannot be used natively on the BTC mainchain, the existence of Babylon is very meaningful. In addition to bringing security to external PoS chains, this protocol is also particularly important for revitalizing the BTC ecosystem internally.

Use Case

There may be many use cases in Babylon, here are some that have been implemented or may be implemented in the future:

1. Shortening the Stake Period and Enhancing Security: PoS chains typically require social consensus (consensus among the community, node operators, and validators) to prevent long-range attacks, which are attacks that manipulate transaction records or control the chain by rewriting the blockchain history. This type of attack is particularly severe in PoS systems because unlike PoW, PoS systems do not require validators participating in consensus to consume a large amount of computational resources. Attackers can rewrite history by controlling the keys of early stakeholders. Therefore, to ensure the consensus stability and security of the blockchain network, a long stake period is generally necessary. For example, Cosmos has a 21-day unbonding period. However, with Babylon, PoS chain historical events can be incorporated into the BTC timestamp server, replacing social consensus with BTC as a trusted source. As a result, the unbonding time can be shortened to just 1 day (approximately 100 blocks after BTC is running). Additionally, PoS chains can have native token staking and BTC staking for dual protection at this time.

2. Cross-Chain Interaction: Through the IBC protocol, Babylon is able to collect checkpoint data from multiple PoS chains, achieving cross-chain interaction. This interoperability allows seamless communication and data sharing between different blockchains, enhancing the overall efficiency and functionality of the blockchain ecosystem;

3. Integrating BTC ecosystem: Currently, most projects in the BTC ecosystem do not have sufficient security, whether it is Layer2, LRT or DeFi, most of them still rely on third-party trust assumptions. And these protocols hold a large amount of BTC in their addresses. In the future, perhaps there will be some good fit solutions colliding with Babylon, mutually nourishing each other, and ultimately forming a powerful ecosystem like Eigenlayer in Ethereum.

4. Cross-Chain Asset Management: The Babylon protocol can be used to securely manage cross-chain assets. By adding a timestamp to cross-chain transactions, it ensures the security and transparency of asset transfers between different blockchains. This mechanism helps prevent double spending and other cross-chain attacks.

Babylon Tower

The story of the Tower of Babel comes from Genesis 11:1-9 of the Bible, which is a classic tale of humanity’s attempt to build a tower to the heavens, only to be thwarted by God. Its symbolism represents the unity and common purpose of humanity. It also holds potential significance for the Babylon protocol, which aims to construct a Tower of Babel for many PoS chains and unite them. Narratively, it may not seem inferior to Eigenlayer, the defender of Ethereum, but what is the actual situation?

As of now, the Babylon Testnet has secured 50 Cosmos zones through the IBC protocol. Beyond Cosmos, Babylon has also partnered with some LSD (Liquidity Staking) protocols, cross-chain interoperability protocols, and the Bitcoin ecosystem for integration. On the other hand, in terms of staking, compared to Eigenlayer, Babylon still lags behind in reusing staking and LSD within the Ethereum ecosystem. However, looking ahead, the dormant BTC locked in many wallets and protocols has not been fully awakened, so this is just the tip of the iceberg of the $1.3 trillion, and Babylon currently needs to actively complement the entire BTC ecosystem.

The Only Solution to PANG’s Nesting Dolls

As mentioned earlier, Eigenlayer and Babylon are flourishing, and from the current trend, both will lock in a massive amount of blockchain core assets in the future. Even if the security of these two protocols themselves is not a problem, will the multiple traps lead the entire staking ecosystem into a death spiral and cause a decline no less than the level of the US raising interest rates again? The current staking track indeed experienced a quite long period of irrational prosperity after Ethereum switched to PoS and Eigenlayer emerged. In order to obtain a higher TVL, project parties often throw out a large number of airdrop expectations and trap overlay returns to tempt users. An ETH can be trapped 5 or 6 times, from native staking to LSD and then to LRT. Naturally, this will cause a lot of risk issues with the trap overlay, and any problem with one protocol will directly affect all protocols involved in the trap (especially the staking protocol at the tail of the trap structure). And the BTC ecosystem also has a large number of centralized solutions, so simply copying this set of risks will only be greater. But it needs to be clear that Eigenlayer and Babylon themselves are guiding the staking flywheel towards real practical value, essentially creating real supply and demand to offset this risk. So, the existence of the ‘shared security’ protocol, while indirectly or directly exacerbating the bad practices, is the only solution for staking traps to break away from Pareto returns. The main issue now is whether the commercial logic of the ‘shared security’ protocol is truly valid.

Real supply and demand is the key

In Web3, whether it’s a public chain or a protocol, the underlying logic often revolves around ‘matching’ the buying and selling parties for certain needs. Those who match properly can obtain ‘the world’, and the blockchain itself simply makes this matching fair, genuine, and trustworthy. In theory, the shared security protocol can complement the thriving stake and modular ecosystem. However, upon careful consideration, will this supply far exceed the demand? Firstly, on the supply side, there are quite a few projects and mainchains that can provide modular security. On the other hand, well-established PoS chains may not need or may hesitate to use such security, and new PoS chains may not be able to afford the interest generated by large amounts of BTC and ETH. For the commercial logic of Eigenlayer and Babylon to form a closed loop, at least the earnings need to balance with the interest generated by the staked tokens within the protocol. Even if this balance can be achieved, or even if the earnings far exceed the interest expenditure, this could lead to a parasitic relationship with the new PoS and protocol. Therefore, how to balance in the economic model, avoid falling into the bubble of relying on airdrops for development, and more healthily drive both supply and demand will be of utmost importance.

References

1. Ten thousand words detailed explanation of how Babylon enables the Cosmos ecosystem to benefit from the security of Bitcoin:

2. In-depth understanding of Eigenlayer: Can it help Ethereum break the “nested doll” situation? _source=publication-search

3. Dialogue with Babylon Co-founder Fisher Yu: How to unlock the liquidity of 21 million BTC through staking?

4. Triangular Debt or Mild Inflation: An Alternative Perspective on Staking: _WzndAZXRjnEgD2hcew

5.A look at what I’ve been seeing in crypto lately：