Vitalik: A new way to implement cross-segment trading

On October 29th, Ethereum co-founder Vitalik Buterin released a new proposal for cross-segment trading, a so-called cross-chip transaction, a feature that the Ethereum 2.0 platform needs to implement.

The following is a translation of the proposal:

One of the requirements of Ethereum 2.0 Phase 2 is the ability to quickly move ETH from one slice to another. Although cross-sliced ​​transactions through common receiving mechanisms are possible, since the protocols themselves only need to provide access to the state roots of each slice that are fragmented to each other, cross-sharding ETHs need to be more secure in protocol activities. . The reason is that we need to track how many ETHs are in each shard, and we need an important mechanism to prevent replay problems across shards.

In general, the receipt-based mechanism does solve this problem, but it is implemented by a state tree with a "consumed receipt ID", which adds quite complexly to the current nominal stateless system. in. This receipt ID tree is needed because we allow receipts to be used out of order. That is, if Alice sends a transaction from slice A to slice B, and then Applebaum also sends a transaction from slice A to slice B, then there may be a trade in Appelbaum earlier. The case where fragment B is accepted. This is necessary because the system uses the gas method to process the receipt consumption transaction, and Alice may decide not to pay for the transmission transaction.

• BTC insurance falls below the 9000 mark, risk and opportunity coexist
• Below the Reg A+ and Reg S prices, Blockstack may face further selling pressure
• Analysis: Why is Zcash, which is favored by V God, the worst performer among the three major anonymous coins?

Therefore, there is a question here: Can we use a mechanism for processing receipts in order instead of the mechanism for processing receipts , so that for the "receipt ID of the fragment B received from fragment A last time", we only need Can a variable be incremented?

That is, each slice A maintains its state, and for each of the other slices B, there are two values: (i) a nonce that will be sent from slice A to the next receipt of slice B, and (ii) The nonce of the next receipt of the slice A will be received from the slice B.

The answer to the question "Who pays" is simple: block producers need to process a certain number of receipts from each segment of each block, and limit the rate by charging the source for the receipt. However, there is a major problem here: What happens if a person sends a receipt (which may be accidental or intentional) from all shards to a particular shard, and a denial of service attack?

N fragments send N receipts respectively, which will generate target fragments. Load.

To solve this problem, we can use the following mechanism: each fragment needs to process the highest N receipts in one block (for example, N = 64); if other fragments process less than N, it can use other points. The Merkle proof of the film proves this. Each shard continuously forwards the total number of receipts it has processed to the beacon chain, which is used to provide an updated "gas price" to send the receipt to the shard. For example, the receipt processing queue for each block shard is full, and the price of gas can be increased by 10% to a maximum of N.

This ensures that in extreme cases, the DoS attack ultimately does not increase the length of the accept fragment queue, so each message is processed, but this always sends a transaction that performs the minimum number of cross-sharding activities. Alternatively, the shard needs to publish its EIP 1559 gasprice to the beacon chain to process the block fee; this fee can also be used for this function.

If we have this mechanism for sending ETH cross-shards, we can also use it for the universal receipt sending function to create a powerful cross-sharding trading system.

The main challenge here is that in order to calculate the effect of the receipt, we need someone to voluntarily provide the status of the Merkle verification content. If the full state is not written, this operation cannot be enforced at the protocol level; however, what you can do is add a form requirement: "In order to include your own transaction, you must also provide verification content for the cross-shard receipt in the queue. ""

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