V God's latest speech: 4 major points to introduce Ethereum 2.0, first review Facebook Libra (full text)

Ethereum 2.0 has 1024 shards, and consensus algorithms and cross-sliced ​​communication are managed by beacon chains. For Facebook Libra, Vitalik believes that it "absolutely" competes with the decentralized blockchain public chain.

This article is intended to convey more market information and does not constitute any investment advice.

On June 29th, the "2019 Second Ethereum Technology and Application Conference", co-organized by CSDN and Lingti Technology, was held in Beijing by the blockchain base camp, ETHPLANET, Mars Finance and Unitimes.

The theme of Ethereum founder Vitalik Buterin (V God) is “Ethernet 2.0 Cross-Slice Trading”, which introduces Ethereum 2.0's core fragmentation technology and beacon chain mechanism.

• Babbitt column | Gold and Bitcoin will continue to fly
• International Monetary Fund IMF report predicts that central banks will issue digital currency in the future
• Why does POW have to be Staking than the original chain? Long or unlock your new "asset" new posture | Bystack Flint Project

Vitalik first introduced the design of 1024 shards used by Ethereum 2.0, and introduced the beacon chain mechanism responsible for managing formula algorithms and cross-slicing transactions. He said that the beacon-related issues are the current research focus, which will fundamentally improve the performance and scalability of Ethereum. The goal of the beacon chain is to increase the performance of Ethereum from the current 10 TPS to more than 10,000 TPS, while increasing the information throughput speed and forming more blockchain applications.

For the problems that may arise in cross-sliced ​​asynchronous transactions, Vitalik introduced a mechanism called “Yank” by taking “booking a train ticket and booking a hotel” as an example. Yank is a technically similar approach to database locking, but it is more widely used to enable faster asynchronous transactions. Later, Vitalik also explained in detail how the fragmentation mechanism can be synchronized in a way similar to the Plasma mechanism.

For reducing complexity, allowing more users to use wallets, improving the convenience of blockchain, performance, application efficiency, etc., Vitalik elaborated on the role of sharding and developer work, and introduced a name. Active virtual machine mechanism for "OVM". Developers need to study the block time and know which block to expose the slice in. However, data is published from different shards, and both logical and smart contracts become complex, and user wallets also require large, high-speed calculations. This is another problem that needs to be solved.

For the overall design and development of Ethereum 2.0, Vitalik summed up four points:

1. First, you need a more general infrastructure, so that everyone can put data on this public chain, which can be calculated more quickly on the chain;

2. The process of using tools for application is more complicated. Different users have different implementation methods, so a global consensus is needed.

3. How to store and how to accurately understand the quantity of a specific coin of a user, which needs to be implemented through further application;

4. In this process, you also need to ensure the simplicity of the entire process, and you need to continuously improve the consensus mechanism to create the underlying protocol with different applications.

After the presentation, Vitalik and his team also accepted an interview with the Mars Financial App to publicly comment on the impact of Facebook Libra. Vitalik believes that Facebook Libra is a big plus for Ethereum and the industry. Its influence, the connected 2 billion users, the existing funds and the developer resources all have huge opportunities. Vitalik said that if Ethereum applications can build bridges connecting Libra and Ethereum, it will bring millions of users.

However, Vitalik also admits that Libra "will definitely" compete with the decentralized blockchain public chain, but will not replace them. Because the decentralized value created by the blockchain company cannot be replaced by the corporate consortium behind Libra. A closer look at the organization behind Libra reveals that many are commercial companies located in the United States. Many people in the world feel uncomfortable with the blockchain projects, decentralized applications and cryptocurrencies managed by these organizations. So there are many opportunities for both systems today.

The following is the full text of Vitalik Buterin's speech, edited by Mars Financial APP, without my confirmation:

Hello everyone!

Now we have to evolve Ethereum to version 2.0 with more shards. There is a lot of work to be done in this area of ​​research on beacon chain related topics. This may be very useful for blockchain trading, increasing its scalability, so that the blockchain concept can be processed from 10 transactions per second, and possibly 10,000 transactions per second, which will increase information throughput. The speed can also be applied to more blockchains.

But there are some challenges for developers. The blockchain now works by having each computer verify all transactions and verifying each node, so security is good, but it's hard to scale because we trade The number is very large, because the transaction speed is determined by a computer, so we want to improve the process, we want to improve its scalability. In this way, each computer only needs to verify a small number of transactions, so that not all nodes have to be verified, and each computer only needs to process one thousandth of the 1000 transactions.

The problem we have to deal with now is that if we see the way the application works now, it will be easy to build other things in this theory. For example, smart contracts and other communication may require 5 applications. Participation, all accounts, smart contracts are stored on a computer, so they are very convenient to communicate with each other. But if we can't do it in a shorter blockchain, because the smart contracts, accounts, and exchange rates in this blockchain are very high, it's hard to make an application talk, making it difficult to talk immediately. communicate with.

So the design of Ethereum 2.0 is not to let every node handle all the transactions and information. We have 1024 fragments, each of which is equivalent to a short chain. Each fragment has its own consensus algorithm. Communication is managed in different segments. Each segment communicates with other segments. It is exchanged by contract and will occur every 6 minutes. Therefore, every 6 minutes each segment has the opportunity to know the hash value and most recently. What happened and so on.

In addition, the previous chain scalability has been limited, so we can choose, or the chain's communication speed is slow, or the scalability is limited, we still have to choose one. In addition, these basic layers focus on data and computing power, etc., the ability of different segments to communicate and communicate, whether they are limited, we can create a mechanism to make them better performance, use efficiency is very high, so users are different Smart contracts can also communicate with each other and are very fast.

First of all, we are the process of asynchronous communication, which I designed before, has been a design process for several years, if you read related articles, such as 2016, there is an article about asynchronous trading. The idea is how to promote the transaction between the segments if we have several shards. For example, I have 5 coins, then I want to transfer these 5 coins to Bob. Bob has an account, its account is at the bottom, my coin is at the top, first I have to make a request for a transaction at the top. This transaction will do the first sharding, then it will have a hash value, of course, it will not be completed immediately, but then we can put it in the bottom shard, it can be at the bottom Fragmentation for verification. After verification, the transaction can be processed.

So there is a message that 5 coins go to Bob, and Bob at the bottom can get 5 coins, it won't happen immediately, because we want to verify, not only the receiver needs to verify, but also other hash values. , data, beacon chains, etc. all need to be verified. We found that the receiver is also part of the shard. It takes 5 minutes for different shards to communicate. So we need to send this transaction in the first step. The second step is to wait a few minutes. The third step is to further process the transaction. Then, the Bob at the bottom can receive the coin, so the Bob account is increased.

There are various cryptocurrencies, including bitcoin, etc. There are different platforms for these digital assets. We find such a transaction, which is actually very powerful. There are many interesting theories and complicated theories to verify the transaction. Whether it is the developer or the processing of java scripts and so on. We found that we understand these mechanisms, but it is very difficult to communicate with customers. We still have a lot to do, but there are restrictions on communication.

The other one is the "train ticket and hotel" problem. For example, if you work in the database, you will understand the corresponding problem. It is very similar to our transaction. We have different ways to solve related problems. You want to travel to a place, we have to buy a train ticket, and we also need to book a hotel. If you can't order one, you have to book two together, so we have to make sure that there are no bookings, or that the hotel and the train ticket are booked together. If there is only a train ticket and no hotel, or just a hotel without a train ticket, it doesn't make any sense to me, it is a waste of money.

