Motivation

Our Contributions

• A recoverable account abstraction solution. We propose an account abstraction wallet architecture to remove a single private key concern, therefore eliminating the risk of permanent asset loss. Furthermore, we present a zero-knowledge recovery solution based on guardians to hide guardian addresses on-chain.
• Implementation and Evaluation. We deploy a web application, a smart contract system, and a simple bundler to test and validate the proposed account abstraction architecture.

Thesis Organization

• Chapter 2 introduces relevant concepts, including blockchain fundamentals, account system in blockchain, the smart contract, and zero-knowledge proofs.
• Chapter 3 discusses the challenges of the current blockchain account model and the need for account abstraction. It also provides an overview of account abstraction mechanisms based on ERC-4337. The chapter also provides knowledge about privacy in account abstraction, including implementations of privacy in account abstraction and several its limitations.
• Chapter 4 describes the proposed system architecture. The chapter focuses on the integration of the recovery method with zero-knowledge proofs to verify and change ownership without revealing guardian identities.
• Chapter 5 This chapter discusses the implementation environment, including the technologies used for deployment, metadata management, and system configuration. It also presents several comparisons between existing recovery wallet solutions and the wallet proposed in this thesis, highlighting key differences in architecture and recovery mechanisms. Furthermore, the chapter evaluates the performance of the proposed approach by measuring proof generation time, verification time, and on-chain gas costs.
• Chapter 6 presents the research results and suggests directions for future work. The chapter summarizes the proposed solution and its contributions to addressing the identified challenges. It also outlines potential improvements and promising areas for further development.

Blockchain

• Decentralization: Data is replicated across nodes, eliminating single points of failure and central control.
• Immutability: Once recorded, data cannot be altered without network consensus, ensuring tamper resistance.
• Security: Cryptographic mechanisms protect against unauthorized access.
• Transparency: Public blockchains allow open access to transaction data, fostering trust.

Blockchain structure

UTXO model

Account system in blockchain

Structure of Externally owned account

• Address: A 20-byte identifier derived from the public key using the Keccak-256 hash function. This is the user's identity on the blockchain, used for sending and receiving assets or interacting with smart contracts.
• Nonce: A transaction counter to prevent replay attacks by ensuring each transaction is unique.
• Balance: The amount of cryptocurrency held by the account. The balance is maintained by the ledger, and the EOA does not physically hold these tokens.

Structure of Contract account

• Address: A 20-byte identifier, generated when the contract is deployed, typically derived from the creator's address and their nonce (number of transactions sent from that address).
• Balance: The cryptocurrency held by the contract.
• Code: The compiled bytecode of the smart contract, executed by the Ethereum Virtual Machine (EVM).
• Storage: Persistent data stored on the blockchain, such as user balances or contract states, organized as a key-value mapping.
• Nonce: Tracks the number of contracts created by the account (if applicable).

Smart contract

• Code: The smart contract's bytecode, written in languages like Solidity, compiled into EVM. The code defines the contract’s logic, such as executing a token swap or updating a voting record.
• Storage: Persistent data stored on the blockchain as a key-value mapping, retaining state information. Storage is costly due to gas fees, incentivizing efficient design.
• Balance: The cryptocurrency held by the contract

Structure of Smart contract

• Custom verification: Smart contracts can replace the standard EOA verification mechanism with custom verification logic. For example, smart contract wallets can use multi-signature or biometric authentication to reduce key loss risks.
• Social recovery: Smart contract wallets can enable social recovery. Fundamentally, users can designate trusted guardians (friends, devices, or entities) to recover accounts.
• Zero-knowledge proofs integration: Smart contract allows the implementation of ZKP to enhance privacy for the system.

Zero-knowledge Proof

• Completeness: An honest verifier will always be convinced by an honest prover if the statement is true.
• Soundness: If the statement is incorrect, a dishonest prover cannot convince the verifier except with negligible probability.
• Zero-Knowledge: The proof reveals no additional information beyond the fact that the statement is true. Even a cheating verifier learns nothing extra.

The interaction between prover and verifier in an interactive zero-knowledge proof protocol

• The prover sends a message as a commitment to the verifier.
• The verifier returns a challenge and asks the prover to answer it.
• The prover calculates the answer and sends it back to the verifier.

The interaction between prover and verifier in a non-interactive zero-knowledge proof protocol

• The prover inputs the secret witness into an algorithm.
• The algorithm generates a proof.
• The proof is sent to the verifier, who checks its validity using the CRS.

• Private Transactions: ZKPs can enable validation without exposing sensitive transaction data. For example, Zcash uses ZKPs to create shielded transactions. These transactions hide the participants and amounts involved while ensuring the network can verify that no double-spending occurs.
• Scalability Solutions: ZKPs compress transaction data off-chain, and then the off-chain computations are verified on-chain with minimal data. This approach reduces the volume of data stored on the blockchain while maintaining trustworthiness and security.
• Identity Verification: Users prove credentials without revealing personal data. For example, a user can prove they are above a certain age without revealing their exact birthday.
• Guardian-Based Authentication: Users can be authenticated by a group of guardians without revealing guardian identities, enhancing security in decentralized networks.

• Succinctness: The proof is short and can be efficiently stored on-chain and quickly verified by network nodes.
• Argument of knowledge: the prover possesses a valid witness that satisfies the given statement.

• Arithmetic Circuit Representation: Initially, the computation to be proven is transformed into an arithmetic circuit composed of addition and multiplication gates over a finite field. Each gate represents a basic arithmetic constraint, and the overall circuit defines the computational statement.
• Rank-1 Constraint System (R1CS): The circuit is then converted into an R1CS. This structured form enables a systematic translation into algebraic proofs.
• Quadratic Arithmetic Programs (QAPs): The R1CS is compiled into a QAP. The central idea is that if a prover knows an assignment that satisfies the R1CS, they can construct polynomials that meet specific divisibility conditions.
• Trusted Setup: A one-time, trusted setup process generates a common reference string (CRS) consisting of public parameters required for proof generation and verification. The security of zk-SNARKs depends on the secrecy of certain components generated during this setup.
• Proof Generation and Verification: Using the CRS, the prover generates a valid proof, and the verifier can check the proof's validity quickly without learning anything about the input itself.

• Trusted setup dependency: The dependency on a trusted setup can cause a potential centralization point and security risk if the setup process is incorrectly conducted.
• Strong cryptographic assumptions: zk-SNARKs depend on complex mathematical structures like elliptic curve pairings and specific non-standard assumptions, making them more complex to implement compared to proof systems relying purely on classical assumptions.

Challenges in the Current Blockchain Account Model

Key management risk

EOAs are secured and controlled through a cryptographic key pair. This key pair enables secure communication, authentication, and transaction signing. The public-private key system is based on asymmetric cryptography, which ensures that only the private key owner can control the account, while others can independently verify ownership using the corresponding public key.

• Transaction signing: When sending a transaction, the private key generates a digital signature. This signature verifies account ownership and authorizes the transaction without exposing the private key.
• Account control: The private key is the only way to access and manage an account. If lost, the account and its associated assets become permanently inaccessible.

The public key is derived from the private key using elliptic curve cryptography. It is primarily used for the verification of digital signatures. A public key is typically 64 bytes long, consisting of two 32 byte integers that represent the $x$ and $y$ coordinates on the elliptic curve.

EOAs rely on a single private key for access and transaction authorization. This dependence causes a major risk: if the private key is lost, forgotten, or compromised, the user permanently loses access to the account and all associated assets.

Bitcoin supply (in million Bitcoin [])

As illustrated in Figure , an estimated 20% of all Bitcoin, approximately 3.84 million BTC, has been lost. This estimate is based on blockchain analysis of addresses where funds have remained inactive for seven years or more. One of the primary causes of the loss is the loss of private keys, including forgotten passwords, misplaced backups, and unrecoverable seed phrases.

Security vulnerabilities

However, despite the cryptographic security of key pairs, EOAs remain vulnerable to various attack vectors, primarily stemming from private key and seed phrase compromises. Notable incidents include:

