paint-brush
Anonymous, Accountable Contract Wallet System With Account Abstraction: Implementationby@abstraction
107 reads

Anonymous, Accountable Contract Wallet System With Account Abstraction: Implementation

tldt arrow

Too Long; Didn't Read

An academic paper about anonymous yet accountable contract wallet systems utilizing blockchain and accountable ring signatures for secure transactions.
featured image - Anonymous, Accountable Contract Wallet System With Account Abstraction: Implementation
Abstraction: Computer Science Discourse HackerNoon profile picture

This paper is available on arxiv under CC 4.0 license.

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.

Abstract & Introduction

Preliminaries

Proposed Anonymous Yet Accountable Contract Wallet System

Implementation

Conclusion & References

IV. IMPLEMENTATION

The dominant of the proposed system in terms of cryptographic operations is to verify accountable ring signatures on-chain. Thus, we mainly focus on the accountable ring signature scheme in our implementation.


We implemented the Bootle et al. accountable ring signature scheme using Node.js. Because it is secure under the Decisional Diffie-Hellman (DDH) assumption, we employed secp256k1 as the underlying elliptic curve, which is known as a DDH-hard curve. We also implemented the RVerify algorithm using Solidity because the verification procedure is run on-chain (by the contract wallet). For ECDSA signature verification, we employed the OpenZeppelin library [7].


A. Contract Wallet Deployment


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.


TABLE IERGS FOR CONTRACT WALLET DEPLOYMENT


B. Implementation by Node.js


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


TABLE IIIMPLEMENTATION ENVIRONMENT OF NODE.JS


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.


TABLE IIIRUNNING TIMES


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


C. Implementation by Solidity


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


TABLE IVIMPLEMENTATION ENVIRONMENT OF SOLIDITY


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.


TABLE VERGS FOR RUNNING RVerify




[7] https://docs.openzeppelin.com/