Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(tracing): decode non-mainnet precompiles when tracing #1078

Open
gakonst opened this issue Mar 27, 2022 · 11 comments
Open

feat(tracing): decode non-mainnet precompiles when tracing #1078

gakonst opened this issue Mar 27, 2022 · 11 comments
Labels
A-compatibility Area: compatibility A-tracing Area: tracing C-forge Command: forge P-normal Priority: normal T-post-V1 Area: to tackle after V1 T-to-investigate Type: to investigate

Comments

@gakonst
Copy link
Member

gakonst commented Mar 27, 2022

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 #1067 (comment)

@onbjerg onbjerg added good first issue Good for newcomers Cmd-forge-test Command: forge test C-forge Command: forge A-tracing Area: tracing P-low Priority: low D-easy Difficulty: easy labels Mar 28, 2022
@onbjerg onbjerg added this to Foundry Apr 17, 2022
@onbjerg onbjerg moved this to Todo in Foundry Apr 17, 2022
@0xduality
Copy link

Avalanche subnets that use the evm have these precompiles

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

More details on the interfaces are here

@mattsse
Copy link
Member

mattsse commented Sep 22, 2022

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

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

@mds1
Copy link
Collaborator

mds1 commented Sep 22, 2022

@avaxmoon do you mind also leaving a comment on foundry-rs/forge-std#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
Copy link

@mattsse I believe you can find all this information here

@0xIsshiki
Copy link

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

@mattsse
Copy link
Member

mattsse commented Oct 2, 2022

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
Copy link

douglasqian commented Dec 6, 2022

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
Copy link

arthurgousset commented Dec 10, 2022

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
Copy link
Member Author

gakonst commented Dec 10, 2022

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

@mds1
Copy link
Collaborator

mds1 commented Dec 18, 2022

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

@palango
Copy link

palango commented Jan 9, 2023

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?

@zerosnacks zerosnacks changed the title Decode non-Ethereum precompiles when tracing feat(tracing): decode non-Ethereum precompiles when tracing Sep 11, 2024
@zerosnacks zerosnacks changed the title feat(tracing): decode non-Ethereum precompiles when tracing feat(tracing): decode non-mainnet precompiles when tracing Sep 11, 2024
@zerosnacks zerosnacks added T-to-investigate Type: to investigate P-normal Priority: normal labels Sep 11, 2024
@grandizzy grandizzy added the T-post-V1 Area: to tackle after V1 label Nov 21, 2024
@grandizzy grandizzy removed this from the v1.0.0 milestone Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-compatibility Area: compatibility A-tracing Area: tracing C-forge Command: forge P-normal Priority: normal T-post-V1 Area: to tackle after V1 T-to-investigate Type: to investigate
Projects
Status: Todo
Development

Successfully merging a pull request may close this issue.