Zk-SNARKs-Based Anonymous Payment Channel in Blockchain

: Payment channels serve as an effective solution to the scalability problem of cryptocur-rencies, 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 cryp-tocurrencies 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.


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 Sections 6 and 7 discuss related issues and analyze the performance.Section 8 concludes the paper.

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.

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.

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 Π = (Setup, KeyGen, Prove, Verify), specifically expressed as: 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 π of the bounded prover, this shows that the prover recognizes the witness w of the given instance.For each PPT adversary A, there is a PPT witness extractor E , namely: Zero-knowledge property: honestly generated proofs are perfectly zero-knowledge, since a poly(λ)-size simulator S exists such that, for all stateful poly(λ)-size delimiters D, the following two probabilities are equal:

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.

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.

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.

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.

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 λ, we will generate the public parameter pp z using the initialization algorithm in zk-SNARKs.Then, the KenGen algorithm in zk-SNARKs is used to generate a key pair (pk zi , vk zi ) for each specific circuit C i required for zk-APC.These circuits are C Mint , C SetSend , C U pdate and C Trans f er , 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 pp BLS of the BLS signature algorithm and the relevant public parameter pp 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.Compute the public-private key pair (pk zi , vk zi ) = zk-SNARKs.KenGen(C i ) 5: end for 6: Set PK z = (pk zMint , pk zSetSend , pk zU pdate , pk zTrans f er ) VK z = (vk zMint , vk zSetSend , vk zU pdate , vk zTrans f er ) 7: Compute pp BLS = BLS.Setup(1 λ ) 8: Choose a suitable prime order N and corresponding cyclic group G, and choose a suitable generator g.Set pp DLG = (N,G,g) 9: Output pp = {pp z , PK z , VK z , pp BLS , pp DLG }

Algorithm 1 Initialization Algorithm
The detailed procedure of Algorithm 1 is shown above.

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 pk 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 tx Mint , facilitating the conversion of a designated amount of plaintext currency into zero-knowledge currency.The minting transaction tx Mint associated with user P i 's public address pk i comprises the following variables: • Address pk 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 cm i : the commitment scheme COMM generates a fresh zeroknowledge currency commitment value.This commitment value encapsulates the hidden components, including the address pk i , value v i , the newly generated random number r i , and a unique string sn 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 Mint : (1) • Signature σ Mint :User P i signs the above (π Mint , cm i ,v i ) with private key sk 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 pk i Output: A zero-knowledge currency c i and a mint transaction tx Mint 1: Randomly sample a random number r i 2: Compute a new serial number sn i = PRF(sk i , r i ) 3: Compute a new commitment cm i = COMM(pk i , v i , sn i , r i ) 4: Set the information that needs to be disclosed to generate a zero-knowledge proof x : = (cm i , v i , pk i ) and hidden evidence w : = (sn i , sk i , r i ) 5: Compute π Mint = zk-SNARKs.GenProof(pk zMint , x, w) 6: Set zero-knowledge currency c i : = (cm i ,pk i ,v i ,sn i ,r i ) 7: Set m : = (π Mint , cm i , v i ) 8: Generate a signature on m using private key sk i σ Mint = BLS.Sign(m, sk i ) 9: Set tx Mint : = (m, pk i , σ Mint ) 10: Output zero-knowledge currency c i and mint transaction tx Mint

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 tx 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 tx SetSend transaction contains the following variables：

•
Merkle tree root rt: This is the proof that the commitment cm old i exists in the ledger; • Commitment serial number sn old i : A unique string associated with the commitment cm old i .

•
Commitment value cm pc : This value is generated by the commitment scheme COMM, and the content implied in the commitment includes the Payer's address pk i , the Payee's address pk j , the transferred value v i , commitment serial number sn old i , and the serial number sn pc i associated with this commitment value generated by the PRF function and discrete logarithmic value Y.

•
Zero-knowledge proof π SetSend : This zero-knowledge proof is a proof generated by zk-SNARKs.GenProof that the following conditions apply to the circuit of C SetSend : (1) cm old i = COMM(pk i , v i , sn old i , r old i ) (2) sn old i = PRF(sk i , r old i ) (3) cm pc = COMM(pk i , pk j , v i , sn old i , sn pc i , Y) (4) sn pc = PRF(pk i , r new ) (5) The path path i from cm old i 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 path i , Zero-knowledge currency c old i and address pk j Output: Zero-knowledge currency c pc and payment channel establishment transactions tx SetSend 1: Parse c pc i :=(cm old i , pk i , v i , sn old i , r old i , sk i ) 2: Randomly sample a random number r new and compute serial number sn pc = PRF(pk i , r new ) 3: Compute the new commitment cm pc = COMM(pk i , pk j , v i , sn old i , sn pc , Y) 4: Set c pc : = (cm pc , pk i , pk j , v i , sn old i , sn pc , Y, r new ) 5: Set the information that needs to be disclosed to generate a zero-knowledge proof x : = (rt,cm pc ,sn old i ) 6: Set hidden evidence w : = (path i , cm old i , pk i , pk j , v i ,sn pc , r old i , r new , sk i , Y) 7: Compute π SetSend = zk-SNARKs.GenProof(pk zSetSend , x, w) 8: Set tx SetSend : = (rt, cm pc , sn old i , π SetSend ) 9: Output zero-knowledge currency c pc and payment channel establishment transactions tx 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 mod N (where g and N are public parameters).Concurrently, P j generates a verifiable timed commitment (C VTD , π VTD ) = VTD.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 VTD.Verify(Y, C VTD , π VTD ).Meanwhile, P i begins running VTD.ForceOp(C i ) 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 cm 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 .

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 tx U pdate .The tx U pdate transaction contains the following variables：

•
Merkle tree root rt: the proof that the commitment cm pc exists in the ledger; • Serial numbers sn pc : strings associated with commitment commitment cm pc ; • Commitment values cm new i and cm new j : these are also generated by the commitment scheme COMM.The contents implicit in the cm new i commitment are the address pk i , the address pk j , the explicit value v new i , serial number sn new i associated with this commitment value generated by the PRF function, and the serial number sn pc ; the contents implicit in the cm new j commitment are the address pk i , the address pk j , the explicit value v new j , serial number sn new j associated with this commitment value generated by the PRF function, and the serial number sn pc ; • Address pk i : the address of the payer; • Zero-knowledge proof π Update : this zero-knowledge proof is a proof generated by zk-SNARKs.GenProof, which is suitable for the circuit of C Update .
(1) cm pc = COMM(pk j , pk j , v old , sn old , sn pc , Y) The path path from cm pc to the rt saved on the ledger is correct 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 new j and the payment channel update transaction tx U pdate to the payee P j .Upon receiving this information, the payee P j first verifies the correctness of the signature σ U pdate included in the payment channel update transaction tx U pdate .Subsequently, utilizing the secret value y, they perform the complete payment channel update transaction tx U pdate .Following this process, the payee P j has the capability to close the payment channel at any time.

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 tx U pdate , 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 tx Trans f er that transfers the zero-knowledge currency c old j received by the payee P j to a new address pk new j , where the tx Trans f er transaction consists of the following variables:

•
Merkle tree root rt: This is the proof that the commitment cm old j exists in the ledger; • Commitment serial number sn old j : A unique string associated with the commitment cm old j ; • Commitment value cm new j : This value is generated by the commitment scheme COMM, and the content implied in the commitment includes the address pk new j , the transferred value v j , new random numbers r new j , and the serial number sn new j associated with this commitment value generated by the PRF function; • Address pk j : the address of user P j ; • Zero-knowledge proof π Transfer : this zero-knowledge proof is a proof generated by zk-SNARKs.GenProof that the following conditions apply to the circuit of C Transfer : (1) cm old j =COMM(pk i , pk j , v j , sn pc , sn old j , Y) (2) sn old j =PRF(pk j , r old j ) (3) cm new j =COMM(pk new j , v j , r new j , sn new j ) (4) sn new j =PRF(sk new j , r new j ) (5) The path path j from cm old j to the rt saved on the ledger is correct • Signature σ Transfer :Signature of the above (π Transfer , rt, cm new j , sn old j ) using the payment channel private key sk j .

