Hyperledger Fabric and zkRolup-based voucher payment infrastructure system

Abstract

The invention belongs to the technical field of zero knowledge proof and block chains, and particularly relates to a block chain transaction system infrastructure capable of generating certificates based on a Hyperledger Fabric alliance chain and zkSNARK. The system comprises a user account module, a transaction processing module and a block chain module. The user account module provides account-related registration and login, transaction anonymous authentication and balance management functions. The transaction processing module provides functions of transaction initiation packaging, query and voucher generation for successful transactions; and the block chain module is responsible for the verification of batch transactions and the storage of account information. According to the method and the system, the defects of low efficiency, poor transaction privacy protection characteristic and poor energy-saving performance of a traditional block chain transaction system at present are overcome in a centralized manner, the transaction privacy of the user is ensured, zero transaction cost and relatively high operation efficiency are ensured, and a credential generation service is finally provided for multiple upper-layer applications as a trust anchor point.

Description

Technical Field

[0001] The present invention provides a blockchain transaction system infrastructure capable of generating vouchers based on a Hyperledger Fabric alliance chain and zkSNARK, and belongs to the technical field of blockchain and zero-knowledge proof encryption. Background Art

[0002] The so-called payment voucher refers to a document or bill that can be used to find or authenticate the entries recorded in the ledger. In other words, it is a guarantee of the legitimacy of the account. Paper currency, digital payment vouchers such as WeChat and Alipay, and blockchain cryptocurrencies all fall into the category of payment vouchers, which is enough to show that voucher payment has become the most mainstream payment method at present.

[0003] The two key factors of voucher payment are trust structure and usage advantages. The trust structure ensures its security and trustworthiness, and the usage advantages provide meaning for its circulation and use. Each generation of voucher payment has excellent usage advantages that the previous generation of payment vouchers do not have on the basis of security guaranteed by a reasonably designed trust structure. For example, paper vouchers are far superior to ancient metal coins in portability, and digital payments are far superior to paper voucher payments in convenience and ease. Blockchain and blockchain cryptocurrency vouchers and transaction systems are emerging vouchers and voucher transaction systems. Compared with the previous generation of WeChat, Alipay and other electronic voucher payment methods, the trust structure has been revolutionized from centralized institutional guarantees to decentralized mechanism guarantees. Therefore, it has obtained the usage advantages of decentralization and non-tamperability, and has received widespread attention. Since Satoshi Nakamoto published a paper in 2008 and formally proposed the concept of blockchain, blockchain technology has developed rapidly and expanded its application scale and scope in just a few decades, thanks to the usage advantages and value of blockchain transaction system vouchers. In particular, the paper "Next Generation Smart Contracts and Decentralized Application Platforms" published by Vitalik Buterin in 2013 formally introduced the script written in Turing complete language - smart contracts into the blockchain system, leading blockchain technology from simple programmable currency to programmable finance and programmable society, to meet the needs of many financial and market areas for decentralized and tamper-proof features. The expansion of demand and scale represents the broad prospects and unlimited possibilities for the further development and application of blockchain technology.

[0004] However, with the booming development of blockchain, many urgent problems in public chain certificate transactions are becoming increasingly acute: on the one hand, the trust structure and usage advantages of blockchain certificates such as cryptocurrencies are decentralized and cannot be tampered with, which shows that the blockchain certificate transaction system still has a lot of room for application expansion, and can use the advantages of decentralized trust structure to radiate more usage advantages rather than just limited to the trust structure itself; on the other hand, in the design of the blockchain system itself, due to the strict verification required by the consensus protocol, a large number of transactions sent by users are queued in the system every second in the traditional blockchain system waiting to be verified and packaged by new legal blocks. In comparison, the real centralized credit card system or transaction system has obvious advantages in transaction throughput. According to statistics, the average transaction volume of VISA is about 24,000 per second, and the domestic transaction system Tmall set a peak reception record of 256,000 transactions per second during the Double Eleven period in 2017. All of the above are enough to prove that with the increase in system scale and transaction demand, the bottlenecks in block capacity, processing speed and verification speed have jointly restricted the development of existing blockchain transaction systems. On the other hand, for security reasons and the need for consensus protocol supervision, the data on the blockchain system is open, transparent and visible to everyone, which casts a shadow on privacy protection. Although traditional blockchain systems use user public key addresses rather than real names as the identity representation, public key addresses are used multiple times for different transactions or multiple times to transfer money to a specific address. Attackers can infer the actual user identity behind the public key address through network analysis, transaction graphs, etc.

[0005] Zero-knowledge proof was first formally proposed by Goldwasser et al. in a paper in 1985. In the more than 30 years of development, zero-knowledge proof has gone through the process from interactive zero-knowledge proof to non-interactive zero-knowledge proof (NIZK), to succinct non-interactive zero-knowledge proof (zkSNARK), and then to the transparently initiated succinct non-interactive zero-knowledge proof (zkSTARK) that appeared in recent years. Nowadays, various zero-knowledge proof protocols have emerged in an endless stream. These protocols have achieved different effects by combining different cryptographic primitives. For example, the two famous zkSNARK protocols Groth16 and PLONK that appeared in recent years are constructed through KZG polynomial commitment + Fiat Shamir transformation. Although these two zkSNARK protocols have a more cumbersome protocol trusted startup process compared to many other types of zero-knowledge proof protocols, they have the fastest proof verification speed and the smallest proof size that other zero-knowledge proof protocols do not have. In recent years, the design of secure and trusted startup processes has also achieved certain results. For example, the Power-of-Tau trusted startup protocol uses a multi-party secure computing (MPC) method to generate the global parameters of zkSNARK, which ensures that as long as one of the participants is honest, the security of the protocol can be guaranteed. In the field of blockchain privacy protection, zero-knowledge proof is widely used because of its inherent advantage of not leaking any information. The cryptocurrency ZeroCash, which was born in 2016, is a currency that uses zkSNARK from beginning to end to achieve user anonymity and privacy throughout the transaction. Although the performance and practicality of the system are not as good as the mainstream co-existing system, its theoretical significance and the application of zero-knowledge proof technology make it a theoretical benchmark. Therefore, zkSNARK technology is the only choice for achieving fast proof and privacy protection. In fact, many blockchain layer 2 expansion plans have begun to use zero-knowledge proof zkRollup technology to expand the blockchain system, that is, the functions of the blockchain execution layer and even part of the data availability layer, such as the verification of most transactions such as signature verification, are placed on the layer 2 server, and a zero-knowledge proof is provided to the blockchain when sending packaged transactions. After the zero-knowledge proof is verified on the chain, it can be believed that all transactions are legal and the blocks are safely expanded to the end of the main chain. This alleviates the execution pressure and storage pressure of the blockchain system and improves the overall efficiency of the system.

[0006] Hyperledger Fabric is a consortium chain framework created by the Linux Foundation in 2015. The main differences between Hyperledger Fabric and other blockchain systems are as follows: (1) All organizations participating in the consortium, including their users, are registered and authenticated through the member service provider (MSP) to ensure the access and security of the consortium; (2) Hyperledger Fabric innovatively provides the channel function, and related nodes can achieve the isolation of transaction data between organizations by jointly creating a private channel to ensure the privacy of transactions; (3) It adopts a practical Byzantine fault-tolerant consensus protocol, so it has the characteristic of fast consensus speed. Summary of the invention

[0007] In view of the many advantages of zkRollup and Fabric technologies introduced in the background technology, such as efficiency, privacy protection, and energy saving, the present invention combines the zkRollup technology implemented by zkSNARK with the Hyperledger Fabric alliance chain technology, in order to realize a certificate trading system that has high throughput and high efficiency on the basis of excellent privacy protection characteristics and energy saving. These characteristics are exactly what most public chain certificate trading systems currently do not have, thereby broadening the advantages of blockchain certificate use. Afterwards, according to the design plan, a certificate trading system infrastructure is fully implemented to provide services for a variety of upper-level applications including but not limited to transfer systems. In summary, it is: successfully creating a certificate trading system that combines the two technologies, which has excellent performance in many aspects and can provide services for a variety of upper-level applications. The specific research content is as follows:

[0008] (1) Design and code writing of zero-knowledge proof for batch transaction verification: Circuit code is the core of generating zero-knowledge proof. Based on the design goal of verifying batch state transfer of the voucher trading system and its pursuit of efficiency, the present invention explores and designs a new circuit for generating zkSNARK zero-knowledge proof, so as to obtain higher verification performance on the basis of sacrificing the decentralized nature to a certain extent. The present invention intends to use circom+snarkjs to implement circuit writing and generate zero-knowledge proof.

[0009] (2) Selection of zkSNARK protocols and parameters: Based on the implemented circuit, the compatibility of two zkSNARK zero-knowledge proof protocols (PLONK and Groth16) with the solution was explored. The multiple system resource consumption indicators of the two protocols for generating zero-knowledge proofs were tested under different numbers of packaged transactions, and the zkSNARK protocol and number of packages with the strongest system adaptability and the best performance were selected after comprehensive evaluation to obtain the theoretical maximum average throughput of the system. The present invention also compares the system operation efficiency and the results of multi-faceted performance evaluation with the existing blockchain transaction system to provide feasibility and data support for the implementation of the voucher system.

[0010] (3) Architecture design of the voucher trading system: Based on the generated zero-knowledge proof, explore and design an overall architecture of the voucher trading system to enable the layer2 server loaded with the zero-knowledge proof generation code to perform stable and usable interactive verification with the verification code on Fabric, thereby realizing batch transaction processing of zkRollup+Fabric.

[0011] (4) Overall implementation and performance evaluation of the voucher trading system: Based on the designed architecture and the zero-knowledge proof generated under the optimal combination of protocol + package number, the front-end and back-end of the voucher trading system are fully implemented. This will achieve the expected goal and create a zkRollup+Fabric voucher trading system with privacy protection, strong security, energy saving and high efficiency.

[0012] The implementation of the solution includes the following core algorithms and structural designs:

[0013] 1. Ordinary user registration algorithm process:

[0014] Before registering, users need to use the public and private key generation tool integrated in the front end of this system or generate the public and private key EdSK for Ed25519 signature locally through the OpenSSL tool. User and EdPK User , then use Password as the signature content, sign it with the private key, and then you can use Password, EdPK User ,EdSign User Sent together to the server for signature verification, that is Ed mentioned in the above code verifierIt is a code package that generates true or false as output according to the legitimacy of the signature and is used to implement Ed25519 signature verification. It is used as a functional component in this system to implement digital signature verification and is also the core component for generating Ed25519 signatures integrated by the front end. Finally, the endpoint server in the process calls the on-chain contract to send the important information of the generated user account to Fabric, and generates an account with an initial balance of 0 on the chain.

[0015] 2. Organize the user registration algorithm process:

[0016] In addition to providing an Ed25519 signature, the registration of organizational users also requires an additional certificate or certificate chain PemCerts_Org and an ECSign signed with the private key corresponding to the public key in the certificate. The registration of organizational users is more complicated in verification than the registration of ordinary users. This is mainly because organizational users have more operating permissions and functional identities in the system than ordinary users. If they are not restricted, identity forgery or abuse of permissions may occur. The process is mainly divided into three parts of verification, namely, on-chain certificate existence verification for organizations that wish to become endpoint organizations, certificate or certificate chain legitimacy verification, additional ECDSA signature verification, and organization Ed25519 signature verification. They are explained one by one below:

[0017] (1) First, the system authenticates the user who intends to register the system as an endpoint organization by determining whether there is a folder with the same name as the input organization name Username in the Fabric organization folder, and then taking out the X.509 certificate or certificate chain stored therein and the PemCerts input by the function. Org A comparison is performed. If they are exactly the same, the organization is considered to have been admitted to the channel as an endpoint organization. Otherwise, the organization's registration will be rejected.

[0018] (2) After that, the system checks the PemCerts provided by the organization. Org The validity of the certificate chain is verified to determine whether the organization's certificate is legitimate.

[0019] (3) Finally, additional signature verification is performed, using ECDSA and Ed25519 to sign the organization's registered password, ensuring the homogeneity of system registration while resisting certificate replay attacks, and signing the organization's own certificate PemCert Org Wait for the chain to create an account, which is similar to the process for ordinary users.

