Anonymous, Accountable Contract Wallet System With Account Abstraction: Abstract & Intro

Table of Links

Abstract & Introduction

Preliminaries

Proposed Anonymous Yet Accountable Contract Wallet System

Implementation

Conclusion & References

Abstract

Account abstraction allows a contract wallet to initiate transaction execution. Thus, account abstraction is useful for preserving the privacy of externally owned accounts (EOAs) because it can remove a transaction issued from an EOA to the contract wallet and hides who issued the transaction by additionally employing anonymous authentication procedures such as ring signatures. However, unconditional anonymity is undesirable in practice because it prevents to reveal who is accountable for a problem when it arises. Thus, maintaining a balancing between anonymity and accountability is important. In this paper, we propose an anonymous yet accountable contract wallet system. In addition to account abstraction, the proposed system also utilizes accountable ring signatures (Bootle et al., ESORICS 2015). The proposed system provides (1) anonymity of a transaction issuer that hides who agreed with running the contract wallet, and (2) accountability of the issuer, which allows the issuer to prove they agreed with running the contract wallet. Moreover, due to a security requirement of accountable ring signatures, the transaction issuer cannot claim that someone else issued the transaction. This functionality allows us to clarify the accountability involved in issuing a transaction. In addition, the proposed system allows an issuer to employ a typical signature scheme, e.g., ECDSA, together with the ring signature scheme. This functionality can be considered an extension of the common multi-signatures that require a certain number of ECDSA signatures to run a contract wallet. The proposed system was implemented using zkSync (Solidity). We discuss several potential applications of the proposed system, i.e., medical information sharing and asset management.

Index Terms—Blockchain, Account abstraction, Contract wallet, Accountable ring signatures.

I. INTRODUCTION

A. Introduction of Account Abstraction

Ethereum involves two kinds of accounts, i.e., externally owned accounts (EOA), which are controlled by a usermanaged 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.[1] 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 “Privacypreserving 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.

B. Privacy on Ethereum

Each EOA manages an ECDSA verification key vk, and the corresponding address is a (last 20 bytes of) hashed value of vk (here Keccak-256 hash function is used). Here, as each address appears random,[2] 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.

Does Pseudonymity Provide Sufficient Privacy Protection? When crypto assets are traded between individuals, the pseudonymity level privacy protection might be sufficient. However, some information leakage occurs if a system is implemented using smart contracts.

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 [5], [16], [17], [20], [22], [25], [26], [30], [33]. In this case, we assume that multipatient 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.

A Naive Solution 1: Key Sharing. Let a pair of signing and verification keys be generated and let all members of a group share the key pair. When a member issues a transaction, the same signing key is used to generate a signature. Then, anonymity level privacy protection is provided because a contract wallet uses the same verification key to verify the signature. However, there is no way to identify who issued the transaction, even among group members. Unconditional anonymity is undesirable in practice because it prevents to reveal who is accountable for a problem when it arises. In addition, determining how to revoke the signing key when a member leaves the group is a nontrivial problem.

A Naive Solution 2: External Services. Amazon Web Services (AWS) Key Management Service or a system on permissioned blockchain that support a trusted execution environment (TEE), e.g., Intel SGX, can be used to solve the above problems. By using such services, group members can issue a transaction without sharing the signing key. Here, anonymity still holds because the contract wallet uses the same verification key. In addition, group members can internally identify who issued a transaction via an access log (AWS Key Management Service) or the transaction (permissioned blockchain). Member revocation is also possible via access control to the services. Thus, technically we can provide both anonymity (for outside of the group) and accountability (for the group) simultaneously. However, both methods assume trust in AWS and TEE, which is undesirable relative to increase trust points.

C. Our Contribution

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).[3] In addition to account abstraction, the proposed system employs accountable ring signatures [10]. [4] 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.

D. Applications

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

Medical Information Sharing. As mentioned previously, when a request to view patient data is made by a transaction in an electronic medical record system using Ethereum smart contracts, it is highly desirable that no information about hospitals and medical offices is leaked from the transactions.

However, it is also essential to be able to internally verify who issued the transaction in order to prevent unnecessary access to medical data. With the proposed system, from the outside, it is possible to hide who is accessing patient data among members in an organization. For example, when a hospital is specified as the organization, it is possible to keep secret which doctors’ offices have access to medical data. If a clinical department, e.g., internal medicine, psychosomatic medicine, or plastic surgery, is specified as the organizational unit, which department is related to which disease is leaked, but no other information is leaked because which doctor accessed the patient data is kept secret. In addition, dividing the organization into independent departments relative to the actual medical offices may further prevent unnecessary leakage of information. Thus, by setting organizational units appropriately, we can control leaked information. In addition, more flexible settings can be realized by using our extended multi-signatures. For example, we can consider a case where the hospital director or a department head must agree to issue a transaction. Here, one person in a medical office needs to agree to issue the transaction.

Asset Management. The range of blockchain-based asset management has expanded due to the advent of smart contracts. Thus, the number of investment companies that manage their clients’ funds has been increasing. In some cases, the addresses held by lenders are known publicly. Then, the status of the fund management can be checked.[5] It is assumed that there are cases where multiple users share an EOA as the address, and cases where multiple users employ contract wallets where transactions can be issued with the consent of a certain number of users. In the former case, it is impossible to know who issued the transaction internally. In the latter case, due to the pseudonymity level privacy protection, anyone can check the investment performance of each address. Except for cases where the investment status is disclosed intentionally, such information can be leaked unexpectedly. By employing the proposed system, the investment status of each address is not disclosed externally, and the investment status of each individual can be known internally.

[1] Although we consider only signatures in this paper, any verification method can be employed or a contract wallet with no verification step can be constructed.

[2] Vanity addresses are often used to reduce the storage cost of addresses. For example, using an address 0x0000..., a part of address “0· · · 0” does not need to be stored. Even in this case, pseudonymity level privacy protection is guaranteed.

[3] We used Free Clip Art (http://www.clker.com/).

[4] A 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.

[5] In fact, these addresses are not disclosed by lenders intentionally. Here, they are assumed to be lenders’ addresses based on the asset management status.