Scaling DeFi — Layer Two

Key takeaways

• There are solutions with different security / centralization / devex / performance trade-offs.
• Appropriate trade-off depend on application requirements.
• All solutions follow the same overall design.
• This design inherently creates walled gardens, with limited functionality.
• For DeFi we need highest security -- tremendous value at risk.
• Often forgotten: transaction ordering and censorship are high value targets in DeFi.
  • Even in Ethereum, the transaction ordering is imperfect and the residual transaction ordering has real economic value, as evident by Miner extractable Value. In our security model we consider this an attack.
  • equivalent in classical exchanges, see flash boys.
  • This value comes out of the traders pocket and is a major driver in the higher spreads.
• Key insight: Different guarantees have different security requirements.
• Key insight: Can use different solutions for different parts of the system.
  • Prioritize security for high value guarantees (i.e. ZKP for custody).
  • Prioritize devex/performance where value is less (i.e. staked side-chains)

Minor takeaways.

• Rollups don't solve the problem.

  • Rollups still scale linearly with the gas cost.
  • Ethereum calldata not meant for data availability.

• Optimistic proofs are difficult to make secure.

  • Watchtowers liveness (See MakerDAO auction)
  • Missing cases (See IDEX 50+ cases)
  • Ethereum availability (In times of crisis, gas cost may be prohibitive for fraud process)

• DeFi/DEX usecase requires account based approach (not utxo)

  • Privacy hard (impossible?) on account based.
  • DeFI hard (impossible?) on utxo.

• All scaling solutions have 'mass exit' problem in one form or the other.

  • In a mass exit, all state needs to be pushed to Ethereum L1.
  • Economic value of migrating state may not offset the cost of storing it on L1.

• Data availability vs. Proof of Publication.

  • Data availability requires Storage in Ethereum.
  • Calldata only provides proof-of-publication.

How do we get more milage?

The basic formula is as follows:

• Only store fingerprint of L2 balances on Ethereum
  • Use Merkle tree hashes.
  • Where are the balances stored?
• Process transactions somewhere
  • Process in batches and periodically send the new fingerprint
  • Batch size / delay tradeoff
  • How do we know this is done correctly?
• Problem: Deposits/withdrawals
  • Atomic interaction between Ethereum state and L2 state
  • Synchronization delays (up to weeks, depending on solution)
  • Data availability problem requires balance to be known.

All L2 solutions currently follow this pattern. The pattern has one major downside:

All L2 solutions are walled gardens with limited functionality.

Where are the balances stored?

• Data is stored on-chain (Rollup):
  • State, state-delta, or equivalent information published to Ethereum.
  • Typically stored in cheap calldata instead of storage!
  • Example: zkSync, Loopring?
• Data is on a side-chain:
  • State stored in a decentralized p2p consensus network.
  • Example: xDAI, 0xChain
• Data stored off-chain:
  • State stored on servers.
  • Example: StarkEx

The on-chain approach is the most secure, but it can only lead to linear scaling. It also makes undue assumptions on the availability of calldata. (In Ethereum, storage has data-availability guarantees, but calldata is only around as a curtesy by nodes. As Ethereum grows, it will make less sense to store all historical transaction data.

On Data Availability

There is a much discussed problem common to all scaling solutions that only shows up during catastrophic times.

In order to claim your funds in a catastrophic unwinding, you need to proof the funds that you held. For this you need some evidence that links it back to the latest state root. The evidence changes with each state root, so it is critically important that you always have access to the latest evidence. This is known as the data availability problem.

One approach to solving this is called rollups. Here information required to construct a proof of funds is submitted together with the batch to Ethereum. The

It is important to note that Ethereum itself does not guarantee data-availability on calldata. The Ethereum protocol requires miners to share all transaction data in the latest blocks, but not necessarily that of historical ones. Storing the

Fortunately for the network, full nodes provide this information altruistically as a service. There are also centralized services like etherscan that offer this free of charge. This currently requires 130 GB.

While there are proposals to limit

How do we know if transactions are processed correctly?

• On-chain
  • Batch verify
  • Potentially use aggregate signatures (SKALE)
• Side-chains
  • Example: Loom, PoA, xDAI, Parts of 0xChain
  • Security only as good as the consensus
• Proof protocols
  • Fraud proofs (AKA Optimistic)
    • State-channels
      • Example: Lightning, Raiden
    • Plasma
      • Example: Matic, OMG, OVM, Truebit
  • Succinct proofs (AKA Zero-Knowledge Proofs *)
    • Example: Loopring, Parts of 0xChain.

* The academic definition of a zero-knowledge has some additional requirements that are stronger than required for succinct proofs. For scaling purposes often simplifications are made that make the proof system no longer zero-knowledge.

The problem with optimistic proofs

It's like you DIY your own Airbag in your car. You won't know you forgot something until it is too late.

IDEX example. "no fewer than 50 fraud proofs."

Can not depend on watchtowers being vigilant: See MakerDAO auction.

Security is multifaceted

• Different kinds of security guarantees with different value.

The hybrid approach

https://www.reddit.com/r/ethtrader/comments/hfi1hs/ethereum_l2_scaling_techniques/