Native Account Abstraction of Starknet Enabling Smart Accounts for Users

Original Text: Native Account Abstraction: Opening Blockchain to New Possibilities

Translation and Proofreading: “Starknet Chinese Community”

Highlights

There is a major obstacle for blockchain to enter the mainstream market: the limitations of security and user experience hinder the wider adoption of Web 2 users in blockchain.

Is there a solution? That is Account Abstraction. It is a software layer that disrupts the blockchain landscape, giving accounts flexible design and adjustable deterministic behavior.

Account Abstraction is available on Ethereum and Starknet, but the implementation is different. Starknet has native Account Abstraction, where all accounts are smart accounts. Ethereum, on the other hand, adds Account Abstraction through ERC-4337 without neglecting the traditional functionality of EOA. However, the thriving environment of EOA greatly weakens the advantages of Account Abstraction, as applications will have to continue to cater to EOA.

Barriers of EOA

External Owned Accounts (EOA) are simple solutions created by Ethereum to represent on-chain users. This solution allows users to interact with the blockchain and possess assets by linking EOA with account assets.

Although this is a simpler way, the behavior of EOA is predetermined by the protocol it deploys, making them inflexible and unable to adjust to different user needs. This often leads to poor user experience and hinders large-scale adoption. The protocol has already identified the biggest problem, which is that EOA is controlled by a pair of private and public keys. Requiring a pair of keys to initiate transactions leads to the following three major issues:

Poor user experience – Users are required to store their private keys in a secure and hidden place, which is not intuitive for those accustomed to using more intelligent and modern methods (such as six-digit passwords or face ID), making initiating transactions more challenging.

Recognition of private keys only – Knowing the details of the private key is not only the only way to initiate transactions, but also the only way the protocol identifies the account owner. This creates a security risk – if your private key is stolen, the account cannot distinguish between you and the person who stole your private key.

Protocol dominance – From the above example, it is clear that in the EOA field, it is the Ethereum protocol, not the developer, that determines the validity of transactions.

The complex problems caused by determining account behavior as part of the chain protocol exist in most chains.

Breaking Barriers: Introducing Account Abstraction

Most chains have this problem, where the protocol determines account behavior, not the user. As early as 2015, Vitalik Buterin, the co-founder of Ethereum, discussed these challenges. He described Account Abstraction as a simpler way to handle accounts, reducing or even eliminating reliance on private keys. More importantly, Account Abstraction creates a range of other benefits that make the user experience of Web3 as smooth as Web2, facilitating large-scale applications of Web3.

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

ERC-4337

As mentioned earlier, Externally Owned Accounts (EOAs) are an integral part of Ethereum, and their behavior is defined by the Ethereum protocol. In addition to EOAs, Ethereum also has contracts, which contain user-defined code. In 2023, Ethereum introduced a protocol upgrade – ERC-4337, with the aim of bridging the structural gap between EOAs and contracts without introducing major protocol changes. The main idea of ERC-4337 is to introduce a new role: Bundler. The Bundler’s role is to collect user actions (treating them as meta-transactions collected in a dedicated memory pool) and send these user actions to Ethereum through their own EOA controlled by the Bundler. This way, Bundlers enable developers and users to deploy and interact with account contracts, thereby gaining the advantages of account abstraction.

By introducing account abstraction into Ethereum through ERC-4337, developers are able to create more flexible behaviors for contracts. However, Ethereum will still continue to maintain EOAs. The consequence for developers is that they will have to serve both EOAs and ERC-4337. In an ecosystem where EOAs have lower costs, it can be foreseen that EOAs will continue to dominate, and applications will not be able to reap the practical value of account abstraction across the entire user base.

Simulated or derivative Ethereum Virtual Machine (EVM) chains (including zkEVM) will also undergo similar evolutions: EOAs will continue to be the dominant account type, which weakens the account abstraction advantages that these EVM chains could have enjoyed and deprives them of the advantage of not having to address legacy issues of EOAs.

Native Account Abstraction on Starknet

In contrast, Starknet embraces account abstraction as its core, where all accounts are smart accounts. Starknet does not have EOAs, but instead jumps 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 construct their own applications and tools knowing that account abstraction applies to all accounts, without having to work with and serve non-account abstraction accounts. Builders can design their applications to benefit from the various opportunities provided by account abstraction, as they know that smart accounts are the only way for users to interact with the applications.

