This paper is under CC 4.0 license. available on arxiv Authors: (1) Kota Chin, University of Tsukuba, National Institute of Information and Communications Technology Japan; (2) Keita Emura, Kanazawa University, Japan National Institute of Information and Communications Technology Japan; (3) Kazumasa Omote, University of Tsukuba National Institute of Information and Communications Technology Japan. 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 ∈ 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 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. i i 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 belonging R generates the signature to issue a transaction is not leaked. i • 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, Σ, pk , π) = 1 holds. i • 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= pk . i

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Account Abstraction, Analysed: Abstract & Introduction

Abstracting Away Account Abstraction on Polkadot

Account Abstraction Could Be The Next Big Thing in Web3

Account Abstraction: Solutions for L1 & L2 Layers and Current State of Adoption

Blockchain Mass Adoption and Exciting Brand Experiences With Account Abstraction: ERC-4337

EIP-4337 Based Account Abstraction: Why It Won't Work for Institutions

Account Abstraction, Analysed: Abstract & Introduction

Abstracting Away Account Abstraction on Polkadot

Account Abstraction Could Be The Next Big Thing in Web3

Account Abstraction: Solutions for L1 & L2 Layers and Current State of Adoption

Blockchain Mass Adoption and Exciting Brand Experiences With Account Abstraction: ERC-4337

EIP-4337 Based Account Abstraction: Why It Won't Work for Institutions

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps