OKX Research: Account Abstraction - A 10-year Evolution and the Final Showdown. Exploring the Past and Future with EIP-7702

Original Title: "OKX Research Institute | Account Abstraction 10-Year Evolution Endgame, Looking at the Past and Future through EIP-7702"

Original Author: shisilu, OKX Research Institute

Pectra is the first major upgrade after Ethereum Dencun, covering the Prague execution layer hard fork and Electra consensus layer update, integrating a record 11 EIPs in history, significantly improving validator flexibility, network scalability, and execution efficiency. With the Ethereum mainnet Pectra hard fork expected to be officially activated on May 7, 2025, the "ultimate form" of account abstraction—EIP-7702, has also officially entered the public eye!

If there is still any EVM-based Web3 wallet that does not support EIP-7702, then undoubtedly, it is equivalent to giving up the entire Ethereum ecosystem and its users. This is the determination of Vitalik and the EF, and it is also the prelude to the opening of Pandora's Box! Currently, to support the Ethereum ecosystem, OKX Wallet has taken the lead in supporting the latest Ethereum account abstraction standard EIP-7702, and has opened an official entry point for users who are willing to try it out. Users can upgrade through the 【OKX Wallet Homepage Feature Area-More-7702 Upgrade】 to experience the secure and professional EIP-7702. Friendly reminder: Users can choose to upgrade and experience as needed, and not upgrading will not affect the normal use of the existing ecosystem and applications. To ensure asset security, it is necessary to operate through official channels, beware of phishing links and malicious websites, and avoid asset risks.

Please follow this article to fully understand the evolutionary history of account abstraction, the user value and market changes brought by EIP-7702, and the hidden dangers within.

Overview

This article involves code located in okx/js-wallet-sdk, the EIP-7702 SDK implementation used by OKX Wallet, all of which is open source for the community.

· EIP-7702 introduces a new transaction type that allows a regular EOA to designate a contract address as its logic proxy contract.

· EIP-7702 will comprehensively inherit and surpass the ecosystem built over many years by ERC-4337 due to its "cost advantages" and "flexibility."

· EIP-7702 also poses invisible risks to ordinary users, as even if users do not upgrade, transaction failures or security risks may occur in specific scenarios.

· EIP-7702 will bring a brand new user experience. When the user's identity undergoes contract-based migration, market applications will also evolve accordingly. Long-awaited smooth experiences such as Gas abstraction, hierarchical family accounts, and more will lead one billion people to enter the Web3 world at a low cost.

For trading platforms and DApps, the application of EIP-7702's features will bring more than a 50% cost reduction, enabling a full embrace of the contract account era.

Why Should an Account Be Abstracted?

It is hard to imagine that the vision of account abstraction predates Ethereum itself.

During this HK Web3 Carnival, Vitalik emphasized multiple times that Ethereum has already achieved 50% of the "iPhone moment" goal through solutions such as multisig, account abstraction, ZK Email, and a series of other approaches.

Fast or slow, optimistic or limited? Let us delve into the underlying aspects to see why AA has such influence! After all, after a 10-year marathon, Vitalik has finally achieved the culmination he has longed for in the AA field, adding a vivid stroke to Ethereum's roadmap progress bar for the 23-year vision.

Account Abstraction: What is it for?

In essence, it solves the problem of property separation because currently, the ownership and signing authority of EOAs (Externally Owned Accounts) are essentially held by the same entity (both rely on a private key for any instruction control). This originates from Ethereum's transaction structure, where standard Ethereum transactions do not have a From field. During execution, the From address is reverse-engineered from its VRS parameters (the user's signature).

Moreover, as Ethereum is designed as a "world-state machine" that relies entirely on transactions to achieve on-chain state changes, and due to the inability to specify a From field, transaction execution authority is coupled with ultimate ownership.

This is why EOA, although simple to understand, is the root cause of a series of usability issues:

· Difficult to protect private keys: Losing the private key (due to loss, hacking, quantum decryption) means losing all assets.

· Limited signature algorithms: Different signature algorithms bring different performance costs, including on-chain storage costs.

· High signature authority: EOA's native private key has all these rights.

· High fees for complex transactions: Transaction fees can only be paid in ETH, and any transaction or single operation requires a basic fee of at least 21,000.

· Transactions lack privacy, even though the Circle proposed a confidential ERC-20 protocol in the past, it did not become mainstream.

