بابل: كيف يمكن فتح القيمة الأمنية للبيتكوين؟

المؤلف الأصلي: الباحث زيكي من شركة YBB Capital

مقدمة

In the modular era led by Ethereum, providing security services by connecting the DA (data availability) layer is nothing new. The concept of shared security brought by Staking provides a new dimension for the modular track, that is, using the potential of digital gold and silver to provide security from Bitcoin or Ethereum for many blockchain protocols and public chains. From a narrative point of view, it is quite grand. It not only releases liquidity of trillions of market value, but also is the key core of the future expansion path. Take the recent Bitcoin staking protocol Babylon and Ethereum re-staking (ReStaking) protocol EigenLayer, which have won huge financing of US$70 million and US$100 million respectively. It is not difficult to see that the top VCs are very recognized for this track.

However, there are also many doubts. If modularization is the final outcome of expansion, and the two as key players will inevitably lock up a huge amount of BTC and ETH, then is the security of the protocol itself worth considering? Will the crazy nesting dolls formed with many LSD and LRT protocols become the biggest black swan in the future blockchain? Is its business logic reasonable? Since we have analyzed EigenLayer in previous articles, the following will mainly discuss the above issues through Babylon.

Extending security consensus

The most valuable public chains in the blockchain world must be Bitcoin and Ethereum. Their security, decentralization, and value consensus accumulated over the years are the key cores that ensure that the two can stand on the top of the public chain for many years. They are also the scarce characteristics that are most difficult to replicate for other heterogeneous chains, and the core of modular thinking is to rent these characteristics to those in need. At this stage, there are mainly two factions in modular thinking:

• The first is to use Layer 1 (usually Ethereum) with sufficient security as the lower three layers or part of the functional layer 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.), the throughput and cost are not particularly friendly;

• The second is to create a DA layer with security close to that of Bitcoin and Ethereum and better cost performance. For example, Celestia, which we are familiar with, uses a pure DA functional architecture, minimizes node hardware requirements, and has low gas costs, in order to create a DA layer with strong performance and security and decentralization comparable to Ethereum in the shortest possible time. The disadvantage of this solution is that it will take some time to complete the security and decentralization, and it lacks orthodoxy and is in open competition with Ethereum, so it is rejected by the Ethereum community.

The other faction is Babylon and Eigenlayer, which use the core idea of POS (Proof-of-Stake) to create shared security services by borrowing the asset value of Bitcoin or Ethereum. Compared with the first two, it is a neutral existence. Its advantage is that while inheriting orthodoxy and security, it also gives the main chain assets more utilization value and is more flexible.

The potential of digital gold

Regardless of the underlying logic of the consensus mechanism, the security of the blockchain depends largely on how many resources it has to support it. The PoW chain requires a lot of hardware and electricity, while PoS relies on the value of the pledged assets. Bitcoin itself is supported by an extremely large PoW computing network, which can be said to be the most secure in the entire blockchain. However, as a public chain with a circulating market value of 1.39 trillion US dollars and occupying half of the blockchain, its assets are only used in two main scenarios: transfer and payment of Gas.

As for the other half of the blockchain, especially since Ethereum Shanghai upgraded to PoS, it can be said that most public chains use PoS with different architectures to complete consensus by default. However, since the new heterogeneous chain itself cannot attract too much capital pledge, its security is very questionable. In the current modular era, although Cosmos zone and various Layer 2 can also use various DA layers to make up for it, it also loses autonomy. For most old public chains or alliance chains with POS mechanisms, it is basically impossible to use Ethereum or Celestia as DA, and the value of Babylon is to fill this gap and pledge BTC to provide protection for the PoS chain. Just as humans used gold to support the value of paper money in the past, BTC is indeed very suitable to play this role in the blockchain world.

From 0 to 1

Releasing digital gold has always been the most ambitious and difficult narrative in the blockchain. From the early sidechains, lightning networks, bridged wrapped tokens to todays runes and BTC Layer 2, it can be said that no matter which solution, there are certain inherent flaws. If Babylon wants to implement the security of Bitcoin, the centralized solution that introduces the third-party trust assumption must be excluded first. Among the remaining solutions, runes and lightning networks (limited by extremely slow development progress) currently only have the ability to issue assets, which means that Babylon needs to design a capacity expansion plan to increase Bitcoin native staking from 0 to 1.

The basic elements currently available in Bitcoin are as follows: 1. UTXO model, 2. Timestamp, 3. Multiple signature methods, 4. Basic operation codes. Babylons solution is based on Bitcoins weak programmability and data carrying capacity. Adhering to the principle of minimization, only the necessary functions of the pledge contract need to be completed on Bitcoin, that is, BTC pledge, confiscation, reward, retrieval, etc. are all completed in the main chain. After achieving this 0 to 1, the complex requirements are handed over to the Cosmos zone for processing. But there is still a key problem here, how to record the data of the PoS chain to the main chain?

Remote Staking

UTXO (Unspent Transaction Outputs) is a transaction model designed by Satoshi Nakamoto for Bitcoin. Its core idea is extremely simple. Transactions are nothing more than the inflow and outflow of funds, so the entire transaction system only needs to be expressed in the form of input and output. The so-called UTXO is when funds come in but not so much is spent, and the remaining part is the unspent transaction output (that is, the bitcoin that has not been paid out). The entire Bitcoin ledger is actually a collection of UTXOs. By recording the status of each UTXO, the ownership and circulation of Bitcoin are managed. Each transaction will consume the old UTXO and generate a new UTXO. Because its properties have certain potential for scalability, it naturally becomes the starting point for many native expansion solutions. For example, the lightning network that uses UTXO and multi-signatures to create a penalty mechanism and a state channel, or the inscriptions and runes that bind UTXO to realize SFT (semi-fungible tokens). All of them are based on this key starting point to become a reality.

Naturally, Babylon also needs to use UTXO to implement the pledge contract (Babylon calls it remote pledge, that is, the security of BTC is remotely transmitted to the PoS chain through the middle layer). At the same time, it cleverly combines the existing operation codes in terms of thinking. The specific steps to implement the contract can be broken down into the following four steps:

• Locking funds The user sends funds to an address controlled by a multi-signature. Through OP_CTV (OP_CHECKTEMPLATEVERIFY, which allows the creation of predefined transaction templates to ensure that transactions can only be executed according to specific structures and conditions), the contract can specify that these funds can only be spent when specific conditions are met. After the funds are locked, a new UTXO is generated to indicate that these funds have been pledged;

• Conditional verification calls OP_CSV (OP_CHECKSEQUENCEVERIFY, which allows a relative time lock to be set, based on the transaction sequence number, indicating that UTXO can only be spent after a certain relative time or number of blocks) to achieve time lock, which can ensure that funds cannot be withdrawn within a certain period of time. Combined with the OP_CTV mentioned above, staking, unstaking (if the staking time is met, the pledger can spend the locked UTXO), and slashing (if the pledger behaves maliciously, the UTXO will be forced to be spent to the locked address and restricted to an unspendable state, similar to a black hole address) can be achieved;

• 

• Status Update Whenever a user stakes or withdraws staked funds, it involves the creation and spending of UTXO. New transaction outputs will generate new UTXOs, and old UTXOs will be marked as spent. In this way, every transaction and fund flow is accurately recorded on the blockchain to ensure transparency and security;

• Based on the staked amount and staked time, the contract will calculate the rewards and distribute them by generating new UTXOs. These rewards can be unlocked and spent after meeting certain conditions through script conditions.

Timestamp

With the native staking contract, it is natural to think about the issue of recording historical events on external chains. In Satoshi Nakamotos white paper, the Bitcoin blockchain introduced a concept of timestamping supported by PoW, a mechanism that provides an irreversible chronological order for events. In Bitcoins native use case, these events refer to various transactions performed on the ledger. Today, in order to enhance the security of other PoS chains, Bitcoin can also be used to timestamp events on external blockchains. Every time such an event occurs, it triggers a transaction sent to miners, who then insert it into the Bitcoin ledger to timestamp the event. These timestamps can be used to solve various security issues of blockchains. The general concept of timestamping events in a child chain on a parent chain is called checkpointing, and the transactions used to add timestamps are called checkpoint transactions. Specifically, timestamps in the Bitcoin blockchain have the following important characteristics:

• Time format: The timestamp records the number of seconds since January 1, 1970 00:00:00 UTC. This format is called Unix timestamp or POSIX time;

• Function: The main function of the timestamp is to identify the generation time of the block, help nodes determine the order of blocks, and assist the network difficulty adjustment mechanism;

• Timestamps and difficulty adjustment: The Bitcoin network adjusts the difficulty every 2016 blocks (approximately every two weeks). Timestamps play a key role in this process, because the network adjusts the mining difficulty based on the total generation time of the last 2016 blocks, making the generation speed of new blocks close to 10 minutes;

• Validity check: When a node receives a new block, it verifies the timestamp. The timestamp of a new block must be greater than the median time of several previous blocks and cannot exceed 120 minutes of network time (i.e. 2 hours in the future).

The timestamp server is a new primitive defined by Babylon that can distribute Bitcoin timestamps through PoS blocks through Babylon checkpoints to ensure the accuracy of time series and prevent tampering. The server is the top layer of the entire Babylon architecture and is the core source of trust requirements.

Babylons three-tier architecture

As shown in the figure above, Babylons overall architecture can be divided into three layers: Bitcoin (as a timestamp server), Babylon (a Cosmos Zone) as the middle layer, and the PoS chain demand layer. Babylon calls the latter two the Control Plane (Babylon itself) and the Data Plane (data demand plane, i.e. various PoS consumer chains).

After understanding the basic implementation of protocol trustlessness, lets look at how Babylon itself uses the Cosmos zone to connect the two ends. According to Stanford Tse Labs detailed explanation of Babylon [1], Babylon can receive checkpoint streams from multiple PoS chains and merge these checkpoints and publish them to Bitcoin. By using the aggregate signature of Babylon validators, the size of checkpoints can be minimized, and the frequency of these checkpoints is controlled by allowing Babylon validators to change only once per Epoch.

Validators of each PoS chain download the Babylon block and observe whether their PoS checkpoints are included in the Babylon block checked by Bitcoin. This enables the PoS chain to detect discrepancies, for example, if a Babylon validator creates an unavailable block checked by Bitcoin and lies about the PoS checkpoints included in the unavailable block. The main components that make up the protocol are as follows:

• Checkpoints: Only the last block of the Babylon Epoch is checkpointed by Bitcoin. A checkpoint consists of the hash of the block along with a single aggregate BLS signature corresponding to the signatures of the 2/3 validator set that signed the block for finalization. Babylon checkpoints also contain the Epoch number. PoS blocks can be assigned the timestamp of a Bitcoin block via a Babylon checkpoint. For example, the first two PoS blocks were checkpointed by a Babylon block, which in turn was checkpointed by a Bitcoin block with a timestamp of t_ 3. Therefore, these PoS blocks were assigned a Bitcoin timestamp of t_ 3.

• 

• Canonical PoS chain: When a fork occurs on the PoS chain, the chain with the earlier timestamp is considered the canonical PoS chain. If two forks have the same timestamp, the tie is broken in favor of the PoS block with the earlier checkpoint on Babylon.

• 

• Withdrawal rules: To withdraw, a validator sends a withdrawal request to the PoS chain. The PoS block containing the withdrawal request is checked by Babylon and then by Bitcoin, and is assigned a timestamp t_ 1 . Once the Bitcoin block with timestamp t_ 1 reaches depth k, the withdrawal is granted on the PoS chain. At this point, if a validator who has withdrawn stake conducts a long-range attack, blocks on the attack chain can only be assigned a Bitcoin timestamp later than t_ 1 . This is because once a Bitcoin block with timestamp t_ 1 reaches depth k, it cannot be rolled back. Then, observing the order of these checkpoints on Bitcoin, the PoS client can distinguish between the canonical chain and the attack chain, and then ignore the attack chain.

• 

• Slashing rules: Validators with double-signed conflicting PoS blocks can be slashed if they do not withdraw their stake when the attack is detected. Malicious PoS validators know that if they wait until withdrawal requests are approved before performing a long-range security attack, they will not be able to confuse clients, which can look at Bitcoin to identify the canonical chain. Therefore, they may fork the PoS chain when assigning Bitcoin timestamps to blocks on the canonical PoS chain. These PoS validators work with malicious Babylon validators and Bitcoin miners to fork Babylon and Bitcoin and replace the Bitcoin block with timestamp t_2 with another block with timestamp t_3. This changes the canonical PoS chain from the top chain to the bottom chain in the eyes of later PoS clients. While this is a successful security attack, it results in the malicious PoS validators stake being slashed because they have double-signed conflicting blocks but have not yet withdrawn their staked stake.

• 

• Stopping rule for unavailable PoS checkpoints: PoS validators must pause their PoS chain when they observe an unavailable PoS checkpoint on Babylon. Here, an unavailable PoS checkpoint is a hash signed by 2/3 of the PoS validators that is assumed to correspond to an unobservable PoS block. If the PoS validator does not stop the PoS chain when they observe an unavailable checkpoint, then an attacker can reveal the previously unavailable attack chain and change the canonical chain in the view of later clients. This is because the checkpoints of the shadow chain revealed later appear earlier in Babylon. The above halting rule reveals why we require that the PoS block hashes sent as checkpoints be signed by the PoS validator set. If these checkpoints are not signed, then any attacker can send an arbitrary hash and claim that it is the hash of an unavailable PoS block checkpoint on Babylon. The PoS validator will then have to pause the checkpoint. Note that creating an unavailable PoS chain is difficult: it requires corrupting at least 2/3 of the PoS validators so that they complete the PoS block with a signature but do not provide data to honest validators. However, in the attack hypothesized above, the malicious adversary stopped the PoS chain without attacking any of the validators. To prevent such attacks, we require that PoS checkpoints are verified by 2/3 of the PoS validators. Therefore, Babylon will only have unavailable PoS checkpoints if 2/3 of the PoS validators are indeed controlled by the attacker. Due to the cost of corrupting PoS validators, this attack is extremely unlikely and will not affect other PoS chains or Babylon itself.

• Halting rule for unavailable Babylon checkpoints: PoS and Babylon validators must halt the blockchain upon observing an unavailable Babylon checkpoint on Bitcoin. Here, an unavailable Babylon checkpoint is a hash with the aggregate BLS signatures of 2/3 of the Babylon validators, which supposedly corresponds to a Babylon block that cannot be observed. If the Babylon validators do not halt the Babylon blockchain, then an attacker can reveal a previously unavailable Babylon chain, thereby changing the canonical Babylon chain in the view of late clients. Similarly, if the PoS validators do not halt the PoS chain, then an attacker can reveal a previously unavailable PoS attack chain as well as a previously unavailable Babylon chain, thereby changing the canonical PoS chain in the view of late clients. This is because the later revealed dark Babylon chain has an earlier timestamp on Bitcoin and contains the checkpoints of the later revealed PoS attack chain. Just like the halting rule for unavailable PoS checkpoints, the above rule reveals why we require that Babylon block hashes sent as checkpoints must be accompanied by an aggregate BLS signature proving the signatures of 2/3 of the Babylon validators. If Babylon checkpoints were unsigned, then an arbitrary adversary could send an arbitrary hash and claim it to be the hash of an unavailable Babylon block checkpoint on Bitcoin. PoS validators and Babylon validators would then have to wait for a checkpoint that did not have any unavailable Babylon or PoS chains in its preimage! Creating an unavailable Babylon chain requires compromising at least 2/3 of the Babylon validators. However, in the hypothetical attack above, the attacker halted all chains in the system without compromising even a single Babylon or PoS validator. To prevent such attacks, we require that Babylon checkpoints be attested by aggregate signatures; so there can only be unavailable Babylon checkpoints if 2/3 of the validators are actually compromised. This data availability attack is extremely unlikely due to the cost of compromising Babylon validators. But in extreme cases, it would affect all PoS chains by forcing them to halt.

Eigenlayer in BTC

Although Babylon is the same as Eigenlayer in terms of purpose, it is by no means a simple fork of Eigenlayer. In the current situation where the BTC main chain DA cannot be used natively, the existence of Babylon is very meaningful. In addition to bringing security to the external PoS chain, the protocol is also particularly important for the activation of the BTC ecosystem.

Example

There are many possible use cases in Babylon. Here are some that have been implemented or have the potential to be implemented in the future:

1. Shorten the staking cycle and enhance security: PoS chains usually require social consensus (consensus among the community, node operators, and validators) to prevent long-range attacks, which are attacks that tamper with transaction records or control the chain by rewriting the history of the blockchain. This attack is particularly serious in the PoS system because, unlike PoW, the validators participating in the consensus in the PoS system do not need to consume a lot of computing resources, and attackers can rewrite history by controlling the early staker keys. Therefore, in order to ensure the stability and security of the consensus of the blockchain network, a long staking cycle is basically necessary. For example, the unstaking cycle of Cosmos takes 21 days. However, through Babylon, the historical events of the PoS chain can be added to the BTC timestamp server, thereby using BTC as a source of trust to replace the social consensus, so that the unstaking time can be shortened to only 1 day (that is, after BTC runs about 100 blocks). And the PoS chain can have the dual protection of native Token staking and BTC staking at this time;

2. Cross-chain interoperability: Through the IBC protocol, Babylon is able to receive checkpoint data from multiple PoS chains and achieve cross-chain interoperability. This interoperability allows seamless communication and data sharing between different blockchains, improving the overall efficiency and functionality of the blockchain ecosystem;

3. Integrate BTC ecosystem: Most of the projects in the current BTC ecosystem do not have strong enough security. Whether it is Layer 2, LRT or DeFi, most of them still rely on third-party trust assumptions. And there are a lot of BTC stored in the addresses of these protocols. In the future, they may collide with Babylon to come up with some good matching solutions, feed back to each other, and finally form a strong ecosystem like 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 assets when they are transferred between different blockchains. Such a mechanism helps prevent double spending and other cross-chain attacks.

Tower of Babel

The story of the Tower of Babel comes from Genesis 11:1-9 in the Bible. It is a classic story about humans trying to build a tower to the sky, but being stopped by God. Its meaning symbolizes the unity of mankind and common goals. It is also the underlying meaning of the Babylon protocol, which aims to build a Tower of Babel for many PoS chains and unite them together. From a narrative point of view, it seems to be no less impressive than Eigenlayer, the defender of Ethereum, but what is the actual situation?

As of now, the Babylon testnet has provided security for 50 Cosmos zones through the IBC protocol. In addition to Cosmos, Babylon has also reached cooperation with some LSD (liquidity pledge) protocols, full-chain interoperability protocols, and Bitcoin ecological protocols for integration. On the other hand, in terms of pledge, compared with Eigenlayers ability to reuse pledges and LSD within the Ethereum ecosystem, Babylon is currently still slightly inferior. But in the long run, BTC sleeping in many wallets and protocols has not been fully awakened, so this is just the tip of the $1.3 trillion iceberg. The current Babylon still needs to form a positive complement to the entire BTC ecosystem.

The only solution to the Ponzi dolls

