BLOGPOST
3327 Logo

Made with love️ for blockchain community by humans from MVP Workshop

Contact us at

[email protected]

All Rights reserved 2024 © 3327

Layer Hack: zkSync’s Account Abstraction

About Layer Hack

Encode Club hosted a great hackathon focused on Layer 2 scaling solutions - Layer Hack. The hackathon lasted for nearly a month (Oct. 17 - Nov. 13), and was sponsored by AltLayer, Boba Network, Metis, and zkSync - each sponsor had their track with its own topic. 

Out of those four tracks, what grabbed our attention was the zkSync’s Account Abstraction (AA) challenge. The open-endedness of the challenge itself - long story short - “build something awesome” (at least that’s how we understood it). 

And so, the 3327 Unit’s - HackOps team decided to gear up and tackle this challenge.

Why did we choose the AA track, what’s the significance of this concept, and most importantly, what have we built? - Stay tuned and be amazed!

Intro to Account Abstraction

In the current Ethereum Virtual Machine (EVM) based systems, there are two distinct types of accounts:

  • Externally-Owned Account (EOA), and
  • Smart Contract Account (SCA)

There exist multiple differences between them, but the ones we will focus on are the fact that only EOAs can initiate transactions and that their validation logic cannot be altered.

Note: We refer to validation logic as the set of rules that need to be obeyed in order for the transaction to be accepted by the network. 

EOAs’ hardcoded validation logic checks whether the transaction was signed by the private key that corresponds to the address of the EOA. In contrast, the validation logic of an SCA can be anything - i.e. multisig.

Having arbitrary logic introduces additional complexity, but it has the benefit of the owner setting their own custom security standards. 

For example, an AA owner can add a “session key” for a specific Decentralized Application (DApp) in one transaction and continue interacting with the DApp without manually signing every transaction. 

The session key’s authority would be limited to a set of specific actions and/or time-limited and/or until a specific range of on-chain states is reached. The applications of this concept are maybe most suitable for on-chain games, where the gamers do not want to break the flow of the game, but any DApp can potentially improve its User Experience (UX) with AA.

There exist several Ethereum Improvement Proposals (EIPs) dating back to 2016 that tackle the AA problem, but it is not known when full AA support will be implemented in Ethereum.

However, in zkSync v2, things are already a lot better:

 “Accounts in zkSync 2.0 can initiate transactions, like an EOA, but can also have arbitrary logic implemented in them, like a smart contract. This feature is called "account abstraction" and it aims to resolve the issues described above.” (Taken from the docs)

Official documentation for zkSync V2

zkSync’s Implementation

Reading the documentation tells us that the (simplified) flow for each transaction consists of the following ordered steps:

  • Validation - logic that checks whether the AA accepts the transaction 
  • Execution - executes the transaction itself

There are, however, limitations to what the validation logic can do, more precisely, what storage slots it can access. In the zkSync’s implementation, the validation logic of an AA (that has the address of AA_addr) can touch:

  • Slots that belong to AA_addr (internal storage of the AA)
  • Slots of type  keccak256(AA_addr || X) - where X can be any native type
    • Useful for accessing mapping (address => value) slots in other contracts
  • Slots of type keccak256(AA_addr || OWN) - where OWN is of type 2 slots
    • Useful for accessing mapping (address => mapping (address => value))

And so, one needs to carefully structure the data that is stored across multiple contracts.

Account Abstraction Plugins Project

There were multiple great ideas that we had for this hackathon - some of which we started researching and implementing after the hackathon.

For Layer Hack, we chose to create a system where the owner of an AA can modify its validation logic according to their always-evolving needs.

Full code is available at 0x3327/layerhack_2022, but we will cover the basic concepts here.

At the center of the AAP is the IPlugin interface that we have defined as such:

interface IPlugin{

     function isValid(Transaction calldata _tx) external view returns (bool);
}

Essentially, the plugin receives the complete transaction and has to decide, based on the transaction’s fields as well as its own internal state, whether it accepts the transaction.

Each AA has a list of enabled plugin types (contracts that support the IPlugin interface), which are called in its validation logic.

We chose to implement a LimiterPlugin type where the owner gives an ETH spending limit to a spender address. The spender can then make transactions that have a value lesser than the limit that is imposed.

contract LimiterPlugin is IPlugin {

    mapping(address => mapping (address => uint )) public activeLimits;

    function isValid(Transaction calldata _transaction)
        public
        view
        override
        returns (bool)
    {
        bytes32 txHash = _transaction.encodeHash();

        address accountAddr = address(uint160(_transaction.from));

        require(_transaction.signature.length == 65, "Signature length is incorrect");

        address signerAddr = ECDSA.recover(txHash, _transaction.signature[0:65]);

        return activeLimits[accountAddr][signerAddr] > _transaction.reserved[1];
    }
}

Note what storage slots we are accessing in the isValid function - only the slots that our AA can touch ( activeLimits[accountAddr] ).

Additionally, this plugin has other functions that need to be called by the AA in order to activate/deactivate these limits for a list of spenders. 

Can a spender increase their own limit? The answer is no because a segment of the AA’s validation logic disallows it - only the owner has the exclusive right to interact with the plugin contracts.

Conclusion 

We would like to give a big shoutout to Encode Club for organizing this eye-opening hackathon, as well as zkSync for working towards implementing AA which will be a game-changer for the whole UX and blockchain adoption.

Currently, we are continuing our research on ideas that use zkSync’s AA mechanism, and we will publish our results soon.


In the meanwhile, let’s connect via Discord or Twitter - We would love to hear from you.

SHARE

COMMENTS (0)

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

You may also find this interesting:

Curvy - protocol for fast anonymous transactions on Ethereum

Have you heard of Stealth Addresses (SA)? Do you know what cryptography is used in their background? Have you heard of BaseSAP, Umbra, or Monero? If so, then find out here what the Curvy protocol is and how it differs from the above protocols. There is a great need to introduce private transactions on public […]

By Marija Mikic
September 24, 2024
Cosmos Blog Header
Ticking All the Boxes: How Madara Modifications Enable On-Chain Game Logic

One of the main lessons from the previous two years is that the blockchain gaming space is expanding rapidly, with many new projects and features being built. However, it still remains in its infancy stage, as no title has managed to grab the mainstream market. I’m not talking about metaverse and virtual reality on the blockchain, though it is a massive part of the gaming space. I’m talking about a core gameplay experience that entirely runs on-chain.

By Filip Moldvai
August 10, 2023
How Lens helps us build user-centric Web3 products?

In our previous blog post, we covered one of the biggest challenges Web3 faces: building user (de)centric products. The main points were: One of the ways to solve this challenge is to start with the validation and exploration of the problems users have rather than a tech solution that can be developed. We want to […]

By Milos Novitovic
December 15, 2022
Deep Dive DeFi: Derivatives

Derivatives DeFi has been an emerging market for the past three years in the Web3 world. Protocols have tried to bridge the gap and bring traditional financial instruments to the Web3world, offering users decentralization, full custody, and favorable conditions to make their own choices with minimum intermediation.  So far, we (Web3 users) have been successful […]

By Andrija Raicevic
December 8, 2022
Let’s geek out together!
Would you love to work with us on Web3-related experiments and studies?
Drop us a message