API/RSS

Social

Explore five aspects of the impact on Ethereum TPS

W3.Hitchhiker

22-07-26 17:40

Read this article in 60 Minutes

AI summary

View the summary

Original title: Components of ETH Transaction Costs

Original author: Xiang, W3.Hitchhiker; Revised by Evelyn, W3.Hitchhiker

Ethereum is known to have its own virtual machine.

What does that mean?

This is what a Bitcoin transaction looks like:

"If Xiao Ming's signature is verified, Xiao Ming will transfer 10 yuan to Xiao Hong's address."

A transaction in Ethereum might look like this:

"When Xiao Ming's signature is verified and Blablablabla conditions are met, 10 yuan from Xiao Ming's account will be transferred to Xiao Hong's account."

The Blablablabla conditions, in fact, can be any logic or any program, where there can be conditional judgments, there can be loops, which Ethereum supports. But here's the problem -- wouldn't it crash all the Ethereum nodes if an unkind-hearted miner packed up a loop and put it in the block?

To prevent this from happening, Ethereum has a cap on the amount of Gas per block and the amount of Gas consumed per computation step.

We can think of Gas roughly as gasoline. For example, a condition judgment requires 10 gas, a signature verification requires 100 Gas, a state read/write requires 10 Gas, and so on... Then, each transaction needs to specify the Gas that will be used for that transaction (and, of course, pay for it). For example, after a transaction, if you write "run 1000 gas", the Ethereum node will execute the transaction, but when the gas consumption exceeds 1000 gas, it will stop regardless of the execution of the transaction step.

For example, if you write an infinite loop, but each loop burns 10 gas, and the upper limit of gas in the block is 10000, you will buy at most 10000 gas for the program, then all nodes will execute 1000 cycles until the gas you give them is burned out and then stop. It doesn't go on forever.

Which brings us to another difference between Ethereum and bitcoin:

In Bitcoin, the most valuable resource on the chain is space -- because a block is 1 meter in size, and it takes an average of 10 minutes to make a block.

However, in Ethereum, the most valuable resource on the chain is GAS, because the GAS per block is capped, and the average block time is fixed, the calculation steps that can be done per unit of time are actually limited, so ETH TPS is also limited.

As a result, Ethereum becomes congested when a large number of people need to make transactions, especially when many transactions are complex.

The ETH TPS

The problems affecting the TPS of ETH can be divided into the following aspects:

- GAS mechanism of ETH

- Transaction costs of ETH

- ETH networks

- Merge processes

- fragmentation chain

1. ETH GAS mechanism

We know that the miner fee consumed in the Bitcoin blockchain is BTC. In order to stimulate the calculation in the Ethereum network, the concept of GAS has been generated in Ethereum. The GAS fee is paid for writing operations on the Ethereum blockchain. Wei is the smallest of these. In the whole process, GAS is paid for sending the Token and calling the contract, and the unit is Wei.

The origin of the Wei

Wei Dai, a computer engineer of Chinese descent, is known for his contributions to cryptography and cryptocurrencies, developing the cryptographic library Crypto++, creating the b-money cryptocurrency system, and co-proposing the VMAC message authentication code algorithm. In 2013, Vitalik Buterin named Wei, the smallest unit of Ethereum, after him. The number one reference resource in the Bitcoin white paper is also David's B-money. Satoshi Nakamoto also tried to contact David many times in the early days of establishing Bitcoin.

Currently, ETH consumes GAS in Gwei, which corresponds to 1 Gwei= 1E9 Wei

The gas limit is the maximum amount of gas you need to start your car.

A more specific expression is:

Gas Price It is the standard amount in Ethereum to calculate the Gwei corresponding to the consumption of 1 GAS. The unit is Gwei.

Gas Limit Is the upper limit unit of gas consumed. The maximum number of GAS that can be used to complete each transaction (GAS limit for a transaction).

Gas Limit Is the upper limit on the total number of Gas a trading platform can use to "pack" a certain amount of transactions into the block. When a node selects a transaction to package, it must ensure that the total number of Gas used by the trading platform in the block does not exceed the block Gas limit after joining the transaction. For a transaction to be packaged, the sum of its Gas Limit plus the Gas limits of other transactions must be less than or equal to the block Gas Limit. Of course, if there is a transaction that cannot be packaged into the current block, there is still a chance that it can be packaged into a later block. The block Gas Limit size is dynamically adjusted and London upgraded to Ethereum to introduce a variable size block Gas Limit. The target size for each block is 15 million Gas, but the block size increases or decreases depending on network requirements until the block limit is 30 million GAS (twice the target block size).

Why is block Gas limit changed

The block size can be adjusted according to the number of transactions on the network. When the network transaction volume is large, the capacity can be automatically expanded.

Prevents malicious for loop attacks by malicious users from paralyzing the network.

By a malicious user accounts continuously transfer limit is very small, make the whole network paralysis, when the transaction cost is very low, negligible, thus the etheric fang introduced the concept of gas, any transfer and intelligent the execution of the contract, all the gas consumes a certain fee, if the gas consumption and the code to continue no longer, This prevents the for loop of malicious code from running so fast that the entire network cannot move on to the next state. Therefore, we know that any computation, storage must be paid for, so as to prevent malicious attack code.

The impact of transaction costs on TPS

When transactions are large, block Gasl IMit will automatically scale up the TPS of Ethereum itself, with a block gas limit of up to 30,000,000 (node default).

2. Transaction costs of ETH

The underlying technology of Ethereum and the design of GAS are both completed by Gavin Wood. For details, please refer to the Yellow Book written by Gavin Wood.

Below is the GAS cost of ETH Yellow Book design.

The screenshot from: https://ethereum.github.io/yellowpaper/paper.pdf

You have to pay to use ETH, and the concept of GAS. In general, every transaction has GAS associated with it -- the cost of sending a transaction consists of two parts: intrinsic cost & NBSP; And & have spent Cost of implementation.

The execution cost depends on how many ETH virtual machine (EVM) resources the transaction requires. The more operations required to execute a transaction, the higher the execution cost.

The inherent cost is determined by the payload of a transaction. There are three types of payloads:

If the transaction is to create a smart contract, the payload is the EVM code that created the smart contract

If the transaction is to call a function of the smart contract, the payload is the input data to execute the message

If the transaction is simply a transfer between two accounts, the load is empty

Inherent cost GAS

Assume that Nzeros represents the total number of bytes with byte 0 in the transaction load; Nnonzeros represents the total number of bytes in the transaction load that are not zero bytes. The inherent cost of the transaction can be calculated by using the following formula, refer to Section 6.2 of the Beige Book:

Intrinsic cost = Gtxdatazero Nzeros + Gtxdatanonzero Nnonzeros + Gtxcreate + Gtransaction + Gasscesslist cost

In Appendix G of the Beige Book, you can see a schedule of expenses associated with creating and executing transactions. The content related to inherent cost is as follows:

Wei Gtransaction = 21000

Wei Gtxcreate = 32000

Gtxdatazero = 4 Wei

Gtxdatanonzero = 16 Wei (from 68 Wei before Istanbul upgrade)

Gasscesslistaddress = 2400 Wei

Gasscessliststorage = 1900 Wei

因为 ETH 是原生的 Token ，没有智能合约，不需要与合约交互，所以 ETH 的转账是最便宜的，只需要 21000 gasl imit 的配置。当 ETH 转账需要附加一些数据时，就可以参考上述公式。

As shown in the figure below, the TP wallet is operated, and two 0 bytes and two non-0 bytes are added during the transfer. According to the above formula:

Intrinsic cost = 21000 + 4 2 + 16 2 = 21040, which corresponds to the gas limit above.

The inherent cost of the transaction must be less than the GAS cap set by the transaction

Knowing the inherent costs, we can understand why a transaction is considered illegal if its inherent costs are higher than the Gas limit. Gas Limit specifies the maximum amount of Gas that can be consumed during the execution of a transaction. If we know the inherent cost is higher than the Gas cap before we even start executing the deal, there is no reason to execute the deal. (This is because the error is reported before the transaction.)

而其他 Token 的转账就会比 ETH 的 21000 gas limit 高很多，这是因为其他 Token 是通过智能合约执行交易，比普通的转账需要更复杂的计算和写入。