[0020] 3. Design of voucher structure:

[0021] The design and generation process of the voucher involves the core of the voucher trading system, which aims to ensure the effectiveness of the voucher while resisting various malicious behaviors including replay attacks, forgery attacks, etc. The system's structure and field design of the voucher are as follows:

[0022] Fields meaning <![CDATA[From Id ]]> Transaction initiator ID From_Name Username of the transaction initiator <![CDATA[To Id ]]> Transaction initiator ID To_Name Username of the transaction initiator Amount Transfer amount TimeStamp Transaction initiation time Comment Transaction Message transactionId The transaction is also the unique ID of the voucher digest SHA256 summary of transaction information FromPK Public key of the transaction initiator <![CDATA[From Sig ]]> The transaction initiator's signature on the Ed25519 digest <![CDATA[Server Pem ]]> The certificate of the endpoint server that processes the transaction <![CDATA[Server Sig ]]> Endpoint server signature on transaction digest

[0023] The fields in the entire voucher structure can be divided into two parts. The upper part is the voucher transaction details Trans Info The lower part indicates the legitimacy of the credential transaction, including the SHA256 summary of the first part of the transaction information and the signature and public key of the initiator and verifier (server) for the summary. In this way, the credential generated by any transaction in the system can guarantee multiple aspects of security and credibility. The security properties it can protect are as follows:

[0024] (1) Anti-counterfeiting: First, the anti-counterfeiting of the certificate is guaranteed by the anti-counterfeiting of the digital signature introduced above. The method of using both the server and the user to sign the certificate can prevent either party from forging the certificate signature. The signature of the transaction information summary indicates that both parties confirm that the transaction information is legal and correct.

[0025] (2) Tamper-proof: Secondly, the credentials designed by the scheme can effectively prevent attackers from tampering with the credentials. Since there is a SHA256 hash of the signed transaction information field as the summary of the transaction, and the signatures of the initiator and the verifier on the credentials are both performed on this summary, once the summary is tampered with and changed, it is equivalent to the signed message has changed, and the verification of all credential signatures will fail, and the credential can be easily verified to be invalid. Trying to modify the signed transaction information without changing the transaction summary is equivalent to artificially creating a hash collision. This behavior is itself a very difficult problem for the SHA256 hash algorithm with collision resistance. Therefore, the tamper-proofness of the credential is jointly guaranteed by the transaction summary and the signature.

[0026] (3) Anti-replay attack: The anti-replay feature of the credential is mainly protected by the timestamp field and the transaction ID field. Unlike a simple signature, the credential has a timestamp field that records the time when the transaction was generated. The timestamp can contribute to the anti-tampering feature on the one hand, and more importantly, it can prevent replay. This is mainly because receiving multiple credentials with exactly the same timestamps and signatures in a short period of time will easily arouse suspicion and further verification. In addition, the application party can freely specify the validity period for internal use of the credentials generated by this system, that is, after how long the timestamp written in the credential has passed, the credential will be considered expired in the upper-level application and lose its effectiveness. On the other hand, since one transaction corresponds to one credential, the transactionId field can better guarantee the anti-replay feature, especially for some occasions where the credential can only be used once.

[0027] 4. Ordinary transaction initiation process:

[0028] Ordinary transactions account for the majority of the total transactions in the system. When a user initiates a transaction, in addition to providing transaction-related information, he or she also needs to provide some encryption materials related to generating credentials, including a digest of basic transaction information, the user's signature on the transaction digest, and the user's public key, etc., which can be described as After that, the server verifies the transaction information and authentication information sent by the user in multiple aspects, including: verifying whether the transaction initiation timestamp is too long ago, whether the transaction amount is non-zero, whether the correct summary of the transaction information is generated, and whether the summary is correctly signed with ED25519. The process can be described as follows:

[0029] Trans Info .Timestamp, Trans Info .Amount

[0030]

[0031] 5. Special transaction initiation process:

[0032] Special transactions in the system refer to the user's top-up and withdrawal operations, which involve financial organizations outside the system and are the source of tokens and value in the system. Special transactions and ordinary transactions are basically the same in the process of users preparing transaction materials, but there are a few special points that need to be explained:

[0033] (1) For recharge transactions, in addition to checking the basic transaction information sent by the user as in ordinary transactions, it is also necessary to call the API provided by the financial organization to query the balance of the user's account in the financial organization to ensure that there is sufficient balance to complete the recharge transaction.

[0034] (2) Different from the ordinary transaction process, which requires the transaction amount to be guaranteed to be Amount>0, the recharge transaction requires Amount<0, and the withdrawal transaction requires Amount>0. This ensures that the system can homogenize the verification of all types of transactions when performing zero-knowledge proof verification on packaged transactions. On the other hand, the initiation process of recharge and withdrawal transactions does not involve the transfer of actual amounts into or out of the system. It is only a process of retaining legal records in the system. The transfer of actual amounts into and out of the system needs to wait for the completion of the packaged transaction verification. Only after the transaction is truly confirmed to be correct can the API of the financial organization be called for processing. This is logically equivalent to the processing method of ordinary transactions.

[0035] 6. Design of zero-knowledge proof circuit:

[0036] Circuit design is the core of generating and using zero-knowledge proof. The signal output Out of the circuit designed by the present invention is a Boolean value representing whether the packaged transaction is legal. As for the input, there are mainly the following ones. Assume that the number of transactions in a packaged transaction is m:

[0037] (1) user_ids: The IDs of all initiators and targets involved in a packaged transaction, which is an int array. Considering the unknown total number of all users involved in the packaged transaction, this uncertainty comes from the fact that any two transactions in the packaged transaction may involve exactly the same or completely different users, or may overlap partially. Unlike some high-level languages ​​with good dynamics that can dynamically specify the size of the array data structure, the input signal of the circuit needs to have a clear number. Therefore, the size of the user_ids array is set to 2m, because for m transactions, a maximum of 2m different users are involved. For the part less than 2m, user IDs that cannot exist in the system, such as -1, 0 or other values, can be used to fill.

[0038] (2) init_state: represents the account balance status value of all users involved in the transaction before the package transaction occurs. Its type is an array of int type. Like the user_ids array, init_state also needs to have an array size of 2m, and its most critical design is that for the user with user id user_ids[i], its account balance Balance should be equal to init_state[i], that is,

[0039] User user_ids[i] .Balance == init_state[i]

[0040] On the one hand, such a design is because the circuit cannot implement efficient corresponding search using data structures such as Map hash tables in high-level languages, so index queries can only be designed manually. On the other hand, such a design also ensures the convenience of queries during the verification process.

[0041] (3) final_state: indicates the final state value of the account balance of all users involved in transactions in the system after the package transaction occurs. Its design is similar to init_state and also has:

[0042] User user_ids[i] .Balance == final_state[i]

[0043] (4) transactions: A three-dimensional array of size m×2×3 representing batch transactions. The meaning of each dimension is as follows: Since there are m transactions in total, the first dimension means that each transaction in the package is represented as a 2×3 two-dimensional matrix; the two-dimensional matrix composed of the second and third dimensions represents each transaction, where the first and second rows respectively represent the change in the account balance of the payee and payer after the transaction. The first element of each row represents the user id, the second element represents the index position idx of the user id in the user_ids and status arrays, and the third element represents the balance change. Take the following matrix as an example:

[0044]

[0045] It means that the transaction initiator with id 17 transferred 500 tokens to the user with id 23, where the index positions of the two parties in the user_ids array are 0 and 1 respectively. When the balance state is transferred, the balance value in the state array is updated according to the index position provided in the second column of each row, and finally the state transfer result after the completion of a single transaction is generated.

[0046] In addition, the circuit has two intermediate signals in the state update process, which are used to receive the results of intermediate calculations, namely:

[0047] (5) median_state: A two-dimensional array used to receive the intermediate results after each transaction state transfer. Its size is m×2m. For the i-th transaction, the intermediate result array (length 2m) of its state transfer is written into median_state[i]. Then the array represented by median_state[i] is written into the single transfer circuit as the input of the next transaction state transfer. Finally, the one-dimensional array represented by median_state[m-1] is the final state of the m packaged transactions. This design has a large space complexity, specifically reaching O(n 2), but due to the poor dynamics of the circom circuit, it is not possible to repeatedly input different values ​​for the same signal, which makes it impossible to use algorithmic methods such as state compression or dynamic programming.

[0048] (6) compare_result: An array of length 2m used to compare median_state[m-1] and final_state. Each position is 0 or 1, which represents that the values ​​at the corresponding positions of the two arrays are unequal or equal, respectively.

[0049] On this basis, the four main modules of the verification circuit are given according to the signal flow order:

[0050] (1) batchtransaction circuit module: the outer scheduling center of the entire circuit and the output circuit of the final result. For the i-th transaction, the 2×3 matrix of the transaction and the current intermediate state are handed over to the transaction module for calculation, and the result is written into the intermediate result and then fed back to the transaction module. Finally, the generated final state is compared with the input final_state to see if they are completely consistent. The last step of the multiple AND operation is actually also implemented by a circuit. Due to space constraints, its code is not presented here. The process calculates each state transition in the packaged transaction and compares the final state with the declared final state to achieve the legitimacy of the state transfer verification.

[0051] (2) Transaction single state transfer circuit: The single state transfer circuit is the core of the verification process. The input of the circuit template function is:

[0052] user_ids,temp,median_state

[0053] For the input 2×3 transaction matrix temp, the first verification that needs to be done is:

[0054] user_ids[temp[0][1]]==temp[0][0],

[0055] user_ids[temp[1][1]]==temp[1][0]

[0056] That is, the ids in the user ids represented by the declared transaction initiator and target index are the same as the declared transaction initiator and target ids. Then the balances of both parties in the current state of the input can be updated according to the index position:

[0057] median_state[temp[0][1]]+=temp[0][2],

[0058] median_state[temp[1][1]]+=temp[1][2]

[0059] The difficulty in implementing these two steps is that the circom circuit does not allow the input signal of one circuit to be used as the index of the input signal of another array, which will cause a Non Quadratic error. Unfortunately, both of the above steps involve this situation, so the selectarrayelement module needs to be used here to handle it.

[0060] (3) selectarrayelement select index element circuit: the key circuit to realize the state transfer circuit. Here, we take the position and specific id of the element corresponding to the index of the transaction initiator in user_ids as an example. The process realizes index search by generating a mask array with only the value 1 at the target index. The way to generate the target id is to multiply and add the elements in user_ids with the corresponding elements in the mask array from_mask one by one. The target id is finally generated. The same method can be used to update the specified position of the balance status array. The core operation of the process can be described as:

[0061]

[0062] (4) IsEqual judgment circuit: It is mainly used to judge whether two elements are equal. It is used in the modules mentioned above.

[0063] The circuit design diagram is as follows Figure 1 shown.

[0064] 7. Trusted startup algorithm process:

[0065] In the zkSNARK-type zero-knowledge proof protocol, the generation of global parameters has always been a thorny issue, the most important of which is the treatment of toxic waste τ. The Powers-Of-Tau protocol is a scheme that uses multi-party secure computing to perform a trusted startup ceremony to generate global parameters. For the i-th participant, the global parameter gp is generated. i The process is as follows:

[0066]

[0067] 8. Batch transaction generation and verification algorithm:

[0068] The first is the process of generating a packaged transaction. Before generating a packaged transaction, the credential system endpoint server Server i All received transactions will be stored in a Server in the order of arrival iQueue in the exclusive Redis secondary queue. When the number of transactions in the queue reaches the number of packaged transactions, take out the transactions in the head of the queue and start a package. Generate the required input of the circuit according to the circuit described in 6: transactions, init_state, final_state, user_ids. Each transaction in the batch contains the initiator id: from and the receiver id: to and the transfer amount amount. After that, the secondary queue will hand over this packaged data structure as a task to the Redis primary queue. At this time, the secondary queue will subscribe to the successful verification custom event of the primary queue and wait for the verification to succeed. When verifying the packaged transaction, the primary queue takes out a package from the head of the queue each time, and assembles the transactions, init_state, final_state, and user_ids into an object as the input signal. Use circom+snarkjs to generate commit_f, π, and Eval(C) for verification and send it to Fabric. The on-chain smart contract also uses the api provided by snarkjs to verify these proofs. If Fabric feedbacks that the verification is successful, the primary queue sends a successful verification custom event, otherwise it publishes a failed custom event. The event subscribers of the secondary queue perform subsequent database updates and credential generation operations based on the success or failure of the published events.

