Vitalik: How to distinguish between side chains, Plasma and shards?

Foreword: What is the difference between sharding, sidechain and Plasma? Although they all have similar Hub-and-spoke structures, they actually have a lot of differences. The author of this article is Vitalik Buterin, translated by the "UH" of the "Blue Fox Notes" community.

There is often a question to ask: What is the difference between a slice and a side chain or a Plasma? All three systems seem to involve hub-and-spoke, with a central "backbone" as the consensus backbone of the system and a set of "sub-chains" containing actual user-level transactions. Hash values ​​from sub-chains are usually released to the main chain on a regular basis (in theory, it is possible to have no shards of hubs, but it has not been completed so far; this article does not pay attention to them, but it is basically the same).

Given this basic similarity, why use one method instead of the other?

It is easy to separate the side chain from the Plasma.

• Bitcoin ETF is far away? SEC again postpones decision on three applications
• Securities Times: Digital currency is ready to go, are you ready?
• Goldman Sachs: Bitcoin will hit a new high in 2019, and these callbacks should be seen as buying opportunities on dips

The Plasma chain is a side chain of non-custodial features: if there are any errors in the Plasma chain, errors can be detected and the user can safely exit the Plasma chain while preventing the attacker from creating long-term damage. The only cost to users is that they have to wait for the challenge period and pay a higher transaction fee on the main chain, and the main chain is not scalable.

Ordinary sidechains don't have this security feature, so they don't have Plasmas security. However, designing a Plasma chain is more difficult in many cases. One might think that for many low-value applications, it is not worth adding these complexities for security.

So how do you distinguish between Plasma and shards?

Key technical differences are related to the concept of tight coupling. Tight coupling is the property of the slice, but not the attribute of the side chain or Plasma. That is to say, the validity of the main chain (the "beacon chain" in Ethereum 2.0) is inseparable from the validity of the sub-chain. That is, by definition, the sub-chain block that specifies the invalid main chain block as a dependency is invalid, and more importantly, the main chain block containing the invalid sub-chain block is also invalid according to the definition.

In non-fragmented blockchains, these blocks are safely available and efficient, as defined by the notion of a canonical chain (ie, the chain that everyone accepts represents "real" history). For example, in the case of Bitcoin and Ethereum, the normative chain that people usually say is the "longest effective chain."

In a fragmented blockchain, by definition, the canonical chain is the heaviest effective and usable chain. This view also applies, where both validity and usability requirements apply to either the main chain or the slice chain. However, the new challenge for fragmentation systems is that users cannot directly verify the validity and availability of any given chain directly because there is too much data.

The engineering challenge of the slice chain is to overcome the above limitations by providing users with maximum trust and practical indirect methods to verify which chains are fully available and valid so that they can determine which chain is the canonical chain. .

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

If the chain structure does not have such a tight coupling property, then it is not a layer-1 fragmentation scheme, but a layer-2 system based on a layer-1 chain without scalability. Plasma is not a tightly coupled system: an invalid Plasma block can definitely submit its block header to the Ethereum main chain, because the Ethereum main chain is completely ignorant of whether it represents an invalid Plasma block, and even the Ethereum main chain is connected to it as a Plasma block. Not sure. All it sees is a transaction that contains some data. However, the failure of a single Plasma chain is limited to the Plasma chain.

Fragmentation: Try very hard to ensure the overall effectiveness and availability of each part of the system.

Plasma: Accepts errors that occur locally, but tries to limit its consequences.

However, if you try to analyze this process: the user performs an "indirect verification" process to determine if the chain they are observing is fully valid and available (and does not download all data and execute transactions), then at this time you will find it There are more similarities with how Plasma works.

For example, to prevent usability issues, they use a common technique for the fisherman program: if a node sees that a particular segment of the block is not available, it can challenge this release statement to create a time period that anyone can post that data. If the block does not encounter a challenge for a sufficient amount of time, the block and all references to which it references as a dependency can be recovered. This looks similar to Plasma. In Plasma, if a block is not available, the user can post a message to the main chain to exit its state.

