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
cmd/evm: implement input txs via rlp in t8n tool (#23138)
In many cases, it's desireable to use already-signed transactions as input to the state transition, instead of having the evm sign them internally (for example to use malformed or not-yet-valid transactions). This PR adds support + docs for that feature.
Copy file name to clipboardExpand all lines: cmd/evm/README.md
+93-24Lines changed: 93 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,15 +4,15 @@ The `evm t8n` tool is a stateless state transition utility. It is a utility
4
4
which can
5
5
6
6
1. Take a prestate, including
7
-
- Accounts,
8
-
- Block context information,
9
-
- Previous blockshashes (*optional)
7
+
- Accounts,
8
+
- Block context information,
9
+
- Previous blockshashes (*optional)
10
10
2. Apply a set of transactions,
11
11
3. Apply a mining-reward (*optional),
12
12
4. And generate a post-state, including
13
-
- State root, transaction root, receipt root,
14
-
- Information about rejected transactions,
15
-
- Optionally: a full or partial post-state dump
13
+
- State root, transaction root, receipt root,
14
+
- Information about rejected transactions,
15
+
- Optionally: a full or partial post-state dump
16
16
17
17
## Specification
18
18
@@ -37,6 +37,8 @@ Command line params that has to be supported are
37
37
--output.result result Determines where to put the result (stateroot, txroot etc) of the post-state.
38
38
`stdout` - into the stdout output
39
39
`stderr` - into the stderr output
40
+
--output.body value If set, the RLP of the transactions (block body) will be written to this file.
41
+
--input.txs stdin stdin or file name of where to find the transactions to apply. If the file prefix is '.rlp', then the data is interpreted as an RLP list of signed transactions.The '.rlp' format is identical to the output.body format. (default: "txs.json")
40
42
--state.fork value Name of ruleset to use.
41
43
--state.chainid value ChainID to use (default: 1)
42
44
--state.reward value Mining reward. Set to -1 to disable (default: 0)
@@ -110,7 +112,10 @@ Two resulting files:
110
112
}
111
113
],
112
114
"rejected": [
113
-
1
115
+
{
116
+
"index": 1,
117
+
"error": "nonce too low: address 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192, tx: 0 state: 1"
118
+
}
114
119
]
115
120
}
116
121
```
@@ -156,7 +161,10 @@ Output:
156
161
}
157
162
],
158
163
"rejected": [
159
-
1
164
+
{
165
+
"index": 1,
166
+
"error": "nonce too low: address 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192, tx: 0 state: 1"
167
+
}
160
168
]
161
169
}
162
170
}
@@ -168,9 +176,9 @@ Mining rewards and ommer rewards might need to be added. This is how those are a
168
176
169
177
-`block_reward` is the block mining reward for the miner (`0xaa`), of a block at height `N`.
170
178
- For each ommer (mined by `0xbb`), with blocknumber `N-delta`
171
-
- (where `delta` is the difference between the current block and the ommer)
172
-
- The account `0xbb` (ommer miner) is awarded `(8-delta)/ 8 * block_reward`
173
-
- The account `0xaa` (block miner) is awarded `block_reward / 32`
179
+
- (where `delta` is the difference between the current block and the ommer)
180
+
- The account `0xbb` (ommer miner) is awarded `(8-delta)/ 8 * block_reward`
181
+
- The account `0xaa` (block miner) is awarded `block_reward / 32`
174
182
175
183
To make `state_t8n` apply these, the following inputs are required:
176
184
@@ -220,7 +228,7 @@ Output:
220
228
### Future EIPS
221
229
222
230
It is also possible to experiment with future eips that are not yet defined in a hard fork.
INFO [01-21|22:41:22.963] rejected tx index=1 hash=0557ba..18d673 from=0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192 error="nonce too low: address 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192, tx: 0 state: 1"
260
-
INFO [01-21|22:41:22.966] rejected tx index=0 hash=0557ba..18d673 from=0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192 error="nonce too low: address 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192, tx: 0 state: 1"
261
-
INFO [01-21|22:41:22.967] rejected tx index=1 hash=0557ba..18d673 from=0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192 error="nonce too low: address 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192, tx: 0 state: 1"
272
+
INFO [07-27|11:53:41.049] rejected tx index=1 hash=0557ba..18d673 from=0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192 error="nonce too low: address 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192, tx: 0 state: 1"
273
+
INFO [07-27|11:53:41.050] Trie dumping started root=84208a..ae4e13
274
+
INFO [07-27|11:53:41.050] Trie dumping complete accounts=3 elapsed="59.412µs"
275
+
INFO [07-27|11:53:41.050] Wrote file file=result.json
276
+
INFO [07-27|11:53:41.051] rejected tx index=0 hash=0557ba..18d673 from=0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192 error="nonce too low: address 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192, tx: 0 state: 1"
277
+
INFO [07-27|11:53:41.051] rejected tx index=1 hash=0557ba..18d673 from=0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192 error="nonce too low: address 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192, tx: 0 state: 1"
278
+
INFO [07-27|11:53:41.052] Trie dumping started root=84208a..ae4e13
279
+
INFO [07-27|11:53:41.052] Trie dumping complete accounts=3 elapsed="45.734µs"
280
+
INFO [07-27|11:53:41.052] Wrote file file=alloc.json
281
+
INFO [07-27|11:53:41.052] Wrote file file=result.json
262
282
263
283
```
264
-
What happened here, is that we first applied two identical transactions, so the second one was rejected.
284
+
What happened here, is that we first applied two identical transactions, so the second one was rejected.
265
285
Then, taking the poststate alloc as the input for the next state, we tried again to include
266
286
the same two transactions: this time, both failed due to too low nonce.
267
287
268
288
In order to meaningfully chain invocations, one would need to provide meaningful new `env`, otherwise the
269
289
actual blocknumber (exposed to the EVM) would not increase.
290
+
291
+
### Transactions in RLP form
292
+
293
+
It is possible to provide already-signed transactions as input to, using an `input.txs` which ends with the `rlp` suffix.
294
+
The input format for RLP-form transactions is _identical_ to the _output_ format for block bodies. Therefore, it's fully possible
295
+
to use the evm to go from `json` input to `rlp` input.
296
+
297
+
The following command takes **json** the transactions in `./testdata/13/txs.json` and signs them. After execution, they are output to `signed_txs.rlp`.:
0 commit comments