Anonymous, Accountable Contract Wallet System With Account Abstraction: Preliminaries

Table of Links

Abstract & Introduction

Preliminaries

Proposed Anonymous Yet Accountable Contract Wallet System

Implementation

Conclusion & References

II. PRELIMINARIES

A. Accountable Ring Signatures

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 pk and secret key sk. This decentralized structure matches blockchain systems. An opener has a public key opk and a secret key osk. When a user who has (pk,sk) generates a ring signature Σ on a message M, the user selects a set of public keys, which we refer to as ring R, and we assume that pk ∈ R, and selects the opener by indicating opk. We say that (Σ, M) is valid if the signer is a member of R, i.e., there exists pk ∈ R for which the corresponding sk has been used to generate Σ. As in group signatures, the designated opener can trace the signer using osk. Moreover, the opening algorithm produces a proof π proving that Σ is generated by sk corresponding to pk ∈ R. We introduce the syntax defined by Bootle et al. [10] as follows.

Definition 1 (Syntax of Accountable Ring Signatures [10]):

• Setup(1λ ): The setup algorithm takes the security parameter λ ∈ N as input and outputs the common parameter pp.

• OKGen(pp): The opener key generation algorithm takes pp as input and outputs the opener public and secret keys opk and osk, respectively.

• UKGen(pp): The user key generation algorithm takes pp as input and outputs the user public verification key pk and user secret signing key sk.

• RSign(opk, M, R,sk): The signing algorithm takes opk, a message M to be signed, a ring R, and sk as inputs and outputs a ring signature Σ. Here, R is a set of user public keys and the pk corresponding to sk is assumed to be pk ∈ R.

• RVerify(opk, M, R, Σ): The verification algorithm takes opk, M, R, and Σ as inputs and outputs 1 (accept) or 0 (reject).

• Open(M, R, Σ, osk): The open algorithm takes as M, R, Σ, and osk as inputs and outputs pk ∈ R of the signer and its proof π or ⊥ otherwise.

• Judge(opk, M, R, Σ, pk, π): The judge algorithm takes opk, M, R, Σ, pk, and π as inputs and outputs 0 if RVerify(opk, M, R, Σ) = 0; otherwise, it outputs 1 to indicate that Σ is generated by sk corresponding to pk, and 0 otherwise.

We require correctness holds where an honestly generated signature is always valid (the RVerify algorithm outputs 1), and a proof generated by the Open algorithm against the signature and corresponding verification key is always accepted by the 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 A (who may control the opener) can falsely accuse an honest user of creating a ring signature, nor A can forge a ring signature on behalf of an honest ring.

• Anonymity: It ensures that no adversary A (who does not have 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 A can produce a signature that is valid but untraceable.

• Tracing Soundness: It ensures that no adversary A can produce proofs for a signature that are accepted by the Judge algorithm for different verification keys.

Some studies have employed accountable ring signatures in blockchain systems [19], [31] 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 [8], [23], [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.

B. Layer 2

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 (zeroknowledge 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 EVMcompatible 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.

C. 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.[6]

[6] This restriction can be removed if a user (who issued a transaction) prepares a node. However, currently only a test net su