Author: Zeke, YBB Capital Source: medium Translation: Shan Ouba, Golden Finance

Foreword

In the era of modular blockchains led by Ethereum, providing security services by integrating a data availability (DA) layer is no longer a new concept. Currently, the concept of shared security introduced through staking provides a new dimension to the modular space. It uses the potential of "digital gold and silver" to provide security from Bitcoin or Ethereum to numerous blockchain protocols and public chains. This story is quite grand because it not only unlocks liquidity for trillions of dollars worth of assets, but is also a key element of future expansion solutions. For example, the recent Bitcoin staking protocol Babylon raised a huge fund of $70 million and the Ethereum re-staking protocol EigenLayer raised a fund of $100 million, which illustrates the strong support of leading venture capital firms for this field.

However, these developments have also raised serious concerns. If modularity is the ultimate solution to scaling, and these protocols are a key component of that solution, they are likely to lock up a large amount of BTC and ETH. This brings up the security issues of the protocols themselves. Will the complex layering formed by numerous LSD (Liquid Stake Derivatives) and LRT (Layer 2 Rollup Tokens) protocols become the biggest black swan in the future of blockchain? Is their business logic reasonable? Since we have analyzed EigenLayer in previous articles, the following discussion will focus on Babylon to solve these problems.

Expanding Security Consensus

Bitcoin and Ethereum are undoubtedly the most valuable public blockchains today. The security, decentralization, and value consensus they have accumulated over the years are the core reasons why they always stand at the top of the blockchain world. These are rare qualities that are difficult for other heterogeneous chains to replicate. The core idea of ​​modularity is to "rent" these qualities to those in need. There are two main factions in the current modular approach:

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

The second faction aims to create a security that is close to Bitcoin and Ethereum but more cost-effective, such as Celestia. Celestia achieves this goal by using a pure DA functional architecture, minimizing node hardware requirements, and low Gas costs. This simplified approach aims to create a DA layer that matches the security and decentralization of Ethereum while providing strong performance in the shortest possible time. The disadvantage of this approach is that its security and decentralization will take some time to fully play out, and it lacks legitimacy when competing directly with Ethereum, leading to rejection by the Ethereum community.

The third type in this faction includes Babylon and feature layers. They use the core concept of proof of stake (POS) to create a shared security service by leveraging the asset value of Bitcoin or Ethereum. Compared with the first two, this is a more neutral existence. Its advantage is that it inherits legitimacy and security, while also providing more practical value to the assets of the main chain and providing greater flexibility.

The potential of digital gold

No matter what the underlying logic of any consensus mechanism is, the security of the blockchain depends largely on the resources that support it. PoW chains require a lot of hardware and electricity, while PoS relies on the value of the staked assets. Bitcoin itself is supported by an extremely large PoW network, making it the most secure existence in the entire blockchain field. However, as a public chain with a circulating market value of 1.39 trillion US dollars and occupying half of the blockchain market, its asset utility is mainly limited to transfers and gas payments.

For the other half of the blockchain world, especially after Ethereum turned to PoS after the Shanghai upgrade, it can be said that most public chains use different PoS architectures by default to reach consensus. However, new heterogeneous chains often fail to attract large amounts of capital to pledge, raising questions about their security. In the current era of modularity, Cosmos zones and various Layer 2 solutions can use various DA layers to compensate, but this often comes at the expense of autonomy. For most old PoS mechanisms or consortium chains, it is also generally impractical to use Ethereum or Celestia as a DA layer. Babylon's value lies in filling this gap by using BTC pledges to provide protection for PoS chains. Just as humans use gold to support the value of paper money, Bitcoin is very suitable for playing this role in the blockchain world.

From 0 to 1

