How do we reject the state-changing Precompile operations in a "static" context/tx?

[IaroslavMazur]

Prior to the execution of certain opcodes, some specific verifications/validations need to happen, in order for the system to function correctly. If, during those verifications, it is determined that the "environment" of the current Tx/Block doesn't support the respective operation/feature, the opcode is simply not executed by the VM.

One example of this is that certain opcodes may only be executed up to/starting from a certain Ethereum Block.

Another one (which directly affects us, given this discussion) has to do with the rejection of the state-changing opcodes at times when they are being called from a "static" context, i.e. when no state-changing is allowed (because of its associated high price tag and whatnot).
Note: the Solidity equivalent for this context is an EOA calling a view/pure function of a smart contract.

Initially, we thought that only the functionalities of the likes of NTCALL, NTDELEGATECALL and NTCREATE are affected, but, after some more consideration, I realized that the MINT and BURN functionalities are, unfortunately, affected by this, as well (i.e. we don't want to allow modifying the VM state by minting/burning NTs in a "static" context/tx).

So, the problem is, in fact, bigger than initially considered, and I don't think we can postpone addressing it until a future release of the Mainnet (as we have theoreticized when considering just the 3 aforementioned MNT-prefixed opcodes).

Now that we've covered why we want to verify and reject the execution of our custom, opcode-like functionalities, the reason this is a problem is that we can't reasonably tap into the information about the "static"/"not-static" state of the current Tx from inside the SabVM Precompile.

This information is, indeed, available on another level of abstraction: the revm's Interpreter crate/struct - and, theoretically, we could bring that information into the context of the trait that is implemented by our Precompile.
However, considering:

• the current revm architecture and
• probably, more importantly - the general logic/common sense,

I'm not convinced this is a good idea, as:

• it would lead to quite a change in the project's architecture (e.g. it's all of the ContextStatefulPrecompileMut-traited Precompiles - and not just ours - that will be affected (note: there are none, atm, but, still)) and
• teaching a Precompile about that/giving it such a responsibility feels wrong, conceptually.

BTW, Solidity doesn't allow you to determine whether the overall/original Tx context is "static" or not. See my discussion w/ ChatGPT regarding the matter here.

@sablier-labs/sabvm, looking forward to your thoughts regarding this. Also, I've presented this problem to Dragan Rakita and asked for his opinion.

In any case, further investigation/brainstorming is needed.

[PaulRBerg]

Thanks @IaroslavMazur - Will review tomorrow but just some feedback for easier review, it would be helpful to split your discussions with section headers, e.g. ## Problem, etc.

[PaulRBerg]

This doesn't seem like a problem to me for Genesis - we don't intend to allow contracts besides SRF-20s. Tokens would be minted and burned only via transactions sent by EOAs.

But yes, post-Genesis this is a problem. More research needed on whether we can inject Interpreter in ContextStatefulPrecompileMut.

[IaroslavMazur]

Yes, as we've discussed on a call, as long as we make sure that the permissioned smart contracts in Genesis don't call the state-changing Precompile functions from a static context, it should be alright.

This requirement/limitation is worth noting down in some SRF-20 Guidelines document, by the way.

[IaroslavMazur]

Let me write down the (better) strategy for addressing the root problem in the OP (initially shared with @PaulRBerg in a DM) which I've come up with after a deeper dive into this issue.

This is the "call stack" that we'll need to modify: EvmContext::make_call_frame() -> EvmContext::call_precompile() -> ContextPrecompiles::call() -> ContextPrecompile::call_mut(), as follows:

• EvmContext::make_call_frame() already possesses the "is or isn't static" information (via the CallInputs parameter);
• we pass is_static to EvmContext::call_precompile() which
• forwards it to ContextPrecompiles::call(), which, in its turn, gives it to
• ContextPrecompile::call_mut() (i.e. the context of our Precompile);
• next, we assert !is_static in the state-changing functions of our Precompile.
• Bingo! 💪

[PaulRBerg]

great sleuthing

[IaroslavMazur]

Ended up implemented the solution above.

Closing the discussion.