feat: evm contract calls

[0xrusowsky]

this PR tackles 2 main areas:

• revamp the previous implementation of contract calls to make it more robust and evm-compliant
• add support for calls between contracts with different compilation targets (r55 and evm)

Revamp previous implementation of contract calls

• feat: impl contract calls #26

allowed contract calls by manipulating revm's frame (call) stack by capturing the return data of the chill frame and manually copying it in the memory region specified in the parent frame.
despite this method worked, it required a previous knowledge of the return size (which was hardcoded at 32bytes for the PoC).

after asking Dani, he mentioned that rather than figuring out the size of the return data i should use the RETURNDATASIZE and RETURNDATACOPY opcodes.

his suggestion made me realize that my initial implementation was a sort of embedding the RETURNDATACOPY in r55's execution env, so i got rid of the frame stack manipulation, and instead implemented contract calls as he suggested (which is way cleaner and fully evm-compliant).

This change modifies:

• eth-riscv-syscalls/src/lib.rs: introduces the 2 new opcodes
• eth-riscv-runtime/src/call.rs: assembles contract calls as CALL + RETURNDATASIZE + RETURNDATACOPY
• r55/src/exec.rs: uses revm's interpreter return data buffer (which is available across frames), rather than having to modify the frame stack

Add support for calls with different compilation targets

with the previous changes, i was confident that the call logic was sound and evm compatible. However, the remaining challenge was that R55 and EVM use different function selectors, so i enhanced the interface macro to handle both compilation targets.

contracts will still auto-generate interfaces, and users can still create interfaces for r55 contracts like before:

#[interface]
trait IERC20 {
    fn balance_of(&self, owner: Address) -> U256;                  // balanceOf
}

however, now they can also inform an "interface compilation target" (either r55 or evm) and they can rename the function names to camel case:

#[interface(target = "evm", rename = "camelCase")]
trait ISimpleStorage {
    fn get(&self) -> U256;                                         // get()
    fn set(&mut self, value: U256);                                // set(uint256)
    fn balance_of(&self, owner: Address, value: U256) -> U256;     // balanceOf(address,uint256)
}

This change modifies:

• contract-derive/src/helpers.rs: to handle the new macro args, and generate the corresponding selector.
• erc20x-standalone/: deprecated in favor of a new testing crate for evm contract call support.

This change introduces:

• evm-caller/: a new crate, with a r55 contract that is set to call a simple evm contract and which is used for testing the new feature
• r55/tests/evm-contract-call.rs: tests for r55 > evm calls, as well as r55 > evm > r55 calls

[leonardoalt]

where is this handled now? Glad to see it gone from here just wondering

[0xrusowsky]

that's what i tried explaining in the PR description, we literally got rid of it in favor of returndatacopy + returndatasize:

allowed contract calls by manipulating revm's frame (call) stack by capturing the return data of the chill frame and manually copying it in the memory region specified in the parent frame.
despite this method worked, it required a previous knowledge of the return size (which was hardcoded at 32bytes for the PoC).

after asking Dani, he mentioned that rather than figuring out the size of the return data i should use the RETURNDATASIZE and RETURNDATACOPY opcodes.

his suggestion made me realize that my initial implementation was a sort of embedding the RETURNDATACOPY in r55's execution env, so i got rid of the frame stack manipulation, and instead implemented contract calls as he suggested (which is way cleaner and fully evm-compliant).

[leonardoalt]

Do we have fmt running in CI? I feel like it would add line breaks here

[0xrusowsky]

i thought there was a cargo fmt check in the CI, but maybe it is quite lax? idk

[leonardoalt]

I feel like there should be something in Alloy that does this or actually the entire conversion from function signature to selector? cc @gakonst

[mattsse]

@DaniPopes not sure if we have this in sol somewhere but maybe this is useful somehow

https://docs.rs/alloy-sol-types/latest/alloy_sol_types/trait.SolType.html