[0069] 9. Credential generation and acquisition process:

[0070] After receiving the event message about the successful verification of the packaged transaction from the first-level queue, the second-level queue marks all transactions in the current package as VERIFIED, and then signs each transaction summary with the private key corresponding to the ECDSA public key in its own certificate and writes the certificate and signature to the database field of the corresponding transaction, and updates the balance of all transactions recorded in the database to the final state. After the above process is completed, the status of all packaged transactions can be updated to SETTLED, indicating that all packaged transactions have been successfully executed.

[0071] When the user needs to obtain the credentials, all they need to do is package all the fields and send the Base64-encoded result to the user:

[0072] BRIEF DESCRIPTION OF THE DRAWINGS

[0073] Figure 1 Circuit design diagram for verifying zero-knowledge proof for batch transactions in the system

[0074] Figure 2 The figure shows the overall model of the scheme.

[0075] Figure 3The figure shows the overall system architecture.

[0076] Figure 4 This is a timing diagram of the system User module.

[0077] Figure 5 It is a timing diagram of the system Transaction module. DETAILED DESCRIPTION

[0078] According to the above scheme, the architecture design and layering of the voucher trading system are as follows:

[0079] (1) Application layer: The application layer is the front end of the voucher trading system, which provides a visual interface for ordinary users and organizational users to directly access the system and interact with the resources in the system. The main functions of the application layer front end are mainly two aspects: one is to provide users with a good interactive experience, design a clear and intuitive display of account data and various transaction function buttons, and the data returned by the back end should be organized and presented to the user in a well-organized manner; the other is to correctly send the user's request to the back end through the interface provided by the back end endpoint server to realize the update and query of account data and the sending and query of transactions. This system uses React to implement the interface and functions of the front end application.

[0080] (2) Service provider layer: The service provider layer is the backend application of the voucher trading system. It is the hub of data transmission and the main provider of functions for the voucher trading system. For this system using zkRollup, the service provider layer is the layer 2 of the system, and its importance in the overall system architecture design is self-evident. The main responsibilities of the service provider layer are as follows.

[0081] 1. Implement the main functions of the system through various defined methods, including organization and general account management, registration and login authentication, transaction sending and query, etc.

[0082] 2. Implement security requirements in the design of credential trading systems by configuring security policies such as tokens and https and implementing signature verification algorithm functions and certificate verification algorithms.

[0083] 3. Configure database-related functions and interfaces to ensure that off-chain transaction records and user records can be correctly stored and authenticated, and that credentials can be correctly generated for each transaction.

[0084] 4. Be able to correctly interact with the Fabric chaincode deployed in the chaincode layer. In addition to updating the information contract of the on-chain account to ensure the system's tamper-proof requirements, the interaction with the zero-knowledge proof verification chaincode also requires the server to implement a secondary queue and communicate with the primary queue on the Fabric running server in the contract layer to ensure that transactions that arrive quickly at the server can be buffered in the secondary queue and enter the primary queue as a single packaged transaction task for queuing, achieving a balance between high-speed user transaction requests and relatively slow zero-knowledge proof verification.

[0085] In addition, the service provider layer can also deploy multiple endpoint servers to represent multiple organizations, and deploy queues between the application layer and the service provider layer through message queue technologies such as RabbitMQ, Kaftka, etc., to achieve uniform load of transaction requests in the system and improve the concurrency performance of the system.

[0086] This system intends to select the Nodejs framework NestJS as the tool for system backend development. First of all, Nodejs is a runtime of the javascript language, which ensures that the javascript language can be separated from the browser and obtain the ability to write backend programs from a simple web scripting language. And because the javascript language embraces the characteristics of asynchronous programming, its running process is non-blocking, which is very suitable for processing heavy I / O application scenarios. The most important role of this is to ensure the user experience when accessing heavy I / O applications, which provides motivation for using Nodejs to write this system. Second, Fabric inherently provides SDK for Nodejs, which is convenient for using Nodejs to achieve connection with Fabric blockchain and chain code through the gRPC protocol, which provides feasibility for using Nodejs to write this voucher trading system. Third, the mature backend application framework NestJs provided by the Nodejs community implements a SpringBoot-like AOP framework by encapsulating the Nodejs classic backend framework Express, and uses typeseript with strict type constraints instead of javascript for code writing, making it possible to use Nodejs to establish convenient and clear modular controllers and service methods.

[0087] Therefore, the system chooses to use NestJs to develop the service provider layer, and according to the requirements and system goals, the system functions and implementations are introduced in the following text from the perspective of the two main functional modules designed in NestJs of this system: User and Transaction.

[0088] (3) Consensus layer: The consensus layer mainly includes the infrastructure necessary for the consensus protocol and the content deployed on the Fabric chain after the consensus protocol. In this credential system, it is specifically the chain code and CA authentication facilities on Fabric. Its main purpose is to store data on the chain and ensure that various transactions involving chain-data structures can be tamper-proof through the consensus protocol. Taking the CA public key infrastructure as an example, it ensures that all organizations entering the Fabric alliance have a legitimate CA authentication certificate to identify their identity, providing a basis and basis for the consensus process of the admission judgment of new organizations by the organizations that have joined the alliance. As for the chain code itself, it must run the consensus protocol before it can be deployed on the chain, and all transaction-related methods written in it must be verified by all members of the alliance before they can modify the state data stored on the chain. Therefore, whether it is the chain code or the CA infrastructure in the consensus layer, its essential function is to provide the lower-level applications with a way to modify and access the state stored in the chain database and blockchain on the basis of ensuring the consensus protocol. The chain code of the credential system is also written in Nodejs, which ensures the homogeneity of the on-chain and off-chain code types.

[0089] (4) Storage layer: As the name implies, the storage layer includes all the ways to store data in the system. Since this system architecture is designed as layer 2 to expand the layer 1 blockchain, one of its main expansion directions is the expansion of the storage layer. Therefore, the MySQL database serving the service layer endpoint server has become the main means of expanding the LevelDB state database used by the blockchain. Most of the user account status data is transferred to MySQL for storage, and only the most important relevant data of each account is retained in LevelDB to ensure account security and tamper-proof characteristics while reducing on-chain storage pressure and protecting user privacy. This design is in line with the application scenario of zero-knowledge proof and is also intended to meet the design goals of the system.

[0090] Therefore, the application layer and service layer development of the present invention are based on this machine, using the Windows 10 operating system, the processor is 11th Gen Intel (R) Core (TM) i7-11800H @ 2.30GHz, and the memory is 64GB. In terms of front-end development, the React framework is used, wherein the Nodejs version is v18.15.0, the npm version is 8.11.0, the React version is 18.2.0, the Axios version is 1.4.0, the ant-design version is 5.7.2, and the @noble / ed25519 package version is 2.0.0 for implementing the Ed25519 signature function, and accessing the front-end page through the Chorome browser. In terms of back-end development, the NestJs framework is selected, and the version is v9.0.0. The back-end service is bound to listen on port 8080, and the MySQL8.0.33 database service is started. The back-end application is connected to the MySQL database, the business data is stored in the database, and the blockchain service is connected through gRPC. The consensus layer and storage layer build the Hyperledger Fabric blockchain. According to the recommendations and best practices of the official documentation of Hyperledger Fabric, the Hyperledger Fabric blockchain is built on the latest long-term support version Ubuntu22.04.2LTS. The Fabric version used is v2.5.2, and the various components in the Fabric network are started through Docker Compose, including 3 peer nodes and 1 orderer node. In order to ensure performance and stability, a 4-core CPU and 16GB memory are configured for the virtual system. Redis v6.0.16 is used to implement the packaging and sending of two-level queue processing transactions. In addition, for the test and stress test in the simulated environment, Alibaba Cloud is used as the cloud server provider, and the general-purpose g7 elastic computing server ecs.g7.4xlarge is rented. Its specific specifications are 16vCPU with a main frequency of 2.7GHz and a turbo frequency of 3.5GHz, and 64GB of memory, also on the Ubuntu 22.04.2LTS system. During the construction process, Docker24.0.4 and Docker Compose v2.19.1 are used to manage containers. The overall system model and architecture are as follows Figure 2 , Figure 3 shown.

[0091] From the perspective of the usage functions of the voucher payment system of the present invention, it can be mainly divided into two key modules, namely the User module responsible for user login, registration and account information management and the Transaction module responsible for transaction processing. The timing diagram of the two modules is shown in FIG. Figure 4 , Figure 5As shown, the specific functions of the module are as follows.

[0092] 1. User module: The User module mainly implements the user registration and login functions, while ensuring the maintenance of the user's personal and balance information. The meanings of the main fields involved in the User module are shown in the following table:

[0093]

[0094]

[0095] On this basis, the more important Service methods used in the User module and their input and return values ​​are as follows. All the methods mentioned here are marked as asynchronous methods with async, so the return values ​​of all methods are the Promise type unique to JavaScript to ensure the non-blocking characteristics of the system:

[0096] createUser(user:UserRegisterDto): Promise <number>:

[0097] The method for creating a normal user account takes the UserRegisterDto type introduced in the previous section as the input type. The method verifies the signature provided in the input parameter, and after passing the signature, it calls the contract layer chaincode in sequence to generate a new account and create a new entry in the User table of the Mysql database, and returns the id of the created new entry to the controller. If any of the above steps go wrong, an exception will be thrown.

[0098] createOrgUser(orgUser:OrgRegisterDto): Promise <number>:

[0099] The method for creating an organization user account uses the OrgRegisterDto type introduced in the previous section. The method verifies all signature materials and certificates provided in the input parameters. If they pass, the contract layer chain code is called in sequence to generate a new account and create new entries in the User table and Organization table of the MySQL database. Otherwise, an exception will be thrown.

[0100] checkUser(userInfo: CheckUserLoginDto): Promise <userinfodto>:

[0101] Due to the login verification method, the input parameter CheckUserLoginDto requires password and at least one of username, phone, and email for login verification. The returned UserInfoDto type contains all fields except type, which is used by the front end to display user information and issue login tokens.

[0102] findAllCommercial():Promise<OrganizationDto[]> :

[0103] The method to search for all financial organizations is mainly used for users to select the way to recharge or withdraw money from all financial organizations when they want to initiate a recharge or withdrawal transaction. The method return value OrganizationDto contains the organization's orgId in the Organization table of the database, the id in the User table, and the name of the organization.

[0104] getUserInfo(id:number):Promise <userinfodto>:

[0105] A method to query a specified user's information, that is, input the user ID and return UserInfoDto containing the user information

[0106] updateUserInfo(id: number, update: UpdateUserInfoDto): Promise <userinfodto>:

[0107] The method for updating account information is only used to update some personal information of the user and not to update authentication fields such as public key and balance fields. Therefore, the input parameter type UpdateUserInfoDto is a data structure after removing the fields id, type, balance, publicKey, access_token, etc. to ensure that these fields cannot be modified by this method. The process of updating the account balance uses the proprietary method in the Transaction module.

[0108] deleteUser(id:number):Promise <boolean>:

[0109] The method used to cancel a user's account. First, call the DeleteAccount method in the Fabric chain code according to the submitted ID to clear the account data on the chain. After success, clear the authentication fields such as publicKey, pemCert and the balance field balance, retain some personal information fields for evidence storage, and finally set alive to 0 and type to DELETED to complete the account cancellation.

[0110] One point that needs to be emphasized is that in the above methods, updateUserInfo and deleteUser require the user to carry the token returned by the service provider server when logging in to authenticate the identity when sending the request, otherwise the request will be intercepted and rejected by Contoller. Figure 4 This is also reflected in the process of updating accounts in the flowchart.

[0111] 2.Transaction module:

[0112] The Transaction module is mainly responsible for processing transactions sent by users, including transaction packaging, queuing, event processing, signature and voucher generation, and transaction information maintenance. It also needs to update the user account status in time when the transaction succeeds or fails. The main fields involved in the module are shown in the following table:

[0113]

[0114] For the transaction statuses listed in the table, the enumeration values ​​are:

[0115] LAUNCHED = 0, / / transaction initiated

[0116] QUEUEING = 1, / / queueing in the secondary queue

[0117] VERIFYING = 2, / / Sent to the first-level queue for verification

[0118] VERIFIED = 3, / / Verification successful

[0119] SETTLED = 4, / / All status updates are successful, transaction completed

[0120] FAILED = 5, / / Verification failed

[0121] For the transaction types listed in the table, the enumeration values ​​are:

[0122] NORMAL = 0, / / normal transaction

[0123] DEPOSIT = 1, / / deposit transaction

[0124] WITHDRAW = 2, / / Withdrawal transaction

[0125] Some of the service methods involved in the Transaction module are as follows. Like in the User module, all methods are marked as asynchronous methods using async:

[0126] createNormalTrans(transaction:CreateTransactionDto):Promise <number>:

[0127] The method for creating a normal transaction, where the input parameter type CreateTransactionDto includes the transaction information part, namely from, to, amount, initTime, comment, digest, fromSignature. The return value is the created transaction id. The method first verifies whether the transaction amount is compliant and whether it is less than 0, and then determines whether the initiator's account balance is sufficient and whether the transaction timestamp is too long ago. After all the verifications are successful, it will verify whether the signature of the digest in the input parameter is legal, and finally write the transaction to the transaction table in the LAUNCHED state and add it to the secondary queue as NORMAL type. The process for recharge and withdrawal transactions is similar to that of ordinary transactions. In addition to the content introduced in the data flow section of this section, there are a few points that the transaction amount of the recharge transaction must be less than 0, which is also mentioned in the previous algorithm process design 5. Finally, the type written to the queue and transaction table should be the corresponding DEPOSIT or WITHDRAW.

[0128] findAllMyTrans(id:number):Promise<TransactionDto[]> :

[0129] A method for querying all transactions in which the user is involved. Involved means that no matter whether the user represented by the input id participates in the transaction as the initiator or the receiver, the transaction will be included in the result array. The return value array element type TransactionDto contains all transaction information fields except digest, as well as the transaction state, type, id, and the user name in the user table corresponding to the initiator and receiver id.

[0130] updateTransBalances(userIds: number[], finalBalances: number[], serverSignature): {id: number, signature: string}[]): Promise <number>:

[0131] This method is used to update the transaction status and server signature after the batch transaction verification is passed. It will be called after the secondary queue receives the verification success message. Since the update involves the account balance and two database entities, the input parameters are relatively complex. First, the userIds array and the finalBalances array are the ids and final balance status of the users involved in the batch transaction generated in the packaged transaction. They correspond one to one in the index, which can easily complete the update of the User table. The serverSignature is the output of the serverSignVouchers method. Its type is an array. The array element type is a transaction id corresponding to a signature generated for the transaction, which makes it very convenient to update the Transaction table. This method returns a number type to record the number of users affected by the update operation. Since the updates to the database in this method are all one-time updates of multiple fields, all update operations will be performed in the form of database transactions.

[0132] generateVoucher(id:number):Promise <string>:

[0133] For a given transaction ID, obtain all its transaction information and signature information, merge them into an object, and convert its KSON string into a Base64 format string and return it to the user

[0134] serverSignVouchers(transDigests: {id: number, digest: string}[]): Promise<{id: number, signature: string}[]>:

[0135] The endpoint server's method for batch signing transactions is to first read the locally stored private key file in pem format for the input batch transaction ID and digest, and then use the encryption library jsrsasign to perform ECDSA signatures on all digests one by one.

[0136] handleTransaction(job:Job):Promise <void>:

[0137] The task processing method in the secondary Bull queue takes the Job type as the task type defined by the Bull queue, which contains the transaction information added to the queue. The processing logic for queue tasks is that before a transaction enters the function, it is in the wait queue, and the task status entering the processing function is active, and when the function is completed, the task enters the completed queue. Therefore, the voucher system designs this method to detect the number of tasks in the completed queue. When the number of transactions is reached, the transactions at the head of the queue are dequeued and packaged to the primary queue, and a listening function is set to listen to the events of the primary queue. All this series of work is completed in this method.

[0138] successEventListener(uuid):Promise <void>:

[0139] The listener function that listens to the verification success event in the secondary Bull queue has the following operation logic: once the primary queue publishes the event of successful verification, all subscribers who listen to the event will receive the message and run the listener function. Therefore, it is very important for the listener to identify whether the successfully verified packaged transaction is the one sent to the primary queue when the verification success event occurs, because only in this way can the transaction be updated correctly. Therefore, the secondary queue will send a generated uuid string with the packaged transaction to identify the packaged transaction, and the primary queue will send this uuid together when publishing the verification success event. When each listener function is called, it will detect whether its own uuid is the same as the published one. If it is different, no processing will be done. If it is the same, other methods of the Transaction module will be called to update the data in the system, and finally the listeners for the success and failure events will be canceled at the same time to prevent too many subscribers from listening to the event as the system runs and calling it at the same time when the event occurs, affecting the system's operating performance. It is worth mentioning that uuid is a random sequence generated by a hash function that resists hash collision, such as SHA256. Considering that the number of listeners existing in the system at the same time is not large after the timely cancellation mechanism, and the hash function with collision resistance has a very large hash result space, the possibility of two packaged transactions with the same uuid existing in the system at the same time can be regarded as negligible.

[0140] failEventListener(uuid):Promise <void>:

[0141] The logic is similar to successEventListener, but it is called when the package transaction verification represented by this subscriber fails.

[0142] handleVerification(job:Job):Promise <void>:

[0143] The task processing method in the first-level Bull queue mainly takes out several proof materials of the zero-knowledge proof of the packaged transaction stored in the arrived task and inputs them as input parameters into the Fabric chain code method zkVerifier for verification, waits for the verification result, and finally publishes the event of successful verification or failed verification according to the result.

