PoCo Series #10 — Moving towards layer 2, a Solidity Developer’s View
An Urgent Need for Scalability
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.
The iExec Sidechain
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:
- First, it suffers from the same drawbacks as xDai, with the consensus being controlled by a few whitelisted validators and not by a fully decentralized consensus like Ethereum’s PoW (and using PoW is not a solution here, since the small mining power dedicated to it would make 51% attacks easy).
- Second, and more importantly, being on a sidechain completely breaks the interoperability with other applications, which is arguably the biggest strength of the Ethereum ecosystem.
Both of these issues are addressed by rollups.
Rollups, what else?
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.
My experience with OptimismPBC
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:
- Initially, precompile were not available. In particular, it was not possible to run ecrecover. This has been fixed for me, and I am now able to perform the signature verifications I need. Still, if you are using some lesser-known precompiles, your first step should be to check their availability.
- For now, the OVM compiler is only available in version 0.5.16. Since most projects (and libraries) have moved to 0.6.x or even 0.7.x, you would either have to wait for a new OVM compiler or refactor your contracts to 0.5.16.
- Token deposits & withdraws, as well as generic message passing between the layers, is on the roadmap. This feature is essential to providing the “L2 experience” devs are looking for.
- I often rely on this create2 factory to deploy smart contracts at the same address on all networks. I just have to send the same bytecode with the same salt and the same contract will be deployed at the same address, regardless of the network or deployer’s nonce. Unfortunately, the difference of compiler between EVM and OVM means that the bytecode I’m used to deploying on EVM networks won’t work on OVM layer 2. I can recompile to target OVM, but this changes the bytecode and thus the resulting contract’s address.
That last point is minor to most developers, but it as some serious consequences, particularly for smart-contract based wallet providers.
Comment on the rollup-centric roadmap
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:
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.
- EOA are accounts with an address corresponding to the (end of the) hash of a public key and naturally derive from a private key. If you know the private key, you can derive the address, but can also sign messages and transactions. Since the private key to address function doesn’t depend on any chain-specific data, the same private key controls the same address on all networks. This is why your Metamask, Portis, Ledger, burner wallet (and many other) accounts are all compatible with both mainnet, testnet, and sidechains like xDai or iExec’s Bellecour. With optimistic rollups’ OVM uses the same cryptographic blocks as the EVM, all these wallets are therefore natively compatible with it.
- Smart-contract based wallet such as Gnosis, Argent, Authereum (and many more) have your assets stored not by an EOA, but by a smart contract. This allows for much more precise control over your assets since the smart-contract can implement any number of custom security policies, including multisignatures and social recovery. These smart-contracts are often controlled by signed messages (produced by EOAs) using meta-transaction relaying. The great thing is, if you lose your private key, or have it leaked, you might still be able to recover the funds using the smart contract features. This is not possible with EOAs.
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.
Going further with ENS & ENSLogin
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.
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.
Conclusion
- Sidechain are available right now, and offer good scalability, but have drawbacks;
- Rollups are an alternative with interesting security assumption;
- Zk-rollups are great if you are willing to make the effort of translating your app into a Zk-structure;
- Optimistic-rollups promise to be compatible with any ethereum apps and are moving to the testnet phase;
- Solidity developer should try out optimistic-rollups and be aware of some specificities that might affect certain parts of their applications;
- Wallets will have to adapt to this new paradigm, particularly smart-contracts based wallets like argent or gnosis;
- ENS might be moving to L2 soon, and ENSLogin it compatible with this shift.
Thanks for reading!
💡 Want to learn more about iExec? Check out iExec Academy!
iExec Academy aggregates all content related to the project. You’ll find articles, tech documentation, videos, interactive demos, and much more! Whether you are a beginner or an expert, a developer or crypto-enthusiast, you’ll find what you are looking for on iExec Academy!
