Ethereum Scaling Overview
While researching it, I thought it would helpful to surface a trying-to-be-complete picture on what are the major Ethereum scaling ideas currently. Keep in mind that many of them are being developed in parallel or are partially dependent on each other. Still others may change shape if better solutions come up in the blockchain ecosystem.
Proof of Stake / Casper
What: Generalised mining. Instead of burning electricity, miners (validators) lock some funds in a contract in exchange for a right to process transactions and get rewards. Also, time between blocks can be shorter; it leads to technical benefits for other scaling solutions.
How: In general, by carefully designing incentives for transaction validators. A special contract would keep track of a set of validators, they would lock some funds in hope of being rewarded for participation. In Casper, there are additionally penalties for misbehavior, i.e. others can submit proofs that a certain validator submitted an illegal block, which would lead to destruction of that validator’s ether.
Difficulties: Complexity related to making sure all cryptoeconomic pieces can work together to cover all security issues.
Code: https://github.com/ethereum/casper
Sources:
- https://medium.com/@jonchoi/ethereum-casper-101-7a851a4f1eb0
- https://ethresear.ch/t/latest-casper-basics-tear-it-apart/151
Raiden Network / State channels
What: An off-chain network for value transfer. You keep an open channel to a Raiden node and can transfer value to any other participant, cheaply and quickly. However, very large transfers are more difficult.
How: A channel is an on-chain construct that allows transferring up-to-X value gradually off-chain to another account, after locking X value by the sender. If any of the participants backs out during the process, the channel falls back to the blockchain and, after some time, each participant can recover the funds already on their side, by submitting proofs. This can be scaled by having a network of simultaneously open channels between many participants.
Difficulties: All nodes on the path of your transfer need to be able to handle the amount you are transferring, by locking at least as much value. This incentivises centralisation and existence of super-nodes; prevents very large transfers
Code: https://github.com/raiden-network/raiden
Sources:
- https://raiden.network/101.html
- https://raiden.network/faq.html
- Raiden Network — Basic Mechanics on YouTube
Plasma
What: Generalised Raiden/Lightning network for ‘virtual’ chains. A tree of blockchains within the blockchain.
How: Instead of building a Raiden-like network for value transfer, it could be possible to generalise it to a network for off-chain settlement of data of any kind. Then, on top, build a payment system and others as well. Plasma plans to implement it by using a proof of stake incentive system written in a contract, to manage a number of virtual sub-chains (having some resemblance to sharding, described below) composed in a tree.
Difficulties:
- Complexity of implementation
- Need of fallback to the main chain in case of an attack (from sharding FAQ)
Sources:
Stateless Client
What: Drastically reducing storage requirements for full nodes and, potentially in the future, for miners as well. This has benefits for adoption but also may be a path to other technical improvements.
How: With each new block, pack more information about data that is being accessed by transactions in it — then to execute those transactions, the node would not need “the whole world”, but just the data being actively used.
Difficulties: dynamic nature of contracts — ideally contracts would need to statically declare what other contracts or accounts they interact with.
Sources:
Sharding
What: Create many sub-chains, sharing security with the main chain. These would act as separate ‘galaxies’ (kind of like separate servers in many MMO games), but would allow different dapps to avoid sharing the same (limited) nodes’ resources with each other.
Transparent sharding potentially could take this a step further, allowing automatic ‘balancing’ of dapps between shards, based on popularity; it’s much more complex to implement.
How: Have special contracts keeping track of shard information. Have collators (validators) being randomly assigned for a limited time to a specific shard(s) to process transactions on them.
Difficulties:
- A bit inconvenient for end-users and developers (unless transparent sharding is used)
- Trade-offs related to security and storage requirements
Prerequisites:
- Proof of stake would reduce complexity related to handling collators
- Stateless client could make it easier for collators to handle different shards and be rotated quickly between them
Code: https://github.com/ethereum/sharding
Sources:
- https://github.com/ethereum/wiki/wiki/Sharding-FAQ
- https://ethresear.ch/t/future-compatibility-for-sharding/386
Other ideas
Contracts as Actors
What: (Note: just an idea, not actively worked on) Make inter-contract communication more like actor message passing from the Actor Model. Would allow nodes to execute multiple transactions in parallel.
How: Prohibit direct calls between contracts, have them asynchronously send messages to other contracts instead. This could potentially allow for easier parallelism of contract execution and removing some contract development security issues.
Difficulties: Backward compatibility, gas handling, library contracts, etc.
Sources:
