Original author:Cabin VC

Original author:

In the current multi-chain ecosystem, the composability brought by modularization is being demonstrated in more innovative cases.

One narrative to watch is the development of "shared security" and "borrowed security", which are becoming more common. Among all kinds of public chains, the consensus mechanism determines many core factors such as the security, scalability, and degree of decentralization of L1 of the entire network. The strong consensus and security brought by the leading public chain are difficult for other ecosystems to achieve. comparable.

Under the structure of the modular blockchain, such security can be "borrowed" and reorganized, which is another highlight of the continuation of the public chain ecology.

(*Previous shared security schemes often lie in the direction of isomorphic cross-chains. The security mechanism, consensus algorithm, network topology, and block generation verification logic between isomorphic chains are consistent. It is more suitable for the shared verifier scheme, but there are also certain restrictions .)

Borrowing the idea of ​​security, EigenLayer, which was popular some time ago, is a good example:

The re-staking (Re-staking) scheme proposed by Eigenlayer creates an optional middle layer, allowing users to deposit the pledged ETH into the smart contract for a second pledge, so as to provide node services for public chains, oracles, bridges, etc. And get verification rewards.

Such a network can be viewed as a subset of validators of Ethereum who voluntarily opt in to re-staking, sharing security with Ethereum, and greatly reducing the cost of validating services.

Through this method of "borrowing the security of the ETH consensus layer", the security of Ethereum is borrowed downstream of EigenLayer.

From the perspective of modularized blockchains and composability, it is a direction worth observing and discussing around "using the security of other blockchains to enhance its own security".

If Eigenlayer brings the native security of ETH, can this idea be applied to the BTC chain? Bitcoin is the most secure blockchain and the strongest consensus in the world, and this may be a good case for using BTC mining computing power to provide external security".

Babylon Chain uses this idea in order to "borrow the security of BTC" to enhance the security of the existing chain. The essence of the idea is that it aims to serve as a middleware to borrow the security of Bitcoin to other POS chains.

Babylon is developed based on the Cosmos SDK, and its architecture is as follows:

(*Image source: Babylon white paper)

1) BTC chain, as a timestamp service

2) Babylon chain, as the middle layer

3) Other Cosmos ecology, use/consumer of security services

Babylon is mainly composed of two modules:

2) BE (Babylon-enhancement) module.

image description

(*Image source: Babylon white paper)

The BE module is mainly responsible for the following directions:

2.1) The BE module connects to the Babylon chain through the Babylon client, and the full node publishes the commitments of the protocol-related information to the Babylon chain, checks whether the message is available, and provides a time stamp for the message according to the position of the commitments in the Babylon chain, and sends it to the PoS node make this data public.

(Only provide timestamp service, do not execute transactions on the chain, do not participate in tracking, do not store PoS data, only mark and check availability of PoS data. Babylon miners need to check the availability of timestamp data.)

2.2) Connecting the Tendermint network module (Cosmos ecology), PoS nodes (including subsequent nodes) can understand the time and order of each piece of data first published, and the PoS node can combine the timestamp of the data with the consensus logic of the original PoS protocol, To resolve security conflicts, identify violators, forfeit, etc.

2.3) The BE module also assists in the execution of other rules, including PoS chain information monitoring, assisting the consensus engine to verify transactions, communicating with the governance module (approving community funds, paying Babylon transaction fees), etc.

In simple terms, consider the module a black box that inputs "PoS transactions" and outputs a final PoS block containing those transactions.

With this setup, Babylon uses Bitcoin PoW as a timestamp and data availability layer to introduce BTC-based security to the Cosmos ecosystem:

This model also solves the problem of Cosmos' long pledge unlocking period:

As a separate chain aggregated PoS chain, Babylon sends aggregated checkpoints (that is, transaction events that need to be time-stamped) to BTC, and publishes them to BTC on behalf of them, and processes transactions based on the security of BTC.

From another point of view, when the BTC network serves as the timestamp service of the PoS chain, the length of time for validating node pledges will be changed. In this case, the 3 weeks originally required by the Cosmos zone can be greatly shortened to hours .