Features for incident analysis

[holiman]

Here are some features which would be good to have, going towards the merge:

• GetBlockReceiptsRLP. Currently, we have no way to obtain the raw rlp receipt-blobs which make up the receiptsRoot for a block.
• Automatically trace new bad blocks to filesystem (memory=disabled, storage=disabled).
• Ability to do geth db get(put/delete?) via RPC layer
• Ability to change the gcMode via RPC. Right now, it's either archive=mode or 2-hours-processing-mode. When the node nears an upcoming fork, it would be nice to set it to flush e.g. after 5m processing, or 512 blocks, and later be able to set it back to a mode which is less disk-heavy.
• Ability to "drop the network"/ "go offline from p2p/discovery" via RPC (keep rpc up though

Decided to skip:

• debug.flushState(). Somehow, it would be nice to be able to flush the state for a certain block. As it is now, we have 128*14 seconds, or about 30m to investigate (e..g get a trace) from a progressing "good" node before a state is forgotten. After that point, we can do reexec, but the reexec never flushes state to disk, so operating on an old state might mean half an hour reexec performed again on every call.

[holiman]

Another one:
It would be good to make the prestateTracer compatible with t8n. Example

{
  "env": {
    "currentCoinbase": "0xc94f5374fce5edbc8e2a8697c15331677e6ebf0b",
    "currentDifficulty": "0x20000",
    "currentGasLimit": "0x750a163df65e8a",
    "currentNumber": "1",
    "currentTimestamp": "1000"
  },
  "alloc": {
    "a94f5374fce5edbc8e2a8697c15331677e6ebf0b": {
      "balance": "0x5ffd4878be161d74",
      "code": "0x",
      "nonce": "0xac",
      "storage": {}
    },
    "0x8a8eafb1cf62bfbeb1741769dae1a9dd47996192": {
      "balance": "0xfeedbead",
      "nonce": "0x00"
    }
  }
}

This is compatible with evm t8n:

[user@work evm]$ cat foobar.json | ./evm t8n --input.alloc=stdin --input.txs=./testdata/1/txs.json --input.env=stdin --output.alloc=stdout --trace
INFO [04-20|14:43:00.126] rejected tx                              index=1 hash=0557ba..18d673 from=0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192 error="nonce too low: address 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192, tx: 0 state: 1"
INFO [04-20|14:43:00.126] Trie dumping started                     root=84208a..ae4e13
INFO [04-20|14:43:00.127] Trie dumping complete                    accounts=3 elapsed="68.344µs"
INFO [04-20|14:43:00.127] Wrote file                               file=result.json

If we can make an online node spit out the such an env+alloc file, then we can more easily try out patches and in general analyze what's happening on a given transaction, in case the evm is misbehaving.

This is basically the original reason for why I made prestateTracer in the first place, but I suspect it's a bit bitrotted by now.

[ryanschneider]

GetBlockReceiptsRLP. Currently, we have no way to obtain the raw rlp receipt-blobs which make up the receiptsRoot for a block.

IMO RLP isn't the right term any more post-EIP-2718, I used Binary in #24741 (which just dumps a single receipt, not all the block receipts).

For debug_getBlockReceiptsBinary I think it should return either an array of tx binaries or even a map of {index: binary}, since that's the input to the receipts root trie. For example on Sepolia block 0x59d58395078eb687813eeade09f4ccd3a40084e607c3b0e0b987794c12be48cc (https://sepolia.otterscan.io/block/852597):

> debug.getBlockReceiptsBinary("0x59d58395078eb687813eeade09f4ccd3a40084e607c3b0e0b987794c12be48cc")
{
  0: "0x02f901850182aebbb9010000800000000000000000000000000000000000000000100000020000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000000000000400000000000000000f87cf87a94830bf80a3839b300291915e7c67b70d90823ffedf842a0e1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109ca00000000000000000000000001b57edab586cbdabd4d914869ae8bb78dbc05571a00000000000000000000000000000000000000000000000000de0b6b3a7640000"
}

I personally prefer the map format since it reinforces the key/value relationship in the receipts root trie, but am totally open to it being a simple array as well. Either way, it'd be nice if it was paired w/ a debug.calculateReceiptsRoot method that took the same form, so one could do:

> receipts = debug.getBlockReceiptsBinary("0x59d58395078eb687813eeade09f4ccd3a40084e607c3b0e0b987794c12be48cc")
> .. potentially tweak the receipts if debugging something ...
> root = debug.calculateReceiptsRoot(receipts)
"0x7800894d3a17b7f4ce8f17f96740e13696982605164eb4465bdd8a313d0953a5"

[MariusVanDerWijden]

We could, instead of implementing flushState also add an additional config flag that stores the state during reexec, so subsequent calls are cached

[holiman]

stale