Eth2.0's relayer network and fee mechanism
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans), Author: John Adler, Translator & Proofreader: IAN LIU & A Jian, reproduced by Odaily with authorization.
background
background
Before diving into the relay network, let's review one of Ethereum's main bottlenecks (or lack thereof): state.
In Ethereum, state refers to the collection of account balance, contract code, and contract storage content (in Bitcoin, state refers to the collection of UTXO). Whenever a transaction is executed, the state (~45 GB of incompressible data) is read and written. Earlier, people questioned the native unscalability of the Ethereum computing model; but today, it is the read and write of the state that has become the cost bottleneck for executing transactions, and the I/O performance of the disk has become the bottleneck for running the Ethereum full network. Node constraints.
Please note that in order to be able to execute any transaction according to the stateful paradigm (stateful paradigm), the full node must ensure that all states are always placed in an accessible location (such as memory, swap space). If it is applied to a single blockchain scenario, this may be barely acceptable, but once faced with fragmentation and the reorganization of the committee on the fragmentation, this requirement is very unreasonable. Imagine that every time a verifier is assigned to a shard chain, he has to synchronize all the states on the shard; then this system is equivalent to a single blockchain, except that the block size at this time is equal to the shard block size * number of shards.
secondary title
Sharding and stateless clients
In the stateless client paradigm (formerly known as "storageless"), validators only need to store a compressed blockchain state table (often referred to as an accumulator), greatly reducing the burden of executing transactions. Usually the size of the accumulator is constant (for example: Merkle tree root value of the state), but it may also be logarithmic in size.
The essence of the stateless client is that each transaction is accompanied by the witness data (witness) of the current accumulator, which contains all the information required to execute the transaction. In Ethereum, using Sparse Merkle Tree (SMT, Sparse Merkle Tree) as an accumulator, all state elements involved in a transaction can be included in Merkle tree branches.
In other applications, stateless clients can shorten the initial synchronization time of Ethereum nodes, which is the principle of Beam Sync.
Remarks: There are some cryptographic accumulators (such as RSA accumulators) that perform better than Merkle accumulators, but such accumulators require trusted initialization, or use unverified cutting-edge cryptography techniques, so it is not safe to deploy them on production systems. It will take some time.
But stateless clients have their own challenges: once a Merkle accumulator is used, the witness expires every time a full execution ends. If the model requires that each transaction contain a separate witness, and then execute these transactions sequentially, the witness data of the later transaction will be out of date, and must be able to update its own witness with the completion of each previous transaction. Fortunately, updating the witnesses of these Merkle accumulators involves a zero-hashing overhead approach - if the witness data can be added as an appendage to the "big bag" of transactions, there is no need to update the individual witnesses belonging to each transaction, or it can Integrated into multiple proofs (multiproof).
If all users maintain full nodes and update the witness status in real time, then the stateless client system can be adopted immediately. Unfortunately, in a sharded environment, this means requiring all users to maintain all state on their own shard; this is not only impractical, but, as we mentioned above, it is equivalent to just creating a block with a larger size. Large single blockchain.
To solve the problem, the concept of relayers (also known as state providers) is introduced here. The relayer is responsible for providing the witness required by the user, and charges the user for the service. Unlike users, relayers can focus services on a single shard; however, relayers cannot predict when users need state, so they must ensure that witnesses are updated in time, that is, real-time storage state (so called state provider ) for the user to obtain.
secondary title
Relay Network and Fee Market Proposal
The design space of Ethereum 2.0 Phase 2 is very large, and there have been many proposals for execution modes. Each proposal expresses how to transfer transactions between users and block proposers better through payment, combined with the relay network mechanism. This chapter will summarize the different protocols as concisely and comprehensively as possible, and focus on analyzing their similarities and differences in the relay network and fee mechanism.
Collator proposal (deprecated)
This is an early proposal of Phase 2, which divides the building block of the shard chain into three parts: proposer, collator, and executor. Some proposers are responsible for collecting transactions and packaging them into blocks (also called collations), some proposers are responsible for submitting collations to the chain (turning them into blocks), and finally, the executor gives a new state root based on the proposed collation.
This proposal was never fully studied; therefore, there was no study of the fee payment mechanism either. Apart from other factors, this proposal was abandoned because its incentive mechanism encourages users to become proposers, collaters, and executors at the same time in order to maximize benefits.
Phase 1 and Done
Casey Detrio emphasized in his pioneering blog post "Phase 1 and Done: Data Availability Engine-Ethereum 2.0": In phase 1, as few execution fragments as possible can be added to bridge the data without the need for state fragmentation. piece. In this scheme, shards can do two things: 1) authenticate data (ie insert a series of transactions into a recognized data structure such as a Merkle tree); 2) perform simple stateless operations such as validating Zero-knowledge proofs for sanctioned data.
A data block handler can be defined by uploading the contract to the beacon chain (the contract will be converted to "precompiles" in the future, and then become an "execution environment"). The form of the contract may be The bytecode that can be parsed by the client depends on the content of the entire protocol.
"Phase 1 and Done" sidesteps most of the questions about the fee payment mechanism, because the payment mechanism problem has existed in previous proposals, and will continue to exist, so the proposal instead attempts to define it as the long-term use of Eth2.0. Minimal changes to make and hope to find out soon. Another suggestion is to pay fees through contracts on Ethereum 1.x (block proposers provide processed and available data blocks on Ethereum 2.0, and then we pay to proposer); however, this is doubtful as it would make Ethereum 2.0's usability strongly dependent on Ethereum 1.x.
Phase 2 Proposal 1
Following Detrio's research, Vitalik Buterin put forward a specific new proposal for Phase 2: phase 2 proposal 1. In this proposal, the execution script (originally called "beacon chain contract") is stored on the beacon chain, and ETH can be deposited into the execution script (in order to pay fees), and it will never leave the beacon chain; The state and execution of each shard are completely independent.
Note that their names can be misleading - execution scripts are the rules that define the virtual machine that executes transactions, not the smart contracts we see in Ethereum today. Executing scripts must define data models and opcodes in a way that clients can parse, measure, and encode (such as ewasm code).
In order to pay fees, each execution script is essentially a layer-2 system, and the verifier cannot "know" its internal payment mechanism. This is not a design flaw, but intentional; if shard verifiers are required to parse and calculate different fee mechanisms (which may involve different currencies), this will undoubtedly lead to a significant increase in the difficulty of implementation and the complexity of the economic mechanism, introducing more Weaknesses that can be exploited, or even rendered completely unusable. To a large extent, the arguments against "economic abstraction" can also be used against this type of execution model that defines the types of fees according to the script (Translator's Note: "Economic Abstraction" is also called "Fee Generalization", in The protocol layer supports users and verifiers to customize which tokens are used to pay the handling fee. Some people think that this will make the native token lose its value).
Because validators cannot directly collect fees from executing scripts, they must obtain service fees through other means. This is done with a special (i.e. enshrined type) execution script; anyone can send a transaction that contains the following logic: "If this data using a certain execution script is packaged in a certain time slot in a certain shard, then I Pay this fee to the person who recorded this data block"; the operations here are all done by relayers (also known as operators): relayers are responsible for collecting user transactions, specified according to non-enshrined common execution scripts The fee is charged according to the rules, and then the block proposer (builder) in the shard is paid for the packaged transaction according to the enshrined execution script.
William Villanueva's blog A Journey Through Phase 2 of Ethereum 2.0 gives a perfect summary of the Phase 2 proposals so far.
Phase 2 Proposal 2
Inspired by Detrio's previous work, V God once again proposed Phase 2 Proposal 2, aiming at simplifying Proposal 1, removing the state on the shard chain, and using the beacon chain to track different shards and execution environments (Execution Environment, EE, formerly called Execution Script) different state roots.
The advantage of this design is that different execution environments can choose their own accumulators (for example: sparse Merkle tree, red-black tree, cryptographic accumulator, etc.), unlike the previous proposal, which must respect (enshrine) A form of accumulator.
Now, the general transaction flow is as follows: a user creates a transaction and sends it to a relayer, who adds witnesses (in the form of Merkle branches if using Merkle accumulators) as the user needs to get paid by the user. Then the relayer packages multiple transactions and sends them to the block proposer together, and pays them through the protocol's built-in mechanism, allowing the proposer to package the batch of transactions into the next (shard) block. Like Proposal 1, the "mechanism built into the protocol" here refers to a higher EE (an enshrined EE), which can be recognized by all verifiers.
For verifiers, this scheme reduces their burden to a certain extent, but because the above operations still require some sharding state, and the proposal does not design an in-protocol fee payment mechanism between users and relayers, it has not yet been resolved The whole problem with relay networks. First, using means outside the protocol to make payments weakens user privacy; second, it is not clear how to create a completely off-chain system (that does not depend on another external blockchain) to ensure that users and relayers have a hand-in-hand The money is delivered in one hand (that is, the atomicity of the transaction); third, the potential high risk of using out-of-agreement means for payment, and the high computing power required to become a relayer (because if a relayer wants to serve an EE or a shard, all their state must be stored in order to be able to generate witnesses), may lead to centralization problems - in the worst case, there may only be a few "gatekeeper" relays left between users and the Ethereum 2.0 network By.
Return to transaction buffer pool mode
Vitalik mentioned in the new proposal that allowing relayers to conditionally pay block proposers requires a heavy double commitment method to ensure the atomicity of payment. Therefore, it is better to use a fee market EE to solve all problems. In this proposal, EE will have its own balance. After EE executes a batch of transactions, it will output a receipt, and the high-level EE (enshrined EE) responsible for paying the fee will transfer Ethereum from the EE account to the block proposer based on this data. Thus, the higher EE paying the fee is able to "look back" at the previous receipt and process the transfer. Recharging the EE account may be the responsibility of the relayer (or other stakeholders).
The advantage of this proposal is that there is no need to use any complicated method to coordinate the payment between the relayer and the block proposer, but it does not specify how the user should interact with the relayer, but only recommends the use of payment channels.
Building on the original proposal, Villanueva suggested a return to the transaction buffer pool model. In this case, the relayer only needs to act as a state provider, only providing witnesses without packaging transactions; the block proposer (or more generally, the shard validator) maintains a buffer pool, and the required The witness data to package the transaction. Since each EE can choose different accumulators, EE must declare a fixed method of merging witnesses in advance, so that block proposers can integrate two or more witnesses, such as integrating multiple Merkle branches into one Merkle multi- prove.
Since the state provider only needs to provide a witness (usually in the form of a Merkle branch), many roles are already available for this task: for example, a light client server. More light-client servers can be incentivized to provide witnesses with more convenient tools and lower costs, which can go a long way towards high reliability. Still, it is a headache for users to have to pay state providers using high-friction payment channels.
Phase 2 Alternative Architecture
Not long ago, Vitalik proposed the Phase 2 alternative architecture, intending to completely remove the state of sharding. The key point is that a complete, stateful, and expressive state transition engine (such as EVM) is added to the beacon chain. This engine acts as a "scheduler" that keeps track of the state root of the EE. The scheduler design also enables multi-shard transaction execution: checks shards and time slots in a predetermined order to ensure that multiple transactions across shards to the same EE are executed correctly (by checking the pre-execution state and the post-execution state state root, ignoring any invalid or out-of-order shard blocks).
The fee payment mechanism of this proposal is unchanged from the previous proposal, but since the dispatcher has sufficient capacity to handle EE balance management and receipt consumption, there is no longer a need for a specific payment fee EE to exist.
Shard Chain Simplification Proposal
At the DevCon 5 conference, Vitalik announced a major restructuring of the Ethereum 2.0 architecture, which was inspired by the design of the Near protocol's sharding block - Nightshade. In the new proposal, instead of requiring each shard chain to run independent fork selection rules, blocks and crosslinks are interleaved to generate blocks and crosslinks at a faster rate; blocks in shards follow Beacon chain blocks are generated together, and all shards are cross-connected with every beacon chain block (under normal circumstances). The architecture increases the number of shard cross-links. In response to the increase in the number of cross-links, the number of shards is reduced from 1024 to 64; at the same time, the throughput of each shard is also increased, making the throughput of the entire system volume remains at the original level.
The fundamental change in the above-mentioned thinking mode makes the fee market simpler: since the number of shards is greatly reduced, cross-shard communication is simplified, and users can directly store Ether on each shard and directly propose blocks payment by the recipient (again via the aforementioned proposal to output receipts via EE).
remind
remind
The above discussion about the relay network/fee market in Ethereum 2.0 is not exhaustive:
For users, relayers, and block proposers, everyone needs appropriate payment incentives and services. Users can get the required witnesses by paying, relayers charge fees to provide witnesses, and block proposers charge to package transactions. The way the relayer pays the block proposer (or indirectly through EE) can be declared in the agreement; but the user wants to obtain the witness data while ensuring that the transaction is packaged, and the payment method is not so Simple.
For users, a good payment method should be low-friction, making it easy for them to switch between different relayers. However, depending on the payment channel of the external blockchain, there are pre-payment deposits and requirements for the liveness of the external chain; ideally, the problem of user payment can be solved within the agreement.
Continuing from the previous point, it should make it difficult for relayers to censor users. Unfortunately, witnesses are taken from embedded access lists, so there is no way to prevent relayers from blacklisting.
Validators don't have to "understand" the payment methods inside each EE, as this would be extremely complex and a huge barrier to deployment and establishing an efficient market.
Users are not obliged to maintain full nodes (for example, they do not need to maintain the witnesses they need). We want this proposal to be very friendly to light clients.
Summarize
Summarize
Looking back on the past year, several iterations have been carried out around the research on the relay network and the fee market. We are committed to bringing a good user experience to users and light nodes while reducing the burden on verifiers and ensuring access-free access as much as possible sex. Looking ahead, we hope to see more proposals for Phase 2, further improving and perfecting all aspects of Ethereum 2.0!
Note: Link to the original text:https://medium.com/
