How Ethereum Layer 2 scaling solutions address barriers to enterprises building on Mainnet

Tas Dienes, EEA Mainnet Working Group

December 2020

If you’ve been following the buzz in the Ethereum ecosystem recently, you’ve probably heard about high transaction fees and the limited processing capacity of Mainnet. You may also have heard about Layer 2. Layer 2 is a set of technologies or systems that run on top of Ethereum (Layer 1), inherit security properties from Layer 1, and provide greater transaction processing capacity (throughput), lower transaction fees (operating cost), and faster transaction confirmations than Layer 1. Layer 2 scaling solutions are secured by Layer 1, but they enable blockchain applications to handle many more users or actions or data than Layer 1 could accommodate.

Layer 2 is a broad field in which many teams are researching and building different scaling solutions that are sometimes competitive and sometimes complementary. The major categories of L2 solutions are: state channels, side chains¹, plasma, optimistic rollups, zk-rollups, and validium. There are also some hybrid solutions that have properties of multiple categories. Each has its own set of strengths, weaknesses, and tradeoffs. Diving into how each type of L2 technology works and the nuances of its tradeoffs is beyond the scope of this article, but many others have written about them.^4,5,6,7

Most L2 solutions are centered around a server or cluster of servers, each of which may be referred to as a node, validator, operator, sequencer, block producer, or similar term. Depending on the implementation, these L2 nodes may be run by the businesses or entities that use them, or by a 3rd party operator, or by a large group of individuals (similar to Mainnet). Generally speaking, transactions are submitted to these L2 nodes instead of being submitted directly to L1; the L2 instance then batches them into groups before anchoring them to L1, after which they are secured by L1 and cannot be altered. The details of how this is done vary significantly between different L2 technologies and implementations.

Private vs Public Ethereum

Many businesses have been building applications on or experimenting with private blockchains, including private Enterprise Ethereum implementations, despite the fact that Ethereum Mainnet’s open and decentralized nature provides certain advantages such as stronger security/immutability, transparency, lower operating cost,³ and the ability to interoperate with all of the other applications that are also on the Mainnet (network effects). Sharing a common frame of reference avoids the unnecessary creation of numerous isolated silos which cannot communicate and share or synchronize information with each other.

These benefits are also available on L2, if desired (transparency is optional). Transactions on L2 are umpired and secured by L1, which still acts as a common frame of reference and ensures globally consistent transaction ordering and state management. Applications can interoperate easily within an L2 instance, and can transact across L2s via cross-chain messaging.

There are numerous reasons why enterprise developers and architects have chosen to build on private chains instead of public ones. In late 2019, John Wolpert of ConsenSys wrote a list of issues with the idea of using the Ethereum Mainnet in business.² Here we will take an expanded version of that list of issues or objections to building on Mainnet, and look at how Layer 2 scaling solutions can change the game for some applications.

