Jumping down the Babylon rabbit hole we stumbled into the realm of security rentals

The concept of Restaking is closely related to the sharing of distributed network security. DAO researcher Jane, Gimmy first started out with curiosity about Babylon/BTC Restaking, and then inadvertently jumped into the rabbit hole of long discussions about underlying consensus mechanisms such as PoW and PoS, and then grasped the core idea of ​​"security leasing", and from We consider the existence significance of AVS from first principles, and finally explore some feasible ways for Web3 project parties to combine Restaking.

Restaking is undoubtedly one of the most important topics in the current Web3 field. After the consensus mechanism of Ethereum has smoothly transitioned from Proof-of-Work (PoW) to Proof-of-Stack (PoS), in addition to solving the problem of long-term inflation of ETH tokens, it has also given it ( In addition to the new) native staking function, it also opens up the possibility of re-staking through Liquidity Staking protocols such as Lido, Rocket Pool, and Frax Finance.

The essence of re-pledge is to use liquid assets such as LST to provide security guarantees to other AVS in order to obtain corresponding income. It can be regarded as a safe leasing service. However, in the context of Bitcoin, the current definition of the term is relatively confusing. What is often referred to as "re-pledge" refers to the use of Bitcoin as the staking asset (BTC as the staking asset). For the sake of simplicity and clarity, this method of using “Bitcoin as a pledged asset” will be collectively referred to as BTC Staking below. On this basis, it is assumed that it is technically possible to take the pledged Bitcoin again. When staking, it is the so-called BTC Restaking (there are no good cases and usage scenarios yet, and we will also demonstrate the rationality of this matter).

The origin of BTC Staking’s establishment

Both PoW and PoS are consensus protocols whose purpose is to maintain synchronization between distributed nodes (Node). The way to maintain synchronization is to select a node and use this node as the standard. The selection method is like a lottery draw, and the weight is represented by a scarce resource. In the case of PoW, the scarce resource is the computing power (hash rate) and the physical energy represented behind it; in the case of PoS, this Scarce resources are capital.

There have been countless debates in history about which of the two is better ( https://www.youtube.com/watch?v=8-_CuPtzoDU &feature=youtu.be ). PoW can guarantee availability (Liveness) under extreme circumstances, but at the expense of only obtaining probabilistic finality (Probabilistic Finality); PoS, on the contrary, can obtain economic certainty (Economic Finality), but cannot obtain availability. Assure. The choice between the two is more about the trade-off between these two characteristics, rather than environmental protection and energy consumption that are easily used as marketing.

Even in the long term, Bitcoin has the hidden danger of unsustainable economic incentives for miners due to the continuous halving of token rewards. Therefore, it may be necessary to iterate to a relatively sustainable model such as PoS at the consensus mechanism level. However, in short-term practical operations, PoW and PoS are not opposing systems. For example, Bitcoin can be used as a pledge asset and the pledge concept of PoS can be introduced into the PoW ecosystem. From the perspective of Bitcoin holders, BTC Staking creates a new usage scenario for it; from the perspective of PoS chain rental security, Bitcoin can be used as a supplementary alternative when pledged assets are (temporarily) insufficient or the cost is high .

Choice of two paths

To implement BTC Staking, there are currently two mainstream methods:

1. Bridging: First bridge Bitcoin to a PoS chain that can support smart contracts, and then use this "bridged version of Bitcoin" as a pledge asset. This is an intuitive and relatively simple approach.

2. Remote staking: Let Bitcoin remain on the Bitcoin main network and be pledged on other PoS chains remotely. The core of this method is that when a node does evil, the PoS chain must be able to staking on the Bitcoin main network. Bitcoin performs instant, permissionless, and trustless slashing. How to implement slashing based on the original performance of Bitcoin is an extremely challenging engineering matter.

Let's take Bouncebit and Babylon as examples to discuss the specific solution details.

Bridge to PoS chain - BounceBit

Most current Bitcoin L2 solutions are to first transfer native Bitcoin to other PoS chains through bridges or mirrors. For example, Stacks uses the Proof of transfer (PoX) mechanism to package Bitcoin into sBTC; CoreDAO uses a multi-signature bridge to package Bitcoin into coreBTC; B² Network uses a bridge to package Bitcoin into B² BTC; BounceBit uses a bridge to package Bitcoin into BBTC.

These methods are similar. The difference lies in the degree of trustlessness of the bridge: some use less multi-signatures, some use more multi-signatures, some use random multi-signatures, etc., and some use mapping, but they all still need to introduce new trust assumptions.

bouncebit doc

Taking BounceBit as an example, referring to the architecture diagram above, users can deposit Bitcoin through BounceBit Protocol, and then BounceBit Protocol will retain the assets deposited by the user in a multi-party computation (MPC) custody account. (and will not leave), and then on the EVM- compatible chain BounceBit Chain, users will be given BBTC (BounceBit BTC) as a deposit certificate in the form of 1:1. Then there will be familiar usage scenarios such as staking, re-staking, and DeFi. This method of not directly facing technical difficulties, but leveraging the public's trust in MPC custody accounts, is an efficient and pragmatic strategy. For its specific operation methods and details, you can refer to this previously written article ( https://medium.com/@BuidlerDAO/binance-megadrop-first project- bouncebit-can it become a btc-ecological-ethena-3939a0ff4dda ).

Remote staking - Babylon

Pure mapping and bridges will not be the most ideal way for staking. Simple mapping does not have the ability of the PoS chain to punish Bitcoin on the Bitcoin main network. It seems that it cannot even be called a PoS mechanism; the bridge is difficult to build because the Bitcoin main network does not yet have a native smart contract layer. In various senses, it can be called a secure bridge, which requires the introduction of additional trust in a third party.

For Bitcoin holders, they first need to ensure the safety of Bitcoin assets, and then consider the benefits they can obtain. When the Bitcoin bridge cannot achieve enough trust, placing assets on the Bitcoin main network is a prerequisite.

For PoS chains that want to rent security, the core lies in how to have an immediate, effective, and trustless slashing mechanism (Slash Mechanism) for assets on the Bitcoin mainnet. As long as both parties have Turing-complete smart contract layers, it is not difficult to have a slashing mechanism. For example, Eigenlayer's Modular Dual Staking can be used between Ethereum and AVS, or Mesh Security can be used between Cosmos Hub and Cosmos Zone.

Under the current constraints of Bitcoin, Babylon has proposed what seems to be the best technical solution at the moment, considering Credible Neutrality (Credible Neutrality: https://nakamoto.com/credible-neutrality/ ).

How does Babylon work?

The key to the establishment of the pledge mechanism is the existence of a trustless and effective penalty mechanism. To achieve BTC Staking, we can split it into the following small goals:

1. Bitcoin needs to stay on the Bitcoin mainnet for staking.

2. There needs to be a mechanism to determine whether a node has done evil.

3. In the absence of any evildoing, pledgers can withdraw their assets and pledge rewards without permission after the Unbonding Period.

4. In the case of evildoing, the PoS chain must be able to confiscate the Bitcoins on the Bitcoin mainnet without permission within the unbinding period.

In order for Bitcoin to remain on the Bitcoin main network for remote staking, a necessary condition is that there can be two-way real-time communication between the Bitcoin main network and the PoS chain. Babylon's approach is to design a three-layer structure, allowing the Babylon Chain to serve as a bridge of communication between the two. After all, it is difficult to imagine directly transmitting a large amount of information on the PoS chain to the Bitcoin main network without compression and processing.

https://docs.babylonchain.io/docs/introduction/architecture

Specifically, Babylon Chain will maintain bidirectional communication with the two chains. On the PoS chain side, they use IBC Relayer to communicate; on the Bitcoin main network side, they use Vigilante Reporter to pass messages from the Bitcoin main network to Babylon Chain, use Vigilante Submitter to transmit messages from Babylon Chain to the Bitcoin main network, use Checkpointing Monitor to supervise the accuracy of bidirectional messages, and use BTC Staker Record staking-related information and use BTC Staking Monitor to handle issues related to slashing.

There are two mainstream methods for judging evil in the PoS mechanism:

• In the Casper consensus mechanism used by Ethereum ( https://medium.com/taipei-ethereum-meetup/intro-to-casper-ffg-and-eth-2-0-95705e9304d6 ), there are two slashing situations: a1 ) At the same block height, two different blocks are signed, a2) Nodes cannot cast a vote whose height is around the height of another vote. For more detailed information, please refer to this article.

• In the CometBFT consensus engine used by Cosmos ( https://medium.com/r?url=https%3A%2F%2Fdocs.cometbft.com%2F ), there are two types of penalty situations: b1) At the same block height , signed two different blocks, b2) the node conducted an Amnesia Attack https://docs.cometbft.com/main/spec/light-client/accountability/#flip-flopping-amnesia-based-attacks ).

Regarding a1 and b1, Babylon introduced EOTS (Extractable One-Time Signatures) to solve it. Nodes on Babylon Chain use EOTS to sign (that is, vote). Its characteristic is that when the same private key is used to sign two transactions, the private key will be automatically exposed. In other words, anyone can take the information of those two transactions and derive the private key of the signer. This can equivalently solve the problem of "signing two different blocks at the same block height". (accountable assertions)

Regarding a2 and b2, since there is no good equivalent solution, Babylon introduced an "additional consensus round using EOTS" based on the original CometBFT consensus mechanism to solve the problem, which is the so-called "Finality Round", which can be understood as, Nodes vote once first, and after reaching a basic consensus basis, they then find another group of nodes (Finality Provider) to vote once more to confirm the consensus again. The condition for reaching consensus for the second time is to obtain more than two-thirds of the pledged rights. EOTS signature. Only when consensus exists both times is it judged that consensus has been successfully reached. The obvious benefit of this solution lies in its modular nature and compatibility with the Finality Gadget consensus system commonly used in other PoS.

In the absence of evildoing, pledge users who want to get back their assets can solve this problem by adding a time lock (the so-called unlocking period) to the UTXO spending conditions. In the case of evildoing, penalties will be directly forfeited through the above-mentioned EOTS method. So far, this is the way Babylon Chain reaches consensus, judges evildoers, and imposes penalties. It is also worth mentioning that EOTS is implemented through Schnorr signatures, which is also a newly introduced feature after the Taproot upgrade of the Bitcoin main network.

Timestamps, unbinding times and long-range attacks

Compared with PoW, since PoS does not have Nakamoto Consensus, it leads to the possibility of long-range attack. Because of this possibility, PoS often has a relatively longer unlocking period. .

Long-range attacks refer to when an attacker masters the private keys (that is, voting weights) of most nodes of any block in history, and can use the voting weights to be reused. In the small world of nodes, a large number of self-fabricated blocks are quickly generated (which can even be longer than the block history of the outside world). In the case of copying legal timestamps, newly added nodes cannot tell which chain was generated in a lot of real time and which chain was fabricated by the attacker in a short period of time. The fundamental reason for this is that the blockchain represents the advancement of its native time by adding new blocks, and there is no exogenous time.

The previous solution was to solve it through social consensus (Social Consensus: https://medium.com/@VitalikButerin/a-proof-of-stake-design- philosophy-506585978d51 ), for example, regularly in a certain place, such as a foundation Websites, forums, etc., tell everyone what the real and legal blocks look like (Checkpoint), so that nodes that come in later can choose when they see the historical data of two different chains. This is called Weak Subjectivity by Vitalik: https://medium.com/r?url=https%3A%2F%2Fblog.ethereum.org%2F2014%2F11%2F25%2Fproof- stake-learned-love -weak-subjectivity ).

But in the case of Babylon, if the timestamping method mentioned earlier is used to allow the two chains to communicate with each other, the exogenous time of the Bitcoin main network can be introduced in the PoS chain in disguise, that is, it can directly Addresses long-range attacks while also allowing the staking unlock period to be shortened to, for example, six Bitcoin blocks (approximately one hour).

Three core questions about security leasing

How to balance external security leasing and native security (POS perspective)

BTC Staking is not meant to completely replace native token staking. In fact, PoS project parties can have two (Bitcoin + native tokens) or even more diverse pledge asset combinations to ensure their own security. Considering that the holding costs of users holding Bitcoin and native tokens are different, the staking rewards of the two often require additional design. Staking rewards may be in the form of native tokens, revenue shares, etc.

Regarding security, let us think from the two dimensions of "dispersion" and "total amount" of funds.

From the perspective of the degree of dispersion of funds, it is more intuitive: on the basis of the original pledged assets and nodes, if external pledged assets and nodes are introduced, no matter which method is used to combine them, it will undoubtedly increase its decentralization. degree, adding resilience to the overall network. Specific combination methods can include:

1. Native double pledge: The native token operator and the ETH operator are regarded as a whole. The pledge shares of different operators are converted through external prices. Effective consensus only needs to reach this overall threshold.

2. Modular double pledge: Effective consensus requires that the number of supporters of the native token operator and the ETH operator each meet the standard; this consensus standard is relatively strict, and it also means that attackers can only attack operators with lower security , can prevent the formation of consensus.

3. Double pledge with veto: The operators of native tokens meet certain quantitative standards on their own, just like traditional PoS. The ETH operator acts as an extra layer of security, giving the native token operator the right to veto if they make a mistake. There is a difference in usability between this solution and modular double staking: even if all ETH-based operators are disconnected, the PoS network under this solution can still operate normally.

https://www.blog.eigenlayer.xyz/dual-staking/

From the perspective of the total amount of funds, we can simply calculate an account from the perspective of economic security. Assuming that the TVL of the assets bridged to a certain chain is $5M, in order to reach the 1.5x security threshold (corresponding to 2/3 agreement, it can penalty), the amount of pledged assets should preferably not be less than $7.5M. Assume that the current pledged native token assets are only $5.5M, which means there is a security budget deficit of at least $2M. At this time, priority can be given to introducing tokens from other closely related protocols as auxiliary pledge assets. If there is still a deficit at this time, you can consider introducing external security (BTC, ETH, etc.). In other words, Babylon they provide services like mercenaries, paying for security as a last resort.

In addition to the different holding costs, holders of native tokens are more likely to choose to continue holding after receiving staking rewards, and after staking users receive rewards, given that they are here for the benefits, they are very likely to Quick sell rewards bring selling pressure to native tokens. From this perspective, project parties can consider supplementing the security provided by Babylon and others, and weigh the security costs of different solutions. This also means that it is risky for the project side to completely outsource security. Having its own independent validator set and native security based on this is still a better choice.

Based on the above discussion, from the perspective of security lenders, even though the cost of renting Bitcoin or Ethereum is generally low, since the loyalty of this fund is not within its own ecology, the hidden dangers of selling pressure need to be considered at the same time. On the other hand, different project parties can have different priorities for the total amount and degree of dispersion of funds. From a rule of thumb, renting from a few centralized fund providers will usually have a lower unit cost, but at the expense of centralization. ; But the core here is to give different project parties the right to choose.

How to choose a good security tenant (Node Operator perspective)

In a complete, decentralized two-sided market for security leasing, providers of funds (i.e. providers of security) should be able to freely choose to pledge to any specific AVS. But if the AVS ecosystem prospers as expected, how to make the correct selection and allocation among hundreds of AVS? We believe that good is defined as a balance of return and security.

Whether it is personal staking (Solo Staking) or providing funds to a Staking Provider, the selection logic is essentially the same as that of traditional node operators (Node Operators, NOs), and you can directly draw on their accumulated experience. Common screening criteria include ensuring that the lessee has a good development team and good publicly viewable code, the concept of the product and the sustainability of the revenue, the reward ratio given to the security provider, the team's past experience, and the project's fundraising capital situation and investor credibility, etc.

Another core point here is that the final performance of AVS is likely to show a power-law distribution (Power-Law Distribution), that is, AVS with returns concentrated at the head. Therefore, being able to intervene in high-quality AVS at an early stage will be an important source of Alpha. This also means that intervening in all long-tail AVS will not be the optimal solution. On the contrary, it will bring a lot of additional complexity and risks. Node Operator may need to charge high commission fees as a result, thereby reducing the risk-adjusted returns of staking users. At the same time, it may also introduce more slashing risks.

Thinking one level further, if an AVS is recognized as having potential, then everyone has more high hopes for its token value, and it can rent security with a relatively small number of token rewards. Given that token prices fluctuate, Node Operators also need to strike a balance and at least select some AVS that are rewarded with revenue sharing so that their income has a lower limit.

How will the security rental market evolve in the future (Marketplace perspective)

The core of the blockchain world is to use a set of mechanisms to allow selfish individuals to reach consensus in a trustless manner. In the world of PoS, we can understand consensus as pledge, and the forfeitable nature of pledge can be understood as a source of security. Then "security leasing" can also be understood as a means of abstracting consensus issues. , which is the core issue of the blockchain world.

Babylon The service they are building can be compared to a security Marketplace. Its essence is to establish a bilateral efficient market that matches the supply and demand for "security". The supply side here refers to the pledgers, and the demand side refers to AVS with security leasing needs. It is obvious that the current dilemma lies in the lack of a complete and diverse rental ecosystem, and there are not many AVSs that can generate income. Where is the break? From the basic principles of economics, we can know that we look at demand in the short term and supply in the long term.

From the demand side:

• Regarding "whether there is a demand", regardless of the intensity of the demand, we can understand from our previous argument that the demand is real. In the future, if the value and market positioning of App Chain can be more widely understood, or if a new type of AVS can be designed and released, the security leasing market will be more stable and prosperous.

• Regarding "whether demanders can provide sustainable real income", we think it is yes to a certain extent. For example, the DA layer can charge for storage, Oracle can charge for providing data, and PoS can share the MEV income and handling fees within the ecosystem. These benefits are all real and sustainable.

From the supply side, Babylon needs to convince the Bitcoin community that it can ensure the security of assets, and Eigenlayer needs to convince the Ethereum community that they do not overuse Ethereum’s consensus. From the perspective of fund stability, the current pledged funds can be withdrawn at any time. It may be possible to consider providing higher rewards for funds that are willing to pledge for a long time. In addition, if you want to build a high-quality supply side, a pragmatic approach is to first make the concept of "security as a service" practical, then make it easy to use, and finally make it bigger and stronger. For example, the story told by Sreeram Kannan is about building Eigenlayer into a cloud service for cryptocurrency: through scale effect, security providers can effectively dilute the cost of security, and also allow security users to have instant scalability as their business develops. ability. In addition, AVS built on Eigenlayer can also take the route of modular services and provide SAAS-like experiences for other projects and ecosystems. This way, security providers Eigenlayer and AVS can be established. A strong and resilient ecosystem.

N ways to implement Restaking

As an important narrative and improvement of industry infrastructure this year and even in the future, different project parties will inevitably need to think about how to organically combine their businesses with Restaking. We believe that it can be roughly divided into two major directions:

Integrate Restaking related assets

For DeFi-related applications, they can usually intuitively consider how to integrate Restaking assets into their own business scenarios. Some potential directions include mortgage lending based on pledged assets, providing liquidity, etc., thereby increasing the utility of pledged assets.

Take Bedrock as an example. As a specialized liquidity re-pledge protocol, it has newly launched uniBTC, providing a solution for wBTC holders on Ethereum to implement Restaking. Compared with staking directly on Babylon, holding uniBTC has greater liquidity, and in addition to the income rewards of Babylon itself, you can also get diamond point rewards from Bedrock, thus increasing the overall income.

https://medium.com/@bedrock_defi/how-bitcoin-liquid-restaking-unibtc- works-54a7be02a248

In addition, you can also refer to the income platform Solv Protocl, which integrates Babylon's re-staking income into its delta-neutral income strategy.

https://solvprotocol.medium.com/solvbtc-will-integrate-restaking-yield-from- babylon-1dba0c5a5193

The above use cases are relatively simple and straightforward. I believe that some more complex and sophisticated derivative designs will appear in the future.

Rent Security as Infra

Rental security is a more common application scenario. Infras that have higher requirements for decentralization and less initial pledged capital can consider leasing. Some potential AVS directions include: Rollup-related services (sequencers, bridges, MEV-related services, etc.), co-processors (verifiable databases, AI interfaces, etc., representative case: Ritual), some encryption applications (TEE Network, Secret sharing, FHE, etc., representative cases: Inco, Fhenix), some proof applications (identity, address proof, etc.), etc. There are some AVSs that have opened up new scenarios on the chain that have never been seen before. In particular, there can be a lot of innovation in the co-processor area, and the encryption application area has just started.

Take Cyber, which recently announced its L2 status, as an example. Based on Eigenlayer's AVS, it builds a decentralized Infra including a sorter, verifier, and CyberDB. Although it works with Eigenlayer rather than Babylon, in terms of rental security, the two are essentially the same. Cyber ​​adopts a dual pledge model. Users can pledge Cyber ​​or LRT assets (currently supporting ezETH, pufETH, weETH) to obtain multiple benefits, including ETH staking benefits, Eigenlayer’s re-pledge benefits and points, LRT points, Cyber ​​re-pledge points, etc. The security equivalent to AVS is also guaranteed by Cyber+ LRT token.

The double-collateralization model has the advantage of helping the network cold-start by renting ETH and mitigating the impact of the death spiral. For example, when the price of native tokens drops, although the security of the PoS network will be affected, the consequences are relatively controllable. After all, the economic security provided by LRT assets is the foundation.

Conclusion

Security is the core lifeblood of the blockchain. Opening up the security of the two largest cryptocurrencies by market value to other applications and developers will undoubtedly have a lasting and far-reaching impact. Restaking therefore deserves to be the narrative on the main channel of the evolution of the blockchain world. In this process, we see top entrepreneurs in the industry facing key issues, taking advantage of the latest technical feasibility, constantly exploring optimal solutions, and breaking through the original limitations of Bitcoin and Ethereum.

If we look at the sharing of security between the PoW and PoS worlds in a limited way, we can use the first principle to divide it into four types: [PoW, PoS] x [PoW, PoS]:

• PoW → PoW: A common method is merged mining, such as Rootstock.

• PoS → PoS : As in, “Eigenlayer’s re-staking” and “Hub and Zone on the Cosmos ecosystem.”

• PoW → PoS: For example, Babylon uses PoW assets as pledge assets for PoS.

• PoS → PoW: This area is relatively less explored, but an intuitive idea can be that the tokenized computing power can be used on PoW through the conversion of RWA assets.

If we look at security leasing in a broader sense, the key lies in how to reach the underlying consensus, how to protocolize, productize, and scale this consensus, and build a prosperous cloud service ecosystem on this basis. Various AVS services are not isolated islands. Efficient collaboration with each other, better resource utilization and data sharing are more in line with the original spirit of Cypherpunk and are the source of real value.

There are still many possibilities that have not yet been developed, such as the rational distribution paradigm of AVS revenue, the emergence of new AVS, and the Lego combination of various services. We believe that the exploration of Restaking has just begun, and it is worth continuing to pay attention to the evolution, iteration and accompanying opportunities in this direction.

Reference:

https://docs.babylonchain.io/docs/introduction/overview

https://docs.bouncebit.io/?gad_source=1

https://docs.eigenlayer.xyz/

https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c