Releasing "digital gold" has always been the most ambitious but most difficult goal in the blockchain field. From early sidechains, lightning networks, bridge tokens to today's Runes and BTC Layer 2, each solution has its inherent flaws. If Babylon aims to leverage the security of Bitcoin, centralized solutions that introduce third-party trust assumptions must first be ruled out. Of the remaining options, Rune and Lightning Network (limited by extremely slow development progress) currently only have the ability to issue assets. This means that Babylon needs to design its own "scaling solution" to achieve native Bitcoin staking from 0 to 1.

Break down the basic elements currently available in Bitcoin, essentially there are the following: 1. UTXO model, 2. Timestamp, 3. Various signature methods, 4. Basic operation code. Given Bitcoin's limited programmability and data carrying capacity, Babylon's solution is based on the principle of minimalism. On Bitcoin, only the basic functions of the staking contract need to be completed, which means that BTC's staking, slashing, rewards, and retrieval are all handled on the main chain. Once this 0 to 1 is achieved, the Cosmos zone can handle more complex requirements. However, a key question remains: how to record PoS chain data to the main chain?

Remote Staking

UTXO (Unspent Transaction Outputs) is the transaction model designed by Satoshi Nakamoto for Bitcoin. The core idea is very simple: transactions are just the in and out of funds, so the entire transaction system can be represented by inputs and outputs. UTXO represents the portion of funds that have entered but not been fully spent, and is therefore retained as an unspent transaction output (i.e., unspent bitcoin). The entire Bitcoin ledger is essentially a collection of UTXOs, recording the status of each UTXO to manage the ownership and circulation of Bitcoin. Each transaction consumes old UTXOs and generates new UTXOs. Due to its inherent scalability potential, UTXOs naturally become the starting point for many native expansion solutions. For example, Babylon also needs to use UTXO to implement the Stake contract (Babylon calls it remote Stake, which means that the security of Bitcoin is remotely delivered to the PoS chain through an intermediary layer). The implementation of the contract can be divided into four steps, cleverly combining existing opcodes: Users send funds to addresses controlled by multiple signatures. Through OP_CTV (OP_CHECKTEMPLATEVERIFY, which allows 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 these funds can only be used under certain conditions. Once the funds are locked, a new UTXO is generated, indicating that these funds have been pledged.

Conditional Verification

Time locks can be implemented by calling OP_CSV (OP_CHECKSEQUENCEVERIFY, which allows relative time locks to be set based on the sequence number of the transaction, indicating that UTXO can only be spent after a certain relative time or number of blocks). Combined with OP_CTV, staking, unstaking (allowing the pledger to spend the locked UTXO after the pledge period is met) and slashing (if the pledger behaves maliciously, the UTXO is forced to be spent to the locked address, making it unspendable, similar to a black hole address).

Status Update

Whenever a user stakes or withdraws staked funds, it involves creating and spending UTXO. New transaction outputs generate new UTXOs, and old UTXOs are marked as spent. In this way, every transaction and fund flow is accurately recorded on the blockchain, ensuring transparency and security.

Reward Distribution

The contract calculates rewards based on the staked amount and the staked period and distributes them by generating new UTXOs. Once specific conditions are met, these rewards can be unlocked and spent through script conditions.

Timestamp

After establishing the native Stake contract, it is natural to consider the problem of recording historical events from external chains. In Satoshi Nakamoto's white paper, the Bitcoin blockchain introduced the concept of timestamps supported by PoW, which provides an irreversible chronological order for events. In Bitcoin's native use case, these events refer to various transactions performed on the ledger. Today, in order to enhance the security of other PoS chains, Bitcoin can also be used to timestamp events on external blockchains. Every time such an event occurs, it triggers a transaction sent to the miners, who then insert it into the Bitcoin ledger, thereby timestamping the event. These timestamps can solve various security issues of the blockchain. The general concept of timestamping events in a child chain on a parent chain is called "checkpointing", and the transactions used to timestamp 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 timestamps is to mark the time of block generation, help nodes determine the order of blocks, and assist 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 vital role in this process because the network adjusts the difficulty based on the total generation time of the last 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. The timestamp of the new block must be greater than the median time of the previous blocks and must not exceed the network time by more than 120 minutes (the next 2 hours).

The timestamp server is a new primitive defined by Babylon that can distribute Bitcoin timestamps through Babylon checkpoints in PoS blocks to ensure the accuracy and non-tamperability of the time series. As the top layer of the entire Babylon architecture, the server is the core source of trust.

Babylon's three-layer architecture

As shown in the figure, Babylon's overall architecture can be divided into three layers: Bitcoin (as a timestamp server), Babylon (Cosmos Zone as the middle layer), and PoS chain as the demand layer. Babylon calls the latter two the control plane (Babylon itself) and the data plane (various PoS consumer chains).

With the basic trustless implementation of the protocol in mind, let’s dive into how Babylon itself uses Cosmos zones to connect the two ends. As explained in detail by Stanford University’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, checkpoint size can be minimized, and the frequency of these checkpoints can be 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 allows the PoS chains to detect discrepancies, such as if a Babylon validator created an unavailable block validated by Bitcoin and lied about the PoS checkpoints contained in it. The main components of the protocol are as follows:

· Checkpoints: Bitcoin only validates the last block of the Babylon epoch. A checkpoint consists of the hash of the block and a single aggregated BLS signature corresponding to the signatures of a two-thirds majority of validators who signed finality on the block. The Babylon checkpoint also includes the epoch number. PoS blocks can be assigned a Bitcoin timestamp via the Babylon checkpoint. For example, the first two PoS blocks are checkpointed by the Babylon block and then by a Bitcoin block with timestamp t_3. Therefore, these PoS blocks are assigned the Bitcoin timestamp t_3.

· Canonical PoS Chain: When a PoS chain forks, the chain with the earlier timestamp is considered the canonical PoS chain. If two forks have the same timestamp, the tie will be broken in favor of the PoS block with the earlier checkpoint on Babylon.

· Withdrawal rules: To withdraw, the validator sends a withdrawal request to the PoS chain. The PoS block containing the withdrawal request is then checkpointed by Babylon and subsequently by Bitcoin, and assigned a timestamp t_1. Once a Bitcoin block with a timestamp of t_1 reaches depth k, the withdrawal is approved on the PoS chain. If the validator who withdraws the stake attempts a long-range attack, blocks on the attacking chain can only be assigned timestamps later than t_1. This is because a Bitcoin block with timestamp t_1 cannot be rolled back once it reaches depth k. By observing the order of these checkpoints on Bitcoin, PoS clients can distinguish between the canonical chain and the attack chain and ignore the latter.

· Slashing rules: If validators do not withdraw their stake after detecting an attack, they may be slashed for double-signing conflicting PoS blocks. Malicious PoS validators know that if they wait until a withdrawal request is approved before launching a long-range attack, they will not be able to deceive clients who can refer to Bitcoin to identify the canonical chain. Therefore, they could fork the PoS chain while assigning 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 timestamped at t_2 with another block timestamped at t_3. This would change the canonical PoS chain from the top chain to the bottom chain from the point of view of later PoS clients. This is a successful security attack though.

· Unavailable PoS checkpoint suspension rule: PoS validators must suspend their PoS chain when they observe an unavailable PoS checkpoint on Babylon. An unavailable PoS checkpoint is defined as a hash signed by two-thirds of PoS validators that allegedly corresponds to an unobservable PoS block. If a PoS validator does not suspend the PoS chain when it observes an unavailable checkpoint, an attacker can reveal a previously unavailable attack chain, thereby changing the canonical chain in the view of later clients. This is because the checkpoint of the shadow chain revealed later appeared earlier in Babylon. The above halting rules explain why we require that PoS block hashes sent as checkpoints be signed by the PoS validator set. If these checkpoints are not signed, any attacker can send an arbitrary hash claiming that it is the hash of an unavailable PoS block checkpoint on Babylon. The PoS validator must then be halted 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 a PoS block without providing data to honest validators. However, in the attack hypothesized above, the malicious adversary halted the PoS chain without compromising a single validator. To prevent such attacks, we require that PoS checkpoints be signed by two-thirds of the PoS validators. Therefore, unavailable PoS checkpoints cannot occur on Babylon unless two-thirds of the PoS validators are compromised, which is extremely unlikely due to the cost of compromising a PoS validator and does not affect other PoS chains or Babylon itself. It requires compromising at least two-thirds of PoS validators to sign a PoS block without providing data to honest validators. However, in the attack hypothesized above, the malicious adversary paused the PoS chain without compromising a single validator. To prevent such attacks, we require PoS checkpoints to be signed by two-thirds of PoS validators. Therefore, there will be no unavailable PoS checkpoints on Babylon unless two-thirds of PoS validators are compromised, which is extremely unlikely due to the cost of compromising PoS validators and does not affect other PoS chains or Babylon itself. It requires compromising at least two-thirds of PoS validators to sign a PoS block without providing data to honest validators. However, in the attack hypothesized above, the malicious adversary paused the PoS chain without compromising a single validator. To prevent such attacks, we require PoS checkpoints to be signed by two-thirds of PoS validators.

· Unavailable Babylon Checkpoint Pause Rule: 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 the aggregate BLS signatures of two-thirds of the Babylon validators that allegedly corresponds to an unobservable Babylon block. If Babylon validators do not pause the Babylon blockchain, an attacker can reveal a previously unavailable Babylon chain, thereby altering the canonical Babylon chain in the view of later clients. Similarly, if PoS validators do not pause the PoS chain, an attacker can reveal both a previously unavailable PoS attack chain and a previously unavailable Babylon chain, thereby altering the canonical PoS chain in the view of later clients. This is because the later-revealed Babylon deep chain has an earlier timestamp on Bitcoin and contains checkpoints of the later-revealed PoS attack chain. Similar to the rule for pausing on unavailable PoS checkpoints, this rule explains why we require that Babylon block hashes sent as checkpoints have aggregated BLS signatures proving the signatures of two-thirds of Babylon validators. If Babylon checkpoints are unsigned, any adversary can send an arbitrary hash claiming it is the hash of an unavailable Babylon block checkpoint on Bitcoin. PoS validators and Babylon validators must then wait for a checkpoint that does not have an unavailable Babylon or PoS chain in its preimage. Creating an unavailable Babylon chain requires compromising at least two-thirds of Babylon validators. However, in the hypothetical attack above, the adversary suspends all chains in the system without affecting a single Babylon or PoS validator. To prevent this type of attack, we require that Babylon checkpoints be attested by aggregated signatures; therefore, there can be no unavailable Babylon checkpoints unless two-thirds of validators are compromised, which is extremely unlikely due to the cost of compromising a Babylon validator. But in the extreme case, it forces all PoS chains to pause, affecting them all.

Feature Layers in BTC

Babylon is similar to Eigenlayer in terms of usage, but it is far from a simple "fork" of Eigenlayer. Given that DA cannot currently be used natively on the BTC main chain, the existence of Babylon is quite important. The protocol not only brings security to external PoS chains, but is also crucial for revitalizing the BTC ecosystem internally.

Use Cases

Babylon offers many potential use cases, some of which have been realized or may have the opportunity to be realized in the future:

1. Shortening the staking cycle and enhancing security: PoS chains usually 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 serious in PoS systems because, unlike PoW, PoS systems do not require validators to consume a lot of computing resources. An attacker can rewrite history by controlling the keys of early stakers. In order to ensure the stability and security of blockchain network consensus, a longer staking cycle is generally required. For example, Cosmos requires a 21-day unbinding period. However, with Babylon, PoS chain historical events can be incorporated into the BTC timestamp server, using BTC as a trust source to replace social consensus. This can shorten the unbinding time to one day (equivalent to about 100 BTC blocks). In addition, PoS chains can achieve 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, thereby achieving cross-chain interoperability. This interoperability allows seamless communication and data sharing between different blockchains, thereby improving the overall efficiency and functionality of the blockchain ecosystem.

• Integration of BTC ecosystem: Most projects in 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 a large amount of BTC in their addresses. In the future, Babylon may develop some solutions that are highly compatible with these projects, creating mutual benefits and eventually forming a strong ecosystem similar to Eigenlayer within Ethereum.

• Cross-chain asset management: The Babylon protocol can be used for the secure management of cross-chain assets. By adding timestamps to cross-chain transactions, the security and transparency of asset transfers between different blockchains are guaranteed. This mechanism helps prevent double spending and other cross-chain attacks.

Tower of Babel

The story of the Tower of Babel comes from Genesis 11:1-9 in the Bible, and is a classic story of mankind trying to build a tower to the sky but being thwarted by God. This story symbolizes human unity and common goals. The Babylon protocol aims to build a similar tower for various PoS chains, unifying them under one roof. In terms of narrative, it seems no less than Eigenlayer, the defender of Ethereum. But how does it work in practice?

So far, the Babylon testnet has provided security for 50 Cosmos zones through the IBC protocol. In addition to the Cosmos ecosystem, Babylon has also integrated some LSD (liquid staking derivatives) protocols, full-chain interoperability protocols, and Bitcoin ecosystem protocols. However, in terms of Stake, Babylon currently lags behind Eigenlayer, which can reuse Stake and LSD within the Ethereum ecosystem. But in the long run, a large amount of Bitcoin dormant in wallets and protocols has not yet been fully awakened, which is just the tip of the $1.3 trillion iceberg. Babylon needs to form a benign symbiosis with the entire BTC ecosystem.

The Only Solution to the Ponzi Staking Dilemma

As mentioned earlier, both Eigenlayer and Babylon are developing rapidly, and future trends indicate that they will lock up a large number of core blockchain assets. Even if these protocols are inherently secure, will multi-layer staking create a death spiral for the staking ecosystem, leading to a collapse similar to another rate hike in the United States? Since Ethereum's transition to PoS and the emergence of Eigenlayer, the current Stake industry has indeed experienced an irrational boom. Projects often attract users with high TVL through huge airdrop expectations and layered returns. One ETH can go through native staking, LSD, and LRT, stacking up to five or six layers. This stacking increases risk because problems in any one protocol may directly affect all the protocols involved, especially those at the end of the staking chain. The Bitcoin ecosystem,

However, it is worth noting that Eigenlayer and Babylon are fundamentally designed to guide the staking flywheel towards real practicality and create real demand to offset the risk. Therefore, while these "shared security" protocols may indirectly or directly exacerbate bad behavior, they are also the only way to avoid layered staking Ponzi scheme returns. The more pressing question now is whether the business logic of the "shared security" protocol is truly feasible.

Real demand is the key

In Web3, whether it is a public chain or a protocol, the underlying logic often involves matching buyers and sellers for specific needs. Do this, and you can "win the world" because blockchain technology ensures that the matching process is fair, real, and credible. In theory, shared security protocols can complement the thriving staking and modular ecosystem. However, will the supply far exceed the demand? On the supply side, there are many projects and main chains that can provide modular security. From the demand side, the old PoS chain may not need or be willing to rent such securities for the sake of face, and the new PoS chain may have difficulty paying the interest generated by a large amount of BTC and ETH. For Eigenlayer and Babylon to form a closed business loop, the income generated must balance the interest generated by the staked tokens within the protocol. Even if this balance is achieved and the income far exceeds the interest expenditure, it may still cause these new PoS chains and protocols to be exhausted. Therefore, how to balance the economic model, avoid the bubble caused by the expectation of airdrops, and drive supply and demand in a healthy way will be crucial.