Original Author: Xiang
Original revision: Evelyn
What does that mean?
What does that mean?
This is how a transaction in Bitcoin looks like this:
"If Xiaoming's signature verification passes, Xiaoming transfers 10 yuan to Xiaohong's address."
A transaction in Ethereum may look like this:
"When Xiaoming's signature is verified and meets the blablablabla conditions, transfer the 10 yuan in Xiaoming's account to Xiaohong's account."
The blablablabla conditions can actually be any logic or any program, in which there can be conditional judgments and loops, all of which are supported by Ethereum. But here comes the problem - if an unkind miner packs an infinite loop and puts it in the block, wouldn't it make all the Ethereum nodes crash?
In order to prevent this kind of thing from happening, the Gas upper limit of each block and the amount of Gas that each calculation step needs to consume are set in Ethereum.
We can simply and roughly understand Gas as gasoline. For example, a conditional judgment requires 10 gas, a signature verification requires 100 gas, a state read and write requires 10 gas, etc... Then, each transaction needs to indicate the Gas required for this transaction (of course, you also need to pay ). For example, after a certain transaction, you indicate "running 1000 gas", so the node of Ethereum will execute this transaction, but when the calculation needs to consume more than 1000 gas, no matter whether the transaction steps are executed or not Will stop at the end.
Therefore, an infinite loop will not appear. For example, if you write an infinite loop, but each loop will burn 10 gas, and the gas limit of the block is 10,000, so you buy a maximum of 10,000 gas for this program, then all nodes will execute 1000 loops, stop until the gas you give is burned, and will not loop infinitely.
And this time leads to another difference between Ethereum and Bitcoin:
In Bitcoin, the most precious resource on the chain is space - because the size of a block is 1 M, and it takes an average of 10 minutes to produce a block.
In Ethereum, the most valuable resource on the chain is gas, because the gas of each block has an upper limit, and the average block time is also fixed, and the calculation steps that can be done per unit time are actually limited, so The TPS of ETH is also limited.
first level title
ETH's TPS
The problems affecting the TPS of ETH can be roughly divided into the following aspects:
ETH gas mechanism
Transaction costs in ETH
ETH's network
merge process
first level title
1. The gas mechanism of ETH
We know that the miner's fee consumed in the Bitcoin blockchain is BTC. In order to motivate the calculation in the Ethereum network, the concept of gas was created in Ethereum. All write operations on the Ethereum blockchain need to pay gas Fees, Ethereum defines the currency as 1 ETH, and 1 ETH = 1e18 Wei. Wei is the smallest amount. Throughout the work, gas is required to be paid for sending tokens and calling contracts, and is calculated with Wei as the unit.
The origin of Wei
Wei Dai is a Chinese computer engineer known for his contributions to cryptography and cryptocurrencies. He developed the Crypto++ cipher library, created the B-Money encryption system, and co-proposed the VMAC message authentication code algorithm. In 2013, Vitalik Buterin's Wei, the smallest unit of Ethereum, was named after him. The number one reference resource of the Bitcoin white paper is also David’s B-money. Satoshi Nakamoto also wanted to contact David many times in the early days of Bitcoin.
Currently, the unit of ETH gas consumption is Gwei, corresponding to 1 Gwei=1e9 Wei
Simply put, the gas price is the unit price of gasoline, and the gas limit is equivalent to the maximum amount of gasoline needed to start a car.
A more specific expression is:
Gas PriceIt is the standard amount of Gwei to calculate the consumption of 1 gas in Ethereum, and the unit is Gwei.
Gas LimitIt is the upper limit unit of gas consumption. How much gas is used to complete each transaction (the gas limit of the transaction).
Block Gas LimitIt is the upper limit of the total Gas used by transactions that can "fit" a certain amount of transactions in the block. When a node selects a transaction to be packaged, the node must ensure that after adding this transaction, the total Gas used by the transactions in the block will not exceed the upper limit of the block Gas. For a transaction to be packaged, its Gas Limit plus the sum of the Gas Limits of other transactions must be less than or equal to the block Gas Limit. Of course, if a transaction cannot be packaged into the current block, it still has a chance to be packaged in the following block. The gas limit size of the block is dynamically adjusted, and the London upgrade has introduced a variable-sized block gas limit for Ethereum. Each block has a target size of 1500 0000 gas, but the block size increases or decreases based on network demand until the block limit is 3000 0000 gas (2x the target block size).
Why block gas limit should be changed
The block size can be freely adjusted according to the number of network transactions. When the network transaction volume is large, the expansion can be realized automatically.
Prevent malicious for loop attacks by malicious users from bringing down the network.
The entire network is paralyzed due to the continuous transfer of very small accounts by malicious users. When the transaction fee is very low, it can be ignored. Therefore, Ethereum has introduced the concept of gas. Any transfer and execution of smart contracts will consume A certain fee is gas. If the gas is consumed, the code will not continue to execute, which prevents the for loop of malicious code from being executed continuously, so that the entire network cannot continue to move to the next state. Therefore, we know that any calculation and storage needs to pay costs, so as to prevent malicious attack codes.
The impact of transaction costs on TPS
first level title
2. The transaction cost of ETH
The underlying technology and gas design of Ethereum were completed by Gavin Wood. For details, please refer to the yellow paper written by Gavin Wood.
image description
Screenshot from:https://ethereum.github.io/yellowpaper/paper.pdf
There is a fee for using ETH, as well as the concept of gas. In general, every transaction has gas associated with it - the cost of sending a transaction consists of two parts: the inherent cost and the execution cost.
The execution cost depends on how much ETH virtual machine (EVM) resources are required for the transaction. The more operations required to execute a transaction, the higher its execution cost.
The inherent cost is determined by the transaction load (payload), and the transaction load is divided into the following three loads:
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 smart contract function, the payload is the input data for executing the message
secondary title
Inherent cost gas
Assume that Nzeros represents the total number of bytes in the transaction load whose bytes are 0; Nnonzeros represents the total number of bytes in the transaction load whose bytes are not 0. The inherent cost of the transaction can be calculated by the following formula, refer to Chapter 6.2 of the Yellow Book:
Inherent cost = Gtxdatazero × Nzeros + Gtxdatanonzero × Nnonzeros + Gtxcreate + Gtransaction + Gasscesslist cost
A fee schedule of the costs associated with creating and executing transactions can be found in Appendix G of the Yellow Paper. Among them, the content related to the inherent cost is as follows:
Gtransaction = 21,000 Wei
Gtxcreate = 32,000 Wei
Gtxdatazero = 4 Wei
Gtxdatanonzero = 16 Wei (68 wei before the Istanbul upgrade)
Gasscesslistaddress = 2400 Wei
Gasscessliststorage = 1900 Wei
Because ETH is a native token, there is no smart contract, and there is no need to interact with the contract, so the transfer of ETH is the cheapest, and only requires a configuration of 21,000 gas limit. When ETH transfer needs to add some data, you can refer to the above formula.
As shown in the figure below, the tp wallet is operated, and two 0 bytes and two non-zero bytes are added during the transfer. Calculated according to the above formula:
image description
The inherent cost of the transaction must be less than the gas limit set by the transaction
Once we know the inherent cost, we can understand why once the inherent cost of the transaction is higher than the gas limit, the transaction will be considered illegal. Gas Limit stipulates the upper limit of Gas that can be consumed when a transaction is executed; if we know that its inherent cost is higher than the upper limit of Gas before executing the transaction, then we have no reason to execute the transaction. trade. (This is because an error will be reported before the transaction)
The transfer of other tokens will be much higher than the 21,000 gas limit of ETH, because other tokens execute transactions through smart contracts, which require more complex calculations and writing than ordinary transfers.
Although the Gas Limit range can be adjusted, if you fill in too little, the transaction may fail, just like the price of oil is high, but you use a Coke bottle as a fuel tank and you have to run 100 kilometers, but the fact is that you haven’t been on the highway yet The car has no gas, so if the gas limit is not enough for the miners to consume, the code execution will be interrupted. Even so, the miners will still collect the labor fee gas~
What is the approximate range of ETH's current tps?
On the afternoon of February 28, 2022, the block gas limit is about 30,000,000, the block generation time of Ethereum is about 13 seconds, the minimum transaction cost is 21,000, and the upper limit of tps corresponding to ETH is about 110. transactions, but transactions that interact with contracts, so the actual tps of ETH is only more than 10.
Execution cost gas
In Ethereum, executing transactions will change the state—several transactions are packaged into a block, and each block is equivalent to a transaction list; when the transactions are executed in order, a new legal state will be output.
Transactions are executed in the following steps:
Increment the nonce value of the sender account by 1
Every time a transaction is sent, the sender account nonce is incremented. This operation will be completed at the beginning of the transaction execution. If the transaction execution fails, the account nonce value will be rolled back.Deduct the transaction upfront amount ( gas limit × gas price ) from the sender's account
We will deduct the transaction prepayment amount from the sender's account balance. This mechanism is simple - the sender pays for the voluntary execution transaction cost (gasLimit × gasPrice).Determine the gas value that the transaction can be used for execution (gas limit - intrinsic cost)
After deducting the inherent costs from the total gas limit of the transaction, what is left is the gas available to execute the transaction.Execute the operation contained in the transaction (transfer, call or create a smart contract)
Executing a transaction also involves a list of EVM operations, and the only transaction that doesn't require any EVM operations at all - is the normal transfer.
Each EVM operation has a corresponding gas cost; during transaction execution, each time an EVM operation is performed, the corresponding gas cost will be deducted from the available gas. Do not stop until one of the following two conditions occurs:Available gas is exhausted, execution failed
After execution, there is still available gas left, or it is just zero
Refund 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 executor can collect 24,000 Wei.
Similarly, when using the SSTORE opcode to write 0s (effectively delete values), the operator can charge 1500 Wei for each 0 written.
One interesting thing about refunds is that there is also a cap on refunds. This upper bound ensures that miners can figure out an upper bound on the computation time required to execute a transaction. (More detailed instructions on gas fees and refunds can be found atEthereum’s Rationality by Designfound in the article).
Another important point is that the refund will only be made after all the operations included in the transaction have been executed. Therefore, any gas that should be returned will not be consumed by the transaction execution process, thereby avoiding the possible _transaction that will never run out of gas_.refund any unused gas to the transaction sender
If the upfront payment used for the transaction exceeds the gas used by the transaction, the sender has the right to reclaim the remaining gas after executing the transaction.Transfer mining proceeds to the beneficiary account (usually belonging to the miner who dug up the block containing the transaction)
All the Gas used to execute the transaction is considered as a transaction fee and is obtained by the miners. This mechanism encourages miners to continue to produce blocks and cooperate continuously at the level of network security.
Refer to the corresponding content in the Yellow Book below for the operation costs involved in executing transactions, such as MUL, DIV, ADD, SUB, etc.
EIP schemes related to gas and tps:
EIP-5: Adjust the gas usage of RETURN and CALL
EIP-150: Gas cost changes for a large number of IO operations
EIP-158: State Cleanup
EIP-1108: Reduce alt_bn128 precompiled Gas cost
EIP-1283: Gas adjustment for SSTORE opcode
EIP-2028: Reduce transaction data usage costs
EIP-2200: A Structured Definition of Net Gas Metering
EIP-2565: Specify ModExpGas cost
EIP-1559: Fee Market Changes for the ETH 1.0 Chain
EIP-2929: Increased gas cost for state access opcodes
EIP-1077: Gas relay for contract calls
EIP-1087: Gas metering for SSTORE operations
EIP-1285: Add GcallstipendGas to CALL opcode
EIP-1380: Reduced Gas cost for internal calls
EIP-1613: Gas station network
EIP-1930: CALL with strict gas semantics
EIP-2045: Granular gas cost for EVM opcodes
EIP-2046: Reduced gas cost for static calls to precompile
EIP-2542: New opcodes TXGASLIMIT and CALLGASLIMIT
EIP-3322: Account Gas storage opcode
EIP-2780: Reduce internal transaction gas
EIP-4488: Reduce transaction calldata gas and total calldata limits
EIP-4844: Sharded Blob Transactions
EIP-1559
It was proposed by V God in 2019 and will be launched on August 5, 2021.
A transaction pricing mechanism consisting of a fixed per-block transaction fee that is burnt and dynamically expands/contracts the block size to account for instantaneous congestion.
A transaction sender specifies its fee by providing two values:
The "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 a high value to compete in sudden high transaction volumes. "gas premium" will be given to miners.
motivation
motivation
"The current "top price auction" fee model in Ethereum is inefficient and costly to users. This EIP-1559 proposes an alternative to this mechanism by adjusting a base network fee based on network demand so that Create better fee price efficiencies and reduce 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 increased by increasing the Gas Price parameter to make it higher than the network average, thereby incentivizing miners to package their own trade. Miners always want to include the transactions with the largest transaction fee into the new block, so the transactions expected to be included in the next block are always those with the highest gas price.
The problem with this top-price auction model is that things can quickly get out of hand during periods of high transaction demand. When a block is close to being full, the cost of getting transactions included in the next block (transaction fees) can rise sharply, as users try to get their transactions included at a higher price than others.
Although the current miners have some ability (note: such as increasing the upper limit of block gas) to increase the number of transactions packaged in a single block, this upper limit cannot be changed soon, and in fact miners are more willing to use more Small full blocks instead of pushing the block gas limit higher and higher (for miners, larger blocks bring higher risks due to the uncle block rate). Especially if your wallet uses a gas pricing algorithm such that your transaction gets included within a certain time frame, you may end up paying a pretty high transaction fee to get your transaction included into the next (Almost) full blocks.
EIP-1559 introduces the concept of "base fee" (basic fee) for gas fees. This fee is set to be adjusted dynamically. When the network exceeds the target gas usage per block, the "base fee" will increase slightly , and the "base fee" will drop slightly when the quantity is below the target. This "base fee" will not go to the miner's pocket, but will be destroyed.
In order to motivate miners to package transactions, users will also set a "Tip" (tip) parameter, and set a maximum amount they are willing to pay in order to have their transactions included in the block, and miners will receive this "Tip" (tip).
Since the "base fee" does not fluctuate violently according to the instantaneous changes in network demand, users are somewhat away from the inefficiencies brought about by the "top price auction" model (the "Tip" fee is still the top price model), because The "base fee" is burned instead of being given to miners, so that miners have no incentive to try to manipulate transaction fees. Importantly, this mechanism also attempts to solve a major problem that wallet developers have with automatically estimating network transaction fees, making transaction fee estimates more predictable.
brief summary
Improve user experience, avoid excessive gas cost growth, better estimate the market, benefit the evaluation of L2 operating costs, reduce miners' profits, destroy more ETH, benefit ETH and layer2, but have little impact on tps.
EIP-4488
It was proposed by V God in November 2021, and it is still in the draft stage (to be discussed and confirmed)
motivation
motivation
Rollups are the only trustless scaling solution for Ethereum in the short, medium, and possibly long term. L1 transaction fees have been very high for a long time, and there is an urgent need to do whatever is necessary to help facilitate the migration of the entire ecosystem to rollup. Rollups significantly reduce fees for many Ethereum users: Optimism and Arbitrum often offer ~3-8x lower fees than Ethereum's L1 layer itself, while ZK rollups that have better data compression and can avoid including signatures cost ~ 40-100 times lower fees.
Even then, however, the fee is too expensive for many users. The long-term solution to the chronic inadequacy of rollups themselves has been data sharding, which will add ~1-2 MB/sec of dedicated data space for rollups in the chain. However, data sharding still takes a considerable amount of time to implement and deploy. Therefore, a short-term solution is needed to further reduce rollup costs and incentivize the entire ecosystem to transition to a rollup-centric Ethereum.
This EIP provides a short-term solution that can be quickly implemented while reducing security risks.
The gas limit of the current block is about 30000000, and the maximum block size of that block is 30000000 / 16 = 1875000 bytes. Simply reducing the calldata from 16 to 3 will increase the maximum block size to 10000000 bytes, which will put the Ethereum P2P network under unprecedented pressure, so this proposal limits the total size of calldata. The formula is as follows:
brief summary
secondary title
The impact of transaction costs on TPS
first level title
3. ETH network
The data between ETH nodes is transmitted through the P2P network. The P2P network of ETH will affect the synchronization speed of block data between nodes, so it will also limit the growth of TPS.
Devp2p is a set of network protocols that form the Ethereum P2P network. Serving the needs of any web application related to Ethereum.
The system provides discovery of and secure communication with other nodes throughout the Internet.
IPFSlibp2pproject, intended 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 scopes and were designed with different goals in mind. devp2p is an integrated system definition that hopes to serve Ethereum's needs well (although it may also be well suited for other applications), while libp2p is a collection of programming library components that do not specifically serve a single application.
secondary title
EIPs related to the ETH network:
EIP-8: devp2p forward compatibility requirements
EIP-627: Whisper Specification
EIP-706: DEVp2p Fast Compression
EIP-778: Ethereum Node Record (ENR)
EIP-868: v4 ENR Extensions
EIP-2124: Reduce transaction data usage costs
EIP-2364: ETH/64: forkid extension protocol handshake
EIP-2464: ETH/65: Transaction Announcement and Retrieval
EIP-2481: ETH/66: Request Identifier
EIP-2976: Gossip-based typed transactions
EIP-4444: Limit historical data for execution layer clients
EIP-4444
November 2021 presented byGeorge Kadianakis、lightclient、Alex Stokesmotivation
motivation
Clients stop serving historical receipts older than one year on the p2p layer. Clients can prune these historical data locally.
History blocks and receipts currently take up over 400GB of disk space (and growing!). Therefore, to verify the chain, a user typically must have a 1TB disk.
Validating new blocks does not require historical data, so once a client has synchronized the end of the chain, historical data will only be retrieved if explicitly requested via JSON-RPC or when a peer attempts to synchronize the chain. By pruning the history, the proposal reduces the hard disk requirements of the nodes. Pruning historical data also allows clients to remove code that processes historical blocks. This means that executing clients do not need to maintain a code path that handles compound changes with each upgrade.
Ultimately, this change will result in reduced bandwidth usage on the network as clients adopt more lightweight synchronization strategies based on PoS.
brief summary
secondary title
The impact of ETH network on TPS
first level title
4. Merge process
beacon chain
beacon chain
The beacon chain will manage or coordinate the extended sharding and staking network. But it won't be like the Ethereum mainnet today. Cannot handle accounts or smart contracts.
The role of the beacon chain will change over time, but it is a fundamental building block of the secure, sustainable and scalable Ethereum that is being worked towards.
The 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.
miningmining(the way the web is currently) easier. In the long run, this will help make Ethereum more secure. The more people participating in the network, the more decentralized and secure it becomes.
Initially, the beacon chain will exist separately from the Ethereum mainnet we use today. But eventually, they will be connected. The plan is to "merge" the mainnet into a POS system controlled and coordinated by the Beacon Chain.
The beacon chain will start in December 2020.
Abandon 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 global users, while improving the security and decentralization of Ethereum. Aside from protocol development, an extremely important shift in Ethereum is the deprecation of the terms "Eth1" and "Eth2". From the end of 2021, core developers will stop using "Eth1" and "Eth2", and replace them with "execution layer" and "consensus layer" respectively. Today, as we highlighted in our Q1 roadmap,ethereum.orgMake the same change to this as well.
Eth1 → Execution layer
Eth2 → consensus layer
Execution Layer + Consensus Layer = Ethereum
overview
overview
The terms Eth1 and Eth2 (Ethereum 2.0) are phased out
Execution Layer (Eth1) vs. Consensus Layer (Eth2) as new terms
The roadmap to scaling Ethereum in a decentralized way remains unchanged
The user does not need to do anything
Where does 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 (Proof of Stake). Earlier, researchers worked on these plans separately, but around 2018, the above were all included in the "Ethereum 2.0" roadmap.
As part of the roadmap, the existing PoW chain (Eth1) will eventually be deprecated via a difficulty bomb. Users and applications will be migrated to the new Ethereum PoS chain (ie Eth2).
The Serenity Roadmap published by ConsenSys in early 2019 explains the specifics.
What has changed?
As work on the beacon chain began, it became clear that the phased Ethereum 2.0 would take years to fully deliver. This has led to a resurgence of research initiatives on PoW chains, such as Stateless Ethereum, a paradigm for limiting the rate of state inflation by removing states from the network that are no longer accessed.
The growing focus on the long-term sustainability of PoW chains, coupled with our awareness that the Beacon Chain will be ready sooner than the rest of the Ethereum 2.0 roadmap, has led to the “Early Merge” proposal. In this proposal, the existing EVM chain will serve as "shard 0" of Ethereum 2.0. Not only will this speed up the transition to PoS, it will also make the transition of applications smoother, as there is no need for any migration of the application endpoints to transition to PoS.
Not long after this proposal was published, Danny Ryan explored how we could accomplish this by leveraging existing Eth1 clients in his article "The Eth1+Eth2 Client Relationship". This will greatly reduce the development work required to deliver a merged system and take full advantage of the battle-tested clients already on mainnet. Around the same time, research on rollups as a viable and safe way to scale Ethereum proved promising. Instead of spending years waiting for a complex and uncertain scaling solution, we might as well focus on rollups-based scaling instead of sharding.
text
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 will intuitively think that: Eth1 comes first, and Eth2 follows; or once Eth2 is created, Eth1 ceases to exist. Both ideas are wrong. By not using the term Eth2 anymore, future users will no longer form this easily misunderstood mindset.
tolerance
With the upgrade of the Ethereum roadmap, Ethereum 2.0 has become unable to accurately express the meaning of the Ethereum roadmap. Rigorous and accurate vocabulary selection can help the public better understand the content of Ethereum.
prevent fraud
Unfortunately, some malicious actors have tried to exploit the Eth2 misnomer to trick users into exchanging ETH for the token "ETH2," or having to somehow migrate their ETH before Eth2 can upgrade.
We hope that the terminology updated this time can clearly eliminate this fraudulent element and make the ecology safer.
Clarification on Pledge
beacon chain
merge
initial,beacon chainRuns separately from the mainnet. Ethereum mainnet continues to pass POWare protected even if the beacon chain usesPOS consensus runs in parallel. Merging is when the two systems finally come together.
Imagine that the Ethereum mainnet is a train full of tourists running at high speed. The same is true for the beacon chain. It is imperceptible, and it is very difficult to imagine.
The merger marks the end of Ethereum’s proof-of-work and ushers in a more sustainable and environmentally friendly era of Ethereum. At this point, Ethereum will be closer to realizing itsEthereum VisionComprehensive, safe and sustainable as outlined in , and the user will not be aware of the whole process.
Once the merger occurs, stakers will be assigned to validate the Ethereum mainnet.POW mode mining will no longer be required, so miners may invest their income in the new proof-of-stake system.
secondary title
Merger impact on TPS
first level title
5. Fragmentation
Sharding, the process of splitting a database horizontally to spread the load, is a common concept in computer science. In the context of Ethereum, sharding will reduce network congestion and increase transactions per second by creating new chains called "shards".
The sharding process of Ethereum will be a multi-stage upgrade process, and finally the sharding chain will distribute the network load to 64 new chains.
secondary title
Fragmentation Features
Keeping it decentralized, sharding is a great way to scale, and with shard chains, validators only need to store/run data for the shard they are validating, instead of storing/running data for the entire network. This speeds things up and greatly reduces hardware requirements.
Sharding will eventually allow ethereum to run on a personal laptop or mobile phone. More people will be able to participate or run clients in a sharded Ethereum. This will improve security, and the more decentralized the network, the smaller the attack surface.
secondary title
Discussion of the details of the shard chain
Shard Chain Version 1: Data Availability
They will only provide additional data to the network when the first shard chain is running. They will not process transactions or smart contracts. But when combined with rollups, they handle a lot of transactions.
Rollup is a "layer2" technology that exists today. They allow dapps to bundle or “rollup” transactions into a single transaction off-chain, generate a cryptographic proof, and submit it to the chain. This reduces the data required for transactions. Combined with all the extra data availability provided by sharding, you can get 100,000 transactions per second.
Shard Chain Version 2: Code Execution
Given the processing power provided by version 1 sharding, whether sharding also needs to be applied to the processing execution. There are arguments in the community. Vitalik Buterin suggested 3 potential options worth discussing.
(1) Does not require state execution
This means that we will not make shards capable of handling smart contracts but only use them as data warehouses.
(2) Part of the implementation of fragmentation
Maybe there is a compromise where we don't need all shards (64 planned for now) to be smarter. We can add this functionality to only a few and leave the rest alone. This can speed up delivery.
(3) Waiting for (ZK) snarks
secondary title
Fragment estimated time
mergemergesecondary title
The impact of fragmentation on TPS
Original link
