search

matter-labs / foundry-zksync

Fork of Foundry tailored for zkSync environment
Apache License 2.0
299 stars 130 forks source link

Have a clear definition of how we interpret intercepted call/creates #642

Open Jrigada opened 2 weeks ago

Jrigada commented 2 weeks ago

When doing a call (https://github.com/matter-labs/foundry-zksync/blob/f7806bba699a32488a6e5f11e51929a45c37cd5b/crates/zksync/core/src/vm/runner.rs#L184) we use env.tx.caller (So using the sender of the root tx that starts the test on the evm) vs using call.caller (This is the caller from CallInput) as the caller? https://github.com/matter-labs/foundry-zksync/blob/f7806bba699a32488a6e5f11e51929a45c37cd5b/crates/evm/evm/src/inspectors/stack.rs#L776

  1. Shouldn’t the sender on the zkEVM transaction be the one making the CALL opcode and hence the one on CallInput vs. the one from the test tx env?
  2. Also right now, from a gas point of view, we are interpreting intercepted call/creates as full transactions and consume the gas a user would be charged to make the transaction. Is there an instance where we would instead want to interpret them as CALL/CREATE opcodes and just charge the execution gas?