Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
Written by Harry (@StackDigest)
Summary
- Native Account Abstraction offers significant advantages, including lower gas fees and an enhanced developer experience.
- Specifically, it reduces gas fees by approximately 38% compared to ERC-4337. This improvement can be tested on Pioneer Alpha, the public Native AA devnet built on the OPÂ Stack.
- Kroma team is actively contributing to refining the current standards and continuously enhancing the implementation of Pioneer Alpha.
Intro: Problems of ERC-4337
Recently, smart accounts have seen increasing use. Since the launch of ERC-4337 on the mainnet in 2023, over 13 million smart accounts and 52 million UserOps have been created, with Paymaster-supported gas totaling approximately $3.2M.
Status Quo of Smart Accounts and ERC-4337 | Source: BundleBear
However, the current smart account infrastructure has some problems, with two main areas in need of improvement:
- High Gas Fees
Transactions involving smart accounts consume approximately five times the gas compared to EOA for ETH transfers and about 80% more for ERC20 transfers.
Although EIP-4844 has reduced overall L2 gas fees significantly, occasional gas fee spikes can severely impact user experience. For dApps sponsoring transactions via paymasters, high gas costs can increase operational expenses.
The primary cause of this issue is the gas overhead generated by the Entrypoint contract in ERC-4337, which was introduced to avoid protocol changes. The various calls, sanity checks, and calculations performed within the Entrypoint contract contribute significantly to the overall gas costs.
Furthermore, as Vitalik mentioned in a blog post, once Ethereum transitions to a Verkle tree, the gas costs associated with loading contract code will become non-negligible. It is estimated that the Entrypoint contract could consume around 158,700 gas during Verkle tree loading, which would further degrade user experiences of smart accounts. - Poor Developer Experience
Since ERC-4337 involves off-chain processes, it does not provide an ideal development environment for developers building on smart accounts. Although tools like permissionless.js and Viem have been developed to ease the process, the need for extensive abstraction in libraries negatively impacts transparency and speed.
Smart contract developers also face limitations when considering smart accounts:
- The handleOps transaction that sends UserOps originates from the Bundler EOA, making it impossible to use tx.origin in contracts interacting with smart accounts.
- Multiple UserOps executed within a single transaction in ERC-4337 can lead to unexpected transient storage behavior, potentially introducing security vulnerabilities if not explicitly cleared at the end of the transaction.
Additionally, even if UserOps are processed like transactions, it is a non-standardized way of handling transactions and lacks compatibility with existing tools that handle transactions. This creates challenges, such as the inability to use existing data analysis tools as is.
These issues are further detailed in this Medium article.
Pioneer Alpha: OP Stack Native AAÂ Devnet
The Kroma team believes that Native Account Abstraction is essential to address these issues. The Kroma team is implementing three standards — RIP-7560, RIP-7711, and RIP-7712 — on the OP Stack. Inspired by the ERC-4337 team’s implementation, we have further developed the implementation of the standards, launching the Pioneer Alpha Devnet in July 2024, including basic functionalities for public testing.
In this section, we will present the results of the gas benchmark conducted on Pioneer Alpha comparing the RIP-7560 transaction to ERC-4337, and explain the two key features implemented on Pioneer Alpha.
Enshrinement of Entrypoint Contract
The Pioneer Alpha introduces several key differences from the standard OP Stack Geth.
- New transaction types and a mempool of bundled AA transactions
- A new state processor for AA transactions
- APIs for convenience (e.g., eth_estimateRip7560TransactionGas)
Through protocol-level integration of the Entrypoint contract by implementing RIP-7560, the Pioneer Alpha reduces the gas overhead intrinsic to ERC-4337.
Previously, in ERC-4337, the bundler would collect UserOps and send a transaction to call the handleOps function in the Entrypoint contract, which would then interact with each smart account and paymaster.
With Native Account Abstraction, the logic of the Entrypoint is integrated into the protocol via a new transaction type (AA transaction), and the state_processor_7560 takes over the Entrypoint’s responsibilities of calling smart accounts and paymasters, calculating gas, and performing other necessary checks.
The process for handling AA transactions in this new system is as follows: when the consensus client calls a forkChoiceUpdated API at geth to create a block, the worker (miner/worker.go) calls the PendingRip7560Bundle function in the RIP-7560 bundle mempool (core/txpool/rip7560pool.go), which returns a bundle object containing the AA transactions. The bundle is then processed natively in core/state_processor_rip7560.go. The process is illustrated in the diagram below.
Gas Benchmark
Thanks to the protocol-level integration of the Entrypoint contract, AA transactions in Pioneer Alpha are significantly cheaper than UserOp.
Below is a gas estimation comparison between ERC-4337 (version 0.6) and RIP-7560 (Pioneer Alpha) for ETH and ERC20 transfers.
In both cases, RIP-7560 showed approximately 38% gas reduction compared to ERC-4337. Notably, the ERC20 transfer’s gas cost is not much different to that of an EOA, which typically costs around 50,000 ~ 60,000 gas.
The benchmark results and methodology are open sourced in the rip7560-scripts repository and can be replayed based on the Pioneer Alpha.
Bundler as a part of the Sequencer (Block Builder)
In the previous Medium article and Optimism spec thread, the structure for Native Account Abstraction we proposed was designed to enable multiple bundlers to participate in the system, similar to ERC-4337. However, after discussions with the ERC-4337 team and various bundler providers, we concluded that it would be better to keep the bundler as part of the sequencer (block builder).
Having multiple bundlers opted in this system exacerbates the following problems:
- Bundle Frontrunning
In this architecture, UserOp bundles are submitted via a new transaction bundle mempool, which exposes bundlers to frontrunning attacks. Attackers can intercept and exploit the bundler’s verification work without risk, thereby diminishing bundler profits and incentives. This vulnerability is already recognized as an issue in ERC-4337. - Potential liveness attack to the blockchain
In ERC-4337, bundlers were responsible for the validation of AA transactions. However, in RIP-7560, this responsibility shifts to block builders. This change raises concerns about potential DoS attacks from malicious bundlers targeting the sequencer, creating a significant liveness attack vector for the chain. To mitigate the risk of DoS attacks on block builders, additional mechanisms such as reputation systems or staking may be necessary. However, these solutions increase engineering complexity and expand the attack surface. Furthermore, they do not fully protect honest participants from being blacklisted or penalized in the event of a frontrunning attack.
For these reasons, we have opted to keep the bundler as part of the sequencer. So there will be only one bundle per a block, and only one global bundler handling AA transactions, if it is applied to the current OP Stack networks. Geth has a predefined Bundler RPC URL, and only bundles from this URL are treated as valid. This setup is akin to a trusted RPC, and arbitrary bundles from other bundlers are not accepted in the mempool.
From the perspective of users/developers and chain operators, changes from ERC-4337 due to this structure are as follows:
- Users/Developers
Users can send AA transactions to the bundler in the same way they send transactions to an RPC. Wallet providers and users can direct all types of transactions to a single RPC URL managed by a router, which then routes the AA transactions to the bundler. - Chain Operators
Chain operators will need to run an additional bundler node, which is not much different from running an extra RPC node. However, due to the transaction verification logic running inside the bundler, it may consume more resources than a typical RPCÂ node.
Future Works
Contribution to Finalizing Relevant RIPs
The RIPs related to Native Account Abstraction are currently in Draft status and have not been finalized. Kroma team has identified several issues with the standards during the implementation process, and is working with the ERC-4337 team to address these issues. The Kroma team plans to continue contributing to finalizing these standards and building production-level implementations based on OPÂ Stack.
Improvements of Current System
While Pioneer Alpha implements all relevant RIPs for Native Account Abstraction, there are areas that need improvement to reach production-level quality. The following enhancements are planned:
- Implementing Validation Phase Observability
- Separating context between transactions within a bundle when applying RIP-7711
- Developing sorting logic for the position of RIP-7711 bundles within a block
In addition, general code refactoring for readability and minimizing diffs will also be undertaken.
Rigorous Testing
Native Account Abstraction introduces significant changes to the execution client, potentially impacting network liveness. If not correctly designed, it could lead to the creation of bad blocks or open up DoS attack vectors on the sequencer.
Therefore, rigorous testing is essential to handle edge cases and mitigate attack surfaces. Comprehensive unit and integration tests will be conducted on the Geth code, and extensive testing will be performed on the bundler client provided as a reference implementation to prevent potential issues.
About Kroma
As Asia’s leading Layer 2 solution built on the Superchain, Kroma is the first OP Stack rollup with an active fault proof system utilizing zkEVM.
Kroma will transition to a universal ZK Rollup once the generation of ZK proofs becomes more cost-efficient and faster — using its original modular ZK backend library, Tachyon.
Kroma plans to push for gamified web3 experience backed by its strengths in gaming, consumer applications, Asia market, and technical capabilities for true universal web3 adoption.
Follow us:
Website | Twitter | Discord | Warpcast | Github | Docs | Ecosystem | Brand Kit |Â Grant
Deep Dive into Pioneer Alpha was originally published in Kroma on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.