Foreword

In the era of modular blockchain led by Ethereum, providing security services through the integration of the Data Availability (DA) layer is no longer a novel concept. Currently, the concept of shared security introduced by staking offers a new dimension to the modular space. It leverages the potential of “digital gold and silver” to provide security from Bitcoin or Ethereum to numerous blockchain protocols and public chains. This narrative is quite grand, as it not only unlocks the liquidity of assets worth trillions of dollars but also serves as a key element in future scaling solutions. For instance, the recent massive fundraisings of $70 million by the Bitcoin staking protocol Babylon and $100 million by the Ethereum restaking protocol EigenLayer illustrate the strong endorsement by leading venture capital firms for this sector.

However, these developments have also raised significant concerns. If modularity is the ultimate solution for scaling, and these protocols are crucial components of this solution, they are likely to lock up massive amounts of BTC and ETH. This brings into question the security of the protocols themselves. Will the complex layering formed by numerous LSD (Liquid Staking Derivatives) and LRT (Layer 2 Rollup Tokens) protocols become the biggest black swan in the future of blockchain? Is their commercial logic sound? Since we have already analyzed EigenLayer in our previous articles, the following discussion will focus primarily on Babylon to address these issues.

Extending Security Consensus

Bitcoin and Ethereum are undeniably the most valuable public blockchains today. Their security, decentralization, and value consensus, accumulated over many years, are the core reasons why they remain at the pinnacle of the blockchain world. These are rare qualities that other heterogeneous chains find hard to replicate. The core idea of modularity is to “rent” these qualities to those in need. In the current modularity approach, there are two main factions:

The first faction uses a sufficiently secure Layer 1 (usually Ethereum) as the bottom three layers or part of the functional layers for Rollups. This solution offers the highest security and legitimacy and can absorb resources from the main chain’s ecosystem. However, it may not be particularly friendly in terms of throughput and cost for specific Rollups (application chains, long-tail chains, etc.).

The second faction aims to create an existence that is close to the security of Bitcoin and Ethereum but with better cost performance, such as Celestia. Celestia achieves this by using a pure DA function architecture, minimizing node hardware requirements, and low gas costs. This simplified approach seeks to create a DA layer that matches Ethereum’s security and decentralization while offering strong performance in the shortest time possible. The disadvantage of this approach is that its security and decentralization still need some time to be fully developed, and it lacks legitimacy while being in direct competition with Ethereum, leading to rejection by the Ethereum community.

A third type in this faction includes Babylon and EigenLayer. They utilize the core concept of Proof-of-Stake (POS) by leveraging the asset value of Bitcoin or Ethereum to create shared security services. Compared to the first two types, this is a more neutral existence. Its advantage lies in inheriting legitimacy and security while also providing more utility value to the main chain’s assets and offering greater flexibility.

Potential of Digital Gold

Regardless of the underlying logic of any consensus mechanism, the security of a blockchain largely depends on the resources supporting it. PoW chains require massive hardware and electricity, while PoS relies on the value of staked assets. Bitcoin itself is backed by an extremely large PoW network, making it the most secure presence in the entire blockchain space. However, as a public chain with a circulating market value of $1.39 trillion, accounting for half of the blockchain’s market, its asset utility is mainly limited to transfers and gas payments.

For the other half of the blockchain world, especially after Ethereum transitioned to PoS following the Shanghai upgrade, it can be said that most public chains use different PoS architectures to achieve consensus by default. However, new heterogeneous chains often cannot attract substantial capital staking, casting doubt on their security. In the current modular era, Cosmos zones and various Layer 2 solutions can use various DA layers to compensate, but this often comes at the cost of autonomy. For most old PoS mechanisms or consortium chains, using Ethereum or Celestia as a DA layer is also generally impractical. Babylon’s value lies in filling this gap by using BTC staking to provide protection for PoS chains. Just as humanity used gold to back the value of paper currency, BTC is well-suited to play this role in the blockchain world.

From 0 to 1

Unleashing “digital gold” has always been the most ambitious yet difficult narrative to achieve in the blockchain space. From early sidechains, Lightning Network, and bridge-wrapped tokens to today’s Runes and BTC Layer 2, each solution has its inherent flaws. If Babylon aims to harness Bitcoin’s security, centralized solutions that introduce third-party trust assumptions must be ruled out first. Among the remaining options, Runes and Lightning Network (limited by extremely slow development progress) currently only have the capability of asset issuance. This means Babylon needs to design its own “scaling solution” to enable native Bitcoin staking from 0 to 1.

