Author: Zeke, YBB Capital Source: Medium Translation: Shan Oba, Bit Chain Vision

Foreword

In the era of modular blockchain led by Taigo, providing security services by integrating data availability (DA) layers is no longer a fresh concept.At present, the concept of sharing security introduced through pledge provides a new dimension for modular space.It uses the potential of “digital gold and silver” to provide a guarantee from Bitcoin or Ethereum to security for many blockchain agreements and public chains.This story is quite magnificent because it not only releases the liquidity of trillions of dollars worth of assets, but also the key element of future expansion solutions.For example, the recently raised a huge amount of funds of $ 70 million in Babylon Babylon, and Ethereum re -pledged the Eigenlayer raised $ 100 million in funds, which shows that the leading venture capital company has strong support for the field.

However, the development of these situations has also caused serious concerns.If modularization is the final solution of extension and these protocols are a key component of the solution, they are likely to lock a large number of BTC and ETH.This brings the security issue of the agreement itself.Will the complex stratification formed by many LSD (liquid Stake Derivatives) and LRT (Layer 2 Rollup tokens) protocols become the largest black swan in the blockchain in the future?Is their business logic reasonable?Since we have analyzed Eigenlayer in previous articles, the discussion below will be mainly concentrated in Babylon to solve these problems.

Expand the safety consensus

Bitcoin and Ethereum are undoubtedly the most valuable public blockchain today.The security, decentralization, and value consensus they have accumulated for many years are the core reasons they have always standing at the pinnacle of the blockchain world.These are rare quality that other isterior chains are difficult to copy.The core idea of modularity is to “rent” these quality to those in need.In the current modular method, there are two main factions:

The first faction uses a safe enough layer (usually Ethereum) as the bottom three layers of the bottom or part of the functional layer of ROLLUPS.This scheme has the highest safety and legitimacy and can absorb the resources of the main chain ecosystem.However, for specific Rollups (application chain, long tail chain, etc.), throughput and cost may not be particularly friendly.

The second faction aims to create a better existence close to Bitcoin and Ethereum, such as CELESTIA.Celestia achieves this goal by using pure DA function architecture, minimum node hardware requirements, and lower GAS costs.This simplified method is designed to create a DA layer that matches the safety and decentralization of Ethereum, and at the same time provide strong performance in the short period of time.The disadvantage of this method is that its safety and decentralization take a period of time to make full use of it, and lack legitimacy when they are directly competing with Ethereum, leading to the rejection of the Ethereum community.

The third types in this faction include Babylon and features.They use the core concept of the rights and interests (POS) to create shared security services by using the asset value of Bitcoin or Ethereum.Compared with the first two, this is a more neutral existence.Its advantage is that it inherits legitimacy and security, and also provides more practical value for the assets of the main chain, and provides greater flexibility.

The potential of digital gold

Regardless of the underlying logic of any consensus mechanism, the security of the blockchain depends to a large extent on supporting its resources.The POW chain requires a large amount of hardware and electricity, while POS depends on the value of pledged assets.Bitcoin itself is supported by an extremely large POW network, making it the safest existence in the entire blockchain field.However, as a public chain in circulation of $ 1.39 trillion and occupying half of the blockchain market, its asset utilization is mainly limited to transfer and GAS payment.

For the other half of the blockchain world, especially after Ethereum turns to POS after the upgrade in Shanghai, it can be said that most public chains use different POS architectures to reach consensus by default.However, new heterogeneous chains often cannot attract a large amount of capital pledge, which causes questioning of its security.In the current modularization era, the COSMOS region and various Layer 2 solutions can be compensated using various DA layers, but this is often at the cost of autonomy.For most old POS mechanisms or alliance chains, it is usually impractical to use Ethereum or Celestia as the DA layer.The value of Babylon is to fill this gap by providing protection for the POS chain with BTC pledge.Just as humans use gold to support the value of banknotes, Bitcoin is very suitable for playing this role in the blockchain world.

From 0 to 1

The release of “digital gold” has always been the most ambitious but most difficult goal in the blockchain field.From early side chains, lightning networks, bridges, to the current Runes and BTC Layer 2, each solution has its inherent defects.If Babylon is designed to use the security of Bitcoin, then the centralized solution that introduces the introduction of third -party trust assumptions must be excluded first.Among the remaining options, runes and lightning networks (limited to the slow development progress) currently only have asset issuance capabilities.This means that Babylon needs to design its own “expansion solution” to achieve the native Bit currency pledge from 0 to 1.

