Due to the inability of the Bitcoin mainnet to support complete smart contracts, the architecture design and application scenarios of Babylon have many differences from EigenLayer.
Authored by: Shawn, E2M Research
The Restaking track represented by EigenLayer has received great attention and has become one of the hottest directions on Ethereum. E2M Research has also conducted many discussions on EigenLayer. EigenLayer extends the security of ETH to other applications on the blockchain network, while providing additional income to ETH or LST holders who participate.
Similarly, Babylon allows Bitcoin users to stake BTC to enhance the security of the PoS network, increase network security, earn income, and maintain self-custody of Bitcoin. Due to the inability of the Bitcoin mainnet to support complete smart contracts, the architecture design and application scenarios of Babylon have many differences from EigenLayer. Anurag Arjun, former founder of Polygon and founder of Avail, also stated on social media that Babylon is severely underestimated compared to projects like EigenLayer. It will suddenly gain momentum at some point, which will be a major breakthrough for the BTC ecosystem.
This article hopes to provide a deeper understanding of the similarities and differences between the two projects by comparing them from various aspects.
Introduction to Babylon
Babylon is a Bitcoin security sharing protocol. Currently, it includes two protocols:
Bitcoin Timestamp: This protocol sends a concise and verifiable timestamp of any data (such as PoS blockchain) to Bitcoin.
Bitcoin Staking: This protocol allows Bitcoin assets to be staked in a trustless (and self-custodial) manner to provide economic security for any decentralized system.
Bitcoin Timestamp Protocol
First is the structure diagram of the Bitcoin Timestamp Protocol:
Babylon's architecture is shown in the above diagram. It consists of three parts and has two levels of checkpoints:
Bitcoin, as the timestamp service layer;
Babylon chain (a chain built on the Cosmos SDK), as the middle layer;
PoS blockchain (e.g., other Cosmos zones) as secure consumers;
An important design consideration is that the data capacity that Bitcoin can carry is very limited. In this case, the Babylon chain has multiple functions:
It aggregates checkpoint streams of many PoS consumer chains, so only one checkpoint stream needs to be inserted into the Bitcoin network to timestamp events for all consumer PoS chains.
Checkpoints in the Bitcoin network can be made compact using cryptographic techniques (e.g., aggregate signatures).
It receives checkpoints from consumer PoS chains through the IBC protocol.
It checks the data availability of the checkpoints of the consumer PoS chains to prevent attackers from timestamping unavailable data.
This structure helps enhance the security of PoS chains, such as resisting long-range attacks.
To protect PoS chains from long-range attacks, we can send the block checkpoints of the PoS chain to BTC and select the fork with the earlier BTC timestamp as the legitimate fork. In this way, there are only two possibilities:
The attacking fork will have a later timestamp on the BTC mainnet, so it will never be chosen by anyone, or
In order to be selected, the attacker must create a very long BTC fork, in which the attacked PoS fork has an earlier timestamp, which is economically infeasible.
Therefore, long-range attacks can be mitigated by BTC timestamps.
In addition to addressing long-range attacks, the irreversible BTC timestamps of PoS blocks provide other security advantages for PoS chains:
Elimination of weak subjectivity: Bitcoin timestamps are objective, eliminating the reliance of PoS chains on social consensus and weak subjectivity.
Shorter unbonding time: By replacing social consensus, BTC timestamps can reduce the unbonding time of PoS chains from weeks to one day.
New chain protection: PoS chains with lower valuations are more susceptible to fork attacks. BTC timestamps can help protect the growth of the chain itself.
Validation of state synchronization and snapshots: The objective facts provided by BTC allow users of PoS chains to verify the chain state or snapshots downloaded from the P2P network.
Protection of important transactions: BTC timestamps can be used to further confirm important PoS transactions, at the cost of longer confirmation delays.
Resistance to censorship: BTC timestamps can also be used to counter transaction censorship in PoS chains by publishing censored transactions to BTC.
Bitcoin Staking Protocol
Babylon's Bitcoin staking protocol allows Bitcoin holders to stake BTC without the need to trust any third party; this staking provides a "comprehensive" slashable staking security guarantee for the PoS chain by simply cross-chain bridging Bitcoin to the PoS chain.
Here is an example of Bitcoin staking:
Alice has one Bitcoin and wants to stake it on a PoS chain. First, she enters a staking contract by sending a staking transaction to the Bitcoin chain. This transaction locks her Bitcoin in a self-custodial vault. The locked Bitcoin can only be unlocked by Alice's private key through one of the following two methods:
(1) Alice initiates an "unbonding transaction," in which case the Bitcoin will be unlocked and returned to Alice within three days.
(2) Alice initiates a "slashing transaction," sending the Bitcoin to a burn address.
Once the staking transaction enters the Bitcoin chain, Alice can start signing blocks with her key to validate the PoS chain. During her validation duty, there are two possible paths.
One is the "happy path" (as shown in (a)), where Alice honestly follows the protocol, and when she wants to unbond the staked Bitcoin, she initiates an unbonding request by sending an unbonding transaction to the Bitcoin chain (as shown in (b)). Once the unbonding transaction enters the Bitcoin chain, Alice's validation obligation on the PoS chain ends, and three days later, Alice can withdraw and retrieve the Bitcoin. The PoS chain will also reward Alice.
The other is the "unhappy path" (as shown in (b)), where Alice turns malicious and participates in a double spend attack on the PoS chain. In this case, the staking protocol ensures that Alice's private key will be exposed to the public. Therefore, anyone can send a slashing transaction to the Bitcoin chain and destroy Alice's Bitcoin. The existence of this unhappy path ensures that the attacker will be slashed, and this deterrence ensures that everyone follows the "happy path"—everyone operates normally.
For the malicious slashing, Babylon utilizes Extractable One-Time Signatures (EOTS) to achieve this. The core idea is that users can sign a message once, similar to a regular signature scheme. EOTS requires an additional tag parameter (the block height is the additional parameter for signing when verifying blocks). If a user attempts to sign the same message with the same tag twice (signing two blocks at the same height), their private key can be extracted from these two signatures.
Comparison
First, there are significant differences in the structure of the Babylon protocol and EigenLayer:
Babylon:
EigenLayer:
Babylon consists of the Bitcoin timestamp protocol and staking protocol. Due to Bitcoin's non-Turing completeness, many processing tasks need to be completed on a separate chain, so the Babylon protocol has its own chain built using the Cosmos SDK, along with its own chain validators. It also includes independent components such as the EOTS Manager and Finality Provider.
EigenLayer, on the other hand, is essentially composed of a set of smart contracts that can accept user staking and manage AVS contracts. It is executed on the Ethereum network and ensures security.
Secondly, the implementation of slashing is different for both:
Since Ethereum supports smart contract functionality, EigenLayer's slashing logic implementation will be written in the contract and can address complex slashing conditions for different AVS. Additionally, if a situation arises that cannot be resolved by predefined slashing conditions, there will be an off-chain veto committee to vote on the resolution.
Due to the limitations of the Bitcoin mainnet, Babylon implements slashing logic through EOTS. Its limitations are more restrictive, and it can only implement relatively simple slashing logic for the case of signing the same block at the same height twice.
Due to the different implementation of slashing, the target audience for both also differs:
EigenLayer can implement complex slashing logic, thus providing secure services for a wide range of AVS. For EigenLayer, its advantage lies in its consistency with Ethereum. Ethereum has the largest ecosystem in the cryptocurrency field, which means more users and greater demand. EigenLayer's solution has the potential to address the limitations of Ethereum, such as the need for secure and decentralized bridging, data availability solutions, and decentralized sequence layers for Layer 2 solutions. Within the Ethereum ecosystem, using ETH as a staking asset is considered the "politically correct" approach. Therefore, applications built around EigenLayer will mostly serve the Ethereum ecosystem.
Babylon, on the other hand, primarily serves PoS chains, especially within the Cosmos ecosystem, as the Bitcoin timestamp service requires message passing between the Babylon chain and Cosmos chain through the IBC protocol, which limits its scope. Each of these PoS chains requires a separate set of validators. Its advantage may lie in the fact that the Cosmos ecosystem has already developed to a large scale and has produced many excellent PoS chains, such as Celestia, Osmosis, Axelar, dYdX, and more. These protocols can easily integrate with the Babylon chain to obtain Bitcoin security. EigenLayer's development, on the other hand, would require a large number of projects to redevelop and adapt to AVS, putting it at a disadvantage in the initial stages. Additionally, the solution of building application chains using the Cosmos SDK has been extensively validated, making it more developer-friendly for project development. In this respect, Babylon also has a certain advantage, as it chooses to bring the Cosmos ecosystem into Bitcoin security.
This is also related to the development direction of the Ethereum and Cosmos ecosystems. The Ethereum ecosystem first built a large secure core, namely the Ethereum mainnet, and then formed many Layer 2 solutions, but the interconnectivity between Layer 2 solutions has not been resolved. The Cosmos ecosystem first solved the interconnectivity between different zones but lacks a strong secure core. The market value of the Cosmos Hub is too low to bear this responsibility, so it naturally needs to find a secure core, which is the need that Babylon aims to address by bringing Bitcoin security into it. At the same time, EigenLayer also hopes to bring Ethereum security into the Cosmos ecosystem. From the perspective of the underlying architecture, Babylon's solution may be more compatible with the Cosmos ecosystem.
Conclusion
The Babylon protocol and EigenLayer both aim to unlock the security of the Bitcoin and Ethereum networks for more applications through their respective methods. However, due to the non-Turing completeness of Bitcoin, its ecosystem development lags far behind that of the Ethereum ecosystem. Additionally, the issuance of Bitcoin assets and the development of second-layer networks have taken a different path from Ethereum. This has led to differences in the technical architecture, slashing methods, and target audience for the Babylon protocol and EigenLayer. Currently, both have their own areas of focus and development advantages, but with the development of modular blockchains and the integration of different ecosystems, in the future, they may form a competitive situation, with no single dominant player.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
