Decode non-Ethereum precompiles when tracing

[gakonst]

Right now we only decode the Ethereum precompiles when tracing, we should add some way to decode extra precompiles. What are some example precomppiles from other networks?

Originally posted by @mattsse in https://github.com/gakonst/foundry/pull/1067#discussion_r835886363

[0xduality]

Avalanche subnets that use the evm have these precompiles

• 0x0200000000000000000000000000000000000000
• 0x0200000000000000000000000000000000000001
• 0x0200000000000000000000000000000000000002
• 0x0200000000000000000000000000000000000003

More details on the interfaces are here

[mattsse]

we can integrate them, what we'd need is a list of:

• address
• function signature: <name>(<inputs>)<outputs>

[mds1]

@avaxmoon do you mind also leaving a comment on https://github.com/foundry-rs/forge-std/issues/134 with the list of relevant avalanche precompiles + what chain IDs they apply to + links to docs? That way we remember to include them there when implementing that

[0xduality]

@mattsse I believe you can find all this information here

[0xIsshiki]

Celo has a bunch of extra precompiles here: https://github.com/celo-org/celo-blockchain/blob/91993404cdf69ff4dad810bae8ac02763ae667d8/core/vm/contracts.go#L168-L199

[mattsse]

thanks for linking this.

It would help if you could prepare them as address + signature pairs, this would make it easier to integrate them in the codebase.

[douglasqian]

Celo has a bunch of extra precompiles here: https://github.com/celo-org/celo-blockchain/blob/91993404cdf69ff4dad810bae8ac02763ae667d8/core/vm/contracts.go#L168-L199

JFYI there's a Celo-specific Foundry fork that devs on Celo are using right now: https://github.com/bowd/celo-foundry

[arthurgousset]

Hi @mattsse 👋 @douglasqian kindly pointed me to this Github discussion.

We'd love Celo to be fully compatible with Foundry out of the box 🙌

Regarding your comment above:

It would help if you could prepare them as address + signature pairs, this would make it easier to integrate them in the codebase.

I put together a gist (Adding Celo to Foundry) with key information (mainly for future reference on our side) and @palango (from the Celo blockchain team) kindly provided a small sample of address + signature pairs to verify the format suits you.

I copied the sample below for ease of reference

0x00000000000000000000000000000000000000fd transfer                 (bytes32 sender, bytes32 recipient, uint256 amount) bytes

0x00000000000000000000000000000000000000fc fractionMulExp           (uint256 aNumerator, uint256 aDenominator, uint256 bNumerator, uint256 bDenominator, uint256 exponent, uint256 decimals) (uint256, uint256)

0x00000000000000000000000000000000000000fb proofOfPossession        (address sender, bytes blsKey, bytes blsPop) bool

0x00000000000000000000000000000000000000fa getValidator             (uint256 index, uint256 blockNumber) address

0x00000000000000000000000000000000000000f9 numberValidators         (uint256 blockNumber) uint256

0x00000000000000000000000000000000000000f8 epochSize                () uint256

0x00000000000000000000000000000000000000f7 blockNumberFromHeader    (bytes header) uint256

0x00000000000000000000000000000000000000f6 hashHeader               (bytes header) bytes32

0x00000000000000000000000000000000000000F5 getParentSealBitmap      (uint256 blockNumber) bytes32

0x00000000000000000000000000000000000000F4 getVerifiedSealBitmap    (bytes header) bytes32

My question: How does the above look to you? (i.e. would this format make the integration easier for you?)

[gakonst]

Let's move the conversation to https://github.com/bluealloy/revm/issues/280. Most of these precompiles are stateful, so would like to understand how you are thinking about introducing that state, e.g. https://github.com/bluealloy/revm/blob/main/crates/revm_precompiles/src/lib.rs#L58

[mds1]

Just noting that one other part of compatibility would be to update StdChains and assumeNoPrecompiles in forge-std with the required Celo information

[palango]

Let's move the conversation to bluealloy/revm#280. Most of these precompiles are stateful, so would like to understand how you are thinking about introducing that state, e.g. https://github.com/bluealloy/revm/blob/main/crates/revm_precompiles/src/lib.rs#L58

Will there be anything else needed besides the changes in revm for decoding, like the ABIs? Or will this just work once the precompiles are in revm?