How does Babylon unlock the value of Bitcoin security?

Author: Zeke, YBB Capital Researcher; Translation: Jinse Finance xiaozou

In the era of modular blockchains led by Ethereum, providing security services through the integrated data availability (DA) layer is no longer a novel concept. Currently, the concept of introducing shared security through staking provides a new dimension to the modular field - using the potential of "digital gold and silver" to provide security across Bitcoin or Ethereum and numerous blockchain protocols and public chains. This narrative is quite grand, as it not only unlocks the liquidity of trillions of dollars worth of assets, but is also a key factor in future scaling solutions. For example, the recent fundraising of Bitcoin staking protocol Babylon and Ethereum re-staking protocol EigenLayer of $70 million and $100 million respectively shows us the strong support of leading venture capital firms in this field.

However, these developments have also raised major concerns. If modularity is the ultimate scaling solution and these protocols are a key component of that solution, they may lock up a large amount of BTC and ETH. This makes the security of the protocol itself the focus of attention. Will the complex layering composed of numerous LSD (liquidity pledge derivatives) and LRT (L2 rollup tokens) protocols become the biggest black swan in the future of blockchain? Is their business logic reasonable? The discussion in this article will mainly revolve around Babylon. After reading this article, you will solve the above doubts.

1. Extended security consensus

Bitcoin and Ethereum are undoubtedly the most valuable public blockchains today. Their security, decentralized characteristics and value consensus have been accumulated over the years, which are the key reasons why they maintain their core position in the blockchain world. These are rare qualities that are difficult for other heterogeneous chains to replicate. The main idea of ​​modularization is to "rent" these qualities to those in need. The current modular field is mainly divided into two factions:

The first faction uses a sufficiently secure L1 (usually Ethereum) as a partial functional layer or the three most basic layers of the rollup. This solution provides the highest security and legitimacy, and can draw resources from the main chain ecosystem. However, 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 solution that is close to the security of Bitcoin and Ethereum but has better cost-effectiveness, such as Celestia. Celestia achieves this 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 characteristics of Ethereum while providing strong performance in the shortest possible time. The disadvantage of this approach is that its security and decentralization characteristics still need some time to fully develop, and it lacks legitimacy in direct competition with Ethereum and is rejected by the Ethereum community.

There is also a third type in this faction, such as Babylon and EigenLayer. They use the core concept of proof of stake (POS) to create shared security services using the asset value of Bitcoin or Ethereum. Compared with the first two categories, this is a more neutral approach. Its advantage is that it inherits legitimacy and security while also providing more practical value for the main chain assets and providing higher flexibility.

2. The potential of digital gold

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

On the other side of the blockchain world, especially after Ethereum transitioned to the PoS mechanism after the Shanghai upgrade, it can be said that most public chains use various different PoS architectures by default to reach consensus. However, new heterogeneous chains often fail to attract a large amount of capital pledge, which makes people doubt their security. In the current era of modularity, Cosmos Zone and various L2 solutions can use various DA layers to compensate, but this usually comes at the expense of autonomy. For most old PoS mechanisms or consortium chains, it is usually impractical to use Ethereum or Celestia as the DA layer. Babylon's value lies in filling this gap by providing protection for PoS chains through BTC staking. Just as humans use gold to support the value of paper money, Bitcoin is very suitable to play this role in the blockchain world.

3. From scratch

In the blockchain space, unleashing the potential of “digital gold” has always been the most ambitious but also the most difficult goal to achieve. From early sidechains, lightning networks, and bridge package tokens to today’s Runes and BTC Layer 2, each solution has its inherent flaws. If Babylon’s goal is to leverage the security of Bitcoin, then centralized solutions that introduce third-party trust assumptions must first be ruled out. Of the remaining options, Runes and the 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 scratch.

Breaking down the basic elements currently available in Bitcoin, there are basically the following: (1) UTXO model, (2) timestamps, (3) various signature methods, and (4) basic opcodes. 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 staking, slashing, rewards, and redemption are all handled on the main chain. Once it is achieved from scratch, Cosmos Zone can handle more complex requirements. However, there is still a key problem: how to record PoS chain data to the main chain?

4. Remote pledge

