Anonymous, Accountable Contract Wallet System With Account Abstraction: Proposed System

Table of Links

Abstract & Introduction

Preliminaries

Proposed Anonymous Yet Accountable Contract Wallet System

Implementation

Conclusion & References

III. PROPOSED ANONYMOUS YET ACCOUNTABLE CONTRACT WALLET SYSTEM

In this section, we describe the proposed anonymous yet accountable contract wallet system. First, we classify users who issue transactions.

• Group User: a user i who manages a key pair of the underlying accountable ring signature scheme (pki ,ski) and the common opening key osk. i ∈ R denotes when user i is a group member where R is the ring used for signature verification (i.e., pki ∈ R).

• Individual User: a user j who manages own ECDSA key pair (vkj ,sigkj ).

A. Security Requirements

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 Policy are sent to a contract wallet, no entity can issue a transaction that is valid under the 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.

B. High-level Description

In the following, we explain the case of Policy := {R, j}. First, we assume that all group users belonging to R share osk. Let a group user i ∈ R issue a transaction. Then, the user i generates a ring signature Σ, and the individual user j generates an ECDSA signature σ, respectively. After these signatures are sent to a contract wallet, the contract wallet checks whether Σ is valid under R, and σ is valid under vkj . 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 Open algorithm using osk, generates π that is a proof of transaction issuing, and sends π 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 π using the Judge algorithm.

We can easily consider a case that consents of two or more individual users are required. For example, Policy := {R, j, k}. Similarly, we can consider two or more rings, e.g., R1 and R2. Here, we assume that R1 ∩ R2 = ∅ and do not consider the case R1 ∩ R2 6= ∅ because the contract wallet cannot distinguish whether one user who belongs to R1 ∩ R2 6= ∅ 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 π will be opened after issuing the transaction, these restrictions could be removed.

C. Proposed System

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

• DeployContractWallet(Code, BlockChain): Let Code be the code of a contract wallet. In the protocol, Code is sent to nodes that support account abstraction. Here, we describe BlockChain as the set of nodes. Then, Code contains a policy 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 CW.

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

In our system, the 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 RVerify algorithm could be run offchain, e.g., the operator of the underlying L2 system runs the RVerify algorithm and sends the validity result to the wallet. However, it requires to assume an additional trust to the operator

D. Security Discussion

• 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 vk specified by 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 Policy are sent to a contract wallet, no entity can issue a transaction that is valid under the Policy.

• Provability: Let Σ be a ring signature generated by ski and verified by a contract wallet. Due to the correctness of the underlying accountable ring signature scheme, Judge(opk, M, R, Σ, pki , π) = 1 holds.

• Proving Soundness: Let a ring signature be generated by ski . Due to the tracing soundness, no user (including group users) can produce π that is accepted by the Judge algorithm with pk 6= pki.