So we imagine two smart contracts, one for booking train tickets and the other for booking hotels. The current system solves this very simple. First, the transaction calls the train ticket. For example, we have booked a seat on the train ticket. This contract will reply to your success or failure, and then we will call the hotel where we booked. This place also responds to your success or failure. If one of them fails, then the transaction will not be allowed to proceed during our trading and the entire transaction will be withdrawn. Today we do the same, whether it is booking a train ticket or booking a hotel, one of them fails, we can withdraw the transaction. But in a shorter chain, booking hotels and booking trains are different in the chain, ensuring consistency is even more difficult, because we found that train tickets have been booked in a consistent environment, and we can't revoke them.

One of the solutions is that we have a new mechanism called "Tug", which looks like a brand new idea, but there are many similarities, much like our previous database. So we have a very diverse approach, not a contract to book a hotel, a contract train ticket, now we separate it, each train seat has a contract, each room has a contract, so each contract They are able to represent the ability of us to reserve a seat or a reservation room.

What can we do now? In the "Tug", a contract is issued. Its function is to use one contract at a time. After we take the contract, we get a seat, and then we put the contract in another position.

What should I do to solve the problem of "hotel and train ticket"? The first step, tug, pull a contract from the hotel shard, pull another contract from the train ticket and book two shards at the same time. Now the hotel contract and the train ticket contract are in one place. Just like the previous transaction, you can order together. But if any of these operations fail, then we will not order anything. Or if someone else wants to book a train or book a hotel, go to the shard that you went to before, you can use this contract to "tap" the operation, there will be no obstacles, the two will be ordered together, it is an automatic process, that is Either both are booked, or both are not booked. So many of the blockchain applications are similar, including examples of decentralized asset exchanges, which are very useful for us to improve user operability and blockchain application.

This is another example and an application we can do. Now let's imagine that we use a shorter blockchain, for example, it takes 5 minutes for a slice to know the data or hash of another slice, but we want this application to be faster, so our The practice is to have a coin on the top, and then we want to move the coin to the bottom. I hope that the way it is that the coin can be applied at the bottom, then we don't have to wait.

How to operate specifically? It seems very difficult, we are doing this. For example, just like our previous program, first of all, I want to send Bob 5 coins, I have to trade in the above shards, then I will give me such a proof, it also contains a regional Fragment, then I put it in the following shard, the following shard will record the transaction. And it already knows the root value in the above fragment, so the following fragment does not know whether the above merkle root is legal, but in any case, it integrates the relevant data into its own data packet. If the merkle root records another message, there may be no way to let the following shards know.

What we want to make here is that at first Alice has 10 coins, Bob has 20 coins, and Charlie has 52 coins. We compress these and store them. There are two cases, one is that Bob has 20 coins, and the other is that Bob has 25 coins. If we see that the root above is R, the following shard can be speculated that Bob has 25 coins and can take 25 coins to others.

Even in this state, our calculations have not been finalized. 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? What would it be like to send 22 coins to Charlie? In this case, you can only evaluate and compare the two situations. In this case, Alice still has 10 coins. If it is legal, Bob has 25 coins before, now 25-22, it has only 3 coins. The currency, if not the root is not enough, so Bob still has 200. If the root is right, it will rise from more than 30 to 52.

After the transaction is over, the above shards and the following shard information can be connected. The following shards can record the information of the shards above. We don't have to think about whether R is real or fake. We know that R must be The real Charlie now has 52 coins. This logic is carried out in the background. The logical effect is analyzed by Bob and Charlie's wallet. We at least know that such a transaction has occurred. What's interesting is that for this technology, you can trade in a cross-blockchain, and you can create applications that allow different blockchains to trade across chains.

For example, we assume that there is such an application, the above fragment is the Ethereum blockchain, and the following fragment is another blockchain. If the two collide and collide, we will use the same mechanism. Ensure that they trade, let them conduct timely communications, timely decentralized transactions. This is very important in Ethereum and cross-Ethernet blockchain trading, which makes cross-chain communication more convenient.

