Thread by @gakonst

SIDECHAINS ARE NOT LAYER 2

Let's put a myth to bed.

Thread on the history of sidechains, their security properites, concluded by their differences to Layer 2 solutions.

(there’s a lot of resources, feel free to skip/bookmark for later!)

👇

-- History of Sidechains --

“Sidechains” is a term coined in [1] by @Blockstream, as a way to access innovative blockchain features which are too risky to try on Bitcoin.

This is done by enabling the transfer of BTC between chains w/ varying feature sets

[1] blockstream.com/sidechains.pdf

They introduced the "two-way-peg" (2WP) for PoW blockchains.

To transfer assets from the “sending chain” (SC) to the “receiving chain” (RC), you lock them on the SC, and mint an equivalent amount on RC by providing a proof of ownership on SC along with a DMMS* with enough work.

* DMMS: Dynamic Membership Multi-party Signature. In the PoW case, that’s an SPV proof. Screenshots from [1].

Note that the 2WP between PoW chains requires each chain be able to verify the other chain’s Proof of Work algo.

Blockstream’s Liquid uses a multisig federation and doesn’t need SPV proofs for peg-in/out (more on that later on PoS sidechains).

-- PoW Sidechains --

A few years later @sol3gga, @socrates1024 and @dionyziz came up with NiPoPoWs [2], a succinct SPV proof technique where the main insight is that some blocks have a better mining target than others.

[2] nipopows.com

(obviously, @socrates1024 talked about this in bitcoin talk in 2012 bitcointalk.org/index.php?topi…)

This works only for constant difficulty PoW, so is still not practical, and is vulnerable to block withholding/bribing! @gtklocker implemented a NiPoPoWs velvet fork and interlinker for Bitcoin Cash which he writes about in his thesis [3].

[3] arctan.gtklocker.com/thesis.pdf

FlyClient [4] by @benediktbuenz utilizes @peterktodd's MMRs* [5] to succinctly commit to the chain history. Combined with probabilistic sampling** has better performance than NiPoPoWs and works for varying PoW difficulty.

[4] eprint.iacr.org/2019/226
[5] github.com/proofchains/py…

* We recently wrote a ZIP with @_prestwich and @therealyingtong to add MMRs in ZCash’s blockheaders. Full FlyClient ZIP soon?

https://twitter.com/zooko/status/1146456571322482689

**the light client repeatedly asks a full node about random parts of the chain history until they're convinced that the chain being shown to them is correct. This is made non interactive via the Fiat Shamir Heuristic

Short discussion on FlyClient vs NiPoPoWs:

https://twitter.com/socrates1024/status/1101333894270468096

@summa_one's stateless SPV proofs [6] can also be used for pegs, but are 'cryptoeconomic': the more work inside the provided headers the more confident you can be about the transaction being part of the heaviest chain

[6]

All PoW sidechain schemes assume that each chain is independently secure. That is a BIG assumption, as argued by Peter against Dionysis:

https://twitter.com/peterktodd/status/953619414523375616

.

Constructing PoW sidechains is also described in [7].

[7] eprint.iacr.org/2018/1048.pdf

TAKEAWAY:

The moment your bitcoins move to an output that is spendable based on an event that happens on a chain with less hashrate than the bitcoin chain, you’re exposing yourself to counterparty risk (the miners of the other chain, or the validators if PoS)

I like to think of crosschain assets as alloys.

BTC on the bitcoin chain is BTC-100. It is pure, inefficient, boring; but it is the most sovereign asset that has ever existed.

BTC-X would explore a different tradeoff space, as envisioned by the original @blockstream paper

Based on that thought, @ethereum’s or @binance’s WBTC would be BTC-X, where X is (cost of corrupting the federation) / (cost of attacking bitcoin). It’s easy to see how the fraction’s value could become 0 on regulatory pressure.

What if the receiving chain's consensus halts (i.e., no blocks are produced)? What if the miners refuse to include your locking transaction?

WORST CASE SCENARIO: YOU LOSE ALL YOUR MONEY

What is the point of gambling your BTC with WBTC in the #DeFi casino if you cannot cash out? It’s as if as the casino shut down with all your money inside. Remember Mt. Gox?

-- PoS sidechains --

In [8], Andrew Poelstra formalizes DMMS security, and argues that a properly implemented PoS with long/short-range attacks protection can be DMMS-like, but has different security from Bitcoin’s DMMS.

Maybe that’s BTC-99.99?

[8] download.wpsoftware.net/bitcoin/pos.pdf (my favorite PoS paper)

Since there’s no notion of “work”, can we construct a secure DMMS that can convince us that an asset was locked on another chain?

Dionysis' work [9], [10] covers this area extensively

[9] eprint.iacr.org/2018/1239.pdf
[10] docs.google.com/presentation/d…

-- Crosschain communication in practice (follow IBC for standardization) --

Deposit from sending PoW chain to receiving PoS chain:

1. Send asset to special output on sending chain
2. Validator listens for deposit *with a light client* and signs it
3. If 2/3rds of validators weighted by stake signed, the asset gets minted on the receiving chain

Withdraw from sending PoS chain to receiving PoW chain:
1. Burn on sending chain
2. Make withdrawal request to validators with proof of burn
3. Validators signs on the withdrawal request
4. Output on receiving chain gets unlocked if signatures with 2/3rds of stake are shown

I hope that I have convinced you that there is counterparty risk in moving assets from a PoW chain to a sidechain with less hashrate, or a PoS chain.

There may be feature tradeoffs which justify that move, but the extra risk must be part of your security model.

What makes Layer 2 special?

L2 security == L1 security

A L1 smart contract acts as an escrow.
Unlocking the assets relies on:
1. Playing a fixed duration game where honest players are guaranteed to win, OR
2. Cryptographically proving ownership with a ZKP.

In detail:

Fraud proofs:

Client side validation with an L1 smart contract as adjudicator. Withdrawal requests take time T, after which you can unlock the claimed asset. If another user comes online and submits a fraud proof, the request is cancelled. (add slashing for incentives).

Assumptions: user comes online, L1 is not congested

Example: Lightning Network, Plasma, State Channels

Validity Proofs:

- L1 smart contract stores hash of state.
- Aggregator gathers state updates, generates & submits ZKP.
- Update contract hash If proof is valid.
- Supports instant withdrawals
- Has no liveness assumption

Assumptions: fancy crypto doesn't break, data availability (sort of)

Examples: ZkRollup, StarkDEX, Loopring

The above was a quick summary of L2 techniques. The biggest issue with L2 that’s not state channels is the data availability problem, but that’s a separate discussion.

More about Fraud vs Validity Proofs in @StarkWareLtd's blog post:

medium.com/starkware/vali…

This was my longest thread! I hope I got my point across, and maybe you, dear reader, are now less confused.

I am considering doing “Drivechains & Statechains are not Layer 2” & “Plasma & Rollup is Layer 2” threads, let me know on your thoughts.

{fin}

ah *properties, @jack give us an edit button already ffs.