How is precompile logic disputed in Cannon?

[PaulRBerg]

Description

Precompiles are implemented natively in the client software, e.g. in go-ethereum they are implemented here.

How does Cannon (the default Fault Proof VM in OP Stack) work when there is a dispute for a transaction that calls a precompile, e.g. the ecrecover located at address 0x01?

How can the onchain MIPS.sol interpreter re-run precompile logic?

Additional Information

I understand that there is this Global Precompile Key, which signifies a "precompile result".

But I still don't see how that helps. What if the rollup operator spoofed the precompile logic itself? Wouldn't the challenger have to trust that the pre-image key was generated using a genuine precompile?

[clabby]

There are two different methods of executing precompiles in the fault proof program:

1. Within the program itself, which is compiled to MIPS and runs on top of the MIPS thread context (MIPS.sol / cannon)
2. Within the host, which is then sent back to the program through the PreimageOracle ABI.

Most precompiles (apart from the accelerated ones [ecrecover, bn256Pairing, KZG Point Evaluation]) run in an EVM within the fault proof program (method # 1 above). If any portion of EVM execution (or any fault proof program execution, for that matter) is spoofed, it is disputed as normal by bisecting to the first agreed-upon prestate and performing an instruction step on-chain within the dispute game.

The accelerated precompiles are outsourced to the host due to how expensive they are to run (in terms of clock cycles) on top of the FPVM. For these, the result is pulled in through the PreimageOracle. When the result of a precompile is needed to execute a single instruction step on-chain, the challenger calls loadPrecompilePreimagePart in the PreimageOracle contract prior to performing the instruction step, which executes the precompile on-chain (and thus, verifiably computes the result of the precompile call.)

Critically, on-chain, all data consumed from the PreimageOracle by the MIPS thread context is verified to be correct, as it is verified when the data enters the PreimageOracle's mappings. This includes precompile execution results as well as preimages to intermediate trie nodes, consensus-RLP, etc.

[tynes]

Also if it's not immediately clear, the precompiles themselves (besides the accelerated ones) are compiled into MIPs and their execution is included as part of the trace that is bisected on chain

[PaulRBerg]

Thank you for the thorough explanation, @clabby, and for the heads-up @tynes. It all makes sense now.

executes the precompile on-chain (and thus, verifiably computes the result of the precompile call.)
...
Critically, on-chain, all data consumed from the PreimageOracle by the MIPS thread context is verified to be correct

This is what made it click for me.

---

P.S. it seems to me that this model works as long as the precompiles are available on L1. If they aren't available, they would have to be run in the program itself (although that would be costly).

[clabby]

If they aren't available, they would have to be run in the program itself

Yep - exactly. The OP Stack hasn't introduced any new precompiles just yet, but will be soon with the Fjord hardfork (EIP-7212). This one thankfully isn't too expensive to run in the FPVM, though.

[PaulRBerg]

Thanks for confirming. It will be interesting to watch the migration to Fjord.

Generally speaking, I am also interested to see how this fault proving mechanism will stand the test of time as more non-L1 precompiles are implemented on L2. My understanding is that RIPs will lead to a future with many non-L1 precompiles.