[ZK Stack] - <Custom Gas token for L2 ZK Stack >

[BobbayB]

Module Affected

• System contracts (era-system-contracts)
• Smart contracts (era-contracts)
• zkEVM (era-zk_evm)
• Server (zksync-era)
• Prover (era-boojum)
• Fee withdrawer (era-fee-withdrawer)
• Block Explorer (clock-explorer)
• Portal - Wallet + Bridge (dapp-portal)
• Other (please specify below)

Rust Version

na

Operating System

• Ubuntu
• MacOS
• Windows
• Other (Please specify below)

Issue Description

Are there any deployed testnets where we can test the custom ERC20 gas token functionality?

Can you point me to the bridging contracts that will be used for custom gas chains in this repo?
Repo: https://github.com/matter-labs/era-contracts/tree/main

For chains that do not use custom gas tokens, will this legacy contract still be deployed? Or is that only going to be available on Era?
Legacy contract: https://github.com/matter-labs/era-contracts/blob/main/l1-contracts/contracts/bridge/L1ERC20Bridge.sol

One more question: the L1ERC20 bridge indicates that it is legacy, but I don’t see any other methods that would allow bridging in arbitrary ERC20 tokens. What’s the right method to call?

Expected Behavior

We want to verify that our Across bridge adaptors should work OOTB for ZK Stack chains and what changes are necessary to support ZK Stack Custom Gas tokens.

Current Behavior

n/a

Repository Link (if applicable)

(https://github.com/matter-labs/era-contracts/tree/main)
https://github.com/matter-labs/era-contracts/blob/main/l1-contracts/contracts/bridge/L1ERC20Bridge.sol

Additional Details

From Across/UMA.

Prior Research

• Yes, I searched for similar issues and did not find any matching ones.

[gleenai[bot]]

Testing Custom ERC20 Gas Token Functionality

Currently, there isn't specific documentation available on deployed testnets for testing custom ERC20 gas token functionality within the ZKsync ecosystem. For the most accurate and updated information, it's recommended to check the official ZKsync documentation or directly engage with the development community on ZKsync's GitHub discussions.

Bridging Contracts for Custom Gas Chains

For bridging contracts related to custom gas tokens, you can refer to the general bridging contracts within the same repository you mentioned. While the repository might not explicitly list contracts for custom gas tokens, the existing contracts like the L1ERC20Bridge might give insights into how bridging is handled. For custom implementations, modifications might be necessary.

Legacy Contracts Deployment

For chains not utilizing custom gas tokens, the deployment of legacy contracts like the L1ERC20Bridge will depend on the specific requirements of those chains. Typically, such contracts are deployed to ensure compatibility and facilitate bridging operations between L1 and L2. However, for ZKsync Era-specific functionalities, these might still be deployed to maintain backward compatibility or to support specific bridging functions.

For detailed and specific inquiries, especially regarding integration with Across bridge adaptors and support for ZK Stack Custom Gas tokens, it's advisable to directly consult with the ZKsync development team or contribute to the discussions on their GitHub repository to get tailored advice and updates.

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.

[bxpana]

Thanks for the post and great to see the Across team here!

Are there any deployed testnets where we can test the custom ERC20 gas token functionality?

Yes, you can test this out on Zero Network as well as Cronos. You could also spin up a custom token chain and test things out as well with our new tutorial

Can you point me to the bridging contracts that will be used for custom gas chains in this repo?
Repo: https://github.com/matter-labs/era-contracts/tree/main

The L1SharedBridge is the contract that stores the funds. The actual call has to be started on the Bridgehub here:
https://github.com/matter-labs/era-contracts/blob/bce4b2d0f34bd87f1aaadd291772935afb1c3bd6/l1-contracts/contracts/bridgehub/Bridgehub.sol#L262
Example here:
https://github.com/matter-labs/era-contracts/blob/bce4b2d0f34bd87f1aaadd291772935a[…]fb1c3bd6/l1-contracts/test/unit_tests/custom_base_token.spec.ts

For chains that do not use custom gas tokens, will this legacy contract still be deployed? Or is that only going to be available on Era?

Yes it is only deployed for Era. From the comments I'm seeing on the contract, the L1SharedBridge will be used and the L1ERC20Bridge is needed for backward compatibility with already integrated projects.

One more question: the L1ERC20 bridge indicates that it is legacy, but I don’t see any other methods that would allow bridging in arbitrary ERC20 tokens. What’s the right method to call?

Example in first answer should show this for you

[bxpana]

Updated the answer above with the correct info.

[BobbayB]

The function that was suggested for us to use was requestL2TransactionTwoBridges. I’m a little confused as to how that differs from the direct method above it and what the secondBridge* arguments are referring to. What is the second bridge in this case and why is it needed? The direct method seems more straightforward, but the natspec makes it seem like it should not be called from a contract.

[BobbayB]

Update on the above: we’ve been using this middleware contract as a guide. It appears (to me) that the two bridges method is used when trying to move a token as opposed to a message (or the base token). Is that correct?
In our existing zksync Era code, we have a proxy contract to handle cases where deposit limits are imposed on our contract. But in the current version of the code, it appears as if those might be deprecated. Is that the case? Should we assume there is no limit to the size of the deposit per address?

[bxpana]

Basically when you are doing a deposit, you need to bridge base tokens, and the tokens that you are bridging. These two tokens might have different bridges.
The first bridge is the baseTokenBridge. The secondBridge can be any bridge, allowing any token to be swapped.
This method is needed ( and the Direct method is not enough), because of the two bridges. The call has to pass through both of them, requiring one to handle the others token, e.g. User -> Bridge1 -> Bridge2 -> Bridgehub call trace would mean Bridge2 hold eth and the custom token.
Using this method the Bridgehub directly interacts with the bridges.
The Middleware contract is used by Cronos to fund the users BaseToken fees, as they have a custom base token contract.

For the deposit limit question the link is the same as the middleware contract, so not sure what you mean. At the moment there is no deposit limit per address to Era or any other chain.