The Gas Limit can be adjusted, but if it is too small, the transaction may fail. It is like when the oil price is too high, you take a Coke bottle as the Gas Limit, and you have to run 100 kilometers, but the fact is that you will run out of Gas before you get on the express train. Therefore, if the gas limit is insufficient, the code execution will be interrupted. Still, miners collect gas for their labor.

What is the current TPS range of ETH?

On the afternoon of February 28, 2022, the block gas limit is about 30,000,000, the block out time of Ethereum is about 13 seconds, the minimum transaction cost is 21000, and the corresponding ETH TPS ceiling is about 110. Because there are still a large number of transactions that are not ordinary transfers, They are transactions interacting with contracts, so the actual ETH TPS are only about 10.

Execution cost GAS

In Ethereum, executing transactions changes state -- several transactions are packaged into a block, each of which is equivalent to a list of transactions; When transactions are executed sequentially, a new legal state is printed.

The transaction is executed as follows:

1. Increase the nonce value of the sender account by 1

Each time a transaction is sent, the sender account nonce is increased. This operation is completed at the beginning of the trade execution, and if the trade execution fails, the account nonce value is rolled back.

2. Deduct the transaction prepayment from the sender's account (gas limit gas price)

We deduct the prepayment from the sender's account balance. The mechanism is simple -- the sender pays for the voluntary cost of executing the transaction (gasLimit gasPrice).

3. Determine the GAS value (gas limit-intrinsic cost) that the transaction can be used to execute.

After deducting the inherent costs, what remains is the GAS available to execute the trade.

4. Perform the actions included in the transaction (transfer, invoke, or create a smart contract)

Executing a trade also involves a list of EVM operations, where the only transaction that does not require EVM operations at all is a normal transfer.

Each EVM operation has a corresponding GAS cost; During the execution of the trade, each EVM operation is performed and the corresponding GAS cost is deducted from the available GAS. Until one of two things happens:

Available gas was exhausted and execution failed

At the end of the execution, the available GAS remains, or is just zero

5. Refund the sender via SELFDESTRUCT and SSTORE functions

In Ethereum, the SELFDESTRUCT opcode is used to destroy smart contracts that are no longer needed. For each contract destroyed, the practitioner can charge 24,000 Wei.

Similarly, when the SSTORE opcode is used to write a 0 (valid delete value), the operator is charged 1500 Wei for each 0 written.

The interesting thing about refunds is that they are also capped. This cap ensures that the miner can calculate an upper bound on the computation time needed to execute the trading platform. (More details on GAS fees and refunds can be found in the Ethereum Design Justification article).

It is also important to note that refunds cannot be made until all the operations contained in the trading platform have been executed. Thus any gas that should be returned will not be consumed by the trade execution process, thus avoiding the possibility of _ transactions _ that never run out of gas.

6. Refund any unused GAS to the sender of the transaction

If the upfront payment for the transaction exceeds the GAS used by the trading platform, the sender is entitled to recover the remaining GAS after executing the transaction.

7. Transfer the proceeds of mining to the account of the beneficiary (usually the miner who mined the block containing the transaction)

All Gas used to execute the trading platform is treated as a transaction fee and is earned by the miner. This mechanism incentivizes miners to keep coming out of the blocks and collaborate on cybersecurity in perpetuity.

The operational costs involved in executing transactions refer to the corresponding contents in the Yellow Book below, such as MUL, DIV, ADD, SUB, etc.

EIP solutions related to GAS and TPS:

Eip-5: Adjusts the Gas consumption of RETURN and CALL

Ip-150: Gas cost variation for a large number of IO operations

Ip-158: The status is cleared

Ip-1108: Reduces the cost of ALT_BN128 precompiling Gas

Eip-1283: Gas adjustment of SSTORE opcodes

Ip-2028: Reduce transaction data usage costs

Eip-2200: Structured definition of net Gas metering

Ip-2565: specifies the cost of ModExpGas

Eip-1559: Pricing market changes for ETH 1.0 chain

Ip-2929: Increased Gas cost for status access opcodes

Ip-1077: Gas relay for contract calls

IP-1087: Gas metering for SSTORE operations

Ip-1285: Adds GcallstipendGas to the CALL opcode

Eip-1380: Reduced Gas cost for internal calls

Ip-1613: Network of Gas stations

Eip-1930: CALL with strict Gas semantics

Ip-2045: Granular Gas cost of EVM opcodes

Ip-2046: Reduces Gas cost for static calls to precompilation

Eip-2542: New opcodes TXGASLIMIT and CALLGASLIMIT

Ip-3322: indicates the Gas storage opcode of the account

Eip-2780: Reduced internal trading of Gas

Eip-4488: Reduced transaction CallData Gas with total CallData limit

Ip-4844: Fragment Blob transaction

EIP-1559

It was proposed by V God in 2019 and went online on August 5, 2021.

A transaction pricing MECHANISM that includes a fixed per-block transaction FEE that is destroyed and dynamically expands/shrinks the block size to cope with instantaneous blockages.

The transaction sender specifies its fee by providing two values:

"Gas Premium" is added to the "Base Fee" to calculate the GAS Price. The "gas premium" can be set to a low value (e.g. 1 gwei) to compensate miners for uncle rate risk, or to a high value to compete in the sudden high volume. "Gas Premium" will be given to miners.

"Fee Cap" indicates the maximum amount of base fee + gas premium that the transaction sender is willing to pay.

motivation

"The current Ethereum 'maximum auction' fee model is inefficient and costly for users. This EIP-1559 proposes an alternative to this mechanism by tailoring a basic network charge to network requirements, thereby creating better fee-price efficiency and reducing the complexity of client software needed to avoid paying unnecessarily high fees."

In the current Ethereum system, newly submitted transactions must wait to be packaged into the next block by a miner, but these transactions can be incentivized by increasing the Gas Price parameter above the network average to give miners an incentive to package their own transactions. Miners will always want to package the deals with the largest transaction fees into new blocks, so expect the deals that will be bundled into the next block to be those with the highest Gas prices.

The problem with this model is that things can quickly get out of hand during periods of high transaction demand. As the block gets close to full, the cost of getting transactions packaged into the next block (the transaction fee) can rise sharply, as users try to get their transactions packaged at a higher price than others.

Although the current miners have some ability (Note: Such as increasing block gas cap) to increase the number of transactions is packaged in a single block, but this cap can't change soon, and in fact the miners more willing to use the smaller piece, rather than block the gas cap pushed higher (for miners, thanks to uncle piece rate, larger blocks lead to higher risk). Especially if your wallet uses the GAS pricing algorithm so that your transactions are packaged within a specific time frame, you may end up paying a fairly hefty transaction fee to get your transactions packaged into the next (almost) full block.

Eip-1559 introduces the concept of the "base fee" for GAS fees, which is set to adjust dynamically, with a slight increase in the "base fee" when the network exceeds the target GAS usage per block, and a slight decrease when the volume falls below the target. This "base fee" will not go to the miners' pockets, but will be destroyed.

To motivate miners to package transactions, users will also set a "Tip" parameter and a maximum amount they are willing to pay in order to have their transactions bundled into the block, which miners will receive as "Tip".

Due to the "basic" will not according to the demand of network instant change and volatility, so the user to a certain extent, away from the low efficiency of the problems of "the highest price auction" mode (" Tip "cost is still the highest mode), because" the basic fee "will be destroyed, not for the miners, so miners don't have an incentive to try to control the costs. Importantly, this mechanism also attempts to solve one of the major problems wallet developers have encountered in automatically estimating online transaction fees, making them more predictable.

Simple summary

Improving user experience, avoiding too fast increase of gas costs, better market estimation, conducive to the evaluation of L2 operating costs, reduced miners' profits, destroyed more ETH, good ETH and Layer2, but little impact on TPS.

EIP-4488

Proposed by V God in November 2021, it is still in the draft stage (to be discussed and determined).

Reduces the cost of calling CallData Gas for transactions and increases the limit on the total number of transactions calling CallData (Gtxdatazero) in a block.

motivation

Rollups in the short and medium term, and possibly long term, Ethereum's only de-trust extension solution. L1 transaction costs have been very high for a long time, and there is an urgent need to take whatever measures are necessary to help facilitate the migration of the entire ecosystem to rollup. Rollups significantly reduced fees for many Ethereum users: Optimism and Arbitrum often offer approximately 3-8 times lower costs than the Ethereum L1 layer itself, while ZK Rollups, which have better data compression and can avoid including signatures, have approximately 40-100 times lower costs.

