I. Introduction Ethereum, as an open and programmable blockchain platform, serves not only as the foundational infrastructure for digital currencies but also provides developers with an environment to build decentralized applications (DApps) and smart contracts. Due to its flexibility and scalability, Ethereum has become a key player in the cryptocurrency ecosystem, attracting developers and users worldwide.
In the previous edition of Cregis Research, we explored the value of Account Abstraction (AA), which led us to a more complex topic: In June, Ethereum’s founder, Vitalik Buterin (commonly known as V God), pointed out in his blog that Ethereum currently faces some significant challenges and issues. These issues need to be resolved for the further development of Ethereum; otherwise, it could lead to its failure. The three key areas for transformation are: smart contract wallets, privacy protection, and Layer 2 scaling. After successful transformations, Ethereum is expected to improve in performance, user experience, and privacy protection.
Of course, these changes will bring new challenges as well. Concerning the issues and significance of smart contract (CA) wallets, our last edition provided a rather clear analysis. Cregis Research has summarized the remaining issues and selected a few key points closely related to our daily experience to revisit Vitalik’s perspectives from over half a month ago.
II. Why Must Ethereum Transform? The primary reasons for Ethereum’s need for transformation stem from challenges in scalability, security, and privacy protection.
Firstly, let’s revisit the discussion from the previous edition of Cregis Research: “Ethereum Account Construction Archaeology and the Value of Account Abstraction.” It mentioned that Ethereum, operating in a decentralized environment, still faces its biggest pain point: the inability to execute high-concurrency transactions and complex code compilations in a linear environment—essentially, the challenge of scalability.
Due to Ethereum’s current limited transaction processing capacity, transaction costs skyrocket when network traffic increases. These high transaction fees hinder Ethereum’s mass adoption in the mainstream market. Therefore, Ethereum needs to improve its capabilities and lower transaction costs through Layer 2 scaling solutions like rollups.
Secondly, wallet security is also a significant issue. The risks of theft with Externally Owned Account (EOA) wallets, generated simply through seed phrases (represented by various plugin wallets), are increasing. From massive leaks of ARB airdrop addresses to Twitter influencers lamenting their wallets being drained by hackers, individual users are becoming increasingly concerned about asset security. At the same time, they are not willing to sacrifice user experience. Corporate users opt for fully self-custodial Multi-Party Computation (MPC) solutions for asset security, even if it means sacrificing on-chain interaction convenience. Ethereum needs to undergo a transformation in wallet security by promoting industry security standards for smart contract wallets (such as EIP-4337) to provide stronger security and convenience for individual users.
Lastly, privacy protection is another key challenge. All transactions on Ethereum’s Layer 1 are public due to the binding of EOA and assets; whether it’s individual users, whales, or corporate entities, all currently may suffer from the discomfort of having their asset addresses tagged and tracked. Therefore, Ethereum needs further improvements to implement non-malicious private computations, ensuring not just the privacy of on-chain assets but also on-chain identity, credit systems, and other DID information. At the same time, there must be mechanisms in place to ensure that malicious actors cannot evade detection and successfully cash out when malevolent events occur.
III: The Top 3 Questions (Summary and Insights by Cregis Research) How Do Users Manage Multiple Wallet Addresses?
Compared to Web 2.0, Web 3.0 loses out on one key advantage: the ability for users to create various application accounts with a single social identifier, such as email or phone numbers. While in the Web 3.0 ecosystem, public chain addresses with the same consensus mechanisms can be interchanged (e.g., BSC, ERC-20, TRC-20), the advent of Layer 2 (L2) scaling solutions means that users will have multiple, entirely different L2 addresses. Moreover, different Layer 1 and Layer 2 networks might employ varying programming languages and middleware, leading to issues in address retention.
Additionally, in multi-chain bridging environments typified by Polkadot, or the universal Layer 2 environments mentioned in Cregis’ future vision, users may have to manage several heterogeneous chain addresses. This increases the complexity of address management.
Finally, proposals for stealth addresses to enhance privacy, if widely adopted, will cause users to have even more addresses, making the task of keeping track of a single address much more challenging.
How Do Users Implement Stealth Payments? (Especially in a Multi-Address Environment)
Assuming that the Layer 2 (L2) solutions in the Ethereum ecosystem evolve as expected, users may find themselves with multiple L2 addresses, even though the majority of native assets are ERC-20 tokens. This makes choosing the correct address for asset transfers or payments more complex than before. Traditionally, all a user needed to know was the other party’s address to send payments. Now, they must also be aware of the specific Layer 2 network that the recipient is using and the corresponding address. This adds extra steps to ensure that funds are sent to the correct destination.
Although Contract Accounts (CAs) built using smart contracts can easily solve the issue of address management, they cannot inherently provide privacy features.
Vitalik Buterin, commonly referred to as “V God,” proposed a privacy solution in the early days of Ethereum known as “stealth addresses.” Stealth addresses can help you maintain privacy during digital currency transactions, preventing others from tracking your activities. Cregis will share some steps to address this privacy concern next:
Stealth addresses are a type of address that can be generated by either the payer or the payee but can only be controlled by the payee. This enhances Ethereum’s privacy in various use-cases. In this model, Bob (the payee) generates a spend key and utilizes it to generate a stealth root address: ( B, h = text{hash}(x) ). He passes this root address to Alice (the payer). Alice can then perform a calculation on this root address to generate a stealth address unique to Alice-to-Bob transactions, ( b-1 ). She can then send any assets she wishes to this address, over which Bob will have complete control.
To generate stealth addresses, elliptic curve operations are used: Bob creates a key ( m ) and calculates ( M = G times m ), where ( G ) is a publicly known base point of the elliptic curve. Alice generates a temporary key ( r ) and publishes the temporary public key ( R = G times r ). Both can calculate a shared secret ( S ), where Alice computes ( S = M times r ) and Bob computes ( S = m times R ).
After generating Bob’s stealth address ( b-1 ), to transact with Alice, she generates a value ( c ) and publishes an encrypted form of ( c ) that only Bob can decrypt. During transaction execution, zero-knowledge proofs are used to verify that the values ( x ) provided by Bob and ( c ) provided by Alice result in ( k = text{hash}(text{hash}(x), c) ). The transaction is finalized when the verification is successful. In this process, Bob’s original address remains concealed. Only encrypted value ( x ) is provided, and the zero-knowledge proof solely verifies the content of ( k ), without revealing the correlation between ( B ) and ( b-1 ).
How can wallet products protect both users’ assets and privacy?
In traditional blockchain environments, wallets mainly focus on protecting private keys. However, in a ZKP (Zero-Knowledge Proof) world, wallets must protect both authentication credentials and user data. An example is ZKpass, based on ZK-SNARKs and MPC (Multi-Party Computation), which allows users to generate basic proofs for identity authentication while keeping the verification process anonymous through MPC.
However, with cryptographic data labels (key shards) replacing EOA (Externally Owned Account) private keys, the issue of secure storage becomes complex. Users must decide between local data storage and relying on third-party encrypted backups. Furthermore, wallets supporting social recovery need to manage both asset recovery and encrypted key recovery to ensure a balance between security and usability. In the foreseeable future, the security strategies for enterprise wallets and individual wallets will diverge. For example, enterprise wallets may forgo smart contract wallets with potential human errors and hybrid custodial MPC wallets with third-party risks, opting instead for private deployment of MPC wallets with the same level of security as hardware wallets. Individual users, prioritizing user experience, may choose products with some level of centralized operations.
Additionally, blockchain addresses alone cannot meet the ecosystem’s identity verification needs. Therefore, ENS (Ethereum Name Service) and SBT (Soul-Binding Token) solutions are gradually gaining acceptance. However, challenges remain: the former struggles with duplicative naming issues inherited from the traditional world, while the latter, although free from duplication issues, lacks a robust ecosystem to fully leverage its DID (Decentralized Identity) functionalities, with the current applications being somewhat limited.
IV. Conclusion Hopefully, it’s clear to everyone that in the topic of “Ethereum’s Transformation,” which has kept the global crypto community buzzing for nearly 3 months, wallets are just one important component. Vitalik Buterin’s ambition goes beyond merely “fixing Bitcoin’s shortcomings through Ethereum.” He also hopes to make Ethereum a realm that is accessible to everyone, highly aligned with the real world, and retains the principles of decentralization.
