[Proposal] Custom base token support about era-contracts

[thomas-nguy]

Related PR

#12

[githubdoramon]

On initial question @thomas-nguy - Why requiring token to have 18 decimals and don't make this customizable?

[thomas-nguy]

@githubdoramon
At the EVM layer (L2) the gas token should have an 18 decimals representation (many operations and sdks depends on it for wei/gwei conversion), if we choose a base token that does not have 18 decimals it will create complications.

[githubdoramon]

@githubdoramon At the EVM layer (L2) the gas token should have a 18 decimals representation (many operations and sdks depends on it for wei/gwei conversion), if we choose a base token that does not have 18 decimals it will create complications.

@thomas-nguy
Good point. We could still create the L@ version with 18 decimals regardless of decimals amount on L1, and upon withdrawals leave any remainder on the L2 side when converting back. Not at ALL a priority or needed on the first iteration, but could be a future use case (imagine Circle wants a hyperchain for example).

[mm-zk]

Hey @thomas-nguy ,

First - thanks for great description of the issue (and a draft PR).

IMHO - I'd be leaning towards doing these changes in separate Facet right now - this will allow faster experimentation. And once the features stabilize, we could add them to the main facet if needed.

[mm-zk]

For the part about:

it is crucial to implement an Oracle in the future to adjust the gas_price on layer2 according to the related price of the base token against Ethereum (could be a coefficient factor stored in DB and updated by a trusted oracle)

I guess we'd have to modify the GasAdjuster (more details here: https://github.com/matter-labs/zksync-era/blob/main/docs/advanced/gas_and_fees.md)

[thomas-nguy]

Hi @mm-zk .

I agree with the facet approach. I think this is the best way to test new features in the zk contract without breaking existing logic.

The reason I use the "same facet" approach in the PR #12 is to make the changes more obvious to review, but I will re-open a new PR using the new facet approach

Regarding the GasAdjuster, it seems that we have the same idea :)

I have opened up a PR in the zksync repository that give an idea of our implementation

matter-labs/zksync-era#96

Let me know if this approach is acceptable

[jaguard2021]

Advantages:

Diversification of Base Tokens: Supporting ERC20 as the base token allows for the use of custom tokens, enhancing flexibility and catering to diverse user needs.

"Minimum Change" Principle: The "minimum change" approach can help reduce risks and system complexity by altering only necessary parts without significantly disrupting existing functionalities.

Contract Flexibility:

CustomBaseMailBox: Adding a new facet like CustomBaseMailBox can facilitate the management of logic related to custom base tokens without disturbing the existing Mailbox. This can aid in separating responsibilities and improving code clarity.

Changes to Existing Contract: Implementing changes to the existing contract can provide a non-breaking change solution, but care must be taken to avoid increasing the complexity of the already existing contract.

Disadvantages:

Maintenance Duplication: Opting for an approach with two facets (CustomBaseMailBox and MailBox) may lead to maintenance duplication. Every change in one facet must be manually implemented in the other facet, increasing the risk of errors.

Oracle and Token Conversion: The solution proposes introducing an Oracle in the future to adjust gas_price on Layer 2 and a mechanism for converting the base token to ETH on Layer 1. While this considers costs and stability, the implementation needs careful consideration to avoid introducing additional complexity.

Gas Price Considerations: Adjusting gas_price on Layer 2 based on the price of the base token against Ethereum requires careful consideration and management to avoid potential exploitation or instability in the network.

[shahar4]

@thomas-nguy thanks again for this fantastic issue! I'm closing this for now and will resume the main design.