News
Beyond sharding and rollups: a new approach to blockchain scalability
Vitalik Buterin he still produced another well argued piece on why one approach to scaling Ethereum (ZK rollup) is better than others (Ethereum sharding). I agree with almost everything Vitalik has written on the subject, yet I fundamentally disagree with the vision he paints. The reason is that his arguments fail to address the fundamental issue: the intrinsic structure of the Blockchain is the real obstacle to scalability. As long as the enterprise layer, which provides value and experience, is coupled with the network layer, which provides scalability, we will not be able to deliver value at scale.
Scalability: the great dilemma of Blockchain
dilemma (noun): a choice between two (or, generically, more) alternatives, which are or appear equally unfavorable – oed
Public blockchain ecosystems like Ethereum have a problem. Monolithic “L1” mainnets are neither suitable nor sufficiently performant and economical for all intended use cases. This problem is usually condensed into talking about “blockchain scalability”.
This problem is serious. Vitalik Buterin, co-founder of Ethereum, wrote about “blockchain scalability” for over 10 years. Many solution approaches have been proposed and implemented: Lightning, Sharding, Optimistic rollups, Rollup ZK, Plasmas, Valid, Baselines, Subnets, Chain guard, Appchain… The pros and cons of the approaches are hotly debated.
Choosing the right option from those listed above is a real dilemma. The problem is real, ecosystems like Ethereum have to make a choice. But all the above choices are equally unfavorable.
As with any good dilemma, arguments can be made as to why one choice is better than another. The Ethereum ecosystem is aligning around rollups and Vitalik Buterin he claims in the long term this will converge towards ZK rollups. His arguments are strong and revolve around the benefits of heterogeneity and developer independence, as well as the technical advantages of efficient proofs on data.
But in the same paper he also underlines that all the options taken into consideration are essentially the same.
“Layer 2” and “sharding” are often described in public discourse as two opposing strategies for how to scale a blockchain. But when you look at the underlying technology, a puzzle arises: the current approaches to scaling are exactly the same. You have some sort of data sharing… The main difference is: who is responsible for creating and updating those parts and how much autonomy do they have?
And they are all the same in the sense that the fragments/rollups/subnets are in a very real sense independent chains. Arguments about whether to use one type of rollup or another are akin to arguing which type of glue is best suited for piecing together the fragments (pun intended) of something that is fundamentally broken.
The way Vitalik talks about this is how to preserve the “feeling” that the ecosystem is a coherent thing, i.e. how to best hide the glued seams:
As Ethereum branches, the challenge is to preserve the fundamental property that it still looks like “Ethereum” and has the network effect of being Ethereum rather than being N separate chains…
Moving tokens from one layer 2 to another often requires centralized bridge platforms and is complicated for the average user.
These problems are known, understood and a lot of effort is being made to iron out these problems. I’ve already discussed why Bridges won’t cut it. But why try to glue together something that is fundamentally broken and not design something that solves the fundamental problem?
The Internet analogy: decoupling business and networking
Everyone in the space loves Internet analogies, and for good reason: The Internet works. It provides connectivity between applications, resources and users and is virtually infinitely scalable. It has many of the properties espoused by blockchain networks.
- Common experience: It has the fundamental property of feeling uniformly like “the Internet” and creating network effects within it. It doesn’t look like N-peering layer 1/2/3 subnets are actually there. The browser provides this experience.
- Heterogeneity: Centralized controls and standards are minimal (TCP/IP, BGP, DNS, etc.). It is possible for developers to try almost anything new. Application operators have complete control of their system, from data permissions to SLAs.
- Modularity: Public-facing APIs can be composited together into new experiences on the underlying apps.
- Scalability: Just add a new server or router to extend.
One of the key design differences between the Internet and blockchains like Ethereum is that the business layer is completely decoupled from the network layer. I’ve pointed out before that the Internet at the network level is really a glued-together mosaic. Traffic is automatically (thanks to BGP) routed through independently controlled peer networks. We experience this in some way only when it goes wrong and a service like Facebook, which runs on its own subnet, disappears from the Internet.
The only thing that matters to you as a user is having sufficient connectivity to one of Facebook’s servers, the enterprise layer of the Internet. This works because Facebook and you have agreed to allow your traffic (hopefully TLS encrypted) to be routed through some third-party infrastructure (backbones, ISPs, etc.). The business layer (authentication, reading and sending data, creating a post, etc.) is only between you, the user, and Facebook as the application provider.
Fully replicated blockchains like Ethereum, as well as the “sharding” techniques mentioned above, are fundamentally different. The network serves as a network and messaging channel (gossip protocols), data persistence layer (storage and service blocks), logic execution/validation (smart contracts), ordering (mining), etc. It’s all integrated, which makes each network/shard a monolithic silo, a “virtual mainframe”. The enterprise topology of the Internet, that is, the connections between users and apps, as well as the composability between apps, is forced to follow the network topology. Ergo, splitting the network layer for scalability fragments the business layer, creating hard-to-cross boundaries, fragmented experiences, and ultimately new silos.
Canton Network was designed from the ground up to decouple the business and network layers such as the Internet. The enterprise layer, which is what we most often call “blockchain,” is entirely between the participants involved: the “participating nodes” of users and application providers, which are analogous to servers on the Internet. They make dynamic use of infrastructures, so-called “synchronizers”, which are only concerned with transmitting and ordering (encrypted) messages, equivalent to routers, subnets or ISPs on the Internet. They do just enough to ensure deterministic execution, atomicity of transactions, and double-spending protection between participants. This allows the business layer to grow seamlessly, organically, and without raw glue. No fragments, no silos.
For example, imagine you have funds, cash and a trading app, each using only their own dedicated sync infrastructures and managed by their respective operators (OP pictured).
The buyer and seller would like to do a trade, but can’t since there is no common connectivity – you effectively have three apps, each running on its own LAN to which the buyer and seller are connected.
With Canton all you need to do is add a common synchronizer, the equivalent of a WAN or Internet backbone.
There is no need to create bridges, no need to “move” tokens, and no need for app/resource operators to modify their application. All the participants need is to connect to an additional common synchronizer. Once this is done, they can coordinate the consensus needed to add an atomic transaction involving all three apps to the “chain.” Sure, you need to put trust in this new infrastructure to properly perform its basic tasks, but trust for the ordering and delivery of messages is a solved problem. Choose a reliable centralized operator (ISP, backbone operator) or use a BFT algorithm (like a blockchain). And when in doubt, you can remove or change the synchronizer as easily as you added it, without migrating your application to a new server.
Conclusion
The whole discussion about sharding and blockchain rollups is a debate about which remedy for a terminal illness is the least serious. The fundamental problem with blockchains like Ethereum is that they tightly couple the business topology with the network topology. Scalable networks are inherently patchwork: as demonstrated by the Internet, the ability to add “patches” is what scalability means. But at the enterprise level, such patchworks are antithetical to the uniform experience and universal composability we need to realize blockchain’s value proposition. Merging independent silos with messaging standards and bridges is not innovation. Networks like SWIFT have optimized this model to a large extent.
What we need is a middle ground that can provide the atomic composability and uniformity of enterprise-level L1 blockchains, while offering the flexible network topology, subnet independence, and scalability of something like Internet.