Scaling refers to a system’s ability to sustain an increase in bandwidth. Particularly in the case of Blockchain networks, this means supporting a higher transactional throughput as well as a greater number of nodes. So what does this look like? And what are the limitations? How can we even begin to approach a problem like this? Let’s find out together as we explore the ‘Scalability Trilemma.’
Scaling a Distributed Network
Like any network, as capacity goes up, so too does its complexity. This gets much harder when we’re talking distributed networks. Fortunately, we can ‘stand on the shoulders of giants’ to reach some perspective by looking at Brewer’s ‘CAP’ Theorem .
First published as the ‘CAP Principle’ in 1999, ‘Brewer’s Theorem’ basically states that distributed systems must sacrifice being either ‘Consistent’ or ‘Available’ in the presence of network ‘Partitions’ (CAP).
- Consistency - Responses are guaranteed to be up-to-date and accurate, or an error will be returned
- Availability - Responses are not guaranteed to be up-to-date or accurate, but will always be returned
- Partition Tolerance - Withstanding a network splitting into distinct sub-networks, kinda like ‘forking’
This often gets confused as a ‘pick two’ scenario, when in reality, it’s a lot more about choosing between ‘Consistency’ and ‘Availability.’
That makes a lot of sense when you think about it too. Distributed networks are inherently vulnerable to forking (partitioning). And if you’ve ever had to write penalties in grade school, you’ll know every line can be just a little bit different from the next. Even if you thought you were slick by running from top-to-bottom doing each letter at a time, each line would just look different (not that I’d know anything about that 🙄)
Now, you could have taken your time, carefully writing each line (or letter) with a monk-like focus, determined to craft your masterpiece and prove you’d learned your lesson…but that accuracy will have taken more time. Or you could have just flown through it, your pencil transcending space and time, each line (or letter) appearing in the blink of an eye, just wanting to get it over and done with. So what if it’s not consistent? At least it got turned in, right?
In either case, you made the choice between getting it done fast or getting it done accurately: available, or consistent. The lines will just be inherently different, even more so as the number of lines goes up, especially if you weren’t the only one writing a penalty. Your lines and Tommy’s lines can look a lot different, even though you have the exact same penalty and it was totally Tommy’s fault to begin with.
If we apply this to distributed networks, each line is like a node on the network, and in much the same way we chose between getting the penalty done accurately and getting it done fast, we also need to choose between whether our network cares more about consistency or availability.
For example, travel directions can change for a variety of reasons. Since it’s safe to assume most people would prefer not to be potentially stranded in the middle of nowhere and eaten by a family of bobcats, our network should prioritize consistency/accuracy. On the other hand, we should prioritize availability for something like the geolocation of a historical landmark since that shouldn’t change…and if it does, well, we’ve got bigger issues to deal with.
So then, how can we apply all this to Blockchain architecture? It’s a distributed network, it’s vulnerable to partitioning, and we stopped trusting Tommy after that whole debacle. This leads us to a concept known as the ‘Scalability Trilemma.’
The Trilemma
The ‘Scalability Trilemma,’ in many ways, reframes Brewer’s Theorem. In it, Ethereum co-founder Vitalik Buterin proposes that within current Blockchain technologies, there will always be a trade-off between Scalability, Security, and Decentralization when dealing with traditional approaches.
- Scalability - Efficiently sustaining an increase in bandwidth, that is, handling more transactions (Brewer’s ‘Availability’)
- Security - Guaranteeing the correctness and integrity of a network, including the ability to resist attacks (Brewer’s ‘Consistency’)
- Decentralization - The degree of resistance to large centralized actors, who might collude to manipulate data (Brewer’s ‘Partition Tolerance’)
Unlike ‘Brewer’s Theorem’, this is much more of a ‘pick two’ scenario:
- Prioritize Scalability and Security, and we sacrifice Decentralization
- Prioritize Scalability and Decentralization, and we sacrifice Security
- Prioritize Security and Decentralization, and we sacrifice Scalability
OK, but what does this mean?
We already know that more nodes means more complexity, and since we don’t want our assets pulling a ninja vanish, this also means more time spent on validating data.
If we want less complexity and time, we need to scale back the number of nodes on our network. But wait…that’s centralization! Not that way! The other way, decentralization. Centralization means trusting a smaller number of nodes, and we don’t want to sacrifice security like that. No thank you!
But then, what do we do? We can have fast and accurate transactions, but not without sacrificing decentralization. And if we rely on a smaller number of nodes to gain speed, we have to extend a great deal of trust since there are fewer nodes validating data.
Since we’d really prefer to steer away from centralization, and we don’t want to sacrifice security, that leaves us with improving the ways that we can scale…but how does that work!?
A Layered Approach
To figure out the different ways we can improve scalability, let’s take a look at the different architectural layers of a Blockchain. The layering of a Blockchain is roughly analogous to the OSI Model which abstracts the protocols and concepts of computing or telecommunications systems into distinct layers.
In Blockchain architecture, Layer-1 (L1) is considered the Base Layer. It’s the lowest level where solutions fundamentally change the way the Blockchain works. This usually involves things like increasing the size of a block, decreasing the size of transactions, consensus changes like switching from PoW to PoS , or sharding . This also makes L1 solutions particularly tied to the ‘Scalability Trilemma’ as L1 is the main network itself. We’re unavoidably going to make trade-offs here if we want to scale. Remember, we can write our penalty fast or consistently, but not both.
What happens when we look at Layer-2 (L2) then? This is where things get interesting. If L1 solutions change the way a Blockchain works, L2 solutions change the way you use a Blockchain. We no longer have to rely solely on using the main chain. That’s right, we can offload overhead onto a secondary network which can work a lot differently. All that matters is that the final result ends up on the main chain.
If L1 solutions change the way a Blockchain works, L2 solutions change the way you use a Blockchain.
To put it another way, using L2 is kinda like the teacher revealing that they never technically said we have to do it all by hand…all they really wanted us to turn in was the same line repeated 50 times…
Conclusion
As we’ve seen, there’s a lot to consider when it comes to scaling a Blockchain network. There are always trade-offs to be made, but that doesn’t mean we can’t rethink solutions to a problem. Sometimes a bit of perspective and taking a different approach reveals that our limitations were based on assumptions about the scope of what we can do…
All it takes is a little bit of thinking outside the Blockchain 🥁
The journey doesn’t end here! We’ll be exploring more technical topics just like this one, including what the different Layer-2 solutions are and how they work.
Let us know if there are particular topics you’d like to learn more about too. We’re only just getting started, my friends 🦾
Simon is a WEB3 developer and technical writer. When he isn't busy programming microcontrollers, documenting Blockchain software, and saving the world from centralization, he enjoys creating music and exploring the latest technological trends.