Introduction
In the modular era led by Ethereum, providing security services through connecting the Data Availability (DA) layer is nothing new. However, the concept of shared security brought by Staking is providing a new dimension to the modular track, utilizing the potential of “digital gold and silver” to offer security to numerous blockchain protocols and public chains from Bitcoin or Ethereum. This narrative is quite grand, releasing trillions of market value in liquidity while being a key core for future scalability. For example, the recent Bitcoin staking protocol Babylon and the Ethereum ReStaking protocol EigenLayer have raised huge amounts of funding, $70 million and $100 million respectively. It is evident that top VCs highly approve of this track.
However, there are many doubts that come along with it. If modularity is the ultimate goal of scalability, then as key members, locking up vast amounts of BTC and ETH, is the security of the protocol worth questioning? Will the crazy “nesting dolls” formed by many LSD and LRT protocols become the biggest black swan in the future blockchain? Is the business logic rational? Since we have already analyzed EigenLayer in previous articles, this article will mainly discuss the above issues through Babylon.
Extending Security Consensus
The most valuable public chains in the blockchain world today are undoubtedly Bitcoin and Ethereum, with their years of accumulation of security, decentralization, and value consensus being the key core that ensures both can stand tall on the public chain mountain year after year. It is also a scarce characteristic that is most difficult to replicate for other heterogeneous chains. The core of modular thinking is to “rent out” these characteristics to those in need. In the current modular thinking, it is mainly divided into two factions:
The first faction has a Layer 1 with sufficient security (usually Ethereum) as the lower three layers or partial functional layers of Rollups. This solution has the highest security and legitimacy, and can also absorb resources from the main chain ecosystem. However, for specific Rollups (application chains, long-tail chains, etc.), throughput and cost are not particularly friendly.
The second faction is to recreate an entity with security close to Bitcoin and Ethereum and better cost efficiency. For example, Celestia, known to us, achieves this through pure DA functional architecture, minimizing node hardware requirements, low gas costs, etc., in a simplified manner to create a DA layer that is secure, decentralized, and high-performance comparable to Ethereum’s. The disadvantage of this solution is that security and decentralization still need time to complete, and it lacks legitimacy and competes overtly with Ethereum, which has been rejected by the Ethereum community.
Another type in this faction is Babylon and Eigenlayer, which use the core idea of POS (Proof-of-Stake) to create shared security services using the asset values of Bitcoin or Ethereum. Compared to the first two, it is a more neutral existence. Its advantage lies in inheriting legitimacy and security while giving main chain assets more utility value and flexibility.
The Potential of Digital Gold
Regardless of the underlying logic of any consensus mechanism, the security of a blockchain largely depends on how much resources support it. PoW chains require a lot of hardware and electricity, while PoS relies on the value of staked assets. Bitcoin itself is supported by an extremely large PoW hashing power network, making it the most secure entity in the entire blockchain. However, as a circulating market value of $1.39 trillion, occupying half of the blockchain world, its asset role is limited to only two main use cases: transfers and gas payments.
For the other half of the blockchain world, especially since Ethereum’s transition to PoS, most public chains default to using PoS with different architectures for consensus. However, new heterogeneous chains themselves cannot attract significant capital staking, leading to significant security concerns. In the current modular era, although Cosmos zone and various Layer 2 solutions can use various DA layers to compensate, they also lose autonomy. For most old PoS public chains or consortium chains, using Ethereum or Celestia as DA is almost impossible, and Babylon’s value lies in filling this gap by staking BTC to provide protection for PoS chains. Just as in the past, humans used gold to support the value of paper money, BTC is indeed well-suited to play this role in the blockchain world.
From 0 to 1
Releasing “digital gold” has always been the most grand and difficult narrative to achieve in the blockchain space. From early sidechains, lightning networks, bridge-packaged tokens to today’s runes and BTC Layer 2, it can be said that each solution has inherent flaws. If Babylon is to embody the security of Bitcoin, the introduction of a centralized solution relying on third-party trust assumptions needs to be eliminated first. Among the remaining solutions, runes and lightning networks (limited by very slow development progress) currently have the ability to issue assets, meaning that Babylon needs to design its own “scaling solution” to take Bitcoin native staking from 0 to 1.
Breaking down some basic elements of Bitcoin that are currently usable boils down to: 1. UTXO model, 2. Timestamp, 3. Multiple signature methods, 4. Basic opcodes. Babylon’s solution is based on the weak programmability and data-carrying capacity of Bitcoin. Following the principle of minimalism, Babylon only needs to fulfill the necessary functions for staking contracts on Bitcoin, meaning that BTC staking, slashing, rewards, withdrawals, etc., are all completed on the main chain. After achieving this 0 to 1, the more complex demands are handed over to Cosmos zone. However, a key issue remains: how to record PoS chain data on the main chain?
Remote Staking
UTXO (Unspent Transaction Outputs) is a transaction model designed by Satoshi Nakamoto for Bitcoin, with a core idea that is extremely simple. Transactions are simply funds coming in and going out, so the entire transaction system only needs to express these in two forms: inputs and outputs. UTXO refers to funds coming in, but when there aren’t enough funds going out, the remaining part is the unspent transaction output (i.e., Bitcoin that hasn’t been spent). The entire ledger of Bitcoin is actually a collection of UTXOs, managing the ownership and circulation of Bitcoin by recording the status of each UTXO, where each transaction spends old UTXOs and generates new ones. Because of its potential for scalability, it has naturally become the starting point for many native scaling solutions. For example, using UTXO and multisig to create penalty mechanisms and state channels in the Lightning Network, or binding UTXO to implement semi-fungible tokens like inscriptions, runes, etc. All these are based on this crucial starting point to become a reality.
Babylon naturally needs to use UTXO to implement staking contracts (Babylon refers to this as remote staking, where BTC security is transmitted to PoS chains through an intermediary layer). By cleverly combining existing opcodes in their approach, the specific steps to implement the contract can be broken down into four steps:
Locking funds: Users send funds to an address controlled by a multisig. Through OP_CTV (OP_CHECKTEMPLATEVERIFY, which allows the creation of predefined transaction templates to ensure that funds can only be spent according to specific conditions), the contract can specify that these funds can only be spent under specific conditions. After the funds are locked, a new UTXO is generated to represent the staked funds.
Condition verification: Using OP_CSV (OP_CHECKSEQUENCEVERIFY, which allows setting a relative time lock based on the transaction’s sequence number, indicating that the UTXO cannot be spent until a certain time has passed), time locking can be achieved to ensure that funds cannot be withdrawn for a certain period. By combining OP_CTV as mentioned earlier, staking, unstaking (staking participants can spend the locked UTXO when the staking period is met), slashing (if stakers behave maliciously, the UTXO will be forcibly spent to a locked address and restricted from being spent, similar to a black hole address) can be achieved.
State update: Whenever a user stakes or unstakes funds, it involves the creation and spending of UTXOs. New transaction outputs will generate new UTXOs, while old UTXOs will be marked as spent. This way, each transaction and fund flow is accurately recorded on the blockchain, ensuring transparency and security.
Profit distribution: Based on the staked amount and staking duration, the contract calculates the rewards due and distributes them through generating new UTXOs. These rewards can be unlocked and spent after meeting specific conditions set in the script.
Timestamp
With a native staking contract in place, there is a need to consider recording historical events from external chains. In Satoshi Nakamoto’s whitepaper, the Bitcoin blockchain introduced a timestamp concept supported by PoW, providing irreversible time sequencing for events. In Bitcoin’s native use cases, these events refer to various transactions executed on the ledger. Nowadays, to enhance the security of other PoS chains, Bitcoin can also be used to timestamp events on external blockchains. Each time such an event occurs, it triggers a transaction sent to miners, who then insert it into the Bitcoin ledger, adding a timestamp to the event. These timestamps can be used to address various security issues on the blockchain. The general concept of adding timestamps to events on a child chain from a parent chain is called “checkpointing”, and the transactions used to add timestamps are called checkpoint transactions. Specifically, the timestamps in the Bitcoin blockchain have the following important characteristics:
Timestamp format: The timestamp records the number of seconds since 00:00:00 UTC on January 1, 1970, in a format known as Unix timestamp or POSIX time.
Function: The main function of timestamps is to identify the generation time of blocks, help nodes determine the order of blocks, and assist in network difficulty adjustment mechanisms.
Timestamp and difficulty adjustment: The Bitcoin network undergoes a difficulty adjustment every 2016 blocks (approximately every two weeks). Timestamps play a crucial role in this process, as the network adjusts mining difficulty based on the total generation time of the most recent 2016 blocks to ensure a new block’s generation speed is close to one every 10 minutes.
Validity check: Nodes verify the timestamp when receiving a new block. A new block’s timestamp must be greater than the median time of several previous blocks and cannot exceed the network time by 120 minutes (i.e., the future 2 hours).
The timestamp server is a new primitive defined by Babylon, allowing Bitcoin timestamps to be allocated to PoS blockchains through Babylon checkpointing, ensuring the accuracy of the time series and preventing tampering. This server serves as the core source of trust requirements in Babylon’s entire architecture.
Babylon’s Three-Layer Architecture
As shown in the above image, Babylon’s overall architecture can be divided into three layers: Bitcoin (as the timestamp server), Babylon (a Cosmos Zone), acting as the intermediary layer, and the PoS chain demand layer. Babylon refers to the latter two as the Control Plane (Babylon itself) and the Data Plane (various PoS consumer chains).
Understanding the basic implementation of trustlessness in the protocol, let’s look at how Babylon itself connects both ends through Cosmos zone. According to Stanford Tse Lab’s detailed explanation of Babylon, Babylon can receive checkpoint streams from multiple PoS chains and merge these checkpoints before publishing to Bitcoin. By using the aggregate signatures of Babylon validators, the size of checkpoints can be minimized, and the frequency of these checkpoints can be controlled by allowing Babylon validators to change only once per Epoch.
Validators of each PoS chain download Babylon blocks to observe if their PoS checkpoints are included in the Bitcoin checkpoints set by Babylon blocks. This allows PoS chains to detect discrepancies, for example, if Babylon validators create an unavailable block checked by Bitcoin and lie about the PoS checkpoints included in the unavailable block. The main components of the protocol are as follows:
Checkpoint: Only the last block of a Babylon Epoch is checked by Bitcoin. The checkpoint consists of the block’s hash and a single aggregate BLS signature corresponding to the signature of a 2/3 validator set that has signed the block for final confirmation. Babylon checkpoints also include the Epoch number. PoS blocks can receive Bitcoin block timestamps through Babylon checkpoints. For example, the first two PoS blocks are set with checkpoints by Babylon blocks, and Babylon blocks are set with checkpoints by a Bitcoin block with a timestamp of t_3. Therefore, these PoS blocks are allocated Bitcoin timestamps.
In conclusion, Babylon introduces a novel approach to sharing security resources across multiple blockchain networks, leveraging the staking capabilities of Bitcoin to enhance the security of PoS chains. Through its innovative three-layer architecture and sophisticated protocols, Babylon aims to bridge the gap between traditional PoS chains and the broader blockchain ecosystem.
In the event of a fork in the PoS chain, the chain with the earlier timestamp is considered the standard PoS chain. If two forks have the same timestamp, the tie is broken in favor of the PoS blocks with an earlier checkpoint on Babylon.
Withdrawal rules dictate that to withdraw, validators must send a withdrawal request to the PoS chain. The PoS block containing the withdrawal request is checked by Babylon, then by Bitcoin, and assigned a timestamp t_1. Once a Bitcoin block with a timestamp of t_1 reaches a depth of k, the withdrawal is granted on the PoS chain. If validators who have withdrawn their stake engage in a long-range attack, blocks on the attacking chain can only be assigned a Bitcoin timestamp later than t_1. By observing the order of these checkpoints on Bitcoin, the PoS client can distinguish between the standard chain and the attacking chain, allowing the attacking chain to be disregarded.
Penalty rules apply if validators fail to withdraw their stake upon detecting an attack, leading to penalties for validators with conflicting double-signed PoS blocks. Malicious PoS validators know that if they wait until the withdrawal request is approved to engage in a long-range security attack, they won’t be able to deceive clients who can verify the standard chain by looking at Bitcoin. Therefore, they may fork the PoS chain when assigning Bitcoin timestamps to blocks on the standard PoS chain. By collaborating with malicious Babylon validators and Bitcoin miners, these PoS validators can fork Babylon and Bitcoin, replacing a Bitcoin block with a timestamp t_2 with another block at timestamp t_3. In the view of subsequent PoS clients, this changes the standard PoS chain from the top chain to the bottom chain. While this is a successful security attack, it results in the stake of malicious PoS validators being penalized because they have conflicting double-signed blocks but have not withdrawn their stake.
Stop rules for unavailable PoS checkpoints dictate that PoS validators must pause their PoS chain upon observing unavailable PoS checkpoints on Babylon. An unavailable PoS checkpoint is a hash signed by 2/3 of PoS validators, corresponding to a PoS block that cannot be observed. Failure to pause the PoS chain upon observing unavailable checkpoints allows attackers to reveal previously unavailable attack chains, altering the standard chain in later client views. This is because the checkpoints of the shadow chain revealed later appear earlier on Babylon. The above pause rule explains why PoS block hashes sent as checkpoints must be signed by a set of PoS validators. Without these signatures, attackers could send arbitrary hashes and claim they are checkpoints for unavailable PoS blocks on Babylon. PoS validators would then have to pause the checkpoints. Creating an unavailable PoS chain is difficult and requires disrupting at least 2/3 of PoS validators to finalize PoS blocks but not provide data to honest validators. However, in the assumed attack above, the malicious party halted the PoS chain without attacking any validators. To prevent such attacks, PoS checkpoints must be verified by 2/3 of PoS validators. Therefore, Babylon will only have unavailable PoS checkpoints when 2/3 of PoS validators are actually controlled by attackers. Due to the cost of disrupting PoS validators, such attacks are highly unlikely and do not affect other PoS chains or Babylon itself.
Stop rules for unavailable Babylon checkpoints require PoS and Babylon validators to pause their blockchain upon observing unavailable Babylon checkpoints on Bitcoin. An unavailable Babylon checkpoint is a hash signed by 2/3 Babylon validators, corresponding to a Babylon block that cannot be observed. Failure to pause the Babylon blockchain upon observing unavailable checkpoints allows attackers to reveal previously unavailable Babylon chains, altering the standard Babylon chain in later client views. Similarly, failure by PoS validators to pause the PoS chain allows attackers to reveal previously unavailable PoS attack chains and Babylon chains, altering the standard PoS chain in later client views. This is because the dark Babylon chain revealed later has an earlier timestamp on Bitcoin and includes checkpoints of previously revealed PoS attack chains. Like the pause rule for unavailable PoS checkpoints, the above rule explains why Babylon block hashes sent as checkpoints must be accompanied by an aggregate BLS signature to prove the signatures of 2/3 Babylon validators. If Babylon checkpoints are not signed, any adversary can send arbitrary hashes and claim they are checkpoints for unavailable Babylon blocks on Bitcoin. Subsequently, PoS validators and Babylon validators would have to wait for a checkpoint with no unavailable Babylon or PoS chains in their preimage. Creating an unavailable Babylon chain requires disrupting at least 2/3 of Babylon validators. However, in the assumed attack above, the attacker halted all chains in the system without disrupting a single Babylon or PoS validator. To prevent such attacks, Babylon checkpoints must be proven by an aggregate signature. Therefore, there will only be unavailable Babylon checkpoints when 2/3 of validators are indeed compromised, making data availability attacks highly unlikely. But in extreme cases, it can affect all PoS chains by forcing them to pause.
Eigenlayer in BTC
While Babylon may seem similar to Eigenlayer in purpose, it is far from being a simple “Eigenlayer” fork. Given the current limitations of native use in the BTC main chain, Babylon’s existence is meaningful. The protocol not only brings security to external PoS chains but is also crucial for revitalizing the ecosystem within BTC.
Use Cases
There are many potential use cases within Babylon, some of which have already been implemented or may be implemented in the future:
1. Shortening staking periods and enhancing security: PoS chains typically require social consensus (consensus between the community, node operators, and validators) to prevent long-range attacks, where the blockchain history is rewritten to manipulate transaction records or control the chain. This type of attack is particularly severe in PoS systems because unlike PoW, PoS validators engaging in consensus do not require significant computational resources. Attackers can rewrite history by controlling early stakers’ keys. To ensure consensus stability and security in the blockchain network, long staking periods are essential, such as the 21-day undelegating period in Cosmos. However, through Babylon, historical events in PoS chains can be integrated into the BTC timestamp server, allowing BTC to serve as a trust source to replace social consensus. This reduces the undelegating time to just 1 day (after approximately 100 BTC blocks have been mined), with PoS chains having dual security of native token staking and BTC staking at this point.
2. 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.
3. Integrating the BTC ecosystem: Most projects in the current BTC ecosystem lack sufficient security, relying on third-party trust assumptions in Layer 2, LRT, or DeFi. These protocols hold significant amounts of BTC in their addresses and may find potential synergies with Babylon in the future, mutually benefiting and eventually forming a robust ecosystem similar to Eigenlayer in Ethereum.
4. Cross-chain asset management: The Babylon protocol can be used to securely manage 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 Babylon
The story of the Tower of Babylon originates from Genesis 11:1-9 in the Bible, where humanity attempts to build a tower to reach the heavens, only to be thwarted by God. The allegory symbolizes human unity and common goals. This is also the potential meaning behind the Babylon protocol, aiming to construct a Tower of Babylon for many PoS chains and unite them. Narratively, it doesn’t seem inferior to Eigenlayer, the Ethereum defender, but how does it fare in reality?
As of now, the Babylon testnet has provided security guarantees to 50 Cosmos zones through the IBC protocol. Beyond Cosmos, Babylon has also collaborated with some LSD (liquidity staking) protocols, full-chain interoperability protocols, and Bitcoin ecosystem protocols for integration. On the staking front, while Eigenlayer can reuse staking within the Ethereum ecosystem and LSD, Babylon currently lags slightly behind. However, looking ahead, with vast amounts of BTC still dormant in various wallets and protocols, the current Babylon needs to actively complement the entire BTC ecosystem.
The Unique Solution of Parallel Nesting
As mentioned earlier, Eigenlayer and Babylon are gaining traction, and based on current trends, both protocols will lock up massive amounts of core blockchain assets in the future. While the security of these two protocols may not be in question, will multiple layers of nesting lead the entire staking ecosystem into a downward spiral, similar to a substantial interest rate hike in the US? The staking track has indeed experienced a prolonged period of irrational prosperity after Ethereum transitioned to PoS and Eigenlayer emerged. To attract higher TVL, projects often offer numerous airdrops and stacking rewards, luring users with multiple layers of nesting, such as staking ETH natively, then in LSD, LRT, and even stacking 5 or 6 times. Naturally, this poses significant risk issues with multiple layers of nesting, as a problem in one protocol can directly impact all protocols involved in nesting, especially those at the tail end of the nesting structure. Moreover, the BTC ecosystem has many centralized solutions, and replicating this approach risks even greater consequences. However, it’s crucial to note that Eigenlayer and Babylon are guiding the staking flywheel towards genuine practical value, aiming to create real supply and demand to offset such risks. So, while the existence of “shared security” protocols indirectly or directly exacerbates unhealthy practices, it also provides the only solution to break free from the side returns of parallel nesting. The main issue now is whether the business logic of “shared security” protocols is truly valid.
Real Supply and Demand is Key
In Web3, whether on public chains or protocols, the underlying logic often revolves around matching buyers and sellers with certain needs. Those who match properly can gain “the world,” with blockchain merely ensuring fair, genuine, and trustworthy matchmaking. In theory, shared security protocols can complement the current thriving staking and modular ecosystem. However, upon closer examination, will this supply far exceed demand? On the supply side, there are numerous projects and main chains that can provide modular security. On the other hand, established PoS chains may not require or, due to prestige, may not lease such security. Additionally, new PoS chains may struggle to afford the massive interest generated by BTC and ETH. For the business logic of Eigenlayer and Babylon to form a closed loop, they need to earn income that balances out with the interest generated by staking tokens within the protocol. And even if this balance is achieved, or even if the earnings far exceed interest expenses, this could lead to a parasitic relationship with new PoS chains and protocols. Therefore, striking a balance in economic models and avoiding reliance on airdrop expectations for development, while driving a healthier interaction between supply and demand, is crucial.
References:
1. A Comprehensive Explanation of How Babylon Benefits from Bitcoin’s Security in the Cosmos Ecosystem:
https://www.chaincatcher.com/article/2079486
2. Understanding Eigenlayer in Depth: Can Ethereum Break Free from the Nesting Dilemma?:
https://haotiancryptoinsight.substack.com/p/eigenlayer?utm_source=publication-search
3. Conversation with Babylon Co-founder Fisher Yu: How to Unlock Liquidity for 21 Million BTC through Staking?:
https://www.chaincatcher.com/article/2120653
4. Triangular Debt or Mild Inflation: An Alternative View of Re-staking:
https://mp.weixin.qq.com/s/dMc_WzndAZXRjnEgD2hcew
5. A look at what I’ve been seeing in crypto lately:
https://theknower.substack.com/p/a-look-at-what-ive-been-seeing-in
