How to distinguish between sidechains, Plasma and sharding?

Original title: "How to distinguish side chains, Plasma and sharding? 》

Original author: Vitalik Buterin (translation: UH)

Original source: Blue Fox Notes

0);">A question that often comes up is: how is sharding different from sidechains or Plasma? All three systems seem to involve a hub-and-spoke architecture, with a central "main chain" that serves as the consensus backbone of the system, and a set of "child chains" that contain the actual user-level transactions. Hashes from the child chains are usually published to the main chain at regular intervals (in theory, shard chains without a hub are possible, but have not been done so far; this article will not focus on them, but the difference is pretty much the same).

Given this basic similarity, why use one approach over the others? It’s easy to distinguish sidechains from Plasma.

Plasma chains are non-custodial sidechains: if anything goes wrong in the Plasma chain, the error can be detected and users can safely exit the Plasma chain, while preventing attackers from doing lasting damage. The only cost to users is that they have to wait out the challenge period and pay higher transaction fees on the main chain, which does not scale.

Normal sidechains do not have this security feature, so they are not as secure as Plasms. However, designing Plasma chains is more difficult in many cases. One could argue that for many low-value applications, the added complexity is not worth the security.

So what distinguishes Plasma from sharding?

The key technical difference has to do with the concept of tight coupling. Tight coupling is a property of sharding, but not of sidechains or Plasma, meaning that the validity of the main chain (or the "beacon chain" in Ethereum 2.0) is inseparable from the validity of the child chain. That is, by definition, a child chain block that specifies an invalid main chain block as a dependency is invalid, and more importantly, by definition, a main chain block that includes an invalid child chain block is also invalid.

In a non-sharded blockchain, these blocks are safe, available, and valid, as defined by the concept of a canonical chain (i.e., the chain that everyone accepts represents the "true" history). For example, in the case of Bitcoin and Ethereum, the canonical chain people usually refer to is the "longest valid chain."

In sharded blockchains, the view that the canonical chain is, by definition, the heaviest valid and available chain also applies, where validity and availability requirements apply to both the main chain and the shard chains. However, a new challenge facing sharded systems is that users cannot directly fully verify the validity and availability of any given chain because there is too much data.

The engineering challenge for sharded chains is to overcome the above limitations by providing users with a maximally trustless and practical indirect method to verify which chain is fully available and valid so that they can determine which chain is the canonical chain.

In practice, this includes techniques such as committees, SNARKs/STARKs, fisherman mechanisms, and fraud and data availability proofs.

If the chain structure does not have this tight coupling property, then it is not a layer-1 sharding solution, but a layer-2 system based on a layer-1 chain that does not scale. Plasma is not a tightly coupled system: an invalid Plasma block can absolutely submit its block header to the Ethereum mainchain, because the Ethereum mainchain has no idea whether it represents an invalid Plasma block, or even whether it is a Plasma block. All it sees is a transaction containing some data. However, the consequences of the failure of a single Plasma chain are limited to the Plasma chain.

l Sharding: Trying very hard to ensure the overall validity and availability of every part of the system.

l Plasma: accept local errors, but try to limit their consequences.

However, if you try to analyze this process: users perform an "indirect verification" process to determine whether the chain they are observing is completely valid and available (without downloading all data and executing transactions), then at this time, you will find that it has more similarities with the way Plasma works.

For example, to prevent availability issues, a common technique they use is the fisherman scheme: if a node sees that a specific piece of a block is unavailable, it can challenge the release statement, creating a time period in which anyone can publish the data. If the block is not challenged for a long enough time, the block and all the blocks it references as dependencies can be restored. This looks basically similar to Plasma, where if a block is unavailable, users can publish a message to the main chain to exit its state.

Both technologies will eventually falter in the same way: if there are too many error challenges in a sharded system, then users will lose track of whether all availability challenges have been answered. Similarly, if there are too many availability challenges in a Plasma system, then the main chain will be overwhelmed as exits fill up the chain’s blocks.

In both cases, it seems that the system nominally scales (O(C^2), where C is the computational power of a node), but in the event of an attack, the scalability drops to O(C). However, sharding has relatively more defenses against this problem.

First, modern sharding designs use randomly sampled committees, so even a single committee cannot easily dominate the production of fake blocks unless it has a majority of validators (perhaps greater than 1/3) of all validator sets on the chain.

Second, there is a better strategy for handling data availability than fishermen: data availability proofs. In a scheme using data availability proofs, if a block is not available, then the client's data availability check will fail and the client will see that the block is not available. If the block is invalid, then even a single fraud proof will convince the entire blockchain of this fact.

An O(1) fraud proof can convince a client of the invalidity of O(C) blocks. Therefore, O(C) data is enough to convince a client of the invalidity of O(C^2) data. (This is the worst case, where the client is processing N sister blocks that all have the same parent, only one of which is valid; in the more likely case, a single fraud proof is enough to prove the invalidity of the entire invalid chain.) Therefore, in theory, sharded systems are less susceptible to being overwhelmed by DoS attacks than Plasma chains.

Again, shard chains provide stronger guarantees in the face of large-scale and majority attackers (more than 1/3 or even 1/2 of validators). Plasma chains can always be successfully attacked by a 51% attack that occurs on the main chain; shard chains cannot. This is because data availability proofs and fraud proofs occur on the client, not on the chain, so they cannot be censored by a 51% attack.

Fourth, the defenses provided by shard chains are easier to generalize; Plasma's exit model requires that the state be divided into discrete parts, each of which is in the interest of a single actor, while shard chains rely on data availability proofs, fraud proofs, fishermen, and random sampling, which are all universal in theory.

So there is really a big difference between the effectiveness and usefulness provided by layer2, which are limited and complex because they require explicit reasoning about incentives and understanding which party has an interest in which part of the state, and also require guarantees that they are provided by a layer1 system that promises to fully satisfy them.

But Plasma chains also have big advantages.

First, they can be iterated on and new designs implemented quickly, because each Plasma chain can be deployed independently without coordinating with the rest of the ecosystem.

Second, sharding is inherently more fragile. This is because it attempts to guarantee the absolute and total availability and validity of a certain amount of data, and that amount must be set in the protocol; too little and the system is less scalable than it should be; too much and the entire system is at risk of being compromised.

The maximum level of security for scalability also depends on the number of users of the system, which is an unpredictable variable. On the other hand, Plasma chains allow different users to make different trade-offs in this regard, and allow users to adjust more flexibly to changing circumstances.

Single operator Plasma chains can also be used to provide more privacy than sharded systems, where all data is public. Even if privacy is not required, they may be more efficient, because the full data availability requirement of a sharded system requires an additional level of redundancy as a safety margin. On the other hand, the data requirements of each shard can be minimized, and in the long run, each individual shard may only need to be replicated a few times, rather than a thousand times as in a sharded system.

Thus, in the long run, a hybrid system that has both a sharding base layer and a Plasma chain built on top of that base layer that provides more scalability seems to be the most likely approach that will better serve the needs of different groups of users rather than relying on one or that strategy alone.

Unfortunately, at sufficient levels of advancement, Plasma and sharding are stuck in the same design. The two are irreducibly different in some key respects (for example, data availability checks done by clients in sharded systems cannot be moved to the mainchain in Plasma, because these checks are only effective if they are done subjectively and based on private information.) But both scalability solutions (including state channels) have a bright future. (The author would like to thank Jinglan Wang for his review and feedback)

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia