RPC Deserialization Issues

[ratankaliani]

RPC providers often add additional fields to their RPC responses for debug methods which causes deserialization issues during witness generation. kona should be more resilient to these deserialization failures.

Given that kona relies on alloy, and alloy can be out of sync with geth nodes, it may be good to specify that reth L1 nodes are always supported in kona, but geth nodes may have incompatibilities, introduced by differing implementations of the node responses.

alloy should better handle deserialization failures. If there are additional fields in the RPC response, ignore them. If fields don't exist, set a reasonable default value.

Relevant Issues

Tenderly added accessList field.

succinctlabs#31

Tenderly added totalTerminalDifficulty field which breaks alloy validation from geth

Reth is still returning totalTerminalDifficulty, Alchemy is not, tenderly is but with 0x0, others mix and match.

paradigmxyz/reth#13362

2024-12-17T15:36:21.388787Z  WARN fetcher: Retrying hint fetch: l1-transactions 0f06ea69ba4796c72f89d9d40c45e88fc7e69879704eeca6f8389b2457c998df
2024-12-17T15:36:21.389106Z ERROR fetcher: Failed to prefetch hint: Failed to fetch block: deserialization error: data did not match any variant of untagged enum BlockTransactions at line 1 column 108597
2024-12-17T15:36:21.389117Z  WARN fetcher: Retrying hint fetch: l1-transactions 5fad2372fe23fdbceab654f269bfebde47d896b6a1c6fc004a15c1d14cd00d76
2024-12-17T15:36:21.389187Z ERROR fetcher: Failed to prefetch hint: Failed to fetch block: deserialization error: data did not match any variant of untagged enum BlockTransactions at line 1 column 114462

[mattsse]

what's the json response?