A blockchain-based conditionally secure large-scale multi-party payment system and method

Abstract

The application discloses a kind of based on blockchain condition security large-scale multi-party payment system, including a probability polynomial time algorithm tuple CCAP=(Gen, Enroll, Agg, Execute, Vrf, Ext);The based on blockchain condition security large-scale multi-party payment method, specifically includes the following steps: step one: registration of buyer and seller;Step two: verifying the identity of buyer user;Step three: buyer user sends transaction request;Step four: verifier verifies transaction;Step five: punishment mechanism of double-spend attack.The technical effect of the application is that the buyer user and the seller user can ensure the safety of the transaction, ensure the smooth progress of the transaction, and can execute the punishment measures, which has a deterrent effect on double-spend attack.The multi-party secure payment system execution efficiency will increase slowly with the increase of the number of users participating in the transaction, so the scheme is suitable for large payment application environment.

Description

Technical Field

[0001] The invention relates to the technical field of deterministic aggregate signature methods, specifically to a large-scale multi-party payment system and method based on blockchain conditional security. Background Technology

[0002] With the continuous advancement and improvement of global digital technology, digital transaction technology has become a future development trend. Large-scale digital transactions can be widely used in all aspects of daily life, including financial security, healthcare, and business forecasting. For example, banks can identify abnormal financial transaction behavior by analyzing users' historical transaction records. Once abnormal behavior is detected, banks can promptly stop transactions, effectively reducing the occurrence of financial fraud and developers absconding with funds. E-commerce companies such as Alibaba and JD.com use big data analytics to improve user experience and optimize product recommendations based on users' browser-related digital transaction records. Another application area of ​​digital transactions is artificial intelligence. On the one hand, it can improve data management and enable the mining of privacy information during digital transactions; on the other hand, it can handle the storage capacity and massive computing power required for large-scale digital transactions.

[0003] The combination of blockchain and digital transaction technology is of great significance. Blockchain can organize complex records of data across the entire network, and this data meets the 5Vs of big data—large capacity, high speed, diversity, authenticity, and high value. Therefore, blockchain-based digital transactions can serve as a data source for large-scale data transaction payment systems. Furthermore, due to its transparency and ease of public access, blockchain-based data transaction processing is also well-suited for artificial intelligence processing.

[0004] Blockchain is a decentralized ledger technology that uses cryptography. Its data structure is public and transparent, writable but immutable, meaning anyone can publish new transactions on the chain, and the data is equal for all honest nodes. Because of its decentralized and transparent characteristics, blockchain can be applied to many areas, efficiently solving trust issues without the need for a trusted third party. Blockchain can be applied to various fields, such as value storage and data storage. The most significant application is on-chain transactions, where peer-to-peer transactions can be completed quickly on the blockchain with extremely low transaction fees, attracting a large number of users.

[0005] However, due to the transparency of blockchain, these transactions present serious privacy issues. If these privacy issues are not resolved, blockchain cannot be widely applied in digital transaction processes.

[0006] Furthermore, as the amount of data increases, blockchain networks become increasingly congested, transaction costs rise, and transaction success rates decline. This problem severely limits the further large-scale application of blockchain-based digital transactions.

[0007] Existing multi-party payment systems are not secure enough, failing to simultaneously meet security requirements such as integrity, anonymity, authentication, traceability, and fairness. Some multi-party payment systems also suffer from low performance, with their performance significantly decreasing as the number of users increases, making them unsuitable for large-scale application scenarios. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of the prior art and provide a large-scale multi-party payment system and method based on blockchain security. This system aims to enhance transaction security, improve data load capacity, and add a penalty mechanism. Under the premise of meeting the security requirements of large-scale transactions, it exposes the privacy information of malicious users to punish their misconduct.

[0009] To achieve the above objectives, the invention provides the following technical solution: a large-scale multi-party payment system based on blockchain conditional security, comprising a probabilistic multinomial time algorithm tuple CCAP = (Gen, Enroll, Agg, Execute, Vrf, Ext);

[0010] The CCAP = (Gen, Enroll, Agg, Execute, Vrf, Ext) specifically includes:

[0011] CAPP.Gen(1 κ →pp: Input safety parameter κ, the algorithm outputs global parameter pp, which contains a p-order group G = <g>and three hash functions H com H agg H sig {0, 1} * →{0,1} l ;

[0012] CAPP.Enroll(pp) → (pk i ,sk i ): Input the pre-determined global parameter pp, and randomly select a private key. Then an authoritative institution calculates the corresponding public key. The algorithm generates a public-private key pair (pk) for each party involved in the transaction. i ,sk i );

[0013] Buyer user P i Calculate a hash value t i =H com (R i P i Select And calculated Then the calculation results are sent to other users P in the transaction. j When all other users P in the transaction j After receiving the results, P i Verify t i =H com (R i Does P hold true? If so, then... i calculate R can be obtained from the aggregator; then P i For message m = (x, p), calculate s i =r i +c·p·a i ·sk i mod q, where x is the transaction amount, p is other information that needs to be signed; finally, the buyer user P i Put σ i =(s i R i ) and the corresponding proof π i Send to other users in the transaction;

[0014] Input a given public key set L = {pk1, ..., pk} n The aggregator calculates a. i =H agg (pk i ,L), and Then, an aggregated public key is calculated using this. And R; this algorithm outputs the aggregated public key. R and the corresponding aggregate signature

[0015] Given a message m = (x, p), a public key set L = {pk1, ..., pk} n } and the corresponding signature Nodes in a blockchain first calculate Then through calculation Verify whether the signature is valid. If the signature is valid, this algorithm outputs 1; otherwise, it outputs 0.

[0016] If a double-spending attack occurs, it means that there are two aggregate signatures corresponding to the collision messages m1 = (x, p1) and m2 = (x, p2). All of this can be achieved through calculation. s i1 =r i +c·p1·a i ·sk i and s i2 =r i +c·p2·a i ·sk i To further obtain the private key of the malicious user who launched this double-spending attack.

[0017] This blockchain-based, conditionally secure, large-scale multi-party payment method specifically includes the following steps:

[0018] Step 1: Registration of Buyers and Sellers: Before the transaction, both buyers and sellers must register with an authoritative institution and obtain certificate information.

[0019] Step Two: Verify Buyer User Identity: Buyer User P i First select And calculated Then P i Calculate a hash value t i =H com (R i ); P i The calculation result t i and R i Send to other users P in the transaction j When all other users P in the transaction j After receiving all the results, verify t. i =H com (R i If the equation is true, the system proceeds to step three; otherwise, the transaction is aborted.

[0020] Step 3: Buyer user sends transaction request: Buyer user P i First calculate Where R and It can be obtained from the aggregator, and then from the buyer user P. i For message m = (x, p), calculate s i =r i +c·p·a i ·sk i modq, where x is the transaction amount, p is other information that needs to be signed, and finally, the buyer user P. i Put σ i =(s i R i ) and the corresponding proof π i Send it to the other parties in the transaction, and the other parties verify the proof π. i Once effective, the seller user P will be... i Signature σ i The aggregated signature of this transaction is generated after aggregation. Send to the verifier;

[0021] Step 4: Verifier verifies the transaction: The verifier knows the message m = (x, p) and a public key set L = {pk1, ..., pk}. n } and the corresponding signature To verify the signature, the verifier first calculates... Then through calculation Verify the validity of the signature. If the signature is valid, the verifier writes the transaction into the blockchain, and the transaction is completed. Otherwise, the transaction is aborted. If a double-spending attack is detected, the system executes step five.

[0022] Step 5: Penalty Mechanism for Double-Spending Attacks: If a double-spending attack occurs, then for the same transaction amount, there are two colliding transaction messages m1 = (x, p1) and m2 = (x, p2), and the aggregate signatures corresponding to these two colliding messages are also specified. In this way, everyone can perform local calculations using transparent data on the blockchain to obtain the private keys of malicious users, thereby enabling the implementation of punitive measures against accounts that commit double-spending attacks.

[0023] Preferably, the certificate information mentioned in step one includes information for user P. i Public and private key pairs for transactions (pk i ,sk i The transaction requires a hash function and global parameter information, including the public key pk. i This is the account address used by the user to receive transfers and is valid indefinitely.

[0024] Preferably, the registration of both buyers and sellers in step one specifically includes:

[0025] The authoritative body first initializes the system's security parameters k based on system scale, service requirements, and security considerations; then, based on the current security parameters, the authoritative body calculates the system's security parameters k according to the algorithm CAPP.Gen(1). κ →pp generates global parameters for computation, including a p-order group G = <g>and three hash functions H com H agg H sig {0, 1} * →{0,1} l These three hash functions take a 0-1 bit string of arbitrary length as input and output a 0-1 bit string of length l. The security of this system depends on the difficult problems of computing the Diffie-Hellman problem and determining the Diffie-Hellman problem.

[0026] When there is a user P i When issuing an account registration request, the authoritative organization uses pre-determined global parameters and user P's... i Selected private key According to the algorithm CAPP.Enroll(pp) → (pk) i ,sk i ) Calculate and generate the corresponding public key This public-private key pair (pk i ,sk i ) will be used for user P i Subsequent transaction activities, including public key PK i Will be used as P i Long-term account address.

[0027] Preferably, step two, which verifies the buyer's user identity, specifically includes:

[0028] Before each transaction, buyer user P i First, select temporary parameters that meet the system requirements. Calculate locally on the client Meanwhile, user P i The local client is performing a hash function determined by an authoritative body, inputting the R calculated in the previous step. i Calculate the hash value t i =H com (R i Pack these two results together (R) i , t i ) Sent to other parties in the transaction P j The safety of this step depends on the difficulty of the discrete logarithm problem, given R. i There is no probabilistic multinomial-time algorithm that can obtain r. i ;

[0029] Other parties in the transaction P j Received a message from the buyer user (R) i , t i After that, t' is also calculated on the local client. i =H com (R i ), verify t' i =t i Whether it is true or not, in order to verify buyer user P i Is the user a legitimate registered user in the system? If this step verifies the user's identity, the transaction continues; otherwise, the transaction is terminated.

[0030] Preferably, step three, whereby the buyer sends a transaction request, specifically includes:

[0031] Before formally generating the transaction request, determine the public key set L = {pk1, ..., pk} of each party to the transaction. n } and temporary parameter information R of the parties to the transaction i ;Use the aggregator according to the algorithm First, calculate a. i =H agg (pk i (L), and then aggregate the public key set to obtain Temporary parameter information R i Aggregation This aggregator generates Both R and P will be used as buyer users. i Generate a transaction request;

[0032] Generated using the above aggregator And R, buyer user P i This step formally generates the transaction request; buyer user P i First, calculate the hash value on the local client. The hash value c contains account information, temporary parameter information, and transaction amount information for all parties involved in the transaction; then, for transaction information m = (x, p), the buyer user P... i Client-side local computation s i =r i +c·p·a i ·sk i mod q, where r i Buyer user P i The temporary parameters are: c is the hash value just calculated containing the account information of all parties involved in the transaction, the temporary parameter information, and the transaction amount information; p is other information that needs to be signed; a... i Buyer user P i public key pk i The public key set of all parties involved in the transaction is used as the input hash value, sk i For buyer user P i The private key, q, is a global parameter of the system. This step is a key step to achieve system traceability and resistance to double-spending attacks.

[0033] Buyer user P i Package the above client-generated results into a signature σ. i =(s i R i And using the ZK-SNARK zero-knowledge proof method, the signature σ is... i =(s i R i Generate proof π i Then σ i and π i Send to all parties involved in the transaction;

[0034] When the parties to the transaction receive σ i Afterwards, the parties to the transaction first discussed the buyer user P. i Signature σ i And proof of π i The verification is performed; if the verification passes, the aggregator proceeds according to the algorithm. Calculate separately Combined with the aggregator generated above And R, generate the aggregate signature for this transaction. Send it to the verifier to verify the legitimacy of the transaction.

[0035] Preferably, the verifier's transaction verification in step four specifically includes:

[0036] The verifier knows the transaction information m = (x, p) and the public key set L = {pk1, ..., pk} of the parties to the transaction. n }, aggregate signature for this transaction Verification is performed; the verifier first repeatedly executes the aggregation algorithm. Calculated and R;

[0037] get After R, the verifier executes the algorithm. In this algorithm, the verifier first runs the system-defined global hash function to calculate the hash value. Generate a 01 bit string c of length l;

[0038] The verifier calculates Verify the validity of the signature. If the signature is valid, the verifier writes the transaction into the blockchain, and the transaction becomes effective. Otherwise, the transaction is terminated. If the transaction is found to be a double-spending attack, proceed to step five above.

[0039] Preferably, the penalty mechanism for double-spending attacks described in step five specifically includes:

[0040] When a double-spending attack occurs, the blockchain contains a pair of colliding messages m1 = (x, p1) and m2 = (x, p2), and a corresponding aggregate signature. First, this information is transparent to all users in the blockchain; therefore, all users can easily perform calculations using this data locally. This is achieved by first utilizing the system's aggregation algorithm. Any user can obtain the aggregated public key for this transaction. Aggregate temporary parameters R and aggregate signatures s;

[0041] Any user can obtain the aggregated public key for this transaction. After aggregating the temporary parameter R and the aggregate signature s, the hash function is first calculated to obtain... Then we obtain the s corresponding to the two aggregate signatures. i1 =r i +c·p1·a i ·sk i and s i2 =r i +c·p2·a i ·sk i At this point, the right side of the equation Since all of these are known quantities, the private key of this malicious user can be obtained. This penalty mechanism against double-spending attacks also satisfies the properties of existence (unforgeable) and dual signature (extractable).

[0042] Preferably, the ZK-SNARK zero-knowledge proof method specifically includes:

[0043] The specific algorithm for proving the validity of a transaction using the ZK-SNARK zero-knowledge proof method is as follows: ZK = (Gen, Prove, Verify), where R satisfies C ={(x, w)|C(x, w)=0};

[0044] use Let's describe the arithmetic circuit C. Since the arithmetic circuit of the transaction validator is fixed, the polynomial it generates is also fixed. First, the user inputs their own circuit C and the security parameter κ determined by the system based on security and performance requirements. Then, the ZK.Gen(κ, C) → (vk, pk) algorithm is executed: This algorithm returns a verification key vk and a proof key pk. This verification and proof key pair will be used later to generate proof π and verify the legality of proof π, respectively.

[0045] After obtaining the verification key vk and the proof key pk, the system can generate a proof based on the ZK.Prove(pk, st, ω)→π algorithm. After inputting the proof key pk, the statement st and the corresponding evidence ω, the algorithm outputs the proof π corresponding to the statement st.

[0046] The verification algorithm for this zero-knowledge proof method is ZK.Verify(vk, st, π) → {0, 1}. The input is the verification key vk, the statement st, and the corresponding proof π. If x∈L... C If a valid proof is found, the algorithm returns 1; otherwise, it returns 0.

[0047] Compared with existing technologies, the beneficial effects of the invention are:

[0048] 1. This large-scale multi-party payment system and method based on blockchain security ensures transaction security for both buyers and sellers, including integrity, anonymity, verifiability, traceability, and fairness. It guarantees smooth transactions without disclosing transaction privacy information, while also imposing penalties on malicious users and deterring double-spending attacks.

[0049] 2. This large-scale multi-party payment system and method based on blockchain security demonstrates that the execution efficiency of the multi-party secure payment system increases with the number of users participating in the transaction. This aligns with the analysis, as an increase in the number of users requires more time for signatures and proofs. The time cost of this system generally exhibits a linear relationship with the increase in the number of users participating in the transaction. Even in a large-scale user transaction system, its time cost remains relatively low, making it suitable for large-scale payment application environments. Detailed Implementation

[0050] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0051] This invention provides a large-scale multi-party payment system based on blockchain conditional security, comprising a probabilistic multinomial time algorithm tuple CCAP = (Gen, Enroll, Agg, Execute, Vrf, Ext);

[0052] The CCAP = (Gen, Enroll, Agg, Execute, Vrf, Ext) specifically includes:

[0053] CAPP.Gen(1 κ →pp: Input safety parameter κ, the algorithm outputs global parameter pp, which contains a p-order group G = <g>and three hash functions H com , × agg H si g: {0, 1} * →{0,1} l ;

[0054] CAPP.Enroll(pp) → (pk i ,sk i ): Input the pre-determined global parameter pp, and randomly select a private key. Then an authoritative institution calculates the corresponding public key. The algorithm generates a public-private key pair (pk) for each party involved in the transaction. i ,sk i );

[0055] Buyer user P i Calculate a hash value t i =H com (R i P i Select And calculated Then the calculation results are sent to other users P in the transaction. j When all other users P in the transaction j After receiving the results, P i Verify t i =H com (R i Does P hold true? If so, then... i calculate R can be obtained from the aggregator; then P i For message m = (x, p), calculate s i =r i +c·p·a i ·sk i mod q, where x is the transaction amount, p is other information that needs to be signed; finally, the buyer user P i Put σ i =(s i R i ) and the corresponding proof π i Send to other users in the transaction;

[0056] Input a given public key set L = {pk1, ..., pk} n The aggregator calculates a. i =H agg (pk i ,L), and Then, an aggregated public key is calculated using this. And R; this algorithm outputs the aggregated public key. R and the corresponding aggregate signature

[0057] Given a message m = (x, p), a public key set L = {pk1, ..., pk} n } and the corresponding signature Nodes in a blockchain first calculate Then through calculation Verify whether the signature is valid. If the signature is valid, this algorithm outputs 1; otherwise, it outputs 0.

[0058] If a double-spending attack occurs, it means that there are two aggregate signatures corresponding to the collision messages m1 = (x, p1) and m2 = (x, p2). All of this can be achieved through calculation. s i1 =r i +c·p1·a i ·sk i and s i2 =r i +c·p2·a i ·sk i To further obtain the private key of the malicious user who launched this double-spending attack.

[0059] This blockchain-based, conditionally secure, large-scale multi-party payment method specifically includes the following steps:

[0060] Step 1: Registration of Buyers and Sellers: Before the transaction, both buyers and sellers must register with an authoritative institution and obtain certificate information.

[0061] Step Two: Verify Buyer User Identity: Buyer User P i First select And calculated Then P i Calculate a hash value t i =H com (R i ); P i The calculation result t i and R i Send to other users P in the transaction j When all other users P in the transaction j After receiving all the results, verify t. i =H com (R i If the equation is true, the system proceeds to step three; otherwise, the transaction is aborted.

[0062] Step 3: Buyer user sends transaction request: Buyer user P i First calculate Where R and It can be obtained from the aggregator, and then from the buyer user P. i For message m = (x, p), calculate s i =r i +c·p·a i ·sk i modq, where x is the transaction amount, p is other information that needs to be signed, and finally, the buyer user P. i Put σ i =(s i R i ) and the corresponding proof π i Send it to the other parties in the transaction, and the other parties verify the proof π. i Once effective, the seller user P will be... i Signature σ i The aggregated signature of this transaction is generated after aggregation. Send to the verifier;

[0063] Step 4: Verifier verifies the transaction: The verifier knows the message m = (x, p) and a public key set L = {pk1, ..., pk}. n } and the corresponding signature To verify the signature, the verifier first calculates... Then through calculation Verify the validity of the signature. If the signature is valid, the verifier writes the transaction into the blockchain, and the transaction is completed. Otherwise, the transaction is aborted. If a double-spending attack is detected, the system executes step five.

[0064] Step 5: Penalty Mechanism for Double-Spending Attacks: If a double-spending attack occurs, then for the same transaction amount, there are two colliding transaction messages m1 = (x, p1) and m2 = (x, p2), and the aggregate signatures corresponding to these two colliding messages are also specified. In this way, everyone can perform local calculations using transparent data on the blockchain to obtain the private keys of malicious users, thereby enabling the implementation of punitive measures against accounts that commit double-spending attacks.

[0065] In this embodiment, the certificate information mentioned in step one includes information for user P. i Public and private key pairs for transactions (pk i ,sk i The transaction requires a hash function and global parameter information, including the public key pk. i This is the account address used by the user to receive transfers and is valid indefinitely.

[0066] In this embodiment, the registration of both buyers and sellers in step one specifically includes:

[0067] The authoritative body first initializes the system's security parameters κ based on system scale, service requirements, and security considerations; then, based on the current security parameters, the authoritative body calculates the system's security parameters according to the algorithm CAPP.Gen(1). κ →pp generates global parameters for computation, including a p-order group G = <g>and three hash functions H com H agg H sig {0, 1} * →{0,1} l These three hash functions take a 0-1 bit string of arbitrary length as input and output a 0-1 bit string of length l. The security of this system depends on the difficult problems of computing the Diffie-Hellman problem and determining the Diffie-Hellman problem.

[0068] When there is a user P i When issuing an account registration request, the authoritative organization uses pre-determined global parameters and user P's... i Selected private key According to the algorithm CAPP.Enroll(pp) → (pk) i ,sk i ) Calculate and generate the corresponding public key This public-private key pair (pk i ,sk i ) will be used for user P i Subsequent transaction activities, including public key PK i Will be used as P i Long-term account address.

[0069] In this embodiment, step two, verifying the buyer's user identity, specifically includes:

[0070] Before each transaction, buyer user P i First, select temporary parameters that meet the system requirements. Calculate locally on the client Meanwhile, user P i The local client is performing calculations on the hash function from the global parameters determined by the authoritative body, inputting the R calculated in the previous step. i Calculate the hash value t i =H com (R i Pack these two results together (R) i , t i ) Sent to other parties in the transaction P j The safety of this step depends on the difficulty of the discrete logarithm problem, given R. i There is no probabilistic multinomial-time algorithm that can obtain r. i ;

[0071] Other parties in the transaction P j Received a message from the buyer user (R) i , t i After that, t' is also calculated on the local client. i =H com (R i ), verify t' i =t i Whether it is true or not, in order to verify buyer user P i Is the user a legitimate registered user in the system? If this step verifies the user's identity, the transaction continues; otherwise, the transaction is terminated.

[0072] In this embodiment, step three, where the buyer sends a transaction request, specifically includes:

[0073] Before formally generating the transaction request, determine the public key set L = {pk1, ..., pk} of each party to the transaction. n } and temporary parameter information R of the parties to the transaction i ;Use the aggregator according to the algorithm First, calculate a. i =H agg (pk i (L), and then aggregate the public key set to obtain Temporary parameter information R i Aggregation This aggregator generates Both R and P will be used as buyer users. i Generate a transaction request;

[0074] Generated using the above aggregator And R, buyer user P i This step formally generates the transaction request; buyer user P i First, calculate the hash value on the local client. The hash value c contains account information, temporary parameter information, and transaction amount information for all parties involved in the transaction; then, for transaction information m = (x, p), the buyer user P... i Client-side local computation s i =r i +c·p·a i ·sk i mod q, where r i Buyer user P i The temporary parameters are: c is the hash value just calculated containing the account information of all parties involved in the transaction, the temporary parameter information, and the transaction amount information; p is other information that needs to be signed; a... i Buyer user P i public key pk i The public key set of all parties involved in the transaction is used as the input hash value, sk i For buyer user P i The private key, q, is a global parameter of the system. This step is a key step to achieve system traceability and resistance to double-spending attacks.

[0075] Buyer user P i Package the above client-generated results into a signature σ. i =(s i R i And using the ZK-SNARK zero-knowledge proof method, the signature σ is... i =(s i R i Generate proof π i Then σ i and π i Send to all parties involved in the transaction;

[0076] When the parties to the transaction receive σ i Afterwards, the parties to the transaction first discussed the buyer user P. i Signature σ i And proof of π i The verification is performed; if the verification passes, the aggregator proceeds according to the algorithm. Calculate separately Combined with the aggregator generated above And R, generate the aggregate signature for this transaction. Send it to the verifier to verify the legitimacy of the transaction.

[0077] In this embodiment, the verifier's transaction verification in step four specifically includes:

[0078] The verifier knows the transaction information m = (x, p) and the public key set L = {pk1, ..., pk} of the parties to the transaction. n }, aggregate signature for this transaction Verification is performed; the verifier first repeatedly executes the aggregation algorithm. Calculated and R;

[0079] get After R, the verifier executes the algorithm. In this algorithm, the verifier first runs the system-defined global hash function to calculate the hash value. Generate a 01 bit string c of length l;

[0080] The verifier calculates Verify the validity of the signature. If the signature is valid, the verifier writes the transaction into the blockchain, and the transaction becomes effective. Otherwise, the transaction is terminated. If the transaction is found to be a double-spending attack, proceed to step five above.

[0081] In this embodiment, the penalty mechanism for double-spending attacks in step five specifically includes:

[0082] When a double-spending attack occurs, the blockchain contains a pair of colliding messages m1 = (x, p1) and m2 = (x, p2), and a corresponding aggregate signature. First, this information is transparent to all users in the blockchain; therefore, all users can easily perform calculations using this data locally. This is achieved by first utilizing the system's aggregation algorithm. Any user can obtain the aggregated public key for this transaction. Aggregate temporary parameters R and aggregate signatures s;

[0083] Any user can obtain the aggregated public key for this transaction. After aggregating the temporary parameter R and the aggregate signature s, the hash function is first calculated to obtain... Then we obtain the s corresponding to the two aggregate signatures. i1 =r i +c·p1·a i ·sk i and s i2 =r i +c·p2·a i ·sk i At this point, the right side of the equation Since all of these are known quantities, the private key of this malicious user can be obtained. This penalty mechanism against double-spending attacks also satisfies the properties of existence (unforgeable) and dual signature (extractable).

[0084] In this embodiment, the ZK-SNARK zero-knowledge proof method specifically includes:

[0085] The specific algorithm for proving the validity of a transaction using the ZK-SNARK zero-knowledge proof method is as follows: ZK = (Gen, Prove, Verify), where R satisfies c ={(x, w)|C(x, w)=0};

[0086] use Let's describe the arithmetic circuit C. Since the arithmetic circuit of the transaction validator is fixed, the polynomial it generates is also fixed. First, the user inputs their own circuit C and the security parameter κ determined by the system based on security and performance requirements. Then, the ZK.Gen(κ, C) → (vk, pk) algorithm is executed: This algorithm returns a verification key vk and a proof key pk. This verification and proof key pair will be used later to generate proof π and verify the legality of proof π, respectively.

[0087] With the verification key vk and the proof key pk, the system can generate a proof based on the ZK.Prove(pk, st, w)→π algorithm. After inputting the proof key pk, the statement st and the corresponding evidence w, the algorithm outputs the proof π corresponding to the statement st.

[0088] The verification algorithm for this zero-knowledge proof method is ZK.Verify(vk, st, π) → {0, 1}. The input is the verification key vk, the statement st, and the corresponding proof π. If x∈L... C If a valid proof is found, the algorithm returns 1; otherwise, it returns 0.

[0089] The following is an explanation of some of the technical terms used in this invention:

[0090] Signature: In this invention, "signature" refers to a digital signature. A digital signature is similar to a physical signature written on paper, but it is implemented using public-key cryptography techniques. It is an application of asymmetric encryption and digital digest technologies. Digital signatures typically involve two operations: signing and verification. Only the signer of the information can generate a digital string that cannot be forged by others. Therefore, digital signatures include functions such as authentication, integrity verification, and non-repudiation.

[0091] Double-spending attack: The same digital asset is used repeatedly, also known as a double-consumption attack.

[0092] Computing the Diffie-Hellman problem: For Given (g) a g b There is no probabilistic multinomial-time algorithm that can calculate g. ab .

[0093] Determining the Diffie-Hellman problem: For There is no probabilistic multinomial-time algorithm that can process tuples (g) a g b g ab ) and (g a g b g c They are clearly distinguishable.

[0094] Address: The addresses mentioned in this invention refer to blockchain addresses, which are used to identify the sender and receiver of a transaction. Blockchain addresses are obtained through a series of hash and encoding algorithms on the public key.

[0095] A secure CAPP solution needs to meet the requirements of integrity, anonymity, verifiability, traceability, and fairness.

[0096] The safety analysis of this invention is as follows:

[0097] Integrity: The integrity requirement of this invention is that valid transactions can be received correctly and that the private key of the transaction can be extracted in the event of a double-spending.

[0098] Anonymity: The anonymity requirement of this invention is that the ledger and transactions will not disclose any private information other than public parameter information to adversaries. That is, for any security parameter k, there is no probabilistic multinomial-time adversary. It can distinguish between two different transactions.

[0099] Authenticability: To prevent the alteration of participants' anonymous addresses and transfer values, this invention provides identity authentication. That is, there is no probabilistic multinomial-time adversary. Transaction information can be modified before it is recorded in the decentralized ledger.

[0100] Traceability and fairness. This invention achieves transaction fairness by extracting the private key in the event of a double-spending transaction. The long-term address of a malicious sender can be traced, providing traceability.

[0101] This system model contains four entities: an authoritative institution, buyer users and seller users, validators, and the blockchain. Their respective functions and responsibilities within the system are as follows:

[0102] Authoritative institutions initialize global parameters for buyer users, seller users, and verifiers to meet the system's subsequent calculation needs, while ensuring that the parameters meet the system's security and performance requirements.

[0103] Buyer and seller users: After registering with an authoritative institution and obtaining initial certificate information including public and private key pairs, they can conduct transactions using the other party's public key as the account address.

[0104] Validators are responsible for maintaining the public ledger. When a transaction request is made on the blockchain, the validator verifies the transaction's validity. If valid, the transaction is written into the blockchain to indicate its validity; otherwise, the request is rejected, and penalties are imposed.

[0105] Blockchain: Uses decentralized and cryptographic technologies to record information, ensuring its immutability, transparency, and security.

[0106] The beneficial effects of this invention are: This large-scale multi-party payment system and method based on blockchain security ensures transaction security for both buyers and sellers, including integrity, anonymity, verifiability, traceability, and fairness. It guarantees smooth transactions without disclosing transaction privacy information, while simultaneously imposing penalties on malicious users and deterring double-spending attacks. The efficiency of this large-scale multi-party payment system and method based on blockchain security increases with the number of participating users. This aligns with the analysis, as an increase in the number of participating users requires more time for signatures and proofs. The time cost of this system increases substantially linearly with the number of participating users, and its time cost remains low even in large-scale user transaction systems, making it suitable for large-scale payment applications.

[0107] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.< / g> < / g> < / g> < / g>

Claims

1. A blockchain conditionally secure large-scale multi-party payment system, characterized in that: An algorithmic tuple comprising a probabilistic polynomial time algorithm ; The Specifically includes: : input security parameters , the algorithm outputs global parameters , containing a group of order p , and three hash functions , which input is an arbitrary length of 01 bit string, and output is a length of 01 bit string; : input the global parameters determined in advance , randomly select a private key , then the authority calculates the corresponding public key , the algorithm generates a pair of public and private keys for each party involved in the transaction ; : buyer user computing a hash value , selecting and computing and sending the result to other users in the transaction ; when all other users in the transaction have received the result, verifying whether the equation is true; if the equation is true, , where can be obtained from the aggregator; then for the message , compute , where is the transaction amount, is other information that needs to be signed, and q is the global parameter of the system; finally, the buyer user sends and the corresponding proof to other users in the transaction;​​ : input given set of public keys , aggregator computes , and , then computes aggregated public key and ; this algorithm outputs aggregated public key , and corresponding aggregated signature ; : given a message , a set of public keys and corresponding signatures ; a node in the blockchain first computes , then verifies the signature by computing and outputs 1 if the signature is valid, otherwise 0; If a double-spending attack occurs, then it means that there are two collision messages Each corresponding aggregated signature ; all of which can be calculated , and , further obtaining the private key of the double-spending attack malicious user .

2. A blockchain-based conditionally secure large-scale multi-party payment method, characterized in that: The large-scale multi-party payment method is realized by the method of claim 1, and specifically includes the following steps. Step one: registration of both buyers and sellers: before the transaction, the buyer and the seller register with the authority to obtain certificate information; Step Two: Verify Buyer User Identity: Buyer User First select And calculated ,Then Calculate a hash value ; Calculation results and Send to other users in the transaction When all other users in the transaction After receiving all the results, verify. Is the equation true? If the equation is true, the system proceeds to step three; otherwise, the transaction is aborted. Step 3: Buyer sends transaction request: Buyer user First calculate ,in and It can be obtained from the aggregator, and then from the buyer user. Regarding the message ,calculate , here It's the transaction amount. Other information that needs to be signed, and finally, the buyer user. Bundle and the corresponding proof Send to other parties in the transaction, who then verify the proof. Once effective, the seller user signature The aggregated signature of this transaction is generated after aggregation. Send to the verifier; Step four: verifier verifies transaction: verifier knows the message , a set of public keys and corresponding signatures , verifying the signature, the verifier first calculates , then calculates to verify whether the signature is valid, if the signature is verified, the verifier writes this transaction into the blockchain, the transaction is completed, otherwise, the transaction is aborted; if a double-spending attack is found, the system performs step five; Step five: Punishment mechanism of double-spend attack: if double-spend attack occurs, there are two collision transaction messages for the same transaction amount , and the two collision messages each correspond to an aggregated signature ; in this way, everyone can locally calculate the private key of the malicious user through transparent data on the blockchain to implement punishment measures on the account that has double-spend attack.

3. The method of claim 2, wherein: The certificate information in step one includes a public-private key pair for the user of a transaction , a hash function required by the transaction, and global parameter information, wherein the public key is used as the account address of the user receiving the transfer and is valid for a long time.

4. The method of claim 2, wherein: The registration of both buyers and sellers in step one specifically includes: The authority first initializes the security parameters of the system according to the system scale, service requirement and security consideration Then, the authority generates the global parameters for calculation according to the current security parameters and the algorithm , including a group of order p , and three hash functions The three hash functions input is an arbitrary length of 01 bit string, and the output length is 01 bit string When a user issues a request for account registration, the authority calculates a corresponding public key according to a pre-determined global parameter and a private key selected by the user , following an algorithm , which public-private key pair will be used for the user 's subsequent transaction activities, with the public key serving as a long-term account address.

5. The method of claim 2, wherein: The verification of the identity of the buyer in step two specifically includes: Before each transaction, the buyer user First, select the temporary parameters that meet the system requirements , the client local calculation ; at the same time, the user Local client on the authority to determine the hash function, input the calculation of the , calculate the hash value ; the two results are packaged Send to other parties in the transaction ; this step security depends on the difficulty of the discrete logarithm problem, known , there is no probabilistic polynomial time algorithm can get ; Other parties in the transaction Received a message from a buyer user Then, the calculation is also performed on the local client. ,verify Whether it is valid or not, in order to verify the buyer user. Is the user a legitimate registered user in the system? If this step verifies the user's identity, the transaction continues; otherwise, the transaction is terminated.

6. The method of claim 2, wherein: The sending of the transaction request by the buyer in step three specifically includes: Determine the public key set of the transaction parties before formally generating the transaction request and the temporary parameter information of the transaction parties ; use the aggregator to calculate , first get , then aggregate the public key set to get , the temporary parameter information is aggregated to get ; here and generated by the aggregator will be used by the buyer user to generate a transaction request; generated by the above-described aggregator and the buyer user In this step, the transaction request is formally generated; the buyer user First, the local client calculates the hash value The hash value contains the account information of the transaction participants, the temporary parameter information and the transaction amount information; then, for the transaction information , the buyer user The local client calculates , wherein is the temporary parameter of the buyer user , the hash value is the hash value containing the account information of the transaction participants, the temporary parameter information and the transaction amount information just calculated, is other information that needs to be signed, is the hash value with the public key of the buyer user and the public key set of the transaction participants as input, is the private key of the buyer user , and is the global parameter of the system. This step is the key step to realize the traceability and anti-double-spend attack of the system; Buyer user Pack the result generated locally by the above client as a signature , and use the ZK-SNARK zero-knowledge proof method to prove the signature Generate proof ; Then send and to the transaction parties; When the transaction parties receive , the transaction parties first verify the signature and the proof of the buyer user , if the verification is passed, the aggregator calculates , respectively, according to the algorithm , and combines the above-mentioned aggregator-generated and to generate the aggregated signature of this transaction, and sends it to the verifier for verifying the legality of the transaction.

7. The method of claim 2, wherein: The verification of the transaction by the verifier in step four specifically includes: the verifier knows the transaction information and the set of public keys of the transaction parties the aggregated signature of the transaction to verify; the verifier first repeats the aggregation algorithm to compute and ; Obtained and After that, the verifier executes an algorithm In this algorithm, the verifier first runs a global hash function defined by the system to calculate a hash value , generating a 01 bit string of length ; The verifier verifies the signature by computing The verifier verifies the signature is valid, if the signature is valid, the verifier writes the transaction into the blockchain, the transaction takes effect, otherwise the transaction is aborted; if the transaction is found to be double-spending attack, go to step five.

8. The method of claim 2, wherein: The punishment mechanism of the double-spend attack in step five specifically includes: When a double-spending attack occurs, there exist in the blockchain a pair of colliding messages , and a pair of aggregated signatures corresponding thereto ; firstly, this information is transparent to all users in the blockchain, so all users can simply use this data to calculate locally; firstly, use the aggregation algorithm of the system , any user can obtain the aggregated public key of this transaction , the aggregated temporary parameter and the aggregated signature ; Any user gets the aggregated public key of this transaction , aggregated temporary parameter and aggregated signature , first, the hash function is calculated , then the two aggregated signatures are calculated and , at this time, the right side of the equation is a known quantity, and the private key of the malicious user can be obtained.

9. The method of claim 6, wherein: The ZK-SNARK zero-knowledge proof method specifically includes: The specific algorithm for proving the validity of the transaction by using the ZK-SNARK zero-knowledge proof method is as follows: wherein the following is satisfied ; Using to describe arithmetic circuits Because the arithmetic circuit of the transaction verifier is fixed, the polynomial it generates is also fixed; first, the user inputs his own circuit and the security parameters determined by the system according to security and performance requirements , execute algorithm: this algorithm returns a verification key and a proof key ; This verification, proof key pair, will be used subsequently to generate proofs and verify the legitimacy of proofs respectively; With the verification key and proof key Afterwards, the system can... The algorithm generates proof of the input proof key. ,statement and the corresponding evidence Then, the algorithm outputs the statement. Corresponding proof ; The verification algorithm of the zero-knowledge proof method is , input verification key , statement and the corresponding proof of the statement , if it is a legal proof of , this algorithm returns 1, otherwise returns 0.