Even then, however, the fees are too high for many users. The long-term solution to the chronic shortage of Rollups themselves has been data sharding, which adds about 1-2 MB/ SEC of dedicated data space to the Rollups in the chain. However, data sharding still takes quite a long time to complete implementation and deployment. Therefore, a short-term solution is needed to further reduce Rollup costs and incentivize the entire ecosystem to transition to Rollup-centric Ethereum.

The EIP provides a short-term solution for quick implementation while also reducing security risks.

The gas limit for the current block is about 30000000, and the maximum block size for that block is 30000000/16 = 1875000 bytes. Simply reducing CallData from 16 to 3 will increase the maximum block size to 10 million bytes, which will put unprecedented pressure on the P2P network of Ethereum, so this proposal limits the total size of CallData. The formula is as follows:

Simple summary

The short-term solution, which may also be long-term, is good for the rollup of Layer2, which can greatly reduce the transaction cost of rollup. Non-zero-byte data can be reduced to less than 1/5 of the current cost, and zero-byte data can also be slightly reduced (AB, OP, Zk and others are expected to be reduced to 1/4-1/5 of the current commission), but the impact on ETH L1 TPS will be little, or even reduced, and the block size will be increased. Therefore, this proposal may be implemented at the same time as IP-4444.

The impact of transaction costs on TPS

The related EIP in draft stage of ETH GAS is mainly EIP-4488, which has a great impact on TPS. It is good for the rollup of Layer2, which can greatly reduce the transaction cost of rollup, and the non-0 byte data can be reduced to less than 1/5 of the current cost. 0 bytes can also be slightly reduced (AB, OP, ZK, etc., are expected to be reduced to 1/4-1/5 of the current fee), but it has little impact on ETH L1 TPS, which may be slightly reduced.

3. ETH network

Data between ETH nodes is transmitted through a P2P network. The P2P network of ETH nodes will affect the synchronization speed of block data between nodes, which will limit the growth of TPS.

Devp2p is a set of network protocols that form the Ethereum P2P network. To serve the needs of any network application related to Ethereum.

The system provides discovery and secure communication with other nodes throughout the Internet.

IPFS libp2p & have spent Project, which aims to be a collection of modules for assembling P2P networks from modular components.

It is difficult to compare the two projects because they have different scope and were designed with different goals in mind. Devp2p is an integrated system definition that is expected to be well suited to the needs of Ethereum (although it may be well suited to other applications), while LibP2P is a collection of programming library components that is not specifically designed to serve a single application.

That said, the two projects are very similar in spirit, and DevP2P is adopting parts of LibP2P as it matures.

EIP related to ETH networks:

IP-8: indicates DEVP2P forward compatibility requirements

IP-627: Whisper specification

IP-706: DEVp2p fast compression

Ip-778: Ethereum Node Record (ENR)

Eip-868: V4 ENR extension

Ip-2124: Reduce transaction data usage costs

Eip-2364: ETH/64: FORKID extended protocol handshake

Eip-2464: ETH/65: Deal announcements and searches

Ip-2481: ETH/66: request identifier

Eip-2976: Typed trading based on Gossip

Ip-4444: Limits the historical data of executive-layer clients

EIP-4444

It was proposed in November 2021 by George Kadianakis, LightClient, and Alex Stokes and is currently in the draft stage

motivation

The client stops providing historical receipts over a year on the P2P layer. Customers can trim this historical data locally.

History blocks and receipts currently take up over 400GB of disk space (and growing!). . Therefore, to validate the chain, the user must typically have a 1TB disk.

Historical data is not required to validate new blocks, so once the client has synchronized the end of the chain, the historical data is retrieved only when explicitly requested through JSON-RPC or when the peer attempts to synchronize the chain. By pruning the history, the proposal reduces the hard disk requirements of the nodes. Pruning history also allows the client to remove code that handles history blocks. This means that the executing client does not need to maintain a code path that handles composite changes for each upgrade.

Finally, this change will result in less bandwidth usage on the network as clients adopt a more lightweight synchronization strategy based on PoS.

Simple summary

Cut historical data from a year ago to reduce network bandwidth usage.

Impact of ETH network on TPS

The EIP, which is in draft stage and is related to the network of ETH, will have little impact on TPS.

4. Merger process

