Closed dcposch closed 7 months ago
In addition to supporting a different compiler, we also need to account for differences in EVM semantics so tests behave as expected. There's an open issue to discuss the best approach for that here: https://github.com/gakonst/foundry/issues/748
I think we need a classification or something for "tiers" of languages/VMs once we start supporting more of them, since we probably can't ship all Foundry features to all languages/backends and it is definitely going to be an iterative process.
The tier should indicate how well-supported the VM or language is. Perhaps a feature table would be nice too to indicate what Foundry features are supported for which languages/VMs. Bare minimum would be build/test (just unit tests, no traces)/deploy
How's this going? Has zkSync era support been added yet? @onbjerg
@daweth zksync has their own foundry fork: https://github.com/matter-labs/foundry-zksync
closing as dup of #7624
Component
Forge
Describe the feature you would like
Support compiling for and deploying to zksync2.
Additional context
Zksync2 is, as far as I can tell, the first (mostly) EVM-compatible ZK rollup. They recently launched a public testnet.
Currently, their deployment pipeline only works with Hardhat. Details: https://v2-docs.zksync.io/dev/guide/hello-world.html#initializing-the-project-deploying-smart-contract
Obviously, I'd prefer to use Forge. I'm not sure what it would take. It looks like we'd have to support using a custom solc. Just opening this as a stub issue to track potential future zksync support.