Algorithm 5 Transfer Algorithm
Input: The public parameter list pp, c old j , Merkle tree root rt and path path j , public key pk j of P j , new public key pk new j of P j and new private key sk new j of P j Output: New zero-knowledge currency c new j ,transfer transaction tx Transfer 1: Parse c old j := (cm old j , pk i , pk j , v j , sn pc , sn old j , r old j ) 2: Select new random number r new := (cm new j , pk new j , v j , sn new j , r new j , sk new j ) 5: Set the information that needs to be disclosed to generate a zero-knowledge proof x: = (rt, cm new j , pk j , sn old j , ) 6: Set hidden evidence w: = ( path j , cm old j , pk i , pk new j , v j , sn pc , sn new j , r old j , r new j , sk new j ) 7: Compute π = zk-SNARKs.GenProof(pk zTransfer ,x, w) 8: Set m := (π Transfer , rt, cm new j , sn old j ) 9: User P i uses private key sk j to generate signature σ Transfer =BLS.Sign(m, sk j ) for m.The detailed procedure of transfer algorithm is shown above.

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 GU L.
We abstract the blockchain network within the payment channel as an oracle X , providing an interface to interact with the operations defined in zk-APC.The blockchain ledger L that stores and manages all transactions is overseen by X .Assume a probabilistic polynomial-time adversary A capable of querying X during the game GU L. X responds to each query with L until A submits a transaction tuple (tx, tx * ) ∈ L satisfying conditions (a) tx and tx * being of the same type, i.e., all three transaction types mentioned earlier, (b) tx ̸ = tx * , and (c) A are not involved in either tx or tx * .If one of the following holds: (a) for payment channel establishment transactions, both tx and tx * involve the same sender and receiver; (b) for payment channel updating transactions or transfer-transactions, tx and tx * involve the same sender and recipient; or (c) for payment channel renewal transactions or transfer-transactions, and tx * do not involve the same recipient, X outputs 1, indicating that A has won the game GU L. Consequently, we can formalize the following proposition: Theorem 1.The zk-APC scheme preserves transaction unlinkability because, for any probabilistic polynomial time adversary A, the following probability is negligible under security parameter λ: Proof.(a) Assume that A outputs a tuple of payment channel establishment transactions (tx SetSend ,tx ′ SetSend ) where tx SetSend satisfies that and tx SetSend ′ satisfies that To win the game GU L experiment, A finds a set of transactions (tx SetSend , tx ′ SetSend ) for which the receiver pk j = pk ′ j and the sender pk i = pk ′ i .To achieve the goal of finding identical receivers, A can determine whether pk j and pk ′ j are equal in two ways: (a) Obtaining the recipient's address pk j (or pk ′ j ) from cm pc ( or cm pc′ ).(b) Extracting pk j (or pk ′ j ) from zk-SNARK proof π SetSend (or π ′ SetSend ).For (a) A must distinguish the (pk j ,pk ′ j ) contained in (cm pc ,cm pc′ ) without knowing the secret values of the (cm pc ,cm pc′ ), which would imply that the hidden nature of the COMM is destroyed, something which corresponds to A is impractical.For (b), since 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, A can also determine it in three ways: (a) distinguishing sender addresses from the zk-SNARKs proof; (b) A initially, searching for commitment values (cm old i , cm old i ′ ) 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 cm pc or (cm pc′ ).
For mode (a), A has to distinguish (pk i ,pk i ′ ) from the different zero-knowledge proofs (π SetSend ,π ′ SetSend ), which implies that mathcal A needs to destroy the zero-knowledge property of zk-SNARK.
For (2) zk-SNARK proof.For method (1), A needs to extract (cm old i , cm old i ′ ) from the Merkle tree root (rt, rt ′ ), requiring a breach in the collision-resistant hash (CRH) property.For method (2), A must extract (cm old i , cm old i ′ ) from the zk-SNARKs proof (π SetSend , π ′ SetSend ), 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 sender and receiver of a transaction cannot be distinguished in a tx SetSend transaction.
(b) Assume that A outputs a tuple of (tx Update ,tx To win the GU L experiment, A must identify a set of transactions (tx U pdate , tx ′ U pdate ) with the recipient pk j = pk ′ j .To achieve this goal, A can also make determinations through two methods:   ).
For (a), A must distinguish (pk j , pk ′ j ) from different zero-knowledge proofs (π Update , π ′ Update ), which implies that 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 tx U pdate 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.

