Cregis Research Observation: New Issues Arising from Three Transformations of Ethereum

Author: 0xCregis

# Introduction

In June, Ethereum's founder Vitalik Buterin pointed out in his blog that Ethereum is currently facing some significant challenges and issues that need to be addressed to promote further development; otherwise, Ethereum will head towards failure. The three directions for transformation are: smart contract wallets, privacy protection, and Layer 2 scaling. After a successful transformation, Ethereum will see improvements in performance, user experience, and privacy protection.

Of course, these transformations will also bring new challenges. The issues and significance of smart contract (CA) wallets have been analyzed clearly in the previous content. Cregis Research has summarized the remaining issues and selected several key points closely related to everyone's daily experience, revisiting Vitalik's views from more than half a month ago.

# Why Must Ethereum Transform?

The main reasons Ethereum needs to transform stem from challenges in scalability, security, and privacy protection.

First, let's revisit the discussion from Cregis Research's last issue: Cregis Research: The Archaeology of Ethereum Account Structures and the Value of Account Abstraction, which mentioned that Ethereum, operating in a decentralized environment, still faces the biggest pain point: the linear environment cannot execute high-concurrency transactions and complex code compilation, which is the scalability challenge.

Due to Ethereum's current limited transaction processing capacity, transaction costs become very high when network traffic increases. This high transaction cost hinders Ethereum's adoption in the mainstream market; therefore, Ethereum needs to improve its processing capacity and reduce transaction costs through Layer 2 scaling, such as rollups.

Secondly, the security of wallets is also an important issue. EOA wallets (represented by various plugin wallets) that generate public-private key pairs solely through seed phrases are frequently hacked, from large-scale leaks of ARB airdrop addresses to Twitter KOLs lamenting that their wallets have been emptied by hackers. Personal users' demands for asset security are increasing, while they are unwilling to sacrifice user experience (enterprise users, for asset security, may choose fully self-custodied MPC solutions and are willing to sacrifice the convenience of on-chain interactions). This necessitates Ethereum to transform wallet security and promote industry security standards for smart contract wallets (such as EIP-4337), providing individual users with stronger security and convenience.

Finally, privacy protection is another key challenge. All transactions on Ethereum Layer 1 are public due to the binding of EOA and assets; whether ordinary individual users, whales, or enterprises, they may currently suffer from the distress of asset addresses being marked and tracked. Therefore, Ethereum needs to further improve to implement non-malicious privacy computing, ensuring that in the future, not only on-chain assets but also on-chain identities, credit systems, and other DID information can be protected; at the same time, it needs to ensure that when malicious events occur, there are mechanisms in place to ensure that wrongdoers cannot evade tracking and cash out smoothly.

# The Three Most Important Issues (Cregis Research Summary and Opinions)

How Do Users Manage Multiple Wallet Addresses?

Compared to Web 2.0, Web 3.0 still retains one advantage: users can create different application accounts using a single social characteristic (email, phone number, etc.). Although in the Web 3.0 world, addresses on public chains with the same consensus mechanism can be interchangeable (for example: BSC, ERC-20, TRC-20), with the advent of Layer 2 scaling solutions, users will have multiple completely different Layer 2 addresses. Different Layer 1 and Layer 2 networks may use different programming languages and intermediate components, leading to issues with address retention. Moreover, before the multi-chain bridging environment represented by Polkadot or the multi-chain universal Layer 2 environment mentioned in Cregis's future vision is realized, users may also need to manage several heterogeneous chain addresses, increasing the complexity of address management.

Finally, if the proposal for invisible addresses in privacy protection is widely adopted, it will give users more addresses to enhance their privacy protection. Therefore, retaining a single address becomes more challenging.

How Can Users Achieve Invisible Payments? (Especially in a Multi-Address Environment)

Assuming that Layer 2 in the Ethereum ecosystem develops as expected in the future, even if most native assets are ERC-20 tokens, users may have multiple Layer 2 addresses, making it more complex to choose the correct address to send assets or make payments. Traditionally, users only needed to know the other party's address to send payment, but now they need to know the Layer 2 network accepted by the other party and the corresponding address, requiring additional steps to ensure that funds are sent to the correct target.

Invisible payment issues in a multi-account Layer 2 environment