Ultimately, in today's blockchain world, it is too complex for users to get involved, as users need to understand concepts such as Gas price, Gas limit, transaction blocking (Nonce order). Hiding complex information from regular users is what EIP-7702 ultimately aims to solve.

What is the core difference between ERC-4337 and EIP-7702?

Regarding AA as the goal, there are actually more than ten different proposals, which the author has explored before. In essence, when summarizing overall, there are two main routes:

Route One: EOA Address Driving CA Address

ERC-4337 is a typical example of this. In summary, it proposes a new transaction object called UserOperation. Users send this object to the memory pool, where it is batched by bundlers to execute transaction instructions sequentially through contract delivery. Essentially, it brings the underlying transactions and account operations to the contract level for execution.

The execution principle is as follows:

Through the role of bundler, this solution addresses issues such as batch transactions, gasless transactions, fewer signature algorithms, and more. However, it does not address complexity, user transaction costs, and the single point of failure risk of bundler and EntryPoint.

Because once a user migrates to ERC-4337, even if, as in the user2 demand in the diagram above, they only need to make a Transfer transaction, the user's transaction fee will double compared to an EOA.

From the latest user volume data of CA and EOA, it can be seen that even if some users are high-end players who heavily rely on various operations based on on-chain CAs, batch calls, etc., if so, why not just use a regular CA?

Due to the bundler's design, it can avoid hard fork-level upgrades and be directly introduced at the application layer. However, ERC-4337 also brings doubled cost, single point of failure risk, and users lose the flexibility of the original EOA. Therefore, faced with diverse user demands, it is evident that the current market users are not so favorable to the ERC-4337 solution. The overall trend has dropped significantly over the 2 years of development, even though the peak number of users is far from the 300M independent addresses on Ethereum.

Of course, we are not here to nitpick the shortcomings of ERC-4337, but rather to acknowledge the evolution that has taken place alongside it, with the introduction of roles and concepts such as Paymaster and Gas Abstraction, which have also been further applied in EIP-7702.

The author believes that the development of any industry is not instantaneous; what's important is to learn from the past's ups and downs, discover patterns, and draw on experience.

Option 2: Transforming EOA Addresses into CA Addresses

Back in November 2015, Vitalik proposed EIP-101, suggesting a new account structure using contracts as accounts. This change would transform addresses to consist only of code and storage space, shift fee support to be ERC20-based, convert the native token balance to a pseudo-ERC20 format through a precompiled contract (enabling features like token withholding authorization), and introduce EIP-859 in January 2018. The core function of EIP-859 was to enable wallet contracts deployment on-the-fly if the recipient contract was not yet deployed, leveraging the code parameter attached to the transaction. Eventually, from the concept in EIP-3074, the solution evolved into EIP-7702, making its way to the Ethereum mainnet!

The concept and impact of EIP-7702 are straightforward. It introduces a new transaction type for initialization, allowing subsequent users to enable temporary, optional smart contract capabilities within a single transaction using an EOA. This facilitates business operations such as batch transactions, gasless transactions, and custom permission management. The key capability is granting users temporary and optional functionality.

Moreover, multiple users can share the same logic contract, significantly reducing user migration costs. Setting up EIP-7702 requires only 80,000 gas (approx. $0.06) and modifying or canceling the logic contract requires 40,000 gas.

Once set up, significant gas optimizations can be achieved during batch transactions, as shown in the table below:

You might wonder whether it's necessary to perform two or even six Token Transfers?

While regular users may be accustomed to performing one action per transaction, scenarios that involve multiple Token Transfers may not be common. However, in diverse applications like Web3 Games and Web3 Payments, such situations can occur frequently. For example, scenarios where users simultaneously spend in-game currency (copper coins) and deposited currency (silver coins) or participate in an event requiring the consumption of an NFT ticket along with an entry fee.

Even if we don't consider complex scenarios, returning to the most mainstream on-chain Swap demand today, there is also a need for batch approve and Transfer. In fact, now you can create a small tool to help users quickly remove their unused approve authorizations. The effect is easy to compare. Clearly, costs can be directly reduced by about 40%.

The Core Principle of EIP-7702

To explore why this effect occurs, we need to go back to its principle, which is actually based on two logics, divided into the user setup phase and the daily use phase.

Setup Logic Contract Phase

The core process is as follows:

Step 1: Signature Authorization, sign a unique hash string with the original EOA's private key, the content of which is constructed through encoding chain_id, address, and nonce. Here, the Address is the address of the logic contract to be set, and the Nonce ensures the transaction is not replayed.