The current basic elements available for Bitcoin are essentially the following: 1. UTXO model, 2. Time stamp, 3. Various signature methods, 4. Basic operating code.Given that Bitcoin’s programmability and data carrying capacity are limited, Babylon’s solution is based on the principle of minimalism.On Bitcoin, the basic function of the pledge contract is needed, which means that the pledge, reduction, rewards and retrieval of BTC are handled on the main chain.Once this 0 to 1 is implemented, the COSMOS area can handle more complicated needs.However, a key issue still exists: how to record the POS chain data on the main chain?

Remote pledge

UTXO (UNSPENT Transaction Outputs) is a trading model designed by Satoshi Nakamoto for Bitcoin.The core idea is very simple: trading is only the in -in -law of funds, so the entire trading system can be represented by input and output.UTXO represents the funds part of but not fully spent, so it retains an unprepared transaction output (that is, the unpaid Bitcoin).The entire Bitcoin ledger is essentially the collection of UTXO, which records the status of each UTXO to manage the ownership and circulation of Bitcoin.Each transaction will spend old UTXO and generate new UTXO.Due to its inherent scalability potential, UTXO has naturally become the starting point of many native expansion solutions.For example,

Babylon also needs to use UTXO to implement the Stake contract (Babylon is called remote Stake, that is, the security of Bitcoin is transmitted to the POS chain through the middle layer).The implementation of the contract can be divided into four steps, which cleverly combines the existing operating code:

Lock up funds

The user sends the funds to the address controlled by multiple signatures.Through OP_CTV (OP_CHECKTEMPLATEVERIFY, the creation of a pre -defined trading template is allowed to ensure that the transaction can only be executed according to specific structures and conditions), and the contract can specify that these funds can only be used under certain conditions.Once the funds are locked, a new UTXO will be generated, indicating that these funds have been pledged.

Conditional verification

By calling OP_CSV (OP_CHECKSEQUENCEVERIFY, the relative time lock is allowed to set the relative time lock according to the serial number of the transaction, which means that UTXO can only be spent after a certain relative time or block), and the time lock can be achieved.Combined with OP_CTV, pledge and cancel the pledge (allowing the pledged to lock in UTXO after the pledge period is satisfied) and cut (if the pledgeer’s malicious behavior is forced, the UTXO costs it to the lock address, so that it should not cost it), similar to the black holeaddress).

State update

Whenever the user pledge or withdraws the pledge funds, it involves the creation and spending UTXO.The new transaction output generates a new UTXO, and the old UTXO is marked as it has been spent.In this way, each transaction and capital flow will be accurately recorded on the blockchain to ensure transparency and security.

Reward distribution

The contract is calculated based on the pledge amount and the pledge period and allocated by generating a new UTXO.Once you meet specific conditions, these rewards can be unlocked and spent through script conditions.

Timestamp

After establishing a native STAKE contract, naturally consider recording the problems of historical events from the external chain.In Nakamoto’s white paper, the Bitcoin blockchain introduced the concept of time stamp supported by POW, providing an irreversible order for the event.In the native use cases of Bitcoin, these incidents refer to various transactions performed on the classification account.Today, in order to enhance the security of other POS chains, Bitcoin can also be used to add a timestamp to events on the external blockchain.Every time such incidents occur, transactions sent to miners, and then the miners insert them into the Bitcoin classification, thereby adding a timestamp to the incident.These timestamps can solve various security problems of the blockchain.The general concept of adding timestamps to the event on the sub -chain is called “checkpoint”, and transactions used to add time stamps are called checkpoint transactions.Specifically, the timestamp in the Bitcoin blockchain has the following important features:

Time format: Time stamp records from 00:00:00 UTC on January 1, 1970, this format is called UNIX time or POSIX time.
Uses: The main purpose of the timestamp is to mark the blocking time of the block, help nodes to determine the order of the block, and assist the difficult adjustment mechanism of the network.
Time stamps and difficulty adjustment: The Bitcoin network is difficult to minify the mining difficulty every two weeks or every 2016 block.Time stamp plays a vital role in this process, because the network adjusts the difficulty according to the total generation time of the recent 2016 blocks to ensure that new blocks are generated every 10 minutes.
Effective check: When the node receives a new block, it will verify the timestamp.The timestamp of the new block must be greater than the median time of the previous blocks, and it must not exceed the network time for more than 120 minutes (next 2 hours).

Time stamp server is a new primitive defined by Babylon. It can allocate Bitcoin timestamp through the babylon checkpoint in the POS block to ensure the accuracy and cannot be tampered with the time sequence.The server is the top level of the entire architecture of Babylon and is the core source of trust.

Babylon’s three -layer architecture

As shown in the figure, the overall architecture of Babylon can be divided into three layers: Bitcoin (as a timestamp server), babylon (COSMOS ZONE as the middle layer), and POS chain as the demand layer.Babylon refers to the latter two as control planes (babylon itself) and data plane (various POS consumption chains).

After understanding the basic trust implementation of the agreement, let’s study how the babylon itself uses the COSMOS area to connect the two ends.According to a detailed explanation of the Tse Lab on Babylon University of Stanford, Babylon can receive checkpoint flow from multiple POS chains and merge these checkpoints to Bitcoin.By using the aggregation signature from the Babylon verification device, the size of the checkpoint can be minimized, and the frequency of these checkpoints can be controlled by allowing the Babylon verification device to change only once a period of each period.

Vermitters from various POS chains download Babylon block to check whether its POS checkpoint is included in the Babylon block inspected by Bitcoin.This allows the POS chain to detect differences. For example, whether the Babylon verification device creates a unavailable block verified by Bitcoin and lies on the POS checkpoint contained in it.The main components of the protocol are as follows:

InCheckpoint: Bitcoin only verifies the last block of Babylonian Age.The checkpoint consists of the hash value of the block and the BLS signature of a single aggregation, which corresponds to the signature of two -thirds of the most depends on the block.The Babylonian Inspection Station also includes the Epoch.POS blocks can allocate bitcoin timestamps through the babylon checkpoint.For example, the first two POS blocks are set up by Babylon block setting, and then the Bitcoin block setting checkpoint with a timestamp to T_3.Therefore, these POS blocks are assigned Bitcoin timestamp T_3.

InSpecify POS Chain: When the POS chain is fork, the early chain of the timestamp is considered to be a standard POS chain.If the two forks have the same timestamp, the draw will be broken, which will help POS blocks that are conducive to the earlier checkpoint on Babylon.

InWithdrawal rules: To withdraw, the verification person sends withdrawal requests to the POS chain.Then, the POS block containing the withdrawal request will be checked by the babylon, and then the Bitcoin will be checked and the timestamp T_1 will be allocated for it.Once the timestamp is t_1 Bitcoin block reaches K depth, the POS chain will be approved on the POS chain.If the verification of the withdrawal equity tries to conduct a remote attack, the block on the attack chain can only be assigned the timestamp of later than T_1.This is because the timestamp T_1 Bitcoin block cannot be rolled once it reaches the depth K.By observing the order of these checkpoints on Bitcoin, the POS client can distinguish between standardized chains and attack chains and ignore the latter.

InReducing rules: If the verification person does not withdraw his rights and interests after the attack is detected, they may be cut because of the POS block of the dual signature conflict.Malicious POS verificationrs know that if they wait for the withdrawal request to be approved before launching a long -range attack, they cannot deceive customers who can refer to Bitcoin to identify the standard chain.Therefore, they may split the POS chain, and at the same time assign Bitcoin timestamp to blocks on the standard POS chain.These POS verifications cooperate with the malicious BABYLON verification device and Bitcoin miners to bifinn the BABYLON and Bitcoin, and replace the timestamp to the Bitcoin block of T_2 to another block stamp to T_3 block.From the perspective of the POS client later, this will change the standard POS chain from the top chain to the bottom chain.Although this is a successful security attack.

· POS checkpoint suspension rules are not available: POS verifications must suspend its POS chain when observing the POS checkpoint that is not available on Babylon.Unavailable POS checkpoints are defined as the hash value signed by two -thirds of POS verifications, which are said to be corresponding to POS blocks that cannot be observed.If the POS verification device does not suspend the POS chain when observing the unavailable checkpoint, the attacker can reveal the attack chain that could not be available before, so as to change the specification chain in the future client view.This is because the checkpoint of the shadow chain later revealed at the time of Babylon was earlier.The above -mentioned suspension rules explain why we require the POS block hash values as a checkpoint.If these checkpoints are not signed, any attacker can send any hash values, claiming that it is the hash value of the POS block checkpoint that is not available on Babylon.The POS verification device must be suspended at the checkpoint.Please note that the unavailable POS chain is challenging: it requires a compromise of at least two -thirds of POS authenticants to sign on the POS block without providing data from honest verifications.However, in the assumed attack above, malicious opponents suspended the POS chain without damaging a single verification device.In order to prevent such attacks, we require the POS checkpoint to sign by two -thirds of POS verifications.Therefore, unless two -thirds of the POS verification device is damaged, there will be no unavailable POS checkpoints on the babylon. Due to the cost of damage to the POS verification device, this possibility is very small and will not affect other POS chains or other POS chains orBabylon itself.It requires a compromise of at least two -thirds of POS verifications to sign on the POS block without providing data from honest verifications.However, in the assumed attack above, malicious opponents suspended the POS chain without damaging a single verification device.In order to prevent such attacks, we require the POS checkpoint to sign by two -thirds of POS verifications.Therefore, unless two -thirds of the POS verification device is damaged, there will be no unavailable POS checkpoints on the babylon. Due to the cost of damage to the POS verification device, this possibility is very small and will not affect other POS chains or other POS chains orBabylon itself.It requires a compromise of at least two -thirds of POS verifications to sign on the POS block without providing data from honest verifications.However, in the assumed attack above, malicious opponents suspended the POS chain without damaging a single verification device.In order to prevent such attacks, we require the POS checkpoint to sign by two -thirds of POS verifications.

InThe pause rules of the Babylonian checkpoint are not available: POS and BABYLON verification device must be suspended when observing the Babylon checkpoint that cannot be available on Bitcoin.The Babylon checkpoint that is not available is defined as the hash value of the polymer BLS signature with two -thirds of the BABYLON verification device. The hash is said to be corresponding to the Babylon block that cannot be observed.If the Babylon verifications do not suspend the Babylon blockchain, the attacker can leak the previous Babylon chain that cannot be used before, so as to change the standard Babylon chain in the future client view.Similarly, if the POS verification device does not suspend the POS chain, the attacker can reveal the POS attack chain that could not be available before and the Babylon chain that could not be used before, so as to change the specified POS chain in the future client view.This is because the Babylonian deep chain later disclosed has earlier time stamps on Bitcoin, and contains the checkpoint of the POS attack chain disclosed later.Similar to the rules for pause at the unavailable POS checkpoint, the rule explains why we require the BLS signature with a polymerized BLS of the BABYLON block has a polymer to prove the signature of two -thirds of the BABYLON verifiable.If the Babylonian checkpoint is not signed, any opponent can send any hash values, claiming that it is the hash value of the Babylonian block checkpoint that is unavailable on Bitcoin.Then, the POS verification device and the Babylon verification device must wait for the checkpoint of the Babylon or POS chain that is not available in its original image.Creating an unavailable Babylon chain requires at least two -thirds of the Babylonian verification.However, in the assumed attack above, the opponent suspension of all chains in the system will not affect a single Babylon or POS verification device.In order to prevent such attacks, we ask the Babylonian checkpoint to prove it through aggregation signatures; therefore, unless two -thirds of the verifications are damaged, there will be no unavailable Babylon checkpoints. Due to damage to the cost of the Babylonian verification device, this will be due to the cost of the Babylonian verification device. ThisThe possibility is very small.But in extreme cases, it will force all POS chains to suspend and affect them.

The characteristic layer in BTC

In terms of use, Babylon is similar to Eigenlayer, but it is far from the simple “bifurcation” of Eigenlayer.Given that it is not currently unable to use DA on the BTC main chain, the existence of babylon is very important.The agreement not only brings security to the external POS chain, but also is also vital to internal revitalization of the BTC ecosystem.

Use case

Babylon provides many potential use cases, some of which have been realized or may have the opportunity to achieve in the future:

Shorten the pledge cycle and enhance security: POS Chain Consensus often requires social consensus (consensus between communities, node operators and verifications) to prevent remote attacks.These attacks involve the history of rewriting blockchain to manipulate transaction records or control chains.Remote attacks are particularly serious in the POS system, because unlike POW, the POS system does not need to consume a lot of computing resources.The attacker can rewrite history by controlling the keys of early mortgors.In order to ensure the stability and security of the blockchain network consensus, a longer pledge cycle is generally required.For example, COSMOS needs a 21 -day unbinding period.However, with Babylon, the POS chain historical event can be included in the BTC timestamp server, and BTC is used as a source of trust to replace social consensus.This can be shortened to one day (equivalent to about 100 BTC blocks).In addition, the POS chain can achieve dual security through native currency pledge and BTC pledge.