Experiment and the
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.

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 ALT 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, U pdate, and Trans f er 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.

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, U pdate, and Trans f er 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 U pdate 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 Trans f er 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.   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, U pdate, and Trans f er are similar to Blockmaze's Deposit.zk-APC's Mint, SetSend, U pdate, and Trans f er are akin to Zerocash's Pour, and zk-APC's Mint is comparable to DMC's Deposit.zk-APC's SetSend and Trans f er are analogous to DMC's OpenChannel, and zk-APC's U pdate is similar to DMC's O f f chainTrans f er.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, U pdate, Trans f er, and Deposit, U pdate and Trans f er 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, U pdate, and Trans f er 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 U pdate circuit.Compared to DMC, our SetSend circuit corresponding to DMC's OpenChannel, Trans f er to DMC's OpenChannel, and U pdate to DMC's O f f chainTrans f er 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 Block-Maze, Zerocash, and DMC, zk-APC exhibited notable efficiency in the computational and storage costs of various zero-knowledge proof operations.

Payment Channel Performance Evaluation
Comparison with DMC.Table 1 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 onchain 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.

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.

Input:
Safety parameter λ Output: The list of public parameters pp 1: Compute pp z = zk-SNARKs.SetUp(1 λ ) 2: for all i ∈(Mint, SetSend, Update, Transfer) do 3: Construct the circuit C i corresponding to the required 4:

j) 3 :) 4 :
and compute serial number sn new j = PRF(sk new j , r new j Compute new commitment value cm new j = COMM(v j , pk new j , sn new j , r new j Set c new j

10 :
Set tx Transfer := (m, pk j , σ Transfer ) 11: Output zero-knowledge currency c new j ,transfer transaction tx Transfer (a) Distinguishing the recipient's address from the zk-SNARKs proofs.(b) Discerning the recipient's address from cm new j , cm new i (cm new j ), and (cm new ′ i
1 λ ): Input a security parameter λ, 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) ← KeyGen(C): Input a mathematical operation circuit 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 verifica-An honest generated proof π has O λ (1) bits, verifying that Verify(vk, x, π) runs at time O λ (|x|).(Here, O λ hides a fixed polynomial factor in λ) The public parameter list pp, c pc , Merkle tree root rt, path path, Private key sk i owned by P i , plaintext values v new Parse c pc :=(cm pc , pk j , pk i , v old , sn old , sn pc , Y, r old ) 2: Compute the random numbers r new Update = zk-SNARKs.GenProof (pk zUpdate ,x, w) 8: Set m = (rt, π U pdate , cm new j , cm new BLS.Sign(m, sk i ) is generated for message m using the private key sk i .10: Set tx Update = (m, pk i , σ U pdate ) 6:Set hidden evidence w :=(path, cm pc , pk j , v old , v 7: Compute π i , sn pc , Y)9:The signature σ U pdate = j and tx U pdate .
method (b), A can differentiate the sender (pk i , pk i ′ U pdate ), where tx Update satisfies that tx Update = (rt, π Update , cm new , sn pc , Y, σ U pdate ) cm pc = COMM pk j , pk i , v old , sn old , sn pc , Y 7.2.2.Comparison with Blockmzae, Zerocash, and DMC Figure

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