Zk-SNARKs-Based Anonymous Payment Channel in Blockchain

Abstract

Payment channels serve as an effective solution to the scalability problem of cryptocurrencies, which significantly increase transaction rates by allowing users to conduct large-scale offline transactions off-chain without posting everything to the blockchain. However, the existing payment channels lack privacy protection for the transaction amount and the linking relationship between the two parties to the transaction. Therefore, in order to address the scalability and privacy issues of cryptocurrencies such as Bitcoin, this paper proposes a zk-SNARKs-based anonymous payment channel (zk-APC), which supports an unlimited number of off-chain payments between the payer and the payee and protects the privacy of the participants. Specifically, the proposed scheme achieves relational anonymity and amount privacy for both on-chain and off-chain transactions in the payment channel through utilizing zero-knowledge proof (zk-SNARKs) and commitment schemes. This paper proves that the proposed method is more effective than similar schemes through a performance evaluation.

1. Introduction

The origins of blockchain technology can be traced back to Satoshi Nakamoto, the creator of the Bitcoin system [1]. Bitcoin, proposed by Nakamoto, is the first widely applied decentralized digital currency system, revolutionizing the traditional digital currency model that relied on trust in a third-party trusted center. The revolutionary aspect of blockchain technology [2,3,4,5,6] lies in the construction of a new trust model, where trust among users is not dependent on a single node but based on trust in the entire system. In Bitcoin, every transaction is recorded in the blockchain, a public ledger maintained by a group of decentralized nodes, ensuring its security. This public ledger establishes a reliable trust foundation for the Bitcoin system. As long as the blockchain meets the security assumptions of the entire system, its trust model can continue to operate. However, despite the advantages of decentralization, security, and traceability brought by blockchain technology [7,8], its low transaction speed and long transaction time pose scalability challenges. For instance, Bitcoin supports only 6 to 7 transactions per second, and Ethereum [9,10] up to 20 transactions per second, in stark contrast to Visa, which can handle up to 47,000 transactions per second. This low transaction throughput is insufficient for daily high-frequency trading needs, let alone executing complex smart contracts. Therefore, addressing the scalability issues of blockchain technology is crucial to its further proliferation.

Among the technologies addressing the scalability issues of decentralized cryptocurrencies [11,12,13], payment channel technology is one of the favored solutions. This technology increases the transaction speed of cryptocurrencies and aims to enable high-frequency daily offline transactions globally, achieving almost instantaneous transaction completion. The core idea of payment channel schemes [14,15] is to conduct transactions off-chain and submit the final state to the blockchain, thereby reducing the load on the blockchain. Payment channel technology divides the process between the transaction parties into three main stages: establishing the payment channel, off-chain transactions, and closing the payment channel. In the establishment phase, the initiator locks the estimated transaction funds on the blockchain, controlled jointly by both parties, to prevent misappropriation. Then, during the off-chain transaction phase, each off-chain transaction results in the initiator reallocating funds within the payment channel.Finally, in the closing phase, the receiver submits the latest off-chain transactions to the blockchain for verification. The benefit of this technology is that users can securely conduct large-scale offline transactions, without frequently interacting with the blockchain. This allows scaling blockchain theory to unlimited transactions, thus supporting daily high-frequency offline transactions for billions of users worldwide.

However, while payment channel technology offers a solution to the scalability issues of blockchain, it inherits many of the well-known weaknesses of blockchain technology, the most prominent being the leakage of private information [16,17]. The current use scenarios of payment channel technology need more protection for two types of private information: the transaction amount, and the relationship between the transaction parties. First, in the existing payment channel model, although transactions are conducted off-chain, the final records on the blockchain ledger still reveal the payment amount. Additionally, establishing and closing payment channels may expose the relationship between the transaction parties. In response to the privacy issues inherent in blockchain technology, recent studies have proposed some solutions, such as ZCash [18], Blockmaze [19], and Monero [20], which have partially resolved these two types of privacy issues of blockchain. However, these privacy mechanisms do not directly address the privacy issues in the payment channel setup. Therefore, while payment channels offer a partial solution to the scalability issues of blockchain, privacy remains a challenge that urgently needs to be addressed.

Our contribution. To resolve the privacy issues in payment channels without affecting their regular use, we propose a zk-SNARKs-based anonymous payment channel, utilizing technologies including zk-SNARKs and verifiable timed commitments [21,22] to achieve privacy protection and fair transactions in payment channels. This scheme ensures regular operation during transactions between parties through the payment channel, while guaranteeing participants’ privacy, including the privacy of transaction amounts and the unlinkability of transaction parties. Our contributions are summarized as follows:

• We present the details of a zk-SNARKs-based anonymous payment channel, which retains all the advantages of the original payment channel schemes while being more robust and secure. Specifically, we achieve privacy protection by integrating blockchain systems with zero-knowledge proofs and commitment schemes and ensure fair transactions using verifiable timed commitments.
• Experimental validation of the zk-SNARKs-based anonymous payment channel was conducted, including testing the three stages of the payment channel transaction process and related tests of zk-SNARKs within the entire system.

The remainder of this paper is organized as follows: Section 2 reviews related methods, and Section 3 describes the preparatory work related to zk-SNARKs. Section 6 introduces the relevant concepts and definitions of the scheme, Section 5 details the complete zk-SNARKs-based anonymous payment channel, and Section 6 and Section 7 discuss related issues and analyze the performance. Section 8 concludes the paper.

2. Related Work

The purpose of payment channels is to reduce transaction costs and enable rapid payments in cryptocurrency, aiming to increase transaction rates and decrease the transaction fees in current cryptocurrency systems, while potentially penalizing malicious recipients. Hearn and Spilman initially proposed payment channel technology and informally introduced a unidirectional micropayment protocol for the Bitcoin system [23], facilitating small off-chain Bitcoin payments. Subsequently, Ying proposed a novel unidirectional payment channel protocol, xLumi [24], which ensures the security of payment channel funds through a set of simple mathematical rules, significantly reducing the complexity of establishing payment channels, thereby enabling easy implementation on any blockchain with the necessary infrastructure. Xu introduced a new unidirectional payment channel protocol, Super [25], allowing off-chain one-way payments between a payer and multiple payees and penalizing double-spending, thus greatly expanding the applicability of unidirectional payment channels.

Although the advent of payment channels has enhanced the scalability of blockchain systems, they still possess numerous weaknesses regarding protecting privacy. Consequently, many specific payment channels have been designed for cryptocurrency systems, to address these privacy concerns. Green and Miers proposed a payment channel scheme, Bolt [26], capable of anonymous transactions on Zcash. In this scheme, the transaction parties in the payment channel can achieve privacy-protected off-chain variable-amount payments through hiding transaction amounts and using blind signatures to validate channel updates. However, Bolt faces several issues, including using blind signature algorithms that are incompatible with Bitcoin. Zhang et al. introduced a privacy-protecting payment channel named Z-Channel [27], utilizing zero-knowledge proofs to safeguard user privacy, thereby avoiding the problems associated with blind signatures. However, it still employs the relative time-lock technique common in most payment channels, hindering its wider adoption. Moreover, Moreno and others proposed a payment channel protocol for Monero, DLSAG [28], enabling privacy-protected off-chain transactions through payment channels built on Moreno. However, their solution requires a hard fork and significant changes to Monero’s transaction scheme, and it is not backward-compatible. Hence, Thyagarajan et al. proposed a new Monero-specific payment channel protocol, PayMo [29], which requires no changes to Monero’s transaction scheme nor additions to the scripting language. Furthermore, any PayMo-related transactions published on the blockchain are indistinguishable from any other regular transactions in Monero. Thus, the PayMo payment channel protocol is now usable within Monero, without system-wide modifications. However, compared to other payment channel schemes, PayMo and DLSAG are custom-designed proposals for Monero that support unidirectional off-chain small payments.

3. Preliminaries

3.1. Blockchain

