ZkSync introduces account abstraction, L2 → L1 messaging

水多多|zkSync

2022-07-23 08:00

Read this article in 27 Minutes

Account abstraction allows us to program authorization to achieve greater wallet and protocol design diversity through use cases.

ZkSync - Introducing account abstraction, L2 L1 messaging, and more

The original author: water | zkSync

Today, we are driving significant structural changes to improve the user experience, improve compatibility with Ethereum EVM, and upgrade the performance of the zkSync V2 test network.

Hello, account abstraction

In this update, we added account abstraction, a feature that has been described as a "long-held dream of the Ethereum developer community." The goal of account abstraction is to reduce the number of account types or entities with Ethereum (ETH) balances that can send transactions. Ethereum currently has two types of accounts -- accounts controlled by private keys and contract accounts.

Account abstraction moves to enforce a single account type, like a contract account, and pushes features like validating signatures, gas payments, and replay protection from the core protocol into EVM, unlike today's Ethereum, where all transactions must start from EOA or an account controlled by a private key. At a very high level, account abstraction enables us to program authorization to achieve greater wallet and protocol design diversity through use cases, including:

- Implement smart contract wallet to improve user experience of private key storage and recovery (e.g. social recovery, multisig)

- The ability of tokens outside ETH to pay natural gas costs natively

- Ability of an account to change public and private keys

- Added unencrypted modifications, users can request expiration time for transactions, confirm slight errors, etc

- Diversity of signature verification systems from current ECDSA, including post-quantum secure signature algorithms (e.g., Lamport, Winternitz)

In other words, account abstraction brings significant improvements to the overall user experience and expands the application design space for developers, and we're sure to see a lot of creative use cases not covered above when it comes to how to use it. Note: AA EOA accounts like Metamask are still supported by ZKSync.

Call level 1, L2 - >; L1 message online

Prior to this upgrade, developers could transfer messages from Ethereum communication to zkSync V2, but not from V2 back to Ethereum. This upgrade closes the communication loop and allows developers to send information to Ethereum when something happens on L2 and then act on it.

For example, DAOs can lock voting tokens in L1's vault but vote on zkSync, which costs much less. Once the vote is finalized, zkSync can forward the results to Ethereum, where the information can be acted on.

We added support for msg.value

Msg. value is a transaction attribute that defines how many ETH are sent in a transaction. Given that ETH is a special token type (not ERC20) and relies on this property, this means that native ETH transactions on zkSync V2 were not previously possible, forcing the developers to modify the existing code base to use wrapped ETH instead. With this new addition, native ETH can be traded on zkSync V2, making it easier than ever for developers to migrate their code base.

New opcode

L2 -> The addition of L1 messages enables us to simplify the interface to the protocol and replace hard-coded operations such as withdrawals with generic L1 & LT; > L2 communication. The compiler now supports the following opcodes to smooth the migration of L1 smart contracts to zkSync.

EXTCODESIZE

CALLVALUE (msg.value)

BALANCE

SELFBALANCE

EXTCODEHASH

We've already done a reset

To implement these changes, we reset the zkSync 2.0 test net, which means that contracts have to be redeployed, account balances and transaction status reset, and we will do another reset before the main net starts up.

The interior management

These upgrades are among the most needed for developers, and we're excited to see what unique applications they unlock. Given that the purpose of the test net is to enhance our system, errors and problems can be expected (especially account abstraction, which should be considered a volatile feature and ground-breaking changes are expected in the near future).