An Anonymous yet Accountable Contract Wallet System using Account Abstraction

Ethereum involves two kinds of accounts, i.e., externally owned accounts (EOA), which are controlled by a user-managed secret key, and contract accounts (contract wallets), which are controlled by smart contracts. In the current implementation of Ethereum, to run a contract wallet, an EOA must send a transaction to the contract wallet. Then the contract wallet runs a transaction according to the rule specified in the contract. Account abstraction [11] allows a contract wallet to initiate transaction execution, i.e., it can remove a transaction sent from an issuer to the contract. Account abstraction provides two primary benefits. The first benefit is the reduction of gas costs because account abstraction can remove a transaction sent from an issuer to the contract wallet. The second benefit is flexible verification. In the current Ethereum implementation, transactions, issued by EOAs, are verified according to the validity of signatures generated by secret keys of EOAs, and the underlying signature scheme is restricted to the elliptic curve digital signature algorithm (ECDSA). Thus, ECDSA signatures are employed generally when transaction validity is verified in the contract, although, theoretically, any signature schemes can be employed because signatures are verified by programs. In contrast, due to account abstraction, no EOA issues transactions, and thus any signature schemes can be employed more easily to verify transaction validity in the contract. For example, CRYSTALS-Dilithium [15], FALCON [18], and SPHINCS+ [4], which have been selected by the NIST Post-Quantum Cryptography Standardization, can be employed under the assumption they can be implemented by a program language that can be run by the contract wallet, e.g., Solidity.¹¹1Although we consider only signatures in this paper, any verification method can be employed or a contract wallet with no verification step can be constructed. In addition, account abstraction allows us to employ signatures with rich functionalities, such as accountable ring signatures [10]. Representative examples of systems that support account abstraction include StarkNet [2] and zkSync [3], which are network technologies in Ethereum Layer 2 (L2). Note that L2 is described in further detail in Section II-B.

Transactions between the EOAs and contract wallets are removed; thus account abstraction is useful for preserving the privacy of EOAs. In fact, EIP-2938 [11] states that “Privacy-preserving systems like tornado.cash” are a motivation to introduce account abstraction (tornado.cash is a mixing service). Concretely, it is expected that account abstraction can hide the issuer of a transaction. Note that a contract wallet typically verifies a signature using a verification key that has been registered in the contract program. Since the verification key is public (in a public blockchain), anyone can identify who issued the transaction (precisely, which verification key is used and the key holder who issued the transaction). In other words, account abstraction does not hide transaction issuer information. We emphasize that unconditional anonymity could promote crime. For example, tornado.cash is a tool that could be misused to facilitate money laundering, and the Fiscal Information and Investigation Service, an agency of the government of the Netherlands, arrested a 29-year-old man in Amsterdam as a suspected developer [1]. This indicates maintaining a balancing between anonymity and accountability is important.

Each EOA manages an ECDSA verification key $\mathsf{vk}$, and the corresponding address is a (last 20 bytes of) hashed value of $\mathsf{vk}$ (here Keccak-256 hash function is used). Here, as each address appears random,²²2Vanity addresses are often used to reduce the storage cost of addresses. For example, using an address 0x0000…, a part of address “0$\cdots$0” does not need to be stored. Even in this case, pseudonymity level privacy protection is guaranteed. anyone can easily determine whether multiple transactions were issued by the same EOA, although it is difficult to detect the EOA in the real world. This means that issuer privacy is preserved in the sense of pseudonymity in crypto asset trading.

For example, assume that a request to view patient data is made by a transaction in an electronic medical record system using Ethereum smart contracts [26, 22, 5, 20, 16, 33, 30, 25, 17]. In this case, we assume that multi-patient data are accessed from the same address. Then, we expect that the transaction issuing address is managed by a doctor or researcher. In addition, we expect that patients are suffering from similar diseases. Here, if the doctor or researcher associated with the address is identifiable, information identifying the patient’s disease may be leaked (although this was not authorized by the patient) depending on the specialty of the issuer of the transaction. Thus, no information about hospitals and medical offices should be leaked from transactions. However, it is necessary to internally verify who issued the transaction in order to prevent unnecessary access to medical data.

