Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
I have been interested in blockchain scalability for a long time. Call me cheap, but I remember times when 10gwei/gas was too much for me. I would pay 2gwei/gas for some of my less-urgent transactions, such as when I configured my ENS domains.
People in this space have long been waiting for adoption, meaning widespread and mainstream adoption of blockchain technology. Giving wallets to the bankless, building auditable decentralized supply chains, reinventing liquid democracy through DAOs… We all have our dreams, and blockchain scalability is essential if we want to turn them into a reality.
Many solutions have been discussed, noticeably with state channels and plasma chains. They promised increased throughput by multiple orders of magnitude, with almost no added security assumption. However, the complexity of these solutions, particularly plasma, and the drawbacks associated (many plasma flavors dropped the account model of EVM in favor of a UTXO model) prevented them from being used in large scale applications.
POA sidechains such as xDai have been in production for a long time, and while they do not offer the security model of plasma and state channel (remember, sidechains are not layer 2) they are very easy to work with.
The initial security concerns about their centralization of consensus have limited sidechain adoption by large dapps. However, the desperate need for scalability has recently made people reconsider this solution, and dapps such as POAP are now moving to these much cheaper EVM chains.
At iExec we realized very early that gas cost may be an issue. When designing iExec, we chose to build the most powerful, secure, and feature-rich protocol possible, leaving a lot of room to grow. This comes at a cost since the security mechanisms (which can be configured) increase gas usage even in cases where they are not necessary.
In addition to the iExec protocol itself, it was also clear that the blockchain applications that would benefit from iExec’s power are also going to struggle from the limited scalability of Ethereum and the gas costs inflation that comes with it.
This is why iExec V4 introduced Bellecour, our sidechain. The first block was produced on September 25th 2019, and we have been using it for low latency (5 secs between block), cheap (0 gas fees) transactions. This sidechain is a scalability solution, even if not perfect.
While it is a great solution for Cloud and Enterprise use-cases, sidechains have 2 majors issues:
Both of these issues are addressed by rollups.
Fortunately, past developments are now turning into real scalability solutions. Their philosophy is to provide a runtime similar to the EVM (in particular where anyone can enter or leave at any time) with no additional security assumptions than those inherent to the L1. The most promising solutions follow a logic called “rollups”, that comes in two different flavors: Optimistic and ZK.
Optimistic rollups (OR) provides an EVM-like environment that promises to be compatible with most if not all of the ethereum tooling. However, unlike sidechains, the optimistic chain relies on a merged consensus, which attests the optimistic chain’s state on the layer 1 (parent chain) where it can be disputed.
The resolution of the dispute is achieved by replaying the OR transactions on the layer 1, which is only possible because the OVM (optimistic virtual machine) is very similar to the EVM. This checkpoint & dispute resolution mechanisms subjugate the OR to the L1 consensus while providing a channel for cross-chain communication (necessary to handle tokens transfers).
ZK rollups rely on zero-knowledge structures to handle the L2 transactions. Thanks to the ZK construction, transactions proofs can be produced that can easily be checked, even on L1, by a dedicated circuit. This cryptographic proof of transaction ensures that whatever state is accepted by the parent chain is valid. No dispute mechanism is needed.
While ZK rollups have more to offer than Optimistic, it is a much bigger jump. Some apps have gone their way to design a ZK structure with the features they need, but we don’t yet have a fully EVM compatible ZK rollup chain where developers can deploy their smart contracts and use the same tolling they are used to, just like if it was an EVM chain.
Optimistic rollups, on the other hand, have made amazing progress lately. From the UniPig demo back in Devcon 5, the OptimismPBC team is now moving to a full-scale testnet.
Light at the end of the tunnel
I’ve started experimenting with OptimismPBC just after EthCC 2020. The initial goal was simple, learn to use their toolkit and evaluate the possibility of moving the iExec stack to a rollup chain. Most of the experience was smooth, but here are some blockers I noticed, that might be useful to other developers:
That last point is minor to most developers, but it as some serious consequences, particularly for smart-contract based wallet providers.
It is now obvious that dapps need to scale before eth2 phase 2 goes live, and the coincidence is that rollups are becoming the de-facto solution for scaling just when phase 0 is around the corner.
Add the complexity of cross-shard communication, that is likely to break the composability of dapps as we see it used in today’s DeFi, and you’ve got a perfect storm that is likely to change the future of ethereum. Eth2, and the sharding it brings, turns out to be much more useful as a data availability layer for rollups chains (possible at phase 1) then as a sharded runtime (not before phase 2). This is discussed by Vitalik in one of its latest posts:
A rollup-centric ethereum roadmap
One of the points raised is that of wallet compatibility with rollups. While I have no experience with the zero-knowledge primitives used by zk-rollups, I won’t comment on the wallet for zk-rollups issue. What I have experience with, however, are EVM wallets, and particularly smart contract-based ones.
Wallets on today’s ethereum fall into two categories: EOAs and smart-contract based.
The issue with smart contract based wallets is that if you want to use them on multiple networks, you have to deploy them on multiple networks, and if you want to have the same address on all networks (like for an EOA) you have to be very careful about how you deploy them.
In my opinion, the best solution is to deploy the wallets using create2, in a way that a smart contract deployed on one chain can easily be deployed with the same initial settings on another chain, and have the resulting address closely tied to the settings used. This is something I implemented in NFWallets.
However, we saw that optimistic chains use a different compiler, which produces different bytecode, and that consequently, you cannot achieve the same address on an EVM and an OVM chain since you have to deploy different bytecode. I don’t think there is any solution to this problem that are available today, but this will have to be solved if we want the smart-contract wallets trend to stay, and if we want to have the amazing UX of wallets such as argent to be available across layers.
As discussed in yet another Vitalik’s post, an immediate use-case for rollups is the scaling of ENS (ethereum name service). Claiming, configuring, and keeping an ens entry up to date became unsustainably expensive. Fortunately, resolving a name is a read-only operation that is mainly performed by wallets and other off-chain apps, and if no smart contract (outside the ens framework) does on-chain resolution, then you actually don’t need the ens data to be stored on mainnet.
A general-purpose L2-friendly ENS standard
ENSLogin uses this design to improve testing: ENS entries stored on testnet are used to retrieve metadata which is valid across blockchain and can be used to instantiate mainnet wallets. Of course, synchronisation between ENS records on different chains is an issue that must carefully be addressed. This feature was designed to improve the ENSLogin modules testing workflow and it wasn’t originally considered as a long term solution. It is however a use-case that can greatly benefit from ENS moving to L2.
Thanks for reading!
Telegram • Twitter •Youtube •Github • Technical Documentation
