Skip to content
Christian Felde

Published On - June 7, 2022

Layer 2: For Scalability not Privacy

In my previous blog post, about enterprise blockchain moving left, I wrote about how private data shouldn’t be on a shared blockchain and that instead, we should use these networks as a source of truth. On this source of truth, we’d be publishing anchor points, and the data in these, we’d be comfortable with being public as part of the anchoring process. 
 
 
If we scratch beneath this surface, we understand that in no way does the need for privacy disappear, but instead we’re simply optimising how we’re maintaining this privacy. As public permissionless blockchains rise to the challenge and provide always-available cheap transactions with no significant limitations on bandwidth, it just makes sense to build on top of these rather than expensive private permissioned networks.
 
As part of the network structure, as core building blocks for offering sufficient transaction bandwidth at low cost, we find two core elements: Sharding and layer 2s

Sharding 

Sharding is easy enough to get a high-level view on, as they are somewhat like what’s often called sidechains. What is different from sidechains, is that through the added security offered by proof-of-stake, we’re able to share a single consensus network, in turn giving us scalable security. Because of this, we can concentrate our resources on one chain, giving us overall better security as it becomes more decentralised.
 
This is very different from spreading our resources out among many separate blockchains. If we try to scale the sidechain model too much, we risk spreading ourselves thin on security, making it easier to attack a single chain. As chains become intertwined through the bridging of assets, the loss of security on any one chain is detrimental to all chains.
 
It therefore, makes sense to have one source of truth, and ensure the security and reliability of this one layer 1 network is maintained at all times. And with sharding we dramatically increase the bandwidth on this layer 1 network, further reducing the argument for other sidechains.
 
But there are technical limitations to how many shards we can have, and limits to what type of transactions we want to put onto a layer 1 blockchain. This is where layer 2s become ever more interesting. 

Layer 2 network

Layer 2, as a term, is a bit bloated, as it’s being used for a few different use cases now. There are also different layer 2 technologies for each of these use cases, further complicating the picture. Let’s define what I mean by layer 2s. 

What is a layer 2 network? 

A layer 2 is anchored to the layer 1 network through a data-sharing mechanism that ensures the integrity and correct behaviour of the layer 2 system. If this integrity is broken for whatever reason, mechanisms tied into the layer 1 system allow honest actors to challenge the current state of the layer 2 system and correct it. This is a convoluted way of saying that the security of the layer 2 system is equal to or comparable to the layer 1 system. Hence, I get the same confidence that my transactions, my assets, and other attributes stored on the layer 2 system are maintained to the same standard as the layer 1 system they are anchored against.
 
This is fantastic from a scalability point of view, because the amount of data needed to be anchored on the layer 1 blockchain from the layer 2 system, is less than the total amount of state altered on the layer 2 system. We get a sort of compression benefit, and this allows for a greater transaction bandwidth on the layer 2 system than what’s needed on the layer 1 network to support this throughput.
 
There are a couple of different core technologies involved when building a layer 2 solution, known as optimistic rollups and rollups based on zero-knowledge proofs (ZKPs). Optimistic rollups are here today, and ZKP based rollups will likely be production-ready in a year or two for a full set of use cases. We’ll likely transition fully to ZKP based rollups in the long run, due to the cryptographic proof of validity they give us, in addition to a few other benefits. It’s important to note that ZKPs are used not to keep data private in this context, but to give cryptographic proof of validity. 

Does a layer 2 system solve our privacy needs?

I think the technology can play a role in that, but I don’t think we should view the layer 2 system itself as the privacy layer, because it again implies putting private data on public infrastructure. Instead, we should view layer 2s as scalability layers. If the layer 1 network exists to ensure a single source of ultimate truth, then layer 2s are about giving us the bandwidth we need to utilise this source of truth at a global scale.
 
Why did I say that putting data on a layer 2 equates to putting data on public infrastructure and hence, layer 2s are no good for private data? Just like we want our layer 1 network to be decentralized and not controlled by any one entity, for availability reasons, so too do we want our layer 2s to be decentralized. That means that there shouldn’t be one operator of a layer 2 service instead, multiple independent entities should compete for who gets to run the currently active layer 2 service. 

Layer 1 vs Layer 2 network

We need to understand that contrary to the layer 1 network, which consists of many equal nodes in a big network, layer 2 systems consist of a single server. This single server takes transactions and processes them in sequence. It then takes a regular snapshot, using a rollup technique, and puts this on the layer 1 network. What happens if this single server goes down? As with any highly available IT system, we need a backup. But the backup for a layer 2 shouldn’t just run in a different data centre, it should also be run by a different operator. Through smart contracts on layer 1, multiple operators can then bid against each other for the privilege of running the layer 2 service. The most cost-effective operator at any time gets to run the service. As transactions are processed by this service, all other layer 2 backup operators would need to be given continuous access to both the processed and yet-to-be processed transactions, so that they can pick up from where the current operator left, should it exit. 
 
This is often referred to as data availability. Without shared data availability among any willing layer 2 operators, we can’t mitigate censorship risks. Should any current layer 2 operator fail in their duties to manage this, the decentralized logic deployed on layer 1 will automatically kick them out and allow the next willing operator in to replace them. (This is all transparent to the regular user of a layer 2 service, by the way.)
 
From this, it is then clear that private data can’t really remain private on a layer 2 as it would need publishing onto a network of layer 2 operators and nodes. You might argue that it’s possible to use ZKPs to hide the specific content of a transaction, but this is limited. While over time the situation might improve, I doubt it’s worth the effort and complexity of trying to make a layer 2 system the place for fully private transactions.
 
From the above, we can start to see multi-layered architecture emerging. At the bottom on the layer 1 network, multiple decentralized nodes participate in a network to establish a shared trust layer. While bandwidth is limited to ensure the system remains decentralized and secure through mechanisms like proof-of-stake and sharding, we are able to provide enough bandwidth when they are combined with many layer 2 networks to cater to global demand. These layer 2 solutions then build on top of this global layer 1 network. 
 
Through zero-knowledge proofs and data anchoring against layer 1, a layer 2 system shares the same security as its anchoring network. And through the rollup data compression process, the bandwidth on a layer 2 system is greater than on the layer 1 network, giving us plenty of transaction throughput at reasonable prices.
 
This is why Layer 2s are primarily about scalability, and I argue that we should avoid putting private data on them, even if encrypted, as private data should remain private. I think however, we can build on top of layer 2s to solve this, in what I will describe as a layer 3 in my next blog post.

Have any questions or comments? We’d love to hear from you! If you want to find out more about blockchain, its growth, and newest developments, then check our blog or listen to our enlightening Web3 Innovators podcast
 
Layer 2, Scalability