V God's latest research: the limitations of blockchain scalability, refuting Musk's Dogecoin expansion method

The Way of Defi

The Way of Defi

, author: Vitalik Buterin, founder of Ethereum, forwarded with authorization.

How scalable can blockchain be? Can really do as Elon Musk (Tesla CEO) wished "by reducing the block time by 10 times, increasing the block size by 10 times and thus reducing the handling fee by 100 times", without causing extreme centralization and damaging the block Is the fundamental property of chain essence? If not, to what extent can blockchain scalability be achieved? What if you choose to scale by changing the consensus algorithm? More importantly, what if you change the technology to introduce features like ZK-SNARKs or sharding? In theory, a sharded blockchain can keep adding more shards. Will this lead to more things being added?

It turns out that there are some important and rather subtle technical factors that limit the scalability of blockchains, even with sharded blockchains. In many cases, we will have corresponding scalability solutions, but these solutions also have limitations. This post explores many of the problems with these scalability schemes.

All problems can be solved by simply increasing the parameters. But at what cost?

1 Ordinary users can also run nodes, which is crucial for blockchain decentralization

At 2:35 AM, you get an urgent call from a buddy on the other side of the world helping you manage your mining pool (or possibly a staking pool). Your partner told you that from about 14 minutes ago, your pool and several other pools suddenly split from the chain, and the original chain still carries 79% of the network computing power. According to your node, blocks produced by this majority chain (the original chain) are invalid. This resulted in a balance error: the key block appears to have mistakenly allocated 4.5 million additional coins to an unknown address.

An hour later, you start communicating in a telegram group with two other mining pools who are as confused as you, and some block explorers and exchanges. Finally you see someone tweet a link. "New on-chain sustainable protocol development fund officially launched," the tweet read.

By morning, twitter, community forums are filled with uncensored arguments, discussions are everywhere. But at this time, a large part of the previously newly issued 4.5 million tokens have been converted into other assets on the chain, and billions of dollars of DeFi transactions have been carried out. 79% of consensus nodes and all important browsers and light wallets are following this new chain. Maybe this new developer fund will fund some development, or maybe all of that money will be gobbled up by leading mining pools, exchanges, etc. But regardless of the outcome, the fund is, for all intents and purposes, a fait accompli, and ordinary users are powerless to fight back.

A good show is coming. Maybe funded by MolochDAO or something.

Can this kind of thing happen on your blockchain? The elite of your blockchain community, including mining pools, block explorers, and custodian nodes, are probably well-coordinated. They are likely all in the same Telegram group and WeChat group. If they really wanted to make sudden changes to protocol rules to further their own interests, they probably would. The Ethereum blockchain once fully resolved a consensus failure in ten hours; if your blockchain has only one client implementation, and you only need to deploy code changes to a few dozen nodes, then the coordination of changing the client code The speed can be faster. The only surefire way to render such a coordinated social attack ineffective is through the active defense of a decentralized community, aka users.

Let's be clear: your resistance to malicious protocol changes comes from a culture of users validating the blockchain. Instead of PoW or PoS - Hasu

This can be seen from what Hasu said

If your community consists of 37 node runners and 80,000 passive listeners who check signatures and block headers, the attacker wins. If everyone in your community is running a node, the attacker will fail. We don't know what the exact threshold for "herd immunity" against coordinated attacks is, but one thing is absolutely clear: more nodes are better, fewer nodes are worse, and we definitely need more than a few dozen or a few hundred .

first level title

• 2 So, how much work do we need full nodes to do?

• To maximize the number of users who can run a node, we will focus on regular consumer-grade hardware. It is possible to add some network capacity by requiring some readily available specialized hardware (e.g. from Amazon), but in practice this doesn't add much to scalability.

• There are three key limitations to the ability of full nodes to process large numbers of transactions:

Computing power: What percentage of CPU power is required to safely run a node?

Bandwidth: Given the realities of current internet connections, how many bytes can a block contain?

• Storage: How much GB disk can we ask the user to store? Also, how fast is the read speed required? (Can a HDD mechanical hard drive be used? Or do you need a solid-state drive?)

• Much of the misconception about how far blockchain can scale using "simple" technology stems from being overly optimistic about each of these numbers. We can introduce these three factors one by one:

Calculate ability

• Error: 100% CPU power can be used for block validation

• Correct: about 5-10% of CPU power can be used for block validation

• There are four main reasons for the low percentage:

• We need a margin of safety against the possibility of a DoS attack (transactions made by attackers to exploit code weaknesses take longer to process than regular transactions)

Nodes need to be able to sync the chain after they go offline. If I disconnect from the network for a minute, I should be able to sync up with the network again in a few seconds

Nodes also need to perform other non-block producing tasks, mainly around validating and responding to incoming transactions and requests on the p2p network.

bandwidth

• Note that until recently, most explanations for "Why only 5-10%?" focused on a different problem: Since PoW blocks appear randomly, the longer time it takes to validate a block increases simultaneously Risk of creating multiple blocks. There are many solutions to this problem (e.g., Bitcoin NG, or using PoS). But those fixes don't fix the other four, so they don't deliver the huge scaling benefits that many initially thought they would.

• Parallelism is not everything. In general, even seemingly single-threaded blockchain clients have been parallelized: signatures can be verified by one thread while execution is done by other threads, and there is a separate thread handling transaction pool logic in the background. Also, the closer to 100% utilization of all threads, the more energy is consumed to run the node and the lower the margin of safety against DoS.

bandwidth

• Mistake: If we are producing 10 MB blocks every 2-3 seconds, then most users have >10 MB/sec network speeds, so they can certainly handle such blocks

• Correct: maybe we can process 1-5 MB blocks every 12 seconds. It's already hard.

• We often hear advertising statistics these days about how much bandwidth an internet connection can provide: figures of 100 Mbps or even 1 Gbps are often heard. However, there is a large discrepancy between the advertised bandwidth and the actual expected bandwidth for several reasons:

• "Mbps" means "millions of bits per second"; a bit is 1/8 of a byte, so you need to divide the advertised bit figure by 8 to get the number of bytes in the advertisement.

A p2p network inevitably brings its own overhead: nodes often end up downloading and re-uploading the same block multiple times (not to mention transactions broadcast through the mempool before being included in the block).

storage

• storage

• text

Error: 10 TB

text

Correct: 512 GB

As you can probably guess, the main argument here: the difference between theory and practice.

A group of blockchain protocol researchers conducted a survey on how much disk space everyone has. I know the sample size is small, but it still tells something.

Additionally, the storage size determines the time it takes for new nodes to be able to come online and start participating in the network. Any data that existing nodes must store is data that new nodes must download. Initial sync time (and bandwidth) is also a major hurdle for users running a node. Synchronizing a new geth node took me about 15 hours at the time of writing this blog post.

If Ethereum usage increases by 10x, it will take at least a week to sync a new geth node, which will most likely cause your network connection to be throttled. This is especially important during an attack when a successful response to the attack involves new users who have never run a node before.

first level title

Furthermore, there is an interaction between these three costs. Since databases internally use a tree structure to store and retrieve data, the cost of fetching data from the database increases logarithmically with the size of the database. In fact, because the top layer (or several top layers) can be cached in RAM, the disk access cost is proportional to the size of the database, a multiple of the size of the data cached in RAM.

Don't take this graph literally. Different databases work differently, and the in-memory part is usually just a single level (but large) (see the LSM tree used in leveldb). But the basic principle is the same.

For example, if the cache is 4 GB, and we assume that each layer of the database is 4 times larger than the previous layer, Ethereum's current state of ~64 GB will require ~2 accesses. However, if the state size is increased 4x to ~256 GB, then this increases to ~3 accesses. So a 4x increase in the gas limit can actually translate into ~6x increase in block validation time. The effect may be stronger: reads and writes generally take longer when the drive is full than when the drive is nearly full.

4 So what does this mean for Ethereum?

Today, in the Ethereum blockchain, running a node has become a challenge for many users, although it is still possible on conventional hardware (I just synced a node on my laptop as I write this!). So we are approaching the bottleneck. The biggest concern of core developers is storage size. So, for now, heroic efforts to address computational and data bottlenecks, or even changes to the consensus algorithm, are unlikely to result in large increases in accepted gas limits. Even solving Ethereum’s largest prominent DoS vulnerability would only increase the gas limit by 20%.

The only solution to the storage size problem is statelessness and state expiration. Statelessness allows a class of nodes to validate the blockchain without maintaining permanent storage. State expiration releases states that have not been accessed recently, requiring the user to manually provide proof of continued maintenance of these states. Both paths have been used for a long time, and proof-of-concept implementations of statelessness have also begun. Combined, these two improvements should greatly alleviate these concerns and open the door for substantially higher gas limits. However, even after statelessness and state expiration are implemented, the gas limit may only be safely increased by a factor of about 3 before other limitations begin to dominate again.

first level title

5 What happens after sharding?

As a result, sharded blockchains can safely have very high transaction throughput that non-sharded blockchains cannot. It would indeed take a lot of cryptographic ingenuity to create a fully verified valid replacement that successfully rejects invalid blocks, but it can be done: the theory is established and a proof-of-concept based on a draft spec is being worked on .

Ethereum is planning to use quadratic sharding, and its overall scalability is limited by the fact that nodes must be able to handle individual shards and the beacon chain must perform some administrative work for each shard. If the shards are too large, the node can no longer process a single shard; if there are too many shards, the node can no longer process the beacon chain. The product of these two constraints forms a sort of upper bound.

It is conceivable that we can go further by sharding three times or even exponentially. Data availability sampling would definitely get more complicated in this design, but it can be done. But Ethereum will not adopt a higher shard than the secondary shard. The reason is that sharding of shards from transactional shards is practically impossible to achieve additional scalability gains unless other risks start to become unacceptably high.

first level title

6 So what are these risks?

Minimum number of users

It is conceivable that a non-sharded blockchain could function even if only one user is willing to participate. This is not the case with sharded blockchains: no single node can process the entire chain, so you need enough nodes so that they can at least process the blockchain together. If each node can handle 50 TPS and the whole chain can handle 10000 TPS, then the chain needs at least 200 nodes to survive. If the chain at some point has fewer than 200 nodes, either the nodes can no longer keep up with the chain, or the nodes stop detecting invalid blocks, or other bad things can happen, depending on how the node software is set up.

• In practice, due to the need for redundancy (including for data availability sampling), a safe minimum number of nodes is several times higher than simply "chain TPS divided by node TPS"; for the example above, let's say 1000 nodes.

• If the capacity of a sharded blockchain increases by 10 times, the minimum number of users will also increase by 10 times. Now, you might ask: why don't we start with a small capacity, increase capacity when we see a large number of users, and reduce capacity when the number of users decreases?

• There are actually some problems here:

What if many users quit suddenly and unexpectedly?

Increase the minimum number of users required to initiate a fork, making malicious takeovers more difficult.

The minimum number of users is 1,000, which is almost certainly ok. On the other hand, the minimum number of users is set at 1 million, which is definitely not acceptable. Even setting the minimum number of users at 10,000 is a bit risky. Therefore, it seems difficult to justify having a sharded blockchain with more than a few hundred shards.

first level title

7 Historical Retrievability

An important property of blockchain that users really value is permanence. When a company goes bankrupt or loses interest in maintaining the ecosystem, digital assets stored on servers cease to exist within 10 years. NFTs on Ethereum, on the other hand, are permanent.

Quantifying this risk is easy. Taking the blockchain's data capacity (MB/sec), multiply by ~30 to get the amount of data stored in TB per year. The current sharding plan has a data capacity of about 1.3 MB/sec, so about 40 TB/year. If you increase that by a factor of 10, it becomes 400 TB/year. If we want data to be not only accessible, but easily accessible, then we also need metadata (for example, decompressing aggregated transactions), so that's 4 PB per year, or 40 PB over ten years. The Internet Archive uses only 50 PB. Therefore, this is a reasonable upper bound for the security of a sharded blockchain.

Summarize

So it looks like the Ethereum sharding design has actually been roughly aimed at fairly reasonable maximum security values ​​in both dimensions. The constant can be increased a little, but not too much.

first level title

Summarize

There are two approaches to attempting to scale blockchains: basic technical improvements and simply increasing parameters. First, increasing the parameters sounds attractive: if you're doing math on a napkin, it's easy to convince yourself that your home laptop can handle thousands of transactions per second, no need for ZK-SNARKs, rollups, or sharding . Unfortunately, there are many subtle reasons why this approach is fundamentally flawed.

Computers running blockchain nodes cannot spend 100% of their CPU power validating the blockchain; they need a large margin of safety against unexpected DoS attacks, and they need spare capacity to do things like process transactions in the mempool tasks, and you don't want to run node on a machine so that the machine can't be used for any other applications at the same time. Bandwidth is also at stake: a 10 MB/s connection doesn't mean you can have 10 MB blocks per second! Maybe 1-5 MB blocks every 12 seconds. This is the same as storage. Increasing the hardware requirements for running a node and restricting node operation to dedicated actors is not a solution. For a decentralized blockchain, it is critical for the average user to be able to run a node and develop a culture that running a node is a normal activity.