Breaking down the basic elements currently usable by Bitcoin, there are essentially the following: 1. UTXO model, 2. Timestamps, 3. Various signature methods, 4. Basic opcodes. Given Bitcoin’s limited programmability and data-bearing capacity, Babylon’s solution is based on the principle of minimalism. On Bitcoin, only the essential functions for staking contracts need to be completed, meaning BTC staking, slashing, rewards, and retrieval are all handled on the main chain. Once this 0 to 1 is achieved, more complex demands can be handled by the Cosmos zone. However, a critical issue remains: how to record PoS chain data onto the main chain?

Remote Staking

UTXO (Unspent Transaction Outputs) is the transaction model designed by Satoshi Nakamoto for Bitcoin. The core idea is extremely simple: transactions are merely funds coming in and going out, so the entire transaction system can be expressed in terms of inputs and outputs. UTXO represents the part of the funds that come in but are not fully spent, thus remaining as unspent transaction outputs (i.e., Bitcoin not paid out). The entire Bitcoin ledger is essentially a collection of UTXOs, recording the state of each UTXO to manage Bitcoin ownership and circulation. Every transaction spends old UTXOs and generates new ones. Due to its inherent potential for scalability, UTXO has naturally become the starting point for many native scaling solutions. For example, utilizing UTXOs and multisig to create penalty mechanisms and state channels for the Lightning Network, or binding UTXOs to implement semi-fungible tokens (SFTs) like inscriptions and runes, all stem from this crucial starting point.

Babylon also needs to leverage UTXO to implement staking contracts (referred to as remote staking by Babylon, where Bitcoin’s security is remotely passed to PoS chains through an intermediary layer). The implementation of the contract can be broken down into four steps, cleverly combining the existing opcodes:

Locking Funds

Users send funds to an address controlled by multisig. Through OP_CTV (OP_CHECKTEMPLATEVERIFY, which allows creating predefined transaction templates ensuring transactions can only be executed according to specific structures and conditions), the contract can specify that these funds can only be spent under certain conditions. Once funds are locked, a new UTXO is generated, indicating these funds have been staked.

Condition Verification

By calling OP_CSV (OP_CHECKSEQUENCEVERIFY, which allows setting a relative time lock based on the transaction’s sequence number, indicating that the UTXO can only be spent after a certain relative time or number of blocks), time locks can be implemented. Combined with OP_CTV, this can achieve staking, unstaking (allowing the staker to spend the locked UTXO after the staking period is met), and slashing (forcing the spending of UTXO to a locked address if the staker acts maliciously, making it non-spendable, similar to a black hole address).

State Updates

Whenever users stake or withdraw staked funds, it involves creating and spending UTXOs. New transaction outputs generate new UTXOs, and old UTXOs are marked as spent. This way, each transaction and fund movement is accurately recorded on the blockchain, ensuring transparency and security.

Reward Distribution

Based on the staked amount and staking duration, the contract calculates the rewards and distributes them by generating new UTXOs. These rewards can be unlocked and spent through script conditions once specific criteria are met.

Timestamps

After establishing a native staking contract, it is natural to consider the issue of recording historical events from external chains. In Satoshi Nakamoto’s white paper, the Bitcoin blockchain introduced a concept of timestamps supported by PoW, providing an irreversible chronological order for events. In Bitcoin’s native use case, these events refer to various transactions executed on the ledger. Today, 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, it triggers a transaction sent to miners, who then insert it into the Bitcoin ledger, thus adding a timestamp to the event. These timestamps can address various security issues of blockchains. The general concept of adding timestamps to events in child chains on the parent chain is known as “checkpointing,” and the transactions used to add timestamps are called checkpoint transactions. Specifically, timestamps in the Bitcoin blockchain have the following important characteristics:

• Time Format: Timestamps record the number of seconds since January 1, 1970, 00:00:00 UTC, a format known as Unix time or POSIX time.
• Purpose: The main purpose of a timestamp is to mark the block generation time, helping nodes determine the order of blocks and assisting in the network’s difficulty adjustment mechanism.
• Timestamps and Difficulty Adjustment: The Bitcoin network adjusts the mining difficulty approximately every two weeks, or every 2016 blocks. Timestamps play a crucial role in this process, as the network adjusts the difficulty based on the total generation time of the most recent 2016 blocks to ensure that new blocks are generated approximately every 10 minutes.
• Validity Check: When a node receives a new block, it verifies the timestamp. A new block’s timestamp must be greater than the median time of several previous blocks and must not exceed the network time by more than 120 minutes (2 hours into the future).

