Author: Zeke, YBB Capital Source: medium Translation: Shan Ouba, Golden Finance
Preface
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, as it not only unlocks liquidity for trillions of dollars worth of assets, but is also a key element of future scaling solutions. For example, the recent Bitcoin staking protocol Babylon raised a huge $70 million fund, and the Ethereum re-staking protocol EigenLayer raised $100 million in funds, 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 question of the security of the protocol itself. 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 already analyzed EigenLayer in a previous article, the following discussion will focus mainly on Babylon to address these issues.
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 to replicate in other heterogeneous chains. The core idea of modularity is to "rent" these qualities to those in need. In the current modularization approach, there are two main factions:
The first group uses a sufficiently secure layer 1 (usually Ethereum) as the bottom three layers or part of the functional layer of Rollups. This solution has the highest security and legitimacy and can absorb the resources of 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 group aims to create a security layer 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 Layer. 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 for the assets of the main chain and providing greater flexibility.
The potential of digital gold
Regardless of the underlying logic of any consensus mechanism, the security of a 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 in the entire blockchain space. However, as a public chain with a circulating market value of $1.39 trillion 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 default to using different PoS architectures 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 is often at the cost of autonomy. For most old PoS mechanisms or consortium chains, it is also generally impractical to use Ethereum or Celestia as a DA layer. The value of Babylon 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 to play this role in the blockchain world.
From 0 to 1
Unleashing "digital gold" has always been the most ambitious but most difficult goal in the blockchain space. 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, then centralized solutions that introduce third-party trust assumptions must first be ruled out. Of the remaining options, Runes 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.
Breaking down the basic elements currently available on Bitcoin, there are essentially the following: 1. UTXO model, 2. Timestamp, 3. Various signature methods, 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 pledge contract need to be completed, which means that BTC's pledge, 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: a transaction is just the inflow and outflow 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., unpaid bitcoin). The entire Bitcoin ledger is essentially a collection of UTXOs, which records the status of each UTXO to manage the ownership and circulation of Bitcoin. Each transaction spends old UTXOs and generates new UTXOs. Due to its inherent scalability potential, UTXO naturally becomes 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 transferred to the PoS chain through an intermediary layer). The implementation of the contract can be divided into four steps, which cleverly combines the existing opcodes:
Locking Funds
Users send funds to an address controlled by a multi-signature. Through OP_CTV (OP_CHECKTEMPLATEVERIFY, which allows the creation of predefined transaction templates that 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 Validation
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), time locks can be implemented. Combined with OP_CTV, staking, unstaking (allowing the staker to spend the locked UTXO after the staking period is met) and slashing (if the staker behaves maliciously, the UTXO is forced to be spent to a locked address, making it unspendable, similar to a black hole address) can be implemented.
Status Update
Every time 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 timestamping 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 miners, who then insert it into the Bitcoin ledger, thus timestamping the event. These timestamps can solve various security issues of blockchains. The general concept of timestamping events in a child chain on a parent chain is called "checkpointing", and the transactions used to add timestamps are called checkpoint transactions. Specifically, timestamping in the Bitcoin blockchain has 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 timestamp is to mark the block generation time, 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 crucial role in this process, as 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 (2 hours in the future).
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 non-tamperability of time series. As the top layer of the entire Babylon architecture, the server is the core source of trust.
Babylon's three-tier 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 sizes 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 Babylon blocks that are verified by Bitcoin. This allows PoS chains to detect discrepancies, such as if a Babylon validator created an unavailable block verified by Bitcoin and lied about the PoS checkpoints included 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 block's hash and a single aggregated BLS signature corresponding to the signatures of a two-thirds majority of validators who signed finality on the block. Babylon checkpoints also include the epoch number. PoS blocks can be assigned a Bitcoin timestamp via a Babylon checkpoint. For example, the first two PoS blocks were checkpointed by a Babylon block and then by a Bitcoin block with timestamp t_3. Therefore, these PoS blocks were assigned a Bitcoin timestamp of 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, a 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, which assigns it a timestamp t_1. Once a Bitcoin block with timestamp t_1 reaches depth k, the withdrawal is approved on the PoS chain. If the validator withdrawing the stake attempts a long-range attack, blocks on the attack 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 cannot deceive clients that can reference Bitcoin to identify the canonical chain. Therefore, they may fork the PoS chain while assigning Bitcoin timestamps to blocks on the canonical PoS chain. These PoS validators work 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 will change the canonical PoS chain from the top chain to the bottom chain from the perspective of later PoS clients. This is a successful security attack despite being a successful security attack.
Unavailable PoS checkpoint suspension rule: PoS validators must pause 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 pause 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 checkpoints of the later revealed shadow chain appeared earlier in Babylon. The suspension rule above explains 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 a PoS block checkpoint that is unavailable on Babylon. PoS validators must then pause at the checkpoint. Note that creating an unavailable PoS chain is challenging: it requires compromising at least two-thirds of PoS validators to sign on 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 that PoS checkpoints are signed by two-thirds of PoS validators. Therefore, unavailable PoS checkpoints will not occur 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 on 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 that PoS checkpoints are signed by two-thirds of PoS validators. Therefore, unavailable PoS checkpoints will not occur 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 hypothetical attack 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 changing 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 changing the canonical PoS chain in the view of later clients. This is because the later disclosed Babylon deep chain has an earlier timestamp on Bitcoin and contains the checkpoints of the later disclosed 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 can force 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 to revitalizing the BTC ecosystem internally.
Example
Babylon offers many potential use cases, some of which have already been implemented or may have the opportunity to be implemented in the future:
Shorten the staking cycle and enhance security: PoS chains usually require social consensus (consensus between 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 pledgers. 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 source of trust 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, from Genesis 11:1-9 in the Bible, is a classic story of humanity’s attempt to build a tower to the sky but being thwarted by God. The story symbolizes human unity and 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 Ethereum’s defender, Eigenlayer. 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 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 tend to attract users with high TVL through huge airdrop expectations and tiered returns. One ETH can go through native staking, LSD, and LRT, stacking up to five or six layers. This stacking increases the 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 about guiding the staking flywheel towards real utility, creating real demand to offset 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 actually feasible.
Real needs are 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. If you do this, you can "win the world" because blockchain technology ensures that the matching process is fair, authentic, 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. Let Eigenlayer and Babylon form a closed business loop, and 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.
