Starknet's native account abstraction: enabling smart accounts for users

原文：Native Account Abstraction: Opening Blockchain to New Possibilities

Translation and proofreading: "Starknet Chinese Community"

Featured Quick Facts

There is one big hurdle in blockchain's journey to the mainstream market: security and user experience limitations are holding back a wider range of Web 2 users from onboarding blockchain.

Is there any solution? That is Account Abstraction. This is the software layer that disrupts the blockchain landscape, enabling accounts to have flexible design and adjustable deterministic behavior.

Account abstraction is available on both Ethereum and Starknet, but implemented differently. Starknet has a native account abstraction, that is, all accounts are smart accounts. Ethereum, on the other hand, adds account abstraction through ERC-4337 without ignoring the traditional functions of EOA. However, an environment in which EOA continues to thrive will greatly diminish the benefits of account abstraction, as applications will have to continue to cater to EOA.

Barriers to EOA

External Accounts (EOA) are Ethereum's simple solution for creating on-chain user representatives. This scheme allows users to interact with the blockchain and own assets by linking EOA with account assets.

Although this is a simpler way, the behavior of EOAs is predetermined by the protocol they are deployed in, so they lack the flexibility to adjust to the different needs of users. This often results in poor user experience and hinders mass adoption. The protocol has pre-located the biggest problem, which is that EOA is controlled by a pair of private and public keys. Having to use a pair of keys to initiate a transaction leads to three main problems:

Poor user experience — Requiring users to store their private keys in a safe, hidden place is unintuitive to those used to smarter, more modern methods like a six-digit passcode or Face ID, thereby Making it more challenging to initiate transactions.

Only trust the private key — Knowing the details of the private key is not only the only way to initiate a transaction, but also the only way for the protocol to identify the owner of the account. This creates a security risk - if your private key is stolen, the account cannot distinguish you from someone who stole your private key.

The protocol rules everything — It is clear from the examples above that in the EOA space, it is the Ethereum protocol, not the developer, that determines the validity of a transaction.

The complications that arise from determining account behavior as part of a chain's protocol exist in most chains.

Breaking Down Barriers: Introducing Account Abstraction

The problem with most chains is that the protocol determines account behavior, not users. Back in 2015, Ethereum co-founder Vitalik Buterin discussed these challenges. He described the account abstraction as a simpler way of dealing with accounts that reduces, or even ends, the reliance on private keys. More importantly, account abstraction creates a series of other benefits, so that the user experience of Web3 can be as smooth as that of Web2, thus facilitating the large-scale application of Web3.

Over the years, two important approaches to account abstraction have emerged, both with the same goal of enabling developers to design their applications and create a simpler way of handling accounts.

ERC-4337

As mentioned earlier, EOAs are an integral part of Ethereum, and their behavior is defined by the Ethereum protocol. In addition to EOA, Ethereum also has contracts, which contain user-defined code. In 2023, Ethereum launched a protocol upgrade - ERC-4337, which aims to bridge the structural gap between EOA and contracts without introducing major protocol changes. The main idea of ERC-4337 is to introduce a new role: Bundler. The role of Bundler is to collect user actions (think of them as meta-transactions collected in a dedicated mempool) and send those user actions to Ethereum via their own EOA (controlled by Bundler). In this way, Bundler allows developers and users to deploy and interact with account contracts, taking advantage of account abstraction.

Bringing account abstraction to Ethereum via ERC-4337 enables developers to create more flexible behavior for contracts. However, Ethereum will continue to maintain the EOA. For developers, the consequence of this is that they must serve both EOA and ERC-4337. In ecosystems where EOA costs are lower, it is foreseeable that EOA will continue to dominate and applications will not be able to reap the real value of the account abstraction across the user base.

EVM chains that emulate or follow Ethereum (including zkEVM) will undergo a similar evolution: EOA will continue to be the dominant account type, which will diminish the account abstraction advantages that these EVM chains can enjoy, and make them lose their original need to solve Advantages of the EOA Legacy.

Starknet's native account abstraction

In contrast, Starknet has account abstraction at its core, i.e. all accounts are smart accounts. Starknet does not have an EOA, but instead leaps directly into a world where every account is a Smart Account. All infrastructure, including wallets and block explorers, is designed and built for account abstraction. This is unique among all L1 and L2 chains, making Starknet the first smart ecosystem: builders can build their applications and tools knowing that the account abstraction applies to all accounts, without having to Accounts that are not account abstractions work and provide services. Builders can design their applications to benefit from the opportunities provided by account abstraction, knowing that Smart Accounts are the only way for users to interact with the application.

The native account abstraction on Starknet removes the additional complexity introduced by Bundler (as ERC-4337 did). Rather than adapting infrastructure and tooling to interact with Bundler, this process is simplified by specifying sequencers to fulfill the role of Bundler.

Three Pillars of Account Abstraction

Account abstraction mainly includes three components, namely signature abstraction, fee abstraction and Nonce abstraction. Each part has its unique role to enhance the overall user experience.

Signature abstraction

The signature abstract design transaction process puts the power to define valid transactions in the hands of the architect, that is, the account designer, regardless of whether the person is a developer or a user. The main benefit of this is that account permissions can be customized and it makes it possible to control the account using a smartphone.

Cost abstraction

Fee abstraction allows transaction fees to be paid in different tokens, not limited to network native tokens. For example, users can directly use USDC to pay transaction fees without first converting USDC into local tokens, saving conversion fees and time.

Nonce abstraction

Nonce abstraction ensures user comfort and convenience. Traditional sequential nonce solutions suffer from some user experience flaws. For example, due to the need to enforce full ordering, users are restricted from sending multiple independent transactions at the same time. The Nonce abstraction provides the required flexibility by allowing custom account replay protection mechanisms.

Rollups such as Starknet can be regarded as blockchain operating systems. When designing a new operating system, things usually go very smoothly if you don't have to take over the legacy challenges of the previous operating system. It's like building a new house is often easier than renovating an old one. When designing a new home, incorporating important infrastructure such as wiring, plumbing and heating should be considered at the blueprint stage. When building a new home, it doesn't make sense to simply tweak and bend standards that are known to be required in the future. The same principle applies to the account abstraction. Starknet was designed with the future in mind, and we believe it will become the standard way of building applications. Starknet uses account abstraction as the default option, and in fact the only option, thereby providing the smooth, efficient, and user-friendly experience we expect to have in the future.

Judging from the functions brought by the implementation of account abstraction, there are two obvious benefits: one is that users can enjoy a better user experience, and the other is that developers do not need to be troubled by the legacy problems of EOA.

Account Abstraction in Starknet Construction

Just as the invention of software revolutionized the cash economy, Starknet's smart ecosystem has provided fertile ground for future growth. What began as software that digitized records and streamlined processes has evolved into a broader set of systems for managing transactions, tracking finances and automating financial processes. Likewise, Starknet's intelligent ecosystem empowers developers to interact seamlessly with a variety of applications and providers. This not only enhances the user experience, making it richer and more dynamic, it also fosters a collaborative and innovative environment, providing fertile ground for development to continue to grow.

The following advances in several applications amply demonstrate the benefits of using signature abstraction over Starknet-native Smart Accounts:

Braavos

Using Starknet-native smart accounts, the Braavos team created a smart wallet that provides a Web 2-like experience, allowing you to use your phone's biometrics to access your wallet. It's an exciting thing to do! The cryptography used by most blockchains differs from that used by mobile devices, which often results in extremely high signature verification costs. In the future, it may become possible to sign transactions using mobile phones while maintaining a high level of security.

Money

ArgentX's guardianship service, Argent-Shield, brings another innovation by using the signature abstraction. The service lets users add an extra layer of protection to their accounts by having Argent act as a guardian. Only transactions confirmed by email will be approved by Argent. This is another two-factor authentication mechanism we are familiar with and is commonly used in many non-blockchain applications.

Visa

STARK proofs were invented to solve Ethereum’s scalability challenges, aiming to achieve the same transaction per second (TPS) processing power as Visa. As such, Visa’s decision to explore its much-anticipated “automated payments for self-hosted wallets” project on Starknet is an important milestone. This is a testament to Visa's recognition of our advanced technology and innovative smart ecosystem.

in conclusion

Starknet's ecosystem is growing by the day, with more and more developers taking advantage of Starknet's native account abstraction to design their applications in the most flexible way possible. The possibility of integration with other providers, the ability to provide users with a more granular and personalized experience, all demonstrate the endless potential of the digital economy.

Instead of having to deal with legacy technology, developers can build applications from the ground up in an environment designed for future needs.