You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our team here at Moonsong Labs has been working on adding support for zkSync on foundry & we have been cooperating with several ofyourrepos to make sure all your tests are successful with our new implementation.
We are opening this issue today to inform you of required action to ensure this repository's contracts are compatible with zkSync in the future.
In summary, we've identified two issues that we will elaborate on below:
Different Create2 addresses leading to test failures.
Cheatcodes in the EraVM (where they are not normally enabled).
Important note: To replicate, be sure you are using the latest compiler version to ensure you take advantage of the compilation time speed-ups improvements (~16m).
forge test --zksync
If you want to further improve compilation times, you may also use:
forge test --zksync --force-evmla true
In this case, compilation times should be even shorter (~4m) but there’s an additional blocker due to the EraVM contract size limit. Many contracts result in being too big, leading to a bytecode size limit. These bytecode size limitations should be addressed first to replicate these issues if you follow this path. If you decide to follow this path, please review 2. Cheatcodes in non-inlineable libraries below to take into account limitations.
1. Create2 Test Failures
The following tests make use of ConfigEngineDeployer.sol and fail in zkSync mode as the etched bytecode is not a multiple of 32.
This however still fails as the create2 addresses do not match between zkSync and EVM.
Ran 1 test for tests/core/ATokenEvents.t.sol:ATokenEventsTests/test_atoken_burnEvents_withdrawAmountLessThanInterests
[FAIL. Reason: setup failed: revert: failure at create2 address derivation] setUp() (gas: 0)
2. Cheatcodes in non-inlineable libraries
The library SlotParser which is used in aave-v3-origin is using the vm.load cheatcode.
library SlotParser {
Vm private constant vm = Vm(address(uint160(uint256(keccak256('hevm cheat code')))));
function loadAddressFromSlot(address target, bytes32 slot) external view returns (address) {
return address(uint160(uint256(vm.load(target, slot))));
}
}
This piece of code would run inside the EraVM, where cheatcodes are not enabled. Any contract calls inside a test will fall under the same problem.
A possible workaround would be to refactor the library and move the use of the cheatcode to a helper function to use in the test. In that case the code will be executed in EVM where the cheatcodes will be enabled. For a further detailed explanation you can check this comment.
These steps mark the final adjustments needed to ensure compatibility with zkSync for aave-v3-origin. If you encounter any further issues or have additional questions, please do not hesitate to reach out!
Hello! 👋
Our team here at Moonsong Labs has been working on adding support for zkSync on foundry & we have been cooperating with several of your repos to make sure all your tests are successful with our new implementation.
We are opening this issue today to inform you of required action to ensure this repository's contracts are compatible with zkSync in the future.
In summary, we've identified two issues that we will elaborate on below:
Important note: To replicate, be sure you are using the latest compiler version to ensure you take advantage of the compilation time speed-ups improvements (~16m).
forge test --zksync
If you want to further improve compilation times, you may also use:
In this case, compilation times should be even shorter (~4m) but there’s an additional blocker due to the EraVM contract size limit. Many contracts result in being too big, leading to a bytecode size limit. These bytecode size limitations should be addressed first to replicate these issues if you follow this path. If you decide to follow this path, please review 2. Cheatcodes in non-inlineable libraries below to take into account limitations.
1. Create2 Test Failures
The following tests make use of
ConfigEngineDeployer.sol
and fail in zkSync mode as the etched bytecode is not a multiple of 32.The bytecode length panics are fixed with padding the bytecode here with extra 0s:
This however still fails as the create2 addresses do not match between zkSync and EVM.
2. Cheatcodes in non-inlineable libraries
The library SlotParser which is used in
aave-v3-origin
is using thevm.load
cheatcode.This piece of code would run inside the EraVM, where cheatcodes are not enabled. Any contract calls inside a test will fall under the same problem.
A possible workaround would be to refactor the library and move the use of the cheatcode to a helper function to use in the test. In that case the code will be executed in EVM where the cheatcodes will be enabled. For a further detailed explanation you can check this comment.
These steps mark the final adjustments needed to ensure compatibility with zkSync for
aave-v3-origin
. If you encounter any further issues or have additional questions, please do not hesitate to reach out!cc @Karrq @elfedy @HermanObst @Jrigada @nbaztec
The text was updated successfully, but these errors were encountered: