Gno Account Abstraction

[AnhVAR]

Account abstraction is a specification designed to achieve account abstraction within the Ethereum ecosystem without necessitating alterations to the consensus layer protocol. However, in the Gnoland blockchain, account abstraction employs distinct mechanisms. This document outlines various methods for implementing account abstraction in Gnoland, while also evaluating the pros and cons of utilizing an independent contract versus account abstraction.

INTRODUCTION

Blockchain technology has evolved over the past decade, offering innovative solutions for various industries. However, the user experience with blockchain has not always been seamless. Traditional interactions with blockchain, often through wallets, have presented challenges such as the risk of forgetting or losing private keys. These issues can lead to significant consequences, including the loss of assets or the inability to access important contracts, thereby impacting both security and user experience.

Moreover, the complexity of blockchain technology poses a barrier to entry for newcomers who may struggle to grasp concepts like wallets and blockchain integration into real-life scenarios. This lack of understanding further complicates the adoption of blockchain technology among a wider audience.

To address these challenges and enhance usability, there's a growing need for solutions that seamlessly integrate blockchain into everyday activities, such as gaming, while ensuring real-time updates to the blockchain. In response, the concept of account abstraction has emerged as a promising approach. Account abstraction aims to simplify the user experience by abstracting away technical complexities, making it easier for individuals to interact with blockchain applications and Web3 platforms effortlessly.

OVERVIEW OF ACCOUNT ABSTRACTION (ERC-4337)

ERC-4337 simplifies blockchain transactions by working above the consensus layer. Instead of directly altering how Ethereum's core functions, it creates a system similar to the transaction mempool. Users submit "UserOperation" objects containing their actions and necessary data. Miners or bundlers, like those in Flashbots, can then combine these objects into a single transaction bundle, which is then added to an Ethereum block.

UserOperation: These are like transaction objects used to execute transactions with contract accounts. They're created by the dapp. Wallets should be able to translate regular transactions into UserOperations, so dapps' frontends don't need to change to support ERC-4337.

Bundler: Bundlers package UserOperations from a mempool and send them to the EntryPoint contract on the blockchain.

EntryPoint Contract: This smart contract handles the verification and execution logic for transactions.

Account Contract: These are smart contract accounts owned by a user. They serve as the user's smart contract wallet.

Factory Contract: When using a wallet for the first time, the initCode field of the UserOperation specifies the creation of the smart contract wallet. Wallet developers need to implement the account factory contract to ensure determinacy of generated addresses.

Paymaster Contract: Optional smart contract accounts that can sponsor gas fees for Account Contracts or allow payment for fees with ERC-20 tokens instead of ETH.

Common Uses

• Easy Wallet Creation: ERC-4337 simplifies creating wallets by removing the need to manage private keys, making it easier for users to access and use cryptocurrencies.
• Account Recovery: It supports recovering accounts if users lose their private keys, using alternative methods like email, phone numbers, or social networks.
• QR Code Payments: Users can pay easily using QR codes, avoiding the need to enter lengthy wallet addresses.
• Advanced Smart Contracts: ERC-4337 enables creating more complex smart contracts with enhanced security and management features.
• Signing Service: It allows creating signing services where users can sign transactions without exposing their private keys.
• Identity Management: ERC-4337 can create decentralized identity management systems, giving users control over their personal data.

Key Features

• Transaction Summary: Users get a simple summary of transactions before confirming, helping them understand the transaction's impact.
• Two-Factor Authentication: Supports two-factor authentication for increased account security.
• Password Signing: Users can sign transactions using a password instead of a private key.
• Spending Limits: Users can set spending limits on their accounts to prevent losses from attacks.
• Cross-Chain Interoperability: It enables creating decentralized applications that work across different blockchains.

[AnhVAR]

Because the concept of two EVMs and GNOVMs is different, we have some changes in ERC 4337. It will not change the core blockchain; it is based on smart contracts available in the blockchain.

IMPLEMENT A SIMPLE CONTRACT SOLUTION.

In this solution, we're letting one wallet authorize another wallet to help it perform actions with a smart contract. It's not a complete wallet system; it's just a way to handle some basic tasks through another wallet.

