Good morning.
I’m Mitsui, a web3 researcher.
Every Saturday and Sunday at noon, we’ll deliver articles explaining basic vocabulary. We aim to keep each article concise enough for a quick read, while also providing content you can revisit and study.
Today’s topic is “Scalability.”
Please watch until the very end!
Misunderstandings About the Term “Scalability”
When people hear the term “scalability,” they often associate it with “slow processing” or “low performance.” However, this is a misconception.
Scalability is not merely about processing speed; it is a concept that questions whether a system can grow without breaking as the number of users increases, and how much the system can expand or contract.
For example, imagine a ticket gate at a train station in the morning. It can process a single passenger instantly, but during rush hour, lines form. Yet the gate itself isn’t broken. This is a scalability issue. On the other hand, if the gate’s parts wear out within an hour, that’s a performance issue.
The same applies to web3, particularly in the context of blockchain. The reason Ethereum appears slow is not due to technical flaws, but because it faces an extremely difficult design challenge: growing while maintaining security and decentralization.
How do existing systems achieve “speed”?
The reason Visa, Mastercard, or bank transfer systems appear so fast is because they operate on the premise that “not everyone is participating equally.”
For Visa, transactions (card payments) are processed in the following sequence:
Even when a merchant sends payment information to Visa, the transfer of funds is not finalized at that point. Visa’s central server records the information, and settlement then occurs between banks via the payment network. In other words, it’s a “perceived acceleration.” In reality, it can take several days from the payment being processed until the funds actually move.
The same applies to bank transfer systems. Using a mechanism called batch processing, they handle large volumes of transactions collectively every hour or once a day. This distributes the verification costs for individual transactions, ultimately increasing overall processing speed.
In other words, the true nature of the “speed” in existing financial systems relies on the existence of a centralized authority. Only when this authority judges “this transaction is valid” does the system function. Furthermore, this authority can cancel transactions as needed. This is why mechanisms like reversals and chargebacks exist. It is precisely because of this power to “reverse” that the entire system can be kept simple.
Why Blockchain Seems Slow
The slowness of blockchain stems from its design philosophy. At its core lies the concept of “full node verification.” Whether Bitcoin or Ethereum, every node (computer) participating in the network must verify and maintain the same transaction history.
This is akin to having every station employee individually verify whether each passenger passing through the ticket gate actually holds a valid ticket. While certainly secure, it is time-consuming.
Furthermore, distributed systems face an unavoidable constraint. This is known as the “scalability trilemma,” which states that it is theoretically impossible to fully achieve all three characteristics—distributed nature, security, and scalability—simultaneously.
For example, prioritizing scalability to speed up processing reduces the number of nodes participating in validation, diminishing decentralization. Alternatively, enhancing security increases the computational load required for validation, sacrificing scalability.
The Block Size Problem: The Origin
To understand the essence of this problem, examining Bitcoin’s history is the most straightforward approach.
