Approach to analyzing risk

This is the framework we use to analyze sidechains, L2s and other scaling protocols

We analyze protocols on four categories: Data availability, network operators, settlement assurance (a.k.a finality), and the bridge custody (or two-way peg).

Protocols do not receive an overall score, but a risk summary is added at the beginning of every assessment to highlight risk areas that can be critical.

For example, if an optimium uses an offchain data availability solution that is a single server, then it only takes collusion between a sequencer and the operator of the DA server to steal everyone’s funds. This is extremely high risk and should be noted in the summary.

Let’s review how protocols can potentially be assessed.

Data availability

  • Self-hosted: User can store data related to scaling protocol transactions locally - low risk

  • Onchain: Protocol uses Bitcoin for data availability - low risk

  • Offchain via alternative consensus protocol: Data is primarily stored on another publicly available, decentralized network and there is a mechanism to verify that the data is made available - medium risk

    • If the network sees N < 21 operators participating in the network, then it is high risk

    • If the network sees N > 100 operators participating in the network, then it is low risk

    • If no mechanism to detect fraud (e.g. DA withholding attack), then high risk

  • Offchain DAC: State updates are stored via a centralized (or permissioned) committee and Bitcoin full nodes, and users, cannot access that data - high risk

  • Offchain Single Server: State updates are stored via a centralized server and Bitcoin full nodes, and users, cannot access that data - high risk

Network Operators

  • Network is operated peer-to-peer Protocol doesn’t rely on third party operators - low risk

  • Network operator set is N > 21 and users can self sequence - low risk

    • Sequencer designs can include of this Federated, Auction, PoS, DPoS, PoW

    • If network operator is N < 21 , then moved to medium risk

  • User can’t self sequence, but operator set is N > 21 - medium risk

    • If operator set is N > 100 then move to low risk

    • Designs include: Federated, Auction, PoS, DPoS, PoW

  • Federated operator set: Transactions are sequenced by an honest majority of participants in a permissioned, offchain consensus protocol/network - high risk

  • Centralized operator with no self-sequencing - high risk

Settlement Assurance

  • Bitcoin-equivalent: Settlement happens on, or is enforced by, Bitcoin script and/or consensus participants - low risk

  • Onchain, optimistic settlement: Settlement happens through an onchain challenge response protocol (BitVM2, Lightning) - low risk

    • Note: BitVM2 sees challenger/verifier role be permissionless

    • If permissioned, medium risk (Citrea’s zk-verifier, SNARKnado)

  • Offchain via alternative, permissionless consensus mechanism: Settlement is managed offchain by a permissionless consensus protocol and/or network of nodes - medium risk

  • Federated: Settlement for the layer is finalized by an honest majority of participants in a permissioned, offchain consensus protocol/network - high risk

  • Offchain via single server: Settlement for the layer is finalized by one party - high risk

  • Edge case:

    • If the protocol has no fraud proofs, then it is high risk

Bridge Custody

  • No custody with unilateral exit enforced by an L1 transaction - low risk

    • If users can not bypass centralized operator for withdrawals, move to medium and note criticial risk that withdrawals can be paused indefinitely, but not stolen

    • If no state validation mechanism in place, and network operator(s) can collude and post fradulent state roots to steal funds, then move to high risk

  • No custody with optimistic settlement - low risk

  • The two-way peg is federated, but anyone can participate as a watchtower/challenger and stop malicious withdrawals - medium risk

    • If he two-way peg is managed by a federated two-way peg where 1-N operators is required to be honest, keep at medium risk if N > 21

    • If N is equal to, or lower than, 21 move to high risk

  • The two-way peg is governed by an alternative, consensus mechanism - medium risk

    • If there is no slashing mechanism then high risk

  • The protocol has an honest-majority federation securing its two way peg - high risk

  • The protocol doesn’t enable unilateral exit, and its two way peg is managed by centralized parties - high risk

  • Edge case:

    • Users can unilaterally exit, but network operators can collude with other network participants to steal funds, and there is no way to challenge fraud - medium risk

Additional security-related questions Bitcoin security

  • Can users unilaterally exit the l2 and/or bridge that is custodying their funds?

    • Yes/no

    • Insert how

  • Does the protocol inherit security from Bitcoin miners, full nodes or BTC the asset?

    • Yes/no

    • Insert how

  • Does an alternative token play a role in network security/permitting withdrawals?

    • Yes/no

    • Insert how

  • Does the protocol create risks for MEV at the protocol, and base layer, level?

    • Yes/no

    • Insert how

  • Does the protocol pay fees to Bitcoin miners?

    • Yes/no

    • Insert how

This framework can be easier to customize and provide more nuance given the number of scaling solutions that are present in Bitcoin today. For example, related to block production/network operators, we can add even more scoring mechanisms based on how decentralized the network is. E.g. A network with 200 validators is better than a network with 10, and we can customize the assessment to highlight this.

Summary

This risk assessment is an initial starting point to analyze Bitcoin scaling protocols. It is a living document and is subject to change.

Bitcoin does not have a unified scaling roadmap. There are tradeoffs with every protocol being implemented to support Bitcoin scaling. This framework hopes to capture some of the nuance related to the various designs being proposed.

If you have comments on this framework, please consider joining our community chat to discuss. Clarifying point(s)

We define permissionless as meaning anyone with sufficient capital and resources can participate in consensus, operating a node, block production, etc.

Last updated