Stealth Address AA Plugin is a smart account plugin built on top of modular smart account provider including ZeroDev Kernel and Biconomy.

💡 If you're well-versed in Account Abstraction and stealth addresses, please skip to Section III.

I. What is Account Abstraction (AA) Plugin​

a. Account Abstraction​

Account Abstraction (ERC-4337) changes how you interact with your crypto wallet. To better understand this, let's use a real-world analogy: think of your crypto wallet as your house, a secure place where you store all your digital assets.

In the pre-AA era, entering this 'house' to manage your assets required a singular, specific 'key'—your private key. You'd need this one and only key to both access your assets and perform transactions.

However, Account Abstraction significantly expands your options. Now, instead of relying solely on that traditional private key, you can also gain entry through various other means of identification like fingerprint scans, voice recognition, or any other form of proof that establishes your identity.

Beyond that, you can add custom rules and logic to your smart account. For instance, you could implement a daily transaction limit for added security, or automate a small contribution to the developers behind Account Abstraction each time you access your wallet, as a way to express gratitude for their groundbreaking work.

The wallet with account abstraction is called smart wallet or smart account compared to external owned account (EOA).

b. Modular Smart Contract Account and Plugin​

As smart accounts evolve, gaining new capabilities for enhanced security and user experience, the question arises: What if we want to adapt our smart accounts to different scenarios or upgrade them just like we update software on smartphones? The traditional method of asset migration between smart accounts designed for different use cases has been cumbersome, to say the least.

Enter ERC-6900: Modular Smart Contract Account and Plugin, which addresses these challenges head-on. Extending our 'house' analogy, with ERC-6900, you no longer have to build your digital house from scratch. You can now start with a robust foundational structure and customize it with your choice of 'furniture,' such as specific gates, modules, or plugins, to fit your unique needs.

Platforms like ZeroDev Kernel and Biconomy have already implemented this modular approach and make it remarkably straightforward to create these modular plugins or modules for your smart account.

For those interested in diving deeper into the realms of Account Abstraction and its modular extension, we recommend checking out our previous article Account Abstraction Lego. Additional comprehensive guides can be found here, here and here.

II. What is Stealth Address​

While the transparency of blockchain technology brings numerous benefits, it also has its downsides—particularly when it comes to privacy. For instance, if you're paying your employee's salary or buying a cup of coffee, the transactions are publicly visible. This means anyone can trace the addresses involved and discern financial details like salary amounts or a café's monthly earnings.

A workaround might be to create a new address each time you receive tokens. However, this strategy makes managing assets across multiple addresses a complicated and cumbersome task.

To address this privacy concern, the concept of stealth addresses was introduced for Bitcoin back in 2014, and has since been refined (improved, dual-key). It's now available for Ethereum as ERC-5564.

With a stealth address, you don't send tokens directly to the receiver's public address. Instead, a stealth address is generated using an ephemeral key combined with the receiver's public address. Only the sender and receiver are privy to who actually owns this stealth address. Furthermore, only the receiver has the ability to withdraw tokens sent to the stealth address, ensuring both privacy and security.

For those eager to delve into the finer details of stealth addresses, we highly recommend reading An incomplete guide to stealth addresses post by Vitalik, as well as this insightful post that provides an excellent introduction to the subject.

III. Why Stealth Address AA Plugin​

In this section, we will delve into the dual motivations behind our Stealth Address Account Abstraction (AA) Plugin, looking at it through the lenses of both Account Abstraction and stealth addresses:

1. Account Abstraction: privacy-preserving plugin
2. Stealth address: transition from EOA to smart contract account

a. Account Abstraction: privacy-preserving plugin​

We believe that privacy should be an inherent property of blockchain technology, not just an optional add-on.

While Account Abstraction (AA) has been instrumental in providing flexible verification logic beyond the traditional ECDSA signature, there remains the need to confirm your identity and prove ownership of the wallet. Whether it's a private key, an enclave-based key, or even biometric data, some form of identification is essential.

At MoonChute, we've created Unified Smart Account Managers that associates an individual's EOA address with their respective smart accounts. From the feedback we've gathered, this utility has been instrumental in simplifying the management of multiple smart accounts. However, we believe that users should also have the freedom to choose how much privacy they want to maintain.

To strike a balance between the utility of Account Abstraction and the need for privacy, stealth addresses serve as an ideal solution. They fulfill our aim of enhancing user privacy without sacrificing the flexibility and user experience that smart accounts offer.

b. Stealth address: transition from EOA to SCA​

If we are going to allow existing EOAs to upgrade to contract , why not make stealth address a contract account?

IV. How Stealth Address AA Plugin works​

a. ECDSA validator plugin​

Within the ZeroDev Kernel's ECDSA Validator, a user operation (userop) is validated based on whether the signature comes from the owner address specified in the validator contract. As the validator facilitates a seamless transition from to smart accounts, there's an opportunity to boost privacy. Specifically, we can break the direct link between the smart account and its owner.

struct ECDSAValidatorStorage {
    address owner;
}

function validateUserOp(UserOperation calldata _userOp, bytes32 _userOpHash, uint256)
        external
        payable
        override
        returns (ValidationData validationData)
    {
        address owner = ecdsaValidatorStorage[_userOp.sender].owner;
        bytes32 hash = ECDSA.toEthSignedMessageHash(_userOpHash);
        if (owner == ECDSA.recover(hash, _userOp.signature)) {
            return ValidationData.wrap(0);
        }
        if (owner != ECDSA.recover(_userOpHash, _userOp.signature)) {
            return SIG_VALIDATION_FAILED;
        }
    }

b. Stealth address​

For simplicity, let's focus on the basic version of stealth addresses. The objective here is for a sender to transfer tokens to a receiver in a way that masks the identity of the receiver, while also ensuring that only the receiver can access and spend the tokens.

First, the sender obtains the public key of the receiver and randomly generates an ephemeral key pair. The sender then publishes the ephemeral public key. Both parties can now compute a shared secret via the Diffie-Hellman key exchange, which is established between the receiver's public key and the ephemeral key, followed by hashing.

The stealth address is formulated by combining the receiver's public key and the public key of the shared secret. The corresponding stealth private key can only be calculated by the receiver, as it combines the shared secret and the receiver's private key.

c. Stealth address validator plugin​

The Stealth Address Validator Plugin are employed to mask the identity of smart account owners. This results in the decoupling of the visible link between smart account owners and their respective smart accounts, thereby ensuring a higher degree of privacy.

struct StealthValidatorStorage {
    address stealthAddress;
}

function validateUserOp(UserOperation calldata _userOp, bytes32 _userOpHash, uint256)
        external
        payable
        override
        returns (ValidationData validationData)
    {
        address stealthAddress = stealthValidatorStorage[_userOp.sender].stealthAddress;
        bytes32 hash = ECDSA.toEthSignedMessageHash(_userOpHash);
        if (stealthAddress == ECDSA.recover(hash, _userOp.signature)) {
            return ValidationData.wrap(0);
        }
        if (stealthAddress != ECDSA.recover(_userOpHash, _userOp.signature)) {
            return SIG_VALIDATION_FAILED;
        }
    }

d. Aggregate signature​

Stealth addresses offer an elegant solution to preserve user privacy. However, the practical limitations of generating shared secrets and corresponding private keys within existing wallet UIs present a challenge. To overcome this, we propose using aggregate signatures that can be verified by the contract.

1. Shared secret​

The shared secret, denoted by $s$, can be generated using the ephemeral public key and the user's private key, or vice versa:

$priv_{shared}=Hash(bR)=Hash(rB)$

In standard stealth address implementations, this usually requires manual management of private keys by users. However, ephemeral private keys could be stored when creating the smart account, simplifying shared secret retrieval within existing wallet UIs.

2. Private key of stealth address​

The private key of the stealth address, denoted as $priv_{stealth}$, is calculated as:

$priv_{stealth}=priv_{shared}+b$, where $s$ is the shared secret and $b$ is the private key of the owner.

The challenge we face is that we're unable to alter the private key within the wallet's user interface. Nevertheless, we do have the latitude to make subtle adjustments in the way signatures are generated and verified, which could provide us with a viable path forward.

Here's original ECDSA siging

ECDSA Signing​

Given a private key: $privKey$, and a message: $m$