The blockchain concept was first proposed in 2008 and in essence is a new type of distributed ledger. Blockchain is a decentralized infrastructure that uses encrypted blockchain structures to validate and store data, distributed node consensus algorithms to generate and update data, and smart contracts to program and manipulate data. It is widely used in finance, agriculture, healthcare, the charity sector, and the Internet of things. The blockchain system architecture generally includes six layers: a data layer, network layer, consensus layer, incentive layer, contract layer, and application layer. The data, network, and consensus layers are the three indispensable layers of the standard blockchain framework. Below, we describe the concept and function of each layer in detail.

• The application layer mainly encapsulates blockchain application scenarios, such as finance, supply chain, transportation, medical care, insurance, etc. Blockchain technology can solve some difficult points that cannot be solved using existing information technology. In addition, blockchain’s empowerment of traditional industries can further enhance their competitiveness.
• The contract layer mainly encapsulates self-executing code scripts and smart contracts, so that the ledger has programmable features. The emergence of smart contracts has accelerated the application of blockchain technology in various industries and fields. At present, most blockchain applications are DAPPs based on smart contracts.
• The incentive layer integrates an issuance and distribution mechanism and encourages the nodes in the blockchain network to actively participate in the consensus and reward the nodes that verify the safety through the incentive mechanism.
• The consensus layer includes various consensus algorithms, such as PoW, PBFT, etc., which are used for packaging transactions into blocks and blockchains.
• The network layer includes the networking mode of nodes, network transmission protocol, data security transmission mechanism, etc.; the network layer is used to realize communication between nodes.
• The data layer includes data block storage, blockchain storage structure encryption technology, etc., to realize data storage and ensure data security.

3.2. zk-SNARKs

Zero-knowledge proofs can prove the correctness of statements without leaking any additional information, and they are a widely used privacy-preserving technique. As a kind of zero-knowledge proof, zk-SNARK’s [30,31,32] non-interactive zero-knowledge proof scheme is the most widely used among the existing zero-knowledge proofs and can verify the validity of a transaction without the verifying node knowing the specific contents. Zk-SNARKs are often used in privacy protection scenarios and have excellent privacy protection effects.

The basic method of zk-SNARK can be described by a set of polynomial time algorithms $\mathrm{\Pi }$ = (Setup, KeyGen, Prove, Verify), specifically expressed as:

• $pp\leftarrow Setup\left(1^{\lambda }\right)$: Input a security parameter $\lambda$, the algorithm outputs a public parameter list $pp$. $pp$ is published to the public and can be accessed by any user, and the algorithm is only executed once at the very beginning.
• $(pk,vk)\leftarrow KeyGen\left(\mathcal{C}\right)$: Input a mathematical operation circuit $\mathcal{C}$, the algorithm uses public parameters $pp$ and generates a key pair $(pk,vk)$ for zero-knowledge proof, where $pk$ is the proof key for generating zero-knowledge proof, and $vk$ is the verification key for verifying a zero-knowledge proof key. The key pair are also exposed as a public parameter.
• $\pi \leftarrow Prove(pk,x,w)$: input circuit $\mathcal{C}$ zero-knowledge proof key, the normal input x of circuit $\mathcal{C}$, and the private input (auxiliary input) w of the circuit $\mathcal{C}$, the algorithm generates a $x,w$ that satisfies the relationship ${\mathcal{R}}_{\mathcal{C}}$’s non-interactive proof $\pi$, constructed using the circuit $\mathcal{C}$. $x,\pi$ are public.
• $b\leftarrow Verify(vk,x,\pi )$: input circuit $\mathcal{C}$ zero-knowledge proof key, circuit $\mathcal{C}$ normal input x, and the non-interactive proof $\pi$ generated according to the circuit $\mathcal{C}$, the algorithm verifies the validity of the non-interactive proof $\pi$, and outputs the result b. If $b=0$, the non-interactive proof $\pi$ is verified valid. Otherwise, the non-interactive proof $\pi$ is invalid.

Zk-SNARKs have the following properties:

Completeness: This means that an honest prover and a valid witness will always be able to convince a verifier; that is, for any $\lambda$, mathematical operation circuit $\mathcal{C}$ and any $(x,w)\in {\mathcal{R}}_{\mathcal{C}}$, we have

$$Pr\left[Verify(vk,x,\pi )=1|\begin{array}{c}(pk,vk)\leftarrow KeyGen\left(\mathcal{C}\right)\hfill \\ \pi \leftarrow Prove(pk,x,w)\hfill \end{array}\right]=1.$$

Conciseness: An honest generated proof $\pi$ has ${\mathcal{O}}_{\lambda }\left(1\right)$ bits, verifying that Verify$(vk,x,\pi )$ runs at time ${\mathcal{O}}_{\lambda }\left(\right|x\left|\right)$. (Here, ${\mathcal{O}}_{\lambda }$ hides a fixed polynomial factor in $\lambda$)

Non-interactive: The proof is a string that the prover sends to the verifier, and the verifier can directly verify the prover without any back-and-forth interaction.

Proof of knowledge: If the verifier accepts the proof $\pi$ of the bounded prover, this shows that the prover recognizes the witness w of the given instance. For each PPT adversary $\mathcal{A}$, there is a PPT witness extractor $\mathcal{E}$, namely:

$$Pr\left[\begin{array}{c}\mathcal{C}(x,w)\ne 0^l\hfill \\ Verify(vk,x,\pi )=1\hfill \end{array}|\begin{array}{c}(pk,vk)\leftarrow KeyGen\left(\mathcal{C}\right)\\ (x,\pi )\leftarrow \mathcal{A}(pk,vk)\hfill \\ w\leftarrow \xi (pk,vk)\hfill \end{array}\right].$$

Zero-knowledge property: honestly generated proofs are perfectly zero-knowledge, since a $poly\left(\lambda \right)$-$size$ simulator S exists such that, for all stateful $poly\left(\lambda \right)$-$size$ delimiters $\mathcal{D}$, the following two probabilities are equal:

$$Pr\left[\begin{array}{c}(x,w)\in {\mathcal{R}}_{\mathcal{C}}\hfill \\ \mathcal{D}\left(\pi \right)=1\hfill \end{array}|\begin{array}{c}(pk,vk)\leftarrow KeyGen\left(\mathcal{C}\right)\hfill \\ (x,w)\leftarrow \mathcal{D}(pk,vk)\hfill \\ \pi \leftarrow Prove(pk,x,w)\hfill \end{array}\right],$$

$$Pr\left[\begin{array}{c}(x,w)\in {\mathcal{R}}_{\mathcal{C}}\hfill \\ \mathcal{D}\left(\pi \right)=1\hfill \end{array}|\begin{array}{c}(pk,vk,trap)\leftarrow \mathcal{S}\left(\mathcal{C}\right)\hfill \\ (x,w)\leftarrow \mathcal{D}(pk,vk)\hfill \\ \pi \leftarrow \mathcal{S}(trap,x)\hfill \end{array}\right].$$

4. The Concepts and Definitions

4.1. System Model

In this paper, there are four entities involved, namely the certificate authority (CA), users, miners, and trusted parties, and the descriptions of these entities are as follows:

• Certificate Authority: This is a trusted third party responsible for generating and managing identity certificates for users or trusted parties.
• Users: The main participants in the payment system are users, who can either be payers or receivers. Each user has an account comprising an address and a private key. The user’s address serves as their identity and must be registered with the certificate authority before they can participate in the system. On the other hand, a private key is used to transfer coins from one address to another. Additionally, each user can have a long-term address and any number of anonymous addresses to ensure anonymity.
• Miners: Miners are responsible for verifying the correctness of transactions and maintaining the public ledger. If the transaction is valid and compliant with policies, they will add it to the blockchain ledger. Otherwise, the miner will discard the transaction, causing the transaction to fail.
• Trusted parties: Trusted parties are responsible for initializing the system and generating public parameters for users and miners.