The native account abstraction on Starknet eliminates the additional complexity introduced by the introduction of Bundlers (as done by ERC-4337). Instead of adjusting infrastructure and tools to interact with Bundlers, the process is simplified by specifying sorters to fulfill the role of Bundlers.

Three Pillars of Account Abstraction

Account abstraction mainly consists of three components: signature abstraction, fee abstraction, and nonce abstraction. Each component has its unique role in enhancing the overall user experience.

Signature Abstraction

Signature abstraction designs the transaction process, giving the power to define valid transactions in the hands of the architect, that is, the account designer, whether they are developers or users. The main advantage of doing this is the ability to customize account permissions and make it possible to control accounts using smartphones.

Fee Abstraction

Fee abstraction allows the use of different tokens to pay transaction fees, not limited to the native network token. For example, users can directly use USDC to pay transaction fees without first converting it to the local token, saving conversion fees and time.

Nonce Abstraction

Nonce abstraction ensures user comfort and convenience. Traditional sequential nonce solutions have some user experience flaws. For example, due to the need for enforced ordering, it restricts users from sending multiple independent transactions simultaneously. Nonce abstraction provides the required flexibility by allowing custom replay protection mechanisms for accounts.

Rollups like Starknet can be seen as blockchain operating systems. When designing a new operating system, things usually go very smoothly if there are no challenges inherited from the previous operating system. It’s like building a new house is often easier than renovating an old one. When designing a new house, important infrastructure such as wiring, plumbing, and heating systems should be considered in the blueprint stage. It doesn’t make sense to just adjust and adapt to known future requirements when building a new house. The same principle applies to account abstraction. Starknet’s design is forward-looking, and we believe it will become the standard way to build applications. Starknet adopts account abstraction as the default and in fact, the only option, providing the smooth, efficient, and user-friendly experience we expect in the future.

From the functionality brought by implementing account abstraction, there are two obvious benefits: better user experience for users and developers not being troubled by the legacy issues of EOA.

Account Abstraction in Starknet Development

Just as the invention of software has fundamentally changed the cash economy, Starknet’s intelligent ecosystem has also provided fertile ground for future development. Initially, software digitized records and simplified processes, and now it has evolved into a broader system for managing transactions, tracking finances, and automating financial processes. Similarly, Starknet’s intelligent ecosystem empowers developers, applications, and providers to interact seamlessly. This not only enhances the user experience, making it richer and more vibrant, but also promotes a collaborative and innovative environment, providing a fertile ground for continuous growth in development.

The progress made by the following applications fully demonstrates the advantages of using signature abstraction on Starknet native smart accounts:

Braavos

The Braavos team has created a smart wallet using Starknet native smart accounts, which provides a Web 2-like experience, allowing you to access your wallet using biometric authentication on your phone. This is exciting! Most blockchains use encryption techniques that differ from those used on mobile devices, which often leads to high signature verification costs. In the future, it may be possible to sign transactions using a phone while maintaining a high level of security.

Argent

By using signature abstraction, Argent’s custody service, Argent-Shield, brings another innovation. This service allows Argent to act as a custodian, adding an extra layer of protection to users’ accounts. Only transactions confirmed via email are approved by Argent. This is another familiar two-factor authentication mechanism that is commonly used in many non-blockchain applications.

Visa

The invention of STARK proofs was aimed at addressing Ethereum’s scalability challenges and achieving the same transaction processing capacity as Visa in terms of transactions per second (TPS). As a result, Visa has decided to explore its highly anticipated “self-custody wallet with automatic payments” project on Starknet, which is a significant milestone. This demonstrates Visa’s recognition of our advanced technology and innovative smart ecosystem.

Conclusion

The Starknet ecosystem is growing rapidly, and more and more developers are designing their applications in the most flexible way using Starknet’s native account abstraction. The possibilities of integrating with other providers and offering users a more sophisticated and personalized experience demonstrate the endless potential of the digital economy.

Developers no longer have to deal with outdated technologies. Instead, they can build applications from scratch in an environment designed for future needs.

Like what you're reading? Subscribe to our top stories.

We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!

Starknet

Gambling Chain