• Ronin Network Hack (2022): This attack exploited vulnerabilities in the private key management of the Ronin Network, leading to the theft of over $600 million worth of assets. The breach was a result of a compromised validator node that managed the private keys for the network.
• Poloniex Private Key Compromise (November 10, 2023): A major security breach resulted in approximately $130 million in cryptocurrency losses across multiple assets, including Ethereum, TRON, and Bitcoin. The attackers gained access to private keys, enabling unauthorized fund transfers.
• Mixin Network Database Attack (September 23, 2023): The largest crypto security breach of 2023, this attack led to estimated losses of $200 million. Attackers exploited vulnerabilities in Mixin's cloud infrastructure, obtaining private keys associated with deposit and hot wallet addresses.
• Cryptocurrency Phishing Scams (ongoing): Phishing scams, where users are tricked into revealing their private keys or seed phrases, remain a prevalent threat. Attackers often use fake websites or emails that mimic legitimate services, leading to theft of funds.

Incident count and number of attacks in 2023

As illustrated Figure , private key compromises were the most costly attack vector, resulting in total losses of $880,892,924 across just 47 incidents. This accounted for nearly half of all financial losses in the crypto space in 2023. These incidents highlight the critical need for enhanced security measures, such as multi-signature wallets, hardware security modules, and account abstraction solutions, to mitigate the risks associated with EOAs.

Need for Account Abstraction

Structure of Account abstraction

Execute transaction by EOA

Multicall by account abstraction

• UserOperation: A signed data structure that represents an abstracted user transaction.
• Bundler: An off-chain node or actor that packages user operations and submits them to the blockchain.
• EntryPoint contract: A smart contract that verifies and executes user operations.
• Paymaster: A contract that sponsors gas fees or handles alternative payment mechanisms.

ERC-4337

• ERC-20: A standard interface for fungible tokens, widely used in DeFi applications.
• ERC-721: The standard for non-fungible tokens (NFTs), enabling unique digital asset representation.
• ERC-1155: A multi-token standard supporting both fungible and non-fungible assets in a single contract.

The architecture of ERC-4337

ERC-4337 smart contract system

interface IEntryPoint {
  function handleOps(
    UserOperation[] calldata ops, 
    address payable beneficiary
  ) external;

  function handleAggregatedOps(
    UserOpsPerAggregator[] calldata opsPerAggregator,
    address payable beneficiary
  ) external;

  function simulateValidation(
    UserOperation calldata userOp
  ) external;
}

Privacy in Account Abstraction

• Privacy-preserving transaction: In a traditional blockchain system, transaction details, including sender and receiver addresses, transferred amounts, and associated metadata, are public. It can compromise user privacy, exposing sensitive information. Using smart contracts and ZKPs, account abstraction can prove the validity of transactions without revealing transaction details.
• Private authentication: Fundamentally, the purpose of private authentication is to prove that a user is authorized without revealing which member of a group they are. For example, in a smart contract recovery with guardians, guardians' identities are typically stored on-chain, so they are public. It can disclose sensitive information about participants, cause privacy problems. To reduce this problem, account abstraction allows for the implementation of ZKP to prove that the guardian is eligible without knowing any guardian's identity.
• Anonymous voting: Account abstraction with ZKPs can support governance functions such as voting in decentralized autonomous organizations (DAOs). For example, users can preserve the privacy of their choices while ensuring that each vote is valid and unique.
• Payment system: Account abstraction with ZKPs can implement a payment system that verifies transactions without compromising privacy. It is useful in peer-to-peer payment systems, where privacy is important.
• Digital identity: Account abstraction with ZKPs enables users to prove their identity without revealing real information. For example, if a user wants to prove that the balance is enough but does not publish the real balance, the user can use ZKP to shield the real balance, preventing the leak of the balance information.

• On-chain verification cost: ZKPs are strongly based on complex mathematical operations, such as elliptic curve, polynomial, so that the verification process demands significant computational resources, which increases fees when executed on Ethereum or other EVM blockchains.
• Proof size and latency: Some ZKP protocols require a large proof for verification. A large proof can increase bandwidth and latency during transmission and verification.
• User experience and accessibility: Privacy-preserving account abstraction requires users to interact with advanced cryptographic tools such as ZK compilers, proof generators, which are often difficult to understand. Moreover, the risk of losing a ZK-based identity or failing to generate a valid proof may lead to transaction failure or loss of account access.
• Trusted setup: Some ZK schemes require a setup phase to generate public parameters. If this process is compromised, the privacy and soundness of the entire system may be at risk.

• We process the evaluation and selection of efficient methods to interact with the ZKP environment. An evaluation was conducted to identify and select suitable methods that minimize proof size, gas consumption, and verification latency. This assessment is based on the following criteria: proof size, gas cost, verification time.
• To improve the accessibility and user experience of privacy-preserving features, a complete interface was developed to facilitate the generation and verification of guardian proofs. This interface abstracts the underlying cryptographic complexity and allows users to:
  • Generate valid ZK proofs without interacting directly with low-level tools or libraries.
  • Verify guardian authorizations securely and privately.
  • Simplify the recovery process in smart wallets while preserving the anonymity of the guardian set.

Architectural Overview

Overview architecture of the proposed system

Guardian-based Account Abstraction Recovery Mechanism

• setup process: This process initializes the guardian configuration parameters.
• updating process: This process updates the guardian configuration parameters after setting up.
• change ownership process: this process supports the owner can change ownership.

Updating process

The updating process

Once the guardian parameters are configured, owners can change them. Similar to the initial setup phase, only the owner can execute these changes. However, transactions can be executed after a time delay. This delay gives the account owner an opportunity to detect and respond to any malicious activities before the transaction is executed. The updating process consists of two phases: queuing and execution ( including aborting), as illustrated in Figure .

Queuing is the process of packing the owner's transaction data into an OwnerTransaction (details in Table ). Queuing process assigns executedType value as 0, and pushes it to a list of OwnerTransactions. The variable eta of each OwnerTransaction defines the nearest time in the future when the owner can execute their transaction. It must be greater than or equal to the current time plus the delay defined in the setup process.

Variable	Type	Description
value	uint256	Value of token sent with a transaction.
data	bytes	Transaction's callData.
eta	uint256	The closest time the owner can execute his transaction.
executedType	uint8	Executed transaction status. 0 - queue status, the transaction is pending to execute; 1 - success; 2 - fail; 3 - cancel.
_type	uint8	Transaction type. 0 - add a guardian; 1 - remove a guardian; 2 - set threshold.

Variables of OwnerTransaction

Execution is the phase where owners execute their transactions and save changes to the smart contract. If an owner chooses to cancel a transaction, the executedType of the OwnerTransaction is set to 3 (indicating canceled), preventing further execution of that transaction. For other cases, depending on the execution result, the executedType can be updated to 1 (success) or 2 (failure).

Transactions can not be executed until the time delay has expired. Once this delay has expired, owners have a period defined by the expirePeriod (set during the initial setup phase) to execute their transaction. The combination of the delay, expirePeriod, and eta parameters creates a flexible mechanism for managing time delays in owner transactions. The relationship between the three parameters is illustrated in Figure .

The relation between delay, expirePeriod and eta.

In Figure , the green period indicates the time when the owner can execute the transaction. The yellow period is the waiting period, and the gray period represents the expired period, after which the transaction can no longer be executed.

Change ownership process

The change ownership process.

The final action supported by the guardian mechanism is the change of ownership, as illustrated in Figure . This process is divided into three steps:

• The owner submits a new owner address. The step is only executed by the owner.
• The guardians generate their zero-knowledge proofs and submit their proofs to the smart contract system.
• Once the required number of valid proofs from guardians is collected, the smart contract system unlocks a special transaction to change ownership. It is important to note that at this stage, anyone can execute the transaction, as all validations and verifications have already been completed in the previous steps. The transaction simply updates the owner to the new address designated by the old owner in Step 1.

Because it is a sensitive process, it is irreversible and blocks all other actions until they are completed.

If the current owner notices that their ownership may have been compromised, the owner can initiate the ownership transfer by submitting a new owner address, stored temporarily on-chain in the ZKRecovery smart contract. The new owner's address must satisfy the following conditions:

• It must not be zero address.
• The new owner's address must be different from the current owner's address.
• The account address calculated from the new owner address by the account factory smart contract is an undeployed address.

The first and second conditions ensure the validity of the new owner's address, and the third condition makes sure that the new owner's address is unique and available. Algorithm illustrates the logic behind the submitNewOwner function.

submitNewOwner function

Submitting a new owner address does not automatically change ownership. Instead, it is a notice to the guardians. Traditionally, each guardian signs a message, including the new owner's address, and submits it to the smart contract. Once the threshold is reached, the smart contract verifies all signatures and processes the transfer of ownership. The traditional approach is easy to implement, but it has several drawbacks

• If any guardian provides an invalid signature, all guardians may have to sign again, or the batch signature must be recalculated, reducing reliability.
• To verify signatures on-chain, the smart contract must store guardian addresses in plain form to compare with the address in the signature, which risks leaking sensitive information.

The proposed design uses ZKPs to overcome the limitations of the traditional approach. The smart contract stores the hash of each guardian's address instead of the plaintext address. Each guardian independently creates and submits their proof on-chain. The proof creation and verification process (referred to as the confirm change owner process, represented by the green square in Figure is discussed in detail in Section . The smart contract verifies each proof and records its validity. Once the number of valid confirmations reaches the required threshold, the smart contract unlocks the ownership change function.

Zero-Knowledge-Based Guardian Mechanism

Overall confirm change owner process.

• in the off-chain phase, a valid guardian signs a message and uses the signature to produce a proof.
• in the on-chain phase, the proof is verified, and if it is valid, the change owner process will be run.

• It receives the signature and the guardian public key as the inputs.
• It verifies the signature to ensure that the guardian is the owner of the valid key pair.
• It hashes the guardian public key and returns it as public output to the smart contract can perform the comparison process.

• Choosing a sufficient hash function.
• Choosing a sufficient curve signature algorithm.

Choosing hash function and curve signature algorithm

ZK circuits are fundamentally built on addition and multiplication operations over finite fields, so it has many steps that depend on arithmetic computations. Therefore, the proposed hash function must simplify circuit construction, minimizing the number of constraints and the amount of computation burden in R1CS and QAP, as well as during the proof generation and verification processes.

XOR circuit.

To measure circuit efficiency, we used the snarkjs library [] to calculate the number of non-linear constraints, linear constraints, wires, labels, witness size, and constraint size. We also measured the time taken to generate and verify the proof.

We evaluate several hash functions: SHA256, Keccak256, pedersen, poseidon [], and poseidon2. We use the implementations of circomlib [] for SHA256, poseidon and pedersen, and hash-circuits [] for Keccak256 and poseidon2. All code is available in our open-source repository []. Table shows the result.

Hash function	SHA256	Keccak256	Pedersen	Poseidon	Poseidon2
non-linear constraints	29412	145408	3124	216	480
linear constraints	1852	17046	132	199	552
wires	31209	155031	3513	417	1034
labels	205033	654273	8129	583	1842
witness size	975.36KB	4.73MB	109.86KB	13.11KB	32.39KB
constraint size	6.65MB	27.81MB	673.53KB	51.96KB	142.70KB
generate proof time (ms)	832.63	4882.06	269.72	124.31	164.19
verification time (ms)	10.63	12.8	11.16	10.85	10.84

Information of some hash function's circuits

SHA256 and Keccak256, which are built on bitwise logic, require a significantly larger number of constraints, especially non-linear constraints, to be represented in a ZK circuit. In contrast, Pedersen, Poseidon, and Poseidon2 are designed with finite field arithmetic in mind and only require hundreds of constraints, leading to significantly better performance.

A suitable hash function for ZK circuits should rely as much as possible on arithmetic operations (addition and multiplication), avoiding bitwise and modular operations. This reduces the circuit's complexity and improves the performance of R1CS and QAP, directly impacting proof generation and verification times.

Similarly, choosing a curve signature algorithm must follow the same rule: minimizing bitwise and modular operations and ensuring compatibility with field arithmetic. However, the choice of curve can also depend on system-specific requirements. For instance, if guardians are required to use ECDSA for other parts of the system, it may be suitable despite its inefficiency in ZK circuits.

Curve signature	ECDSA	BabyJubJub
non-linear constraints	1508922	19095
linear constraints	131701	615
wires	1632054	20713
labels	2129808	52949
witness size	52.23MB	647.36KB
constraint size	294.52MB	3.90MB
generate proof time (ms)	44145.32	2098.61
verification time (ms)	998.12	11.32

