On July 13, on the Ethereum research blog, Vitalik Buterin issued a message saying that in the long run (more than a year later), the scalable data layer will be Ethereum 2.0 because it plans a 10 mb / sec data throughput ratio than any Some blockchains are much higher. However, in the short term, we can begin to study these technologies immediately by using existing blockchains (especially those with a transaction cost per byte lower than that of Ethereum) as the data layer. Bitcoin cash (BCH) can be said to fully comply with this standard.
Image source: pixabay
- Funds Fair Win and imitation led to the congestion of Ethereum in the past few days, and the number of confirmed transactions was as high as 120,000.
- Analysis | How will fragmentation technology achieve blockchain expansion?
- Getting Started with Blockchain | Generalized State Channels on Ethereum
- The coin is stolen, and then talk about the ETS attack account of the Ethereum
- Vitalik's latest thinking: what kind of subversive effect the second party payment will bring
- Introduction | Market Development Model and Ethereum 2.0 Development Process
The following is the full text of the V God article:
"Conceptual Background Overview: Two-Level State Plan
There are a number of powerful and efficient extension solutions that rely on a non-scalable computing layer (that is, the current Ethereum chain is sufficient) plus an extensible data layer. The general principle of these techniques is to calculate the state of the Ethereum using interactive computing techniques (such as Truebit). The key is to rely on data layer-guaranteed data availability verification to ensure that fraudulent commits can be detected and severely penalized. We can use this technology to build a highly scalable universal Ethereum virtual machine (EVM) system.
In the long run (more than a year later), the scalable data layer will be Ethereum 2.0 because its planned 10 mb / sec data throughput is much higher than any existing blockchain. However, in the short term, we can begin to study these technologies immediately by using existing blockchains (especially those with a transaction cost per byte lower than that of Ethereum) as the data layer. Bitcoin cash (BCH) can be said to fully comply with this standard for the following reasons:
- High data throughput (32 MB / 600 seconds = 53333 bytes / sec, and Ethereum ~ 8000 bytes / sec)
- Very low commission (and BTC fees are very expensive)
- Thanks to http://btcrelay.org/, we already have all the mechanisms needed to validate the Bitcoin Cash (BCH) block inside Ethereum; we just need to redirect it to the BCH chain and then open it. For example, verifying a BCH block is also quite inexpensive compared to an ETC block.
The BCH community seems to be very friendly to anyone who uses their blockchain to do whatever they want, as long as they pay for the transaction (for example, https://memo.cash)
The main weakness of the BCH blockchain is the 10-minute block time. Unfortunately, this seems unlikely to change. However, the BCH community has a positive interest in using zero-confirmation payments with technologies such as the Avalanche pre-consensus. If these techniques become robust in use cases that prevent recurring costs, we can separate them out to achieve a shorter final time, as shown below. On the Ethernet chain, N "proposers" are randomly selected. We encourage people to send small BCH transactions to these proposers. In our Layer 2 protocol, we require that the data on the BCH chain be valid. It must contain a specific UTXO as one of its inputs, and the UTXO sends them a small amount of BCH payments. Thus, once the offerer issues a transaction, if the BCH's anti-repetitive spending mechanism works, it will prevent the transaction from being replaced. Although this technique may be too complicated to implement in practice, we may only want to be satisfied with using 10 minutes of block time in a full-featured VM until Ethereum 2.0 appears.
Another natural alternative is the Ethereum classic blockchain because it has a faster 14 second block time; however, it has lower scalability (~8kb/sec) than BCH, and It is much more difficult to verify the ETC Workload Proof (PoW). However, ETC can take some changes to reverse the balance. Reducing the cost of calls for calldata (ETH is being planned) will increase the data rate, and adding flyclient support can reduce the cost of header verification to a sufficiently low level that the ETH chain can handle at a lower cost (note, These structures and header validation have been postponed for a day without a big deal, so flyclient is perfect here). ”