The Case for Application-Specific Blockchains @ CESC

application_specific_blockchains.md

The Case for Application-Specific Blockchains

Loi Luu, Kyber Network

Why Loi Luu is a badass

• Designed Elastico, first peer-reviewed sharding protocol for public blockchain
  • Inspired Zilliqa
• Created Oyente, first open-source smart contract verifier
  • Used by Melonport, Quantstamp, Augur
• Co-founder at Kyber Network
  • On-chain liquidity protocol for token swaps

Kyber Network

• Decentralized on-chain token swap
  • Integrated with major wallets
• Enabling decentralized payments: pay in any ERC20
• Providing liquidity of decentralized financial apps/protocols
  • Melonport, Set Protocol, etc.

Kyber scalability

• Has been live for more than 6 months
• Major feedback:
  • Fees are unpredictable
  • Long confirmation times
• Scalability should not come at the cost of cross-platform integrations
  • Most integrations so far are done on-chain to guarantee transparency and avoid the compromise of trust

TPS is not everything

• Results in a myopic view of what it means to be scalable
• Scalability requires:
  • Low tranaction fees
  • Low latency
  • Easy to run and execute complex transactions

Layer 1 scaling is not an ultimate solution

• Lots of data to transfer and store
  • Core constraint: data grows as the network grows
• Eventually only a few will be able to run full nodes
  • It's already very hard to sync Ethereum nodes from scratch
• Have to resort to sharding or layer 2 solutions to improve the situation

Sharding

• Promising because it allows scalability without increasing resources from nodes
  • Each shard manages its own chain that keeps a fraction of the state
• Main limitation is cross-shard communication
  • This is hard, because the need to communicate potentially cancels all scaling efficiencies
    • Data is distributed in different places
    • No direct way to get access to data on a different shards
    • May require many transactions for what is done in one transaction today
• Example: cross-shard locking costs at least 3 transactions in a sharded blockchain, whereas in current Ethereum it's only 1

Plasma

• Nice because it allows you to move transactions to a sidechain
• Challenges:
  • Data availability
  • Mass exit
• Existing solutions: make more assumptions
  • Plasma => Plasma Cash => PlasmaXT
• Main limitation: the primary scale up Plasma is to add more layers
  • Each layer works as a separate blockchain
  • This will add complexity to security and interoperability here
• Many Plasma chains on the same root chain are also hard to interoperate
  • Primarily well-suited for standalone ecosystems

State channels

• Inspired by payment channels, to do more transactions off-chain
• Harder to generalize
  • State channels for complex applications are very difficult
• Main limitations:
  • State encoding is hard and can become large, even more expensive than the value at stake
  • Availability guarantees
  • Suitable for turn-based games or applications

Key Challenges to Scale General Purpose Blockchains

• Cannot make assumptions about the execution of specific applications
  • Has to be a generic protocol to handle all possible outcomes
• Most proposed scalability solutions are initially demonstrated with specific use cases
  • I.e., payment channels to state channels
  • Later becomes much harder to generalize the solution
• Is it even feasible to build a general scalability solution?
• Should we even focus on looking for one?

Revisiting the Scalability Trilemma

• Scalability, decentralization, security: choose 2
  • EOS trades off decentralization (only 21 BPs)
  • Plasma trades off security (users have to monitor Plasma chain for fraud)
• We believe this trilemma is too generic
  • This framework is only applicable to blockchains that do everything
• It should be possible to scale up and achieve better performance by becoming more application-specific!
  • CPU < GPU < FPGA < ASIC

Scalability Quadrilemma (really?)

• Scalability, decentralization, security, genericity: choose 3
• We can build scalable blockchains as long as the chain focuses on specific applications vs being general-purpose

Proposal: Application Specific Sharding (Project Gormos)

• Many applications have multiple components which don't talk to each other much
• Put each component in a separate shard
• Number of cross-shard communications should be much less than intra-shard communications
• Can be implemented at layer 1 or layer 2
• Several applications benefit from these designs:
  • Sharded decentralized exchange:
    • Many shards, but each shard trades certain pairs
      • Shard 1: ETH <> OMG
      • Shard 2: ETH <> ZEC
      • Shard 3: ETH <> SPANK
  • Decentralized sharing economy
    • Shard 1: US (West)
    • Shard 2: US (East)
    • Shard 3: Singapore

Conclusion

• Scaling general purpose blockchains might not be that feasible
• Developers should start looking for scalability solutions that work for their specific purpose
  • Rather than trying to generalize everything
• Application-specific sharding schemes are a good idea!