Information of ECDSA and EdDSA circuit

Table compares the performance of ECDSA and BabyJubJub (EdDSA). ECDSA requires over a million constraints, and proof generation time is over 44 seconds, while EdDSA needs only tens of thousands of constraints and about 2 seconds to generate a proof. Unless there are specific requirements for ECDSA, EdDSA is a more efficient choice.

Based on the evaluation and the efficient design for the ZK protocol, we selected Poseidon as the hash function and BabyJubJub as the curve signature algorithm for our implementation.

The proposed confirm change owner process

In Section , we discussed the guardian mechanism. In this section, we explain the latest process from the previous section: the confirming change owner process. This proposed process is divided into two sub-processes

• Creation proof process: This occurs off-chain, where guardians generate their proof and submit it to the smart contract.
• Verification proof process: The smart contract validates the guardian's proof, and when all requirements are met, the system unlocks the change-owner transaction.

Creation and verification proof processes

Figure illustrates the creation proof and the verification proof processes. Normally, both Poseidon hash function and EdDSA do not require a fixed-size message as input. However, since circuits are static and do not support variable-length inputs, a fixed-size message is required. In this thesis, we define the fixed size to be 256 bits. Therefore, the proof creation process uses a fixed-size combination of increment and _tempNewOwner as input. In detail, the 256-bit message consists of two parts:

• The first 64-bit is padded increment, which is extended to 64 bits by adding zeros in front of it.
• The remaining 192 bits are padded _tempNewOwner, likely to increment, _tempNewOwner is padded to 192 bits by adding zeros in front of it.

This fixed-size message is then signed using EdDSA. Next, the proof generator takes the signature and the public key as inputs to create a zk-SNARK proof. All of this can happen off-chain. While anyone, including non-guardians, can generate a proof, only proofs created by guardians are accepted based on zk-SNARK protocol. In this setup, guardians act as provers attempting to convince the verifier, which is a smart contract.

Generate proof

In the first stage, firstly, the process checks whether there is enough confirmation or not; if they are enough, every following step will be stopped. Secondly, the smart contract verifies that the submitted proof belongs to a guardian and confirms that the signed message matches the current increment. Since the circuit was designed to output (or can be called public signals) the account address hash, the _tempNewOwner and the increment, this stage simply compares the proof's address hash with each guardian's hash stored in the smart contract, as well as the proof's increment and proof's _tempNewOwner with the current increment and current _tempNewOwner stored in the smart contract respectively. This stage acts as a barrier to block proofs submitted by non-guardians. Only the proof that comes from a guardian will be executed.

The first stage

Before executing the main verification (illustrated in Algorithm ), the system first checks if the proof has already been submitted. If it has, the verification is skipped to reduce the amount of computations. Otherwise, the system verifies the zk-SNARK proof using the constraints defined in the circuit. If the proof is valid, the number of confirmations is updated.

The second stage

The common proposed circom logic

Algorithm illustrates the basic circuit's logic. It receives four inputs: the 256-bit message msg, the plain public key A, and the EdDSA signature components R8 and S}. It returns three outputs: the Poseidon hash of the public key hashPublicKey, the increment, and the address (new owner address) derived from the message.

To conclude, the proposed confirm change owner process follows a non-interactive zero-knowledge proof protocol, in which guardians serve as provers and the smart contract acts as verifier. Guardians generate their proofs off-chain and submit them to the smart contract. The smart contract then validates these proofs and determines whether the submitting guardian is authorized. This approach ensures a secure and efficient verification process without revealing any sensitive information.

Implementation

Circuit Implementation

We use circomlib [], a library that provides a collection of cryptographic circuits and helper functions specifically designed for use with zk-SNARKs and zk-STARKs, as a tool to build our circuit.

The circuit has four inputs: msg, A, R8, and S, representing the fixed-size message, the public key, and the $R$ and $S$ components of the EdDSA signature, respectively. It produces three outputs: hashPublicKey, increment, and address. These correspond to the hashed guardian account address, the increment value, and the new owner address extracted from the 256-bit message signed by the guardian.

To implement the signature verification and hash computation, we use EdDSAVerifier and Poseidon provided by circomlib, as illustrated in Program .

signal input msg[256];

signal input A[256];
signal input R8[256];
signal input S[256];

signal output hashPublicKey;
signal output increment;
signal output address;

// calculate guardian's address hash
component bitAToNum = Bits2Num(256);
component poseidon = Poseidon(1);

bitAToNum.in <== A;
poseidon.inputs[0] <== bitAToNum.out;
hashPublicKey <== poseidon.out;

// verify the signature
component verifier = EdDSAVerifier(256);
verifier.msg <== msg;
verifier.A <== A;
verifier.R8 <== R8;
verifier.S <== S;

// calculate increment and new owner address
calculationMessage.input <== msg;
increment <== calculationMessage.increment;
address <== calculationMessage.address;

The common structure of guardian circuit

To compile and integrate the circuit with a smart contract, we use circom and snarkjs []. First, the circuit is compiled into a WebAssembly file (.wasm) and a constraint file (.r1cs). The witness-calculator program uses secret data, containing the input file and WebAssembly, to generate a witness. The snarkjs tool compiles the constraints and witnesses to a Solidity file, enabling smart contracts to validate ZKPs (as illustrated in Figure ). The compilation and integration process are discussed in more detail in Section .

Architecture for generating and verifying proof using Circom and snarkjs.

interface IAccountFactory {
    mapping(address => address) public owners;
    
    function createAccount(
        address owner, uint256 salt
    ) external returns (BaseAccount ret);
    
    function getAddress(
        address owner, 
        uint256 salt
    ) external view returns (address);

    function changeOwner(
        BaseAccount _account, 
        address _newOwner
    ) external;
}

contract Account is BaseAccount {
    address public owner;
    address public accountGuardian;

    modifier onlyAccountGuardian() {
        require(accountGuardian != address(0), 
        'guardian not setup yet');
        require(msg.sender == accountGuardian, 
        'only guardian manager');
    }

    function changeOwner(
    AccountFactory _accountFactory,
    address _newOwner
      ) public onlyAccountGuardian {
        require(_newOwner != owner && _newOwner != address(0), 'invalid newOwner');
        _accountFactory.changeOwner(this, _newOwner);
        owner = _newOwner;
      }

    function setUpGuardian(address _accountGuardian) public onlyOwner {
        require(accountGuardian == address(0), 'accountGuardian has been setup');
        accountGuardian = _accountGuardian;
        emit GuardianInitialized(_accountGuardian);
    }

    function deployGuardian(bytes32 _salt) public onlyOwner {
        ZKGuardian manager = (new ZKGuardian){salt: _salt}();
        manager.initialize(this);
        setUpGuardian(address(manager));
      }
}

modifier isPublicSignalCorrect(uint _guardian, uint256 _increment, uint256 _hash);
        
    function isEnoughConfirm() public view returns (bool);
    
    function submitNewOwner(
        address _newOwner,
        AccountFactory accountFactory,
        uint256 salt
    ) public onlyOwner

    function confirmChangeOwner(
        uint[2] calldata _pA, 
        uint[2][2] calldata _pB, 
        uint[2] calldata _pC, 
        uint[3] calldata _pubSignals
    ) external payable isPublicSignalCorrect(
        _pubSignals[0], 
        _pubSignals[1], 
        _pubSignals[2]);

    function changeOwner(AccountFactory accountFactory) public payable;

    function setupGuardians(
        uint[] memory _guardians,
        uint256 _threshold,
        uint256 _expirePeriod,
        uint256 _delay
    ) public onlyOwner;

    function setThreshold(uint256 _threshold) external onlyOwner;
    function addGuardian(uint _guardian) external onlyOwner;
    function removeGuardian(uint _guardian) external onlyOwner;
}

Comparison with Existing Architectures

• KELP: a guardian-less smart contract recovery solution. KELP is based on smart contracts without the need for external guardians.
• OKX wallet: an MPC wallet, which divides the private key into three shares to improve tolerance.
• Soul wallet: an ERC-4337 smart contract wallet with guardian-based recovery but not ZKP implementation.
• Clave wallet: an ERC-4337 smart contract wallet with guardian-based recovery and ZKP, but using email accounts as guardians instead of web3 accounts.

• (1) Proactive vs. Reactive: Proactive approaches require users to take initial actions to enable recovery, such as off-chain backups. In contrast, reactive approaches do not require any initial action from users. Instead, these systems are designed to provide recovery with a minimal initial system setup to configure the recovery solution.
• (2) Account recovery vs. Fund recovery: Account recovery aims to protect and restore the key pair associated with a user's funds, enabling the recovery of assets linked to that key pair. In contrast, fund recovery focuses on retrieving funds, such as key rotation. In key rotation, the old key must be disabled, and any future actions tied to the old key should be revoked.
• (3) Standard accounts vs. Contract accounts
• (4) Recovery using guardians
• (5) Multi-key recovery: In MPC, multi-signature or threshold signature wallets, transactions require multiple keys instead of one. If a single key is lost, the remaining keys can be used to recover or replace it.
• (6) Key-custody: Referring [], we divide wallets into three types: custodial, non-custodial, and self-custodial. A custodial wallet is managed entirely by a third party, which holds the user's private keys and can restrict access or freeze funds. A non-custodial wallet splits control between the user and a service provider, allowing shared signing. In contrast, a self-custodial wallet gives the user full control of their private keys, with no external party able to block or modify actions.
• (7) Zero-knowledge proof: In the context of wallet recovery, ZKPs can be used to improve privacy guarantees and enhance the trustworthiness of decentralized recovery systems.

Soul wallet vs. the proposed wallet

Soul Wallet is a guardian-based ERC-4337 wallet that uses Web3 accounts as guardians. Similar to the proposed wallet in this thesis, guardians in Soul Wallet only participate when the owner initiates a change to a new address. Both wallets adopt a delayed execution mechanism, meaning that actions such as adding or removing a guardian are not performed immediately but instead require a predefined waiting period.

However, in Soul Wallet, the guardian addresses are stored in the smart contract in a hashed form (using the Keccak256 hash function) and are only revealed during the ownership change process. In contrast, the proposed wallet uses ZKP to verify guardians without ever revealing their identities on-chain, thereby enhancing privacy.

Common recovery process used by Soul wallet and the proposed wallet

Figure shows the common recovery process used by Soul wallet and the proposed wallet. Both wallets divide the recovery process into three steps, with several differences:

• Submit new owner: A transaction is executed to store the new address in the smart contract. In Soul wallet, the transaction can be executed by anyone instead of only by the owner in the proposed wallet.
• Confirm change owner: In both Soul Wallet and the proposed wallet, guardians perform the recovery process by submitting proof or a signature. Specifically, in the proposed wallet, guardians submit zero-knowledge proofs, whereas in Soul Wallet, they provide signatures. Once the threshold is met, both wallets unlock a function that allows the owner address to be changed.
  An important difference is how guardian identities are handled during this process. In Soul Wallet, guardians must reveal their raw addresses (as shown in Program Program , where the rawGuardian parameter and signature are used to verify their identity). This approach exposes guardian information on-chain, which can potentially be linked to the owner through external analysis. In contrast, the proposed wallet hides guardian identities by using ZKP, ensuring that guardian identities remain hidden even during the recovery process.
• Change owner: In both wallets, the transaction to change owner can be executed by anyone. The difference is the delay time before executing the transaction in Soul wallet. In the proposed wallet, the delay time is unnecessary because enough valid guardians agree to change owner, so a delay time is inconvenient.

function scheduleRecovery(
    address wallet,
    bytes32[] calldata newOwners,
    bytes calldata rawGuardian,
    bytes calldata guardianSignature
) external override returns (bytes32 recoveryId)

Schedules a recovery operation for a wallet

In conclusion, the two wallets differ in three key aspects:

• In Soul Wallet, anyone can execute the submission of a new owner, whereas in the proposed wallet, only the current owner can perform this action.
• In Soul Wallet, guardians' addresses are revealed after they confirm the ownership change, while in the proposed wallet, this does not occur.
• Soul Wallet enforces a delay before the ownership change transaction can be executed, whereas the proposed wallet does not.

Difference (1) is an advantage of Soul wallet, as guardians are considered trusted entities and only confirm when they recognize that the submission comes from an authorized owner. Differences (2) and (3) are advantages of the proposed wallet, as they enhance privacy and improve user convenience.

Performance Evaluation