Renaissance of Bitcoin Scaling II — Babylon

TL; DR

This is the second article in our “Renaissance of Bitcoin Scaling” series. We are exploring a novel protocol called Babylon, which is developing three innovative security-sharing protocols: the Bitcoin Staking Protocol, the Bitcoin Timestamping Protocol, and the Bitcoin Data Availability Protocol. By implementing these pioneering protocols, Babylon envisions a more secure and decentralized future. According to our analysis framework, it falls into the category of upgrading capital efficiency of BTC.

Previous efforts to scale Bitcoin and expand its use cases by building sidechains and other layer 2 projects have been hindered by the inability to transfer a large amount of bitcoins to these chains. This is due to limitations in security and/or capacity. As a result, the majority of bitcoins remain idle, making it difficult to effectively utilize them to protect the decentralized economy. Babylon, unlike other protocols that rely on third-party custody or bridging, empowers the utility of Bitcoin by fully releasing its potential on the Bitcoin native layer.

The goal of the Babylon project is to use Bitcoin as a reliable source of trust to support other blockchains in the broader ecosystem. By providing unparalleled security, Babylon aims to make BTC the anchor for these PoS chains.

In this article, we’ll examine Babylon by answering four straightforward questions: Why is Babylon necessary? How does it solve the problems it aims to? What security assumptions does it introduce? What ecosystem has it built so far?

To sum it up, the answers to the following four questions are as follows:

1. Babylon serves as a win-win solution for both Bitcoin and PoS networks.
2. Babylon functions as middleware that utilizes Bitcoin to secure PoS chains.
3. Babylon unavoidably introduces new security assumptions, in addition to those of the Bitcoin network.
4. Babylon has integrated multiple Cosmos chains as a Cosmos hub.

Win-win Solution for Bitcoin and PoS

As previously mentioned, BTC is unencumbered from PoS chains, currently idle, more decentralized, and less volatile than most PoS assets. The liquidity and utility of BTC are often underestimated in the market. On the other hand, PoS chains have certain security limitations in comparison to PoW chains. The security of a blockchain is largely determined by the value of the resource supporting it, which is the value of cryptocurrency being staked. Although the capital efficiency of PoS chains is much higher, their low market cap may not ensure the chain’s survival.

Indeed, PoS and PoW possess complementary strengths, and a well-designed architecture can harness the advantages of both. Babylon aims to create a mutually beneficial solution for both PoS and PoW chains. The general concept of recording event timestamps in a child chain on a parent chain is referred to as checkpointing, and the transactions that record these events are known as checkpoints. Babylon is implementing checkpointing for PoS chains on Bitcoin.

Yields for Bitcoin Holders

For Bitcoiner, all that is needed is to lock the BTC on the native layer. There is no need to bridge or wrap assets, as the idle BTC can earn extra yield from PoS chains. This is similar to the solution offered by Eigen Layer, with the key difference being that Eigen Layer leverages staked assets like sETH to secure other PoS chains. These assets are ERC20 tokens whose security is ensured by smart contracts. Under the Bitcoin staking protocol, the underlying asset is the native BTC. It is worth noting that the underlying protocol of Bitcoin is more secure and robust than Ethereum.

Security Enhancement for PoS

In PoS chains, a safety violation will result in a 1/3 slash of the Bitcoin stake. The PoS chain will remain operational as long as at least 2/3 of the Bitcoin stake honestly follows the PoS protocol. Babylon’s key feature is its modular design, which allows it to function as a plug-in for various PoS consensus algorithms. This compatibility does not significantly affect the PoS chains and ensures compatibility with existing PoS chains.

First and foremost, checkpointing on Bitcoin add another security layer for PoS chains. Proof-of-stake chains require social consensus to thwart long range attacks and this leads to long unbonding periods. In Cosmos, this is typically 21 days. Bitcoin security replaces social consensus and reduces unbonding periods to hours(Testnet unbonding time ~ 17.96h). Once the checkpoint of a PoS block becomes sufficiently deep in Bitcoin, the checkpoint cannot be reverted, implying that the checkpoints of any attack chain would appear later on Bitcoin, and can subsequently be ignored.

