This PR allows to calculate the new state root for the fallback block using the approach described in this discussion. Some noteworthy things about it (I'm going to report them in the discussion as well, once everything is finalized):
the trace_callMany RPC endpoint does not show every touched account state and balance decreases due to gas payments. This has also been highlighted in a stackexchange question.
As such we're falling back on iterative calls of debug_traceCall, supported by all clients, using state overrides. NOTE: at the moment not every client seems to support state overrides, like Nethermind and Besu
not every execution client has the same interface for state overrides. For example, Reth and Geth want 32 bytes for both keys and values of the state_diff hashmap, as shown here. Erigon instead requires values to be unsigned integers of 256 bits (as shown here which cannot be obtained by deserialisation of big-endian 32 bytes with leading zero, because of this check in the uint256 dependency library. Maybe there is a workaround for this but I haven't experimented a lot yet.
Update: in the end the approach adopted has been the one in #93, however this PR keeps some of the trace call functionality described above
This PR allows to calculate the new state root for the fallback block using the approach described in this discussion. Some noteworthy things about it (I'm going to report them in the discussion as well, once everything is finalized):
trace_callMany
RPC endpoint does not show every touched account state and balance decreases due to gas payments. This has also been highlighted in a stackexchange question. As such we're falling back on iterative calls ofdebug_traceCall
, supported by all clients, using state overrides. NOTE: at the moment not every client seems to support state overrides, like Nethermind and Besustate_diff
hashmap, as shown here. Erigon instead requires values to be unsigned integers of 256 bits (as shown here which cannot be obtained by deserialisation of big-endian 32 bytes with leading zero, because of this check in theuint256
dependency library. Maybe there is a workaround for this but I haven't experimented a lot yet.Update: in the end the approach adopted has been the one in #93, however this PR keeps some of the trace call functionality described above