We can also achieve other goals, such as we have already done some work, such as the synchronous transaction through the Plasma method, our goal is to first establish the Plasma, hope that data will be published to the shard, all of this data Not necessarily all can be published on the blockchain, but one of the things that ends up is that we still use the same method as Plasma to achieve the same purpose, we will not immediately count the total number of states. We must at least know what the purpose of the owner of the current Ethereum is to trade in any shard, or wait a while to get the assets out. So if there is a conflict, he may want to upload evidence, and the owner can restructure the coin.

This method ensures that if we receive the currency and never make an illegal payment, our transaction will be synchronized to the entire blockchain for broadcast. These transactions have appeared. We have two assets, X and Y. The other transaction is X. It is AC. Our shards have their own priorities. They may conduct a transaction before the next transaction, as well as BG and FM. Wait for the transaction. There are still many transactions, some are legal, some are illegal, and MM is illegal, because it is impossible to achieve in time.

If we have assets in the course of the transaction and you want to send the transaction information, you can post it to any shard. If you are an asset owner, you can just analyze the shards and evaluate the history of these transactions. Some assets do not belong to this transaction process. We can also make similar conclusions.

In the blockchain, we will do less work, such as the user wallet can do more, and it can help us to consider what kind of trading method is reasonable, that is, who pays more attention to each piece, Then what is the corresponding asset for each piece, this is a very good idea.

In order to reduce the complexity and let more users use the wallet, we will greatly improve the convenience, performance and application efficiency of the blockchain. We hope that by using this method to make the more complicated transactions more convenient and simple, this basic strategy Let us make a faster transaction. There is no need for a decentralized consensus layer. We hope to use these user wallets to find out how many coins are currently in our wallet.

Such a design has recently been called "Active Virtual Machine (OVM)". It concludes that your ownership of assets has not been transferred immediately. We started a process that does not require the money to be taken out. It may take a whole week to really Arrived, but if you are a user, you can know why you can't take out an asset right away, and you have a feeling that the deal is actually available.

What do we need to do? It takes 10 seconds to cross-segment transactions. For example, if there are 20 shards participating in the transaction, will the transaction speed increase the block speed? We need to study the block time. For example, the top slice may take 10 seconds, then the next slice is shifted to the right, which is 0.5, then 10.25, then 11.1, then 21.5, etc., and gradually shifts to the right.

The basic principle is that there must be some fragmentation at a certain point in time to a fixed position. First, we must first know in which block the fragment needs to be exposed. The advantage of this is that if we do this, we will get a public trading ability, and we can get timely confirmation. It may take 0.5 seconds to confirm immediately, get the block, and then you can prove it. If done very successfully, the user experience will be very good, just like the experience provided by the centralized server. If we use the second layer method to publish data from different shards, the logic will be very complicated, smart contract. It will also become very complicated, the user wallet will carry out very high speed, a lot of calculations, and how many coins will take longer to calculate, which is a point we need to study.

What is the conclusion I got here? If we want to make a general-purpose blockchain, we must first have a more general infrastructure that allows us to put data on this chain and make faster calculations on this chain. Our process of using tools for application is complex, and different users have different implementations. So the blockchain requires us to have a global consensus on how to store and how to accurately understand the quantity of a particular user's currency, which needs to be implemented through further application; and we need to ensure that the whole The simplicity of the process prevents this process from becoming complex; it requires constant improvement of the consensus mechanism to create underlying protocols with different applications.

This has become a very active research, we are studying how to design the mechanisms just mentioned, let us create different applications above the extended blockchain, it has strong performance, can carry out very fast transactions, even Asynchronous, synchronous transactions can be implemented, and cross-sharding transactions can be implemented. Of course, there are many other good features, such as other encryption methods for further expansion.

Therefore, the second-tier mechanism is closely related to Ethereum 2.0, which can take the blockchain to the next level.

Interactive moments:

Are you optimistic about Ethereum 2.0? Welcome friends to leave a message below~

Source: Mars Finance

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