Sudden! V God turns on the AMA answer mode to see what kind of "difficulty" he has encountered.

Editor: Jhonny & Shirley Source: Unitimes

Today, Ethereum founder Vitalik Buterin made an online AMA for fans of the Ethereum Chinese community, but unlike usual, this AMA is completely “bursty”. Let's take a look at what kind of "difficult" V God will face! 🙂

Question 1: What conditions are needed to become an Ethereum 2.0 node?

Vitalik : 32 ETH and regular computers should be enough.

Question 2: If there are more than 32 ETHs? For example, if there is 320 ETH, how do you become a verifier? Is it divided into 10 nodes?

Vitalik : You can only run one Ethereum 2.0 client. The client can manage multiple certifier IDs. But the more certifier IDs the client manages, the more data the client needs to verify. For example, if you pledge 10,000 ETH, you may need a server.

Question 3: The more data you need to store, the more data on the same chain, the more times many verifiers vote (vote)?

Vitalik : This is a feature of the shard . The blocks in the shard are assigned to each certifier ID for voting, so if you have a lot of certifier IDs, you need to verify and sign more blocks.

Question 4: Do 10 certifier IDs have to hold 10 private keys? Or a private key, you only need to manage 10 certifier IDs through 1 client?

Vitalik : Requires 10 private keys. But the client can generate multiple private keys with a private key.

Question 5: It seems that Eth2.0's staking should not include the "delegation" part. If it is not enough for 32ETH, it cannot be delegated to other nodes in a decentralized manner.

Vitalik : After the implementation of Phase 2 of Ethereum 2.0, you can do the commissioning by using smart contracts.

Question 6: What do you mean, after Phase 2, can several people get 32 ​​ETH through one contract and become a single verifier together?

Vitalik : Yes.

Question 7: The threshold for 32ETH is still very high.

Vitalik : 32 This number is set by looking at the efficiency of the client. If the limit is set to 4 ETH, then the number of certifier IDs will be a lot, and the overhead of the Ethereum 2.0 chain will be too high.

Question 8: In theory, the efficiency of the client should also be optimized and improved.

Vitalik : Yes. The efficiency of the client can be improved in two directions: one is to reduce the minimum ETH threshold of the verifier, for example, to 8 ETH, and increase the number of fragments; the second is not to raise these numbers, so that the client becomes more The lower the resource, the more users can run the beacon node.

Question 9: You can share a validator through a contract (popular participation, share voting identity), which is why the scene service?

Vitalik : Let me describe this method a lot. When you open a certifier, you need to set up two public keys: the signed public key and the withdrawald public key. After Phase 2, you do not need to set the withdrawal public key, you can also set the withdrawal contract. The signed private key can withdraw (withdrawal), after the withdrawal is completed, the funds in the verifier are given to the address of the withdrawal contract.

So when you open a new validator, you can first send an e-coin, such as 1 Ethercoin, and set up a withdrawal contract. The rule of this contract is, whoever stores it in it, who can withdraw the amount according to the ratio. For example, if you store 1 ETH in it, then 3 other people store 8, 10, 13 ETH, so there is a total of 32 ETH, so the certifier identity can be activated. After a while, you send the withdrawal transaction, now because the amount of the certifier is 33.6 Ethanol (plus 5%), 33.6 ETH to the contract, the contract rules are assigned 1.05 to you, 8.4, 10.5 and 13.65 ETH to the other 3 Participants. The private key of the signature is yours, and the rules for who can withdraw the amount are contractual. Others can look at the rules of a refiner's withdrawal contract that has not yet been activated. If they think it is reasonable, they can send their coins to the contract. This is the method of delegation.

Question 10: If a node is always running on a slice, can it only store the state of this slice, and the beacon chain?

Vitalik : Yes.

Question 11: For a client with 320,000 ETH, the 10,000 certifier IDs created will be randomly numbered to 1,024 shards. Does the client have to store all the partial data pairs?

Vitalik : Yes. But the most recent plan is not to achieve 1,024 shards, but 64 shards, for a total of 2,048 commits (committees). If you pledge more than 60,000 ETHs, then you need to deal with almost all the blocks. So local tyrants may have to run the server :). But in fact, it is not a lot of data, 2.7 MB / sec, depending on what kind of trading volume the Ethereum 2.0 network will reach. Ordinary trade 5000, the transaction inside the rollup is 150,000.

Question 12: If there is a smart contract transaction that needs to operate with some accounts in each shard, do you need to lock the status of the corresponding account on the 1024 shards? Will this cross-chain operation block all shards from dealing with transactions and consensus?

Vitalik : Not a lock account, it is yank, but the meaning is similar. This will require a lot of gas.

Question 13: In the future, if everyone uses ETH2.0, the magnitude of the overall data is Internet data level (zettabytes), the constant level of the fragment can not handle this level of data, there is no other way to solve this Huge-scale decentralized data storage?

Vitalik : Blockchain is a consensus platform, not a particularly good storage platform, and even fragmentation can't solve this problem. But there are other decentralized storage protocols, such as swarm.

Question 14: What is the final TPS achieved under the ultimate state?

Vitalik : 1 billion users, one transaction per user per day, or 11,500 transactions per second. But we will need several years to reach 1 billion users, so we don't need to work hard to reach 1 million TPS.

Question 15: Is the book of the beacon chain also a normal node storage?

Vitalik : Yes.

Question 16: If there are 1024 shards and there are n transactions, what is the expectation of a cross-segment transaction?

Vitalik : Maybe n/3? I don't know.

Question 17: There is a problem. In Eth2.0, can the user choose which segment to enter?

Hsiao-Wei : Users can choose which shard to use.

Question 18: Are cross-segment transactions going through a beacon chain? If so, can the beacon chain withstand such pressure?

Vitalik : Cross-sliced ​​transactions are propagated through receipts. The beacon chain does not require all cross-sliced ​​data, only merkle root.

Question 19: Is it possible that Eth 1.0 is reserved, 2.0 and 1.0 are implemented across the chain? I always feel that there is a black swan in the 1.0 chain.

Vitalik : The current plan is to let Eth1 and Eth2 coexist for a while, and merge when appropriate.

Question 20: Is the merger turning the 1.0 chain into a piece?

Vitalik : There is a problem with Eth1. Keeping PoW requires a lot of resources and adding a lot of ETH. Ok, my plane is taking off, and I am going to worship Asia.

Question 21 : More concerned about cross-segment transactions. If all the cross-segment transactions go through the beacon chain and then the total amount of cross-slice transactions in all the transactions, then the beacon chain will be under a lot of pressure, and the benefits of the shards will be brought up. where?

The last question was not answered because of V God’s boarding. What do you think about this? Welcome to elaborate in the comment area 🙂

[This article belongs to Unitimes. Please reprint the copyright information. It may not be used in any way without authorization, including reprinting, extracting, copying or mirroring. Unitimes will hold the infringer legally responsible.