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.
@ -4,15 +4,15 @@ The `evm t8n` tool is a stateless state transition utility. It is a utility
which can
which can
1. Take a prestate, including
1. Take a prestate, including
- Accounts,
- Accounts,
- Block context information,
- Block context information,
- Previous blockshashes (*optional)
- Previous blockshashes (*optional)
2. Apply a set of transactions,
2. Apply a set of transactions,
3. Apply a mining-reward (*optional),
3. Apply a mining-reward (*optional),
4. And generate a post-state, including
4. And generate a post-state, including
- State root, transaction root, receipt root,
- State root, transaction root, receipt root,
- Information about rejected transactions,
- Information about rejected transactions,
- Optionally: a full or partial post-state dump
- Optionally: a full or partial post-state dump
## Specification
## Specification
@ -37,6 +37,8 @@ Command line params that has to be supported are
--output.result result Determines where to put the result (stateroot, txroot etc) of the post-state.
--output.result result Determines where to put the result (stateroot, txroot etc) of the post-state.
`stdout` - into the stdout output
`stdout` - into the stdout output
`stderr` - into the stderr output
`stderr` - into the stderr output
--output.body value If set, the RLP of the transactions (block body) will be written to this file.
--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")
--state.fork value Name of ruleset to use.
--state.fork value Name of ruleset to use.
--state.chainid value ChainID to use (default: 1)
--state.chainid value ChainID to use (default: 1)
--state.reward value Mining reward. Set to -1 to disable (default: 0)
--state.reward value Mining reward. Set to -1 to disable (default: 0)
@ -110,7 +112,10 @@ Two resulting files:
}
}
],
],
"rejected": [
"rejected": [
1
{
"index": 1,
"error": "nonce too low: address 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192, tx: 0 state: 1"
}
]
]
}
}
```
```
@ -156,7 +161,10 @@ Output:
}
}
],
],
"rejected": [
"rejected": [
1
{
"index": 1,
"error": "nonce too low: address 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192, tx: 0 state: 1"
}
]
]
}
}
}
}
@ -168,9 +176,9 @@ Mining rewards and ommer rewards might need to be added. This is how those are a
- `block_reward` is the block mining reward for the miner (`0xaa`), of a block at height `N`.
- `block_reward` is the block mining reward for the miner (`0xaa`), of a block at height `N`.
- For each ommer (mined by `0xbb`), with blocknumber `N-delta`
- For each ommer (mined by `0xbb`), with blocknumber `N-delta`
- (where `delta` is the difference between the current block and the ommer)
- (where `delta` is the difference between the current block and the ommer)
- The account `0xbb` (ommer miner) is awarded `(8-delta)/ 8 * block_reward`
- The account `0xbb` (ommer miner) is awarded `(8-delta)/ 8 * block_reward`
- The account `0xaa` (block miner) is awarded `block_reward / 32`
- The account `0xaa` (block miner) is awarded `block_reward / 32`
To make `state_t8n` apply these, the following inputs are required:
To make `state_t8n` apply these, the following inputs are required:
@ -220,7 +228,7 @@ Output:
### Future EIPS
### Future EIPS
It is also possible to experiment with future eips that are not yet defined in a hard fork.
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"
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"
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"
INFO [07-27|11:53:41.050] Trie dumping started root=84208a..ae4e13
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"
INFO [07-27|11:53:41.050] Trie dumping complete accounts=3 elapsed="59.412µs"
INFO [07-27|11:53:41.050] Wrote file file=result.json
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"
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"
INFO [07-27|11:53:41.052] Trie dumping started root=84208a..ae4e13
INFO [07-27|11:53:41.052] Trie dumping complete accounts=3 elapsed="45.734µs"
INFO [07-27|11:53:41.052] Wrote file file=alloc.json
INFO [07-27|11:53:41.052] Wrote file file=result.json
```
```
What happened here, is that we first applied two identical transactions, so the second one was rejected.
What happened here, is that we first applied two identical transactions, so the second one was rejected.
Then, taking the poststate alloc as the input for the next state, we tried again to include
Then, taking the poststate alloc as the input for the next state, we tried again to include
the same two transactions: this time, both failed due to too low nonce.
the same two transactions: this time, both failed due to too low nonce.
In order to meaningfully chain invocations, one would need to provide meaningful new `env`, otherwise the
In order to meaningfully chain invocations, one would need to provide meaningful new `env`, otherwise the
actual blocknumber (exposed to the EVM) would not increase.
actual blocknumber (exposed to the EVM) would not increase.
### Transactions in RLP form
It is possible to provide already-signed transactions as input to, using an `input.txs` which ends with the `rlp` suffix.
The input format for RLP-form transactions is _identical_ to the _output_ format for block bodies. Therefore, it's fully possible
to use the evm to go from `json` input to `rlp` input.
The following command takes **json** the transactions in `./testdata/13/txs.json` and signs them. After execution, they are output to `signed_txs.rlp`.:
echo"In order to meaningfully chain invocations, one would need to provide meaningful new \`env\`, otherwise the"
echo"In order to meaningfully chain invocations, one would need to provide meaningful new \`env\`, otherwise the"
echo"actual blocknumber (exposed to the EVM) would not increase."
echo"actual blocknumber (exposed to the EVM) would not increase."
echo""
echo""
echo"### Transactions in RLP form"
echo""
echo"It is possible to provide already-signed transactions as input to, using an \`input.txs\` which ends with the \`rlp\` suffix."
echo"The input format for RLP-form transactions is _identical_ to the _output_ format for block bodies. Therefore, it's fully possible"
echo"to use the evm to go from \`json\` input to \`rlp\` input."
echo""
echo"The following command takes **json** the transactions in \`./testdata/13/txs.json\` and signs them. After execution, they are output to \`signed_txs.rlp\`.:"