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

ecpairing precompile decoding is incorrect #5337

Closed
1 of 2 tasks
recmo opened this issue Jul 8, 2023 · 5 comments · Fixed by #6222
Closed
1 of 2 tasks

ecpairing precompile decoding is incorrect #5337

recmo opened this issue Jul 8, 2023 · 5 comments · Fixed by #6222
Labels
T-bug Type: bug

Comments

@recmo
Copy link
Contributor

recmo commented Jul 8, 2023

Component

Forge, Other (please describe)

Have you ensured that all of these are up to date?

  • Foundry
  • Foundryup

What version of Foundry are you on?

forge 0.2.0 (c78a811 2023-07-08T00:13:27.174343000Z)

What command(s) is the bug in?

forge test

Operating System

macOS (Apple Silicon)

Describe the bug

0x08: ecpairing(x1: Uint(256), y1: Uint(256), x3: Uint(256), x2: Uint(256), y3: Uint(256), y2: Uint(256)) -> (success: Uint(256)),

I'm not sure where x1, y1, x3, x2, y3, y2 comes from, but it's there.

The ecpairing interface doesn't follow the ABI standard strictly and is ((x, y), ((x0, x1), (y0, y1)))*. See eip-197.

@recmo recmo added the T-bug Type: bug label Jul 8, 2023
@gakonst gakonst added this to Foundry Jul 8, 2023
@github-project-automation github-project-automation bot moved this to Todo in Foundry Jul 8, 2023
@DaniPopes
Copy link
Member

We were using the definitions from evm.codes and looks like it was incorrect there, see smlxl/evm.codes#236

This is a simple fix, just renaming the parameters correctly, if anybody wants to take this on 🙂

@recmo
Copy link
Contributor Author

recmo commented Jul 8, 2023

It's a bit more complicated than renaming. The number of variables itself is dynamic. Note that precompile contracts do not follow ABI encoding rules, and for this one and modexp there is no ABI equivalent. What maybe works is decoding the first couple point pairs and decode the rest as raw bytes? Or just do everything as raw bytes.

As it is right now, when you have a Groth16 pairing check it looks like this:

PRECOMPILE::ecpairing(
17519552636721698831893983089005607244313436617223871493622354365226943523095 [1.751e76],
7121326991389379063369205750624509106532474629342682182707280696044506219231 [7.121e75],
8956693125727482614765896064098910453911452457095550427166762652229288610568 [8.956e75],
8339411128381037772491803473605093476447566279367653017086352304208450530941 [8.339e75],
1852029409971259439300520532102969363036906940939032723317032686200726164899 [1.852e75],
20939026486477391100834172923405965640443170384568933644798260848108189293729 [2.093e76]
)

But this is missing most of the data. The actual calldata is:

26bbb723f965460ca7282cd75f0e3e7c67b15817f7cee60856b394936ed02917
0fbe873ac672168143a91535450bab6c412dce8dc8b66a88f2da6e245f9282df
13cd4f0451538ece5014fe6688b197aefcc611a5c6a7c319f834f2188ba04b08
126ff07e81490a1b6ae92b2d9e700c8e23e9d5c7f6ab857027213819a6c9ae7d
04183624c9858a56c54deb237c26cb4355bc2551312004e65fc5b299440b15a3
2e4b11aa549ad6c667057b18be4f4437fda92f018a59430ebb992fa3462c9ca1
2d4d9aa7e302d9df41749d5507949d05dbea33fbb16c643b22f599a2be6df2e2
14bedd503c37ceb061d8ec60209fe345ce89830a19230301f076caff004d1926
0967032fcbf776d1afc985f88877f182d38480a653f2decaa9794cbc3bf3060c
0e187847ad4c798374d0d6732bf501847dd68bc0e071241e0213bc7fc13db7ab
304cfbd1e08a704a99f5e847d93f8c3caafddec46b7a0d379da69a4d112346a7
1739c1b1a457a8c7313123d24d2f9192f896b7c63eea05a9d57f06547ad0cec8
001d6fedb032f70e377635238e0563f131670001f6abf439adb3a9d5d52073c6
1889afe91e4e367f898a7fcd6464e5ca4e822fe169bccb624f6aeb87e4d060bc
198e9393920d483a7260bfb731fb5d25f1aa493335a9e71297e485b7aef312c2
1800deef121f1e76426a00665e5c4479674322d4f75edadd46debd5cd992f6ed
090689d0585ff075ec9e99ad690c3395bc4b313370b38ef355acdadcd122975b
12c85ea5db8c6deb4aab71808dcb408fe3d1e7690c43d37b4ce6cc0166fa7daa
2dde6d7baf0bfa09329ec8d44c38282f5bf7f9ead1914edd7dcaebb498c84519
0c359f868a85c6e6c1ea819cfab4a867501a3688324d74df1fe76556558b1937
29f41c6e0e30802e2749bfb0729810876f3423e6f24829ad3e30adb1934f1c8a
030e7a5f70bb5daa6e18d80d6d447e772efb0bb7fb9d0ffcd54fc5a48af1286d
0ea726b117e48cda8bce2349405f006a84cdd3dcfba12efc990df25970a27b6d
30364cd4f8a293b1a04f0153548d3e01baad091c69097ca4e9f26be63e4095b5

I don't care much about the variable names, but I do care about being able to see all the calldata.

@CluEleSsUK
Copy link

Sorry to necro this, but I still get EvmError: InvalidFEOpcode running PRECOMPILES::ecpairing in tests.

i'm running forge 0.2.0 (b174c3a 2024-02-09T00:19:10.198273000Z) on mac m1 which ought to include the fix in the PR attached to this issue.

@DaniPopes
Copy link
Member

Not related at all, that error is an 0xfe opcode was encountered while executing bytecode. Usually a solidity 0.4 revert or something like arbitrum precompiles not being loaded. Please open another issue if you really think this is not right.

@CluEleSsUK
Copy link

Ah I see, thanks for your help and quick response!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-bug Type: bug
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants