FHE-DKSAP with Abstract Accounting

1. Background

In our previous work, we introduced the FHE-DKSAP protocol. This system safeguards the association between a blockchain transaction and the recipient's wallet address, ensuring a heightened level of security. Notably, it offers quantum computing resistance, eliminates key leakage concerns, and enhances efficiency by allowing the reuse of certain public keys. A detailed explanation of the scheme is available in our earlier blog post FHE-DKSAP.

However, this scheme is still based on the current regular accounts (EOA) wallets. The EOA is controlled by a private key and can directly send transactions and receive ETH tokens, which is the type of account most familiar to ordinary users. Apart from this EOA address, there is contract accounts (i.e., CA, which stands for Contract Account). Contract accounts are controlled by smart contract codes and do not have a private key. Vitalik foresees a future where users transition from the conventional EOA wallets to those based on smart contracts. If this vision materializes, managing crypto wallets could become as straightforward as handling email accounts.

Ethereum account abstraction, also called abstract account (AA, Abstract Account), abstracts regular accounts and contract accounts, allowing them to be seen as the same type of account. In this proposal, we aim to integrate the FHE-DPSAK with AA. This integration offers three significant benefits:

• While Account Abstraction (AA) necessitates the verification of a user's identity and the proof of wallet ownership, the integration with the stealth address protocol can effectively conceal the identities of smart account holders of the recipient.
• The usability of the FHE-DKASAP account is enhanced, making this privacy-preserving scheme more versatile within blockchain technology.
• The SA in AA blog introduced the implementation SA in AA, but in a self-created way. We will extend it to compatibility with ERC-5564.

2. Solution:

2.1 DKSAP in AA

2.2 FHE-DKSAP in AA

2.3 Stealth Smart Account

Here, we provide the structure of the stealth smart account of Bob (recipient):

struct StealthAddress {
    uint256 stealthPubkey;
    uint256 stealthPrikey;
    address stealthAddress;
    uint8 stealthPubkeyPrefix;
    uint8  stealthPrikeyPrefix;
}

Following is the structure of the stealth smart account of Alice (sender):

struct StealthAddress {
    uint256 stealthPubkey;
    address stealthAddress;
    uint8 stealthPubkeyPrefix;
}

As observed, the system only retains the stealth address, stealth public key, and the secret key associated with the stealth address. Notably, the user's private key and the EOA address are not displayed. While Alice is the transaction's sender, she doesn't need to open the wallet. As a result, the stealth address private key isn't displayed.

Notebably, AA operates on the traditional ECDSA signature. As highlighted in the Sa in AA , there are practical limitations to SA in generating shared secrets and the associated private keys within the current wallet user interfaces. To address this, a proposition has been made to use aggregate signatures, which the contract can verify. Our method similarly leverages this approach to verify the signature by the contract. We are not to repeat the same scheme here.

3. Conclusion

In summary, the integration of FHE-DKSAP with Account Abstraction represents a significant advancement in the realm of blockchain security and privacy. The FHE-DKSAP's capability to obfuscate user identities, combined with the foundational principles of Account Abstraction, offers a robust solution to the prevailing challenges of stealth address implementation. This synergy not only heightens the security and privacy of transactions but also enhances the versatility and usability of accounts in blockchain technology. As the blockchain landscape continues to evolve, the adoption of such innovative combinations will be pivotal in ensuring user trust and the broader acceptance of decentralized platforms.