Scaling a blockchain
Solving the blockchain trilemma
Three desirable properties of any blockchain are:
decentralization: not controlled by a single authority
security: resistant to attacks from malicious entities
scalability: support more and more transactions per second
The blockchain trilemma states that a simple blockchain architecture can only achieve two out of three. Want a secure and decentralized blockchain? You need to sacrifice scalability.
Most blockchains, including Bitcoin and Ethereum, are decentralized and secure, but do not scale. However, a variety of solutions have been proposed to increase scalability of the chains without sacrificing (too much of) the decentralization and security properties. In the following, we will cover the main scalability solutions for the Ethereum blockchain.
The rest of the contents in this insight are largely taken from:
Scaling
The main goal of scalability is to increase transaction speed (speed of finality of a transaction) and transaction throughput (number of transactions per second), without sacrificing decentralization or security.
On Ethereum blockchain, high demand leads to slower transactions and nonviable gas prices. Increasing the network capacity in terms of speed and throughput is fundamental to the meaningful and mass adoption of Ethereum.
While speed and throughput are important, it is essential that scaling solutions enabling these goals remain decentralized and secure. Keeping the barrier to entry low for node operators is critical in preventing a progression towards centralized and insecure computing power.
On-chain scaling
On-chain scaling requires changes to the Ethereum protocol (the so called layer 1). Sharding is the main on-chain scaling solution.
Sharding is the process of splitting a database. Subsets of validators would be responsible for individual shards rather than keeping track of all of Ethereum.
Sharding was on the Ethereum roadmap for a long time, and was once intended to be shipped before the merge to proof-of-stake. However, the rapid development of layer 2 rollups (off-chain scaling) has led the Ethereum community to favor rollup-centric scaling instead of scaling by sharding.
Off-chain scaling
Off-chain solutions are implemented separately from layer 1 - they require no changes to the existing Ethereum protocol.
In the following, we will briefly review rollups, which are currently the preferred off-chain solution for scaling Ethereum. See the scaling page of Ethereum foundation for information about the other solutions or watch the following Finematics video.
Rollups
The idea under rollups is to outsource computation from layer 1 to another entity called layer 2 while maintaining verifiable results.
The whole process essentially executes transactions on a side chain (layer 2), separated from the main chain (layer 1), takes the output data, compresses it and rolls it up to the main chain in a single batch, hence the name – a rollup.
How does Ethereum know that the posted data is valid and was not submitted by a bad actor trying to benefit themselves?
The exact answer depends on a specific rollup implementation, but in general, each rollup deploys a set of smart contracts on layer 1 that are responsible for verifying proofs of computation.
Proofs are also where the main distinction between different types of rollups comes into play:
Optimistic rollups use fraud proofs
Zero-knowledge rollups use validity proofs
Let's explore these two types of rollups further.
Optimistic rollups
Optimistic rollups post data to layer 1 and assume it is correct hence the name optimistic. If the posted data, representing the output of the off-chain execution of a batch of transactions, is valid we are on the happy path and nothing else has to be done. The optimistic rollup benefits from not having to do any additional work in the optimistic scenario.
In case of an invalid transaction, the system has to be able to identify it, recover the correct state and penalize the party that submits such a transaction. To achieve this, optimistic rollups implement a dispute resolution system that is able to verify fraud proofs, detect fraudulent transactions and disincentivize bad actors from submitting other invalid transactions or fraud proofs.
In most of the optimistic rollup implementations, the party that is able to submit batches of transactions to layer 1 has to provide a bond, usually in the form of ETH. Any other network participant can submit a fraud proof if they spot an incorrect transaction.
After a fraud proof is submitted, the system enters the dispute resolution mode. In this mode, the suspicious transaction is executed again this time on the main Ethereum chain. If the execution proves that the transaction was indeed fraudulent, the party that submitted this transaction is punished, usually by having their bonded ETH slashed.
To prevent the bad actors from spamming the network with incorrect fraud proofs, also the parties wishing to submit fraud proofs usually also have to provide a bond that can be subject to slashing.
Optimism and Arbitrum are currently the most popular implementations when it comes to optimistic rollups.
Zero-knowledge rollups
When it comes to zero-knowledge rollups (ZK rollups), there is no dispute resolution at all. This is possible by leveraging a clever piece of cryptography called zero-knowledge proofs.
In this model, every batch posted to layer 1 includes a cryptographic proof called validity proof. Validity proofs allow parties to prove the correctness of a statement without revealing the statement itself — hence, with zero additional knowledge.
ZK rollups use validity proofs to confirm the correctness of off-chain state transitions without having to re-execute transactions on Ethereum. These proofs can come in the form of non-interactive ZK proof solutions like ZK-SNARK or ZK-STARK.
Loopring, a non-custodial exchange and payment protocol, uses ZK rollup technology to scale its exchange and payment protocol.
A comparison of rollups
Withdraw delay. Due to the nature of the dispute resolution process, optimistic rollups have to give enough time to all the network participants to submit the fraud proofs before finalizing a transaction on layer 1. This causes the withdrawals from optimistic rollups to be quite long as the users have to wait even as much as a week or two to be able to withdraw their funds back to layer 1. ZK rollups don’t have the problem of long withdrawals as the funds are available for withdrawals as soon as the rollup batch, together with a validity proof, is submitted to layer 1.
Ethereum compatibility. Due to the complexity of the technology, it is much harder to create an EVM-compatible ZK rollup, which makes it more difficult to scale general-purpose applications without having to rewrite the application logic. Optimistic rollups have a little bit of an easier time with the EVM compatibility. They still have to run their own version of the EVM with a few modifications, but most of contracts can be ported without making any changes.
Computational complexity. ZK rollups are also way more computation-heavy than optimistic rollups. This means that nodes that compute ZK proofs have to be high-specific machines, making it hard for other users to run them, hence increasing the risk of centralization.
Last updated
