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.
- The financial structure of the Ethereum Ecology: How does it work?
- The first strand of the blockchain: Jia Nan Zhi Zhi turned gorgeous on Nasdaq
- I understand the super-book DLT, library, development tools, how many members of the Hyperledger family do you know?
- Explore: Bitcoin and Nash's ideal currency
- "The Eye of the Government" Chainalysis: Most Bitcoin mixed currency transactions are legal transactions
- The latest IMF article: The rise of stable currency, the weak currency will face a huge threat
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.
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. ""