zkSync 2.0 Update: Dynamic Fee Milestone Completed

Author: Shazia

Source: medium

Less than a month after the public roadmap was released , zkSync, Ethereum’s Layer 2 scaling solution, has achieved another major milestone towards mainnet. The dynamic fee milestone includes a new fee model, an update to add payer support to the account abstraction, and EIP-1559 support. This also brings us one step closer to realizing zkSync's mission of extending the value and security of Ethereum.

dynamic fee

In order for the network to function, there are fees to be paid: running an L2 protocol is expensive, and transaction fees must cover these costs. While we have to charge enough to cover the cost, our goal is to keep it as low as possible. This means that behind the simple fact of charging “X ETH” for a transaction, there needs to be monitoring and analysis to ensure that the proposed fee is indeed optimal.

We also want users to be in control of what they agree to pay. Unlike Ethereum, a significant portion of transaction costs represent the amount of data we need to publish on L1 to guarantee data availability. This price component depends on the gas price on L1. Operators calculate fees based on gas prices, and the same transaction on zkSync 2.0 can generate different fees depending on the level of activity on Ethereum.

This means that transaction fees are calculated based on two values: (1) the amount of computation required to process a transaction and generate a proof for it; and (2) the L1 gas fee required to finally complete the transaction. The goal is to allow the user to control these two components.

To distinguish it from the term "gas" used on Ethereum, we use the term "erg". The word was inspired by physics, where "erg" is a measure of "work".

The cost per transaction is defined by several parameters. Some parameters are close to those on Ethereum: [ergsLimit] and [ergPrice]. There is also a parameter [ergsPerPubdataByte] which limits how many ergs each byte of calldata sent to L1 will cost. This last parameter allows users to agree to a specific gas price, for example, to ensure that transactions are not executed during gas price spikes on L1.

With these parameters, transaction fees are estimated based on the expected system resources required and charged based on the resources actually used. This fee model is only a preliminary implementation and improvements are expected. From now on, we will be actively monitoring the system in a live environment, making adjustments to it, and listening to your feedback.

We have several optimizations in place for upcoming milestones that will allow us to provide a better user experience and developer experience while keeping fees as low as possible.

Payer Support

zkSync 1.0 came with native support for ERC-20 tokens used to pay fees, and zkSync 2.0 initially derived the same functionality. However, we decided to add a better feature: "paymaster".

Inspired by EIP-4337 ( explained by Vitalik ), our payer release brings developers a set of tools for building new mechanisms for processing fee payments. It can be used for many purposes. The first and main use is the ability to pay fees in ERC-20 tokens, but it is not limited to this. Imagine, for example, a dApp that subsidizes your transactions, making them cheaper (or completely free). The system is very flexible and allows developers full control over the payment process.

This feature also makes native support for ERC-20 tokens redundant. Users will notice that they initially need ETH to pay fees on some dApps, but as developers move their apps from using fee tokens to payers, users will be able to use other tokens to pay fees. See the zkSync 2.0 documentation for how to do this, and build your own payer.

This is a major improvement to zkSync's account abstraction support, and it won't be the last. Over the next few months, we will continue to refine the interface and deploy improvements.

Important note: To incentivize diversity in the zkSync infrastructure, our mainnet will not ship with a "default" payer. This ensures that everyone is equal and there are no entities in the network that are considered privileged.

EIP-1559 support

EIP-1559 became the new standard for Ethereum transactions, and now the zkSync 2.0 testnet supports it.

While you can send EIP-1559 transactions, the specifics of zkSync differ from Ethereum. For example, all transactions are processed on a first-come, first-served basis, so there is no need to pay first or tip. Currently, EIP-1559 transactions are just a format, not a new layer of functionality in the protocol logic.

However, we plan to build several features on top of EIP-1559. More information will be shared in an upcoming release.

other

Other updates joining this release include:

Now supports the Vyper programming language . See getting started example .

The Hardhat compiler plugin can now download compiler binaries instead of Docker images.

zkEVM compatibility improvements: We actively listen to your feedback on smart contract behavior issues, and our virtual machine now behaves more consistently with Ethereum.

If you experience transaction issues (pending transactions, etc.) after restarting, please reset your Metamask wallet . If this doesn't solve your problem, please join our Discord or send an email to [email protected] .

looking to the future

We are on track to launch the mainnet in 59 days. Stay tuned for the next exciting release.

In the meantime, port or launch your project on zkSync 2.0 by joining our testnet: v2.zksync.io .