[0144] After the system was completed, we first tested the Groth16 protocol in a virtual machine environment to find that it was more suitable for this system. Then we further conducted point testing and stress testing on transactions with different numbers of packages in a Groth16 system in a cloud server environment. The test results are shown in the following tables:

[0145] First, the results of the buried point test:

[0146] Number of packages Cloud Server Environment Virtual Machine Environment 8 3.48 2.55 16 6.55 4.19 32 11.05 5.59 64 14.04 4.71 128 10.86 4.04

[0147] It can be seen that the cloud server environment has higher transaction processing performance than the virtual machine environment due to its higher computing and read / write performance. At the same time, 32-trace and 64-trace packages are the package numbers with better system performance.

[0148] In view of the above results, we further conducted stress tests on the system using Groth16+32 and 64 packaged transactions. The test method was to submit transactions to the system at a speed of 50ms and 10ms. Each test was conducted three times. In each experiment, a total of 1024 transactions were submitted and the system's processing of transactions was observed. The test results are shown in the following table:

[0149]

[0150]

[0151] First of all, for all the tests presented above, the transactions sent were successfully executed and became SETTLED, which means that the system can withstand the input pressure of 100 transactions per second and 20 transactions per second. In terms of throughput, the average throughput of 32 and 64 packages during the stress test was 10.37 and 11.64, which was generally maintained above 10TPS. On the other hand, the test results further illustrate that Groth16+64 packages per batch are the optimal combination for the adaptation system design. And combined with the analysis in the previous chapter, it can be considered that the system throughput is between 11-14TPS.

[0152] In summary, from the perspective of theoretical research, this paper obtains detailed data through performance testing and analyzes the experimental results for different zkSNARK zero-knowledge proof protocols PLONK and Groth16, and then selects the Groth16 protocol with the best system adaptability and the best performance from an empirical perspective.

[0153] From the perspective of architecture, the present invention designs a complete two-layer blockchain credential transaction system architecture, which ensures the security and privacy of users while enjoying the convenience brought by the expansion of layer1 blockchain by layer2 through multiple signature methods, and realizes the packaging and verification of zkRollup batch transactions by providing zero-knowledge proof to layer1 to improve the operation efficiency. The speed mismatch between the endpoint server and the zero-knowledge proof verification chain code on the Fabric chain is balanced by innovatively designing a secondary queue.

[0154] From the application perspective, the voucher trading system proposed in the present invention can serve as the infrastructure for a variety of upper-level applications, including but not limited to the generation of vouchers for ordinary transfer payment systems, the issuance of volunteer service certificates, the generation and issuance of membership cards for various commercial entities and shopping institutions, the generation of contracts or IOUs, etc. The essence of the realization of these applications on this system is that the voucher system designed in this article has good tamper-proof and security.< / void> < / void> < / void> < / void> < / string> < / number> < / number> < / boolean> < / userinfodto> < / userinfodto> < / userinfodto> < / number> < / number>

Claims

1. A computer-readable storage medium having a computer program (instructions) stored thereon, characterized in that: When the program (instructions) is executed by the processor, the following steps are implemented: (1) The user enters the necessary transaction information, including the sender and receiver IDs, transaction amount, and transaction message (remarks), and generates a SHA256 transaction digest and the user's private key's ED25519 signature algorithm signature on the transaction digest based on this information; (2) The transaction initiated in (1) is transferred to the Redis secondary queue for queuing and waiting for transaction packaging; (3) After the program waits for the queue described in (2) to reach the set number of transactions, it takes out the set number of transactions at the head of the queue and packages them, generates a Groth16 zero-knowledge proof as a summary of the legitimacy of the batch transaction state transfer, and transfers it to the Redis primary queue to wait for verification (4) The program connects to the corresponding peer node on the Fabric consortium chain through gRPC, takes out the zero-knowledge proof of the first batch transaction at the head of the first-level Redis queue, and uses it as the input of the Fabric verification legitimacy chaincode method to verify the legitimacy of the transaction transfer; (5) After the chain code method that verifies the transaction returns a success message after successful verification, the transaction summary of each transaction in the program batch transaction is signed by the ECDSA signature algorithm; (6) After (5), the account balance status and transaction status of all users involved in the batch transaction can be updated to indicate that the transaction has been completed; (7) The program outputs a certificate of successful transaction. The certificate includes the names and IDs of the two parties to the transaction, the transaction amount, the transaction time, the transaction message, the transaction summary, the public key of the transaction initiator and its ED25519 signature on the transaction summary, and the X.509 certificate of the transaction processor and its ECDSA signature on the transaction summary. Users can obtain the certificate and use it for voucher payment.

2. A computer-readable storage medium having a computer program (instructions) stored thereon, characterized in that: When the program (instruction) is executed by the processor, steps (3) and (4) of the method described in claim 1 are implemented, namely, the verification process of batch transactions, which is also the content of the generated zero-knowledge proof. The specific steps are: (1) Input the ID array set of all users involved in the batch transaction, the initial balance state array of the accounts involved before the batch transaction occurs, the final expected state array after the transaction occurs, and the three-dimensional array representing the batch transaction into the circom verification circuit template, where each transaction in the three-dimensional array is represented by a two-dimensional matrix element, which records the IDs of the sender and receiver, the index number in the input ID array, and the changes in the account balances of the sender and receiver after the transaction occurs; (2) The program executes a loop, taking the current state (the initial state of the first transaction) and the currently queried transaction as inputs to the template function for obtaining the account balance state result after a single transaction, and performing verification and state transfer on the single transaction; (3) Iterate the process in (2), gradually verify each transaction and use the transaction result as the input of the next iteration call, and finally obtain the final result of the batch transaction; (4) Compare the result calculated in (3) with the final expected state array after the batch transaction input in (1). If they are completely consistent, the transaction can be determined to be legal.

3. A computer-readable storage medium having a computer program (instructions) stored thereon, characterized in that: When the program (instructions) is executed by a processor, it can output the credential structure and function described in step 7 of the method according to claim 1.

4. A computer-readable storage medium having a computer program (instructions) stored thereon, characterized in that: When the program (instruction) is executed by the processor, the steps in claim 1 are performed to process packaged transactions, and the throughput of processing packaged transactions is 10-15 TPS.

Images