You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: packages/statemanager/README.md
+30-9Lines changed: 30 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,11 +25,13 @@ Note: this library was part of the [@ethereumjs/vm](../vm/) package up till VM `
25
25
26
26
The `StateManager` provides high-level access and manipulation methods to and for the Ethereum state, thinking in terms of accounts or contract code rather then the storage operations of the underlying data structure (e.g. a [Trie](../trie/)).
27
27
28
-
The library includes a TypeScript interface `StateManager` to ensure a unified interface (e.g. when passed to the VM) as well as a concrete Trie-based implementation `DefaultStateManager` as well as an `RPCStateManager` implementation that sources state and history data from an external JSON-RPC provider.
28
+
The library includes a TypeScript interface `StateManager` to ensure a unified interface (e.g. when passed to the VM), a concrete Trie-based `DefaultStateManager` implementation, as well as an `RPCStateManager` implementation that sources state and history data from an external JSON-RPC provider.
29
29
30
30
It also includes a checkpoint/revert/commit mechanism to either persist or revert state changes and provides a sophisticated caching mechanism under the hood to reduce the need for direct state accesses.
Starting with the v2 release and complemented by the v2.1 release the StateManager comes with a significantly more elaborate caching mechanism for account, storage and code caches.
51
53
@@ -55,6 +57,25 @@ Caches now "survive" a flush operation and especially long-lived usage scenarios
55
57
56
58
Have a loot at the extended `CacheOptions` on how to use and leverage the new cache system.
57
59
60
+
#### Instantiating from a proof
61
+
62
+
The `DefaultStateManager` has a static constructor `fromProof` that accepts one or more [EIP-1186](https://eips.ethereum.org/EIPS/eip-1186)[proofs](./src/stateManager.ts) and will instantiate a `DefaultStateManager` with a partial trie containing the state provided by the proof(s). See below example:
63
+
64
+
```typescript
65
+
// setup `stateManager` with some existing address
const slot2FromNewSM =awaitstateManager.getContractStorage(contractAddress, storageKey1) // should also match
77
+
```
78
+
58
79
### `RPCStateManager`
59
80
60
81
First, a simple example of usage:
@@ -74,9 +95,9 @@ The `RPCStateManager` can be be used with any JSON-RPC provider that supports th
74
95
75
96
**Note:** Usage of this StateManager can cause a heavy load regarding state request API calls, so be careful (or at least: aware) if used in combination with a JSON-RPC provider connecting to a third-party API service like Infura!
76
97
77
-
### Points on usage:
98
+
####Points on `RPCStateManager`usage
78
99
79
-
#### Instantiating the EVM
100
+
#####Instantiating the EVM
80
101
81
102
In order to have an EVM instance that supports the BLOCKHASH opcode (which requires access to block history), you must instantiate both the `RPCStateManager` and the `RpcBlockChain` and use that when initalizing your EVM instance as below:
82
103
@@ -92,24 +113,24 @@ const evm = new EVM({ blockchain, stateManager: state })
92
113
93
114
Note: Failing to provide the `RPCBlockChain` instance when instantiating the EVM means that the `BLOCKHASH` opcode will fail to work correctly during EVM execution.
94
115
95
-
#### Provider selection
116
+
#####Provider selection
96
117
97
118
- The provider you select must support the `eth_getProof`, `eth_getCode`, and `eth_getStorageAt` RPC methods.
98
119
- Not all providers support retrieving state from all block heights so refer to your provider's documentation. Trying to use a block height not supported by your provider (e.g. any block older than the last 256 for CloudFlare) will result in RPC errors when using the state manager.
99
120
100
-
#### Block Tag selection
121
+
#####Block Tag selection
101
122
102
123
- You have to pass a block number or `earliest` in the constructor that specifies the block height you want to pull state from.
103
124
- The `latest`/`pending` values supported by the Ethereum JSON-RPC are not supported as longer running scripts run the risk of state values changing as blocks are mined while your script is running.
104
125
- If using a very recent block as your block tag, be aware that reorgs could occur and potentially alter the state you are interacting with.
105
126
- If you want to rerun transactions from block X or run block X, you need to specify the block tag as X-1 in the state manager constructor to ensure you are pulling the state values at the point in time the transactions or block was run.
106
127
107
-
#### Potential gotchas
128
+
#####Potential gotchas
108
129
109
130
- The RPC State Manager cannot compute valid state roots when running blocks as it does not have access to the entire Ethereum state trie so can not compute correct state roots, either for the account trie or for storage tries.
110
131
- If you are replaying mainnet transactions and an account or account storage is touched by multiple transactions in a block, you must replay those transactions in order (with regard to their position in that block) or calculated gas will likely be different than actual gas consumed.
111
132
112
-
#### Further reference
133
+
#####Further reference
113
134
114
135
Refer to [this test script](./test/rpcStateManager.spec.ts) for complete examples of running transactions and blocks in the `vm` with data sourced from a provider.
0 commit comments