Our system operates as follows: Certificate authorities are responsible for registering and issuing valid transactions to the parties involved. Trusted parties are responsible for initializing the system’s public parameters. Miners are responsible for maintaining a public, append-only ledger $L_T$. Users have the options to engage in regular on-chain transactions or conduct off-chain transactions through payment channels.

4.2. Design Goal

Regarding the system model mentioned above, we primarily focus on the following security objectives:

• Unlinkability: The connection between the parties involved in transactions through the payment channel is unlinkable. This attribute ensures the public cannot link the fund sender (consumer) with the corresponding receiver (provider) within the payment channel.
• Privacy Preserving: The amount of funds transacted between parties within the payment channel should only be known to those involved; this remains hidden from the public. This means the public must be unaware of how much was spent or received by the participants.

4.3. Threat Model

Regarding the proposed system model and objectives, we define our threat model from the perspective of each entity in the zk-SNARK-based anonymous payment channel.

• Certificate Authority: We assume that the certificate authority is honest and trustworthy and does not disclose any information.
• Users: Since many transacting users are in the system, they are arbitrarily malicious. They will act in their own best interests and deviate from the intended protocol at will.
• Miners: We assume that miners implement a secure consensus algorithm to maintain their blockchain and that our scheme trusts the blockchain as a trusted intermediary to properly process transactions and smart contracts. However, the blockchain is public to all entities and does not retain private data.
• Trusted party: We assume the trusted party is honest but curious. That is, the trusted party will honestly follow the deployed protocols, but it is also interested in inferring users’ details, such as identity and data information.

5. Proposed Model

In order to address the privacy preservation problem faced by payment channels, this paper proposes a zk-SNARKs-based anonymous payment channel. The main idea of our zk-SNARKs-based anonymous payment channel is to use zk-SNARKs and a verifiable timed commitment scheme to ensure correctness and fairness, while preserving privacy and guaranteeing unlinkability. The zk-SNARKs-based anonymous payment channel consists of the following five operations: initialization, minting, payment channel establishment, payment channel update, and payment channel closure.

The initialization operation is performed before all other operations, in which the system’s zk-SNARK public parameters, signature public parameters, and verifiable timed commitment scheme commitment public parameters are initialized. The minting operation transforms a certain amount of plaintext currency into zero-knowledge currency, and the payer performs this operation. The payer and the payee jointly perform the payment channel establishment operation to establish a payment channel between the payee and the payer, and this operation freezes a certain amount of zero-knowledge currency of the payer. The payer and the payee perform the payment channel update operation to realize the transfer of funds from the payer to the payee. During the payment channel closure phase, the payee will close the payment channel.

5.1. Phase I: Setup Phase

The system public parameter list pp will be initialized during the setup phase through the Algorithm 1 initialization algorithm. In the initialization algorithm, first, for a given security parameter $\lambda$, we will generate the public parameter $p{p}_z$ using the initialization algorithm in zk-SNARKs. Then, the KenGen algorithm in zk-SNARKs is used to generate a key pair $\left(p{k}_{zi},v{k}_{zi}\right)$ for each specific circuit $C_i$ required for zk-APC. These circuits are $C_{Mint}$, $C_{SetSend}$, $C_{Update}$ and $C_{Transfer}$, which will be used for the generation and verification of transaction proofs in the payment channel. At the same time, we need to set the relevant public parameter $p{p}_{BLS}$ of the BLS signature algorithm and the relevant public parameter $p{p}_{DLG}$ of the discrete logarithm. Note that this phase is executed only once, to output the list of public parameters. A trusted third party executes this phase at the beginning of the ledger creation, and it is executed only once, and the output is made public to all users.

Algorithm 1 Initialization Algorithm

Input: Safety parameter $\lambda$ Output: The list of public parameters $pp$ 1: Compute $p{p}_z$ = zk-SNARKs.SetUp(1λ) 2: for all $\mathrm{i}\in$(Mint, SetSend, Update, Transfer) do 3:       Construct the circuit $C_i$ corresponding to the required 4:       Compute the public-private key pair $\left(p{k}_{zi},v{k}_{zi}\right)$ = zk-SNARKs.KenGen(${\mathrm{C}}_i$) 5: end for 6: Set $P{K}_z$ = ($p{k}_{zMint}, p{k}_{zSetSend}, p{k}_{zUpdate}, p{k}_{zTransfer}$) $V{K}_z$ = $(v{k}_{zMint}, v{k}_{zSetSend}, v{k}_{zUpdate},$ $v{k}_{zTransfer})$ 7: Compute $p{p}_{BLS}$ = BLS.Setup($1^{\lambda }$) 8: Choose a suitable prime order N and corresponding cyclic group G, and choose a suitable generator g. Set $p{p}_{DLG}$ = (N,G,g) 9: Output $pp$ = $\left\{p{p}_z,P{K}_z,V{K}_z,p{p}_{BLS},p{p}_{DLG}\right\}$

The detailed procedure of Algorithm 1 is shown above.

5.2. Phase II: Minting Phase

Before engaging in transactions within the anonymous payment channel, the payer must possess a specific quantity of zero-knowledge currency acquired through the Algorithm 2 mint algorithm. When payer $P_i$ intends to convert their currency using the minting algorithm, the following steps are followed: First, payer $P_i$ must have at least one public address $p{k}_i$ on the blockchain, with an adequate amount of plaintext currency at that address. Subsequently, user $P_i$ employs the minting algorithm to generate a mint transaction $t{x}_{\mathrm{Mint}}$, facilitating the conversion of a designated amount of plaintext currency into zero-knowledge currency. The minting transaction $t{x}_{\mathrm{Mint}}$ associated with user $P_i$’s public address $p{k}_i$ comprises the following variables:

• Address $p{k}_i$: this is the address of the transaction sender and the address of the transaction receiver.
• Value $v_i$: this is the value of minting transactions that need to be transformed from plaintext currency into zero-knowledge currency.
• Commitment Value $c{m}_i$: the commitment scheme $COMM$ generates a fresh zero-knowledge currency commitment value. This commitment value encapsulates the hidden components, including the address $p{k}_i$, value $v_i$, the newly generated random number $r_i$, and a unique string $s{n}_i$ generated by the $PRF$ function associated with this specific commitment.
• The zero-knowledge proof is a proof generated by zk-SNARKs.GenProof that the following conditions apply to the circuit of $C_{\mathrm{Mint}}$:

  (1)

  $c{m}_i=$ COMM ($p{k}_i,v_i,s{n}_i,r_i$)

  (2)

  $s{n}_i=$ PRF ($s{k}_i,r_i$)

• Signature ${\sigma }_{\mathrm{Mint}}:$User $P_i$ signs the above (${\pi }_{\mathrm{Mint}}$, $c{m}_i$,$v_i$) with private key $s{k}_i$.

The detailed procedure of the user $P_i$ minting algorithm is shown below.

Algorithm 2 Mint Algorithm

Input: The list of public parameters $pp$, the coin value to be converted $v_i$ and address $p{k}_i$ Output: A zero-knowledge currency $c_i$ and a mint transaction $t{x}_{\mathrm{Mint}}$ 1: Randomly sample a random number $r_i$ 2: Compute a new serial number $s{n}_i$ = PRF($s{k}_i,r_i$) 3: Compute a new commitment $c{m}_i=$ COMM($p{k}_i,v_i,s{n}_i,r_i$) 4: Set the information that needs to be disclosed to generate a zero-knowledge proof $x:$ = ($c{m}_i,v_i,p{k}_i$) and hidden evidence $w:$ = ($s{n}_i,s{k}_i,r_i$) 5: Compute ${\pi }_{Mint}$ = zk-SNARKs.GenProof($p{k}_{\mathrm{zMint}},x,w$) 6: Set zero-knowledge currency $c_i:$ = ($c{m}_i$,$p{k}_i$,$v_i$,$s{n}_i$,$r_i$) 7: Set $m:$ = (${\pi }_{\mathrm{Mint}},c{m}_i,v_i$) 8: Generate a signature on m using private key $s{k}_i$${\sigma }_{\mathrm{Mint}}=$ BLS.Sign($m,s{k}_i$) 9: Set $t{x}_{\mathrm{Mint}}$: = ($m,p{k}_i,{\sigma }_{\mathrm{Mint}}$) 10: Output zero-knowledge currency $c_i$ and mint transaction $t{x}_{\mathrm{Mint}}$

5.3. Phase III: Payment Channel Establishment Phase

Once the payer of the payment channel $P_i$ has a certain amount of zero-knowledge currency, they can enter the payment channel establishment phase. In this phase, the payer $P_i$ needs to freeze a certain amount of zero-knowledge currency $v_i$. The purpose of freezing the currency is to prevent the payer $P_i$ from using the same currency to transact with different receivers, which may result in unfair transactions. In order to lock the payer $P_i$’s funds in the payment channel established with the payee $P_j$, it is necessary to convert the payer $P_i$’s zero-knowledge currency into a new zero-knowledge currency, which is still owned by the payer $P_i$ but in which a discrete logarithmic value Y corresponding to the secret value y chosen by the payee $P_j$ is hidden and can be used only when the the payer $P_i$ can spend the new zero-knowledge currency, and only if the correct secret value y is provided. Thus, in this way the payer $P_i$ cannot spend the funds frozen in the payment channel at will.

However, while protecting the rights and interests of the payee $P_j$, we need to consider the possibility that the payee $P_j$ may go offline after establishing the payment channel. If this happens, it will result in the payer $P_i$’s funds being locked in the payment channel forever. Therefore, to prevent such a situation, we must also guarantee that the payer $P_i$ can retrieve the funds after a fixed period T (negotiated off-chain between the two parties). In order to unfreeze the funds locked in the payment channel by the payer $P_i$, the payee $P_j$ generates a discrete logarithmic value Y and its corresponding verifiable timed commitment, so that the payer $P_i$ unfreezes the funds after time T.

The payment channel establishment operation is performed by the Algorithm 3 payment channel establishment algorithm, through which a payment channel establishment transaction $t{x}_{SetSend}$ is generated. The payment channel establishment transaction locks the zero-knowledge currency of the payer $P_i$ involved in the transaction into the payment channel. The $t{x}_{SetSend}$ transaction contains the following variables:

• Merkle tree root $rt$: This is the proof that the commitment $c{m}_i^{old}$ exists in the ledger;
• Commitment serial number $s{n}_i^{old}$: A unique string associated with the commitment $c{m}_i^{old}$.
• Commitment value $c{m}^{pc}$: This value is generated by the commitment scheme COMM, and the content implied in the commitment includes the Payer’s address $p{k}_i$, the Payee’s address $p{k}_j$, the transferred value $v_i$, commitment serial number $s{n}_i^{old}$, and the serial number $s{n}_i^{pc}$ associated with this commitment value generated by the PRF function and discrete logarithmic value Y.
• Zero-knowledge proof ${\pi }_{\mathrm{SetSend}}$: This zero-knowledge proof is a proof generated by zk-SNARKs.GenProof that the following conditions apply to the circuit of $C_{\mathrm{SetSend}}$:

  (1)

  $c{m}_i^{old}$ = COMM($p{k}_i,v_i,s{n}_i^{old},r_i^{old}$)

  (2)

  $s{n}_i^{old}$ = PRF($s{k}_i,r_i^{old}$)

  (3)

  $c{m}^{pc}$ = COMM($p{k}_i,p{k}_j,v_i,s{n}_i^{old},s{n}_i^{pc},Y$)

  (4)

  $s{n}^{pc}$ = PRF($p{k}_i,r^{new}$)

  (5)

  The path $pat{h}_i$ from $c{m}_i^{old}$ to the $rt$ saved on the ledger is correct

Algorithm 3 Payment Channel Establishment Algorithm

Input: The list of public parameters pp, Merkle root $rt$, path $pat{h}_i$, Zero-knowledge currency $c_i^{old}$ and address $p{k}_j$ Output: Zero-knowledge currency $c^{pc}$ and payment channel establishment transactions $t{x}_{\mathrm{SetSend}}$ 1: Parse $c_i^{pc}:=$($c{m}_i^{old},p{k}_i,v_i,s{n}_i^{old},r_i^{old},s{k}_i$) 2: Randomly sample a random number $r^{new}$ and compute serial number $s{n}^{pc}=PRF\left(p{k}_i,r^{new}\right)$ 3: Compute the new commitment $c{m}^{pc}$ = COMM($p{k}_i,$ $p{k}_j, v_i, s{n}_i^{old}, s{n}^{pc}, Y$) 4: Set $c^{pc}:$ = ($c{m}^{pc}, p{k}_i, p{k}_j, v_i, s{n}_i^{old}, s{n}^{pc}, Y, r^{new}$) 5: Set the information that needs to be disclosed to generate a zero-knowledge proof $x:$ = ($rt$, $c{m}^{pc}$, $s{n}_i^{old}$) 6: Set hidden evidence $w:$ = ($pat{h}_i, c{m}_i^{old}, p{k}_i,p{k}_j, v_i$,$s{n}^{pc}, r_i^{old}, r^{new}, s{k}_i, Y$) 7: Compute ${\pi }_{\mathrm{SetSend}}$ = zk-SNARKs.GenProof($p{k}_{\mathrm{zSetSend}}$, $x, w$) 8: Set $t{x}_{\mathrm{SetSend}}$: = $(rt,c{m}^{pc}, s{n}_i^{old}, {\pi }_{\mathrm{SetSend}})$ 9: Output zero-knowledge currency $c^{pc}$ and payment channel establishment transactions $t{x}_{\mathrm{SetSend}}$

The detailed procedure of the payment channel establishment algorithm is shown above.

In the payment channel establishment algorithm, the payee $P_j$ calculates the discrete logarithmic value Y by randomly selecting the secret value y and computing it using $Y=g^{y}modN$ (where g and N are public parameters). Concurrently, $P_j$ generates a verifiable timed commitment $(C_{\mathrm{VTD}},{\pi }_{\mathrm{VTD}})=\mathrm{VTD}.\mathrm{Commit}(y,T)$ based on the time T and y. $P_j$ sends this verifiable time commitment and the discrete logarithm value Y to $P_i$. Subsequently, the payer $P_i$ initiates the payment channel establishment operation after successful verification via $\mathrm{VTD}.\mathrm{Verify}(Y,C_{\mathrm{VTD}},{\pi }_{\mathrm{VTD}})$. Meanwhile, $P_i$ begins running $\mathrm{VTD}.\mathrm{ForceOp}\left(C_i\right)$ until time T has elapsed, computing y to unlock the currency in the payment channel. Upon successfully initiating the payment channel establishment transaction using $P_i$, this sends all the values concealed in the newly generated promise $c{m}^{pc}$ to $P_j$ to verify the correct discrete logarithmic value Y hidden within it. Consequently, these operations establish a payment channel between the payer $P_i$ and the payee $P_j$.

5.4. Phase IV: Payment Channel Update Phase

After the formal establishment of the payment channel, the transacting parties $P_i$ and $P_j$ proceed to the subsequent phase: the payment transactions between them. In this phase, the payer $P_i$ redistributes the zero-knowledge currency locked within the payment channel based on the transactions between both parties, reallocating it with each transaction until completion. The fund allocation within the payment channel is executed using the Algorithm 4 payment channel update algorithm, generating a payment channel update transaction $t{x}_{Update}$. The $t{x}_{Update}$ transaction contains the following variables:

• Merkle tree root $rt$: the proof that the commitment $c{m}^{pc}$ exists in the ledger;
• Serial numbers $s{n}^{pc}$: strings associated with commitment commitment $c{m}^{pc}$;
• Commitment values $c{m}_i^{new}$ and $c{m}_j^{new}$: these are also generated by the commitment scheme COMM. The contents implicit in the $c{m}_i^{new}$ commitment are the address $p{k}_i$, the address $p{k}_j$, the explicit value $v_i^{new}$, serial number $s{n}_i^{new}$ associated with this commitment value generated by the PRF function, and the serial number $s{n}^{pc}$; the contents implicit in the $c{m}_j^{new}$ commitment are the address $p{k}_i$, the address $p{k}_j$, the explicit value $v_j^{new}$, serial number $s{n}_j^{new}$ associated with this commitment value generated by the PRF function, and the serial number $s{n}^{pc}$;
• Address $p{k}_i$: the address of the payer;
• Zero-knowledge proof ${\pi }_{\mathrm{Update}}$: this zero-knowledge proof is a proof generated by zk-SNARKs.GenProof, which is suitable for the circuit of $C_{\mathrm{Update}}$.

  (1)

  $c{m}^{pc}$ = COMM($p{k}_j, p{k}_j, v^{old}, s{n}^{old}, s{n}^{pc}, Y)$

  (2)

  $s{n}^{pc}$ = PRF($p{k}_i, r^{old})$

  (3)

  $c{m}_j^{new}$ = COMM($p{k}_i, p{k}_j, v_j^{new}, s{n}^{pc}, s{n}_j^{new})$

  (4)

  $s{n}_j^{new}$ = PRF($p{k}_j, r_j^{new})$

  (5)

  $c{m}_i^{new}$ = COMM($p{k}_j, p{k}_i, v_i^{new}, s{n}^{pc}, s{n}_i^{new})$

  (6)

  $s{n}_i^{new}$ = PRF($p{k}_i, r_i^{new})$

  (7)

  $v^{old}=v_j^{new}+v_i^{new}$

  (8)

  The path $path$ from $c{m}^{pc}$ to the $rt$ saved on the ledger is correct

• Signature ${\sigma }_{\mathrm{U}\mathrm{p}\mathrm{d}\mathrm{a}\mathrm{t}\mathrm{e}}$: signature of the above ($rt$, ${\pi }_{\mathrm{Update}}$, $c{m}_i^{new}$, $c{m}_j^{new}$, $s{n}^{pc}$) using the private key $s{k}_i$.
• Discrete logarithmic value Y and secret value y: $Y=g^{y}modN$ (where g is the common parameter).

Algorithm 4 Payment Channel Update Algorithm

Input: The public parameter list $pp$, $c^{pc}$, Merkle tree root $rt$, path $path$, Private key $s{k}_i$ owned by $P_i$, plaintext values $v_j^{new}$ and $v_i^{new}$ Output: Zero-knowledge currency $c_i^{new}$ and $c_j^{new}$, payment channel update transaction $t{x}_{\mathrm{Update}}$ 1: Parse $c^{pc}:=$($c{m}^{pc}, p{k}_j, p{k}_i, v^{old}, s{n}^{old}, s{n}^{pc}, Y, r^{old}$) 2: Compute the random numbers $r_i^{new}$ and $r_j^{new}$, and compute serial number $s{n}_j^{new}=PRF\left(p{k}_j, r_j^{new}\right)$ and $s{n}_i^{\mathrm{new}}=PRF\left(p{k}_i, r_i^{\mathrm{new}}\right)$ 3: Compute the new commitment value $c{m}_i^{new}=$ COMM ($p{k}_j$, $p{k}_i$, $v_i^{new}$, $s{n}^{pc}$, $s{n}_i^{new}$) and $c{m}_j^{new}=$ COMM ($p{k}_i, p{k}_j, v_j^{new}, s{n}^{pc}, s{n}_j^{new}$) 4: Set $c_i^{new}:=$($c{m}_i^{new}, p{k}_j, p{k}_i, v_i^{new}, s{n}^{pc}, s{n}_i^{new}, r_i^{new}$) and $c_j^{new}:=$$(c{m}_j^{new}, p{k}_i, p{k}_j, v_j^{new},$$s{n}^{pc}, s{n}_j^{new}$, $r_j^{new})$ 5: Set the information that needs to be disclosed to generate a zero-knowledge proof $x:=$($rt, c{m}_j^{new}$, $c{m}_i^{new}$, $p{k}_i$, $s{n}^{pc}$, $Y)$ 6: Set hidden evidence $w:=$($path$, $c{m}^{pc}$, $p{k}_j$, $v^{old}$, $v_j^{new}$, $v_i^{new}$, $s{n}_j^{new}$, $s{n}_i^{new}$, $s{n}^{old}$, $r_j^{new}$, $r_i^{new}$, $r^{old})$ 7: Compute ${\pi }_{\mathrm{Update}}$ = zk-SNARKs.GenProof $(p{k}_{\mathrm{zUpdate}}$,x, $w)$ 8: Set $m=(rt, {\pi }_{Update}, c{m}_j^{new}, c{m}_i^{new}, s{n}^{pc}, Y)$ 9: The signature ${\sigma }_{Update}=BLS.Sign(m, s{k}_i)$ is generated for message m using the private key $s{k}_i$. 10: Set $t{x}_{\mathrm{Update}}=(m, p{k}_i, {\sigma }_{Update})$ 11: Output $c_i^{new}$, $c_j^{new}$ and $t{x}_{Update}$.

The detailed procedure of the payment channel update algorithm is shown above.

After the payer $P_i$ completes the payment channel update algorithm, they are required to send the new zero-knowledge currency $c_j^{new}$ and the payment channel update transaction $t{x}_{Update}$ to the payee $P_j$. Upon receiving this information, the payee $P_j$ first verifies the correctness of the signature ${\sigma }_{Update}$ included in the payment channel update transaction $t{x}_{Update}$. Subsequently, utilizing the secret value y, they perform the complete payment channel update transaction $t{x}_{Update}$. Following this process, the payee $P_j$ has the capability to close the payment channel at any time.

5.5. Phase V: Payment Channel Closure Phase

After both parties of a payment channel have completed their transaction, the payee can close the channel by posting the latest updated transaction without communicating with the payer. When the payee $P_j$ posts the latest payment channel update transaction $t{x}_{Update}$, they can immediately receive the due currency. At the same time, the payer $P_i$ can also obtain the remaining money immediately. However, since the zero-knowledge currency owned by the payee $P_j$ that has been promised to be generated by the payer $P_i$, this also needs to be transferred immediately from the zero-knowledge currency to a new address, in order to protect the security of the payee’s funds. This is accomplished using the Algorithm 5 transfer algorithm that generates a transfer transaction $t{x}_{Transfer}$ that transfers the zero-knowledge currency $c_j^{old}$ received by the payee $P_j$ to a new address $p{k}_j^{new}$, where the $t{x}_{Transfer}$ transaction consists of the following variables:

• Merkle tree root $rt$: This is the proof that the commitment $c{m}_j^{old}$ exists in the ledger;
• Commitment serial number $s{n}_j^{old}$: A unique string associated with the commitment $c{m}_j^{old}$;
• Commitment value $c{m}_j^{new}$: This value is generated by the commitment scheme COMM, and the content implied in the commitment includes the address $p{k}_j^{new}$, the transferred value $v_j$, new random numbers $r_j^{new}$, and the serial number $s{n}_j^{new}$ associated with this commitment value generated by the PRF function;
• Address $p{k}_j$: the address of user $P_j$;
• Zero-knowledge proof ${\pi }_{\mathrm{Transfer}}$: this zero-knowledge proof is a proof generated by zk-SNARKs.GenProof that the following conditions apply to the circuit of $C_{\mathrm{Transfer}}$:

  (1)

  $c{m}_j^{old}=$ COMM($p{k}_i, p{k}_j, v_j, s{n}^{pc}, s{n}_j^{old}, Y)$

  (2)

  $s{n}_j^{old}=$ PRF($p{k}_j, r_j^{old})$

  (3)

  $c{m}_j^{new}=$ COMM($p{k}_j^{new}, v_j, r_j^{new}, s{n}_j^{new})$

  (4)

  $s{n}_j^{new}=$ PRF($s{k}_j^{new}, r_j^{new})$

  (5)

  The path $pat{h}_j$ from $c{m}_j^{old}$ to the $rt$ saved on the ledger is correct