Step 2: Signature Transaction, with the authorization information from step 1, anyone can construct a type 4 transaction, which can include multiple authorization information, authorizing multiple addresses in a unified manner.

Step 3: Broadcast to the chain, so when the transaction completes internal Authorization processing, the logic contract is already in effect.

There are more technical details here, refer to: the implementation of the OKX open-source JS SDK to see the underlying data encoding process. Of course, this solution also hides some security risks and complexities, which we will discuss in detail in the following sections.

Execution Logic Contract Phase

Once you have set up, when any transaction To address points to you, it will be similar to calling a smart contract. The system will "load" the code of the logic contract you originally set into your current EOA state to execute its logic.

Likewise, let's examine using two scenarios:

The First Type, Calling Yourself

If you have set up a smart contract similar to OKX 7702 Smart Contract, which boasts high security and customizable control capabilities, you can specify through pre-written calldata to have your current operation complete multiple instructions at once. For example, you can complete Approve+Transfer simultaneously, or Approve+Swap at the same time.

Do not underestimate the power. Out of a total of 2.7 billion Ethereum transactions, Approve accounts for approximately 75 million transactions. Calculated at 80,000 Gas per transaction, this results in the consumption of 460,000 ETH. Based on a $1700 ETH market price, this amounts to nearly $8 billion.

The Second Type, Being Called by Others

Previously, Ethereum did not have situations where others could call an EOA address. However, now, you are a versatile smart contract that can be fully customized. You can create sub-accounts for permission delegation, or whitelist a few Paymasters to permit designated DApp accounts to initiate transactions on your behalf, thus completely eliminating the awkwardness of repeatedly prompting for signatures in traditional blockchain applications.

What a powerful capability! Therefore, almost all mainstream wallets including OKX Wallet, Metamask, WalletConnect, Biconomy, BaseWallet, Rhinestone, ZeroDev, TrustWallet, Safe, and other related teams are rapidly providing support in response.

Is EIP-7702 the Endgame of Account Abstraction?

Yes, Because This Time, the User Will Choose it!

It's not that EOAs are not good enough. Objectively speaking, EOAs are straightforward, simple, and secure. However, after the Prague upgrade and the introduction of EIP-7702, EOAs will be better. This is because of cost and user experience. Just like the experiences users had when Steve Jobs pulled out an iPhone from his jeans pocket, things that users had not initially considered possible.

Account abstraction is actually an area that many chains are exploring and actively experimenting with. For example:

· Starknet, as a ZK-Rollup (Layer 2), defaults to using contract accounts and does not have EOAs.

· zkSync Era, where using an AA account is the default way, and there is no need for the complexity of a Bundler.

· Nervos CKB, similar to the UTXO model, but it also allows all accounts to customize their validators, separating holding from control.

· Aptos / Sui, as a key player in the Move-based Layer 1, although not following the EVM-style AA, also has the ability for account customization, allowing modular signature schemes, multi-party validation, and more.

As for the EVM ecosystem—Linea / Base / Mantle / Polygon / Arbitrum / Optimism, these related ecosystems have not only completed AA support through ERC4337, but will also almost all follow the EIP-7702 upgrade, just like the Ethereum mainnet. Wallets and foundational infrastructure in the AA domain are even more comprehensively preparing for EIP-7702.

These advancements stem from the core experience optimizations of EIP-7702: batch transactions, Gas abstraction (including Gasless and other gasless solutions), and account custody. Similar services such as Coinbase, Metamask, Biconomy, Zerodev, Rhinestone, Ithaca, among others, all fully support these developments.

All of these advancements have further evolved from the ERC-4337 era, which is a significant strength of EIP-7702. Ultimately, the primary account entity takes the form of both an EOA and a CA, allowing for the migration and adaptation of a large number of infrastructures that were once centered around AA.

Now, let's use a table to illustrate the final effect layer differences between EOA, ERC-4337, and EIP-7702.

Objectively speaking, the Ethereum system carries a much heavier historical burden than other chains. This is why there has been recent community opposition to Vitalik's modification of the EVM virtual machine and why early on there was a need to choose ERC-4337. However, once a better option (EIP-7702) is available that can achieve compatibility with historical burdens and excellent cost optimization, users will experience an "iPhone moment."

With the transformation of the underlying form, further imaginative forms can also be envisioned, such as:

