Explore: Blocking and expansion of blockchains

This article focuses on cross-slicing transactions, invalid transactions, and malicious behavior.

It has been discussed before that the basic shard type is not a very practical sharding method because its shards cannot communicate with each other, which makes them the same as a single blockchain.

Let us give an example of a simple payment. If User A and User B are on the same shard, the certifiers in the shard will be able to handle the transaction easily, but if they are in different shards and have different accounts?

• Analysis: The DAO governance trend is gradually rising, and the blockchain needs no braking mechanism?
• The Bank of International Settlements economists propose a new method for financial market monitoring based on DLT
• Weizhong Bank issued a “good” social governance framework and used blockchain for social governance

User A is on slice 1 and user B is on slice 2. The certifiers on each shard cannot record or deduct funds from the user account because they do not have the relevant permissions.

However, there are solutions to this problem, see the detailed description:

Synchronous (simultaneous) cross-segment transaction

In this case, when user A of slice 1 needs to send funds to user B of slice 2, the block containing the state of the relevant transaction in each slice will be generated at the same time, and the verifier on each slice Will coordinate the transaction. As early as the beginning of 2018, Vitalik Buterin proposed to use this solution to merge blocks.

Asynchronous cross-segment transaction

This operation is simpler and easier to coordinate, so it is more popular than synchronous trading.

Similarly, we assume that User A of Fragment 1 is to send money to User B of Fragment 2.

In this case, the fragment responsible for the funds deposited into the B account, once sufficient evidence is obtained, proves that the fragment responsible for deducting funds from the A account has completed its part of the work (ie, the funds have been deposited from the A account). After deducting), the shards of the funds will be completed in the part of their work (the funds will be credited to the B account).

However, this method is not perfect, and the possibility that a block in a slice becomes a lone block is still non-zero. And a non-zero possibility, no matter how small the probability, is still a loophole that cannot be underestimated.

Take a look at the chart below and analyze the reasons:

This blockchain has two slices, and purely by coincidence, they all fork when the transaction is merged into block A in slice 1 and block X' in slice 2. When such a fork occurs, each segment must isolate one of the chains and accept the other. In this case, if the chains A, B become the chains accepted by the segment 1, and the chains W', X' become the chains accepted by the segments 2, then the transaction can be successfully executed, and all of them are happy.

If slice 1 accepts chains A', B' and slice 2 accepts chains W, X, the transaction fails, but the result is acceptable because the transaction can be resent.

But what if the slice 1 accepts the chains A, B and the slice 2 accepts the chains W, X? This will cause some transactions to be successfully executed (on chain A, B), while another part of the transaction is discarded (chains W, X).

Consideration

Now that you have mastered the shards and how they work, you may find this explanation clear and you may have a lot of questions, but don't forget that there is another factor to consider: malicious participants .

Malicious node

Regardless of the system, when there is a lot of money, someone will try to attack the system. This is not uncommon.

Approval of invalid blocks

A malicious participant node may attack the network by creating a block that can change the network. Taking User 1 and User 2 as an example, assume that User 1 has 10 coins and User 2 has 0 coins. When user 1 sends these 10 coins to user 2, a malicious node on the network can attempt to create a block such that end user 1 owns 0 coins and user 2 owns 1000 coins.

In a regular blockchain without slices, it is impossible for an attacker to initiate such an attack, because each node will verify each block. If an invalid block is found, all nodes (whether or not The miners will reject the block.

For traditional blockchains, no matter how many blocks are created by malicious nodes or how fast they are created, honest participants in the network will always ignore those blocks and continue to build an honest chain.

For a blockchain that forks into two, a malicious node builds an invalid block and populates their account with a lot of coins. In this case, the number of malicious nodes may even exceed that of honest nodes. At this point, the shorter chain is the honest chain, and the longer chain is the invalid chain. In a conventional non-fragmented blockchain, each participant is responsible for verifying all the blocks they receive and confirming the status, thus having any vested interest in the blockchain (and extending its integrity) Both will immediately identify the invalid chain and ignore it, thus continuing to build a shorter chain (according to this case).

The sharding chain is a bit more complicated because the participants cannot verify every transaction on each shard, so we have to figure out how to confirm that there are no invalid blocks in the entire history of the shard.

Since the beacon chain (discussed in the previous article) usually cannot verify every block in each shard, we need another solution to ensure the integrity of each chain.

Assuming that each fragment in a network has a Byzantine fault tolerance mechanism and the number of malicious nodes in the fragment is controlled below 66.667%, it is possible to construct a mechanism that can be used when a malicious node attempts to generate an invalid block. An alert is issued to the system, and then one or more honest nodes verify that the block is valid. If more than 66.667% of the fragments are controlled by malicious nodes, then in theory, they can eventually generate blocks, but as long as one of the fragments is honest, you can build a mechanism to let honest nodes fight against malicious nodes.

The original source is Hackernoon, and the translation is provided by First.VIP. Please reprint the information at the end of the article.

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