Jumping down the Babylon rabbit hole, we stumbled into the land of secure rentals

The concept of Restaking is closely related to the sharing of distributed network security. DAO researcher Jane, Gimmy started with curiosity about Babylon / BTC Restaking, then accidentally jumped into the rabbit hole of long discussions about underlying consensus mechanisms such as PoW and PoS, then grasped the core idea of ​​"security leasing", and considered the significance of AVS from the first principles, and finally discussed 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 Ethereum's consensus mechanism 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 and giving them a (new) native staking function, it also opened up the possibility of re-staking through protocols such as Lido, Rocket Pool, and Frax Finance.

The essence of re-staking is to use liquid assets such as LST to provide security to other AVS in order to obtain corresponding returns, which can be regarded as a security rental service. However, in the context of Bitcoin, the current definition of the term is relatively confusing. "Re-staking" often refers to the use of Bitcoin as the staking asset (BTC as the staking asset). For the sake of simplicity and clarity, the following text will refer to this practice of "using Bitcoin as a pledged asset" as BTC Staking; on this basis, assuming that it is technically possible to stake the already pledged Bitcoin again, it will be the so-called BTC Restaking (there are currently no good cases and usage scenarios, and we will also demonstrate the rationality of this matter).

The origin of BTC Staking

Both PoW and PoS are consensus protocols whose purpose is to maintain synchronization between distributed nodes. The way to maintain synchronization is to select a node and take 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 hash rate and the physical energy behind it; in the case of PoS, this scarce resource is capital.

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

Even in the long run, Bitcoin has the hidden danger of unsustainable economic incentives for miners due to the continuous halving of token rewards, so it may be necessary to iterate to relatively sustainable models such as PoS at the consensus mechanism level. But in the short-term practical operation, PoW and PoS are not opposing systems. For example, Bitcoin can be used as a pledge asset to introduce the concept of PoS pledge in the PoW ecosystem. From the perspective of Bitcoin holders, BTC Staking has created a new use scenario for them; from the perspective of the security of PoS chain leasing, Bitcoin can be used as a supplementary alternative when the pledge assets are (temporarily) insufficient or costly.

Choice of two paths

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

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

2. Remote staking: Keep Bitcoin on the Bitcoin mainnet and stake it on other PoS chains remotely. The core of this method is that when a node behaves maliciously, the PoS chain must be able to slash Bitcoin on the Bitcoin mainnet in an instant, permissionless, and trustless manner. How to achieve slashing on the current performance of Bitcoin is an extremely challenging engineering task.

We take Bouncebit and Babylon as examples to explore the specific solution details.

Bridge to PoS chain - BounceBit

Most of the current Bitcoin L2 solutions are to transfer native Bitcoin to other PoS chains first 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, and the difference lies in the degree of trustlessness of the bridge: some use fewer 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

Take BounceBit as an example, referring to the architecture diagram above, users can deposit Bitcoin through the BounceBit Protocol, and then the BounceBit Protocol will keep the user's deposited assets in a multi-party computing (MPC) escrow account (and will not leave), and then on the BounceBit Chain, an EVM-compatible chain, in a 1:1 form, give the user BBTC (BounceBit BTC) as a deposit certificate. Then there will be the familiar use scenarios such as staking, re-staking, DeFi, etc. This method of not facing technical difficulties directly but borrowing the public's trust in MPC custody accounts is an efficient and pragmatic strategy. For its specific operation and details, please refer to this previous article (https://medium.com/@BuidlerDAO/币安-megadrop-第一项目-bouncebit-成为-BTC-生态的-ethena-3939a0ff4dda).

Remote Staking —— Babylon

Simple mapping and bridge will not be the most ideal way of staking. Simple mapping does not have the ability of the PoS chain to punish Bitcoin on the Bitcoin mainnet, which does not seem to be a PoS mechanism; as the Bitcoin mainnet does not have a native smart contract layer, it is difficult to build a bridge that can be called safe in all senses, and it is necessary to introduce additional trust in third parties.

For Bitcoin holders, the first thing is to ensure the security of Bitcoin assets, and then consider the benefits that can be obtained. When the Bitcoin Bridge cannot achieve sufficient trustlessness, placing assets on the Bitcoin mainnet is a prerequisite.

For PoS chains that want to rent security, the key lies in how to have an instant, effective, and trustless slashing mechanism for assets on the Bitcoin mainnet. Under the condition that both parties have a Turing-complete smart contract layer, 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 restrictions of Bitcoin, from the perspective of Credible Neutrality (https://nakamoto.com/credible-neutrality/), Babylon has proposed what seems to be the best technical solution at the moment.

How does Babylon work?

The key to the establishment of the staking 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 is malicious.

3. In the absence of malicious behavior, the pledger can withdraw his assets and pledge rewards without permission after the unbonding period.

4. In the case of malicious behavior, the PoS chain must be able to confiscate Bitcoin on the Bitcoin mainnet without permission during the unbonding period.

In order for Bitcoin to remain on the Bitcoin mainnet for remote staking, the necessary condition is that the Bitcoin mainnet and the PoS chain can communicate in real time in both directions. Babylon's approach is to design a three-layer structure, allowing the Babylon Chain to act as a bridge for 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 mainnet without compression and processing.

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

Specifically, Babylon Chain will communicate with the two chains in both directions. On the PoS chain side, they use IBC Relayer to communicate; on the Bitcoin mainnet side, they use Vigilante Reporter to pass messages from the Bitcoin mainnet to Babylon Chain, and use Vigilante Submitter to pass messages from Babylon Chain to the Bitcoin mainnet. Checkpointing Monitor is used to supervise the correctness of two-way messages, BTC Staker is used to record pledge-related information, and BTC Staking Monitor is used to handle penalty-related issues.

There are two mainstream approaches to judging malicious behavior 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 types of slashing situations: a1) signing two different blocks at the same block height, a2) nodes cannot cast votes with a height around another voting height. 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 also two types of slashing situations: b1) signing two different blocks at the same block height, b2) the node performs 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 the problem. Nodes on the Babylon Chain use EOTS to sign (i.e. 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 use the information of the two transactions to deduce 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 "extra consensus round using EOTS" based on the original CometBFT consensus mechanism to solve it, which is the so-called "Finality Round". It can be understood that the node first votes once, and after reaching a basic consensus, another group of nodes (Finality Provider) will be found to vote once more to confirm the consensus again. The condition for reaching a consensus for the second time is to obtain EOTS signatures of more than two-thirds of the staked rights. Only when there is consensus twice, it is judged that consensus has been successfully reached. The obvious advantage of this solution is its modularity, which is compatible with other PoS commonly used Finality Gadget consensus systems.

In the absence of malicious behavior, if the pledged user wants to retrieve his assets, he can add a time lock (the so-called unlocking period) to the spending conditions of UTXO. In the case of malicious behavior, the above-mentioned EOTS method will be used to directly confiscate the assets. So far, this is the way Babylon Chain reaches consensus, judges malicious behavior, and imposes confiscations. It is also worth mentioning that EOTS is implemented through Schnorr signatures, which is also a new feature introduced after the Taproot upgrade of the Bitcoin mainnet.

Timestamp, unbinding time and long-range attack

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

Long-range attack means that when an attacker has mastered the private keys (that is, voting weights) of most nodes in any block in history, he can use the feature of reusable voting weights to quickly generate a large number of self-fabricated blocks (even longer than the history of external blocks) in his own small world of controlled nodes. In the case of copying legitimate timestamps, newly added nodes cannot distinguish which chain is generated by a lot of real time and which is a chain fabricated by the attacker in a short 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), such as regularly telling everyone what the real and legal blocks look like (Checkpoint) somewhere, such as the foundation's website, forum, etc., so that the nodes that come in later can choose when they see the historical data of two different chains. This is called Weak Subjectivity by Vitalik (Weak Subjectivity: https://medium.com/r?url=https%3A%2F%2Fblog.ethereum.org%2F2014%2F11%2F25%2Fproof-stake-learned-love-weak-subjectivity).

However, in the case of Babylon, if the timestamping technique mentioned above is used to allow the two chains to communicate with each other, the exogenous time of the Bitcoin main network can be introduced on the PoS chain in disguise, which can directly solve long-range attacks and shorten the unlocking period of the stake to, for example, six Bitcoin blocks (about one hour).

Three core questions about security leasing

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

BTC Staking does not mean to completely replace the staking of native tokens. In fact, PoS project parties can have two (Bitcoin + native tokens) or even more diversified staking asset combinations to ensure their own security. Considering the different holding costs of Bitcoin and native tokens for users, the staking rewards for both often require additional design. Staking rewards may be in the form of native tokens, revenue sharing, etc.

Regarding security, let's think about it from the two dimensions of "dispersion" and "total amount" of funds.

From the perspective of the dispersion of funds, it is relatively 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 and increase the resilience of the overall network. Specific combinations can be:

1. Native double staking: Native token operators and ETH operators are regarded as a whole, and the pledged shares of different operators are converted through external prices. Effective consensus only needs to reach the threshold of this whole.

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

3. Double staking with veto: The operators of the native tokens meet a certain number of standards on their own, just like traditional PoS. As an extra layer of protection, the ETH operator has the right to veto when the native token operator makes a mistake. This scheme is different from modular double staking in terms of availability: even if all ETH-based operators are disconnected from the network, the PoS network under this scheme can still operate normally. From the perspective of the total amount of funds, we can do a simple calculation 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.5 times security threshold (corresponding to 2/3 consent to be confiscated), the amount of pledged assets should not be less than $7.5M. Assuming that the current pledged native token assets are only $5.5M, it means that there is at least a $2M security budget deficit. At this time, it is possible to give priority to introducing tokens of other closely related protocols as auxiliary pledged assets. If there is still a deficit at this time, it is possible to consider introducing external security (BTC, ETH, etc.). In other words, the services provided by Babylon and others are like mercenaries, and security can be obtained by paying when necessary.

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

   To sum up the above discussion, from the perspective of the security renter, even though the cost of renting Bitcoin or Ethereum is usually low, because the loyalty of this fund is not within its own ecosystem, it is necessary to consider the hidden dangers of selling pressure at the same time. On the other hand, different project parties can have different priorities for the total amount of funds and the degree of dispersion. From the rule of thumb, renting from a few concentrated fund providers usually has a lower unit cost, but it will be at the expense of centralization; but the key here is to give different project parties the right to choose.

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

   In a complete and decentralized security rental bilateral market, the provider of funds (that is, the provider of security) should be free to choose to stake on any specific AVS. But if the AVS ecosystem prospers as expected, how to make the right choice and allocation among hundreds of AVS? We believe that the definition of excellence should be a balance between return and security.

   Whether it is individual staking (Solo Staking) or providing funds to Staking Provider, the selection logic is essentially the same as that of traditional node operators (Node Operators, NOs), and they can directly learn from their accumulated experience. Common screening criteria include ensuring that the lessee has a good development team and good publicly reviewable code, product philosophy and sustainability of benefits, the proportion of rewards given to security providers, the team's past experience, the project's fundraising situation and the credibility of investors, etc.

   Another core point here is that the final performance of AVS is likely to show a power-law distribution, that is, the returns are concentrated in the top AVS. 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, thereby reducing the risk-adjusted returns of pledge users. At the same time, it may also introduce more penalty risks.

   Thinking one step further, if an AVS is recognized as having potential, then everyone will have more high hopes for the value of its token, 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 to ensure 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 PoS world, we can understand consensus as staking, and the confiscable nature of staking can be understood as the source of security. "Security rental" can also be understood as a means of abstracting the consensus problem, which is the core problem of the blockchain world.

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

   From the demand side:

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

   • Regarding "whether the demander can provide sustainable real income", we believe that it is certain to some extent. For example, the DA layer can charge for storage, Oracle can charge for providing data, and PoS can share the income and fees of MEV in the ecosystem, and these incomes are real and sustainable.

   From the supply side, Babylon needs to convince the Bitcoin community that it can guarantee the security of assets, and Eigenlayer needs to convince the Ethereum community that they do not overuse Ethereum consensus. From the perspective of fund stability, the current pledged funds can be withdrawn at any time, and here it may be possible to consider providing higher rewards for funds willing to pledge for a long time. In addition, if you want to build a high-quality supply side, the 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 to build Eigenlayer into a cloud service for cryptocurrency: through economies of scale, security providers can effectively dilute the cost of security, and also allow security users to have the ability to expand instantly as their business develops. In addition, AVS built on Eigenlayer can also take the route of modular services to provide other projects and ecosystems with a similar experience to that of SAAS, so that a strong and resilient ecosystem can be established around security providers Eigenlayer and AVS.

   N Ways to Carry 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 business with Restaking. We believe that it can be roughly divided into two major directions:

   Integration of Restaking-related assets

   For DeFi-related applications, they can usually intuitively consider how to integrate Restaking-related 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 dedicated liquidity re-pledge protocol, it has newly launched uniBTC, which provides a solution for wBTC holders on Ethereum to implement Restaking. Compared with staking directly on Babylon, holding uniBTC has stronger liquidity, and in addition to obtaining Babylon's own income rewards, you can also obtain Bedrock's diamond points rewards, thereby 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 direct. I believe that some more complex and sophisticated derivative designs will appear in the future.

   As Infra Leased Security

   Leasing security is a more universal application scenario. Infras with high requirements for decentralization and less initial pledge capital can all consider leasing. Some potential AVS directions include: Rollup-related services (sorters, bridges, MEV-related services, etc.), coprocessors (verifiable databases, AI interfaces, etc., representative cases: Ritual), some cryptographic applications (TEE Network, secret sharing, FHE, etc., representative cases: Inco, Fhenix), some proof applications (identity, address proof, etc.), etc. Some of these AVS have opened up new on-chain scenarios that have never been seen before, especially the coprocessor, which can have a lot of innovations, and the cryptographic application is just getting started.

   Take Cyber, which recently announced that it would do L2, as an example. It builds a decentralized Infra including sorters, verifiers, and CyberDB based on Eigenlayer's AVS. Although it cooperates with Eigenlayer instead of Babylon, the two are essentially the same in terms of rental security. Cyber ​​adopts a dual staking model, where users can stake Cyber ​​or LRT assets (currently supports ezETH, pufETH, weETH) to obtain multiple benefits, including ETH staking benefits, Eigenlayer re-staking benefits and points, LRT points, Cyber ​​re-staking points, etc., which is equivalent to the security of AVS and Cyber+ LRT tokens.

   

   The dual staking model has an advantage: it can help the network cold start by renting ETH and reduce the impact of the death spiral. For example, when the price of the native token falls, the security of the PoS network will be affected, but the consequences are relatively controllable, after all, there is the economic security provided by LRT assets.

   Conclusion

   Security is the core lifeblood of blockchain. Opening up the security of the two largest cryptocurrency tokens to other applications and developers will undoubtedly have a lasting and far-reaching impact. Restaking is therefore a well-deserved narrative on the main channel of the evolution of the blockchain world. In this process, we see that the top entrepreneurs in the industry are facing key issues, using the latest technical feasibility, and constantly exploring the optimal solution to break 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, using the first principle, it can be divided into four types: [PoW, PoS] x [PoW, PoS]:

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

   • PoS → PoS: For example, "Eigenlayer's re-staking" and "Hub and Zone on the Cosmos ecosystem" belong to this category.

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

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

   If you look at security leasing in a broader sense, the key lies in how to reach the underlying consensus, how to make this consensus protocol, product, and scale, and build a prosperous cloud service ecosystem on this basis. Each AVS service is not an isolated island. Efficient collaboration, better resource utilization and data sharing are more in line with the original spirit of Cypherpunk and the source of real value.

   There are still many possibilities that have not been developed, such as the reasonable distribution paradigm of AVS income, 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