func Login(driverAddress std.Address) *Car {
    std.AssertOriginCall()
    caller := std.GetCallerAt(2)
    if caller != std.GetOrigCaller() {
        panic("should not happen") // because std.AssertOrigCall().
    }
    index, carI, ok := addrOwner2Car.Get(caller.String())
    if ok {
        car := carI.(*Car)
        car.driverAddress = driverAddress
        addrOwner2Car, _ = addrOwner2Car.Set(caller.String(), car)
        addrDriver2Car, _ = addrDriver2Car.Set(driverAddress.String(), car)
        return car.(*Car)
    }
    car := &Car{
        ownerAddress:  caller,
        driverAddress: driverAddress,
        name:          "Car lever 1",
        x:             100,
        y:             100,
    }
    addrOwner2Car, _ = addrOwner2Car.Set(caller.String(), car)
    addrDriver2Car, _ = addrDriver2Car.Set(driverAddress.String(), car)
    return car.(*Car)
}

func assertIsDrive(caller string) *Car {
    index, carI, ok := addrDriver2Car.Get(caller)
    if !ok {
        panic("Please login to create new car, car not found !")
    }
    car := carI.(*Car)
    if caller != car.driverAddress.String() {
        panic("drive not able access")
    }
    return car.(*Car)
}

func Right() {
    std.AssertOriginCall()
    caller := std.GetCallerAt(2)
    if caller != std.GetOrigCaller() {
        panic("should not happen") // because std.AssertOrigCall().
    }
    car := assertIsDrive(caller.String()) // This line is changed
    car.x += 100
}

In the code example, we're showing how the main wallet can give permission to another wallet to control a game car. We have functions like Login, Up, Down, Left, and Right for moving the car. The Login function allows the owner car to authorize the driver, so it can take actions on its behalf.

COMPARE USING ACCOUNT ABSTRACTION AND SIMPLE CONTRACT SOLUTION

Aspect	Account Abstraction	Simple Contract Solution
Practical wallet	It supports all the functions of a wallet	Only perform delegation to another wallet, through the backend
Complexity	More complex due to abstraction and additional logic	Simpler as it directly interacts with smart contracts
Security	Offers enhanced security by abstracting user interactions	Security depends on the implementation of contract functions or caller
Flexibility	Provides greater flexibility for managing user interactions	Limited flexibility compared to abstraction
Gas Efficiency	Can potentially optimize gas usage through batching	Gas costs may vary depending on contract design
Scalability	Can improve scalability by reducing individual transaction overhead	Scalability depends on how efficiently contracts are designed
Implementation Effort	Requires additional implementation for abstraction logic	Simpler to implement without abstraction layer
Adoption Difficulty	May require more understanding of abstraction concepts	Easier for developers with basic smart contract knowledge

[zivkovicmilos]

@AnhVAR

Thank you for opening up this hackerspace discussion, and I apologize it's been a minute since you've received any feedback 🙏

I'm curious to understand more how you plan to apply this ERC-4337 system for the GnoVM.

The basis of ERC-4337 is that you can utilize EVM traits like delegatecall and create2 to orchestrate account factory creation and execution delegation. If I'm understanding correctly, you are proposing we utilize the on-realm storage in place of factories and call delegaton?

What is exactly being abstracted away here? The user would still need to utilize their own account (form and sign a transaction) in order to perform an operation on the Realm -- this is something doable in Solidity, within the same Smart Contract.

How would gas payment work through the Paymaster contract, given that the GnoVM / TM2 does not support any kind of payment model other than signer pays, no refunds?

I would like to see an expansion on the following parts of the proposal:

• how realm factories would be created, given that the GnoVM does not implement concepts like create2 and delegatecall
• where the bundler mempool would live, and how user operations would be defined (within their own unique Msg I'm assuming)
• a flow diagram detailing and contrasting the user operation flow between the EVM (ERC-4337 proposal) and the GnoVM, given that these systems have drastically different account models and language features

[AnhVAR]

@zivkovicmilos
I understand. Based on your perspective, applying ERC-4337 to GnoVM could be challenging due to significant differences between the EVM and GnoVM. This is entirely reasonable.

Our proposed solution is using Realm as a solution to handle features like secondary accounts representing primary accounts in transactions on the chain makes sense. However, the question of whether ERC-4337 can be effectively applied to GnoVM remains open.

@moul proposed solution is also a viable option, and further discussion on applying ERC-4337 to GnoVM will help us better understand the capabilities and limitations of each approach.

Let’s continue the discussion and explore more to make an informed decision for GnoVM. 😊