Merging refers to the merging of Ethereum beacon chain as the consensus layer and POW chain of the main network used by most ETH users as the implementation layer. After merging, the implementation layer will give up the existing POW consensus mechanism.

Beacon chain

The beacon chain will manage or coordinate the extended sharding and pledge network. But it won't be like the main Ethereum network of today. Cannot process accounts or smart contracts.

The role of the beacon chain will change over time, but it is a foundational component of the secure, sustainable and scalable Ethereum that is being worked on.

Beacon Chain will introduce POS to Ethereum. This is a new way to help you secure Ethereum. Think of it as a public good that will make Ethereum healthier and earn you more ETH in the process.

Pledging and being a verifier is easier than mining (the way the web is now). This will help make Ethereum more secure in the long run. The more people participate in the network, the more decentralized and secure it becomes.

Initially, the beacon chain will exist separately from the main Ethereum network we use today. But eventually, they will be connected. The plan is to "merge" the main network into a POS system controlled and coordinated by a chain of beacons.

The beacon chain will start in December 2020.

Deprecated for ETH2

The Ethereum protocol is undergoing major changes. The client team is upgrading the protocol and expanding the capacity of Ethereum to meet the needs of users around the world, while increasing the security and decentralization of Ethereum. In addition to protocol development, an extremely important shift in Ethereum is the abandonment of the terms "Eth1" and "Eth2". At the end of 2021, core developers stopped using "Eth1" and "Eth2" and replaced them with "implementation layer" and "consensus layer" respectively. Today, as we highlighted in our Q1 roadmap, Ethereum.org. Do the same about it.

Eth1 executive

For Eth2 consensus layer

Executive management & have spent + Consensus layer & have spent = the etheric fang

Let's find out why.

An overview of

The terms Eth1 and Eth2 (Ethereum 2.0) were phased out

Executive layer (Eth1) and consensus layer (Eth2) are new terms

The roadmap for expanding Ethereum in a decentralized way remains the same

The user does not need to do anything

Where did Ethereum 2.0 come from?

As part of its roadmap, Ethereum has been planning to scale the network in a decentralized manner and transition to PoS & NBSP; (proof of interest). Earlier, researchers worked on these plans separately, but around 2018, they were all incorporated into the "Ethereum 2.0" roadmap.

As part of the roadmap, the existing PoW chain (Eth1) will eventually be deprecated by difficulty bombs. Users and applications will be migrated to the new Ethereum PoS chain (i.e. Eth2).

ConsenSys' Serenity Roadmap, published in early 2019, explains why.

What has changed?

As work on the beacon chain began, it became clear that the phased-in Ethereum 2.0 would take years to fully deliver. This has led to a resurgence of research projects on PoW chains, such as Stateless Ethereum, a paradigm that limits the rate of state inflation by removing states from a network that are no longer accessed.

The growing focus on the long-term sustainability of the PoW chain, coupled with our realization that the Beacon chain will be ready earlier than the rest of the Ethereum 2.0 roadmap, resulted in the "Early Merge" proposal. In this proposal, the existing EVM chain will act as "shard 0" for Ethereum 2.0. This not only speeds up the transition to PoS, but also makes the transition to PoS smoother, as no migration of the application terminal is required.

Shortly after this proposal was published, Danny Ryan, in his article Eth1+Eth2 Client Relationships, discussed how we could do this by leveraging existing Eth1 clients. This will significantly reduce the development effort involved in delivering a consolidated system and take advantage of clients already battle-hardened on the main network. Around the same time, research into Rollups as a viable and safe way to scale up Ethereum proved promising. Rather than spend years waiting for a complex, uncertain scale-up solution, we should focus on Rollups-based scale-up solutions rather than sharding.

Want to read more? Check out Danny Ryan's ETHGlobal talk Eth1 + Eth2 = Ethereum

Why can't we use Eth2?

Thinking mode

One of the main problems with the Eth2 brand name is that Eth2 creates an incomplete mental model for new Ethereum users. They intuitively assume that Eth1 is first and Eth2 is second; Or once Eth2 is created, Eth1 no longer exists. Both ideas are wrong. By not experimenting with the term Eth2, future users will no longer be able to develop this misleading mindset.

inclusive