1. Calculate the message hash: $h=hash(m)$
2. Generate a random number $k$
3. Calculate $R=k*G$ and take its x-coordinate $r=R.x$
4. Calculate $s=k^{-1}*(h+r*privKey)\mod n$
5. The signature is $(r,s)$

ECDSA Verifying​

1. Calculate the inverse of signature s: $s_1=s^{-1}\mod n$
2. Calculate $R'=(h*s_1)*G+(r*s_1)*pubkey$, and take its x-coordinate r'=R'.x
3. The result is $r==r'$

We propose an adjustment to the signing and verification steps to facilitate stealth address usage:

Aggregate ECDSA Signing​

Given private key of owner: $priv_{owner}$, shared secret key: $priv_{shared}$ and message: $m$

1. Perform step 1 - 4 as in ECDSA signing using $priv_{owner}$
2. Calculate the aggregate signature $s'=s(h+r*priv_{shared})\mod n$
3. The aggregate signature is $(r,s')$

Aggregate ECDSA Verifying​

The aggregated signature

We notice that:

We can thus verify the aggregate signature by:

1. Calculate the inverse of aggregate signature $s_1=s'^{-1}\mod n$
2. Calculate $R'$ and take its x-coordinate $r'=R'.x$$R'=(h^2*s_1)*G+(h*r*s_1)*pubkey_{stealth}+(r^2*s)*dh_{owner\_shared}$
3. The result is $r==r'$

V. Workflow​

In this section, we outline the complete workflow for creating a smart account with the Stealth Address Account Abstraction (AA) Plugin.

a. Create stealth smart account​

1. Generate Ephemeral Key Pair: Start by generating a random ephemeral key $r$
2. Compute Shared Secret: Use the random ephemeral private key $r$ and the owner's public key $B$ to compute the Diffie-Hellman shared secret, $s$, through hashing: $s=Hash(rB)$
3. Compute Stealth Public Key and Address: Calculate the stealth public key by adding the public keys of the owner and the shared secret: $pub_{stealth}=pub_{owner}+pub_{shared}$ Then calculate the stealth address: $addr_{stealth}=bytes20(keccak256(pub_{stealth})$
4. Compute Diffie-Hellman Key: Now calculate the Diffie-Hellman key between the owner and the shared secret: $dh_{owner\_shared}=pub_{owner}*s$
5. Call CreateAccount: Finally, call the createAccount function in the Smart Account Factory Contract.

Within the framework of our validator, we'll securely store the stealth address, stealth public key, and the Diffie-Hellman key. Importantly, to bolster user privacy, the owner's address will not be stored in the validator. This design ensures that there is no explicit connection between the smart account and its respective owner.

struct StealthAddressValidatorStorage {
    uint256 stealthPubkey;
    uint256 dhkey;
    address stealthAddress;
    uint8 stealthPubkeyPrefix;
    uint8 dhkeyPrefix;
}

b. Verify signature​

The signature in the userOp is constructed with the signature or aggregated signature generated by stealth smart account owner with the 1 Byte prefix mode.

Mode 0: ECDSA Verification If the mode is set to 0, the signature will be verified using standard ECDSA verification logic that matches the stealth address's private key. In other words, the signature is considered valid if it can be mathematically confirmed to have been generated by the stealth address's private key.

Mode 1: Aggregated Signature Verification If the mode is different from 0, the signature will undergo aggregated signature verification as detailed in the previously discussed procedure for Aggregate ECDSA Verifying.

VI. What's next​

ERC-5564 Compatibility and Stealth Address Scanning

While our stealth smart accounts are self-created, eliminating the need for separate viewing and spending keys used in standard stealth address implementations, our aim is to ensure compatibility with ERC-5564. This will enable senders to transfer tokens to recipients while maintaining the recipient's anonymity.

One of the issues widely discussed with stealth addresses is stealth address scanning overhead. It's worth exploring an efficient solution to minimize the cost in the realm of smart account.

Enhancing privacy through Account Abstraction Since the stealth smart accounts are essentially smart contract wallets, they offer a greater degree of flexibility. For example, we could use a paymaster to sponsor userOps in such a way that the link between the stealth smart account and its owner remains concealed.

1. Lego​

a. EOA wallet​

Executing an action on the blockchain can be likened to constructing a Lego structure. Let's illustrate this with the example of swapping USDC for ETH using Uniswap. Initially, you must identify the correct 'port' or function on the Uniswap 'Lego block.' This could be a 'swap,' 'createPool,' or 'mint' function. Simultaneously, you have another Lego block, your EOA (Externally Owned Account) wallet, which holds your USDC tokens.

Here's the catch: these two Lego blocks—your wallet and the targeted Uniswap function—don't have compatible ports. They can't snap together directly. To bridge this gap, you'll need a transaction, which acts as an adapter, linking the dApp (in this case, Uniswap) with your wallet's assets.

The final piece of the puzzle lies in securely connecting this transaction adapter to your wallet. Your wallet has a unique port designed to safeguard its assets. The keystone in this setup is the keypair held by you, the owner. This signature signed by the private key of keypair serves as the secure joint that connects your assets to the dApp, making the transaction valid and secure.

In an ideal 'Lego blockchain' world, one could freely replace any component with another. But that's not the case in reality. The only truly interchangeable component is the dApp module. You're free to choose which dApp to interact with—be it swapping tokens via Uniswap or purchasing an NFT on OpenSea. When it comes to wallets and keys, however, the only operable logic is signature verification, which corresponds to the ECDSA keypair.

b. Smart account wallet with account abstraction​

Account abstraction is revolutionizing the blockchain landscape by making it more flexible, adaptive, and efficient. By breaking away from the limitations of traditional Externally Owned Accounts (EOA), it offers diversified authentication methods, injects programmable logic into wallets, and streamlines complex transactions. Let's delve into these three transformative benefits.

The first hallmark of account abstraction is its significant departure from the rigid structures of traditional EOA wallets. Instead of being limited to standard private key-based authentication, the system now offers an array of verification methods. These range from the familiar private keys to device-based passkeys and beyond.

The second groundbreaking feature of account abstraction is the ability for wallets to harbor their own logic, similar to dApps. This opens up fascinating possibilities for user-driven asset management. For instance, you could program your wallet to incorporate specific conditions that must be met before validating a transaction. Imagine setting time-based restrictions that only allow high-value transactions during a certain period, or establishing spending limits when interacting with specific dApps.

Just as transactions were the adapter under EOA scheme, 'user operations' serve as the bridge in the world of account abstraction, facilitating intricate and batch transactions far more efficiently. This allows for much smoother and multifaceted interactions between different blockchain components, such as wallets, dApps, and other smart contracts.

c. Lego Builder​

The field of account abstraction is bustling with builders. In the realm of smart accounts, companies like ZeroDev, Biconomy, Safe, and Alchemy are laying the foundational blocks for modular smart accounts, especially with protocols like ERC-6900. When it comes to key management, 0xPass has developed the Passport protocol, while Clave simplifies key storage with secure enclaves, thus eliminating the need for seed phrases. Furthermore, Stackup and Pimlico are pioneering the 'bundler,' helping users craft and send user operations, as well as introducing paymasters to sponsor gas fees for users.

As we reflect on the transformative power of account abstraction—from its diversified authentication options to its advanced wallet logic and streamlined 'user operations'—it's crucial to acknowledge the builders who are turning these innovative concepts into reality. These are the "Lego Builders" of the account abstraction ecosystem. They're the architects behind the modular smart accounts, advanced key management solutions, and efficient infra that make all these benefits possible.

Building Blocks of Smart Accounts​

In the realm of smart accounts, organizations like ZeroDev, Biconomy, Safe, fun are serving as foundational architects. They're bringing to life the modular smart account frameworks. Alchemy, rhinestone and the preceding builders are leading the discussion of modular smart account standards like ERC-6900, which enables the kind of customization and flexibility discussed earlier.

Key Management Revolutionized​

When it comes to managing cryptographic keys, there's also a surge of innovation. 0xPass is advancing the field with their Passport protocol, providing users with more dynamic and secure ways to manage their identity. Clave is making strides by securely storing keys in secure enclaves, which can render the traditional seed phrases obsolete, thus making key management more user-friendly.

Infra​

Stackup and Pimlico are filling an important niche by focusing on bundlers and paymasters. They facilitate the crafting and sending of user operations, thereby acting as the grease that keeps the wheels of account abstraction turning smoothly. Paymasters, in particular, are introducing an innovative model to sponsor gas fees, making it easier for users to interact with the blockchain without worrying about the associated costs.

2. User experience transformed from user’s perspective

Building on the contributions of these Lego Builders, let's pivot to explore how these technological advances in account abstraction might shape the user experience. While the landscape is becoming increasingly flexible and user-centric, it's worth noting that these benefits come with their own sets of challenges.

Before the advent of account abstraction, entering the world of dApps required generating and securely storing a keypair—a cumbersome process that served as a significant barrier to entry for new users. The model was restrictive and offered no room for customization based on the user’s specific needs or the particular requirements of individual dApps.

Account abstraction changes the game by decoupling key modules from account modules. This separation enables the adoption of more intuitive proof systems, like biometric data, touch ID, face ID, or even social logins. With this new approach, dApps can welcome users without the intimidating requirement of keypair generation and memorization. Moreover, dynamic key and account modules empower users to tailor their interaction with dApps, like creating session keys for seamless in-game experiences or setting up multi-factor authentication for high-value NFT transfers.

With account abstraction, it’s likely that users will own multiple smart accounts with varying smart accounts plugin and key modules for different dApps. You might have a basic ECDSA key pair for your primary assets, secured in one smart account with multi-signature and another with multi-factor authentication. Alongside these, you could have additional smart accounts managed through easier-to-use passkey modules for daily spending or gaming.

However, this newfound flexibility isn't without its challenges. As users accumulate more smart accounts—each featuring unique implementations and plugins from a variety of builders like ZeroDev, Biconomy, and Safe-the management of these accounts becomes an increasingly complex affair.

Your key your crypto​

In traditional EOA wallets, choosing a wallet client was as simple as importing your private key. In contrast, smart wallet schemes present a far more intricate landscape. For example, consider you have a ZeroDev-enabled smart account for gaming, powered by your basic ECDSA private key and equipped with a session module. You might accrue in-game items that you'd like to sell for USDC. However, selling these assets becomes challenging not just because the game lacks an exchange, but also because each smart account comes with its own set of rules, making asset management far more complex than what we were accustomed to with EOAs.

Thus, while account abstraction enriches the blockchain experience with a layer of customization and user-friendliness, it also introduces an intricate web of modules that users must navigate.

In light of these complexities, ongoing discussions around standardizing smart accounts—especially through proposal like ERC-6900—are promising. This standardization aims to streamline the validation, execution, and integration of smart account plugins, thereby potentially simplifying their management. Yet, despite these advancements, navigating through a myriad of smart accounts and their associated plugins remains a considerable challenge for users. This points to an ongoing tension between customization and simplicity, a dynamic that will likely continue to evolve as the technology matures.

3. MoonChute: “Your key your smart account”

To mitigate the complexity that comes with account abstraction, MoonChute offers a unified smart account manager that embodies the principle of "your key, your smart account." MoonChute makes it easy for you to manage all smart accounts associated with your key in one place. Whether your smart accounts are created on different chains like Base or Polygon, or through various platform like ZeroDev with an ECDSAValidator plugin or Biconomy, MoonChute aims to make management seamless.

To delve deeper into the world of smart accounts and how they can revolutionize your blockchain experience, you're encouraged to Explore MoonChute's Unified Smart Account Manager. And if you're a developer—whether for wallets or dApps—MoonChute is soon to release an API tailored to your needs. So, don't hesitate to Get in Touch on Twitter for the latest updates.

Conclusion​

Account abstraction is like adding advanced, multi-functional Lego blocks that opens up unprecedented avenues for customization and user flexibility. While this new landscape is incredibly promising, it also introduces complexity that we must address through further development and standardization. Kudos to all the dedicated Lego builders—developers, innovators, and thought leaders—in the field of account abstraction; your work serves as the cornerstone of a new, more intricate.

If you want to dive deeper into the technical aspects of account abstraction, several thought leaders in the field offer rich insights:

• Alchemy: You Could Have Invented Account Abstraction (link)
• Biconomy: Decoding EntryPoint and UserOperation with ERC-4337 (link)
• Clave: Getting Wallets Ready for the Next One Billion Users: Account Abstraction (link)
• rhinestone: WTF is Modular Account Abstraction (link)

Make all humans incentive-aligned toward creating value to the world.​

1. Our Vision​

Our vision is Making all humans incentive-aligned toward creating value to the world.

Previously, we’ve delved into the intricate connection between productivity and asset. However, after months thinking an building in blockchain, we uncovered a groundbreaking realization: it’s not merely about leveraging assets to spur productivity, but also about employing a unique, incentive-aligned technique to engender a more prosperous, positive-sum world.

So, what’s our vision? We’re aiming to making all humans incentive-aligned toward creating value to the world. The advent of account abstraction offers us a perfect launchpad to commence building this brave new world.

2. Account Abstraction and why it is important​

Before we dive into the concept of account abstraction, it’s pivotal to revisit our understanding of assets. Assets hold three crucial characteristics — ownership, security, and interoperability. They should be possessed by their rightful owners, resistant to theft, and readily exchangeable with other assets. Picture this: it’s 500 AD and your hard-earned wealth from a successful harvest is securely locked in a sturdy box, hidden carefully. Yet, if a thief were to get a hold of the key, all would be lost. This conundrum is analogous to the state of assets in the blockchain ecosystem before the advent of account abstraction.

Account abstraction revolutionizes this landscape, turning the physical box into an abstract construct — an account. This transformation allows you to delineate how you interact with your assets, who can access them, and under what conditions. Just like your current financial portfolio, where you keep cash on hand, have a daily transaction limit for your bank account, have investments in stocks, a hefty safe with a dual-access password, and even a credit card for your children to spend responsibly.

Assets hold three crucial characteristics — ownership, security, and interoperability.

3. Roadmap toward the vision​

In line with our vision of realigning human incentives towards global value creation, we’ve charted a three-phase plan for the upcoming 10–20 years:

a. Build an interface between people and their asset account​

As more people start using account abstraction, features like not needing a seed phrase and making transactions without gas fees are becoming popular for the next wave of users. However, we believe that account abstraction isn’t merely a new wallet with social login.

Users will possess multiple accounts with specific asset constraints and validation methods. This necessitates an interface to manage and interact with the various accounts and corresponding decentralized applications (dApps), akin to how we navigate through apps installed on our phones.

b. Elevating incentives for collective creation and contribution towards a positive-sum world​

With the ability to manage and utilize their assets freely, creators can share their creations’ value with like-minded individuals.

For instance, builders could invite users to propose feature requests and reward valuable contributors with early access or discounts. Through this aligned incentive and value accrual method, value creation will transition from a top-down approach to a bottom-up, positive-sum process involving every participant.

c. Remove incentive for harmful behavior like violence​

While positive value creation is incentivized, negative behavior tends to follow suit.

In this phase, we aim to remove incentives for such behavior. With advancements in biometric identification and consciousness interpretation, we envision a future where asset transfers could only be executed via a ‘Proof of Will’. This ensures that assets can only be transferred willingly, rendering acts of force, such as robberies, pointless. Although this concept needs extensive research and discussion, it has the potential to significantly reduce crime in our society. 4. Laying the first brick

As the first step on our exciting path, we’re excited to share with you MoonChute 2FA Protection. In alignment with the first phase of our roadmap, MoonChute is more than just a security feature; it’s a pioneering attempt at building a bridge between people and their digital asset accounts.

MoonChute’s architecture encapsulates our commitment to strengthening the bond between users and their assets, thereby transforming the way people manage and interact with their digital possessions. By establishing a base for smoother and safer access to blockchain assets, MoonChute is poised to lead the way to our ultimate goal of creating a world where everyone can contribute and accrue value seamlessly.

5. We need your help​

Your help is invaluable in this transformative mission. Whether you’re a builder, investor, thinker, or advocate of decentralization, we invite you to join us. Share your insights, feedback, or any thoughts that might further our cause.

Follow us on Twitter to stay updated with our progress and share your thoughts directly with us — our DMs are always open! Your feedback and support will be instrumental in shaping our path forward, pushing the boundaries of what’s possible in the world of Web3. We’re excited to venture into this brave new world together.

If you would like to try 2FA protection for your asset, please refer to MoonChute.