· Users can achieve wallet control using Passkey or Google Account. Implement limited condition-free signing and other experiential features.

· Users can achieve Recovery capability through setting up ZKEmail, allowing them to retrieve private keys.

For on-chain whale operations, with multiple transactions integrated into one, it can significantly reduce block waiting time, making on-chain swaps faster. Through consecutive transactions, the risk of transaction failures is also reduced. Time has a huge impact on user experience. As the consensus system ranked second in the entire blockchain world (only behind BTC), ETH cannot, like BSC, arbitrarily reduce block time from 3s to 1.5s to enhance user experience. Therefore, based on the EIP-7702 wallet tool, which is the most important bridge for user experience.

Therefore, in conjunction with our previous discussion of its underlying principles, it can be said that EIP-7702 is the ultimate form of account abstraction!

However, if everyone will fully use it in the future, it is not very likely because its application itself requires caution. Once integrated with complex intelligence, it brings about security risks, and some attack methods are even very subtle. Therefore, after the Ethereum Prague upgrade activation on May 7, 2025, what users need most is a truly secure wallet, guided by technical professionalism.

Has the final battle ended?

No.

Indeed, Pectra is by far the most ambitious Ethereum upgrade to date, covering 11 EIPs, the highest number in history! We have seen the many benefits of EIP-7702, and we have made judgments based on the principles and data presented above. However, it is after user involvement and selection that the market will face a chaotic battle.

In the continuous development of the AA ecosystem, a trend of fragmentation has gradually emerged. Among them, the EIP that defines account abstraction at the framework level has interface standards such as ERC-4337, ERC-6900, ERC-7579, but there are significant differences in user experience, interface specifications, and behavioral expectations between different implementation solutions. Different wallet implementation solutions focus on similar application scenarios and limited core functions, but each adopts incompatible design assumptions and implementation logics.

One of the most typical hidden problems is storage disarray. After the introduction of EIP-7702, the storage space under an EOA account can be used by contracts, and this storage space is not monopolized by a single contract but may be collectively used by multiple smart account providers, switching it off.

When a user initiates a "re-delegation" operation, the original account contract will be replaced by a new contract. However, the state data written by the old contract will not be cleared and will still be retained in the storage of that EOA. This means that the new proxy contract can access or even modify the storage data written by the old contract, introducing the risk of "state pollution" that may disrupt or even destroy the current contract's execution logic.

Although various solutions have emerged in the community, such as isolating storage through namespaces (ERC-7201) to reduce the impact of storage confusion, there is still a lack of a mandatory unified standard in the current ecosystem to ensure the uniqueness and security of nonces.

Another typical issue is the disorder of standard execution. As revealed in this article: "Moving from Fragmentation to Unity: The Necessity of Smart Account Standardization"

Today, Safe, Biconomy, and ZeroDev have each implemented their own version of batch call functionality, but the three have different function names, interface parameters, and result handling methods. ZeroDev considers scenarios where batch calls fail, while Safe and Biconomy do not handle such scenarios.

The industry's standard "every man for himself" approach inevitably leads to a battle of chaos, with users, dApps, and developers being the victims. Therefore, the introduction of EIP-7702 is not only a technological innovation but also an opportunity to establish a common infrastructure for smart accounts. It provides us with a window of "refactoring consensus," driving the entire Web3 wallet ecosystem from feature diversity to structural uniformity, achieving truly sustainable development.

Three Essential Security Understandings After EIP-7702 Activation

Now, let's switch perspectives and look at this system from different angles: from users, from dApps, from organizations like exchanges, etc., to see how it affects us. It brings opportunities but also risks. Only by understanding the risks can we fully enjoy the benefits of this system.

Is EIP-7702 Too Complicated for Me to Upgrade?

Of course, you can choose not to upgrade proactively, but there is a risk you need to be aware of. After the Prague upgrade, one of your message signatures may inadvertently put you in danger.

Indeed, EIP-7702 carries a significant phishing risk because its Authorization parameter is composed of address, nonce, and chainid. If the chainid is 0, the signature authorization can be effective on any chain as long as the nonce condition is met.

Through the OKX open-source Signature SDK, the specific implementation of the 7702 process can be seen. To comply with this standard, the final signed message by the user is a hash value: 0xabc. The calculation method is as follows:

Where keccak is the mainstream hashing algorithm on Ethereum, known for producing a fixed 32-byte length result for data of any length. RLP is a set of information encoding schemes, and the Magic within it is a fixed value.

However, since the end result is an incomprehensible hash value, if a user hastily signs a message and someone else can use your authorization to execute an on-chain action, it may unknowingly trigger a code injection vulnerability, leading to a 0-day level attack event. Furthermore, since setting code is mandatory, you cannot assume that a previously secure contract will not be replaced.

Hence, secure wallets typically prevent users from signing an arbitrary hash value, as this could potentially represent a malicious transaction.

How to Protect Yourself If You Accidentally Upgrade a Vulnerable Contract?

This risk is also quite common, as it's impossible to guarantee that you won't fall victim to phishing attacks. To mitigate this issue, it is important to understand a technical background: in the Ethereum system, transactions must follow a nonce order to be recognized by the blockchain. Therefore, there are two attack scenarios.

The first scenario is, if a hacker steals the nonce value of your next transaction and signs an authorization, the response is straightforward. If you have been attacked, promptly use a wallet that allows custom Gas fees, such as the OKX Wallet or another secure wallet, to swiftly transfer your ETH to another secure address. This action not only moves the ETH funds but also invalidates the nonce in the hacker's possession.

The second scenario is, if a hacker steals a future nonce value, your current transaction may inadvertently validate the hacker's authorization. Since you are unsure about the nonce, no action can guarantee absolute security. The best course of action is to transfer your assets as quickly as possible to protect yourself.

It seems that EIP-7702 is now even more dangerous, right? Not quite so!

For a blockchain like this, which truly puts user sovereignty back into a system where the user owns the private key, any reckless signing at any time will lead to a loss of funds. However, the key here is that, apart from the scenario where high-value users are specifically targeted for poisoning, most risks arise because users tend to frequently use important private keys.

If you have already implemented an Account Abstraction (AA) solution, combining household accounts and individual sub-accounts with predefined usage limits for each sub-account, then basically your master account only needs to be invoked when modifying system-level settings. For routine daily use, only small accounts are needed to transact.

Why did some common transactions fail after the upgrade?

This situation often occurs in wallet tools that do not support EIP-7702.

First, let's provide some technical background. During a contract call on Ethereum, it first checks the code field of the current user's address. If there is content present, it will execute the default fallback function to perform the corresponding logic. For us regular users, this means that if I have completed the EIP-7702 contract setup, and thus have a default fallback function, then any ordinary ETH Transfer transaction will execute some contract logic, thereby increasing the overall Gas use. If your regular transaction's Gas Limit is set to 21,000, the transaction will naturally fail.

Similarly, since many NFT projects check whether the recipient address is a black hole address (an address from which assets cannot be withdrawn) to prevent transactions, if your fallback function is improperly implemented, it will also prevent ERC20 and ERC721 assets from being received and result in a loss. To address this, it is recommended to configure your wallet using a wallet that explicitly supports EIP-7702 or to use logic contracts that have undergone rigorous security audits and user acceptance, such as: https://github.com/okx/wallet-core

What other changes are there on the Ethereum mainnet Pectra?

Many voices in the market seem to think that Ethereum has lost its way. Why do many upgrades not seem to impact users? Is this really the case? Let's take a look at the other EIPs in this upgrade to find the answer. Undoubtedly, EIP-7702 is the most significant upgrade change that users can experience, but there are 10 other EIPs that bring changes to the Ethereum ecosystem in different dimensions.

First is the cryptography support. Through EIP-2537, a precompile for the BLS12-381 elliptic curve has been introduced, optimizing complex cryptographic operations such as BLS signature verification to provide higher security (120+ bit security) and computational efficiency (Gas optimization).

There are multiple optimizations for the staking scenario. Objectively speaking, staking does need optimization. The Ethereum validator set has been growing rapidly, with nearly a million staking addresses. This is because the MAX_EFFECTIVE_BALANCE is limited to 32 ETH, and node operators need to create multiple validator accounts to manage larger staking assets, resulting in a large number of "redundant validators." Therefore, EIP-7251 has increased the maximum limit, which allows aggregation staking protocols like Lido to reduce the number of controlling accounts, decreasing system complexity. However, this may exacerbate centralization issues, making the ETH staking market more centralized.

After this upgrade, larger-scale node operators can merge multiple validator accounts, while also bringing more flexibility to small validators. For example, they can increase their earnings through compounding returns or more flexible staking increments. This is very important. After reaching 32 ETH, if you earn an additional 10 ETH, you wouldn't continue to stake it because you need to reach 32 ETH again to open a new account. However, with this update, you can now stake 42 ETH directly. This means your compounding returns can be reintegrated into the ETH system, providing user experience convenience and potentially posing a threat to ETH liquidity.

