Full Version of Vitalik Buterin's Ethereum Developers Conference Speech

Editor's Note: This article comes fromBabbitt, Author: Helen, published with permission.

Editor's Note: This article comes from

Babbitt

, Author: Helen, published with permission.

On June 29, 2019, the "2019 Ethereum Technology and Application Conference" jointly sponsored by CSDN and Lingtai Technology was held in Beijing.

As the most influential Ethereum technology conference in China, this conference focuses on the ecological panorama of Ethereum, the future development of Ethereum, the actual development of Ethereum, high-quality project cases, etc., and invited the founder of Ethereum Vitalik Buterin, the core Technology developer Hsiao-Wei Wang, well-known project leaders at home and abroad, industry leaders, and Ethereum ecological elite experts discussed the new progress of the Ethereum ecosystem and shared the latest Ethereum development experience.

Vitalik Buterin, the founder of Ethereum, delivered the first speech of this conference with the theme of "Ethereum 2.0 Cross-shard Transactions" amid warm applause. Vitalik introduced the concept and progress of Ethereum 2.0 to developers in detail, and aimed at the topic of "Ethereum performance" that developers are concerned about, introduced the principle of cross-shard transactions to developers, and answered the common questions of developers Got the answer.

In the current chain, all nodes download and verify all transactions, which is safe but severely limits scalability. So we want to improve this situation. In the future, the blockchain will be fragmented, which means that each node only downloads and verifies a part of the transactions.

For example, in the design of Ethereum 2.0, there are 1024 shards, so each node only needs to verify 1/1024 transactions. This change will improve the performance of the blockchain, and may increase the number of transactions per second on Ethereum by 10. 10,000 transactions per second, but this will face a new challenge, which is:

Users and applications are on different shards, how to "communicate"?

Now, all accounts, smart contracts are stored on one computer (meaning Ethereum), and it is very convenient for them to communicate with each other. But if our accounts and contracts are on different shards in the future, it will be difficult to have immediate dialogue and communication.

Therefore, the design of Ethereum 2.0 does not allow each node to process all transactions and information. We have 1024 shards, and each shard is equivalent to a short chain. Each shard has its own consensus algorithm. . A transaction is issued on one shard, and then every 6 minutes, each shard "communicates", that is, the hash value of other shards is discovered. The beacon chain manages the consensus algorithm and cross-shard communication.

"Asynchronous" transaction This is what I designed before. For example, I have 5 coins, and then I want to transfer it to Bob, Bob has an account, his account is at the bottom, and mine is at the top. First of all, I want to make a transaction request at the top. This transaction will be processed in the first shard, and then generate a hash value, but it will not be completed immediately, and then we can put it in the shard at the bottom. When it is validated on the bottom shard, the transaction can be processed.

For example, if you want to book a train ticket and a hotel, of course you want them to be booked together. It doesn’t make sense if there is only one without the other. What if the train and hotel are in different shards?

We imagine two smart contracts, one contract is used to book train tickets, and the other is used to book hotels. If any of these fails, we can reverse the transaction. But since the two contracts are in different shards, it is more difficult to ensure consistency.

One of the solutions is "yank", each train ticket has a contract, each room has a contract, so that each contract can represent our ability to book a seat or book a room. What can we do now? Initiate a contract in a "yank" whose function is to use one contract at a time. Pull a contract from the hotel shard, pull another contract from the train ticket, and book the two shards at the same time. And if you give up booking, and others still want to book, you can "yank" into their contract. It's an automatic process, either order both or neither.

But imagine that we need to spend 5 minutes to let one shard know the data or hash value of another shard, but we want this application to be faster.

For example, initially Alice has 10, Bob has 20, and Charlie has 52, we compress these and store them. There are two situations, one is that bob has 20 coins, and the other is that Bob has 25 coins after. If we see on the wallet that the root above is R, we can make a guess in the following shards, that is, Bob has 25 coins, so he can take 25 coins to others.

But during this process, our calculations are not finalized, although it seems that the transaction has been completed. Then you may ask, it seems that Bob has these coins, but he has not spent these coins. Let's say Bob wants to send 25 coins to Charlie, what will he do?

We don't have to think about whether R is real or fake, because Charlie now has 52 coins, so he knows that R must be real. This logic is carried out in the background, and the logical effect is through the wallet analysis of Bob and Charlie. We at least know that such a transaction has occurred. It is very interesting that you can use communication to conduct transactions across blockchains, and you can also let it create applications that allow different blockchains to conduct cross-chain transactions.

We can also achieve other goals, such as synchronous transactions through the Plasma method, transactions can be initiated on any shard, and assets will be stored in the contract, but we will not immediately count the total number of states, and it will take a week to withdraw. At this point, if anyone can prove that state is not valid, they can cancel the withdrawal.

This method can ensure that if we receive the coin and do not make illegal payments, our transaction will be synchronized to the entire blockchain for broadcast. We have two assets, X and Y, and our shards have their own priorities, which may be one transaction before the next.

If we participate in the transaction process, we have assets, and you also want to send transaction information, you can publish it on any shard. If you are the owner of an asset, you can just analyze these shards and assess what the history of these transactions is.

Such a design we call "Active Virtual Machine (OVM)", the assets you own are not transferred immediately, we start a process, do not need to take out the money, it may take a whole week to actually arrive, but if You are a user, you can know why a certain asset cannot be withdrawn immediately, and you have a feeling that this transaction can actually be credited.

The advantage of this is that we will obtain the ability to open transactions, and can also be confirmed in a timely manner, which may be confirmed immediately in 0.5 seconds. If so, the user experience will be very good, similar to the experience provided by the centralized server.

If we publish data from different shards, the logic will be very complicated, the smart contract will also become very complicated, and the user wallet will perform a large number of calculations, which will take longer to calculate.