Introduction
In the era of modularity led by Ethereum, providing security services through connecting the Data Availability (DA) layer is no longer a novelty. The concept of shared security brought by Staking now provides a new dimension to the modular race, leveraging the potential of “digital gold and silver” to offer security to numerous protocols and public chains in the blockchain space from Bitcoin or Ethereum. This narrative is quite grand, releasing liquidity worth trillions and being the key core of future scalability. Taking the recent Bitcoin staking protocol Babylon and the Ethereum ReStaking protocol EigenLayer as examples, which secured massive financing of $70 million and $100 million respectively, it is evident that top VCs highly recognize this track.
However, along with the acclaim, there are also many doubts. If modularity is the ultimate goal of scalability, and as key players, they will inevitably lock up a huge amount of BTC and ETH, is the security of the protocols worth questioning? Will the frenzy of “nested dolls” formed by numerous LSD and LRT protocols become the biggest black swan in the future blockchain space? Is the business logic reasonable? Since we have already analyzed EigenLayer in a previous article, the following discussion will mainly focus on Babylon to address these issues.
Extending Security Consensus
The most valuable public chains in the blockchain world to date are undoubtedly Bitcoin and Ethereum, with their years of accumulated security, decentralization, and value consensus being the key core that ensures their enduring dominance in the public chain space. They also possess scarce characteristics that are difficult for other heterogeneous chains to replicate. The core idea of modularity is to “rent” these characteristics to those in need. In the current modular approach, it mainly divides into two factions:
The first faction involves Layer 1 (usually Ethereum) with enough security serving as the lower three layers or partial functional layers of Rollups. This solution has the highest security and orthodox nature, incorporating resources from the main chain ecosystem. However, it is not particularly friendly in terms of throughput and cost for specific Rollups (application chains, long-tail chains, etc.).
The second faction involves recreating a presence with security close to Bitcoin and Ethereum and better cost performance, such as the well-known Celestia. By simplifying the architecture with pure DA functionality, minimizing node hardware requirements, reducing gas costs, and so on, it aims to quickly create a DA layer that is secure, decentralized, and high-performing enough to rival Ethereum. The downside of this solution is that security and decentralization still need time to mature, and it lacks orthodoxy, creating a competitive relationship with Ethereum, leading to rejection by the Ethereum community.
Another category within this faction includes Babylon and EigenLayer, utilizing the core idea of Proof-of-Stake (PoS) to create shared security services by leveraging the asset value of Bitcoin or Ethereum. Compared to the first two factions, this is a more neutral existence. Its advantages lie in inheriting orthodox security while providing more utility value to main chain assets and greater flexibility.
The Potential of Digital Gold
Regardless of the underlying logic of any consensus mechanism, the security of blockchain largely depends on the amount of resources it has. PoW chains require a lot of hardware and electricity, while PoS relies on the value of staked assets. Bitcoin itself is supported by a vast PoW hash power network, making it the most secure entity in the entire blockchain. However, as a circulating market value of $1.39 trillion, occupying a significant portion of the blockchain space, its assets are only used for two main scenarios: transactions and gas payments.
For the other significant portion of the blockchain space, especially since Ethereum’s shift to PoS after the Shanghai upgrade, most public chains default to using different PoS architectures for consensus. However, new heterogeneous chains themselves cannot attract large capital staking, raising significant security concerns. In the current modular era, while Cosmos zones and various Layer 2 solutions can use various DA layers to compensate, they also lose autonomy. For most old PoS mechanisms in public or consortium chains, using Ethereum or Celestia as DA is practically impossible. Babylon’s value lies in filling this gap, allowing BTC staking to protect 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 Network, bridge-packaged tokens to today’s runes and BTC Layer 2, each solution has inherent flaws. For Babylon to embody the security of Bitcoin and introduce a centralized solution relying on third-party trust assumptions is naturally the first thing to eliminate. Among the remaining solutions, runes and Lightning Network (limited by slow development progress) currently only have the ability to issue assets, meaning Babylon needs to design its own “scaling solution” to take Bitcoin native staking from 0 to 1.
Breaking down some of the basic elements of Bitcoin that can be utilized, they are nothing more than: UTXO model, timestamps, various signature methods, basic opcodes. Babylon’s proposed solution is to consider the weak programmability and data-carrying capacity of Bitcoin. Following the principle of minimalism, Babylon only needs to complete the necessary functions of the staking contract on Bitcoin, meaning BTC staking, slashing, rewards, withdrawal, etc., are all completed on the main chain. After achieving this 0 to 1, the complex requirements are then handed over to Cosmos zones. However, a key issue still remains, how to record PoS chain data on the main chain?
Remote Staking
The UTXO (Unspent Transaction Outputs) model, designed by Satoshi Nakamoto for Bitcoin, is a simple and concise transaction model. Transactions involve funds coming in and going out, and the entire transaction system only needs to express these forms of input and output. UTXO refers to funds that have come in but have not been spent when the funds going out are less, leaving behind unspent transaction outputs (unpaid bitcoins). The entire ledger of Bitcoin is essentially a collection of UTXOs, managing ownership and circulation of bitcoins by recording the state of each UTXO, where each transaction spends old UTXOs and generates new ones. Due to its potential for scalability, UTXO has become the starting point for many native scaling solutions. For example, utilizing UTXO and multisig to create penalty mechanisms and state channels in the Lightning Network, or binding UTXO to implement semi-fungible tokens like runes and glyphs. All these solutions are based on this critical starting point to become a reality.
Babylon naturally needs to leverage UTXO to implement the staking contract (referred to as remote staking by Babylon, transmitting BTC security to PoS chains through an intermediate layer). By cleverly combining existing opcodes, the specific steps for implementing the contract can be broken down into four:
Locking funds: Users send funds to an address controlled by multisig. By using OP_CTV (OP_CHECKTEMPLATEVERIFY, allowing the creation of predefined transaction templates to ensure funds can only be spent according to specific conditions), the contract can specify that funds can only be spent when certain conditions are met. Once the funds are locked, a new UTXO is generated to represent the staked funds.
Condition verification: Using OP_CSV (OP_CHECKSEQUENCEVERIFY, allowing the setting of a relative time lock based on the transaction’s sequence number), time locking can be implemented to ensure funds cannot be withdrawn within a certain timeframe. Combining OP_CTV as mentioned earlier allows for staking, unstaking (staking can be spent after the staking time is met), slashing (if a staker behaves maliciously, the UTXO will be forced to be spent to a lock address and restricted from being spent, similar to a black hole address).
State update: Every time a user stakes or withdraws staked funds, it involves creating and spending UTXOs. New transaction outputs generate new UTXOs, while old UTXOs are marked as spent. This way, every transaction and fund flow is accurately recorded on the blockchain, ensuring transparency and security.
Earnings distribution: Based on the staked amount and staking time, the contract calculates the rewards due and distributes them by 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, consideration needs to be given to recording historical events on external chains. In Satoshi Nakamoto’s whitepaper, the Bitcoin blockchain introduced a timestamp concept supported by PoW, providing irreversible time sequencing for events. In the native use cases of Bitcoin, these events refer to various transactions executed on the ledger. Today, to enhance the security of other PoS chains, Bitcoin can also be used to timestamp events on external blockchains. Each time such an event occurs, it triggers a transaction sent to miners, who then insert it into the Bitcoin ledger, adding a timestamp to the event. These timestamps can be used to address various security issues in blockchain. The general concept of adding timestamps to events in child chains on the parent chain is called “checkpointing,” while the transactions used to add timestamps are called checkpoint transactions. Specifically, the timestamp in the Bitcoin blockchain has the following important characteristics:
Time format: The timestamp records the number of seconds since January 1, 1970, 00:00:00 UTC, in a format known as Unix timestamp or POSIX time.
Function: The main function of the timestamp is to identify the time of block generation, assisting nodes in determining the order of blocks and aiding in network difficulty adjustment mechanisms.
Timestamp and difficulty adjustment: The Bitcoin network adjusts the mining difficulty every 2016 blocks (approximately every two weeks). The timestamp plays a critical role in this process because the network adjusts mining difficulty based on the total generation time of the most recent 2016 blocks, ensuring a new block generation speed close to 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 the previous few blocks and cannot exceed the network time by 120 minutes (i.e., 2 hours into the future).
The timestamp server is a new primitive defined by Babylon, allowing Bitcoin timestamps to be allocated to PoS blockchains through Babylon checkpoints, ensuring the accuracy of the time sequence and preventing tampering. This server serves as the core source of trust requirements in the entire Babylon architecture.
Babylon’s Three-Layer Architecture
As shown in the diagram above, Babylon’s overall architecture can be divided into three layers: Bitcoin (as the timestamp server), Babylon (a Cosmos Zone), serving as the intermediate layer, and the PoS chain demand layer. Babylon refers to the latter two as the Control Plane (Babylon itself) and Data Plane (various PoS consumer chains).
Understanding the protocol’s basic implementation of trustlessness, let’s further explore how Babylon itself bridges the two ends using Cosmos zones. 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 them to Bitcoin. By using aggregate signatures from 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 various PoS chains download Babylon blocks and observe whether their PoS checkpoints are included in the Babylon blocks checked by Bitcoin. This enables PoS chains to detect discrepancies, such as if Babylon validators create an invalid block checked by Bitcoin and lie about the PoS checkpoints included in the invalid block. The main components of the protocol include:
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 signatures of a 2/3 validator set that signed the block for final confirmation. Babylon checkpoints also include the Epoch number. PoS blocks can timestamp Bitcoin blocks through Babylon checkpoints. For example, the first two PoS blocks are allocated timestamps from Babylon blocks, which in turn are set by a Bitcoin block with timestamp t_3. Therefore, these PoS blocks are assigned Bitcoin timestamps.
In conclusion, Babylon’s innovative approach to combining security, staking, and interoperability can potentially revolutionize the blockchain space, providing a secure and efficient way for various PoS chains to benefit from the security of Bitcoin. By leveraging UTXO, timestamps, and a three-layer architecture, Babylon opens up new possibilities for cross-chain transactions and scalability in the blockchain ecosystem.