Lastly, there has been a significant optimization for the L2 ecosystem. Ethereum has always been steadfast in advancing the L2 ecosystem. Other systems like the SVM and MOVE series are essentially still developing their L1 and even exploring conflicts and contradictions in their L2 solutions. The root cause is that the high performance of these chains is not as reliant on L2 solutions.

To encourage more efficient L2 interactions with the Ethereum mainnet, EIP-7623 has increased the gas cost of calldata in transactions directly from 4/16 gas per byte to 10/40 gas per byte, pushing L2 solutions to avoid calldata and instead favor Blob usage.

Additionally, through EIP-7691, the block's blob capacity has been increased to support larger L2 storage. In the previous Cancun upgrade, there were two core blob parameters, target and max, used to indicate the target number of blobs per block and the maximum number of blobs per block.

Cancun is 3 and 6, and now after Prague, the parameters have become 6 and 9, in short, it has been scaled up.

Therefore, Ethereum achieves its own improvement through L2's TPS, although there are many issues involved, such as liquidity dispersion, cross-chain complexity, emergency escape capacity, and more. Therefore, in the current Pectra upgrade, Ethereum is adding a "highway" to L2, but how to solve the "traffic management" and "different high-speed toll standards" in the future is the most fundamental issue.

Glimpse of the Future

This verbose article is close to ten thousand words. We start from the development origin of account abstraction, to the two routes represented by ERC-4337 and EIP-7702, then delve into the principles and mechanisms of EIP-7702, analyzing its pros and cons and adjustment effects on mainstream user scenarios.

The author believes that "Not your keys, Not your money" is a great concept. EIP-7702 does not subvert it but complements and perfects it from another dimension, enabling it to have both sovereignty and usability. As Yoav Weiss, a researcher at the Ethereum Foundation, said, "The next billion users will not write 12 words on paper."

Then through a comparison of the two, it can be said that it has significantly optimized ERC-4337, giving users space and flexibility, making it easier to be recognized and used by users in the future market. Once users start adopting CA as the on-chain entity, complex transaction types will surge on EVM-based chains.

Thus, we catch a glimpse of the future shadow accompanied by the richness of underlying account entities and transaction types. Many application experience problems that were once bottlenecks will also be solved, no longer forcefully requiring users to understand logic such as Nonce, Gas, and so on, but instead providing simplified handling by wallet and other entry service tools.

Although facing industry-level diversity, bringing a certain degree of interface standards and storage space disorder, the author is also optimistic that the more valuable the chaos, the more likely a unified standard will emerge. The decentralized multi-party game will eventually promote industry development. Therefore, after the launch of EIP-7702, it will not immediately ignite the ecosystem on Ethereum because it is a spiral-up technological upgrade. Such upgrades often lead the market application by 2-3 years, leaving room for gradual fermentation at the application layer.

Furthermore, starting from this upgrade, user security will be more dependent on the service quality of the entry tools layer. Open source openness is an important step in providing users with a sense of security. Therefore, the EIP-7702 underlying SDK implementation integrated by OKX Wallet this time is also open source, openly accepting the test of the community and the market. Many wallets that maintain openness are progressing further on the road to self-custody, providing users with absolute autonomy through open and fair principles.

Finally, returning to the Pectra upgrade itself, we can once again see Ethereum's reflection on future direction and commitment. Now that the L2 grand strategy has entered a stable execution phase, Ethereum's roadmap has undergone many detailed changes in the past decade. However, the core goal has surprisingly remained consistent: to have a secure and decentralized green (POS) blockchain that is both highly scalable and easy to verify. Proposals such as EIP-7702, which effectively enhance user experience, introduced through hard forks, represent Ethereum's continuous exploration of how to maintain decentralization while enhancing competitiveness among multiple chains (even in the face of competition from strong new-generation blockchains such as Solana), and how to become the ideal supercomputer!

References:

1. https://github.com/okx/js-wallet-sdk

2. https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md

3. https://www.okx.com/en/learn/smart-account-standardization

4. https://mp.weixin.qq.com/s/WjpPNKEVlxlCSz1WyHH4tw

5. https://vitalik.eth.limo/general/2024/12/03/wallets.html

6. https://metamask.io/news/account-abstraction-past-present-future