|If you find WORDS helpful, Bitcoin donations are unnecessary but appreciated. Our goal is to spread and preserve Bitcoin writings for future generations. Read more.||Make a Donation|
Posted July 4, 2019
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  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
 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 .
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 –
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 .
 arctan.gtklocker.com/thesis.pdf FlyClient  by @benediktbuenz utilizes @peterktodd ‘s MMRs*  to succinctly commit to the chain history. Combined with probabilistic sampling** has better performance than NiPoPoWs and works for varying PoW difficulty.
 eprint.iacr.org/2019/226 proofchains/python-proofmarshal Contribute to proofchains/python-proofmarshal development by creating an account on GitHub. https://github.com/proofchains/python-proofmarshal/blob/master/proofmarshal/mmr.py
**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:
@summa_one’s stateless SPV proofs  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
All PoW sidechain schemes assume that each chain is independently secure. That is a BIG assumption, as argued by Peter against Dionysis: .
Constructing PoW sidechains is also described in .
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 , 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?
 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 ,  covers this area extensively
– Crosschain communication in practice (follow IBC for standardization) –
Deposit from sending PoW chain to receiving PoS chain:
- Send asset to special output on sending chain
- Validator listens for deposit with a light client and signs it
- 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:
- Burn on sending chain
- Make withdrawal request to validators with proof of burn
- Validators signs on the withdrawal request
- 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:
- Playing a fixed duration game where honest players are guaranteed to win, OR
- 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
- 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: Validity Proofs vs. Fraud Proofs - StarkWare - Medium Validity Proofs and Fraud proofs are both used in different L2 scalability solutions. In this post we analyze and compare them. https://medium.com/starkware/validity-proofs-vs-fraud-proofs-4ef8b4d3d87a
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.