omurovec / foundry-zksync-era Goto Github PK

Overview

Deploying directly from L2 requires some additional problem solving including sending custom eth_sendTransaction calls which could require some changes to foundry or some messy ffi calls. Some more research has to be done here to figure out the proper solution.

Requirements

• Format tx data to this spec
• Sign data using vm.sign()
• Broadcast EIP-712 data (will most likely require changes to forge)

address DIAMOND_PROXY_MAINNET = 0x1908e2BF4a88F91E4eF0DC72f02b8Ea36BEa2319; address DIAMOND_PROXY_GOERLI = 0x32400084C286CF3E17e7B677ea9583e60a000324;

Needs flipping

Overview

It would be good to also have a way to verify contracts properly. This will probably not be possible with foundry atm due to compiler differences however it should be possible through the block explorer interface.

The solc version should be set to whatever solc --version evaluates to on your machine and the zksolc version should match the version specified in your Deployer() constructor. Have tried this with optimized selected and without but does not seem to work correctly for me.

1. The alias method deployFromL1 should return the counterfactual address
2. Both deployFromL1 functions could also return the response from requestL2Transaction, which is the l2 tx hash.

Overview

Currently we require users to add their operating system & architecture to their env variables (to use for downloading the correct compiler binary) however it would be much easier to run a script that can determine this automatically.

Details

This is done in zksync-hardhat-solc but it is not as trivial using solidity/foundry.

The solution would most likely require some bash scripting.

Hi, I noticed you need to pass in value to pass the _verifyDepositLimit check inside the function being called. Thanks!

Overview

The broadcast param in deployFromL1 is used to toggle vm.broadcast calls but this is unnecessary since broadcasts are not actually broadcast to the chain unless the --broadcast flag is used. This means there is really no need to have this extra parameter.

When using this on non Apple Silicon macOS or on x64 Linux, foundry-zksync-era will download the macOS ARM binary & therefore not function as intended.

This is due to a bug in the way FFI has been implemented to detect system info. It just gets back $(uname -m) verbatim from the ffi call, without evaluating the intended command, hence the ternary statements default to arch and os to macOS / arm64 respectively, which leads to the wrong binary being downloaded & executed.

Overview

Currently we hard-code the gas values for requestL2Transaction to be the max values so that it never fails. What we should do instead is estimate the correct values that it is expected to cost.

Details

It is somewhat unclear how to get these values, but the relative docs can be found here