Firstly, implementing checkpoints on Bitcoin adds an extra layer of security for proof-of-stake chains. These chains rely on social consensus to prevent long range attacks, which results in lengthy unbonding periods (typically 21 days in Cosmos). By leveraging Bitcoin’s security, unbonding periods can be reduced to just a few hours (testnet unbonding time is approximately 17.96 hours). Once the checkpoint of a proof-of-stake block is deep enough in Bitcoin, it becomes irreversible. This means that an attack chain’s checkpoints would appear later on Bitcoin and could be disregarded.

Secondly, checkpointing on Bitcoin can bootstrap new chains. The low initial valuation of the chain may discourage users from engaging in high-value trades due to the risk of safety attacks, which in turn can hinder any increase in the token value caused by low trade volume. BTC timestamping can help protect the chain and its growth. Moreover, a double-spending adversary will also incur the cost of forking Bitcoin, which requires the purchase of a tremendous amount of hash power.

Thirdly, checkpointing on Bitcoin can also protect important transactions while ensuring fast finality for normal transactions. We will delve into the details of finality as part of our security assumptions.

Fourthly, checkpointing on Bitcoin can inherit the censorship resistence from Bitcoin. Transactions that have been censored can be recorded on the Bitcoin ledger as a backup. This allows for transparency and accountability, as censored transactions can still be recorded on the ledger.

Babylon is Middleware

Directly checkpointing on Bitcoin seems like an ideal solution for both Bitcoin and PoS chains. However, implementing this solution on every PoS chain is impractical and unnecessary for three main reasons:

1. Checkpointing every Cosmos block that contains a withdrawal request is necessary, which could potentially include all blocks in a Cosmos zone.
2. To prevent a weak adversary (who does not control many validators) from sending arbitrary hashes and pretending to checkpoint a Cosmos block on Bitcoin, it is essential to post enough signatures with each checkpoint. However, BTC can not verify the checkpointed data.
3. The limited space of Bitcoin blocks creates a critical scalability problem for the checkpointing solution. Therefore, Babylon is designed to be middleware that solves the scalability issue with checkpointing. For example, Osmosis checkpointing first on Babylon, then on Bitcoin.

Babylon can be considered not only as a scalable solution, but also as a market maker that offers robust security guarantees to both consumer PoS chains and provider Bitcoin holders. This incentivizes PoS chains to pay yield for security enhancement and Bitcoin holders to stake their funds.

Scalable Architecture

Overall, Babylon is a relayer chain based on Cosmos-SDK that serves as the control plane between Bitcoin and the data plane. For Bitcoin, Babylon is just a child chain attempting to checkpoint on it. For proof-of-stake chains (especially Cosmos zones), Babylon serves as the Cosmos hub.

In the strictest sense, Babylon encompasses more than just the relayer chain. It is a comprehensive solution consisting of four parts: IBC Relayer, Babylon Chain, Vigilante Relayer, and Bitcoin Script Contracts.

IBC Relayer

IBC enables a relayer between two zones. The relayer operates through two layers: the transport layer and the application layer.

The transport layer ensures secure communication between the two zones by establishing a light client of each zone inside the other. The sender zone’s light client maintains a header chain of the sender zone within the receiver zone.

The application layer interprets messages carried by IBC packets sent between the two zones. The application layer of IBC only processes verified messages.

The IBC Relayer is a trustless system as long as there is at least one honest relayer. This means that IBC communication is possible with just one honest relayer. The IBC relayer utilizes PoS’s headers to Babylon as Babylon transactions, effectively functioning as a natural checkpointing mechanism.

Babylon Chain

Babylon acts as a relayer chain, connecting the Bitcoin and PoS chains, and is primarily responsible for two tasks: the Staking Protocol and the Timestamping Protocol.

Staking Protocol

The staking protocol tracks staking and validation information, validator key registration, and finality signature on PoS.

In the Babylon chain implementation, this protocol is known as the Epoching module. The Epoching module is responsible for validator rotation at the end of each epoch, as well as other staking actions such as creating validators, delegating, undelegating, and redelegating. On the testnet, we can observe that the Epoch is set to 1 hour and the block time is 12 seconds, which results in Babylon wrapping around 300 blocks into one epoch checkpoint.

Babylon implemented its own module to reduce the frequency of validator set updates in order to keep pace with Bitcoin. Additionally, Babylon had to disable the native 21-day unbonding function to implement the Bitcoin unbonding mechanism.

Timestamping Protocol

The timestamping protocol is a crucial element that drives the entire checkpointing process. It begins with an efficient PoS timestamp on Babylon, moves on to verify and aggregate checkpoints on the Babylon chain, and concludes with the publication of clear, verifiable, and adversary-slashing checkpoints of the Babylon chain on Bitcoin. As a result, it employs numerous modules to coordinate and communicate with both Bitcoin and PoS chains.

Following the Epoching module, the first block of each epoch E that we checkpoint is BLS-signed by the validator set of epoch (E-1). This is because this block carries the execution result of the last block of epoch (E-1) and is committed by the new validator set.

The Checkpointing module handles all messages related to BLS signatures, such as signing, verifying, and accumulating BLS signatures, and collecting the BLS signatures and aggregating them into a BLS multisig. It then generates the commitment to the epoch’s validator set. The original signatures used by Tendermint are ed25519, but they are not aggregable and take up a lot of space. To minimize the checkpoint size, Babylon requires every validator to register a BLS public key when it signs up. Validators need to provide their BLS public keys, as well as proof that proves ownership of this key (proof-of-possession, or PoP).

After the Checkpointing module generates a checkpoint, it will be handed over to the Vigilante Submitter. The Vigilante Submitter will then submit the Babylon checkpoints to Bitcoin as OP_RETURN transactions.

To ensure whether checkpoints are confirmed on the Bitcoin network, the specific BTCCheckpoint module receives reports from Vigilante Reporters and block information from the BTCLightClient module. This module then provides the confirmation status of these checkpoints. Although the BTCCheckpoint module itself does not verify the validity of checkpoints, it leverages the help of the Checkpointing module. The BTCCheckpoint module serves as the data source, storing and tracking checkpoints and providing the stages of the checkpoint life cycle.

To connect with the Bitcoin and PoS chain, respectively, Babylon has implemented two separate light clients, the BTCLightClient module and the IBCLightClient module. The BTCLightClient module maintains a BTC header chain and validates BTC blocks, including depth and transaction validity. On the other hand, the IBCLightClient module verifies the headers shared by the IBC relayer and uses the verified headers to further verify PoS transactions.

Furthermore, Babylon serves not only as the relayer but also as the timestamping protocol for PoS chains. Therefore, it maintains the checkpoints for all integrated PoS chains. Babylon implements a Concierge module to checkpoint Cosmos PoS chains to Babylon. The Concierge module extracts verified PoS headers from the IBCLightClient module and maintains their BTC-confirmation status based on the BTC-confirmation status of the Babylon transactions that carry them. In return, the Concierge module builds an index for each IBCLightClient and provides proof that a header is finalized by Bitcoin.

Vigilante Relayer

Vigilante Relayers are a set of standalone programs that operate alongside Babylon nodes in three modes: submitter, reporter, and monitor.

As the name suggests, Vigilante Submitters convert a raw checkpoint into two OP_RETURN transactions and submit them to the Bitcoin network. Since OP_RETURN can store arbitrary data but is limited to 80 bytes, the raw checkpoint of around 110 bytes needs to be split into two separate transactions: CheckpointFirst (195 bytes) and CheckpointSecond (183 bytes), including other transaction parts. If the network is congested, the above transaction pair can be submitted at a different price, such as a miner fee of 12 sats/byte or 3 sats/byte. At the current price of BTC (30,000), the transaction cost for each checkpoint will be 1.36 or $0.34. Additionally, Vigilante Submitters use a pull-based approach to repetitively submit checkpoints.

Vigilante Reporters scan the BTC ledger for Babylon’s BTC checkpoints. They check for the ‘BBNT’ tag at the beginning of the OP_RETURN data and report them back to Babylon as Babylon transactions.

Vigilante Monitors is an affiliate tool responsible for monitoring the consistency between the real-world BTC canonical chain and the BTC header chain maintained by Babylon’s BTCLightClient module. It also monitors whether BTC checkpoints have been included in Babylon’s ledger on time so that all Babylon nodes can see them.

Bitcoin Script Contract

Bitcoin’s programmability is limited, so many protocols use script to mimic smart contract functionality. Babylon combines OP_RETURN transactions and BLS multiSig to enable checkpointing on Bitcoin in a simple, timely, and flexible manner when compared to the Pikachu protocol by Protocol Labs. To generate checkpoints, Babylon validators only need to submit on-chain BLS signature transactions, rather than signing BTC transactions. Moreover, Babylon supports future signature customization as well.

The primary issue with Bitcoin timestamping is that the unbonding process is faster in Bitcoin than in PoS. This means that a staker could potentially launch an attack by unbonding and then creating a fork in the PoS chain. In order to prevent this, Babylon includes PoS block hashes and signatures of PoS blocks on the Bitcoin chain. If an attacking fork were to occur, it would have a later BTC timestamp in the BTC canonical chain and would not be selected by anyone since it is economically unfeasible to create a long BTC fork in which the attacking PoS fork has an earlier timestamp.

The script behind the mechanism consists of two types of contracts. The first is the Time-Lock Contract, which uses the OP_CHECKSEQUENCEVERIFY opcode to lock the stake for a specific time period. The second is the Bitcoin Covenant Contract, which uses the OP_CHECKTEMPLATEVERIFY opcode to specify conditions for spending the funds in future BIP119 adoption. In the current version, Babylon uses covenant emulation to set specifications for four transaction types.

• Staking: This action makes the output spendable by unbonding or slashing.
• Unbonding: This action allows the staker to spend the output
• Slashing: This action allows the owner of the slashing address to spend the output.
• Unstaking: This action spends the output from unbonding.

In this way, the slashing transaction can be spent before unstaking if the adversary signs two messages using the same private key. In the normal withdrawal process, once the checkpoint of a PoS chain containing the withdrawal request becomes deep enough in the confirmed Bitcoin chain, the staker can withdraw by initiating an unstaking transaction on Bitcoin.

Security Model

Additional Security Assumptions

As seen above, Babylon introduces new layers to build scalable architecture, which inevitably introduces new security assumptions about the system. Babylon can only be considered safe if the following assumptions are satisfied:

1. BTC is always secure with the k-deep confirmation rule.
2. Babylon has an honest majority.
3. Cosmos zones have an honest majority.
4. There exists at least one honest IBC relayer.
5. There exists at least one vigilant submitter/reporter.

Except for the first assumption, which has been battle-tested in the past years and ensured by the Longest Chain Rule on Bitcoin, the other assumptions are newly set up by Babylon, and all add new dimensions of vulnerability.

Normal Mode and Rollup Mode

While Babylon leverages the security of Bitcoin to handle emergency situations caused by security breaches.

Under normal mode or optimistic scenarios, the PoS chain uses the native fast finality rule and the sequence of checkpoints on Bitcoin to obtain a checkpointed chain of PoS blocks. In this process, PoS blocks with earlier checkpoints take precedence over conflicting blocks with later checkpoints. Although Bitcoin cannot protect the PoS chain against safety attacks under the fast finality rule, it makes these attacks slashable by not allowing attackers to withdraw stakes after signing conflicting blocks. If an adversary corrupts at least 2/3 of the PoS validators so they can finalize PoS blocks with their signatures and withhold data from honest validators, the system will go into Emergency Break. In most cases, normal mode satisfies user demands and offers slashable security.

For high-value transactions or during the early stages of a PoS chain, slashability may not be enough. In these scenarios, a PoS chain can switch to rollup mode, which provides slow finality. When a PoS chain is in rollup mode, validators only confirm the availability of data within PoS blocks, while the sequence of blocks is determined by their checkpoints on Babylon. The canonical Babylon chain is formed using the Babylon block checkpoints on Bitcoin, which serves as the ultimate authority for the order of PoS blocks. Under the slow finality rule, Babylon is protected from adversarial validators, as long as Bitcoin remains secure. In this way, Babylon achieves Bitcoin’s safety, though at the cost of longer confirmation times.

PoS chains can actively adopt rollup mode to bootstrap or handle high-value transactions. They can also passively enter rollup mode to address censorship. If a user of the PoS chain believes that a certain transaction (tx) has been censored by the PoS chain, they can trigger the chain to enter rollup mode by submitting a censorship complaint (a Babylon transaction that includes the hash of the censored transaction tx) to Babylon. PoS validators wait until the checkpoint of the complaint reaches k confirmations on Bitcoin. At this point, if a validator hasn’t yet seen tx become finalized within the PoS chain, it stops creating new PoS blocks or signing new proposals. Instead, it sends a checkpoint for its view of the PoS chain to Babylon. Once the checkpoint of the censorship complaint reaches 2k confirmations on Bitcoin, if none of the Bitcoin checkpoints support PoS blocks containing tx in their prefix, the validators and the user enter rollup mode.

In Rollup Mode, a validator can propose a bundle of PoS transactions. Once this bundle is received, each validator in Rollup Mode will sign the bundle hash if the transactions are visible to the validator. If bundle hashes receive signatures from validators with over half of the stake, those hashes and associated signatures are posted to Babylon as bundle checkpoints. To be valid, a bundle checkpoint must include signatures from validators holding over half of the stake.

Validators will automatically exit rollup mode after observing the building of T>2k blocks on the checkpoint of the censorship complaint on Bitcoin.

Points

Babylon’s solution enhances the security of PoS chains from Bitcoin. However, it does not fully inherit security from Bitcoin because it does not post the entire PoS data to Bitcoin. Instead, it posts only the hash and signatures as checkpoints. Under our analysis framework:

Read: A light client can read the state of Bitcoin. It relies on any trust of Vigilante Relayers. As long as one honest party is present, the reading process is trustless.

Write: It relies on any trust of Vigilante Relayers. As long as one honest party is present, the writing process is secure.

Custody of Bitcoin: Bitcoins are staked on the native layer using script language.

Security Assumption: More security assumptions are introduced as mentioned above.

Overall, Babylon’s weakest points are the validators’ corruption in Babylon and PoS chains. However, it has put up some emergency brakes and slower modes to ensure the security of the system, sacrificing some short-term performance.

Present and Future

Academic-Driven Team

Babylon was developed by the Standford Tse Lab, led by David Tse, a celebrated professor at Stanford University and advisor of Bain Capital Crypto. David and his co-authors published a research paper that was accepted by the 2023 IEEE Symposium and revealed the weaknesses of PoS chains. The concept of Babylon is based on Bitcoin-Enhanced Proof-of-Stake Security behind the paper, a revolutionary protocol designed to enhance the security of Proof-of-Stake (PoS) blockchains.

David and his team have also collaborated with the Ethereum Foundation, contributing to the security of the PoS Ethereum Consensus protocol launched in the Ethereum Merge.

The core team is comprised of a group of consensus protocol researchers from Stanford and experienced layer 1 developers from around the world. For instance, Xinshu Dong was the co-founder of Zilliqa.

Diverse Testnet Ecosystem

Babylon has made significant progress within the Cosmos ecosystem. To date, it has announced official partnerships with 22 entities and integrated 31 Cosmos chains. Many of these chains are major players in the Cosmos ecosystem.

Thanks to the Cosmos SDK’s customization feature, Babylon has the potential to expand into a versatile ecosystem beyond DeFi. Babylon’s diversity is represented by various protocols, including EVM compatibility, DeFi hub, NFT center, decentralized cloud infrastructure, data privacy, interchain liquid staking, SaaS providers, and more.

Evmos Evmos is a blockchain in the Cosmos ecosystem based on the Ethereum Virtual Machine. It enables developers to launch apps that run smart contracts across any number of EVM- and Cosmos-based blockchains.

Akash Akash is decentralizing cloud infrastructure by giving users control over the price they pay, as well as included amenities. It is also funding the development of Mesh security, which will allow blockchains that share the same set of validators to validate and verify transactions at lower costs.

Stargaze Stargaze represents a paradigm shift in the world of blockchain by putting power in the hands of its community members. With its foundation based on the CosmWasm framework and the native utility token $STARS, Stargaze offers a feature-rich and decentralized environment for creating and exchanging NFTs.

Secret Network Secret Network is the first blockchain with data privacy by default, allowing you to build and use applications that are both permissionless and privacy-preserving. This unique functionality protects users, secures applications, and unlocks hundreds of never-before-possible use cases for Web3.

Quicksilver Quicksilver Protocol is a permissionless, sovereign Cosmos SDK zone that provides liquid staking to the Interchain ecosystem. It is created for Cosmos, by Cosmonauts, and is on a mission to support user sovereignty and decentralization.

Chain4Energy Chain4Energy is a customer-centric SaaS provider that brings blockchain technology to the energy market to enable transparent, secure, and decentralized solutions.

Among the 31 integrated chains, the latest block of 25 chains has 101 BTC confirmations. The average submission interval of these chains is 626 seconds, which is around 10 minutes. Taking Osmosis as an example, its block time is 6 seconds. It will submit its block headers from the past 10 minutes (around 100 blocks) to Babylon. As mentioned before, the epoch of Babylon is set to one hour (or exactly 0.9 hours). An approximate calculation shows that Osmosis will make 6 submissions during an epoch, as shown below.

Regarding the checkpoints of epoch, there are 5 statuses:

1. ACCUMULATING: At each epoch boundary, the Checkpointing module generates an empty checkpoint of this epoch.
2. SEALED: Once sufficient voting power is accumulated or a SUBMITTED checkpoint is found on a forked BTC checkpoint.
3. SUBMITTED: The Vigilante submits the checkpoint to BTC.
4. CONFIRMED: The checkpoint receives sufficient confirmations on the BTC header chain maintained by the btclightclient module, meaning n-deep (testnet: 1 confirmation) BTC headers of Babylon are consistent with the BTC full node.
5. FINALIZED: More confirmations are received, and reporters send checkpoints that are not yet w-deep (testnet: 100 confirmations) in BTC to Babylon.

According to testnet metrics, it takes an average of 0.92 hours for checkpoints to accumulate with epoch, followed by 0.01 hours or 6 minutes to be sealed. Submitting to BTC takes an average of 9.02 hours, and BTC takes 10.23 hours to confirm. Finally, after receiving 100 confirmations, it takes around 24.8 hours to be finalized. The standard deviation shows that there is room for improvement in making the process more stable on Bitcoin.

Regarding the decentralization of Babylon, there are currently 80 active validators out of a total of 151 validators in the network’s history. The Babylon Foundation holds approximately 74.8K voting power, which accounts for nearly 42.5% of the entire network. The other validators are primarily collaborators. Thus, Babylon should aim to attract more validators to operate the network, thereby increasing its decentralization.

Opportunities and Challenges

By integrating with Cosmos zones, Babylon not only provides Bitcoin security to these networks, but also increases the value of PoS ecosystems by channeling them into the Bitcoin network. However, the total market cap of these partner zones is currently only $1,796,834,688, which is only 0.3% of the idle BTC capacity.

In comparison to Stack, which we analyzed in our previous article, Babylon has much greater potential. While Stacks uses its own token to secure the custody of BTC, its capacity is limited by its market cap. On the other hand, Babylon leverages BTC to secure the PoS chains, and the more PoS chains it supports, the greater the utilization ratio of BTC. According to TradingView, BTC dominates 50.43% of the whole crypto market, which means BTC can secure all of the remaining PoS chains so far. With the development of different implementations of IBC in other languages, such as Move and Solidity, Babylon can support a broad PoS network, including Polygon, BNB, Polkadot, Solana, Aptos, and Near. So in the three-layer architecture of Babylon, the only bottleneck may be the market cap of Babylon itself. Babylon could attack the timestamping protocol and temporarily stall the running of the PoS chain. However, Babylon is a plug-in that can be easily unplugged, and PoS chains can find a way to recover.

Looking on the bright side, Babylon has the greatest motivation to expand the ecosystem, enlarge the market scope, and empower its own middle layer, rather than harm the system. But we have to admit that Babylon faces some obvious challenges to promote its solution:

1. The Bitcoin community is more conservative than anticipated.

Although BTC is staked on the Bitcoin network, validators may get slashed if they corrupt the network. Many Bitcoin whales prefer to store their assets in cold wallets, and the yield may not be attractive enough for them to provide liquidity.

2. Benefit distribution varies among PoS chains.

Currently, there are no standard distribution mechanisms for PoS chains. There may be controversy in each PoS chain regarding how much they are willing to pay for additional security enhancements.

3. Babylon must be objective and decentralized to coordinate both sides.

As the middleware, Babylon needs to be decentralized and objective enough to convince participants to join. The starting point is to fairly launch its own token, making the token distributed to as many validators as possible.

As long as Babylon solves the trust problem of the Bitcoin community and establishes its tokenomics well, we may witness the combined power of PoW and PoS brought by it in the near future. It will be interesting to see how this scaling paradigm on Bitcoin will evolve.

Reference

1. Home — Babylon
2. BabylonChain Inc.
3. Blog — Babylon
4. arxiv.org
5. docs.babylonchain.io
6. Babylonscan
7. bitcoin/src/validation.cpp at a688ff9046a9df58a373086445ab5796cccf9dd3 · bitcoin/bitcoin
8. cosmos-sdk/docs/architecture/adr-039-epoched-staking.md at main · cosmos/cosmos-sdk
9. bips/bip-0119.mediawiki at master · bitcoin/bips
10. Blockchains & Decentralized Systems | Tse Lab at Stanford University
11. Goldfish: No More Attacks on Proof-of-Stake Ethereum