In the case of group asset management, pseudonymity level privacy protection would make the investment performance of each address public. Thus, it is desirable to be able to prove the investment performance internally while keeping information about the issuer of the transaction secret externally.

In this paper, we focus on account abstraction, which is attractive in terms of constructing a privacy-preserving system, and we propose an anonymous yet accountable contract wallet system (Figure 1).³³3We used Free Clip Art (http://www.clker.com/). In addition to account abstraction, the proposed system employs accountable ring signatures [10].⁴⁴4A user (EOA) needs to issue a transaction to a contract wallet when account abstraction is not employed. Thus, information that who issued a transaction is leaked even a ring signature scheme is employed in this case. Thus, both account abstraction and ring signatures are required mandatory in our system. We do not the following one-time deployment case that a contract wallet is newly deployed for issuing a transaction because it is not realistic solution. We implemented the proposed system using zkSync (Solidity). Precisely, we implemented the verification algorithm of the underlying accountable ring signature scheme using Solidity. The proposed system is briefly introduced as follows.

• •

  To issue a transaction, a ring signature is sent to a contract wallet, and the contract wallet verifies the signature. Then, the contract wallet uses a ring (i.e., a set of verification keys) to verify the signature. Anonymity holds in the sense that the contract wallet cannot identify the issuer among the verification key holders.

• •

  The opening functionality of the accountable ring signatures allows the actual issuer to prove that they issued the transaction, and other users can recognize this fact. In contrast, due to a security requirement of accountable ring signatures (i.e., opening soundness), no user can prove that they issued a transaction if they did not actually issue the transaction, and moreover the transaction issuer cannot claim that someone else issued the transaction. In addition, the proof can be generated by other ring members who share the secret opening key of the underlying accountable ring signatures. This functionality allows us to clarify the accountability involved in issuing a transaction. We remark that we mainly focus on how to identify/prove who issued a transaction in this paper. That is, we assume that the organization to which the transaction issuer belongs is accountable, and we do not address what penalties that organization would impose on the transaction issuer if the transaction became problematic, or how that organization would be held accountable.

• •

  The proposed system allows an issuer to employ a typical signature scheme, e.g., ECDSA, with the ring signature scheme. This functionality can be considered an extension of the typical multi-signatures that require a certain number of ECDSA signatures to run a contract wallet. For example, the contract wallet determines whether one of the issuers belongs to a group (in an anonymous manner), and a specific user (in the usual manner) agrees to run the contract wallet by verifying a ring signature and an ECDSA signature. This is illustrated in Figure 2. In the usual multi-signatures setting, anyone can recognize who agreed with running the contract wallet by observing ECDSA verification keys used for ECDSA signatures verification. Note that if two signatures are sent to the contract wallet separately, one of them must be preserved in the contract wallet which incurs an additional gas cost. To reduce the cost, one sender can collect all of the required signatures, and send them to the contract wallet.

Potential applications of the proposed system include, but are not limited to, the following.

As a generalization of ring signatures [29] and group signatures [13], Xu and Yung proposed accountable ring signatures [34]. Briefly, as in ring signatures, each user generates their own public key $\mathsf{pk}$ and secret key $\mathsf{sk}$. This decentralized structure matches blockchain systems. An opener has a public key $\mathsf{opk}$ and a secret key $\mathsf{osk}$. When a user who has $(\mathsf{pk},\mathsf{sk})$ generates a ring signature $\Sigma$ on a message $M$, the user selects a set of public keys, which we refer to as ring $R$, and we assume that $\mathsf{pk}\in R$, and selects the opener by indicating $\mathsf{opk}$. We say that $(\Sigma,M)$ is valid if the signer is a member of $R$, i.e., there exists $\mathsf{pk}\in R$ for which the corresponding $\mathsf{sk}$ has been used to generate $\Sigma$. As in group signatures, the designated opener can trace the signer using $\mathsf{osk}$. Moreover, the opening algorithm produces a proof $\pi$ proving that $\Sigma$ is generated by $\mathsf{sk}$ corresponding to $\mathsf{pk}\in R$. We introduce the syntax defined by Bootle et al. [10] as follows.

We require correctness holds where an honestly generated signature is always valid (the ${\sf RVerify}$ algorithm outputs 1), and a proof generated by the ${\sf Open}$ algorithm against the signature and corresponding verification key is always accepted by the ${\sf Judge}$ algorithm. Bootle et al. defined full unforgeability, anonymity, traceability, and tracing soundness, which are briefly explained as follows. Refer to the literature [10] for details on these security definitions.

• •

  Full Unforgeability: It ensures that no adversary $\mathcal{A}$ (who may control the opener) can falsely accuse an honest user of creating a ring signature, nor $\mathcal{A}$ can forge a ring signature on behalf of an honest ring.

• •

  Anonymity: It ensures that no adversary $\mathcal{A}$ (who does not have $\mathsf{osk}$) can identify the signer, i.e., a signature does not reveal the identity of the ring member who generated it.

• •

  Traceability: It ensures that no adversary $\mathcal{A}$ can produce a signature that is valid but untraceable.

• •

  Tracing Soundness: It ensures that no adversary $\mathcal{A}$ can produce proofs for a signature that are accepted by the ${\sf Judge}$ algorithm for different verification keys.

Some studies have employed accountable ring signatures in blockchain systems [31, 19] due to its decentralized structure. In addition, Qiao et al. [28] removed the opening functionality from group signatures to reduce its centralized structure; however, it still has a centralized structure because a group manager issues signing keys to the group members unlike to (accountable) ring signatures. Linkable ring signatures [23, 8, 24] have been employed to provide a pseudonymity level privacy protection. As mentioned previously, this is insufficient; thus, anonymity level privacy protection is desirable. Delegatable anonymous credentials (DAC) [12] have been employed for eKYC systems [9, 32], where KYC stands for Know-Your-Customer. However, DACs are not applicable in the proposed system because they do not provide tracing functionality. Connolly et al. [14] proposed a revocable and auditable anonymous credential scheme called Protego, and they considered its application to Hyperledger Fabric. Although it might be employed in the proposed system, Connolly et al. only considered permissioned blockchains. Thus, accountable ring signatures are employed in the proposed system.

Ethereum is widely recognized as providing high security as a smart contract-enabled blockchain. However, in terms of ensuring security and providing a distributed structure, there is room for improvement regarding scalability. Concretely, the number of transactions that can be processed within a certain time period is less than that of other blockchain systems. Thus, transaction fees (gas costs) will increase when many EOAs want to issue transactions. To solve this problem, we can issue a transaction off-chain, and the proof that the transaction is generated correctly, is only stored on the Ethereum blockchain. In this case, the blockchain and off-chain are referred to as Layer 1 (L1) and Layer 2 (L2), respectively. For example, when a Merkle tree is used to generate a hash chain, the proof that the hash chain satisfies the Merkle tree is stored in L1. To reduce the proof size stored in L1, the zk-STARK (zero-knowledge Scalable Transparent ARgument of Knowledge) [6] or zk-SNARK (zero-knowledge Succinct Non-interactive ARguments of Knowledge) [21, 27] are employed.

zkSync [3] is an Ethereum L2 network technology that supports zk-SNARK. The goal of L2 technologies to provide the same execution environment of Ethereum (i.e., the EVM: Ethereum Virtual Machine), and zkSync nearly supports the same execution environment of Ethereum, i.e., it is EVM-compatible and can run a smart contract programed by Solidity. Thus, we can utilize Ethereum ecosystem tools, and smart contracts on zkSync are described by Solidity. This means that the proposed system can be used directly when Ethereum supports account abstraction.

In the following, we describe account abstraction. A user sends the code of a contract wallet to nodes that support account abstraction, and requests to its deployment. Note that the user does not need to be an issuer of a transaction. After deploying the contract wallet, an issuer sends transaction data to blockchain via nodes. Finally, the contract wallet runs the transaction according to the rule described in the code. We illustrate the flow of transaction issuing when account abstraction is/is not employed in Figure 3 and Figure 4.

Here, the issuer (User (EOA)) communicates with nodes, their IP address is known by nodes which break anonymity trivially. Thus, we exclude the nodes in our anonymity requirement.⁶⁶6This restriction can be removed if a user (who issued a transaction) prepares a node. However, currently only a test net supports account abstraction, and users who can prepare nodes are restricted.

We require the following security notions hold. Especially, due to the provability and proving soundness, the protocol is accountable because they allow us to clarify the accountability involved in issuing a transaction.

• •

  Anonymity: All entities that can observe transactions including contract wallets and excluding group users and nodes that communicate with the transaction issuer, cannot identify the actual issuer among the verification key holders contained in ring $R$.

• •

  Unforgeability: As long as all signatures (either/both the ring signatures and/or the ECDSA signatures) specified by the $\mathsf{Policy}$ are sent to a contract wallet, no entity can issue a transaction that is valid under the $\mathsf{Policy}$.

• •

  Provability: When a group user $i$ sends a ring signature to issue a transaction, the user can generate its proof.

• •

  Proving Soundness: When a group user $i$ does not send a ring signature to issue a transaction, the user cannot generate its proof.

In the following, we explain the case of $\mathsf{Policy}:=\{R,j\}$. First, we assume that all group users belonging to $R$ share $\mathsf{osk}$. Let a group user $i\in R$ issue a transaction. Then, the user $i$ generates a ring signature $\Sigma$, and the individual user $j$ generates an ECDSA signature $\sigma$, respectively. After these signatures are sent to a contract wallet, the contract wallet checks whether $\Sigma$ is valid under $R$, and $\sigma$ is valid under $\mathsf{vk}_{j}$. If both signatures are valid, then the contract wallet runs the transaction. We note that only the signature verification is executed on-chain. Next, the user $i$ runs the ${\sf Open}$ algorithm using $\mathsf{osk}$, generates $\pi$ that is a proof of transaction issuing, and sends $\pi$ to other group users (via an off-chain channel). For example, any information sharing tool used in the organization (e.g., a bulletin board in the organization or e-mails) can be used for sending pi. Other group users can recognize that the user $i$ issues the transaction by checking $\pi$ using the ${\sf Judge}$ algorithm.

We can easily consider a case that consents of two or more individual users are required. For example, $\mathsf{Policy}:=\{R,j,k\}$. Similarly, we can consider two or more rings, e.g., $R_{1}$ and $R_{2}$. Here, we assume that $R_{1}\cap R_{2}=\emptyset$ and do not consider the case $R_{1}\cap R_{2}\neq\emptyset$ because the contract wallet cannot distinguish whether one user who belongs to $R_{1}\cap R_{2}\neq\emptyset$ sends two ring signatures or not, due to anonymity. Similarly, we do not consider a case that consents two or more group users belonging to the same ring are required because the contract wallet cannot distinguish whether one user who belongs to the ring sends two or more ring signatures or not, due to anonymity. We remark that ring members can internally check whether one user who belongs to the ring sends two or more ring signatures or not. Thus, in the case that the proof $\pi$ will be opened after issuing the transaction, these restrictions could be removed.

Here, we describe the proposed anonymous yet accountable contract wallet system. The proposed system consists of two procedures, $\mathsf{DeployContractWallet}$ and $\mathsf{SecdTransaction}$. The $\mathsf{DeployContractWallet}$ protocol is used to deploy a contract wallet, and the $\mathsf{SecdTransaction}$ protocol issues a transaction against a transaction issuing request.

• •

  $\mathsf{DeployContractWallet}(\mathsf{Code},\mathsf{BlockChain})$: Let $\mathsf{Code}$ be the code of a contract wallet. In the protocol, $\mathsf{Code}$ is sent to nodes that support account abstraction. Here, we describe $\mathsf{BlockChain}$ as the set of nodes. Then, $\mathsf{Code}$ contains a policy $\mathsf{Policy}$, and a set of verification keys (a ring $R$ and ECDSA verification keys), and the rule that specifies the procedure run after the verification of signatures is passed. Finally, deploy a contract wallet $\mathsf{CW}$.

• •

  $\mathsf{SecdTransaction}(\mathsf{TransactionData},\mathsf{BlockChain},\mathsf{CW})$: A transaction data $\mathsf{TransactionData}$, containing accountable ring signatures and ECDSA signatures, is sent to $\mathsf{CW}$ via nodes described by $\mathsf{BlockChain}$. Then, $\mathsf{CW}$ checks the validity of signatures according to $\mathsf{Policy}$, and issues a transaction.

In our system, the ${\sf RVerify}$ algorithm is run on-chain by the contract wallet, as in the case of ECDSA signatures, because any one can issue a transaction if no verification is involved. One may think that the ${\sf RVerify}$ algorithm could be run off-chain, e.g., the operator of the underlying L2 system runs the ${\sf RVerify}$ algorithm and sends the validity result to the wallet. However, it requires to assume an additional trust to the operator

• •

  Anonymity: Due to account abstraction and the anonymity of the underlying accountable ring signature scheme, the fact that a group user $i$ belonging $R$ generates the signature to issue a transaction is not leaked.

• •

  Unforgeability: Due to the unforgeability of the underlying accountable ring signature scheme and ECDSA, no entity, that does not belong to $R$ or does not have a signing key corresponding to $\mathsf{vk}$ specified by $\mathsf{Policy}$, can issue a transaction. Due to the tamper resistance of the blockchain, the code of a contract wallet is not modified after its deployment. Thus, as long as all signatures (either/both ring signatures and/or the ECDSA signatures) specified by $\mathsf{Policy}$ are sent to a contract wallet, no entity can issue a transaction that is valid under the $\mathsf{Policy}$.

• •

  Provability: Let $\Sigma$ be a ring signature generated by $\mathsf{sk}_{i}$ and verified by a contract wallet. Due to the correctness of the underlying accountable ring signature scheme, ${\sf Judge}(\mathsf{opk},M,R,\Sigma,\mathsf{pk}_{i},\pi)=1$ holds.

• •

  Proving Soundness: Let a ring signature be generated by $\mathsf{sk}_{i}$. Due to the tracing soundness, no user (including group users) can produce $\pi$ that is accepted by the ${\sf Judge}$ algorithm with $\mathsf{pk}\neq\mathsf{pk}_{i}$.

First, we show that ergs (which is used in zkSync) for contract wallet deployment (which represent the average of ergs of 100-times deployment in the case of $|R|=4$ and $|R|=10$). We estimate the case of $|R|=4$ and $|R|=10$ (i.e., four/ten verification keys are contained in the ring). We also calculate the corresponding ETH and USD (using chart on 2022 December 1st). We can see that the costs are almost independent to the number of verification keys, i.e., $|R|$, because each verification key is represented by two unsigned integers only.

Here, we describe our implementation environment of Node.js in Table II.

We show our implementation results (which represent the average of running times of 100-times executions) of the accountable ring signature scheme in Table III. We estimate the case of $|R|=4$ and $|R|=10$.

Although they depend on the ring size, they are reasonable because they are run off-chain, except the ${\sf RVerify}$ algorithm in the proposed system. The running time of the ${\sf RVerify}$ algorithm here is also important because the ${\sf Open}$ and ${\sf Judge}$ algorithms internally run the ${\sf RVerify}$ algorithm, since the corresponding ring signatures to be opened are required to be valid.

Here, we describe our implementation environment of Solidity in Table IV.

We show our implementation results (which represent the average of ergs of 100-times executions in the case of $|R|=4$ and $|R|=10$) of the accountable ring signature scheme in Table V. We also calculate the corresponding ETH and USD (using chart on 2022 December 1st). Currently, transaction fee to run zkSync is not strictly established, and thus, they are reference values. Nevertheless, they are quite expensive as a fee to issue a transaction. We note that the ECDSA verification algorithm is run by 574,254 ergs. The main reason of these high costs is inefficiency of elliptic curve operations in Solidity. Moreover, it seems that the transaction needs to be divided in the real environment due to the ergs costs because there is a limitation on the transaction size that can be executed in a single transaction in the mainnet.