• Signature ${\sigma }_{\mathrm{Transfer}}$:Signature of the above $({\pi }_{\mathrm{Transfer}}$, $rt$, $c{m}_j^{new}$, $s{n}_j^{old})$ using the payment channel private key $s{k}_j$.

Algorithm 5 Transfer Algorithm

Input: The public parameter list $pp$, $c_j^{old}$, Merkle tree root $rt$ and path $pat{h}_j$, public key $p{k}_j$ of $P_j$, new public key $p{k}_j^{new}$ of $P_j$ and new private key $s{k}_j^{new}$ of $P_j$ Output: New zero-knowledge currency $c_j^{new}$,transfer transaction $t{x}_{\mathrm{Transfer}}$ 1: Parse $c_j^{old}:=(c{m}_j^{old}, p{k}_i, p{k}_j, v_j, s{n}^{pc}, s{n}_j^{old}, r_j^{old})$ 2: Select new random number $r_j^{new}$ and compute serial number $s{n}_j^{new}$ = PRF($s{k}_j^{new}$, $r_j^{new})$ 3: Compute new commitment value $c{m}_j^{new}$ = COMM($v_j$, $p{k}_j^{new}$, $s{n}_j^{new}$, $r_j^{new})$ 4: Set $c_j^{new}:=(c{m}_j^{new}, p{k}_j^{new}, v_j, s{n}_j^{new}, r_j^{new}, s{k}_j^{new})$ 5: Set the information that needs to be disclosed to generate a zero-knowledge proof x: = ($rt$, $c{m}_j^{new}$, $p{k}_j$, $s{n}_j^{old}$, ) 6: Set hidden evidence w: = ( $pat{h}_j$, $c{m}_j^{old}$, $p{k}_i$, $p{k}_j^{new}$, $v_j$, $s{n}^{pc}$, $s{n}_j^{new}$, $r_j^{old}$, $r_j^{new}$, $s{k}_j^{new})$ 7: Compute $\pi$ = zk-SNARKs.GenProof($p{k}_{\mathrm{zTransfer}}$,x, w) 8: Set $m:=({\pi }_{\mathrm{Transfer}}, rt, c{m}_j^{new}, s{n}_j^{old})$ 9: User $P_i$ uses private key $s{k}_j$ to generate signature ${\sigma }_{\mathrm{Transfer}}=$ BLS.Sign($m, s{k}_j)$ for m. 10: Set $t{x}_{\mathrm{Transfer}}:=(m, p{k}_j, {\sigma }_{\mathrm{Transfer}})$ 11: Output zero-knowledge currency $c_j^{new}$,transfer transaction $t{x}_{\mathrm{Transfer}}$

The detailed procedure of transfer algorithm is shown above.

6. Analysis

In this section, we analyze how this anonymous payment channel scheme based on zk-SNARKs achieves the design goals presented in Section 4.3.

Unlinkability: In Section 4.3, we designed unlinkability to address the lack of linkability between the two parties involved in the payment channel establishment send transaction, the payment channel update transaction, and the transfer transaction mentioned in the aforementioned scheme. To prove the unlinkability of this scheme, we conduct a formal security proof by executing the game $\mathcal{GUL}$.

We abstract the blockchain network within the payment channel as an oracle $\mathcal{X}$, providing an interface to interact with the operations defined in zk-APC. The blockchain ledger $\mathcal{L}$ that stores and manages all transactions is overseen by $\mathcal{X}$. Assume a probabilistic polynomial-time adversary $\mathcal{A}$ capable of querying $\mathcal{X}$ during the game $\mathcal{GUL}$. $\mathcal{X}$ responds to each query with $\mathcal{L}$ until $\mathcal{A}$ submits a transaction tuple $(tx, t{x}^{\ast })\in \mathcal{L}$ satisfying conditions (a) $tx$ and $t{x}^{\ast }$ being of the same type, i.e., all three transaction types mentioned earlier, (b) $tx\ne$$t{x}^{\ast }$, and (c) $\mathcal{A}$ are not involved in either $tx$ or $t{x}^{\ast }$. If one of the following holds: (a) for payment channel establishment transactions, both $tx$ and $t{x}^{\ast }$ involve the same sender and receiver; (b) for payment channel updating transactions or transfer-transactions, $tx$ and $t{x}^{\ast }$ involve the same sender and recipient; or (c) for payment channel renewal transactions or transfer-transactions, $tx$ and $t{x}^{\ast }$ do not involve the same recipient, $\mathcal{X}$ outputs 1, indicating that $\mathcal{A}$ has won the game $\mathcal{GUL}$. Consequently, we can formalize the following proposition:

Theorem 1.

The zk-APC scheme preserves transaction unlinkability because, for any probabilistic polynomial time adversary $\mathcal{A}$, the following probability is negligible under security parameter λ:

$$Pr\left[\mathcal{GUL}\right(\lambda , \mathcal{A}\left)\right]=1$$

Proof. 

(a) Assume that $\mathcal{A}$ outputs a tuple of payment channel establishment transactions $(t{x}_{\mathrm{SetSend}}$,$t{x}_{\mathrm{SetSend}}^{\prime })$ where $t{x}_{\mathrm{SetSend}}$ satisfies that

$$\begin{array}{c}t{x}_{\mathrm{SetSend}}:=(rt, c{m}^{pc}, s{n}_i^{old}, {\pi }_{SetSend})\\ c{m}^{pc}=COMM(p{k}_i, p{k}_j, v_i, s{n}_i^{old}, s{n}^{pc}, Y)\\ c{m}_i^{old}=COMM(p{k}_i, v_i, s{n}_i^{old}, r_i^{old})\end{array}$$

and ${t{x}_{\mathrm{SetSend}}}^{\prime }$ satisfies that

$$\begin{array}{c}t{x}_{\mathrm{SetSend}}^{\prime }:=(r{t}^{\prime }, {c{m}^{pc}}^{\prime }, {s{n}_i^{old}}^{\prime }, {\pi }_{SetSend}^{\prime })\\ {{cm}^{pc}}^{\prime }=COMM(p{k}_i^{\prime }, p{k}_j^{\prime }, v_i^{\prime }, {s{n}_i^{old}}^{\prime }, {s{n}^{pc}}^{\prime }, Y^{\prime })\\ {c{m}_i^{old}}^{\prime }=COMM({p{k}_i}^{\prime }, {v_i}^{\prime }, {s{n}_i^{old}}^{\prime }, {r_i^{old}}^{\prime })\end{array}$$

To win the game $\mathcal{GUL}$ experiment, $\mathcal{A}$ finds a set of transactions $(t{x}_{\mathrm{SetSend}}$, $t{x}_{\mathrm{SetSend}}^{\prime })$ for which the receiver $p{k}_j=p{k}_j^{\prime }$ and the sender $p{k}_i=p{k}_i^{\prime }$.

To achieve the goal of finding identical receivers, $\mathcal{A}$ can determine whether $p{k}_j$ and $p{k}_j^{\prime }$ are equal in two ways:

(a) Obtaining the recipient’s address $p{k}_j$ (or $p{k}_j^{\prime }$) from $c{m}^{pc}$ ( or ${c{m}^{pc}}^{\prime }$).

(b) Extracting $p{k}_j$ (or $p{k}_j^{\prime }$) from zk-SNARK proof ${\pi }_{\mathrm{SetSend}}$ (or ${\pi }_{\mathrm{SetSend}}^{\prime }$).

For (a) $\mathcal{A}$ must distinguish the ($p{k}_j$,$p{k}_j^{\prime }$) contained in ($c{m}^{pc}$,${c{m}^{pc}}^{\prime }$) without knowing the secret values of the ($c{m}^{pc}$,${c{m}^{pc}}^{\prime }$), which would imply that the hidden nature of the $COMM$ is destroyed, something which corresponds to $\mathcal{A}$ is impractical. For (b), since $\mathcal{A}$ cannot break the zero-knowledge property of zk-SNARKs mentioned in Section 3, the receiver address cannot be obtained from the zero-knowledge proof either.

To achieve the objective of finding the same sender, $\mathcal{A}$ can also determine it in three ways: (a) distinguishing sender addresses from the zk-SNARKs proof; (b) $\mathcal{A}$ initially, searching for commitment values ($c{m}_i^{old}$, ${c{m}_i^{old}}^{\prime }$) used in the SetSend transaction from its view, then distinguishing the sender utilizing the $Mint$ transaction associated with $cm$; (c) distinguishing the sender addresses from $c{m}^{pc}$ or (${c{m}^{pc}}^{\prime }$).

For mode (a), $\mathcal{A}$ has to distinguish ($p{k}_i$,${p{k}_i}^{\prime }$) from the different zero-knowledge proofs (${\pi }_{\mathrm{SetSend}}$,${\pi }_{\mathrm{SetSend}}^{\prime }$), which implies that $mathcalA$ needs to destroy the zero-knowledge property of zk-SNARK.

For method (b), $\mathcal{A}$ can differentiate the sender ($p{k}_i$, ${p{k}_i}^{\prime }$) without knowledge of the other secret values in ($c{m}_i^{old}$, ${c{m}_i^{old}}^{\prime }$) through examining previous transactions $(t{x}_{\mathrm{Mint}}$, $t{x}_{\mathrm{Mint}}^{\prime })$ that include ($c{m}_i^{old}$, ${c{m}_i^{old}}^{\prime }$). However, as $c{m}_i^{old}$ and ${c{m}_i^{old}}^{\prime }$ are not visible in $t{x}_{\mathrm{SetSend}}$ and $t{x}_{\mathrm{SetSend}}^{\prime }$, $\mathcal{A}$ must obtain $c{m}_i^{old}$ and ${c{m}_i^{old}}^{\prime }$ through two means: (1) Merkle tree root; (2) zk-SNARK proof. For method (1), $\mathcal{A}$ needs to extract ($c{m}_i^{old}$, ${c{m}_i^{old}}^{\prime }$) from the Merkle tree root ($rt$, $r{t}^{\prime }$), requiring a breach in the collision-resistant hash (CRH) property. For method (2), $\mathcal{A}$ must extract ($c{m}_i^{old}$, ${c{m}_i^{old}}^{\prime }$) from the zk-SNARKs proof (${\pi }_{\mathrm{SetSend}}$, ${\pi }_{\mathrm{SetSend}}^{\prime }$), which implies a breach in the zero-knowledge property of zk-SNARKs. Regarding method (c), for the same reasons mentioned, this violates the hiding property of COMM. Therefore, the commitment scheme, hash function, and zk-SNARKs security features guarantee that the sender and receiver of a transaction cannot be distinguished in a $t{x}_{\mathrm{SetSend}}$ transaction.

(b) Assume that $\mathcal{A}$ outputs a tuple of $(t{x}_{\mathrm{Update}}$,$t{x}_{Update}^{\prime })$, where $t{x}_{\mathrm{Update}}$ satisfies that

$$\begin{array}{c}t{x}_{\mathrm{Update}}=(rt, {\pi }_{\mathrm{Update}}, c{m}_j^{\mathrm{new}}, c{m}_i^{\mathrm{new}}, p{k}_j, s{n}^{pc}, Y, {\sigma }_{Update})\\ c{m}^{pc}=COMM\left(p{k}_j, p{k}_i, v^{\mathrm{old}}, s{n}^{\mathrm{old}}, s{n}^{pc}, Y\right)\\ c{m}_j^{\mathrm{new}}=COMM\left(p{k}_i, p{k}_j, v_j^{\mathrm{new}}, s{n}^{pc}, s{n}_j^{\mathrm{new}}\right)\\ c{m}_i^{\mathrm{new}}=COMM\left(p{k}_j, p{k}_i, v_i^{\mathrm{new}}, s{n}^{pc}, s{n}_i^{\mathrm{new}}\right)\end{array}$$

and $t{x}_{Update}^{\prime }$ satisfies that

$$\begin{array}{c}t{x}_{\mathrm{Update}}^{\prime }=(r{t}^{\prime }, {\pi }_{\mathrm{Update}}^{\prime }, c{m}_j^{ne{w}^{\prime }}, c{m}_i^{ne{w}^{\prime }}, p{k}_i^{\prime }, s{n}^{p{c}^{\prime }}, Y^{\prime }, {\sigma }_{\mathrm{Update}}^{\prime })\\ c{m}^{p{c}^{\prime }}=COMM\left(p{k}_j^{\prime }, p{k}_i^{\prime }, v^{ol{d}^{\prime }}, s{n}^{ol{d}^{\prime }}, s{n}^{p{c}^{\prime }}, Y^{\prime }\right)\\ c{m}_j^{ne{w}^{\prime }}=COMM\left(p{k}_i^{\prime }, p{k}_j^{\prime }, v_j^{ne{w}^{\prime }}, s{n}^{p{c}^{\prime }}, s{n}_j^{ne{w}^{\prime }}\right)\\ c{m}_i^{ne{w}^{\prime }}=COMM\left(p{k}_j^{\prime }, p{k}_i^{\prime }, v_i^{ne{w}^{\prime }}, s{n}^{p{c}^{\prime }}, s{n}_i^{ne{w}^{\prime }}\right)\end{array}$$

To win the $\mathcal{GUL}$ experiment, $\mathcal{A}$ must identify a set of transactions $(t{x}_{Update}$, $t{x}_{Update}^{\prime })$ with the recipient $p{k}_j$ = $p{k}_j^{\prime }$. To achieve this goal, $\mathcal{A}$ can also make determinations through two methods: (a) Distinguishing the recipient’s address from the zk-SNARKs proofs. (b) Discerning the recipient’s address from ${\mathrm{cm}}_j^{\mathrm{new}}$, ${\mathrm{cm}}_i^{\mathrm{new}}\left({\mathrm{cm}}_j^{\mathrm{new}}\right)$, and $\left(c{m}_i^{ne{w}^{\prime }}\right)$.

For (a), $\mathcal{A}$ must distinguish $(p{k}_j, p{k}_j^{\prime })$ from different zero-knowledge proofs $({\pi }_{\mathrm{Update}}$, ${\pi }_{\mathrm{Update}}^{\prime })$, which implies that $\mathcal{A}$ needs to break the zero-knowledge property of zk-SNARK.

For (b), for the same reasons mentioned earlier, this would violate the hiding property of the commitment scheme (COMM). Therefore, due to the security properties of the commitment scheme, hash functions, and zk-SNARK, this ensures that in the $t{x}_{Update}$ transactions, it is impossible to determine the receiver of the transactions. The same applies to the corresponding transfer transactions of the same type.

Therefore, Theorem 1 is proved to be correct. □

Privacy Preserving: In the scheme proposed within this paper, each user involved in a transaction adopts anonymous addresses, and the verification only involves these anonymous addresses. This prevents the disclosure of users’ real identities, as no relevant identity information can be obtained from transactions by anyone other than these anonymous addresses. Therefore, the scheme proposed in this paper ensures users’ identity privacy. The zk-SNARKs-based anonymous payment channel also safeguards the privacy of transaction amounts for both parties involved in the payment channel establishment, sending transactions, payment channel updating transactions, and transfer transactions mentioned in this paper: on one hand, the substantial collision hash property of commitments keeps the transaction amount hidden from outsiders; on the other hand, due to the zero-knowledge nature of zk-SNARKs, attackers cannot extract any information about the transaction values from the zero-knowledge proofs. Additionally, this scheme protects the privacy of users’ balance values. Each user’s balance can be split into a plaintext balance and a zero-knowledge balance. Attackers could obtain the plaintext balance through ledger inspection. However, the zero-knowledge balance is secretly stored using hash key-value pairs on the blockchain’s Merkle tree. Upon revealing its serial number, the zero-knowledge balance is consumed and replaced by a new zero-knowledge balance, consequently replacing its balance commitment with a new commitment. Due to the substantial collision resistance property of the balance commitment’s hash function, attackers cannot deduce specific amounts from the balance commitment and the disclosed serial number. Therefore, attackers cannot obtain the user’s current balance values.

