forks/go-ethereum
1
0
Fork 1
mirror of https://github.com/ethereum/go-ethereum.git synced 2026-08-19 18:32:23 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

fix: md Item numbering and form repair

Browse source
This commit is contained in:
songzhibin97 2024-05-03 12:15:21 +08:00
parent 86a1f0c394
commit 2a7d0583d9
4 changed files with 196 additions and 155 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
README.md
View file

@ -35,7 +35,7 @@ The go-ethereum project comes with several wrappers/executables found in the `cm
directory.
| Command | Description |
| :--------: | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|:----------:|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **`geth`** | Our main Ethereum CLI client. It is the entry point into the Ethereum network (main-, test- or private net), capable of running as a full node (default), archive node (retaining all historical state) or a light node (retrieving data live). It can be used by other processes as a gateway into the Ethereum network via JSON RPC endpoints exposed on top of HTTP, WebSocket and/or IPC transports. `geth --help` and the [CLI page](https://geth.ethereum.org/docs/fundamentals/command-line-options) for command line options. |
| `clef` | Stand-alone signing tool, which can be used as a backend signer for `geth`. |
| `devp2p` | Utilities to interact with nodes on the networking layer, without running a full blockchain. |

4
cmd/clef/README.md
View file

@ -225,7 +225,7 @@ Response
- `value` [number:optional]: amount of Wei to send with the transaction
- `data` [data:optional]: input data
- `nonce` [number]: account nonce
1. method signature [string:optional]
2. method signature [string:optional]
- The method signature, if present, is to aid decoding the calldata. Should consist of `methodname(paramtype,...)`, e.g. `transfer(uint256,address)`. The signer may use this data to parse the supplied calldata, and show the user. The data, however, is considered totally untrusted, and reliability is not expected.
@ -915,7 +915,7 @@ along with the UI.
There are a couple of implementation for a UI. We'll try to keep this list up to date.
| Name | Repo | UI type | No external resources | Blocky support | Verifies permissions | Hash information | No secondary storage | Statically linked | Can modify parameters |
| ---- | ---- | -------| ---- | ---- | ---- |---- | ---- | ---- | ---- |
|-----------|-----------------------------------------------------|-------------------|-----------------------|----------------|----------------------|------------------|----------------------|-------------------|------------------------|
| QtSigner | https://github.com/holiman/qtsigner/ | Python3/QT-based | :+1: | :+1: | :+1: | :+1: | :+1: | :x: | :+1: (partially) |
| GtkSigner | https://github.com/holiman/gtksigner | Python3/GTK-based | :+1: | :x: | :x: | :+1: | :+1: | :x: | :x: |
| Frame | https://github.com/floating/frame/commits/go-signer | Electron-based | :x: | :x: | :x: | :x: | ? | :x: | :x: |

51
cmd/evm/README.md
View file

@ -9,7 +9,6 @@ layer.
## State transition tool (`t8n`)
The `evm t8n` tool is a stateless state transition utility. It is a utility
which can
@ -52,6 +51,7 @@ Command line params that need to be supported are
--trace.nostack (default: false)
--trace.returndata (default: false)
```
#### Objects
The transition tool uses JSON objects to read and write data related to the transition operation. The
@ -209,7 +209,9 @@ There are a few (not many) errors that can occur, those are defined below.
./evm t8n --input.alloc=./testdata/1/alloc.json --input.txs=./testdata/1/txs.json --input.env=./testdata/1/env.json --state.fork=Frontier+1346 2>/dev/null
exitcode:3 OK
```
#### Forks
### Basic usage
The chain configuration to be used for a transition is specified via the
@ -217,15 +219,19 @@ The chain configuration to be used for a transition is specified via the
found in [`tests/init.go`](../../tests/init.go).
#### Examples
##### Basic usage
Invoking it with the provided example files
```
./evm t8n --input.alloc=./testdata/1/alloc.json --input.txs=./testdata/1/txs.json --input.env=./testdata/1/env.json --state.fork=Berlin
```
Two resulting files:
`alloc.json`:
```json
{
"0x8a8eafb1cf62bfbeb1741769dae1a9dd47996192": {
@ -241,7 +247,9 @@ Two resulting files:
}
}
```
`result.json`:
```json
{
"stateRoot": "0x84208a19bc2b46ada7445180c1db162be5b39b9abc8c0a54b05d32943eae4e13",
@ -275,10 +283,13 @@ Two resulting files:
```
We can make them spit out the data to e.g. `stdout` like this:
```
./evm t8n --input.alloc=./testdata/1/alloc.json --input.txs=./testdata/1/txs.json --input.env=./testdata/1/env.json --output.result=stdout --output.alloc=stdout --state.fork=Berlin
```
Output:
```json
{
"alloc": {
@ -351,6 +362,7 @@ the tool allows for negative uncle reward (distance > 8)
Example:
`./testdata/5/env.json`:
```json
{
"currentCoinbase": "0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
@ -359,13 +371,21 @@ Example:
"currentNumber": "1",
"currentTimestamp": "1000",
"ommers": [
{"delta": 1, "address": "0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb" },
{"delta": 2, "address": "0xcccccccccccccccccccccccccccccccccccccccc" }
{
"delta": 1,
"address": "0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
},
{
"delta": 2,
"address": "0xcccccccccccccccccccccccccccccccccccccccc"
}
]
}
```
When applying this, using a reward of `0x08`
Output:
```json
{
"alloc": {
@ -381,10 +401,12 @@ Output:
}
}
```
#### Future EIPS
It is also possible to experiment with future eips that are not yet defined in a hard fork.
Example, putting EIP-1344 into Frontier:
```
./evm t8n --state.fork=Frontier+1344 --input.pre=./testdata/1/pre.json --input.txs=./testdata/1/txs.json --input.env=/testdata/1/env.json
```
@ -394,6 +416,7 @@ Example, putting EIP-1344 into Frontier:
The `BLOCKHASH` opcode requires blockhashes to be provided by the caller, inside the `env`.
If a required blockhash is not provided, the exit code should be `4`:
Example where blockhashes are provided:
```
./evm t8n --input.alloc=./testdata/3/alloc.json --input.txs=./testdata/3/txs.json --input.env=./testdata/3/env.json --trace --state.fork=Berlin
@ -402,6 +425,7 @@ Example where blockhashes are provided:
```
cat trace-0-0x72fadbef39cd251a437eea619cfeda752271a5faaaa2147df012e112159ffb81.jsonl | grep BLOCKHASH -C2
```
```
{"pc":0,"op":96,"gas":"0x5f58ef8","gasCost":"0x3","memSize":0,"stack":[],"depth":1,"refund":0,"opName":"PUSH1"}
{"pc":2,"op":64,"gas":"0x5f58ef5","gasCost":"0x14","memSize":0,"stack":["0x1"],"depth":1,"refund":0,"opName":"BLOCKHASH"}
@ -410,19 +434,23 @@ cat trace-0-0x72fadbef39cd251a437eea619cfeda752271a5faaaa2147df012e112159ffb81.j
```
In this example, the caller has not provided the required blockhash:
```
./evm t8n --input.alloc=./testdata/4/alloc.json --input.txs=./testdata/4/txs.json --input.env=./testdata/4/env.json --trace --state.fork=Berlin
ERROR(4): getHash(3) invoked, blockhash for that block not provided
```
Error code: 4
#### Chaining
Another thing that can be done, is to chain invocations:
```
./evm t8n --input.alloc=./testdata/1/alloc.json --input.txs=./testdata/1/txs.json --input.env=./testdata/1/env.json --state.fork=Berlin --output.alloc=stdout | ./evm t8n --input.alloc=stdin --input.env=./testdata/1/env.json --input.txs=./testdata/1/txs.json --state.fork=Berlin
```
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
the same two transactions: this time, both failed due to too low nonce.
@ -433,10 +461,13 @@ 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
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`.:
The following command takes **json** the transactions in `./testdata/13/txs.json` and signs them. After execution, they
are output to `signed_txs.rlp`.:
```
./evm t8n --state.fork=London --input.alloc=./testdata/13/alloc.json --input.txs=./testdata/13/txs.json --input.env=./testdata/13/env.json --output.result=alloc_jsontx.json --output.body=signed_txs.rlp
INFO [12-27|09:25:11.102] Trie dumping started root=e4b924..6aef61
@ -447,12 +478,14 @@ INFO [12-27|09:25:11.103] Wrote file file=signed_t
```
The `output.body` is the rlp-list of transactions, encoded in hex and placed in a string a'la `json` encoding rules:
```
cat signed_txs.rlp
"0xf8d2b86702f864010180820fa08284d09411111111111111111111111111111111111111118080c001a0b7dfab36232379bb3d1497a4f91c1966b1f932eae3ade107bf5d723b9cb474e0a06261c359a10f2132f126d250485b90cf20f30340801244a08ef6142ab33d1904b86702f864010280820fa08284d09411111111111111111111111111111111111111118080c080a0d4ec563b6568cd42d998fc4134b36933c6568d01533b5adf08769270243c6c7fa072bf7c21eac6bbeae5143371eef26d5e279637f3bd73482b55979d76d935b1e9"
```
We can use `rlpdump` to check what the contents are:
```
rlpdump -hex $(cat signed_txs.rlp | jq -r )
[
@ -460,7 +493,9 @@ rlpdump -hex $(cat signed_txs.rlp | jq -r )
02f864010280820fa08284d09411111111111111111111111111111111111111118080c080a0d4ec563b6568cd42d998fc4134b36933c6568d01533b5adf08769270243c6c7fa072bf7c21eac6bbeae5143371eef26d5e279637f3bd73482b55979d76d935b1e9,
]
```
Now, we can now use those (or any other already signed transactions), as input, like so:
```
./evm t8n --state.fork=London --input.alloc=./testdata/13/alloc.json --input.txs=./signed_txs.rlp --input.env=./testdata/13/env.json --output.result=alloc_rlptx.json
INFO [12-27|09:25:11.187] Trie dumping started root=e4b924..6aef61
@ -468,8 +503,10 @@ INFO [12-27|09:25:11.187] Trie dumping complete accounts=3 el
INFO [12-27|09:25:11.187] Wrote file file=alloc.json
INFO [12-27|09:25:11.187] Wrote file file=alloc_rlptx.json
```
You might have noticed that the results from these two invocations were stored in two separate files.
And we can now finally check that they match.
```
cat alloc_jsontx.json | jq .stateRoot && cat alloc_rlptx.json | jq .stateRoot
"0xe4b924a6adb5959fccf769d5b7bb2f6359e26d1e76a2443c5a91a36d826aef61"
@ -479,6 +516,7 @@ cat alloc_jsontx.json | jq .stateRoot && cat alloc_rlptx.json | jq .stateRoot
## Transaction tool
The transaction tool is used to perform static validity checks on transactions such as:
* intrinsic gas calculation
* max values on integers
* fee semantics, such as `maxFeePerGas < maxPriorityFeePerGas`
@ -499,6 +537,7 @@ The transaction tool is used to perform static validity checks on transactions s
}
]
```
```
./evm t9n --state.fork London --input.txs testdata/15/signed_txs.rlp
[
@ -514,6 +553,7 @@ The transaction tool is used to perform static validity checks on transactions s
}
]
```
## Block builder tool (b11r)
The `evm b11r` tool is used to assemble and seal full block rlps.
@ -566,6 +606,7 @@ type Header struct {
BaseFee *big.Int `json:"baseFeePerGas"`
}
```
#### `ommers`
The `ommers` object is a list of RLP-encoded ommer blocks in hex