[General] How to deploy contracts under reproducible addresses?

[CodeSandwich]

Team or Project

Drips

Environment

Mainnet

L2 block number

No response

Provide a brief description of the functionality you're trying to implement and the issue you are running into.

I need a stable address derivation scheme, so on EVM I would deploy the logic contract and then CREATE2 clones of them, which gives me a known derivation path. On zkSync I can't use clones, but I can cheaply re-deploy an existing contract to a new address, which is comparably good. I do it by obtaining the codehash of the "master copy" of the contract and then by passing it to ContractDeployer.create2. It works fine, but in the Foundry tests context it only works in the top-level tests contracts. Invoking this routine from any other contract causes the This method require system call flag error. I couldn't find anything about the system call flag in the docs or in the help channels. What is this and how to work this issue around? Is my Foundry tests contract a system contract?

Repo Link (Optional)

No response

Additional Details

No response

[gleenai[bot]]

In ZKsync, the deployment of contracts, especially using the create2 method for reproducible addresses, involves specific mechanisms that differ from Ethereum. The error you're encountering, "This method require system call flag," suggests that there's an issue with how the contract deployment is being invoked in your Foundry tests.

Here are a few points to consider and steps you might take to resolve this issue:

1. System Contract Calls: In ZKsync, certain operations, like those involving create2, are restricted to system contracts or require specific flags due to the security model and the way system contracts interact with the ZKsync protocol. This might be why you're seeing the error when calling from non-top-level contracts.

2. Deployment from Non-System Contracts: If your Foundry tests contract is not recognized as a system contract, it may not have the necessary permissions to invoke create2 directly. This is likely the cause of the "system call flag" error.

3. Workaround: To work around this, ensure that any contract that needs to deploy another contract using create2 is either:

   • A system contract itself.
   • Has the appropriate permissions or flags set to allow it to make system-level calls.

4. Documentation and Support: Since this seems to be a nuanced issue specific to ZKsync's implementation and your development environment, I recommend discussing this further with the ZKsync developer community. You can raise this issue on the ZKsync developers discussions on Github for more in-depth support and potential solutions from other developers who might have faced similar challenges.

This approach should help you address the specific error and continue with your contract deployment strategy on ZKsync.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[CodeSandwich]

Has the appropriate permissions or flags set to allow it to make system-level calls.

How do I achieve that?

[CodeSandwich]

I've also noticed something really bizarre in assembly inlines. It seems that the call Yul instruction has a different meaning in zkSync and in EVM. In EVM the first argument is the gas limit, but in zkSync it's the target address to be called, at least when making system calls. Does it mean that all assembly inlines using call written for EVM will fail weirdly on zkSync and need to be rewritten? Can I accidentally call a system contract if I'm unlucky when choosing the gas limit? The weirdest part is that zkSync docs don't mention such difference, the first argument is said to be the gas limit.

[dutterbutter]

Happy to provide a resource that is helpful!

ZK compiler version is not even configurable

You can configure the compiler via foundry.toml as described here, albeit we are going to release a zksolc policy as described in this issue.

would be really cool if the hand-crafted contracts like clone proxy or CREATE3 worked in zkSync

If I am not mistaken this may be supported when we release bytecode evm equivalency as part of our 2025 roadmap. If you haven't seen that I recommend checking it out here.

I don't think that the example of obtaining the bytecode hash you provided in testCreate2SyntaxDeployment is feasible

Definitely agreed, I merely used it to provide an additional example of retrieving bytecodehash.

It's unclear to me when exactly the user will need to provide the bytecode to be deployed via CREATE2 attached to the transaction?

Not exactly sure what you mean here. Can you elaborate?

I would love to use era-contracts as my dependency, but all the contracts inside are weirdly pinned to different versions of Solidity

This is something I've heard more then once, I will try to escalate this to the protocol team so they may make adjustments for an improved developer experience 🙏

Is EfficientCall.rawCall(..., REAL_DEPLOYER_SYSTEM_CONTRACT, ...) different from SystemContractsCaller.systemCallWithReturndata(...)?

Only difference is EfficientCall doesnt re-copy the data into memory it passes a fat pointer to the underlying function

Why are you using ACCOUNT_CODE_STORAGE_SYSTEM_CONTRACT.getRawCodeHash(address(counter)) instead of address(counter).codehash, does it provide any advantage?

tbh I havent really used address(counter).codehash, I have always defaulted to querying storage rather then making use of EXTCODEHASH. address(counter).codehash is certainly nicer, and both still depend on the contract being known (e.g. deployed previously).

[CodeSandwich]

You can configure the compiler via foundry.toml as described here, albeit we are going to release a zksolc policy as described in this matter-labs/foundry-zksync#759.

Awesome, I wasn't aware of these options! They improves the builds reproducibility a lot 👍

release bytecode evm equivalency as part of our 2025 roadmap

Again, that's great, I can't wait for it! I don't expect any commitment, but is it more of a January thing or a Q4-if-stars-align thing?

Not exactly sure what you mean here. Can you elaborate?

Sure. AFAIK when you deploy a contract for the first time to zkSync, you need to attach its bytecode to the transaction that causes the deployment. This only needs to be done once, after that the deployment can be done again by just using the bytecode hash, the zkSync network is expected to know what the contract is supposed to do. If we have a contract like in the example, where a function deploys another contract, at some point somebody must provide the bytecode of the another deployed contract. My question is who and when? It's entirely possible that the another contract is actually deployed for the first time after a long time or even never. Do I need to provide its bytecode when deploying the "parent" contract that will be deploying it? Or does the user who triggers the first deployment need to do that? If so, how are they expected to obtain the bytecode? What's the default behavior and how to do it "right"?

I will try to escalate this to the protocol team so they may make adjustments for an improved developer experience 🙏

Yes please, that would be great! It doesn't seem like an awful lot of work, Solidity is very careful about backward compatibility, but it will enable a ton of tooling for many devs.

[dutterbutter]

Hopefully this min-example provides additional clarity when working with factory contracts.

In that min-example:

1. Parent Deployment Without Child Bytecode:
   In the example, the ChildFactory contract (the parent) is deployed first, but we do not attach the child's bytecode to the factory at this stage. The factory constructor only stores the known bytecode hash, not the full bytecode itself.

2. First Child Deployment (Providing Bytecode):
   When we run the DeployChild script, you see that only at the moment we call factory.deployChild(...) for the first time we use vmExt.zkUseFactoryDep("Child"). This command includes the child's bytecode in the transaction.

3. Afterward, Only the Hash Is Needed:
   When we call factory.deployChild(...) again (using the same child code), we no longer need to provide the vmExt.zkUseFactoryDep("Child") line. The code hash is known, so the second and subsequent deployments can rely on the previously registered bytecode.

We also have a similar HH example and foundry here for native multisigs.

Does that help?

[CodeSandwich]

Does that help?

Yes, thank you! In practice that means that in my use case (a factory deploying copies of a single contract) it makes the most sense to make a dummy deployment of the child contract during the deployment of the factory. It will give me the correct child bytecode hash with no complex steps and will solve the potential UX problems around of the first deployment of the child because the network will be guaranteed to know the bytecode even when the first user triggers the deployment of the first child.

[dutterbutter]

I've also noticed something really bizarre in assembly inlines. It seems that the call Yul instruction has a different meaning in zkSync and in EVM. In EVM the first argument is the gas limit, but in zkSync it's the target address to be called, at least when making system calls. Does it mean that all assembly inlines using call written for EVM will fail weirdly on zkSync and need to be rewritten? Can I accidentally call a system contract if I'm unlucky when choosing the gas limit? The weirdest part is that zkSync docs don't mention such difference, the first argument is said to be the gas limit.

I asked one of our protocol engineers 👇 :

By default zksolc compiler has the same behavior as EVM. However to enable zksync-specific features we use so called "eravm extensions". You can read more about them there. These are special features of our compiler, which roughly look like that: if you use a constant address inside the yul call (and the constant is one from the list here , then yes a special opcode will be invoked). Note, that not all opcodes are available for users for the sake of security, but some are. E.g. this is how EfficientCall library works. For security reasons these extensions are disabled by default, to enable them, you need to provide a special flag to our compiler. An example for foundry zksync.

To sum it up:

• By default the behavior is 100% identical to EVM.
• If you turn the flag on (this may be necessary when you are developing a custom account for instance), then this special behavior would only be activated, only if your call uses a constant special address. I.e. just writing call(gas(), to, ... is not enough, the to must be derived from a constant from the list above known at compile time, which never happens in practice since it would be very weird to use the special addresses from above as a constant (these are empty addresses on Ethereum)

[CodeSandwich]

Thanks for taking your time to reach out to the protocol devs 👍 Now it makes sense.