Using `vm.writeFile` throws `EvmError: Revert`
brotherlymite opened this issue · comments
Component
Forge
Have you ensured that all of these are up to date?
- Foundry
- Foundryup
What version of Foundry are you on?
forge 0.0.2 (4f2145e 2024-07-31T00:29:10.879990000Z)
What command(s) is the bug in?
forge test --zksync
Operating System
macOS (Apple Silicon)
Describe the bug
vm.writeFile cheatcode seems to be revert when used via a helper contract SnapshotHelpersV3
To reproduce the error please run FOUNDRY_PROFILE=zksync forge test --zksync --match-path=zksync/src/20240731_AaveV3ZkSync_TestIssue/AaveV3ZkSync_TestIssue_20240731.t.sol -vv on the repo.
On the traces:
11514] 0x7FA9385bE102ac3EAc297483Dd6233D62b3e1496::test_defaultProposalExecution() ├─ [0] VM::zkVm(false)
│ └─ ← [Return] ├─ [0] 0xF9E9ba9Ed9B96AB918c74B21dD0f1D5f2ac38a30::createConfigurationSnapshot("AaveV3ZkSync_TestIssue_20240731_before", 0xE154F1bc662cb2829D4d5Dc5C25DAC05719cA83A, true, true, true, true)
│ └─ ← [Stop] └─ ← [Revert] EvmError: Revert
We see the call the vm.writeFiles reverts on the createConfigurationSnapshot() method on the SnapshotHelpersV3 contract
Hi @brotherlymite, I wanted to provide an update on our work regarding this issue.
We understand that the problem originated from the split in the Aave proposal contracts, which led to the use of cheatcodes in external contracts—functionality that isn’t natively supported and is quite complex to implement. More context & documentation can be found in the zksync discrepancies aave-v3-origin issue and this related issue.
To partially enable this functionality, we utilized the zkVm cheatcode to switch execution between EVM and zkVM. However, during this transition, a migration occurs, which we believe is corrupting the state. Consequently, when switching back from zkVM to EVM, the cheatcodes stop functioning.
In cases where only one cheatcode is involved, using a low-level call can resolve the issue. This method allows us to verify the state without the additional checks performed by high-level calls. However, Aave’s extensive tests, which involve multiple cheatcodes, make this workaround highly cumbersome. We acknowledge that implementing this would require significant changes to the codebase, and although we’re testing it ourselves, the process is challenging due to the extensive modifications needed.
We understand that a better solution for this is a top priority, and we’re treating it as such. Resolving this will require further research and development time. We’re progressing as quickly as possible, but we anticipate that it will take more time during this week to provide a path forward for this issue.
Hey @brotherlymite thanks for the report - we investigated the issue and found (and applied with #499) a fix that should make your original use case work.
We tried running your example with the fix applied and that resulted in Ownable: caller is not the owner, could you please verify that it is the intended behavior of the test?
Thank you
@Karrq thank you, yes it was expected on the test.
On the latest commit of foundry-zksync I'm able to run the tests without any issues.