Both technologies end up being pressured in the same way: if there are too many error challenges in the sharding system, then the user cannot track whether all usability challenges have been answered. Similarly, if there are too many usability challenges in the Plasma system, then the main chain will be overwhelmed because the exit will fill the chain blocks.

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

First, modern shards are designed using randomly sampled committees, so even a committee cannot easily lead to the creation of false blocks unless they have most of the verifiers (perhaps more than 1/3) of all the certifier groups on the chain. Second, there is a better strategy for handling data availability than fishermen: proof of data availability. In a scenario that uses data availability proof, if the 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 certificate will convince the entire block of this fact.

The O(1) size fraud certificate allows the client to trust the O(C) size block invalidity. Therefore, the O(C) data is sufficient for the client to be convinced of the invalidity of the O(C^2) data. (This is the worst case where the client is processing N sister blocks, all of which have the same parent block, only one of which is valid; wherever possible, a single piece of fraud evidence is sufficient to prove the whole invalid Invalidity of the chain.) Therefore, in theory, the slice system is not easily overwhelmed by DoS attacks relative to the Plasma chain.

Again, the fragmentation chain provides a stronger guarantee (more than 1/3 or even 1/2 of the verifiers) in the face of large and majority attackers. The Plasma chain can always be successfully attacked by 51% of the attacks in the main chain; the slice chain cannot. This is because data availability certificates and fraud certificates occur on the client side, not on the chain, so they cannot be reviewed by 51% of attacks. Fourth, the defense provided by the fragmentation chain is easier to generalize; Plasma's exit model requires that the state be divided into discrete parts, each part of which is in the interest of a single actor, and the fragmentation chain relies on data availability proof, fraud proof, Fishermen and random sampling are theoretically common. Therefore, there is indeed a big difference between the effectiveness and usefulness provided by layer2, they are limited and complex, because they require explicit reasoning about the incentives, and to understand which party is interested in that part of the state, it also needs to be guaranteed It is provided by the layer1 system that promises to fully satisfy them.

However, the Plasma chain also has a big advantage. First, they can be iterated and new designs can be implemented quickly because each Plasma chain can be deployed separately without the need to coordinate the rest of the ecosystem. Second, from the essence, fragmentation is more fragile. This is because it tries to guarantee the absolute and overall availability and validity of a certain amount of data, and must be set in the protocol; too little, the scalability of the system is lower than it should be; too much, The entire system is at risk of damage.

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, the Plasma chain allows different users to make different trade-offs in this regard and allows users to adjust more flexibly to adapt to changes in the environment. A single operator Plasma chain can also be used to provide more privacy than a sharding system, and all data for the sharding system is public. Even if privacy is not required, they may be more efficient because the full data availability requirements of the sharding system require an additional level of redundancy as a safety margin. On the other hand, the data requirements for each piece of data can be minimized, and in the long run, each individual piece of data may only need to be copied a few times instead of being copied a thousand times as in a sharding system. Therefore, in the long run, a hybrid system with both fragmented and underlying Plasma chains can provide more scalability, which seems to be the most probable way to serve different groups of users. Instead of relying solely on one or the other strategy.

Unfortunately, at a sufficient level of advancement, Plasma and shards fall into the same design. There are indispensable differences between the two in some key aspects (for example, the data availability check performed by the client in the sharding system cannot be moved to the main chain in Plasma because these checks are only done subjectively and based on private Only valid when the information is available.)

But these two scalable solutions, including state channels, have bright prospects.

(The author is particularly grateful to Jinglan Wang for his review and feedback)

——

Risk Warning : All articles in Blue Fox Notes can not be used as investment suggestions or recommendations . Investment is risky . Investment should consider individual risk tolerance . It is recommended to conduct in-depth inspections of the project and carefully make your own investment decisions.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!