7. Experiment and the Results

In this section, we describe our comprehensive evaluation of the zk-SNARK-based anonymous payment channel and present experimental results to demonstrate the feasibility and performance of the scheme.

7.1. Experiment Configuration

To benchmark the protocol’s performance, we implemented our protocol using the C++ programming language, the Libsnark library, and the GMP library, where Libsnark is a library for implementing zk-SNARKs schemes in C++.

To implement zk-SNARKs in the zk-SNARKs-based anonymous payment channel, we utilized the Libsnark library [33] to develop functions for generating and verifying zk-SNARK proofs. For zk-SNARKs implemented based on the Libsnark library, we chose $AL{T}_{B}N128$ as the default elliptic curve and used various zero-knowledge proof schemes, including Groth16 [34], GM17 [35], and PGHR13 [36]. Each blockchain node generated and pre-installed the key pair $(pk, vk)$ for zk-SNARK proof generation/verification. Additionally, the hash function COMM for constructing Merkle trees and generating commitments, the hash function, and the pseudo random function (PRF) we used were instantiated using the SHA-256 hash function. To implement BLS signatures [37], we developed and implemented a BLS signature algorithm based on the GMP library. According to the workflow of the zk-SNARKs-based anonymous payment channel, we conducted a comprehensive evaluation, primarily including the following components:

• We conducted a performance evaluation of the zk-SNARKs circuits for the $Mint$, $SetSend$, $Update$, and $Transfer$ aspects of the zk-SNARKs-based anonymous payment channel;
• We compared the zk-SNARKs-based anonymous payment channel with similar protocols, such as Blockmaze, Zerocash, and DMC [38];
• We evaluated the performance of the three phases of the payment channel, payment channel establishment, payment, and payment channel closure, and compared them with DMC.

All experiments in this paper were conducted on an Ubuntu Linux 16.04 LTS machine, equipped with an AMD Ryzen 7 5800H @ 3.20GHz CPU and 16 GB RAM.

7.2. Experiment Results

7.2.1. zk-SNARKs Performance Evaluation

To determine the most suitable zk-SNARKs scheme for zk-APC, this paper evaluated the performance of PGHR13, Groth16, and GM17 schemes regarding computation and storage. Figure 1 shows a performance comparison of these three schemes for the $Mint$, $SetSend$, $Update$, and $Transfer$ circuits regarding five aspects: setup time, size of proof/verification keys, proof generation time, and verification time. As seen in Figure 1, Groth16 had significant advantages over PGHR13 and GM17, especially regarding the proof verification time, size of proof/verification keys, and setup time. In the $Mint$ circuit, the proof verification time for the GM17 scheme was 4.9-times that of Groth16, and for the PGHR13 scheme, it was 7.3-times that of Groth16. In the $Update$ circuit, the proof key size for GM17 was 2.4-times that of Groth16, and for PGHR13, it was 1.45-times that of Groth16. In the $SetSend$ circuit, the verification key size for GM17 was 2.4-times that of Groth16, and for PGHR13, it was 1.45-times that of Groth16. In the $Transfer$ circuit, the proof generation time for Groth16 and PGHR13 was almost the same, while for GM17, it was twice that of Groth16. Overall, the Groth16 scheme was the most suitable for the computation time and space requirements. Hence, all subsequent experiments in this paper utilized the Groth16 scheme.

7.2.2. Comparison with Blockmzae, Zerocash, and DMC

Figure 2 illustrates a comparison of our privacy protection scheme with other privacy protection schemes regarding five aspects: setup time, size of proof/verification keys, proof generation time, and verification time for zk-SNARKs. Although Blockmaze, Zerocash, and DMC differ from our scheme in certain scenarios, they all employ similar methods, specifically zk-SNARKs, for privacy protection. From an algorithmic functionality perspective, the $Mint$ operation in zk-APC corresponds to Blockmaze’s $Mint$, and zk-APC’s $SetSend$, $Update$, and $Transfer$ are similar to Blockmaze’s $Deposit$. zk-APC’s $Mint$, $SetSend$, $Update$, and $Transfer$ are akin to Zerocash’s $Pour$, and zk-APC’s $Mint$ is comparable to DMC’s $Deposit$. zk-APC’s $SetSend$ and $Transfer$ are analogous to DMC’s $OpenChannel$, and zk-APC’s $Update$ is similar to DMC’s $OffchainTransfer$. Compared to these three schemes, our zk-APC scheme demonstrated advantages over Blockmaze for $Mint$ regarding setup time, size of proof/verification keys, and proof generation time. In the comparison of $SetSend$, $Update$, $Transfer$, and $Deposit$, $Update$ and $Transfer$ showed inferior performance for the proof verification time. Compared to Zerocash, our $Mint$ required zero-knowledge operations, which were unnecessary in Zerocash. However, our $SetSend$, $Update$, and $Transfer$ had significant computational and storage cost advantages over Zerocash’s $Pour$, with the $Pour$ circuit’s proof generation time being 2.02-times that of the $Update$ circuit. Compared to DMC, our $SetSend$ circuit corresponding to DMC’s $OpenChannel$, $Transfer$ to DMC’s $OpenChannel$, and $Update$ to DMC’s $OffchainTransfer$ had minor differences in the five aspects mentioned above. However, the $Mint$ circuit, corresponding to DMC’s $Deposit$, required more time for setup, proof key size, and proof generation. Specifically, zk-APC’s $Mint$ circuit setup time was 2.13-times that of DMC’s $Deposit$, and the proof generation time for zk-APC’s $Mint$ was 2.4-times that of DMC’s $Deposit$, with the proof key size being double. Although there were certain disadvantages for these three aspects, they are typically only required for the initial setup or performed offline, having a minimal impact on the overall scheme. In summary, compared to BlockMaze, Zerocash, and DMC, zk-APC exhibited notable efficiency in the computational and storage costs of various zero-knowledge proof operations.

7.2.3. Payment Channel Performance Evaluation

Comparison with DMC. 

Table 1. On-chain Storage Overhead and Off-chain Communication Overhead.

	Channel Opening (On-Chain)	Channel Opening (Off-Chain)	Channel Update
zk-APC	224B	5062B	634B
DMC	288B	-	256B

compares our scheme with other existing schemes in terms of on-chain storage overheads during the establishment and updating of payment channels, as well as off-chain communication costs. Compared to the similar scheme DMC, during the channel establishment process, the transaction size to be stored on-chain in our scheme was 0.78-times that of DMC. However, our scheme requires off-chain communication overheads, while DMC’s scheme needs almost no off-chain communication. In the payment channel updating process, the off-chain communication cost of our scheme was 2.4-times that of DMC’s.

Computation cost. For the three stages of the payment channel, we evaluated the time consumed in each stage. In the zk-APC scheme, each stage incurred significant time costs due to zero-knowledge proofs and time-bound verifiable commitments. Our measurement of time disregarded communication time. According to our measurements, the initiator needed 36.1 seconds for the payment channel establishment process. In the payment channel updating process, each update took 31.5 s. Compared to similar Zcash shielded transactions with 6.6 tps, if our scheme was used, the transaction throughput per second could be increased to 0.032D tps, where D is the number of channels opened on the blockchain. If there are 10,000 payment channels open on the blockchain, our scheme can provide a transaction throughput of 32 tps per second.

8. Conclusions

In this paper, we proposed a zk-SNARKs-based anonymous payment channel, which solves the privacy problem during off-chain transactions between payers and payees through utilizing commitment schemes, zk-SNARKs, and timed verifiable commitments. Specifically, our approach achieves on-chain and off-chain amount privacy during payment channel transactions and unlinkable relationships between payers and payees, while ensuring the fairness of the transaction process. In this paper, we provided a concrete construction of the zk-SNARKs-based anonymous payment channel and performed security analysis and experimental verification.