Research: The State Provider Model in Ethereum 2.0
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from
Ethereum enthusiasts (ID: ethfans)
Introduction
, Author: adietrichs, translation & proofreading: Pei Qi & A Jian, reprinted by Odaily with authorization.
This article was co-authored 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 state they want to access. More precisely, for a block proposer (BP), in addition to containing transactions, a block also needs to contain all states and corresponding witness information accessed by all transactions. Assuming that neither the users who create transactions nor the BPs store state data, then the network needs another group to save and provide these states. This role is often referred to as a Status 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 the contract, estimating the cost of Gas or checking the balance of the account. This means that the state provider needs to expose a pull-like interface for users. Although there is no incentive layer, only relying on selfless state providers can also provide users with state (Ethereum 1.0 does this), and payment can also be implemented through state channels, adding an incentive layer to state providers.
comparison criteria
state access restriction
Because the execution of the transaction is based on the state at the time of execution, if the underlying state changes, the execution of the transaction will also change. In particular, for some transactions, the location of state access may change. This could be due to simple jump statements (such as if), or the location visited is calculated at runtime. We refer to both cases as 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 to these transactions ahead of time (since it is not known in advance which global state these transactions will access). Different state provider patterns behave differently in the extent to which they support these transactions.
If a mode restricts dynamic state access, Eth1 will most likely fail to be an Eth2 Execution Environment (EE) and will often require special handling.
secondary title
Who pays and how is compensation calculated?
centralization risk
Are altruistic state providers supported initially, and if so, can incentives be added later?
secondary title
centralization risk
Centralization risk varies for each model:
Who can review transactions and to what extent?
time constraints
There is a fixed time for block producers to broadcast blocks. So we specifically consider how the different modes perform within that time limit.
In Eth1, once the signature verification and balance and nonce checks for a given transaction are complete, miners can be confident that they will be paid to include the transaction. In Eth2, whether the block proposer can get paid depends on whether the lost state is an attributable fault. If so, even if a transaction fails due to state loss, the block proposer can still get paid. Otherwise, the lost-state transaction itself is unpackable, but the block proposer may not discover it until all (typically long) transactions have been executed. (Translator's Note: The payment here means that the block proposer needs to charge the transaction fee in the packaged transaction. If it is an unattributable error, then the block proposer spends the cost to package the transaction, but does not get the transaction in the transaction. fee.)
model
If the block proposer has to run transactions to find the error, but these transactions are not packaged (that is, cannot pay the transaction fee), then the block proposer is vulnerable to a denial of service attack with almost zero cost.
model
secondary title
Direct Push Model
state access restriction
excitation
The user who creates the transaction essentially becomes the only state provider for the transaction. Generally speaking, there is no way to ensure that the status provided by the user can meet all access needs when transactions are on-chain in the future. Therefore, in Direct Push mode, only transactions with predictable state access can be executed. Because transactions can only be accessed using static state, contract creators should also design their contracts to have predictable state access: annotations such as access lists can be used, detailing where the contract can access during runtime. This approach, combined with a pattern that avoids dynamic state access (see this related blog post by Vitalik on Eth1.x), should result in a new pattern that should still provide sufficient functionality.
excitation
centralization risk
This pattern only relies on the general state provider network. As stated above, it seems possible to do without an incentive system.
Incentive systems can also be added through payment channels. Given that each user must establish a payment channel with one or more state providers, this approach should be particularly complex.
centralization risk
A single state provider cannot censor transactions, as users can send multiple queries to multiple state providers.
Because state providers can keep only a portion of state, hardware requirements can be reduced as needed.
Monetary incentives may encourage some state providers to centralize, so when users purchase state through payment channels, they need to trust their opponents.
There are no time constraints.
key point
Attributability of lost state
key point
Main advantage: simplicity. No need for specialized status providers or incentive systems. There is no particular time constraint.
Main disadvantage: Only suitable for transactions where all state access needs are known in advance. This limits the functionality of the entire system. Compatibility issues cannot be resolved, although some mitigations are available. In particular, under this model, Eth1 cannot become the operating environment of Eth2.
secondary title
Relayed Push Model
Correspondingly, the system can still run when the transaction packages in the transaction package pool are proved to be unusable. Relayers only announce the existence of transaction packets. The block proposer will directly contact the relayer, get the transaction package and include it in the new block.
excitation
state access restriction
no limit. As long as the relayer can push the state to the transaction package every slot (slot) to ensure that the needs of state access can be met, it will be fine. Additionally, each new block contains only one data packet, which prevents interference between transaction packets.
excitation
Two possible solutions:
centralization risk
In the absence of a transaction pool, the transaction package is not public. The relayer sells the state-attached transaction package to the block proposer (the fee is a little lower than the transaction fee), thus forming a transaction package market. There are some risks for the block proposer: a transaction may have been included in another block, making it an invalid transaction; or the transaction fee received is less than the relayer announced when selling.
Alternatively, transactions can include payments to a particular relayer, with or without a transaction pool. The user commits to an exclusivity period (i.e., a few time slots) during which no other transactions will be created by the user. If a user signs two or more transactions at the same time during the exclusive period, they will be penalized. To do this, EE must provide a way to "slash" users. But because users don't lock up deposits, it's not clear how to fine users who don't have enough account balance.
centralization risk
Centralization risk depends on which relayer incentives are used:
Given that merging transaction bundles is complex (due to dynamic state access), transaction bundle marketplaces lead to high centralization and allow individual relayers to review transactions. Because of the risks that BPs may suffer from the above list, BPs prefer to cooperate with well-known and trusted relayers. Compared with these well-known relayers, individual users cannot provide transaction packages with sufficiently high transaction fees.
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 with a higher transaction fee.
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 an update corresponding to the transaction package to the block proposer, and the block proposer will include the updated transaction package in the new block, all of these actions must be within a slot time completed within.
key point
State loss can be attributed to relayers. The block proposer can ask the relayer (or the relayer voluntarily chooses) to attach a "refund transaction" to a transaction, which is used to refund the block proposer when the transaction fails due to state loss.
shortcoming:
key point
Main advantage: No state access restrictions.
shortcoming:
Without a transaction pool, transaction packages cannot be combined, so a block can only contain transaction packages proposed by a single relayer. Relayers can centralize and introduce censorship.
Even with a transaction pool, it is unclear whether the combination of transaction bundles will be sufficient to fully alleviate the censorship problem.
Incentive systems are complex.
secondary title
Pull Model (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 packs the transaction package into a new block.
Before the state provider provides all the state, in order for the intermediate nodes and block proposers to verify the validity of the transaction, the user must attach the witness message required to verify the signature and fee payment ability to the transaction. Therefore this part must be standardized across different execution environments (EEs), and all EEs must provide an option for the simplest verification function.
Alternatively a Value-Holding EE (VHEE) can be used. Every transaction uses this VHEE to pay fees. Nodes in the network will understand VHEE so that they can verify transaction validity.
In both cases, the nodes in the network need to update the witness information of the attached state when new blocks arrive.
state access restriction
excitation
Because the user must include the state of verifying the signature and the ability to pay the fee, technically, the restrictions on the transaction part are the same as those listed in the Direct Push model. However these limitations are insignificant in practice. Because in Eth1, signature verification and fee payment are predictable state access, the compatibility between Eth1 and Eth2 will not be broken. Also, for VHEE, its design ensures predictable state access, making further restrictions unnecessary.
centralization risk
excitation
The block proposer can pay for the state provided by the state provider through the payment channel or other means. According to the trust degree of BP and counterparty SP, the fee can be paid according to the number of transactions (this is trust minimization), or according to the transaction package (this is more efficient)
centralization risk
The state provider must save all state, and the storage requirement is very large. State providers are also expected to execute transaction packages quickly and thus require computational power.
Block proposers may be more inclined to obtain state from their trusted state provider group, reducing the risk of malicious damage, thereby increasing the degree of centralization.
However, a single state provider cannot censor transactions because it is the block proposer who is responsible for creating and ordering the transaction package. It is possible for a state provider to hide the state that a certain transaction package needs, but doing so would damage their reputation, and the block proposer could easily retry with another state provider.
Attributability of lost state
key point
advantage:
A state provider is always responsible for the state it provides. The block proposer cannot pack transactions with insufficient state into the block, and will only pay after verifying that the state is sufficient.
key point
advantage:
There are no associated state access restrictions.
There are fewer time constraints issues.
No significant centralization risk. Although it is expected that certain state providers will provide state exclusively for 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.
The main disadvantage: Some standardization must be done on signature verification, either via a verification script, or using VHEE.
extended discussion
Self-reliance testimonial information & Gas cost
If transaction initiators 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 certainty can be guaranteed, but it will increase the complexity.
state fee
How do block proposers and state providers negotiate state prices? Is it set by the network? To produce a block, should a block proposer bid to multiple state proposers and choose the cheapest one?
Is the price calculated according to the number of status visits? Or is it calculated according to the size of the witness data?
If the charge is based on the data volume of the witness data, how does BP know that SP does not contain extra bytes?
If multiple transactions use the same witness information, should the fee be split equally? Or do you pay the full amount for each transaction? Or is it only the first transaction that needs to be paid?
state abstraction
