[Dev Tools] Difficulties integrating with ZK chain because lack of compatibility with Ethereum Dev Tools

[thomas-nguy]

Team or Project

Cronos zkEVM

Environment

Mainnet

Select the Dev Tool you are using

Hardhat Plugins

Provide the version of the tool (if applicable)

No response

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

Hi, we are receiving some feedbacks from project trying to integrate with Cronos zkEVM complaining that the zksync-hardhat is not completely compatible with their code and the in memory zk-node is missing some core RPCs that is critical for their developments

Is there any alternatives or any plan to support those?

Putting the message below

Currently, the only issue is the amount of refactoring to be done across our three smart contract repos: they all depend on ethersV5, hardhat-toolboxV2 and typechain, while zksync plugins require ethersV6, toolboxV5 and direct usage of contract deployment routines. Also, inMemory zkNode does not support historical access, making many hardhat-chai matchers useless (e.g., .changeEtherBalance, .changeTokenBalance assertions). I am currently looking for ways to reduce the amount of changes while preserving a decent level of assertions. This is at least what have been revealed during smart contract level review.

Repo Link (Optional)

No response

Additional Details

No response

[gleenai[bot]]

It seems you are facing compatibility issues with the ZKsync-hardhat plugins, particularly with the versions of ethers, hardhat-toolbox, and typechain your projects are using. Here are some steps and considerations that might help:

1. Version Compatibility: Ensure that your project dependencies are compatible with the versions required by the ZKsync plugins. For ethers, the ZKsync plugins require ethers v6 for plugin versions ≥1.0.0. It's recommended to update your dependencies to align with these requirements.

2. Toolbox and Typechain: Consider updating the hardhat-toolbox and typechain to versions that are compatible with the ZKsync plugins. This might involve significant refactoring, but it is necessary for integration.

3. InMemory zkNode Limitations: The lack of historical access in the inMemory zkNode is a known limitation. You might need to adjust your testing strategies or use alternative methods for assertions that do not rely on historical data.

4. Alternative Solutions: If refactoring is too extensive, you might want to explore other Layer 2 solutions that offer better compatibility with your existing tools, or wait for updates from ZKsync that might address these compatibility issues.

For more detailed guidance and updates on the development tools, you can visit the ZKsync developers discussions on Github.

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.

[cytadela8]

• What do you mean by the requirement of "direct usage of contract deployment routines"? You can use ex. hardhat-zksync-upgrades that implements hardhat-upgrades funcionality. Typechain is also supported.
• You/They seem to be using hardhat-toolbox. You shouldn't import hardhat-toolbox, but all appropriate modules directly following the guide
• I can confirm your issue with hardhat-chai-matchers. Rewriting is unfortunately the only workaround I have.
• You may also use older versions of hardhat-zksync plugins to avoid upgrading to ethers-v6. I can get back to you on the version numbers to use.

[thomas-nguy]

Thank you @cytadela8

How about the issue regarding the lack of support of the historical access on the in memory zk node?

Any plan to support these?

[cytadela8]

Hi, I have risen this issue further, and we are considering if we have the resources to work on this. I do not have the technical details, but this might require some substantial work.

[thomas-nguy]

Also I receive another question:

Have you guys tried using @openzeppelin/hardhat-upgrades overloaded with @matterlabs/hardhat-zksync-upgradable? I have found a very unexpected bug in hre.upgrades.deployProxy (which is documented on https://docs.zksync.io/build/tooling/hardhat/guides/migrating-to-zksync#deploying-proxy-contracts). When running the following simple code:

const factory = await hre.ethers.getContractFactory(contract); const proxy = await hre.upgrades.deployProxy(factory, args, { initializer: 'initialize'});

error

TypeError: Cannot read properties of undefined (reading 'formatJson') at Function.from (/Users/alxch/dev/debridge/evm-router/node_modules/ethers/src.ts/abi/interface.ts:1260:24) at new ContractFactory (/Users/alxch/dev/debridge/evm-router/node_modules/ethers/src.ts/contract/factory.ts:53:33) at new ContractFactory (/Users/alxch/dev/debridge/evm-router/node_modules/@matterlabs/hardhat-zksync-upgradable/node_modules/zksync-ethers/src/contract.ts:56:5) at deployProxyArtifact (/Users/alxch/dev/debridge/evm-router/node_modules/@matterlabs/hardhat-zksync-upgradable/src/proxy-deployment/deploy-proxy.ts:108:21) at /Users/alxch/dev/debridge/evm-router/node_modules/@matterlabs/hardhat-zksync-upgradable/src/proxy-deployment/deploy-proxy.ts:55:20 at Proxy.<anonymous> (/Users/alxch/dev/debridge/evm-router/node_modules/@matterlabs/hardhat-zksync-upgradable/src/utils.ts:31:16) at async SimpleTaskDefinition.action (/Users/alxch/dev/debridge/evm-router/src/deploy.ts:80:19) at async Environment._runTaskDefinition (/Users/alxch/dev/debridge/evm-router/node_modules/hardhat/src/internal/core/runtime-environment.ts:351:14) at async Environment.run (/Users/alxch/dev/debridge/evm-router/node_modules/hardhat/src/internal/core/runtime-environment.ts:184:14) at async main (/Users/alxch/dev/debridge/evm-router/node_modules/hardhat/src/internal/cli/cli.ts:322:7)

After a bit of debugging I have found out that their makeDeployProxy() expects factory to be instance of zk.ContractFactory, however the hre.ethers.getContractFactory() returns some other (still compatible) object. After adding a hardcoded always-true flag in the source code of @matterlabs/hardhat-zksync-upgradable, it passed

Any clues about this issue?

[cytadela8]

Hi, I'm not sure what is going on without seeing the package.json and hardhat.config, but these types of errors are frequently caused by importing incompatible packages. In this case, I suspect you may be importing @openzeppelin/hardhat-upgrades in hardhat.config.

If you do import @openzeppelin/hardhat-upgrades, please remove it. If you don't, please share your hardhat config and package.json.

[thomas-nguy]

Thank you , very helpful 🙏