Preface

The Restaking track represented by EigenLayer has garnered immense attention, becoming one of the hottest directions in Ethereum currently. E2M Research has also extensively discussed EigenLayer. EigenLayer extends Ethereum’s security to other applications on the blockchain network while providing additional rewards to participating ETH or LST holders.

Similarly, Babylon allows Bitcoin users to stake BTC to enhance PoS networks’ security, improve network security while earning rewards, and maintain Bitcoin’s self-custody. Since the Bitcoin mainnet cannot support full smart contracts, Babylon’s architecture design and application scenarios differ significantly from EigenLayer. Anurag Arjun, former co-founder of Polygon and founder of Avail, also stated on social media that compared to projects like Eigenlayer, Babylon seems to be more underestimated. It will gain development momentum, which might be a major unlock for the BTC ecosystem.

This article aims 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 suite of Bitcoin security-sharing protocols. Currently, it includes two protocols:

• Bitcoin Timestamp: This protocol sends a succinct and verifiable timestamp of any data (e.g., a PoS blockchain) to Bitcoin.
• Bitcoin Staking: This protocol allows Bitcoin assets to be staked in a trust-minimized (and self-custodial) manner to provide economic security for any decentralized system.

Bitcoin Timestamp Protocol

First, let’s look at the structure of the Bitcoin Timestamp protocol:

Babylon’s architecture is shown in the above diagram. It consists of three parts, with two levels of checkpoints:

• Bitcoin, as the timestamp service layer.
• The Babylon chain (a chain built on the Cosmos SDK), is the intermediate layer.
• The PoS blockchain (e.g., other Cosmos zones) is the security consumer.

An important design consideration is that Bitcoin has a very limited capacity for carrying data. In this case, the Babylon chain serves multiple functions:

• It aggregates checkpoint streams from many PoS consumer chains, so only one checkpoint stream needs to be inserted into the Bitcoin network to timestamp events across all consumer PoS chains.
• Its checkpoints in the Bitcoin network can be made compact using cryptographic techniques (e.g., aggregate signatures).
• It receives checkpoints from consumer PoS chains via the IBC protocol.
• It checks the data availability of checkpoints from PoS consumer chains, so attackers cannot timestamp unavailable data.

This structure helps PoS chains improve their security, for example, against long-range attacks.

To protect a PoS chain from long-range attacks, we can send the PoS chain’s block checkpoints to BTC and choose the fork with an earlier BTC timestamp as the valid fork. This leaves only two possibilities:

• The attacking fork will have a later timestamp in the BTC mainnet, in which case the fork will never be chosen by anyone.
• To be chosen, the attacker must create a very long BTC fork where the attacking PoS fork has an earlier timestamp, which is economically impossible.

Thus, long-range attacks can be mitigated through BTC timestamps.

In addition to addressing long-range attacks, the irreversible BTC timestamp for PoS blocks provides other security advantages for PoS chains:

• Eliminate Weak Subjectivity: Bitcoin timestamps are objective, eliminating the reliance of PoS chains on social consensus and weak subjectivity.
• Shorter Unbonding Times: By replacing social consensus, BTC timestamps can shorten the unbonding times of PoS chains from weeks to a day.
• New Chain Bootstrapping: Low-valued new PoS chains are more vulnerable to fork attacks. BTC timestamps can help protect the chain’s growth.
• State Sync and Snapshot Verification: The objective facts about a PoS chain provided by BTC allow PoS chain users to verify the chain state or snapshots downloaded from the P2P network.
• Securing Important Transactions: BTC timestamps can be used to further confirm important PoS transactions, at the cost of longer confirmation latency.
• Censorship Resistance: BTC timestamps can also resist transaction censorship on PoS chains by publishing censored transactions to BTC.

Bitcoin Staking Protocol

Babylon’s Bitcoin staking protocol allows Bitcoin holders to stake their Bitcoin without having to trust any third party; this staking does not require bridging Bitcoin across chains to a PoS chain to provide full slashable staking guarantees for that PoS chain.

Here is an example of Bitcoin staking:

Alice has one Bitcoin, and she wants to stake it on a PoS chain. First, she enters a staking covenant by sending a staking transaction to the Bitcoin chain. This transaction is a Bitcoin transaction that locks her Bitcoin into a self-custodial vault. The locked Bitcoin can only be unlocked by Alice’s private key through one of the following two paths:

(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 this staking transaction enters the Bitcoin chain, Alice can start signing blocks with her key to validate the PoS chain.

During her verification duty, there are two possible paths.

Source: https://docs.babylonchain.io/papers/btc_staking_litepaper(CN).pdf

The “happy path” (figure (a)) is where Alice honestly follows the protocol, and when she wants to unstake her Bitcoin, she initiates an unbonding request by sending an unbonding transaction to the Bitcoin chain (figure (b)). Once the unbonding transaction enters the Bitcoin chain, Alice’s validation duty on the PoS chain ends, and after three days, Alice can withdraw and retrieve her Bitcoin. The PoS chain will also award Alice with rewards.

The “unhappy path” (figure (b)) is where Alice turns malicious and participates in a double-spend attack on the PoS chain. In this case, the staking covenant ensures that Alice’s private key will be leaked. Then, anyone can send a slashing transaction to the Bitcoin chain as Alice and burn her Bitcoin. The existence of this unhappy path ensures that an attacker will be slashed, which deters everyone from misbehaving - everyone behaves normally on the “happy path”.

For the slashing of misbehaviour, Babylon utilizes extractable one-time signatures (EOTS). The core idea is that a user can sign a message once, similar to a normal signature scheme. EOTS requires an extra label parameter (the block height is the extra parameter when signing a block during validation). If the user attempts to sign the same message twice with the same label (signing two blocks at the same height), the user’s private key can be extracted from these two signatures.

Comparison

First, there is a significant structural difference between the Babylon protocol and EigenLayer:

Babylon:

Babylon protocol structure diagram

EigenLayer:

EigenLayer structure diagram

Babylon consists of the Bitcoin Timestamp protocol and the Staking protocol, and since Bitcoin is not Turing-complete, much of the processing work needs to be done by a separate chain, which is why the Babylon protocol has its chain built on the Cosmos SDK, with its own set of validation nodes accordingly. It also includes independent components like the EOTS Manager and Finality Provider.

In contrast, EigenLayer is essentially a set of smart contracts that can accept user stakes and manage AVS contracts, with the underlying Ethereum network executing and ensuring security.

Second, the two protocols differ in their slashing implementation.

Since Ethereum supports smart contract functionality, EigenLayer’s slashing logic is implemented in the contracts, allowing for more complex slashing conditions tailored to different AVSs. Meanwhile, if a situation arises that cannot be resolved by the predefined slashing conditions, there will be an off-chain veto committee to resolve it through voting.

Constrained by the functionality of the Bitcoin mainnet, Babylon implements slashing logic through EOTS. It has more limitations and can only implement a relatively simple slashing logic for the case of signing the same block height repeatedly.

Due to the different slashing implementations, the two protocols also differ in their target services.

EigenLayer’s ability to implement complex slashing logic allows it to provide security services for a wide range of AVSs. For EigenLayer, its advantage lies in its consistency with Ethereum. Ethereum has the largest ecosystem in the cryptocurrency space, meaning more users and greater demand. EigenLayer’s solution has the potential to address Ethereum’s limitations, such as the need for secure and decentralized bridges, data availability solutions, and decentralized sequencer layers for Layer 2 solutions. Within the Ethereum ecosystem, using ETH as the staking asset is considered the “politically correct” approach. So the applications built around EigenLayer will primarily serve the Ethereum ecosystem.

On the other hand, Babylon mainly serves PoS chains, especially those in the Cosmos ecosystem, because the Bitcoin timestamp service needs to pass messages between the Babylon chain and Cosmos chains via the IBC protocol, which limits its applicability. These PoS chains all require their own separate sets of validation nodes. Its advantage may be that the Cosmos ecosystem has already grown to a considerable scale and has produced many excellent PoS chains, such as Celestia, Osmosis, Axelar, dYdX, and more, which can all easily integrate with the Babylon chain and benefit from Bitcoin’s security. In contrast, EigenLayer’s development would require a significant number of projects to re-develop and adapt to AVSs, putting it at an initial disadvantage. Additionally, the approach of building application chains using the Cosmos SDK has been extensively validated and may be more developer-friendly, giving Babylon an advantage in terms of bringing the Cosmos ecosystem under Bitcoin’s security umbrella.

This is also related to the development directions of the Ethereum and Cosmos ecosystems. The Ethereum ecosystem first built a massive security core, the Ethereum mainnet, and then formed many Layer 2 solutions on top of it, but the interoperability between Layer 2s has yet to be solved. In contrast, the Cosmos ecosystem first addressed the interoperability between different zones but lacks a powerful security core, as the Cosmos Hub’s market cap is too low to bear this responsibility. Therefore, there is a natural need to find a security core, which is where Babylon comes in, aiming to bring Bitcoin’s security into the ecosystem. At the same time, EigenLayer also hopes to bring Ethereum’s security into the Cosmos ecosystem through collaboration. From an architectural perspective, Babylon’s approach may be better suited to the Cosmos ecosystem.

Summary

Both the Babylon protocol and EigenLayer aim to unlock the security of the Bitcoin and Ethereum networks respectively for more applications. However, due to Bitcoin’s non-Turing-complete nature, its ecosystem development lags far behind Ethereum’s ecosystem. Additionally, Bitcoin’s asset issuance and Layer 2 networks have taken a different path from Ethereum’s. This has led to differences between the Babylon protocol and EigenLayer in terms of technical architecture, slashing mechanisms, and target services. Currently, both protocols have their areas of focus, each with its advantages. However, as modular blockchains and interconnectivity between different ecosystems develop, the two protocols may eventually compete with each other, without a single dominant player.

Reference Articles

https://twitter.com/E2mResearch/status/1783714279394586787 https://mirror.xyz/0x80894DE3D9110De7fd55885C83DeB3622503D13B/H6Atmt82NYjR5OgKN664IaTZJuR5hyfaRavvEHXoVvg https://pmcrypto.xyz/blog/wtf-is-eigenlayer-and-babylon-cn https://docs.eigenlayer.xyz/eigenlayer https://docs.babylonchain.io/docs/introduction/overview https://www.chaincatcher.com/article/2079486

Disclaimer:

1. This article is republished from [E2M Research] , with the copyright belonging to the original author [ShawnYang]. If there are any objections to the republication, please contact the Gate Learn Team, and they will handle it according to the relevant procedures.

2. Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.

3. Translated versions of this article by the Gate Learn team cannot be copied, disseminated, or plagiarized without mentioning Gate.io.