Problems with Building on the Ethereum Mainnet	Impacts of Using a Layer 2 Solution
Scaling Problem: My application requires hundreds or thousands of transactions per second, which public chains can’t handle	This is exactly the problem L2 solutions are designed to address. Depending on the specific L2 technology and implementation, it may offer from 50x to over 1000x more throughput than L1. On the high end: state channels, plasma, validium, side chains, and certain hybrid solutions. On the lower end: zk-rollups and optimistic rollups.
Speed and Latency Problem: Our CRM and ERP systems don’t need the kind of Transaction Per Second speeds of a Visa or Mastercard (and even they get those TPS rates through parallelization…can’t fool me). But long wait times for round-trip + consensus makes things I might do with the Mainnet a bad user experience.	Some L2 solutions can provide “instant” transaction confirmations with an economic guarantee that your transaction will be included in the next L2 block. Sidechains can also offer shorter block times and faster finality within the sidechain (though the transactions are not anchored to L1). Finalizing L2 transactions on L1, to get the full benefits of L1 security, still depends on L1 block time. Whether you need to wait for L1 finality, L1 confirmation, or only for L2 confirmation will depend on the specifics of your application.
Finality Problem: Ethereum is an “eventual consistency” machine. If that’s changing with Eth2.0, I don’t understand it…something about a magical fast finality something. I dunno. What I do know is that all my systems are ones where a change to data is final the second it’s written.	L2 may make this a bit more complicated, because transactions may need to be finalized on both L2 and L1. At a minimum it’s the same level of complexity as L1. However, Ethereum 2.0 introduces finality via its new consensus algorithm, Casper FFG. After migration to Eth2, both L1 and L2 transactions can be considered finalized after some period of time.
Noisy Neighbor Problem: Other users and network activity must not disrupt my operations. As an enterprise conducting mission-critical operations that rely on predictable operation timing, I need to be comfortable that a “cryptokitty” event isn’t a possibility. I need to know that, even though the Mainnet is a public utility, there is reasonable assurance by some means that the reads, writes and computations I need to conduct business on the Mainnet will not be reduced to a crawl by the activities of others.	The degree to which “noisy neighbors” can disrupt your operations by consuming most of the L1 capacity depends on the type of L2 technology and how it is implemented. Some technologies such as plasma and validium write very little data to L1. Because of this, the L2 operator can pay higher gas prices if needed to ensure that their transactions are processed on L1 in a timely manner. These solutions are very resistant to “noisy neighbors”. Sidechains are also relatively immune to this problem because they do not depend on the L1 chain. But transferring tokens or data to/from the L1 chain is still subject to the capacity of L1. Rollup style L2 solutions are constrained by the available capacity of L1, and can suffer more from Mainnet congestion. The L1 gas cost to anchor these L2 transactions on L1 is still much lower than the cost to make these transactions directly on L1, so the operator may be able to pay higher transaction fees in order to ensure timely processing. These solutions are less resistant to noisy neighbors than the previously mentioned ones, but more resistant than applications running directly on L1. If enterprise applications are sharing an L2 instance with other applications, depending on the implementation, the L2 operator may be able to provide some amount of guaranteed throughput or an SLA with respect to that L2 instance. An application or company may also have its own L2 instance all to itself.
Private Data Problem: Eighty percent of our data is considered sensitive, internal or personally identifiable client, customer or user data. Encryption isn’t enough. Any data can be deanonymized and decrypted given time. And anyone with a full node has forever to crunch the bits on the ledger. So I don’t like putting even encrypted data on a public chain.	Certain L2 technologies (such as validium, side chains, and Arbitrum SCSC) are able to keep all L2 data within the L2 instance and off of L1. If multiple companies are writing data to the same shared L2 instance, they will be able to see each other’s data (like a consortium), but if a company has its own instance then the data can be kept private.
Security Issues: Encrypted data is still data. It is against our policy to store PII and client data, even encrypted, on peer to peer platforms.	While rollups write all transaction data to L1, other solutions do not. Some L2 solutions enable a company to run their own private L2 instance which keeps all L2 data to itself, on servers controlled by that company. Ultimately, the need to place sensitive data on a blockchain should be questioned, as there are design patterns which avoid using blockchains as databases and focus on leveraging their strengths, while keeping sensitive data off-chain.
Data Locality Problem: GDPR requires that I can account for where PII data is stored, even when it is encrypted. And I need to be able to delete that data permanently upon request. If the data is sitting permanently on any number of nodes not controlled by me everywhere…yeah.	With certain L2 solutions that do not write transaction data to L1, an L2 operator can provide a GDPR compliant L2 service which stores L2 data in a known location with the required level of security. Or a company can run its own private L2 instance and have complete control over the L2 data.
Responsible Party Problem: My legal structure requires that there be a responsible party handling all aspects of my data and business logic. If I put data on the Mainnet, I lose a key responsible party.	Some L2 solutions are run by an operator, who can offer and be held accountable for SLAs and security in traditional fashion.
Transaction Cost Problem: Ethereum gas prices have been going up. If I need to conduct millions of transactions, it’s going to be insanely expensive.	This is another problem that L2 was specifically designed to address. Because anchoring L2 transactions on L1 consumes much less gas than conducting the transactions directly on L1, L2 transaction cost is much lower. The exact savings depends on the L2 technology. L2s like state channels, plasma validium, and sidechains are the most economical, while L2s that store transaction data on L1, like rollups, offer less (but still substantial) savings.
Cost Unpredictability Problem: Gas prices go up and down. Crypto prices go up and down. It’s too hard to forecast how much my transactions will cost.	With certain L2 implementations, there is an operator who may charge a fixed/guaranteed price per transaction. Sidechain operators may offer flat rate pricing for variable durations of chain operation (3mo, 6mo, 12mo). Transactions within the chain would largely be gasless. Even under variable market-based pricing, L2 greatly reduces cost per transaction. Depending on the type of L2, L2 transaction costs may vary linearly as gas prices on L1 vary (rollups), or may be relatively decoupled because less data is stored on L1 (validium, plasma, etc.). Given lower overall cost, the implications of variability may be reduced.
Crypto Payment Problem: I have to hold crypto and pay for transactions in crypto. Getting my company’s treasury comfortable with buying and holding and paying in crypto is a nightmare.	If the L2 instance is run by a 3rd party operator, the operator may accept payment for L2 transactions in any form of currency they choose, including traditional fiat. This problem may also be addressed on L1 by transaction relayers (aka gas stations) who can accept payment in fiat or tokens and relay transactions to the L1 network.
Strategy Leaks Problem: Transaction metadata can be used to game the system or collect / analyze for strategic counterintelligence or corp. espionage. In the age of AI, any trace activity done on a permanent, public ledger can be used to figure out who is doing what, even if it’s just little changes to Merkle tries.	L2s based on certain technologies (such as validium, side chains, Arbitrum SCSC) are able to keep L2 transaction details contained within the L2 and off of L1. The L2 can then restrict access to authorized entities. If a company runs its own private L2 instance then the details of their transactions can be kept private (though there may be limited use cases for L2s that are used by only one entity). It is also possible to use an approach like Baseline, wherein transactions between entities are conducted privately, and only ZK proofs of correctness (gathered in batches) are submitted to either L1 or L2. An emerging technology called zkzk-rollup (e.g. Aztec 2.0) allows confidential transactions within the L2 so that others on the same L2 instance cannot decipher your transactions. Also under development are data privacy and custody protocols which rely on access rights management, distributed key generation, and trusted execution environments so as to keep data private except for while inside a TEE within the Layer 2.
Confidential Code Problem: You can’t just hide the data with something like ZK-SNARKS and think that everything is ok from a corporate perspective. Many business agreements are embodied in code… business logic. If a machine can execute a smart contract, it can decompile and look at the logic, and that can leak sensitive info.	Some L2s don’t support smart contracts and execution of code. If your transactions require code execution, it may be possible to use an approach like Baseline, wherein transactions between entities are conducted privately, and only ZK proofs of correctness are submitted to either L1 or L2. An emerging technology called zkzk-rollup (e.g. Aztec 2.0) allows confidential transactions within the L2 so that others on the same L2 instance cannot decipher your transactions.
Emotional: Bitcoin and Ethereum are for non-regulated/off book uses (i.e. criminal activity). I don’t want to be associated with that, and I’m afraid of what might happen if governments cracked down on public blockchains.	As public use of Ethereum grows, it becomes more difficult for any one government to censor or block the network. While there may be global efforts to remove or reduce use by criminal actors, it is unlikely to forestall the growth of decentralized computing and public networks. The advantages of shared protocols, digital currency/tokens, trustless and automated contract execution, along with other Web3 benefits are too powerful to stop. Running your applications on L2 can provide a degree of isolation from the public L1 blockchain. The L2 may be operated more like traditional business IT infrastructure with security and accountability, and act as a buffer between your business and unregulated activity, but still has L1 as an umpire, plus the benefits of immutability, interoperability, and the common frame of reference that L1 provides.