The timestamp server is a new primitive defined by Babylon, which can allocate Bitcoin timestamps through Babylon checkpoints in PoS blocks, ensuring the accuracy and immutability of the time sequence. This server acts as the top layer in Babylon’s entire architecture, serving as the core source of trust.

Babylon’s Three-Layer Architecture

As illustrated in the diagram, Babylon’s overall architecture can be divided into three layers: Bitcoin (serving as the timestamp server), Babylon (a Cosmos Zone acting as the intermediary layer), and the PoS chains as the demand layer. Babylon refers to the latter two as the Control Plane (Babylon itself) and the Data Plane (various PoS consumer chains).

Having understood the basic trustless implementation of the protocol, let’s delve into how Babylon itself connects the two ends using the Cosmos zone. According to the detailed explanation from Stanford’s Tse Lab on Babylon , Babylon can receive checkpoint streams from multiple PoS chains and merge these checkpoints to publish on Bitcoin. By using aggregated signatures from Babylon validators, the checkpoint size can be minimized, and the frequency of these checkpoints is controlled by allowing Babylon validators to change only once per epoch.

Validators from various PoS chains download Babylon blocks to check if their PoS checkpoints are included in the Bitcoin-checked Babylon blocks. This enables PoS chains to detect discrepancies, such as if Babylon validators create an unavailable block verified by Bitcoin and lie about the PoS checkpoints contained within it. The main components of the protocol are as follows:

· Checkpoints: Only the last block of a Babylon epoch is verified by Bitcoin. A checkpoint consists of the block’s hash and a single aggregated BLS signature, corresponding to the signatures of the two-thirds majority of validators who signed off on the block for finality. Babylon checkpoints also include the epoch number. PoS blocks can assign Bitcoin timestamps through Babylon checkpoints. For example, the first two PoS blocks are checkpointed by Babylon blocks, which are then checkpointed by a Bitcoin block with timestamp t_3. Consequently, these PoS blocks are assigned the Bitcoin timestamp t_3.

· Canonical PoS Chains: When a PoS chain fork occurs, the chain with the earlier timestamp is considered the canonical 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 then checkpointed by Babylon and subsequently by Bitcoin, assigning it timestamp t_1. Once the Bitcoin block with timestamp t_1 reaches a depth of k, the withdrawal is granted on the PoS chain. If a validator with withdrawn stakes attempts a long-range attack, the blocks on the attack chain can only be assigned a timestamp later than t_1. This is because once the Bitcoin block with timestamp t_1 reaches a depth of k, it cannot be rolled back. By observing the order of these checkpoints on Bitcoin, PoS clients can distinguish the canonical chain from the attack chain and ignore the latter.

· Slashing Rules: If validators do not withdraw their stakes upon detecting an attack, they can be slashed for having double-signed conflicting PoS blocks. Malicious PoS validators know that if they wait until after their withdrawal request is approved to launch a long-range attack, they cannot deceive clients who can refer to Bitcoin to identify the canonical chain. Hence, they may fork the PoS chain while assigning Bitcoin timestamps to blocks on the canonical PoS chain. These PoS validators, in collaboration with malicious Babylon validators and Bitcoin miners, fork Babylon and Bitcoin to replace the Bitcoin block with timestamp t_2 with another block with timestamp t_3. In the subsequent view of PoS clients, this would change the canonical PoS chain from the top chain to the bottom chain. Although this is a successful security attack, it results in the slashing of the malicious PoS validators’ stakes because they have double-signed conflicting blocks without withdrawing their stakes.