With the evolution of the Ethereum roadmap, Ethereum 2.0 is no longer an accurate representation of the Ethereum roadmap. Rigorous and accurate vocabulary selection can help the public better understand the content of Ethereum.

To prevent fraud

不幸的是，一些恶意行为者试图利用 Eth2 这一误称来骗用户用 ETH 来兑换 Token 「ETH2」，或者要在 Eth2 升级前，必须以某种方式迁移他们的 ETH。

We hope that the updated terminology will clearly eliminate this element of fraud and make the ecology safer.

Clarification of the pledge

有些质押运营商还把他们在信标链上的 ETH 打上「ETH2」的标签。这可能会带来误解，因为这些服务的用户并不会实际收到」ETH2」 Token 。从来就没有所谓的「ETH2」 Token ；那仅代表用户在特定运营商的押金中的份额。

merge

Initially, the beacon chain operates separately from the main network. The Ethereum main network continues to be secured via POW, even when the beacon chain is in use. POS consensus runs in parallel. The merger is when the two systems finally come together.

Imagine that the Ethereum main network is a train full of tourists running at high speed, and the beacon chain is the same. At the same time, they need to connect with each other and merge into a new train with stronger performance, and the tourists are unaware of the process, so it is very difficult to think about it.

The merger marks the end of the proof-of-work for Ethereum and the start of a more sustainable and environmentally friendly Ethereum era. At this point, Ethereum will be closer to achieving the full, secure and sustainable nature outlined in the Ethereum vision, and users will be unaware throughout.

Once a merger occurs, a pledge will be assigned to verify the Ethereum master network. There will be no need for POW mining, so miners may plough their earnings into the new certificate of ownership system.

Estimated Merger time: The merger time provided on the ETH website is in the third quarter of 2022.

Impact of merging on TPS

After the merger, the main network continues to operate as the execution layer. The average time for block production of POW is about 13 seconds, and after the POS transfer, it will be about 12 seconds for a block, so the block production time will be much more stable. Traditional POW miners may also turn to POS mining, which will improve the demand for ETH and benefit ETH, but after the POS transfer, There will be only a slight increase in TPS for the etheric chain, not a major change.

5, shard

Sharding is the process of horizontally splitting a database to spread the load, a common concept in computer science. In the Ethereum environment, sharding will reduce network congestion and increase transaction volume per second by creating new chains called "shards".

The Ethereum sharding process will be a multi-stage upgrade process, culminating in the sharding chain spreading the network load across 64 new chains.

Low hardware requirements will be maintained to regulate the local running nodes. Sharding will provide Ethereum with more ability to store and access data and is not currently thought to affect executing code.

Characteristics of Sharding

Keeping it decentralized, sharding is a good way to scale. With sharding chains, verifiers only need to store/run data for the shards they are verifying, not for the entire network. This speeds things up and significantly reduces hardware requirements.

Sharding will eventually allow Ethereum to run on a personal laptop or phone. More people will be able to participate in or run clients in sharded Ethereum. This will improve security, and the more dispersed the network, the smaller the range of attacks.

Because of the low hardware requirements, sharding makes it easier for you to run the client yourself, without relying on any mediation services at all.

The details of the sharding chain are discussed

Shard chain version 1: Data availability

When the first shard chain runs, they only provide additional data to the network. They won't process transactions or smart contracts. But when combined with Rollup, they handle a large number of transactions.

Rollup is the "Layer2" technology that exists today. They allow DApps to bundle or "rollup" transactions into individual transactions off-chain, generate cryptographic proofs, and then submit them to the chain. This reduces the amount of data required by the transaction. Combined with all the extra data availability provided by sharding, aggregation can get 100,000 transactions per second.

Shard chain version 2: Code execution

Given the processing power provided by version 1 sharding, is it still necessary to apply sharding to the processing execution? There is a debate in the community. Vitalik Buterin suggests three potential options worth discussing.

(1) No state execution is required

This means that we don't want shards to be able to process smart contracts and just use them as data warehouses.

(2) One part performs sharding

Maybe there is a compromise where we don't need all the shards (64 planned now) to be smarter. We can add this functionality to only a few and leave the rest untouched. This can speed up delivery.

(3) Wait for (ZK) SNARks

This issue was reexamined as the ZK SNARks technique matured and established. Perhaps the ZK SNARks technology needs more slices.