Conclusion

Layer 2 scaling solutions for Ethereum Mainnet have been under development for the last few years, and are now becoming ready to take on real applications. Building your application on a Layer 2 will help you achieve much higher throughput than running all your operations directly on Layer 1. And it will minimize transaction costs. Layer 2 can also help solve problems related to privacy, confidentiality of transactions, and data custodianship. And it can help avoid the need for businesses to deal with cryptocurrency tokens and price volatility when paying for transactions.

There are many L2 solutions, each with its own strengths and weaknesses and tradeoffs. It is advisable to think carefully about your application’s requirements and to study the available options before making a selection.

Examples of L2 solutions that are production ready or will be soon include:

Optimistic rollups (data on chain, fraud proofs)
ZK rollups (data on chain, ZK validity proofs)
Validium (data off chain, ZK validity proofs)
- Starkware
- Matter Labs zkPorter
Plasma (data off chain, fraud proofs)
State channels
- Connext
- Raiden
- Perun
Sidechains¹
- Skale
- POA Network
Hybrid solutions
- Offchain Labs Arbitrum SCSC – has properties of both sidechains and state channels, but falls back to optimistic rollup if validators misbehave.
- Celer – has tunable properties of sidechains and state channels and optimistic rollups

Notes and references

Thanks to John Wolpert, Ken Fromm, and Jack Leahy for their input on this article.