Author: YBB Capital Researcher Zeke
Preface
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 to 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, the two as key players will inevitably lock up a huge amount of BTC and ETH. So 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 type 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 safest existence in the entire blockchain. However, as a public chain with a circulating market value of 1.39 trillion US dollars and accounting for half of the blockchain, its assets are only used in two main scenarios: transfer and gas payment.
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 highly questionable. In the current modular era, although Cosmos zone and various Layer2 can also use various DA layers to make up for it, it also loses autonomy. For most old blockchains 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, bridge-wrapped tokens to today's runes and BTC Layer2, 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 of Bitcoin that can be used are as follows: 1. UTXO model, 2. Timestamp, 3. Multiple signature methods, 4. Basic operation codes. Babylon's solution is based on Bitcoin's 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 the unspent transaction output (that is, the unpaid Bitcoin) when funds come in but not so much is spent. The entire Bitcoin ledger is actually a UTXO collection. By recording the status of each UTXO, the ownership and circulation of Bitcoin are managed. Each transaction will spend the old UTXO and generate a new UTXO. Because its attributes have certain potential 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 state channel, or the inscriptions and runes that bind UTXO to 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 transferred to the PoS chain remotely 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 Users send 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 Calling 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) can 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;
● Revenue Distribution Based on the staked amount and staked time, the contract will calculate the rewards due and distribute them by generating new UTXO. These rewards can be unlocked and spent through script conditions after meeting specific conditions.
Timestamp
With the native staking contract, it is natural to think about the issue of recording historical events on external chains. In Satoshi Nakamoto's white paper, the Bitcoin blockchain introduced a concept of timestamping supported by PoW, a mechanism that provides an irreversible chronological order for events. In Bitcoin's 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:
1. 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;
2. 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;
3. Timestamp 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 one every 10 minutes;
4. Validity check: When a node receives a new block, it will verify 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.
Babylon's three-tier architecture
As shown in the figure above, Babylon's 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, let's look at how Babylon itself uses Cosmos zones to connect the two ends. According to Stanford Tse Lab's 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 various PoS chains download Babylon blocks and observe whether their PoS checkpoints are included in the Babylon blocks 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 a hash of the block along with a single aggregate BLS signature corresponding to the signatures of the 2/3 set of validators that have 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 timestamp t_3. Therefore, these PoS blocks were assigned the Bitcoin timestamp 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, the 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 a depth of k, the withdrawal is granted on the PoS chain. At this point, if a validator who has withdrawn the stake conducts a long-range attack, the 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 a depth of 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.
● Halting rule for unavailable PoS checkpoints: PoS validators must halt 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 a PoS validator does not halt the PoS chain when it observes an unavailable checkpoint, then an attacker can reveal a 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 halting rule above 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. PoS validators will then have to halt 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 the data to honest validators. However, in the hypothetical attack above, the malicious adversary halted the PoS chain without attacking any validator. To prevent such attacks, we require PoS checkpoints to be validated by 2/3 of PoS validators. Therefore, Babylon will only have unavailable PoS checkpoints if 2/3 of PoS validators are indeed controlled by the attacker. Due to the cost of compromising 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 a Babylon checkpoint that is unavailable on Bitcoin. Here, an unavailable Babylon checkpoint is a hash with the aggregate BLS signatures of 2/3 of the Babylon validators that supposedly corresponds to a Babylon block that is unobservable. 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 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 the Babylon block hash sent as a checkpoint 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 corrupting at least 2/3 of the Babylon validators. However, in the hypothetical attack above, the attacker stopped all chains in the system without even corrupting a single Babylon or PoS validator. To prevent such attacks, we require Babylon checkpoints to be attested by aggregate signatures; so there would only be unavailable Babylon checkpoints if 2/3 of the validators were actually corrupted. This data availability attack is extremely unlikely due to the cost of corrupting Babylon validators. But in extreme cases, it would affect all PoS chains by forcing them to stop.
Eigenlayer in BTC
Although Babylon and Eigenlayer have the same purpose, Babylon 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 keys of early stakers. 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. Integration with BTC ecosystem: Most of the projects in the current BTC ecosystem do not have strong enough security. Whether it is Layer2, 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 Chapter 11, verses 1-9 of 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 Eigenlayer's 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. At present, 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, the project party often throws out a large number of airdrop expectations and nesting doll superimposed benefits to lure users. One ETH can even nest doll 5 or 6 times from native staking to LSD and then to LRT. This will naturally cause a lot of risk problems with the nesting doll superposition. As long as one of the protocols has a problem, it will directly affect all the protocols participating in the nesting doll (especially the staking protocol 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 themselves are guiding the staking flywheel to real practical value. In essence, the two 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 staking nesting dolls to escape Ponzi profits. The more important question now is whether the business logic of the "shared security" protocol is really valid?
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 earned must be balanced with the interest generated by the pledged tokens in the protocol. And 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.
references
1. 10,000-word explanation of how Babylon allows the Cosmos ecosystem to benefit from Bitcoin’s 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 I've been seeing in crypto lately：https://theknower.substack.com/p/a-look-at-what-ive-been-seeing-in
