feat(rpc): implement debug_executionWitness API

[0x00101010]

Implement a new debug_executionWitness API to return execution witness for desired blocks.

This is helpful for

1. fault proofs and ZK applications, instead of trying to retrieve MPT tries and contract codes by hashes, they can now use this API to retrieve relevant information.
2. cross client validation

This PR upstreams changes to op-geth, and the API has already been implemented in reth as well

[karalabe]

This should be moved to the API part. It's the encoding specific to that API endpoint, not something generic for the witness + we don't want a JSON encoding in general because it's very expensive.

[0x00101010]

Done, understood that JSON encoding can be very expensive. How do you feel about merge it for now given

1. currently performance is not a big concern
2. with JSON encoding, it helps with readability, troubleshooting, ease of parsing and cross client compatibility until we have an agreed upon format (maybe through an EIP)?

[MariusVanDerWijden]

Could you add some transactions to the test chain so that we have some more data in the witnesses other than the coinbase payment?

e.g.

tx, err := types.SignTx(types.NewTransaction(0, common.Address{0x00}, new(big.Int), params.TxGas, block.BaseFee(), nil), signer, key)
			if err != nil {
				panic(err)
			}
			block.AddTx(tx)

[0x00101010]

done

[karalabe]

Been thinking about this but would like to push back on the map format.

The original witness format I used sent the codes and the trie nodes as an array of bytes. This PR changes that to return a map, keyed by hash.

This is IMO a problem, because if I send a malicious witness (keys do not match the content), and the receiving side blindly trusts it, then you can get arbitrary results. You could say that the receiver must verify the hashes, but that means hashing the content, so the effort to verify is the same as if the hashes weren't transmitted in the first place.

So: transmitting the hash keys bloats the witness up; and it potentially permits clients to be less secure. IMO, this should be reverted to my format.

The other quirk my format has and this doesn't is the transmission of the root hash. The reasoning is the same, by omitting the root hash, a verified has to 100% work correctly, otherwise it cannot arrive to the correct result. In this case however, some bug could still "verify" the correct root, since you have it anyway.