As mentioned in the preface, Eigenlayer and Babylon are gradually gaining momentum. Judging from the current trend, the two will lock up a huge amount of blockchain core assets in the future. Even if the security of the two protocols themselves is not a problem, will multiple nesting dolls cause the entire staking ecosystem to enter a death spiral and cause a decline that is no less than the level of the United States interest rate hike? The current staking track has indeed experienced a long period of irrational prosperity after Ethereum switched to PoS and Eigenlayer came out. In order to obtain higher TVL, project parties often throw out a large number of airdrop expectations and nesting doll superimposed benefits to lure users. One ETH can even nest dolls 5 or 6 times from native staking to LSD and then to LRT. This will naturally cause a lot of risk problems with the stacking of nesting dolls. As long as one of the protocols has problems, it will directly affect all the protocols participating in the nesting dolls (especially the staking protocols at the end of the nesting doll structure). There are a large number of centralized solutions in the BTC ecosystem. If you copy the gourd and copy the set, the risk will only be greater. But one thing that needs to be made clear is that Eigenlayer and Babylon are guiding the pledge flywheel towards real practical value. In essence, they are creating real supply and demand to offset this risk. Therefore, although the existence of the shared security protocol has indirectly or directly contributed to the aggravation of bad practices, it is the only solution for pledge dolls to escape Ponzi profits. The more important question now is whether the business logic of the shared security protocol is true?

Real supply and demand is the key

In Web3, whether it is a public chain or a protocol, its underlying logic is often based on matching buyers and sellers with certain needs. Those who match properly can win the world, and the blockchain itself only makes this match fair, real and credible. In theory, the shared security protocol can form a good complement to the current prosperous pledge and modular ecology. But think carefully, will this supply far exceed the demand? First of all, there are quite a lot of projects and main chains that can provide modular security on the supply side. On the other hand, the old PoS chain may not need or will not rent such security for face. And whether the new PoS chain can pay the interest generated by the huge amount of BTC and ETH, the business logic of Eigenlayer and Babylon must form a closed loop, at least the income must be balanced with the interest generated by the pledged tokens in the protocol. Even if this balance can be achieved, even if the income far exceeds the interest expenditure, in this case there will be blood sucking from the new PoS and protocol. Therefore, how to balance the economic model, not fall into the bubble of airdrop expectations, and drive both supply and demand in a healthier way will be the top priority.

مراجع

1. 10,000 words explaining how Babylon allows the Cosmos ecosystem to benefit from Bitcoin鈥檚 security: https://www.chaincatcher.com/article/2079486

2. In-depth understanding of Eigenlayer: Let Ethereum break the Matryoshka situation? : https://haotiancryptoinsight.substack.com/p/eigenlayer?utm_source=publication-search

3. Dialogue with Fisher Yu, co-founder of Babylon: How to unlock the liquidity of 21 million BTC through staking? : https://www.chaincatcher.com/article/2120653

4. Triangular debt or mild inflation: an alternative perspective on re-pledge: https://mp.weixin.qq.com/s/dMc_WzndAZXRjnEgD2hcew

5.A look at what Ive been seeing in crypto lately: https://theknower.substack.com/p/a-look-at-what-ive-been-seeing-in

This article is sourced from the internet: Babylon: How to unlock the security value of Bitcoin?

Related: Planet Daily | Mainland investors are not yet allowed to participate in the trading of Hong Kong virtual asset spot ETFs

Headlines Caixin: Mainland investors are currently not allowed to participate in the trading of Hong Kong virtual asset spot ETFs The first batch of six virtual asset spot ETFs issued by Bosera International, China Asset Management (Hong Kong) and Harvest Global have been officially approved by the Hong Kong Securities Regulatory Commission, with the goal of listing on April 30, 2024. Although the relevant ETFs were first issued by Hong Kong companies under Chinese public funds, it should be pointed out that mainland Chinese investors are currently not allowed to participate in buying and selling. According to the product list on the Hong Kong Securities and Futures Commission website, these six virtual asset spot ETFs were officially approved on April 23, 2024. The relevant products are: Harvest Bitcoin Spot ETF…