While contract accounts (CAs) built using smart contracts can easily solve addressing issues, they cannot directly provide privacy protection functionality.

Vitalik proposed a privacy protection solution in the early days of Ethereum: invisible addresses. Invisible addresses can help you maintain privacy during cryptocurrency transactions without being tracked by others. Next, Cregis will share some steps to address privacy issues:

(Complete workflow of invisible addresses)

Invisible addresses are addresses that can be generated by either the payer or the payee but can only be controlled by the payee. This type of address can enhance Ethereum's privacy in various scenarios. In this model, Bob (the payee) generates a consumption key and uses this key to generate an invisible meta-address: B, h = hash(x). He passes this meta-address to Alice (the payer). Alice can perform a computation on this meta-address to generate an invisible address from Alice to Bob: b-1. Then, she can send any assets she wants to this address, and Bob will have complete control over them.

The generation process of invisible addresses requires operating elliptic curve functions: Bob generates a key m and calculates M = G * m, where G is a publicly known generator point of the elliptic curve. Alice generates a temporary key r and publishes a temporary public key R = G * r. Alice can calculate a shared secret S = M * r, and Bob can also calculate the same shared secret S = m * R.

After Bob's invisible address b-1 is generated, when he needs to transact with Alice, Alice generates a value c and publishes encrypted data of c that only Bob can decrypt; during the transaction execution, zero-knowledge proofs are used to verify: the value x provided by Bob and the value c provided by Alice can make k=hash(hash(x), c). Once verified, the transaction is completed. In this process, Bob's original address is not exposed; only the encrypted value x is provided, and the zero-knowledge proof is only responsible for verifying the content of k, without revealing the association between B and b-1.

How Can Wallet Products Protect Users' Assets and Privacy Simultaneously?

In traditional on-chain environments, wallets mainly focus on protecting private keys, but in the ZKP (zero-knowledge proof) world, wallets need to protect both authentication credentials and user data. One example is the identity system ZKpass based on ZK-SNARK and MPC, which allows users to generate basic proofs of authentication while ensuring that the process of verifying identity does not require revealing any real information through MPC.

However, since the encrypted data labels (key shares) themselves replace the EOA's private key, the issue of storing encrypted data labels becomes more complex, as users need to weigh between storing data locally or relying on third parties to hold encrypted copies. Additionally, wallets that support social recovery need to manage asset recovery and encrypted key recovery to ensure a balance between security and usability. Therefore, in the foreseeable future, the security strategies of enterprise-level wallets and personal wallets will diverge significantly. For enterprise-level wallets, due to the need for the most stringent security environment to protect funds, enterprise wallet users are likely to abandon: 1. contract wallets that may have human vulnerabilities; 2. hybrid custodial MPC wallets with third-party risks, opting for privatized deployment of MPC wallets with security levels equivalent to hardware wallets. In contrast, personal users, in scenarios beyond asset custody, may always seek the best user experience and might choose products with some degree of centralized operation.

Moreover, blockchain addresses indeed cannot meet the identity verification needs in the ecosystem, so solutions like ENS (Ethereum Name Service) and SBT (Soulbound Tokens) are gradually being accepted by the public. However, there are still unresolved issues: the former struggles to address the problem of name collisions brought by the traditional world, while the latter, although it does not have name collision issues, lacks sufficient ecological applications to fully realize its DID functionality, and the current application scenarios can be said to be quite thin.

The original text has a lot more content; if you are interested, you can visit: 《The Three Transitions》，Author: Vitalik Buterin.

# Conclusion

I believe everyone understands that in the topic of "Ethereum Transformation," which has stirred the global crypto community for nearly three months, wallets are just one important component. Vitalik's ambition is not only to achieve the goal of "Ethereum completing Bitcoin's deficiencies" but also to create a world where everyone can enter, highly integrated with the real world, while retaining the concept of decentralization.

Cregis Research is not only an observer but also one of the participants in this transformation. Since 2016, Cregis has been providing crypto-native enterprise-level payment solutions for Web 3.0 companies and startup teams, similar to how Alipay, PayPal, and other payment services provide for traditional enterprises and e-commerce organizations. At the same time, Cregis also offers internal fund management and approval flow tools, allowing Web 3.0 companies and startup teams to experience unique comprehensive services.