PoCo Series #10 — Moving towards layer 2, a Solidity Developer’s View

Hadrien Croubois
Oct 8, 2020 · 9 min read

An Urgent Need for Scalability

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.

Please, please, please, stop saying that xDai is layer 2

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

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?

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

  • 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.
One year ago I presented my (first gen) create2 factory at Devcon 5. Unfortunately, the optimistic compiler, and the produced bytecode, breaks the assumption about deployment reproducibility.

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

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.

NFWallet uses create2 to ensure a wallet can be deployed on all blockchains at the same address.

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

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.


  • 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! Follow iExec:

WebsiteSlackTelegramTwitterYoutubeGithubTechnical Documentation


Blockchain-based Decentralized Cloud

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store