Feat: add RIP-7212 to the list of precompiles Cairo1Helpers module

[Quentash]

Add the precompiled contracts p256verify to the list of precompiled contracts at address 0x0b following this implementation : ethereum/go-ethereum#27540 .

I have chosen the 0x0b instead of 0x100 because of the amount of lines that the second one would have added to the precompiles.cairo and I am currently unaware of a precompiled contract at address 0x0b.

Pull Request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build-related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

Resolves: #755

What is the new behavior?

• p256verify is now added to the list of precompiled contract at address 0x0b

Does this introduce a breaking change?

• Yes
• No

---

This change is 

[enitrat]

I have chosen the 0x0b instead of 0x100 because of the amount of lines that the second one would have added to the precompiles.cairo and I am currently unaware of a precompiled contract at address 0x0b.

You can just add a specific if / else before the match table handling this specific case for 0x100. This should not be an issue when deciding a precompile address. Given that it seems a consensus was found on using 0x100 - 0x1ff for rollup precompiles, let's go with 0x100

[enitrat]

Reviewed 4 of 5 files at r1, all commit messages.
Reviewable status: 4 of 5 files reviewed, 3 unresolved discussions (waiting on @ClementWalter and @Quentash)

---

crates/evm/src/precompiles.cairo line 72 at r1 (raw file):

                )
            },
            11 => { P256Verify::exec(input)? },

see main comment - we can still move use it as 0x100

---

crates/evm/src/precompiles/p256verify.cairo line 20 at r1 (raw file):

    fn exec(input: Span<u8>) -> Result<(u128, Span<u8>), EVMError> {
        let gas: u128 = P256VERIFY_PRECOMPILE_GAS_COST;

missing input size check. if size is 160 then you can assume the precompile input is correct and simply message_hash.from_be_bytes().unwrap() (same for all conversions)

globally I think you can remove all the manual error handling as long as size is ok. if size !=160 return 0

---

crates/evm/src/tests/test_precompiles/test_p256verify.cairo line 16 at r1 (raw file):

#[test]
fn test_p256verify_precompile() {
    let (_, _) = setup_contracts_for_testing();

do you need to setup a contract? Can this not be a unit test?

[Quentash]

• Chose 0x100 as precompiled address
• Added length check ( nice catch )
• Added tests concerning length check
• Removed setup_contracts for unit tests

[enitrat]

Reviewed 4 of 4 files at r2, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @ClementWalter and @Quentash)

---

crates/evm/src/call_helpers.cairo line 124 at r2 (raw file):

fn is_precompile(self: EthAddress) -> bool {
    let self: felt252 = self.into();
    return (self != 0 && self.into() < 257_u256);

only [0, 9] and 0x100 are valid addresses, this needs to be modified accordingly

[Quentash]

Corrected precompiled contracts address range

[enitrat]

some tests are failing, can you verify is 256 or 0x100 is an address used in tests?

[Quentash]

Alright, my bad, I missed those since I struggle running every tests and didn't notice it on github.
But indeed, some tests were deploying on the 0x100 address which created conflicts. I changed them to deploy their test contract on 0x101.

[enitrat]

Alright, my bad, I missed those since I struggle running every tests and didn't notice it on github.
But indeed, some tests were deploying on the 0x100 address which created conflicts. I changed them to deploy their test contract on 0x101.

0x101 is still too "close" we should ideally have a random value like 0xabfa740ccd

[Quentash]

You're right ! 0xabfa740ccd it is then !

[enitrat]

Reviewed 1 of 1 files at r3, 1 of 1 files at r5, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @ClementWalter and @Quentash)