Why Rollups are the key to all of Bitcoins problems

History of Validity Rollups

• Satoshi Nakamoto's statement emphasizes the difficulty of preventing double-spending in a decentralized system without a central authority:

  • Each node needs to verify that each coin being spent has not already been spent in another transaction.

  • Simply hashing transaction points is not enough; the actual signatures must be checked to ensure authenticity and prevent fraud.

  • The concept of using zero-knowledge proofs to prove the absence of double-spending is theoretically complex and practically challenging because it requires verifying the non-existence of a transaction across the entire network.

  • Bitcoin currently solves these challenges by using a global public ledger (the blockchain) where every node maintains a copy of all transactions. This ensures that each node can independently verify the integrity of transactions and prevent double-spending by checking the entire transaction history.

• The fundamental problem scaling researchers set out to solve was: to remain free from the dangers of centralization, it had to be easy for any crypto user to run a full-node with even limited computational effort of verifying.

• They focused on 4 techniques:

  • Onchain Optimisation - reducing the footprint of resources required to store & process transactions

  • Network Optimisation - 2 techniques, reduce block propagation latency & bandwidth cost

  • Sharding - technique in which block processing & storage is split into 2+ nodes with shared security

  • Offchain Transaction Execution - protocols designed to offload the processing to a new layer off the base chain.

• The first practical need for scaling was observed in 2017 when Ethereum blockspace was congested due to rising demand of tokens & NFTs. A mixed approach was being taken with long-term approach arriving in the form of Sharding but in the meantime short-term solutions like sidechains & state-channels were implemented.

  • Sidechains had an issue of user having to give up self-custody and port assets on a company run chain risking the node decentralisation

  • State-channels had limitations like the inability to build for multiparty applications, and expensive capital lockups, and needed both parties of txn. to be online to receive updates

  • Plasma was another proposed solution (mix of above 2) but it had a “mass exit problem” primarily caused by the lack of data-availability, non-turing completeness.

• In 2019 Ethereum developers began thinking about how to solve both the data availability problem and the EVM compatibility problem, this category of protocols that put minimal data onchain while keeping transaction execution offchain came to be known as a "rollup”

• Rollups were categorised into 2 variants:

  • Optimistic

  • ZK or Validity

Intro to Validity Rollups

• A rollup is a blockchain that stores

  • State root

  • Enough txn. data to recompute the current state from genesis

• It’s different from state channels, sidechains & validia chains as they store max txn. data offchain

• Validity rollups are so-called because of “validity-proofs”. Understand how they work with an example

• The security of a rollup is strongly dependent on its relationship to its parent chain. This relationship gives a rollup its two key features that other "offchain" protocols lack:

  1. inherited double-spend security

  2. secure two-way bridge.

Validity rollup UX

How to create a rollup

• A protocol is implemented on parent chain with defined rules like-

  • Consensus rules

  • How to verify rollup blocks using the above rules

  • How rollup block producers are selected in multiple competing producers

  • Protocol for moving assets from L1 → L2 → L1

• This entire protocol is implemented as a smart contract deployed on the L1 chain (needs to have programmability)

• Most rollups currently have 1 centralized block producer and this is accepted because if it halts production, users can still confirm txn on L1 to exit the rollup.

How it works

1. With each rollup block that gets produced, the rollup transaction data is stored in a state update transaction on the parent chain along with a cryptographic proof of the validity of the rollup block

2. Once the state update transaction is confirmed on the parent chain, the rollup block is considered confirmed by rollup full nodes and is added to the rollup chain tip

3. In order to re-organize a rollup block that has been confirmed on the parent chain, the parent chain block that the rollup block was confirmed in would have to be re-organized too. This gives rollups their inherited double-spend security feature.

Using a validity rollup

• A user can either

  • Transfer assets from L1 to L2 or

  • Transfer assets from L2 to L2

• There is no need for a new rollup user to establish inbound liquidity similar to using state channels like lightning