· Unavailability of PoS Checkpoint Pausing Rules: PoS validators must pause their PoS chain upon observing an unavailable PoS checkpoint on Babylon. An unavailable PoS checkpoint is defined as the hash signed by two-thirds of the PoS validators, which purportedly corresponds to a PoS block that cannot be observed. If PoS validators do not pause the PoS chain upon observing an unavailable checkpoint, an attacker can reveal a previously unavailable attack chain, changing the canonical chain in later client views. This is because the checkpoint of the shadow chain revealed later appears earlier on Babylon. The above pausing rule explains why we require the PoS block hashes sent as checkpoints to be signed by the PoS validator set. If these checkpoints were unsigned, any attacker could send an arbitrary hash, claiming it to be the hash of an unavailable PoS block checkpoint on Babylon. PoS validators would then have to pause at the checkpoint. Note that creating an unavailable PoS chain is challenging: it requires compromising at least two-thirds of the PoS validators to sign off on the PoS block without providing data to honest validators. However, in the assumed attack above, the malicious adversary pauses the PoS chain without compromising a single validator. To prevent such attacks, we require PoS checkpoints to be signed by two-thirds of the PoS validators. Consequently, there will be no unavailable PoS checkpoints on Babylon unless two-thirds of the PoS validators are compromised, which is highly unlikely due to the cost of compromising PoS validators and does not affect other PoS chains or Babylon itself.

· Unavailability of Babylon Checkpoint Pausing Rules: Both PoS and Babylon validators must pause the blockchain upon observing an unavailable Babylon checkpoint on Bitcoin. An unavailable Babylon checkpoint is defined as a hash with an aggregated BLS signature of two-thirds of Babylon validators, which purportedly corresponds to a Babylon block that cannot be observed. If Babylon validators do not pause the Babylon blockchain, an attacker can reveal a previously unavailable Babylon chain, changing the canonical Babylon chain in later client views. Similarly, if PoS validators do not pause the PoS chain, the attacker can reveal a previously unavailable PoS attack chain and the previously unavailable Babylon chain, changing the canonical PoS chain in later client views. This is because the deep Babylon chain revealed later has an earlier timestamp on Bitcoin and includes checkpoints of the later revealed PoS attack chain. Similar to the rule for pausing at unavailable PoS checkpoints, this rule explains why we require the Babylon block hashes sent as checkpoints to have an aggregated BLS signature proving the signatures of two-thirds of the Babylon validators. If Babylon checkpoints were unsigned, any adversary could send an arbitrary hash, claiming it to be the hash of an unavailable Babylon block checkpoint on Bitcoin. PoS validators and Babylon validators would then have to wait for a checkpoint that has no unavailable Babylon or PoS chains in its preimage. Creating an unavailable Babylon chain requires compromising at least two-thirds of the Babylon validators. However, in the assumed attack above, the adversary pauses 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 aggregated signatures; thus, there will be no unavailable Babylon checkpoints unless two-thirds of the validators are compromised, which is highly unlikely due to the cost of compromising Babylon validators. But in extreme cases, it will affect all PoS chains by forcing them to pause.

Eigenlayer in BTC

In terms of purpose, while Babylon is similar to Eigenlayer, it is far from being a simple “fork” of Eigenlayer. Given the current inability to natively use DA on the BTC main chain, Babylon’s presence is quite significant. This protocol not only brings security to external PoS chains but is also crucial for revitalizing the BTC ecosystem internally.

Use Cases

Babylon presents numerous potential use cases, some of which have already been realized or may have opportunities for realization in the future:

1. Reducing Staking Periods and Enhancing Security: PoS chains typically require social consensus (consensus among the community, node operators, and validators) to prevent long-range attacks. These attacks involve rewriting blockchain history to manipulate transaction records or control the chain. Long-range attacks are particularly severe in PoS systems because, unlike PoW, PoS systems do not require validators to consume significant computational resources. An attacker can rewrite history by controlling the keys of early stakers. To ensure the stability and security of the blockchain network consensus, long staking periods are generally necessary. For example, Cosmos requires a 21-day unbonding period. However, with Babylon, PoS chain historical events can be included in the BTC timestamp server, using BTC as a trust source to replace social consensus. This can reduce the unbonding time to just one day (equivalent to approximately 100 BTC blocks). Furthermore, PoS chains can have dual security through native token staking and BTC staking.

• Cross-Chain Interoperability: Through the IBC protocol, Babylon can receive checkpoint data from multiple PoS chains, enabling cross-chain interoperability. This interoperability allows seamless communication and data sharing between different blockchains, enhancing the overall efficiency and functionality of the blockchain ecosystem.
• Integrating the BTC Ecosystem: Most projects within the current BTC ecosystem, including Layer 2, LRT, and DeFi, lack sufficient security and often rely on third-party trust assumptions. These protocols also store large amounts of BTC in their addresses. In the future, Babylon might develop some highly compatible solutions with these projects, creating mutual benefits and eventually forming a robust ecosystem similar to Eigenlayer within Ethereum.
• Cross-Chain Asset Management: The Babylon protocol can be used for secure management of cross-chain assets. By adding timestamps 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.

The Tower of Babel

The story of the Tower of Babel comes from the Bible, Genesis 11:1–9, and is a classic tale of humanity’s attempt to build a tower to reach the heavens, only to be thwarted by God. This story symbolizes human unity and shared goals. The Babylon protocol aims to build a similar tower for various PoS chains, uniting them under one roof. In terms of narrative, it seems no less impressive than Eigenlayer, the defender of Ethereum. But how does it hold up in practice?

As of now, the Babylon testnet has provided security guarantees to 50 Cosmos zones through the IBC protocol. Beyond the Cosmos ecosystem, Babylon has integrated with some LSD (Liquid Staking Derivatives) protocols, omnichain interoperability protocols, and Bitcoin ecosystem protocols. However, in terms of staking, Babylon currently lags behind Eigenlayer, which can reuse staking and LSD within the Ethereum ecosystem. In the long run, though, the vast amount of BTC lying dormant in wallets and protocols has yet to be fully awakened, representing just the tip of the $1.3 trillion iceberg. Babylon needs to form a positive symbiosis with the entire BTC ecosystem.

The Only Solution to the Ponzi Staking Dilemma

As mentioned earlier, Eigenlayer and Babylon are both rapidly developing, and future trends suggest they will lock up massive amounts of core blockchain assets. Even if these protocols themselves are secure, could multiple layers of staking create a death spiral for the staking ecosystem, causing a crash akin to another interest rate hike by the US? The current staking sector has indeed experienced irrational exuberance since Ethereum’s transition to PoS and the emergence of Eigenlayer. Projects often lure users with high TVL through massive airdrop expectations and layered returns. An ETH can go through native staking, LSD, and LRT, stacking up to five or six layers. This stacking increases risk, as a problem in any one protocol can directly impact all protocols involved, especially those at the end of the staking chain. The BTC ecosystem, with its numerous centralized solutions, would face even greater risks if it adopts this model.

However, it’s important to note that Eigenlayer and Babylon are fundamentally about guiding the staking flywheel towards genuine utility, creating real demand to offset risks. Therefore, while these “shared security” protocols may indirectly or directly exacerbate bad practices, they also represent the only way to escape the Ponzi-like returns of layered staking. The more pressing issue now is whether the commercial logic of “shared security” protocols is truly viable.

Real Demand is Key

In Web3, whether for public chains or protocols, the underlying logic often involves matching buyers and sellers for a particular demand. Those who do this well can “win the world,” as blockchain technology ensures that the matching process is fair, real, and trustworthy. Theoretically, shared security protocols can complement the booming staking and modular ecosystems. However, will the supply far exceed the demand? On the supply side, there are many projects and main chains capable of providing modular security. On the demand side, established PoS chains may not need or be reluctant to rent such security for the sake of face, while new PoS chains may struggle to pay the interest generated by large amounts of BTC and ETH. For Eigenlayer and Babylon to form a closed commercial loop, the revenue generated must balance the interest generated by the staked tokens within the protocol. Even if this balance is achieved and the revenue far exceeds the interest expenditure, it could still result in these new PoS chains and protocols being drained. Therefore, how to balance the economic model, avoid bubbles fueled by airdrop expectations, and healthily drive both supply and demand will be crucial.

About YBB

YBB is a web3 fund dedicating itself to identify Web3-defining projects with a vision to create a better online habitat for all internet residents. Founded by a group of blockchain believers who have been actively participated in this industry since 2013, YBB is always willing to help early-stage projects to evolve from 0 to 1.We value innovation, self-driven passion, and user-oriented products while recognizing the potential of cryptos and blockchain applications.

Website | Twi: @YBBCapital

References

1. Detailed explanation of how Babylon benefits the Cosmos ecosystem with Bitcoin’s security: ChainCatcher Article
2. In-depth understanding of Eigenlayer: Breaking Ethereum out of the “stacking” predicament? HaoTianCryptoInsight Article
3. Conversation with Babylon Co-Founder Fisher Yu: How to unlock the liquidity of 21 million BTC through staking? ChainCatcher Article
4. Triangular debt or mild inflation: An alternative perspective on re-staking: Weixin Article
5. A look at what I’ve been seeing in crypto lately: TheKnower Substack

Disclaimer：

1. This article is reprinted from [Medium]. All copyrights belong to the original author [YBB]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.

2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.

3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.