UTXO (unspent transaction output) 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 a part of the funds that have entered but not been fully spent, so it is an unspent transaction output (that is, unpaid 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 spends the old UTXO and generates a new UTXO. Due to its inherent expansion potential, UTXO naturally becomes the starting point for many native expansion solutions. For example, using UTXO and multi-signatures to create penalty mechanisms and state channels for the Lightning Network, or binding UTXO to implement semi-fungible tokens (SFTs) such as inscriptions and runes, all of which originate from this key starting point.

Babylon also needs to use UTXO to implement the pledge contract (Babylon calls it remote pledge, where the security of Bitcoin is remotely transmitted to the PoS chain through the middle layer). The implementation of the contract cleverly combines existing opcodes and can be divided into four steps:

Step 1: Lock funds

The user sends funds to the address controlled by multisig. Through OP_CTV (OP_CHECKTEMPLATEVERIFY, which supports 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.

Step 2: Conditional Verification

Time locks can be implemented by calling OP_CSV (OP_CHECKSEQUENCEVERIFY, which supports setting a relative time lock based on the transaction sequence number, indicating that a 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 expires) and confiscation (if the pledger commits malicious behavior, the UTXO spending will be forced to be transferred to the locked address, making it unspendable, similar to a black hole address) can be achieved.

Step 3: 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.

Step 4: Reward Distribution

The contract calculates rewards based on the amount of stake and the time of stake, and distributes them by generating new UTXO. Once a specific standard is met, these rewards can be unlocked and spent through script conditions.

5. Timestamp

After establishing a native staking 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 Bitcoin ledger. Today, in order to enhance the security of other PoS chains, Bitcoin can also be used for event timestamps 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 adding a timestamp to the event. These timestamps can solve various security issues of blockchains. The concept of adding timestamps to events in a child chain on the parent chain is called "checkpointing", and the transaction used to add timestamps is called a checkpoint transaction. Specifically, the timestamp in the Bitcoin blockchain has the following important features:

• Time format:The timestamp records the number of seconds starting from 00:00:00 UTC on January 1, 1970, in a format called Unix time or POSIX time.

• Purpose:The main purpose of the timestamp is to mark the block generation time, help nodes determine the order of blocks, and assist the network's difficulty adjustment mechanism.

• Timestamp and difficulty adjustment:The Bitcoin network adjusts the mining difficulty approximately every two weeks or every 2016 blocks. The timestamp plays a vital role in this process because the network adjusts the difficulty based on the total generation time of the most recent 2016 blocks to ensure that a new block is generated approximately every 10 minutes.

• Validity check:When a node receives a new block, it verifies the timestamp. The timestamp of a new block must be greater than the median time of the previous blocks and must not exceed 120 minutes of network time (the next 2 hours).

The timestamp server is a new primitive defined by Babylon, which can distribute Bitcoin timestamps through Babylon checkpoints in PoS blocks to ensure the accuracy and immutability of time ordering. The server is at the top level of the entire Babylon architecture and is the core source of trust requirements.

6. 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, a Cosmos Zone - Babylon as an intermediate layer, and a PoS chain as a 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 Babylon protocol in mind, let’s delve into how Babylon itself uses Cosmos Zone to connect the two ends. According to a detailed explanation of Babylon by Stanford University’s Tse Lab, Babylon can receive checkpoint streams from multiple PoS chains and merge and publish these checkpoints to Bitcoin. By using aggregate signatures from Babylon validators, the size of the checkpoints can be minimized, and the frequency of these checkpoints can be controlled by limiting Babylon validators to only one update per epoch.

Validators from different PoS chains download Babylon blocks and check if the PoS checkpoint is included in the Babylon block checked by Bitcoin. This allows the PoS chain to detect deviations, for example, a Babylon validator creates an unavailable block verified by Bitcoin and falsely reports that it contains a PoS checkpoint. The main components of the protocol are as follows:

• Checkpoints:Only the last block of a Babylon epoch will be verified by Bitcoin. The checkpoint consists of the hash of the block and a BLS aggregate signature corresponding to the signature of a two-thirds majority of validators who signed the block to obtain finality. 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 the Bitcoin block with timestamp t_3. Therefore, these PoS blocks will be assigned a Bitcoin timestamp of t_3.

• Canonical PoS chain: When a PoS chain forks, the chain with an earlier timestamp is considered the canonical PoS chain. If two forks have the same timestamp, the PoS block with an earlier checkpoint on Babylon is preferred.

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

• Slashing Rules: If validators do not withdraw their stake after detecting an attack, they may be slashed for having a double-signed conflicting PoS block. 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 users who can refer to Bitcoin to identify the canonical chain. So, they could fork the PoS chain while assigning Bitcoin timestamps to blocks on the canonical PoS chain. These PoS validators colluded with malicious Babylon validators and Bitcoin miners to fork Babylon and Bitcoin, replacing the Bitcoin block with timestamp t_2 with another block with timestamp t_3. In the eyes of later PoS clients, this would change the canonical PoS chain from the top chain to the bottom chain. While this was a successful security attack, it also resulted in the malicious PoS validators’ stakes being slashed because they had double-signed conflicting blocks without withdrawing their stakes.

• Suspension rules for unavailable PoS checkpoints:PoS validators must suspend their PoS chain immediately after observing 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 immediately halt the PoS chain after observing an unavailable checkpoint, then an attacker could potentially expose a previously unavailable attack chain, changing the canonical chain for later clients. This is because the checkpoints of the shadow chain that appeared later appeared earlier on Babylon. The suspension rule above explains why we require that the PoS block hashes sent as checkpoints are signed by the PoS validator set. If these checkpoints are not signed, any attacker can send an arbitrary hash and claim that it is the hash of a PoS block checkpoint that is unavailable on Babylon. PoS validators must be suspended at checkpoints. Note that creating an unavailable PoS chain is challenging: it requires at least two-thirds of PoS validators to sign PoS blocks without providing data to honest validators. However, in the hypothetical attack above, the malicious attacker paused the PoS chain but did not attack any 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 attacked, because it is extremely costly to attack PoS validators without affecting other PoS chains or Babylon itself, so the situation where two-thirds of PoS validators are attacked is basically impossible.

7. EigenLayer in BTC

Although Babylon is similar to EigenLayer in terms of purpose, it is far from a simple "fork" of EigenLayer. Given that DA cannot be used natively on the BTC main chain at present, the existence of Babylon is very important. This protocol not only brings security to external PoS chains, but is also crucial to the revitalization of the BTC internal ecosystem.

Use Cases

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

(1) Reduce the staking cycle and enhance security:PoS chains usually require social consensus (consensus among the community, node operators, and validators) to prevent long-range attacks. These attacks include rewriting the 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. Attackers can rewrite history by controlling the keys of early participants. In order to ensure the stability and security of the blockchain network consensus, a longer staking cycle is usually required. For example, Cosmos requires a 21-day unbinding period. However, with Babylon, the historical events of the PoS chain can be included in the BTC timestamp server, and BTC can be used as a trust source to replace social consensus. This can shorten the unbinding time to one day (equivalent to about 100 BTC block times). In addition, the PoS chain can achieve double security through native token staking and BTC staking.

(2) Cross-chain interoperability:Through the IBC protocol, Babylon can receive checkpoint data from multiple PoS chains and achieve 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.

(3) 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 work with these projects to develop some highly compatible solutions for mutual benefit and win-win results, and ultimately form a strong ecosystem similar to EigenLayer in Ethereum.

(4) 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 can be ensured. This mechanism helps prevent double-spending attacks and other cross-chain attacks.

8. Tower of Babel

The story of the Tower of Babel comes from the Bible, Genesis Chapter 11, verses 1-9. It is a classic story about how humans tried to build a tower to heaven but were thwarted by God. This story symbolizes human unity and striving for a common goal. 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 can it stand up 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 (liquidity staking derivatives) protocols, full-chain interoperability protocols, and Bitcoin ecosystem protocols. However, in terms of staking, Babylon is currently still behind EigenLayer, which can reuse staking and LSD in the Ethereum ecosystem. However, in the long run, a large amount of dormant Bitcoin in wallets and protocols has not yet been fully awakened, and this is just the tip of the $1.3 trillion iceberg. Babylon needs to form a positive symbiotic relationship with the entire Bitcoin ecosystem.

(1) 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 safe in themselves, will multi-layer staking cause the staking ecosystem to fall into a death spiral, leading to another major crash similar to the US interest rate hike? Since Ethereum transitioned to the PoS mechanism and the emergence of EigenLaeyr, the current staking field has indeed experienced an irrational boom. Projects usually attract high TVL users through large airdrop expectations and layered returns. ETH can be stacked with five or six layers through native staking, LSD, and LRT. This nesting doll operation increases the risk because any problem with one protocol may directly affect all related protocols, especially those at the end of the staking chain. If this model is adopted, the Bitcoin ecosystem with many centralized solutions will face greater risks.

However, it is important to note that Eigenlayer and Babylon are fundamentally about guiding the staking flywheel towards real utility, creating real demand to hedge against 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 returns. The more pressing question now is whether the business logic of the "shared security" protocol is truly viable.

(2) Real demand is the key

In Web3, whether it is a public chain or a protocol, the underlying logic usually involves matching buyers and sellers with specific needs. Projects that do well in this regard can "win the world" because blockchain technology ensures that the matching process is fair, real and trustworthy. In theory, shared security protocols can further complement the thriving staking and modular ecosystem. However, will supply far exceed demand? On the supply side, there are many projects and main chains that are able to provide modular security. On the demand side, existing PoS chains may not need or be willing to rent such security for the sake of face, while new PoS chains may find it difficult to pay the interest generated by large amounts of BTC and ETH. In order for EigenLayer and Babylon to form a closed business cycle, the revenue generated must be able to balance the interest generated by the staked tokens within the protocol. Even if this balance is achieved and the revenue far exceeds the interest expenses, these new PoS chains and protocols may still dry up. Therefore, how to balance the economic model, avoid bubbles caused by airdrop expectations, and promote the healthy relationship between supply and demand will be crucial.