Why is ContextStatefulPrecompileMut not allowed in Precompiles?

[supragya]

The stateful-precompile example explicitly says:

/// NOTE: This does not work with "context stateful precompiles", ie `ContextStatefulPrecompile` or
/// `ContextStatefulPrecompileMut`. They are explicitly banned.

Why so?
What if a precompile is not "pure", but intends to have side effects like doing an sstore internally. Is that not allowed?

[Rjected]

The stateful-precompile example explicitly says:

/// NOTE: This does not work with "context stateful precompiles", ie `ContextStatefulPrecompile` or
/// `ContextStatefulPrecompileMut`. They are explicitly banned.

Why so?
What if a precompile is not "pure", but intends to have side effects like doing an sstore internally. Is that not allowed?

This example doc is slightly outdated, but this example specifically implements a precompile cache. Caching the result of a stateful precompile would mean that we then have to invalidate cached results if the state changed. Whereas caching stateless precompile results indefinitely is clearly valid

[supragya]

The question is about accessing things like sstore via precompile. Is that discouraged, are we expecting "pure"-ity in sense of no load / store from and to EVMCTX?

[Rjected]

No, this is not necessarily discouraged, it's just that this example cache will not work properly with other stateful precompiles.

[lilixac]

In the example docs, by

/// NOTE: This does not work with "context stateful precompiles", ie `ContextStatefulPrecompile` or
/// `ContextStatefulPrecompileMut`. They are explicitly banned.

Does it mean, we should avoid using cache for ContextStatefulPrecompileMut? Or, should we stop using ContextStatefulPrecompileMut trait in overall?

[supragya]

Hey @Rjected, we have been experimenting a bit lately with custom precompiles, but seems like it is a reth issue on calling precompiles. Seems like gas accounting is wrong somewhere:

2025-03-21T08:31:55.843762Z  WARN Encountered invalid block number=27 hash=0x6ebbcc4a97e8716243e0b7997d463e25c3f65b49d41dc3646f00b5a338f797c6
2025-03-21T08:31:57.823613Z  INFO New payload job created id=0x94eef1a0a18c6f94 parent=0x6095f5fdbf72e07219ff0d2ec0e9f61a16954f982a39d54da1e1fe92e0657404
2025-03-21T08:31:57.842386Z  WARN Invalid block error on new payload invalid_hash=0x687a7279c769a500b71f589315eae6f4b76b5aceb6dfe3f16219d6fc5527a4a5 invalid_number=27 validation_err=block gas used mismatch: got 23563, expected 23900; gas spent by each transaction: [(0, 23563)]
2025-03-21T08:31:57.842563Z  WARN Bad block with hash invalid_ancestor=BlockWithParent { parent: 0x6095f5fdbf72e07219ff0d2ec0e9f61a16954f982a39d54da1e1fe92e0657404, block: NumHash { number: 27, hash: 0x687a7279c769a500b71f589315eae6f4b76b5aceb6dfe3f16219d6fc5527a4a5 } }
2025-03-21T08:31:57.842765Z  WARN Encountered invalid block number=27 hash=0x687a7279c769a500b71f589315eae6f4b76b5aceb6dfe3f16219d6fc5527a4a5
2025-03-21T08:31:57.842794Z ERROR Error advancing the chain: Invalid payload

You can reproduce this at your end by following this repository: https://github.com/supragya/reth-precompile-failures/tree/d7b15744f2c061d7051bf1165653011b31794c37

[supragya]

On a secondary note, hickory_provider, an internal dependency has been updated upstream. If we delete the Cargo.lock file, and try building again, it fails.

It presents this:

no function or associated item named `tokio_from_system_conf` found for struct `hickory_resolver::Resolver` in the current scope:
   |
63 |         TokioResolver::tokio_from_system_conf().map(Self::new)
   |                        ^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `Resolver<GenericConnector<TokioRuntimeProvider>>`

This is because the following is resolved:

[[package]]
name = "hickory-resolver"
version = "0.25.1"

If instead resolution is:

[[package]]
name = "hickory-resolver"
version = "0.25.0-alpha.5"

It builds without an issue.

[Atamanov]

I can confirm that custom precompile gas calculation seems broken. If we add

impl StatefulPrecompile for ConsensusVerifierPrecompile {
    fn call(
        &self,
        bytes: &alloy_primitives::Bytes,
        _gas_limit: u64,
        _env: &reth::revm::primitives::Env,
    ) -> PrecompileResult {
        Ok(PrecompileOutput {
            gas_used: 50000,
            bytes: Bytes::new(),
        })
    }
}

the reth is than stalled

The gas is the header was set wrong for the block that involved a precompile call. Header's gas was calculated from the receipts that are in turn seem wrong.