Rollups and other “Layer 2” (L2) technologies aim to solve the state and gas cost issues on Ethereum. For the non-developer: Layer 2 technologies aim to dramatically reduce the cost and time of transactions on Ethereum.
For those not deeply familiar with these projects and their associated tech, it’s extremely difficult—if not impossible—to decide which is best and safest to use for their application’s needs.
This article proposes a framework to assist an Ethereum user in the analysis of Layer 2 projects. Specifically, it’s meant for readers who are vaguely familiar with Layer 2 but might feel out of depth diving into technical details. This framework will help you develop a mental model for analyzing Layer 2 solutions.
It’s also going to kick-off a series of articles in which we apply these series of questions to current L2 projects, which are rapidly gaining adoption (L2BEAT is tracking $1.16B locked in various rollups) as users seek to swap tokens with lower gas fees. This first article may seem a bit light in detail but we’re hoping to simply map out the overall framework. In later articles, we will build out the framework more based on examples of L2 projects in production.
Questions to Ask
When buying a car, there are a few things you should ask about every vehicle that interests you. What’s the mileage? Has it been in an accident? Is it gas, electric, or hybrid? How much space does it have? The answers to these questions may not lead you to a clear decision right away. Instead, they’re meant to help you (not an automotive engineer) get a sense for the car and how well it meets your needs.
In the same way, we’re going to walk through four questions to ask yourself when looking at a Layer 2 project. It’s not a strict grading process, mind you. It’s more to build a mental model about a project, how it might help and, most importantly, how it may fail. A way to kick the tires before taking it for a ride, so to speak.
Here are the four questions to ask about an L2 project:
Who operates it?
How’s the data?
What’s the stack like?
How does it prepare for the worst?
Who Operates It?
Miner nodes on mainnet Ethereum move or “operate” the network forward by solving Proof of Work and creating new blocks. Those blocks can then be strung together in sequential order to illustrate network activity (like a zoopraxiscope).
One of the ways L2 solutions increase transaction throughput is to condense network activity into a single mainnet block. This network activity, if done on mainnet, would span a larger number of blocks, cost high fees and take significant time. The L2 conducts that activity on its network and then summarizes it in a single mainnet block.
So the L2 solution requires a similar “operator” role on its network, which is the miner-equivalent of Ethereum mainnet that can move the L2 network forward. There are a few differences, however. For example, along with processing and authorizing transactions like a miner, an L2 operator may also facilitate users entering and exiting the L2 layer itself.
Here are some questions to help you figure out more about the operators of the L2:
Who or what is required to operate the L2 network?
If they exist, how do they become operators in the L2 network? What rules do they abide by?
What trust assumptions must the L2 users make about the operator?
What are the operators responsible for? What power do they have?
What are the motivations to become an operator of this L2?
The overall element we’re trying to suss out here is trust. Specifically, how much does a user need to trust an operator? On mainnet Ethereum, the answer is “not much.” Our mainnet node will check the validity of every new block from a miner. On an L2, we trade away some of that minimal trust to gain benefits of speed and / or cost.
The above questions are meant to find out exactly how much trust a user is giving away in an L2. Once we’re clear on that, we will have a better sense of the risk exposure created by the operator(s) in the L2.
How’s the Data?
The next broad area we’re going to check out is data. By definition, a Layer 2 technology must create incremental data checkpoints on a Layer 1 (Ethereum mainnet). The checkpoints are similar to a puppy tromping out into the world, smelling things, nibbling on grass or playing with new friends. But the puppy will always, at some point, need to check back with its mother either for reassurance or sustenance. It’s the same with a Layer 2 technology. Separate from mainnet, it will conduct its own activity and generate its own network data. However, it will regularly check back in and reconcile its data with mainnet.
Our concern, then, is with the interstitial time between those periodic Layer 1 check-ins. Specifically, how is Layer 2 data generated, stored and stewarded while away from the safe harbor of Layer 1? We are most concerned with this because it is when the user is furthest from the trustless security of a public mainnet. Again, we need to clearly see where trust trade-offs are occurring to best gauge our risk exposure.
Our unit of data measure here will be transactions. Just like with Ethereum mainnet, all Layer 2 network activity boils down to the transactions a user submits. Specifically, we want to know how transactions are recorded by the Layer 2 operator and how the details of our transactions are ultimately reflected on mainnet.
Table stakes for conducting transactions on a Layer 2 network is typically a “lock-up.” The lock-up refers to the first transaction submitted on Layer 1 by someone wanting to use the Layer 2 network. The lock-up represents the total funds the user would like to have initially available to them on the Layer 2. It is the user “entering” the L2 network, a handshake between the user and the L2 network on the last L1 state they agree on. It also represents the conditions under which a user can “exit” the L2 network. Because of the extra parameters and logic required to capture all this, lock-up mechanisms are encoded to smart contracts on Layer 1.
Now, there is an important exception here. Effective Layer 2 solutions provide minimal gas and time costs for transactions. This is ideal for onboarding customers, particularly non-technical ones. Sometimes they might not even know they’re on an L2 or perhaps on a blockchain network at all! In this case, they would not be making an initial lock-up on Layer 1. However, they may, at some point, wish to exit a L2 back to mainnet.
For example, the popular NFT auction site OpenSea announced an integration with an L2 solution to reduce gas costs for its users. This means a user could purchase an NFT on OpenSea’s Layer 2 solution without realizing they’re on an L2. Only when that user wishes to leave the OpenSea platform with their NFT, perhaps to resell it, would the L2 arrange for an exit.
It may seem niche, but it’s incredibly important. NBA TopShot users have complained about not being able to withdraw their (sometimes substantial) balances from the L2 platform.
What are the lock-up conditions for the L2?
How soon are those funds available on the L2?
How does the L2 provide for users entering without a L1 lock-up?
Once a user has submitted their lock-up transaction and entered the L2 network, they’re able to submit transactions within that L2 network. Now we need to know how their subsequent L2 transactions are recorded. This recording is particularly important if you’d like to dispute a transaction that occurs on an L2. How would you prove a series of L2 transactions are valid or invalid? Some L2s use a series of cryptographic signatures that can be used on the Layer 1 lock-up contract. Others might use economic incentives to have multiple L2 Operators guard each other. Whatever the solution, these decisions underpin the integrity of any activity on the L2.
How would a user dispute an invalid L2 transaction? Prove a valid L2 transaction?
The mechanism to exit an L2 system is another major point of analysis. We need to know how soon the funds that are “locked up” on Layer 1 (plus or minus the L2 activity that was conducted after the lock-up) will be available. Some of these issues will be answered with the above questions about transaction disputes. But what if there’s a mass exit of users, how does the L2 system prepare for that? This is a critical pain point for L2 solutions.
How does the L2 system prepare for mass exit of users?
The other interesting possibility is the availability of Layer 1 liquidity providers to reduce wait times when exiting a L2. These would be parties who, confident in the L2 exit mechanism, will advance you the L1 funds (redeemable immediately) in exchange for the locked-up funds. And a fee of course!
Once an L2 user wishes to exit, how soon are the locked-up Layer 1 funds (plus or minus any L2 gains or losses) available back on L1?
Are there Liquidity Providers on Layer 1 willing to provide immediately redeemable L1 funds?
What’s the Stack Like?
In software parlance, “stack” references to the different pieces of software comprising a project. It can be a broad term. As a non-software example, the stack of a desktop computer includes how much RAM and storage a computer has as well as peripherals such as the mouse, monitor or printer. In Ethereum, the stack encompasses everything from the way nodes execute code in a deployed smart contract to the rules governing miners.
Just writing that sentence I could imagine some readers’ eyes glazing over. Have no fear! Since this guide is meant to be less technical, you don’t need to know the specifics about any given stack belonging either to Ethereum or Layer 2 solution. We want to know about certain characteristics of the stack. Specifically:
How much does a Layer 2’s stack share with the Ethereum stack?
This is important for two reasons. First, the Ethereum stack has been running for some years now and has not only survived but thrived. Network growth, as evidenced by high gas fees, is frequently cited as a problem (which it is) but it’s also a testament to the integrity of the Ethereum stack. Network growth stress tests the technology of the network. It breaks weak elements and highlights strong ones. Therefore, any piece of Ethereum a Layer 2 borrows means it’s battle-tested. It definitely matters what part and how it’s used, but it’s a good initial sign.
The second benefit of shared elements is the developer network effects a Layer 2 receives. There are a lot of tools for developers working on Ethereum. If an L2 adopts Solidity as its smart contract language, for example, it inherits all the Solidity developer tooling and community. If the L2 borrows some cryptographic primitive from Ethereum, say Proof of Stake, they benefit from the ongoing research and troubleshooting by the Ethereum core developers.
To be clear, using a different stack from Ethereum mainnet is not bad. In fact, when done well, it’s very good! There’s enormous strength in the diversity of tools used. Layer 2 innovation can also provide great value to Layer 1 by testing new ideas. Zero-knowledge proofs are a great example of this phenomena. Even though they have been around since the 1980s, work like that being done by Ethereum developers has dramatically grown the field. Yet using new, cutting-edge technology always poses significant risks, especially since there has been little testing of it in the wild
The comparison of stack is important to highlight what a Layer 2 has or has not changed from Ethereum mainnet. Remember, we’re trying to ask questions to help us isolate and identify the trade-offs Layer 2s are making.
How Does It Prepare for the Worst?
This question is broad but the explanation will be short.
When learning outdoor safety skills, experts teach students to assess danger by asking the question, “What will kill me in this situation?” It’s dramatic, but it’s very clear. In a dynamic environment full of potentially confusing variables, it’s critical to be able to clearly identify points of failure and potential danger. From there, you can work backwards to protect yourself.
The benefits of Layer 2 solutions should be obvious. If they’re not, we wouldn’t be looking into them. It is more important to understand how a certain Layer 2 solution will fail. The previous three questions are the ways in which we hope to discover these weak points. This last question is the way we analyze how an L2 addresses those weak points.
Here is a small sampling of generic L2 “worst-case scenarios”:
How does an L2 prepare for:
A mass exit of users due to suspected fraud by an L2 participant?
L2 participants attempting to game the L2 consensus. For example, by forming a cartel?
A bug or exploit discovered in a critical part of its system?
We hope such worst case scenarios never occur, of course. But it would be naive to dismiss them out of hand. And it would be downright reckless to not have countermeasures in place.
Conclusion
Those are the four questions! Take them to any L2 solution and we guarantee they will enhance your understanding of it.
However, these questions are not exhaustive nor comprehensive. We haven’t mentioned network costs or user costs, for example. Rather, we hope these questions help develop an intuition for the benefits and trade-offs of different L2 solutions, such as being able to locate the failure points or appreciating an elegant solution.
We’re not the Kelly Blue Book, but in the next installment, we would like to analyze a few Layer 2 projects using these questions. We hope to help illustrate the ways in which you, the non-technical reader, can feel more confident identifying possible L2 solutions. It will also help flesh out the framework we’ve begun with this article.
For updates on when we publish our next article, subscribe to our Developer newsletter, State Change, here.
This article references Chris Wessels' research, but seriously, it wasn’t him that wrote it.