Cross -chain interoperability: Through the IBC protocol, Babylon can receive checkpoint data from multiple POS chains to achieve cross -chain interoperability.This interoperability allows seamless communication and data sharing between different blockchain, thereby improving the overall efficiency and function of the blockchain ecosystem.
Integrate BTC ecosystem: Most of the projects in the current BTC ecosystem, including Layer 2, LRT, and Defi, lack sufficient security and often depend on third -party trust assumptions.These protocols also store a large number of BTCs in their addresses.In the future, babylon may develop some highly compatible solutions with these projects, create mutual benefit, and eventually form a powerful ecosystem similar to Eigenlayer in Eto.
Cross -chain asset management: Babylon protocol can be used for security management of cross -chain assets.By adding timestamps to cross -chain transactions, the safety and transparency of asset transfer between different blockchains is guaranteed.This mechanism helps to prevent double flowers and other cross -chain attacks.

Babeta

The story of Babetta comes from the Bible Creation 11: 1-9. It is a classic story that humans try to build Tongtian Tower but are obstructed by God.This story symbolizes human unity and common goals.The babylon protocol aims to build a similar tower for various POS chains and unify them under a roof.As far as narrative is concerned, it seems no less than Eigenlayer, the defender of Ethereum.But how does it work in practice?

As of now, the Babylon test network has provided security guarantee for the 50 COSMOS zones through the IBC protocol.In addition to the COSMOS ecosystem, Babylon also integrates some LSD (liquid pledge derivatives) protocol, full -chain interoperability protocol and bitcoin ecosystem protocol.However, in terms of Stake, Babylon is currently lagging behind Eigenlayer. Eigenlayer can reuse STAKE and LSD in the Ethereum ecosystem.But in the long run, a large number of hibernation in wallets and protocols has not been completely awakened. This is only 1.3 trillion US dollars of icebergs.Babylon needs to form a benign symbiosis with the entire BTC ecosystem.

The only solution to Ponzi betting dilemma

As mentioned earlier, both Eigenlayer and Babylon are developing rapidly, and future trends show that they will lock a large number of core blockchain assets.Even if these protocols are safe, will multi -layer pledge cause death spirals for the pledge ecosystem, causing similar to the collapse of the United States to raise interest rates again?Since Ethereum’s transformation to POS and the emergence of Eigenlayer, the current Stake industry has indeed undergone irrational prosperity.Projects often attract high TVL users through huge airdrop expectations and layered returns.One ETH can be stacked by primary pledge, LSD and LRT, up to five to six layers.This stack of stacks increases risks, because problems in any agreement may directly affect all the agreements involved, especially the protocol located at the end of the pledged chain.Bitcoin ecosystem,

However, it is worth noting that EigenLayer and Babylon fundamentally use to guide the pledged flying wheels towards real practicality and create real needs to offset risks.Therefore, although these “shared security” protocols may indirect or directly exacerbate bad behaviors, they are also the only way to avoid the return of pledged Ponzi schemes.The more urgent question is whether the business logic of the “Sharing Security” agreement is really feasible.

Real needs are the key

In Web3, whether it is a public chain or an agreement, the underlying logic often involves matching buyers and sellers for specific needs.To do this, you can “get the world”, because blockchain technology guarantees the fairness, authenticity, and credibility of the matching process.Theoretically, shared security agreements can supplement the booming pledge and modular ecosystem.However, will the supply far exceed the demand?On the supply side, many projects and main chains can provide modular security.From the perspective of demand, the old POS chain may not be able to rent this securities for faces that do not need or unwilling to rent, and the new POS chain may be difficult to pay a large amount of interest generated by BTC and ETH.Let Eigenlayer and Babylon form a commercial closed loop, and the income generated must balance the interest generated by the internal coin in the protocol.Even if this balance and income far exceed interest expenses, it may still cause these new POS chains and protocols to be exhausted.Therefore, how to balance the economic model and avoid bubbles caused by airdrop expectations, health drives supply and demand is very important.