Finance
Specials
On-chain Eco
Entry
Podcasts
API/RSS
Social
Roaming the Ether: Past, Present, Future
Summarized by AI
Original Title: "Roaming the Ether: Past, Present, Future"
Original Author: Hakeen, W3.Hitchhiker; Revised: Evelyn, W3.Hitchhiker
< /p>
One , Ethereum upgrade roadmap M2SVPS
The Merge
In The In the Merge phase, the POW consensus mechanism will transition to POS, and the beacon chain will be merged together. For ease of understanding, we simplify the Ethereum structure to the following diagram:
Here we first define what is sharding: a simple understanding is to split the database horizontally to spread the load The process
After switching to POS: the block proposer and block verifier are separated, and the POS workflow is as follows (according to the above diagram):
< /p>
Submit transaction on Rollup
Validator adds transaction to shard block
Beacon chain selects validator to propose new block
The rest of the verifiers form a random committee and verify the proposals on the shards
Proposing blocks and proving proposals need to be completed in one slot, usually 12s. Every 32 slots constitute an epoch cycle, and each epoch will disrupt the validator order and re-elect the committee.
After the merger, Ethereum will implement proposer-builder separation (PBS) for the consensus layer. Vitalik believes that the endgame of all blockchains will be to have centralized block production and decentralized block verification. Since the fragmented Ethereum block data is very dense, the centralization of block production is necessary due to the high requirements for data availability. At the same time, there must be a way to maintain a decentralized set of validators that can validate blocks and perform data availability sampling.
Separation of miners and block verification. Miners build blocks and submit them to validators. Bid to validators to choose their own block, and then validators vote to decide whether the block is valid.
Sharding is a partition method that can distribute computing tasks and storage workloads in a P2P network. After this processing method, each node does not have to be responsible for processing The transaction load of the entire network only needs to maintain information related to its partition (or shard). Each shard has its own network of validators or nodes.
Security of shards: For example, if there are 10 shard chains in the entire network, 51% of the computing power is needed to destroy the entire network, so destroying a single shard only Requires 5.1% of computing power. Therefore, subsequent improvements include an SSF algorithm, which can effectively prevent 51% computing power attacks. According to vitalik 's summary, turning to SSF is a multi-year roadmap. Even if a lot of work has been done, it will be one of the major changes implemented by Ethereum later, and it is far behind Ethereum's PoS proof mechanism, sharding and Verkle. After the tree is fully rolled out.
The beacon chain is responsible for generating random numbers, assigning nodes to shards, capturing snapshots of a single shard and other various functions, responsible for completing inter-shard communication, and coordinate network synchronization.
The execution steps of the beacon chain are as follows:
The block producer will check the block header and Bids come with commitment.
The block owners (verifiers) on the beacon chain choose the winning block header and bid, regardless of whether the block packager finally generates the block body or not. The winning bid fee will be received unconditionally.
Committee (randomly selected among validators) votes to confirm the obtained block header.
The block packer discloses the block body.
The Surge
The main goal of this route is to promote Rollup-centric expansion. Surge refers to the addition of Ethereum sharding, which is an expansion solution. The Ethereum Foundation claims that this solution will further enable the second-tier blockchain with low gas fees, reduce the cost of rollup or bundled transactions, and Make it easier for users to operate nodes that secure the Ethereum network.
The diagram can still be understood with the following diagram:
Take the operation principle of zkrollup as an example: in zkrollup, it is divided into sorting Sequencer and aggregator. The sequencer is responsible for sorting user transactions and packaging them into batches and sending them to the aggregator. The aggregator executes the transaction, generates the post state root (post state root) from the prev state root, and then generates the proof (proof). The aggregator finally sends the pre-state root, post-state root, transaction data, and proof to L1 The contract on the contract is responsible for verifying whether the proof is valid, and the transaction data is stored in calldata. Zkrollup data availability allows anyone to restore the global state of the account based on the transaction data stored on the chain.
But the cost of using calldata is very expensive, so the entire EIP The -4844 protocol (which may change at any time) proposes to change the size of the transaction block to 1-2MB, laying a solid foundation for future rollup and data sharding. At present, the block size of Ethereum is about 60KB ~ 100KB. Taking EIP-4844 as an example, the block size limit can be increased by 10 ~ 34x. This block format is called a blob (also called a data shard).
The Scourge
< br>
Scourge at this stage is a supplement to the roadmap and is mainly used to solve the problems of MEV. So what are MEVs?
The full name of MEV is Miner Extractable Value / Maximal Extractable Value. Value (Miner Extractable Value)”. This is because in Proof-of-Work, miners master the role capabilities of inclusion, exclusion, and ordering of transactions. However, after the transition to proof-of-stake via merger, validators will be in charge of these roles and mining will no longer apply (the value extraction method presented here will remain after this transition, hence the need for a name change). In order to continue using the same acronym to ensure continuity, while maintaining the same basic meaning, "Maximum Extractable Value" is now used as a more inclusive alternative.
Arbitrage space includes:
By compressing the storage space, the price difference of the gas fee is obtained;
The referee is running ahead: Extensively search the transactions on the mempool, the machine performs calculations locally to see if it will be profitable, and if so, initiate the same transaction with its own address, and Use higher gas fees;
Find liquidation targets: Robots race to parse blockchain data as quickly as possible to determine which borrowers can be liquidated, Then be the first to submit a clearing transaction and collect the clearing fee yourself.
Sandwich transactions: Searchers will monitor the large transactions of DEX in the memory pool. For example, someone wants to buy 10,000 UNI using DAI on Uniswap. Such large transactions can have a significant impact on the UNI/DAI pair, potentially significantly increasing the price of UNI relative to DAI. The searcher can calculate the approximate price impact of the large amount transaction on the UNI / DAI pair, and execute the optimal buy order immediately before the large amount transaction, buy UNI at a low price, and then execute the sell order immediately after the large amount transaction, with the large amount order resulting in a higher price to sell.
MEV flaws:
Certain forms of MEV, such as sandwich transactions, can cause users to experience significant worse. Users caught in the middle face higher slippage and poorer trade execution. At the network layer, frontrunners in general and their frequent participation in gas auctions (when two or more frontrunners gradually increase the gas fee for their own transactions so that their transactions are included in the next block) lead to Network congestion and high gas fees for others trying to run normal transactions. In addition to what happens within a block, MEV may also have detrimental effects between blocks. If the MEV available in a block greatly exceeds the standard block reward, miners may be incentivized to remine blocks and capture MEV for themselves, leading to blockchain reorganization and consensus instability.
Most MEV is extracted by independent network participants called "seekers". Seekers run complex algorithms on the blockchain data to detect profitable MEV opportunities, and there are bots that automatically submit these profitable trades to the network. The MEV issue on Ethereum involved the use of bots to exploit network transactions, causing congestion and high fees.
The Verge
Verge will implement "Verkle trees" (a mathematical proof) and "stateless clients". These technical upgrades will allow users to become network validators without storing large amounts of data on their machines. This is also one of the steps around rollup expansion. As mentioned above, the simple working principle of zk rollup is that the aggregator submits a proof, and the verification contract on layer 1 only needs to verify the KZG commitment in the blob and the generated proof. Here is a brief introduction to the KZG commitment, which is to ensure that all transactions are included. Because rollup can submit some transactions to generate proofs, if KZG is used, then all transactions will be guaranteed to be included to generate proofs.
The Verge is to ensure that the verification is very simple, only need to download N bytes of data, perform basic calculations to verify the proof submitted by the rollup.
It is worth mentioning that there are many solutions for ZK rollup, such as stark, snark or bulletproof. Each scheme has a different approach to proof and verification, so there are trade-offs. SNARKs is currently easier to use than STARKs technology, and the technology is more complete, so many projects use SNARKs at the beginning, but with the iteration of STARKs technology, they will eventually turn to STARKs that are resistant to quantum attacks. Although one of the main improvements of EIP-4844 in order to adapt to rollup in Ethereum is the transaction format blob, which expands the block capacity, the main bottleneck of all current zero-knowledge proofs still lies in the self-proof algorithm. On the one hand, it can be solved by improving the algorithm To prove the problem, on the other hand, to improve the efficiency of the proof by stacking hardware, and thus derived the ZK mining track. Those who are interested can go to this article.
The Purge
The Purge will reduce the amount of space required to store ETH on the hard drive in an attempt to Simplifies the Ethereum protocol and does not require nodes to store history. This can greatly increase the bandwidth of the network.
EIP-4444:
Clients MUST stop serving headers, bodies, and recipients older than one year on the P2P layer. Clients can prune these historical data locally. Preserving the history of Ethereum is fundamental, and I believe there are various out-of-band ways to achieve this. Historical data can be packaged and shared via torrent magnet links or networks such as IPFS. Additionally, systems such as Portal Network or The Graph can be used to obtain historical data. The client should allow the import and export of historical data. Clients can provide scripts that fetch/validate data and automatically import them.
The Splurge
This route is mainly some piecemeal optimization repairs, such as account abstraction, EVM optimization, and random number scheme VDF.
The account abstraction (Account Abstraction, AA) mentioned here has always been the goal that Layer 2 of the ZK system wants to achieve first. So what is account abstraction? After the account abstraction is realized, a smart contract account can also actively initiate transactions without relying on the "meta transaction" mechanism (this was proposed in EIP-4844).
In Ethereum, accounts are divided into contract accounts and external accounts. At present, there is only one type of transaction in Ethereum, which must be initiated by an external address, and the contract address cannot actively initiate a transaction. Therefore, any change in the state of the contract itself must depend on a transaction initiated by an external address. Whether it is a multi-signature account, a currency mixer, or any configuration change of a smart contract, it needs to be triggered by at least one external account.
No matter what application is used on Ethereum, users must hold Ethereum (and bear the risk of Ethereum price fluctuations). Secondly, users need to deal with complex fee logic, gas price, gas limit, transaction blocking, these concepts are too complicated for users. Many blockchain wallets or applications try to improve user experience through product optimization, but with little effect.
The goal of the account-centric solution is to create an account for users based on smart contract management. The benefits of realizing account abstraction are:
The current contract can hold ETH and directly submit transactions including all signatures, and users do not necessarily need to pay gas fees for transactions , depends entirely on the project.
Due to the implementation of custom cryptography, it will not be mandatory to use ESCDA elliptic curves for signatures in the future. In the future, fingerprint recognition, facial recognition, Technologies such as biometrics can be used as a signature method.
This has significantly improved the user's interactive experience with Ethereum.
Second, the modularization of Ethereum
There is a trend of modularization in the entire Ethereum, and the execution layer is in charge of Layer 2 (such as arbitrum, zksync, starknet, polygon zkevm, etc.). They are responsible for executing transactions of users on L2 and submitting proofs. Layer 2 generally uses OP technology/ZK technology. Theoretically, the TPS of ZK technology is much higher than that of OP. At present, a large number of ecosystems are in the OP system, but in the future, with the improvement of ZK technology, more and more applications will be migrated to the ZK department. This section is a detailed description and supplementary why and how of the roadmap.
At present, Ethereum only separates the execution layer. In fact, other layers are still mixed up. In Celestia's vision, the execution layer only does two things: for a single transaction, execute the transaction and change the state; for the same batch of transactions, calculate the state root of the batch. Part of the current execution layer of Ethereum is assigned to Rollup, which is known as StarkNet, zkSync, Arbitrum and Optimism.
Now whether it is optimism, polygon, starknet, zksync, etc., they are all exploring the road of modularization.
Optimism proposes bedrock / op stack, polygon is also developing polygon avail as a data availability layer, and supernets are used to simplify chain creation and share validator sets.
Settlement layer: It can be understood that the Rollup contract on the main chain verifies the validity of the pre-state root, post-state root, and proof mentioned above (zkRollup) Or fraud proof (Optimistic Rollup) process.
Consensus layer: Regardless of PoW, PoS or other consensus algorithms, in short, the consensus layer is to reach a consensus on something in a distributed system, that is, to state A consensus is reached on the validity of the transformation (the former state root is transformed into the latter state root after calculation). In the context of modularization, the meanings of the settlement layer and the consensus layer are somewhat similar, so some researchers have unified the settlement layer and the consensus layer.
Data Availability Layer: Ensure that the transaction data is completely uploaded to the data availability layer, and the verification node can reproduce all state changes through the data in this layer.
What needs to be discriminated here is the difference between data availability and data storage:
Data availability and Data storage is distinctly different, the former being concerned with the availability of data from the latest block release, while the latter is concerned with storing data securely and guaranteeing that it can be accessed when needed.
1. Various Rollups on the settlement layer
From the perspective of the settlement layer, it is currently believed that the focus of rollup is on the ZK system . If the size, gas consumption, and cost of the ZK proof system are improved through the rollup of the ZK system, and combined with recursive and parallel processing, its TPS can be greatly expanded. So let's start with ZK rollup.
With the development of Ethereum expansion, Zero Knowledge Proof (ZKP) technology is considered by Vitalik to be the end of the expansion battle plan.
The essence of ZKP is for someone to prove that they know or have something. For example, I can prove that I have the key to the door without having to take the key out. Proving knowledge of an account's password without having to enter it and risk being exposed is a technology that has implications for personal privacy, encryption, business and even nuclear disarmament. Deepen your understanding with a modified version of Yao's Millionaire Problem: This problem discusses two millionaires, Alice and Bob, who want to know which of them is richer without revealing their actual wealth.
Assuming an apartment rents for $1,000 per month, to qualify as a rental candidate, one would need to pay at least 40 times one month's rent. Then we (tenants) need to prove that our annual income must be more than $40,000. But the landlord didn't want us to find loopholes, so he chose not to announce the specific rent. His purpose was to test whether we met the standard, and the answer was only met or not, and he was not responsible for the specific amount.
There are now ten boxes in increments of $10,000 , marked as $10-100k. Each has a key and a slot. The homeowner walks into the room with the box and destroys 9 keys, taking the key labeled $40k box.
The tenant's annual salary reaches 75,000 US dollars, the bank agent supervises the issuance of the asset certification document, and does not specify the specific funds. The essence of this document is the bank's asset statement Verifiable claim documents. We then drop that file into bins ranging from 10k to 70k. Then when the homeowner uses the 40k key to open the box and sees the verifiable claim documents inside, the tenant is determined to meet the criteria.
The points involved here include that the declarant (bank) issues a certificate of asset compliance, and the verifier (homeowner) verifies whether the tenant is eligible through the key. It is emphasized again that there are only two options for the verification result—qualified or not qualified, and it does not and cannot require the tenant to specify the amount of assets.
We can still use the following picture as an understanding, the transaction is Execute on layer 2 and submit transactions on shards. Layer 2 generally adopts the form of rollup, that is, multiple transactions are packaged into a batch on layer 2 to process transactions, and then submitted to the rollup smart contract of layer 1. This includes the old and new state roots. The contract on layer 1 will verify whether the two state roots match. If they match, the old state root on the main chain will be replaced with the new state root. Then how to verify that the state root obtained after batch processing is correct? Optimistic rollup and zk rollup are derived here. Use fraud proof and zk technology to confirm transactions and verify state roots respectively.
The layer 2 (rollup) here is equivalent to the declarant (bank) in the above example, and its packaging operation is this statement operation, and does not make a statement on the specific amount, but Confirm that the standard is met. What is packaged and submitted to layer 1 is this claimable declaration document. The root of verifying the old and new status is that the homeowner uses the key to verify whether the economic strength of the tenant he expects meets the standard. The state root verification problem is the statement submitted by the bank, how to make the statement to make the problem credible.
Based on the optimistic rollup, that is, the fraud proof, the Rollup contract of the main chain records the complete record of the root change of the internal state of the Rollup, and each (trigger state root changed) batched hashes. If someone finds that the new state root corresponding to a batch is wrong, they can post a proof on the main chain that the new state root generated by the batch is wrong. The contract verifies the proof, and if the verification is passed, all batch processing transactions after the batch processing will be rolled back.
The verification method here is equivalent to that the declarant (bank) submits a verifiable asset declaration document, and then publishes all the asset documents on the chain, and the data must also Open to the chain, other challengers calculate based on the original data to see if there are any errors or forgery in the verifiable asset documents, if there is a problem, they will challenge, and if the challenge is successful, they will claim compensation from the bank. The most important issue here is to allow time for the challenger to collect data and verify the authenticity of the document.
For Rollup using Zero Knowledge Proof (ZKP) technology, each batch contains a so-called ZK-SNARK Cryptographic proof. Banks generate asset declaration documents through cryptographic proof technology. In this way, there is no need to reserve time for the challenger, so the role of the challenger does not exist.
2. The reason why ZK rollup is not as expected< /h4>
At present, the hermez of the polygon series has been released, and the zksync dev mainnet and starknet mainnet have also been launched. But their transaction speed seems to be too far from our theory, especially starknet users can clearly perceive that its mainnet speed is surprisingly slow. The reason is that the zero-knowledge proof technology is still very difficult to generate proofs, the cost is still high, and there is a need to balance the compatibility of Ethereum and the performance of zkevm. The Polygon team also admitted: "The testnet version of the Polygon zkEVM also has limited throughput, meaning it is far from final as an optimized scaling machine."
3. Data Availability Layer
The abstract execution steps of Ethereum are as follows:
In the process of decentralization of Ethereum, we can also see it on The Merge roadmap - go to Centralized validators. The most important of these is to realize the diversity of clients, lower the entry threshold of machines, and increase the number of verifiers. Therefore, if some verifiers whose machines are not up to standard want to participate in the network, they can use the light client. The operating principle of the light node is to ask for the block header through the adjacent full nodes. The light node only needs to download and verify the block header. If the light nodes do not participate, then all transactions need to be verified by the full node, so the full node needs to download and verify each transaction in the block. At the same time, as the transaction volume increases, the full node is under more and more pressure. Large, so the node network gradually tends to be high-performance and centralized.
But the problem here is that malicious full nodes can give missing/invalid block headers, but light nodes cannot falsify. There are two kinds of problems The method is to use the fraud proof at the beginning, which requires a credible full node to monitor the validity of the block, construct a fraud proof after finding an invalid block, and judge it as a valid block header if the fraud proof is not received within a period of time .
But a trusted full node is obviously needed here, that is, trusted settings or honest assumptions are required. However, the block producer can hide some transactions, and the fraud proof is obviously invalid, because the honest node also depends on the data of the block producer. If the data itself is hidden, then the trusted node believes that the submitted data is all data , then naturally no fraud proof will be generated.
In a paper co-authored by Mustarfa AI-Bassam and Vitalik, a new solution - Erasure Coding is proposed. Erasure codes are used to solve the problem of data availability. For example, celestia and polygon avail use reed-solomon erasure codes. But how to ensure that the data transmitted is complete data, combined with KZG commitment/fraud proof.
In the KZG commitment/fraud proof, it can ensure that the block producer publishes complete data, does not hide transactions, and then encodes the data through erasure codes , and then through data availability sampling, so that the light nodes can correctly verify the data.
The data submitted by the aggregator in Rollup is stored on the chain in the form of calldata, because calldata data is cheaper than other storage areas.
Calldata cost in gas = Transaction size 16 gas per byte
The main The overhead is in the cost of calldata, because the cost of storage on the chain is extremely expensive, and this part accounts for as much as 80% to 95% of the cost of rollup.
Because of this problem, we proposed the new transaction format blob of EIP-4844 to expand the block capacity and reduce the gas fee required to submit to the chain.
4. On-chain and off-chain of data availability layer
So how to solve the problem of expensive data on the chain Woolen cloth? There are the following methods:
The first is to compress the size of the calldata data uploaded to L1, and there have been many optimizations in this regard.
The second is to reduce the cost of storing data on the chain, and provide "big blocks" for rollup through Ethereum's proto-danksharding and danksharding. Data availability space, using erasure code and KZG commitment to solve the problem of light nodes. Such as EIP-4844.
The third is to put data availability off the chain. The general solutions for this part include celestia / polygon avail, etc.
According to the location where the data availability is stored, we divide it into the following figure:
< a target="_blank" href="https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3 .amazonaws.com%2Fpublic%2Fimages%2F9982183d-557c-473f-8b44-4bb773ba4e8f_404x302.png" rel="">
Validium's solution: Data availability Putting it off-chain, these transaction data will be maintained by centralized operators, and users need trusted settings, but the cost will be very low, but at the same time there is almost no security. Later, both starkex and arbitrum nova proposed to set up DAC to be responsible for the storage of transaction data. DAC members are well-known individuals or organizations within the legal jurisdiction, and the trust assumption is that they will not collude and do evil.
Zkporter proposes guardians (zksync token holders) to pledge to maintain data availability. If a data availability failure occurs, the pledged funds will be forfeited.
Volition is the user's choice of on-chain/off-chain data availability, and choose between security and cost according to needs.
At this time, celestia and polygon avail appeared. If validium has the requirement of off-chain data availability and fears that the degree of decentralization will be low, which will lead to private key attacks similar to cross-chain bridges, then the decentralized general DA solution can solve this problem. Celestia and polygon avail provide an off-chain DA solution for validium by becoming a separate chain. But through a separate chain, although the security is improved, the cost will be increased accordingly.
The expansion of Rollup actually has two parts, one part is The execution speed of the aggregator, on the other hand, requires the cooperation of the data availability layer. At present, the aggregator is operated by a centralized server. Assuming that the transaction execution speed can reach an infinite degree, the main expansion dilemma is that it is limited by the underlying data availability. The impact on the data throughput of the solution. How to maximize the data space throughput of a data availability solution is critical if rollup is to maximize its transaction throughput.
Going back to the beginning, use KZG commitment or fraud proof to ensure data integrity, expand transaction data through erasure codes to help light nodes sample data availability , to further ensure that light nodes can verify data correctly.
Maybe you also want to ask, how does the KZG commitment work to ensure the integrity of its data? Maybe you can answer it a little bit:
KZG Promise: Prove that the value of a polynomial at a specific position is consistent with the specified value.
KZG commitment is nothing more than a kind of polynomial commitment, which can verify the message without giving a specific message. The general process is as follows:
Transform the data into a polynomial through erasure code and expand it. Using KZG promises to ensure that our extensions are valid and the original data is valid. Then use the extension to reconstruct the data, and finally perform data availability sampling.
The committer (commiter) generates a commitment (commitment) and binds it to the message.
Transmit the bound message to the verifier. The communication scheme here is related to the size of the proof size.
Verifier (verifier), multiple values brought into the finite field to verify whether it is still equal to a (this is the process of usability sampling), the basic principle is the number of verifications The more there are, the higher the probability of being correct.
While Celestia requires validators to download entire blocks, today's danksharding utilizes data availability sampling techniques.
Because the block is partially available, we need to ensure synchronization when reconstructing the block at any time. When the block is indeed partially available, the nodes communicate with each other to piece the block together.
Comparison of KZG commitment and data fraud proof:
You can see that KZG commitment can ensure Extensions and data are correct, while fraud proofs are brought in for third-party observation. The most obvious difference is that fraud proofs need a time interval to respond to observers before reporting fraud. At this time, nodes need to be directly synchronized so that the entire network can receive fraud proofs in a timely manner. KZG is significantly faster than fraud proof, which uses mathematical methods to ensure the correctness of data without a waiting period.
It can prove that the data and its extension are correct. However, since the one-dimensional KZG commitment requires more resources, Ethereum chooses the two-dimensional KZG commitment.
For example, 100 rows and 100 columns, that is 100,00 shares. But every sampling is not a one in ten thousand guarantee. Then expanding four times means that at least 1/4 of the entire share must be unavailable, and you may draw an unavailable share, which means it is really unavailable, because it cannot be recovered. Only when 1/4 is unavailable can it be recovered, it is really effective to find errors, so the probability of drawing once is about 1/4. If you smoke more than ten times, fifteen times, you can achieve a 99% reliability guarantee. Now make choices in the range of 15–20 times.
5, EIP-4844 (Proto-Danksharding)
In the proto-danksharding implementation, all validators and users still have to directly validate the full data availability.
The main feature introduced by Proto-danksharding is a new transaction type, which we call blob-carrying transactions. A transaction with a blob is similar to a regular transaction, except that it also carries an additional piece of data called a blob . Blobs are very large (~125 kB) and are much cheaper than calling data for a similar amount. However, these blobs are not accessible from the EVM (only promises to blobs). And blobs are stored by the consensus layer (beacon chain) instead of the execution layer. This is actually the beginning of the gradual formation of the concept of data sharding.
Because validators and clients still need to download the full blob content, the data bandwidth target in proto-danksharding is 1 MB per socket instead of The full 16 MB. However, since these figures do not compete with the gas usage of existing Ethereum transactions, there are still large scalability gains.
While implementing full sharding (using data availability sampling etc.) is a complex task and remains a complex task after proto-danksharding, But this complexity is contained in the consensus layer. Once proto-danksharding is rolled out, no further work is required from the executive layer client team, rollup developers, and users to complete the transition to full sharding. Proto-danksharding also separates blob data from calldata, making it easier for clients to store blob data in less time.
It is worth noting that all work is done by the consensus layer changes without any additional work performed by the client team, users or Rollup developers.
EIP-4488 and proto-danksharding both result in a long-term maximum usage of about 1 MB per socket (12 seconds). This equates to about 2.5 TB per year, much higher than the growth rate Ethereum needs today.
In the case of EIP-4488, solving this issue requires the history expiration proposal EIP-4444 (mentioned in the roadmap section), which no longer Requires clients to store history longer than a certain period of time.
6. Data Fragmentation
Here, I will explain as much as possible from the perspective of Xiaobai that everyone is discussing during the expansion of Ethereum. So let's go back to sharding, and once again emphasize the one-sided concept of sharding: a simple understanding is the process of horizontally splitting the database to spread the load.
Here, our data sharding has a very important problem. In PBS (the proposer is separated from the block builder, as mentioned in the roadmap The Merge), in the sharding In the shard, each node group only processes transactions within the shard, and the transactions will be relatively independent between the shards. Then, how should users AB and AB be in different shards, how to deal with mutual transfers? Then there is a need for good cross-chip communication capabilities.
The old way is to shard the data availability layer, each shard has independent proposers and committees. In the set of verifiers, each verifier takes turns to verify the data of the fragment, and they download all the data for verification.
The disadvantage is:
Strict synchronization technology is required to ensure that the validators can Synchronization within a slot.
Validators need to collect all committee votes, and there will be a delay here.
And the verifier is under a lot of pressure to download the data completely.
The second approach is to forego full data validation and instead use data availability sampling (this method was implemented later in The Surge). Here are divided into two random sampling methods, 1) block random sampling, sampling part of the data slice, if the verification is passed, the verifier will sign. But the problem here is that there may be cases where transactions are missed. 2) Reinterpret data into polynomials through erasure codes, and then use the characteristics of polynomials that can restore data under certain conditions to ensure the complete availability of data.
The key to "sharding" is that validators are not responsible for downloading all data, and this is why Proto-danksharding is not considered "sharded" ( Although it has "sharding sharding" in its name). Proto-danksharding requires each validator to download all shard blobs in full to verify their availability; Danksharding then introduces sampling, where individual validators only need to download fragments of shard blobs.
Third, Layer 3 of the future of Ethereum
It is regarded as the ZK series Layer 2 that Ethereum expands in the future such as Both zksync and starknet have proposed the concept of Layer 3. A simple understanding is Layer 2 of Layer 2.
High transaction costs on Ethereum are pushing it (L3) to become the settlement layer for L2. It is believed that in the near future, due to the significant reduction in transaction costs, the increasing support for DeFi tools, and the increased liquidity provided by L2, end users will conduct most of their activities on L2, and Ethereum will gradually become the settlement layer.
L2 improves scalability by reducing gas costs per transaction and increasing transaction rates. At the same time, L2s retains the benefits of decentralization, general logic, and composability. However, certain applications require specific customization, which may be better served by a new independent layer: L3!
L3 is related to L2, just like L2 is related to L1. As long as L2 can support the verifier (Verifier) smart contract, L3 can use validity proof to achieve. When L2 also uses validity proofs submitted to L1, as StarkNet does, this becomes a very elegant recursive structure, where the compression advantage of L2 proofs is multiplied by the compression advantage of L3 proofs. Theoretically, if each layer achieves, say, a 1000x cost reduction, then L3 could be 1,000,000x lower than L1 - while still maintaining the security of L1. This is also a real use case for the recursive proofs that starknet is proud of.
Part of the knowledge of "On-Chain and Off-Chain of Data Availability Layer" is needed here. The entire Layer 3 includes:
Rollup (on-chain data availability), validium (off-chain data availability). The two correspond to different application requirements. Web2 companies that are sensitive to prices and data can use validium to put data off-chain, which greatly reduces gas costs on the chain, and can not disclose user data to achieve privacy, allowing companies to complete their own control over data. Using a custom data format, the data business model of the previous enterprise can still run smoothly.
L2 is for extensions and L3 is for custom features such as privacy.
In this vision, there is no attempt to provide "quadratic scalability"; instead, there is a layer in the stack that Help the application scale, and then separate the layers according to the customized functional requirements of different use cases.
L2 is for generic extensions and L3 is for custom extensions.
Custom extensions may come in different forms: specialized applications that use something other than the EVM for computation, whose data Compressing rollups optimized for a specific application's data format (including separating "data" from "proofs" and completely replacing proofs with a single SNARK per block), etc.
L2 is used for trustless expansion (rollup), and L3 is used for weak trust expansion (validium).
Validium is a system that uses SNARKs to verify computations, but leaves data availability to trusted third parties or committees. In my opinion, Validium is grossly underrated: in particular, many "enterprise blockchain" applications may actually be best served by a centralized server running a validium prover and periodically submitting hashes to the chain .
Validium is less secure than rollup, but can be much cheaper.
For dApp developers, there are several options for infrastructure:
Develop a Rollup (ZK Rollups or Optimistic Rollups) by yourself
The advantage is that you can inherit the ecology of Ethereum (users), and its security, but for a dApp team, the development cost of Rollup is obviously too high.
Choose Cosmos, Polkadot or Avalanche
The cost of development will be lower (for example, dydx chose Cosmos), but you will lose the ecology (users) and security of Ethereum.
Develop a Layer 1 blockchain by yourself
Let's compare three situations:
Difficulty/Cost: Alt-layer 1 > ; Rollup > Cosmos
Security: Rollup > Cosmos > Alt-layer 1
Ecology/Users: Rollup > Cosmos > Alt-layer 1
Control: Alt-layer 1 > Cosmos > Rollup
As a dApp developer, if you want to inherit the security and traffic, then you cannot redevelop a chain, you can only choose rollup. However, it is very expensive to develop a layer 2 rollup by yourself, so the appropriate solution is to use the layer 3 SDK to develop an application-specific rollup (application-specific rollup), that is, Layer 3.
Fourth, the future development of Layer 2
Since Ethereum is designed based on the account model, all users are in a whole state Therefore, parallelism cannot be performed in the tree, so the shackles of Ethereum itself make it necessary to strip the execution operation and synthesize multiple transactions of rollup into one transaction, which exists as a settlement layer. Now all the problems are focused on improving the throughput of layer 2. Not only can layer 3 improve transaction throughput, but parallel processing on layer 2 can also greatly increase the throughput of the entire network.
Starknet is also actively exploring the issue of parallelization. Although it is currently proven that the algorithm is still a shackle, it is not expected to become a hindrance in the future. Potential bottlenecks include:
Sequencer tx processing: some sequencer jobs seem to be inherently serial.
Bandwidth: The interconnection between multiple sequencers will be limited.
L2 state size
In the starknet community, members also suggested that the parallel processing method of aptos is very good. As far as Starknet is concerned, the capability of tx parallel sorting inside the sorter is also being promoted.
V. Summary
Ethereum is stripping away the execution layer, all in the direction of its vision of a "global" settlement layer. Although the progress of the entire Ethereum is slow at present, it is because its overall size is too large, and each update involves many interests and trade-offs. However, it is undeniable that Ethereum is undergoing major changes. There are a large number of activities on the chain of Ethereum, the improvement of economic mechanisms, and the scalability of Ethereum 2.0. Its leading innovations such as ICO, Defi, and NFT are worthy of the excitement of the Ethereum community. expect. It is believed that with the deployment of Ethereum nodes in more and more countries, such as the Argentine capital government plans to deploy Ethereum verification nodes in 2023, in the near future, Ethereum will really be able to realize its grand vision.
Original link
欢迎加入律动 BlockBeats 官方社群：
Telegram 订阅群：https://t.me/theblockbeats
Telegram 交流群：https://t.me/BlockBeats_App
Twitter 官方账号：https://twitter.com/BlockBeatsAsia
