AnhVAR
commented
9 months ago 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
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
Key Features