This article was written in collaboration with samwilsn and adietrichs, with great help from villanuevawill and the Quilt team.
Introduction
The statelessness of Ethereum 2.0 means that transactions must carry the states they want to access. More precisely, for block proposers (BPs), in addition to transactions, blocks also need to contain all states accessed by all transactions and corresponding witness information. Assuming that neither the user who created the transaction nor the BP stores the state data, the network needs another group to save and provide these states. This role is usually called a state provider (SP).
Regardless of how block proposers and state providers exchange state, users may need to obtain state before creating transactions. For example, by obtaining the bytecode of a contract, estimating gas costs, or checking account balances. This means that state providers need to expose a pull-like interface to users. Although there is no incentive layer, it is also possible to provide state to users by relying solely on selfless state providers (this is what Ethereum 1.0 does), or to implement payments through state channels, adding an incentive layer to state providers.
Comparison criteria
There are many ideas about how to integrate state providers into the overall system. In the following sections, we will briefly introduce several solutions. In addition to the general description, we will also compare the following properties:
Status access restrictions
Because transactions are executed based on the state at execution time, if the underlying state changes, the transaction execution will also change. In particular, for some transactions, the location of the state accessed may change. This may be due to simple jump statements (such as if), or the location accessed is calculated at runtime. We call both cases dynamic state access (DSA). In stateless mode, this complicates the transaction creation process. The problem is that it may not be possible to provide state for these transactions in advance (because it is not known in advance which global state these transactions will access). Different state provider patterns vary in the degree to which they support these transactions.
If a mode restricts dynamic state access, then Eth1 will most likely not be able to become an Eth2 EE and will often require special handling.
Incentives
Compensation for state providers is compared in two ways:
Who pays and how is the compensation calculated?
Are altruistic state providers favored at the outset, and if so, can incentives be added later?
Centralization Risk
The centralization risks of each model are different:
Who can review transactions and to what extent?
How much state can a state provider store? What kind of hardware is required?
What level of mutual trust is required between block proposers and state producers?
Time Constraints
Block producers have a fixed time to broadcast blocks, so we specifically consider how different models perform under this time constraint.
Attributability of lost state
In Eth1, once the signature verification and balance and nonce checks for a given transaction are completed, miners can be sure that they will get the transaction fee for packaging. In Eth2, whether the block proposer can get paid depends on whether the lost state is an attributable fault. If so, the block proposer can still get paid even if a transaction fails due to lost state. Otherwise, the transaction with lost state itself is not packageable, but the block proposer may not find out until all (usually long) transactions have been executed. (Translator's note: The payment here refers to the transaction fee that the block proposer will charge for packaging the transaction. If it is an unattributable fault, the block proposer will spend the cost to package the transaction but will not get the transaction fee in the transaction.) If the block proposer has to run transactions to discover errors, but these transactions are not packaged (i.e., they cannot pay transaction fees), then the block proposer is vulnerable to a denial-of-service attack with almost zero cost.
model
model
Status Access
Incentives
Centralization Risk
Time Constraints
Direct push mode
Restricted
Voluntary donation or payment channel
Highly visible status providers will have an advantage
none
Relay push mode
Unrestricted
Charge by batch or exclusive period
There is a possibility of censorship
A batch of data needs to be updated and transferred within a slot
Pull Mode
Unrestricted
Payment Channels
Highly visible status providers will have an advantage
To request a batch of status in one slot
Direct Push Model
The user directly requests the necessary state from one or more state providers, and then sends the transaction with the state to the network. The node maintains a pool of pending transactions and updates the witness information whenever the network generates a new block. When the block proposer creates a block, a subset of transactions to be packaged is selected from the transaction pool and included in the new block. Status access restrictions The user who creates a transaction essentially becomes the sole state provider for that transaction. In general, there is no way to ensure that the state provided by the user will satisfy all access needs when the transaction is later put on the chain. Therefore, in Direct Push mode, only transactions with predictable state access can be executed. Because transactions can only use static state access, contract creators should also design their contracts to obtain predictable state access: annotations such as access lists can be used to specify the locations that the contract can access during runtime. This approach combined with the pattern of avoiding dynamic state access (see this related blog post proposed by Vitalik in the Eth1.x section) should still provide sufficient functionality. However, this will be very different from the current Eth1 system, and may make the plan to switch from Eth1 to Eth2 go awry. excitation This model relies only on a general network of state providers. As mentioned above, it seems to work without an incentive system. Incentives can also be added via payment channels. This approach would be particularly complex given that every user would have to establish a payment channel with one or more state providers. Centralization Risk It is impossible for a single state provider to censor transactions because users can send multiple queries to multiple state providers. Because the state provider can keep only a portion of the state, the hardware requirements can be reduced as needed. Monetary incentives may drive some state providers to centralize, so users need to trust their counterparties when purchasing state through payment channels. Time Constraints There is no time constraint. Attributability of lost state Lost state can be attributed to the user. In most cases, block providers can package transactions with insufficient state and still let users pay. The only exception is when the state required for initial signature verification or fee payment is also lost, in which case the transaction will not be packaged. Analogous to the case of Eth1, nodes in the network can discard such transactions from the transaction pool. For these initial transaction parts, some restrictions must be imposed to maximize the utilization of Gas. Key Points
Main advantages: Simplicity. No specialized state providers or incentive systems required. No special time constraints.
Main disadvantage: Only works for transactions that know in advance all state access needs. This limits the functionality of the entire system. Although some mitigation measures can be used, the compatibility issues cannot be solved. In particular, Eth1 cannot be the operating environment of Eth2 under this model.
Relayed Push Model
The user sends a transaction to a relayer (professional state provider) on his own initiative. The relayer bundles multiple transactions together and attaches the transaction status, and relays the bundled transaction package to the network. The node maintains a pool of pending transaction packages. Whenever a new block is generated, the relayer relays the updated status for the transaction package, and all nodes update the corresponding witness information. When creating a block, the BP selects the latest pending transaction packages from the transaction package pool and includes them in the new block. Accordingly, the system can still operate even if the transaction package in the transaction package pool is proven to be unusable. The relayer only announces the existence of the transaction package. The block proposer will directly contact the relayer to obtain the transaction package and include it in the new block. Status access restrictions There is no limit. As long as the relayer can push the state to the transaction package in each time slot to ensure that the need for state access can be met, it will be fine. In addition, each new block contains only one data packet to prevent interference between transaction packages. excitation Designing incentive mechanisms for relayers is actually quite complicated, because once the status and witness information are made public, users and/or BPs have the opportunity to bypass the witnesses and recreate transaction packages themselves. Two possible solutions:
Without a transaction pool, transaction packages are not public. Relays sell transaction packages with attached states to block proposers (with a fee slightly lower than the transaction fee), thus forming a transaction package market. There are some risks for block proposers: a transaction may have been included in another block, making it invalid; or the transaction fee received is less than what the relay announced when selling.
Another approach is that transactions can include payments to a specific relayer, with or without a transaction pool. Users commit to an exclusivity period (i.e., a number of time slots) during which they will not create other transactions. If a user signs two or more transactions at the same time during the exclusivity period, they will be punished. To do this, the EE must provide a way to "fine" users. But since users do not lock up a deposit, it is unclear how to fine users who do not have sufficient account balances.
Centralization Risk Centralization risk depends on which relayer incentive mechanism is used:
Assuming that merging transaction bundles is complex (due to dynamic state access), the transaction bundle market leads to high centralization and allows individual relayers to censor transactions. Because of the risks that BPs may suffer listed above, BPs are more likely to work with well-known and trusted relayers. Individual users cannot provide transaction bundles with high enough transaction fees compared to these well-known relayers.
Using exclusivity periods and transaction pools provides a high degree of decentralization, but at the expense of user convenience and a more complex transaction pool implementation. In theory, any user can retrieve a transaction package from the transaction pool, add their own transactions to expand the transaction package, and then relay the transaction package at a higher transaction fee.
Time Constraints In order to support all types of transactions, any transaction package included in a block must contain the latest state. The relayer must download the previous block, create and send the update corresponding to the transaction package to the block proposer, and the block proposer includes the updated transaction package in the new block, all of which must be completed within the time of one slot. Attributability of lost state State loss can be attributed to relayers. Block proposers can ask relayers (or relayers can choose to do so) to attach a "refund transaction" to a transaction, which will refund the block proposer if the transaction fails due to state loss. Key Points
Main advantage: No state access restrictions.
shortcoming:
A single transaction pool may not be enough, as transaction packages are large in size (as opposed to the transaction pool consisting of individual exchanges in Eth1) and have strict time constraints.
Without a transaction pool, transaction packages cannot be combined, so a block can only contain transaction packages proposed by a single relayer. Relays may become centralized and introduce censorship.
Even with transaction pools, it is unclear whether transaction package combination capabilities are sufficient to fully mitigate censorship concerns.
Incentive systems are complex.
Pull Model
Users send transactions to the network, and nodes maintain a pool of pending transactions. Before creating a block, the block proposer selects some pending transactions from the transaction pool, forms a transaction package, and sends it to a status provider to request the status of the transaction package. After receiving the status, the block provider packages the transaction package into a new block. Before the state provider provides all the states, in order for the intermediate nodes and block proposers to verify the validity of the transaction, the user must attach a witness message to the transaction to verify the signature and fee payment ability. Therefore, this part must be standardized in different execution environments (EEs), and all EEs must provide a simplest verification function option. Alternatively, you can use a Value-Holding EE (VHEE). Each transaction uses this VHEE to pay for the fee. Nodes in the network will understand VHEE and can verify the validity of the transaction. In both cases, nodes in the network need to update witnesses of additional state when new blocks arrive. The block proposer cannot predict the actual gas cost of the transaction package. Under special conditions, any transaction in the transaction package may invalidate all subsequent transactions of this transaction, such as reducing the sender's balance to 0. To alleviate this problem, the block proposer will "overbundle", that is, send more transactions to the state provider than they expect to be packaged in the block. The state provider will provide the status of these transactions until the block limit is reached. If VHEE is used, the transaction may also have additional data attached, including a list of VHEE addresses and the maximum amount that can be taken from these addresses. In this way, the block proposer can prevent the previous transaction from invalidating the subsequent transaction. Status access restrictions There are no restrictions on major transactions. Block proposers only contact state providers when creating blocks, ensuring that the returned state is up to date. More importantly, by bundling transactions together and requesting state per transaction bundle, the state is attached in the correct context. This approach ensures that the provided state is always sufficient. This involves a key difference from the Direct Push model, where the state is attached before the transaction is bundled, resulting in limited state access. Because users must include state for signature verification and fee payment capabilities, technically, the restrictions on the transaction part are the same as those listed in the Direct Push model. However, these restrictions are irrelevant in practice. Because signature verification and fee payment are predictable state access in Eth1, compatibility between Eth1 and Eth2 will not be broken. In addition, for VHEE, its design will ensure predictable state access, so there is no need for further restrictions. excitation Block proposers can pay for the state provided by state providers through payment channels or other means. Depending on the trust level of BP and counterparty SP, fees can be paid by the number of transactions (which is trust-minimized) or by transaction packages (which is more efficient) Centralization Risk The state provider must save all states, which requires a lot of storage. It is also expected that the state provider will execute transaction packages quickly, so there are also requirements for computing power. Block proposers may be more inclined to obtain state from a group of state providers they trust, reducing the risk of malicious damage and thus increasing centralization. However, a single state provider cannot censor transactions, as block proposers are responsible for creating and ordering transaction packages. A state provider may hide the state required for a transaction package, but doing so would damage their reputation, and the block proposer can easily retry with another state provider. Time Constraints The block proposer must contact a state provider within a time slot that can provide TA with the state required for the transaction package to be uploaded to the chain. Attributability of lost state State providers are always responsible for the state they provide. Block proposers cannot include transactions with insufficient state in a block, and will only pay after verifying that the state is sufficient. Key Points
advantage:
There are no associated state access restrictions.
There are fewer time constraint issues.
There is no significant centralization risk. While it is expected that some state providers will specialize in providing state to block proposers, no single state provider can significantly interfere with the overall process. The worst thing a state provider can do is not provide state when requested.
Major disadvantage: must do some standardization of signature verification, either via verification scripts, or using VHEE.
Extended discussion
Self-Reliant Witness Information & Gas Costs
If the transaction initiator can provide enough witness information to guarantee their balance, can state access be cheaper? If the witness information is also placed in the transaction and signed, its finality can be guaranteed, but it will increase complexity.
Status Fees
How do block proposers and state providers negotiate the price of state? Is it set by the network? To generate a block, should the block proposer bid to multiple state proposers and choose the cheapest one? Is the price calculated based on the number of state accesses or the size of the witness data? If the fee is based on the amount of witness data, how does the BP know that the SP does not include extra bytes? If multiple transactions use the same witness, should the fee be split evenly, or should each transaction pay the full amount, or should only the first transaction pay it?
State Abstraction
This proposal does not define exactly how the execution environment should obtain state, but a pull model or relay model runtime should be required.
Distributed State Network
Imagine that instead of collecting transactions and sending the entire transaction package to the state provider, it is possible to create a distributed hash table and let the block proposer dynamically obtain the state during execution? This alternative approach will block the execution of transactions on network requests, which may make the serialization of transactions too slow/unpredictable. This alternative approach can also be achieved by leveraging the progress in software transactional memory.
