bug: native not executing the same as cairo

[enitrat]

Bug: executing on native doesn't yield the same result as Sierra:

Repro

• Cairo Native fork: feat: ef test compat enitrat/cairo_native#1 downgraded version of libc for compatibility issues
• Sequencer fork: https://github.com/kkrt-labs/sequencer/pull/1/files - Added serde logic for contract classes (unrelated to native) - mostly based on Nethermind's native integration branch
• EF-Tests: our Ethereum test vector runner: Using ContractExecutor to compile Sierra to Native wip: cairo native kkrt-labs/ef-tests#763
  Repro:

clone ef-tests, ensure correct branch
make
make setup-kakarot
cargo test test_baseFeeDiffPlaces_d0g0v0_Cancun --features v1,native -- --nocapture

Expected behavior:
The test should pass

Actual behavior:
The test fails (the execution doesn't crash, but the expected values are not met).

Precisions:

• From the logs I see a contract is being deployed. Normally, running this test doesn't deploy a contract.
• Contracts can only be deployed if, when querying a certain storage var, no value is registered. Thus, perhaps the storage_read is not returning the correct value ?

[edg-l]

I have a question, would it be possible that the bug lies in the blockifier implementation? Especially the syscall handler implementation, since its not exactly the same code as the VM (due to how native is designed). (not ruling out native isn't at fault, but its a possibility)

[rodrigo-pino]

I have a question, would it be possible that the bug lies in the blockifier implementation? Especially the syscall handler implementation, since its not exactly the same code as the VM (due to how native is designed). (not ruling out native isn't at fault, but its a possibility)

Totally possible, there might be a bugs on the syscall handler. Specifically on storage though, they are fairly straightforward to implement and we have dedicated unit tests and ERC20 contracts, which indirectly tests for the correct usage of storage syscalls.

@enitrat do the variable always gets registered? Meaning that it is not behind any conditional, maybe there might be an issue even before in the code that might cause the runtime to take another execution path?

[enitrat]

yes, basically when we setup the state we write to the sequencer state this variable, so normally it's always set to some value.

It's done here:

https://github.com/kkrt-labs/ef-tests/blob/8e680e7d9167a6292a8a6c5926f094d5bcc60e0b/crates/ef-testing/src/evm_sequencer/evm_state/mod.rs#L87-L138

[enitrat]

fixed by #812 I believe