Block chain transaction method and device, equipment, storage medium and program product

Abstract

The embodiment of the invention provides a block chain transaction method and device, equipment, a storage medium and a program product, and relates to the technical field of block chains. The method comprises the steps that a server determines a target proving party node from participating nodes corresponding to a target transaction set based on dynamic selection, and the server distributes at least one transaction in the target transaction set to the target proving party node. The target certification party node generates a first block and a first block certification of the first block according to at least one transaction distributed by the block chain service party, and after the verification party node verifies that the first block certification passes, the verification party node transactions with the target certification party node according to the first block. And recording the transaction information of the transaction to a main chain of the block chain. According to the method, through a mode of dynamically selecting the target proving party node, the centralization of the proving party node is reduced, the decentralization effect of the block chain transaction is improved, and the transaction risk is reduced.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a blockchain transaction method, device, equipment, storage medium and program product. Background Art

[0002] With the rapid development of blockchain, more and more fields are beginning to apply blockchain. At present, transaction packaging is a particularly critical part of blockchain technology. In short, the process of transaction packaging is to collect and organize multiple transactions generated within a period of time and finally form a data block, which will then be added to the blockchain. The purpose of this process is to ensure the security and effectiveness of transactions while optimizing the operating efficiency of the blockchain. However, in the process of transaction packaging, the proving party node is centralized, resulting in weak trust and high transaction risks in transaction packaging.

[0003] Therefore, how to improve the security of transaction packaging is an urgent problem to be solved. Summary of the invention

[0004] The present application provides a blockchain transaction method, device, equipment, storage medium and program product to solve the technical problems of weak trust in transaction packaging and high transaction risk.

[0005] In a first aspect, the present application provides a blockchain transaction method, comprising:

[0006] Determining, based on dynamic selection, a target prover node from participating nodes corresponding to a target transaction set, the participating node being associated with at least one transaction in the target transaction set;

[0007] Distribute at least one transaction in the target transaction set to the target prover node.

[0008] In a second aspect, the present application provides a blockchain transaction method, comprising:

[0009] Obtain at least one transaction distributed by the blockchain service provider;

[0010] Generate a first block and a first block certificate of the first block according to at least one transaction distributed by the blockchain service provider;

[0011] Based on the first block and the first block proof of the first block, a transaction is performed with a verifier node.

[0012] In a third aspect, the present application provides a blockchain transaction method, comprising:

[0013] Obtaining a first block from the blockchain network, and a first block proof of the first block, wherein the first block comes from a target prover node;

[0014] Verifying the first block proof;

[0015] If the verification is successful, the transaction is performed according to the first block, and the transaction information of the transaction is recorded in the main chain of the blockchain.

[0016] In a fourth aspect, the present application provides a blockchain transaction device, comprising:

[0017] a processing module, configured to determine, based on dynamic selection, a target prover node from participating nodes corresponding to a target transaction set, wherein the participating node is associated with at least one transaction in the target transaction set;

[0018] The transceiver module is used to distribute at least one transaction in the target transaction set to the target prover node.

[0019] In a fifth aspect, the present application provides a blockchain transaction device, comprising:

[0020] An acquisition module, used to acquire at least one transaction distributed by a blockchain service provider;

[0021] A processing module, configured to generate a first block and a first block certificate of the first block according to at least one transaction distributed by the blockchain service provider;

[0022] A control module is used to conduct a transaction with a verification node based on the first block and the first block proof of the first block.

[0023] In a sixth aspect, the present application provides a blockchain transaction device, comprising:

[0024] An acquisition module, configured to acquire a first block and a first block certificate of the first block from the blockchain network, wherein the first block comes from a target prover node;

[0025] A processing module, configured to verify the first block certificate;

[0026] The control module is used to perform a transaction according to the first block if the verification is passed, and record the transaction information of the transaction in the main chain of the blockchain.

[0027] In a seventh aspect, the present application provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0028] The memory stores computer-executable instructions;

[0029] The processor executes the computer-executable instructions stored in the memory to implement the methods described in the first to third aspects.

[0030] In an eighth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the methods described in the first to third aspects.

[0031] In a ninth aspect, the present application provides a computer program product, which, when executed by a processor, is used to implement the methods described in the first to third aspects.

[0032] The blockchain transaction method, device, equipment, storage medium and program product provided by the present application, the server determines the target prover node from the participating nodes corresponding to the target transaction set based on dynamic selection, and the server distributes at least one transaction in the target transaction set to the target prover node. The target prover node generates a first block and a first block proof of the first block according to at least one transaction distributed by the blockchain service party. After the verification node verifies that the first block proof is passed, it conducts a transaction with the target prover node according to the first block, and records the transaction information of the transaction in the main chain of the blockchain. This method reduces the centralization of the prover node by dynamically selecting the target prover node, improves the decentralization effect of blockchain transactions, and reduces transaction risks. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0034] Figure 1 A flowchart of a blockchain transaction method provided in an embodiment of the present application;

[0035] Figure 2 A flowchart of another blockchain transaction method provided in an embodiment of the present application;

[0036] Figure 3 A flowchart of another blockchain transaction method provided in an embodiment of the present application;

[0037] Figure 4 A schematic diagram of the structure of a zero-knowledge proof algorithm provided in an embodiment of the present application;

[0038] Figure 5 A schematic diagram of the structure of a ciphertext certificate provided in an embodiment of the present application;

[0039] Figure 6 A flowchart of another blockchain transaction method provided in an embodiment of the present application;

[0040] Figure 7A schematic diagram of the structure of a blockchain transaction device provided in an embodiment of the present application;

[0041] Figure 8 A schematic diagram of the structure of another blockchain transaction device provided in an embodiment of the present application;

[0042] Fig. 9 A schematic diagram of the structure of another blockchain transaction device provided in an embodiment of the present application;

[0043] Fig.10 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0044] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0045] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0046] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with the relevant laws, regulations and standards of the relevant countries and regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0047] In addition, this application involves conducting big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.), and using artificial intelligence technology to make automated decisions, and making technical solutions that have a significant impact on personal rights and interests based on the results of automated decisions. The application provides users with corresponding operation entrances for them to choose to agree or reject the results of automated decisions; if the user chooses to reject, the expert decision-making process will be entered.

[0048] It should be noted that the blockchain transaction method, device, equipment, storage medium and program product provided in this application can be used in the field of blockchain technology, and can also be used in any field outside the field of blockchain technology. The application field of the blockchain transaction method, device, equipment, storage medium and program product in this application is not limited.

[0049] At present, with the rapid development of blockchain, more and more fields are beginning to apply blockchain. Blockchain transaction packaging is to collect and organize multiple transactions generated within a period of time, and finally form a data block, which will then be added to the blockchain. The purpose of this process is to ensure the security and effectiveness of transactions, while optimizing the operating efficiency of blockchain. In the existing technology, the first layer of the network is generally used for transaction packaging. In order to improve the efficiency of transaction packaging, a second layer of the network is generally set up for transaction packaging. In the second layer network, transactions are packaged into batches and submitted to the first layer network. The transactions in these batches will be verified and compressed to reduce the load on the main chain. This can greatly improve the throughput and scalability of the network.

[0050] In the second-layer network, there are proving nodes and verifying nodes. The proving node is responsible for packaging one or more transactions into a block. The proving node generates a block containing multiple transactions and generates the corresponding signature proof. The proving node signs the block with the private key and submits it to the verifying node as a proof for verification. The verifying node receives the block and signature proof submitted by the proving node, and verifies the validity of the signature proof to ensure that the transactions in the block are legal.

[0051] However, the current proof-party nodes are centralized, which results in weak trust in transaction packaging on the second-layer network and creates transaction risks.

[0052] In view of this, the present application provides a blockchain transaction method, in which the server determines the target prover node from the participating nodes corresponding to the target transaction set based on dynamic selection, and the server distributes at least one transaction in the target transaction set to the target prover node. The target prover node generates a first block and a first block proof of the first block according to at least one transaction distributed by the blockchain server. After the verification node verifies that the first block proof is passed, it conducts a transaction with the target prover node according to the first block, and records the transaction information of the transaction in the main chain of the blockchain. This method reduces the centralization of the prover node by dynamically selecting the target prover node, improves the decentralization effect of blockchain transactions, and reduces transaction risks.

[0053] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0054] Figure 1 A flowchart of a blockchain transaction method provided in an embodiment of the present application. Figure 1 As shown, the method may include:

[0055] S101. The server determines a target prover node from participating nodes corresponding to a target transaction set based on dynamic selection.

[0056] Among them, the participating node is related to at least one transaction in the target transaction set. The target transaction set is a set of a series of transactions that need to be processed, such as a set of a batch of transactions that are packaged through the second-layer network and submitted to the first-layer network. The participating node is a node that has an association relationship with at least one transaction in the target transaction set, such as participating in the initiation, transfer or other operations related to the transaction. The target prover node is a node selected from the participating nodes to generate a block certificate for the transaction.

[0057] In one possible implementation, the server may dynamically select the target prover node by randomly determining the target prover node, that is, the server randomly selects a node from the participating nodes corresponding to the target transaction set as the target prover node.

[0058] Another possible implementation method is that the server can determine the target prover node based on a preset rotation rule and dynamically select the target prover node, that is, the server selects the target prover node for the transaction according to the rotation rule from the participating nodes corresponding to the target transaction set.

[0059] S102: The server distributes at least one transaction in the target transaction set to a target prover node.

[0060] Accordingly, the target prover node obtains at least one transaction distributed by the blockchain service provider.

[0061] After determining the target prover node, the server selects at least one transaction from the target transaction set. These transactions can be selected in a certain order, such as transaction time order or transaction amount order, or can be randomly selected. Then, the server sends the selected transaction to the target prover node.

[0062] The target prover node obtains at least one transaction distributed from the server (e.g., receives information about the transaction, monitors the distribution behavior of the server, etc.). When receiving the transaction data sent by the server, it parses the received data according to the predetermined data format and stores the transaction information in the local transaction cache or a dedicated transaction database for subsequent processing.

[0063] S103. The target prover node generates a first block and a first block proof of the first block according to at least one transaction distributed by the blockchain service provider.

[0064] The first block is a data block in the blockchain containing transaction information generated by the target proving node based on the received transaction. The first block proof is a data structure used to prove the legitimacy and integrity of the first block.

[0065] In this step, the target prover node can organize the acquired transactions. According to the predetermined rules, the transaction information (such as the addresses of the two parties to the transaction, the transaction amount, the transaction timestamp, etc.) is serialized and organized into a specific data structure. For example, multiple transactions are arranged in chronological order to build a list containing these transaction information. The hash value of the data structure is calculated. The choice of hash function must meet the security requirements of the blockchain, such as using hash algorithms such as SHA-256. This hash value will be used as part of the first block to identify the uniqueness of the block and ensure the integrity of the block content. For example, a hash value of a fixed length is obtained by performing a hash calculation on the list containing the transaction information. The first block can also contain some metadata, such as the hash value of the previous block, which helps to link the block to other blocks in the blockchain.

[0066] The target proving node can use its own private key and a specific encryption algorithm to generate the first block proof. For example, the specific encryption algorithm can be a technology such as the Elliptic Curve Digital Signature Algorithm (ECDSA). Combine some key information in the first block (such as summary information and metadata of the transaction) with the private key of the node and calculate it through the encryption algorithm. This calculation process will generate a unique signature, which is the core part of the first block proof. Optionally, some format conversion and additional information can be added to this signature (for example, adding some tags to identify the source and type of the proof), and finally form a complete first block proof.

[0067] After generating the first block, the target proving node may synchronize the first block and the first block proof to the blockchain network so that the verifying node can conduct transactions based on the first block and the first block proof.

[0068] S104. The verifier node obtains the first block and the first block certificate of the first block from the blockchain network.

[0069] The first block comes from the target prover node. The blockchain network is a distributed network composed of many nodes for storing and disseminating blockchain data, and the blockchain network includes the first block.

[0070] The verifier node obtains the first block and its block certificate by communicating with other nodes in the blockchain network. It can periodically send requests to the surrounding neighboring nodes to obtain the latest block. After receiving the request, if the neighboring node has the first block and its certificate generated by the target prover node stored locally, it will send it to the verifier node. After receiving the data, the verifier node parses it according to the predetermined data format and stores the first block and the first block certificate in the local cache or a dedicated verification data storage area.

[0071] S105. The verifier node verifies the first block certificate.

[0072] The verifier node verifies the first block proof through the first block proof, for example, the first block proof can be verified through the verification key. The first block proof is verified through a verification algorithm that is opposite to the block proof generated by the target prover node (for example, a verification algorithm corresponding to the zero-knowledge proof algorithm). If the calculation result of the verification algorithm meets expectations, the verification is passed.

[0073] S106. If the verification is successful, the verifier node conducts a transaction with the target prover node according to the first block, and records the transaction information in the main chain of the blockchain.

[0074] The main chain is the blockchain branch with the longest valid chain length that is recognized by all nodes in the blockchain network. It is the core part of the blockchain and records all legal transaction information.

[0075] If the first block passes the verification, the verifier node performs a transaction operation with the target prover node based on the transaction information in the first block. For example, if the transaction in the first block is an asset transfer transaction, the verifier node will perform corresponding updates in the local account balance database (if it exists) according to the amount, sender, and receiver in the transaction. Then, the verifier node records the transaction information of this transaction in the main chain of the blockchain. This process includes encoding the transaction information in the data format of the blockchain, calculating the hash value of the transaction information, and then adding it to the end of the main chain. At the same time, the verifier node will broadcast this new transaction information and the update of the main chain to the surrounding nodes so that other nodes can be updated synchronously.

[0076] In the method provided by the embodiment of the present application, the server determines the target prover node from the participating nodes corresponding to the target transaction set based on dynamic selection, and the server distributes at least one transaction in the target transaction set to the target prover node. The target prover node generates a first block and a first block proof of the first block according to at least one transaction distributed by the blockchain service provider. After the verification node verifies that the first block proof is passed, it conducts a transaction with the target prover node according to the first block, and records the transaction information of the transaction to the main chain of the blockchain. This method reduces the centralization of the prover node by dynamically selecting the target prover node, improves the decentralization effect of blockchain transactions, and reduces transaction risks.

[0077] Next, how to determine the target proving party node from the participating nodes corresponding to the target transaction set based on dynamic selection in the aforementioned step S101 is described in detail.

[0078] Method 1: Randomly determine the target prover node from the participating nodes corresponding to the target transaction set.

[0079] Specifically, by introducing a random algorithm (an algorithm that generates numbers or selects elements according to random principles, such as a quantum true random number generator), the prover role can be randomly selected from a list of provers (i.e., the participating nodes corresponding to the target transaction set), so that the role of the prover node is decentralized, avoiding a single prover node selecting only a specific transaction to generate validity proof, and reducing transaction risks.

[0080] For example, after the server obtains the list of participating nodes corresponding to the target transaction set, it can number these nodes in a certain order (such as the network address order of the nodes or the node registration order, etc.). Then, a quantum true random number generator is used to generate a random number between 1 and the number of participating nodes. Finally, the participating node with the number corresponding to the random number is determined as the target prover node.

[0081] Method 2: Obtain a rotation rule for determining a target prover node, and determine the target prover node from the participating nodes corresponding to the target transaction set according to the rotation rule.

[0082] The rotation rule is a rule mechanism for determining the target proving node. It aims to select a suitable node as the target proving node from the participating nodes through certain logic to ensure the fairness, security and efficiency of blockchain transactions.

[0083] Optionally, the server can determine the target prover node based on a pre-set node rating system. For example, the server rates each participating node, and this rating can take into account multiple factors, such as the node's hardware configuration (computing power, storage capacity, etc.), network connection status (bandwidth, stability, etc.), security protection capabilities (firewall settings, data encryption capabilities, etc.), etc. For example, the nodes are divided into three levels: high, medium, and low. Then, according to a rotation mode, such as selecting the target prover node alternately according to the level, first select a node from the high-level nodes in a certain order (such as registration order) as the target prover node, the next time select from the intermediate nodes, and the next time select from the low-level nodes, and so on.

[0084] Optionally, the rotation rules can be based on the attribute parameters of each participating node, including at least one of the following: the pledge parameter (a parameter related to the amount of assets pledged by the node in the blockchain, which can reflect the node's economic investment and commitment to the network), the reputation parameter (a parameter reflecting the node's reputation based on the node's past transaction performance, compliance with the rules, etc.), and the number of proof parameters (a parameter that records the number of times the node has performed proof operations). Method 2 can be specifically achieved through the following: Figure 2 The steps shown are implemented. Figure 2 A flowchart of another blockchain transaction method provided in an embodiment of the present application. Figure 2 As shown, the aforementioned step S101 may specifically include:

[0085] S201. The server obtains attribute parameters of each participating node and the weight of the attribute parameters.

[0086] The server obtains the attribute parameters of each participating node from the node information storage area of ​​the blockchain network (which can be a distributed database or a dedicated node information management module), including pledge parameters, reputation parameters, and proof number parameters. These parameters may be stored in different formats. For example, pledge parameters may be stored as specific numbers (representing the number of pledged digital currencies or the quantitative value of other assets), reputation parameters may be stored as scores (values ​​between 0 and 100 points), and proof number parameters are recorded as integers. At the same time, the server obtains the weight corresponding to each attribute parameter from the local configuration file or a dedicated weight setting module. These weights are also pre-set values. For example, the pledge parameter weight is 0.3, the reputation parameter weight is 0.5, and the proof number parameter weight is 0.2.

[0087] S202: The server determines a target score for each participating node according to the attribute parameters of each participating node and the weight of the attribute parameters.

[0088] Optionally, for each attribute parameter, the server can first sort all participating nodes according to the value of the attribute parameter. For example, the nodes are sorted from high to low according to the value of the pledge parameter, and then converted into a score according to the position of the node in the sorting, such as the first-ranked node has a pledge score of 100 points, the last-ranked node has a pledge score of 0 points, and the scores of other nodes are determined by linear interpolation. The same operation is performed for the reputation parameter and the number of proof parameters. Finally, the converted scores of each attribute parameter are weighted and summed according to the weight to obtain the target score.

[0089] Optionally, the initial score of each participating node may be determined according to the weights of different attribute parameters and the reward weights of each participating node. This implementation method may be specifically implemented through the following sub-steps:

[0090] S2021. Determine an initial score of each participating node based on the attribute parameters of each participating node and the weight of the attribute parameters.

[0091] Among them, different weights can be set in advance for different attribute parameters of participating nodes (the weights can be set according to actual needs, and this application does not limit this), so as to determine the initial scores of participating nodes based on the weights and multiple attribute parameters of participating nodes. For example, for each participating node, the server can multiply its attribute parameters by the corresponding weights, and then add these products to obtain the initial score. Exemplarily, for a certain participating node, assume that its pledge parameter value is 100 and the pledge parameter weight is 0.3; the reputation parameter value is 80 and the reputation parameter weight is 0.5; the proof number parameter value is 50 and the proof number parameter weight is 0.2. Then the initial score is 100×0.3+80×0.5+50×0.2=80.

[0092] Optionally, the attribute parameters of the participating nodes can be updated in real time. Taking the reputation parameter as an example, the initial value of the reputation parameter can be consistent for all proving nodes, and then each time the verified node passes the verification, the reputation parameter is increased, and if it fails, the reputation parameter is reduced.

[0093] Optionally, the weight of the attribute parameter can also be adjusted according to the actual situation. For example, if the verification pass rate in the historical time period is high, such as 100%, it is considered that the probability of the proving node cheating is low, and the weight of the reputation parameter can be reduced; if the verification pass rate is low, such as 70%, it is considered that the probability of the proving node cheating is high, and the weight of the reputation parameter can be increased. Through dynamic adjustment, the effectiveness of the rotation rules and the effectiveness of transaction packaging can be improved.

[0094] S2022. Obtain the reward weight of each participating node.

[0095] Among them, the reward weight is inversely proportional to the number of times each participating node has submitted proofs in history, which aims to encourage nodes that have submitted fewer proofs to participate in the competition for the target proof node.

[0096] The server can obtain the number of historical proof submissions of each participating node from the node operation record area of ​​the blockchain network (which can be a database specifically recording node proof operations). Assuming there are a total of 100 opportunities to submit proofs (this value can be determined based on the overall scale and settings of the blockchain network), for a participating node, if its historical proof submission number is 10 times, the reward weight is 1-10 / 100=0.9. The server performs such calculations for each participating node to obtain their respective reward weights.

[0097] S2023. Determine the target score of each participating node based on the initial score and reward weight.

[0098] Optionally, the server can multiply the initial score of each participating node by its reward weight to get the target score. For example, if the initial score of a participating node is 80 and the reward weight is 0.9, the target score is 80×0.9=72. The server performs this calculation for all participating nodes to get their respective target scores.

[0099] S203. The server determines the target prover node from the participating nodes corresponding to the target transaction set according to the target score.

[0100] The server compares the target scores of all participating nodes and selects the participating node with the highest target score as the target proving node. If there are multiple nodes with the same and highest target scores, other rules (such as the order of the node's network address, etc.) can be used to further filter and determine the unique target proving node.

[0101] According to the method provided in the embodiment of the present application, the server determines the target prover node from the participating nodes corresponding to the target transaction set based on random selection or according to a preset rotation rule, so as to realize dynamic selection of the target prover node, reduce the probability that a single prover node only selects a specific transaction to generate a validity proof, thereby reducing the centralization of the prover node, improving the decentralization effect of blockchain transactions, and reducing transaction risks.

[0102] Next, a detailed description is given of how to generate the first block certificate of the first block according to at least one transaction distributed by the blockchain service provider in the aforementioned step S103. Figure 3 A flowchart of another blockchain transaction method provided in an embodiment of the present application. Figure 3 As shown, the operation of the target prover node in the aforementioned step S103 may specifically include:

[0103] S301. The target proving node obtains the proving key and ciphertext certificate of the first block.

[0104] Among them, the ciphertext certificate includes public input and private input. The proof key is a key element used to generate block proofs, similar to an identity or a private key in cryptography. Only with the correct proof key can the corresponding block be legally proved, ensuring the security and reliability of blockchain transactions. The ciphertext certificate is an encrypted data structure that contains two parts: public input and private input. Public input is information that can be publicly obtained and may contain some public information of the transaction (such as transaction amount, timestamp, and other public data that have been specifically processed); private input is secret information known only to specific nodes (such as the target proving party node), which may involve the node's private data or encrypted sensitive transaction information.

[0105] The target proving node can obtain the proof key of the first block from the local secure storage area. This secure storage area can be an encrypted key library or a dedicated secure storage module to ensure the confidentiality and integrity of the proof key. For the ciphertext certificate, the target proving node can receive and store it from the previous transaction processing flow, or obtain the ciphertext certificate containing public input and private input from a specific data source in the blockchain network (such as extraction from the transaction information library according to certain rules).

[0106] Specifically, to confirm that the transaction is correct, the target proving party node needs to provide a proof of validity of the state changes before and after the transaction is executed, generated by a zero-knowledge proof algorithm. After the proof is submitted to the main chain smart contract, any node can use the proof to verify a specific batch of transactions on the second-layer network. Figure 4 A schematic diagram of the structure of a zero-knowledge proof algorithm provided in an embodiment of the present application. Figure 4 As shown, the zero-knowledge proof algorithm generates the keys required for proof and verification through a trusted setup module. The trusted setup module needs to be initialized and set once each time a proof is generated to generate the keys required for proof and verification. Specifically, the problem to be proved can be converted into a calculation circuit, and the calculation circuit and the random number r are used as input parameters of the trusted setup module to generate the proof key and the verification key.

[0107] Figure 5 A schematic diagram of the structure of a ciphertext certificate provided in an embodiment of the present application. Figure 5 As shown, the ciphertext certificate includes a public input S and a private input X. The public input S can be, for example, a state tree root (such as Figure 5 The state tree root StateRoot is obtained by further hashing the transaction, where tx1, tx2, tx3, tx4, etc. represent different transactions). The private input can be the information that the proving node wants to hide, and some privacy data is generated by the processing of the computing circuit (for example, the privacy data generated by the balance and account address of the target proving node through the computing circuit).

[0108] S302. The target proving node generates a first block proof of the first block according to the proving key and the encrypted certificate.

[0109] The first block proof is a data structure used to prove the legitimacy, integrity and authenticity of the first block. It is generated through a specific cryptographic algorithm and is an important component of blockchain to ensure the trustworthiness of transactions.

[0110] The target prover node can use a cryptographic algorithm (such as a zero-knowledge proof algorithm or other specific blockchain proof algorithm) and take the proof key and ciphertext certificate as input parameters. The proof key is processed according to the requirements of the algorithm, such as extracting specific fields in the key or performing key conversion operations. For the public input and private input in the ciphertext certificate, the processed proof key is combined and calculated in the manner specified by the algorithm to obtain a data result in a specific format as the first block proof of the first block. The target prover node associates the generated first block proof with the first block and prepares to send it to the blockchain network for verification by the verifier node.

[0111] Correspondingly, Figure 6 A flowchart of another blockchain transaction method provided in the embodiment of the present application. Figure 6 As shown, the operation of the verification node in the aforementioned step S103 may specifically include:

[0112] S601. The verifier node obtains the verification key corresponding to the proof key, the private input, and the first block proof.

[0113] The verification key corresponds to the proof key and is used to verify the legitimacy of the block proof. It can be the public key part of the proof key, which is used to decrypt or verify the first block proof during the verification process.

[0114] The verifier node obtains the verification key corresponding to the proof key from the local verification key repository. This verification key repository is a place specifically used to store verification keys related to nodes in the blockchain network to ensure the security and accessibility of verification keys. For private inputs, the verifier node can obtain them from the same data source as the target prover node (such as the transaction information library in the blockchain network, extracted according to pre-defined rules). At the same time, the verifier node receives the first block proof sent by the target prover node from the blockchain network, and stores the obtained verification key, private input and first block proof in the local temporary verification data area for subsequent verification operations.

[0115] S602. The verifier node verifies the first block certificate according to the verification key, the private input, and the first block certificate.

[0116] The verifier node uses a specific verification algorithm (corresponding to the algorithm used by the target prover node to generate the first block proof. For example, if the generation process uses a zero-knowledge proof algorithm, the corresponding zero-knowledge proof verification algorithm is used here). The verification key, private input, and first block proof are used as input parameters of the algorithm. The verification key is initialized according to the verification algorithm. Then, the private input is processed according to the algorithm requirements, such as format conversion, data extraction, etc. Next, the processed verification key, private input, and first block proof are verified and calculated. If the verification calculation results meet the expectations of the algorithm, the first block proof is determined to have passed the verification; otherwise, the verification is determined to have failed. The verifier node decides whether to accept the transaction based on the first block based on the verification result.

[0117] In the method provided by the embodiment of the present application, the target proving party node obtains the proving key and the ciphertext certificate of the first block, and generates the first block certificate of the first block according to the proving key and the ciphertext certificate. The verifying party node obtains the verification key, the private input, and the first block certificate corresponding to the proving key, and verifies the first block certificate according to the verification key, the private input, and the first block certificate, thereby improving the security and privacy of blockchain transactions.

[0118] Figure 7 This is a schematic diagram of the structure of a blockchain transaction device provided in an embodiment of the present application. Figure 7As shown, the blockchain transaction device may include: a processing module 11 and a transceiver module 12.

[0119] The processing module 11 is configured to determine, based on dynamic selection, a target prover node from participating nodes corresponding to a target transaction set, where the participating node is related to at least one transaction in the target transaction set.

[0120] The transceiver module 12 is used to distribute at least one transaction in the target transaction set to the target prover node.

[0121] Optionally, the processing module 11 is specifically configured to randomly determine the target proving party node from the participating nodes corresponding to the target transaction set.

[0122] Optionally, the processing module 11 is specifically configured to obtain a rotation rule for determining a target proving party node, and determine the target proving party node from the participating nodes corresponding to the target transaction set according to the rotation rule.

[0123] Optionally, when the rotation rule is based on the attribute parameters of each participating node, and the attribute parameters include at least one of a pledge parameter, a reputation parameter, and a certification number parameter, the processing module 11 is specifically used to obtain the attribute parameters of each participating node and the weight of the attribute parameters. According to the attribute parameters of each participating node and the weight of the attribute parameters, the target score of each participating node is determined. According to the target score, the target proving party node is determined from the participating nodes corresponding to the target transaction set.

[0124] Optionally, the processing module 11 is further used to update the attribute parameters of each participating node and / or the weight of the attribute parameters of each participating node according to the transaction history of each participating node.

[0125] Optionally, the processing module 11 is specifically used to determine the initial score of each participating node according to the attribute parameters of each participating node and the weight of the attribute parameters. Obtain the reward weight of each participating node, which is inversely proportional to the number of times each participating node has submitted proofs in history. Determine the target score of each participating node based on the initial score and the reward weight.

[0126] The blockchain transaction device provided in the embodiment of the present application can execute the blockchain transaction method on the server side in the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here.

[0127] Figure 8 This is a schematic diagram of the structure of another blockchain transaction device provided in an embodiment of the present application. Figure 8 As shown, the blockchain transaction device may include: an acquisition module 21, a processing module 22, and a control module 23.

[0128] The acquisition module 21 is used to acquire at least one transaction distributed by the blockchain service provider.

[0129] The processing module 22 is used to generate a first block and a first block proof of the first block according to at least one transaction distributed by the blockchain service provider.

[0130] The control module 23 is used to perform a transaction with a verification node based on the first block and the first block proof of the first block.

[0131] Optionally, the processing module 22 is specifically configured to obtain a certification key and a ciphertext certificate of the first block, wherein the ciphertext certificate includes a public input and a private input, and generate a first block certification of the first block according to the certification key and the ciphertext certificate.

[0132] The blockchain transaction device provided in the embodiment of the present application can execute the blockchain transaction method of the target prover node in the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here.

[0133] Fig. 9 This is a schematic diagram of the structure of another blockchain transaction device provided in an embodiment of the present application. Fig. 9 As shown, the blockchain transaction device may include: an acquisition module 31, a processing module 32, and a control module 33.

[0134] The acquisition module 31 is used to obtain a first block and a first block proof of the first block from the blockchain network, where the first block comes from a target proof node.

[0135] The processing module 32 is used to verify the first block certificate.

[0136] The control module 33 is used to perform a transaction according to the first block if the verification is passed, and record the transaction information of the transaction in the main chain of the blockchain.

[0137] Optionally, the processing module 32 is specifically configured to obtain a verification key, a private input, and the first block certificate corresponding to the certification key, and verify the first block certificate according to the verification key, the private input, and the first block certificate.

[0138] The blockchain transaction device provided in the embodiment of the present application can execute the blockchain transaction method of the verification party node in the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here.

[0139] Fig.10 The following is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. The electronic device is used to execute the aforementioned blockchain transaction method. Fig.10As shown, the electronic device 1000 may include: at least one processor 1001 , a memory 1002 , and a communication interface 1003 .

[0140] The memory 1002 is used to store programs. Specifically, the programs may include program codes, and the program codes include computer operation instructions.

[0141] The memory 1002 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0142] The processor 1001 is used to execute the computer-executable instructions stored in the memory 1002 to implement the method described in the above method embodiment. The processor 1001 may be a CPU, or an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0143] The processor 1001 can communicate and interact with external devices through the communication interface 1003. The external device can be, for example, the server of the aforementioned blockchain network. In specific implementation, if the communication interface 1003, the memory 1002 and the processor 1001 are implemented independently, the communication interface 1003, the memory 1002 and the processor 1001 can be connected to each other through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, etc., but it does not mean that there is only one bus or one type of bus.

[0144] Optionally, in a specific implementation, if the communication interface 1003, the memory 1002 and the processor 1001 are integrated on a chip, the communication interface 1003, the memory 1002 and the processor 1001 can communicate through an internal interface.

[0145] The present application also provides a computer-readable storage medium, which may include: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, and other media that can store program codes. Specifically, the computer-readable storage medium stores program instructions, and the program instructions are used for the methods in the above embodiments.

[0146] The present application also provides a program product, which includes an execution instruction, which is stored in a readable storage medium. At least one processor of a computing device can read the execution instruction from the readable storage medium, and at least one processor executes the execution instruction so that the computing device implements the above-mentioned blockchain transaction method.

[0147] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required by the present application.

[0148] It should be further noted that, although the various steps in the flowchart are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowchart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0149] It should be understood that the above-mentioned device embodiments are only illustrative, and the device of the present application can also be implemented in other ways. For example, the division of units / modules in the above-mentioned embodiments is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units, modules or components can be combined, or can be integrated into another system, or some features can be ignored or not executed.

[0150] In addition, unless otherwise specified, each functional unit / module in each embodiment of the present application may be integrated into one unit / module, each unit / module may exist physically separately, or two or more units / modules may be integrated together. The above-mentioned integrated unit / module may be implemented in the form of hardware or in the form of a software program module.

[0151] If the integrated unit / module is implemented in the form of hardware, the hardware may be a digital circuit, an analog circuit, etc. The physical implementation of the hardware structure includes but is not limited to transistors, memristors, etc. Unless otherwise specified, the processor may be any appropriate hardware processor, such as a CPU, a GPU, an FPGA, a DSP, an ASIC, etc. Unless otherwise specified, the storage unit may be any appropriate magnetic storage medium or magneto-optical storage medium, such as a resistive random access memory (RRAM), a dynamic random access memory (DRAM), a static random access memory (SRAM), an enhanced dynamic random access memory (EDRAM), a high-bandwidth memory (HBM), a hybrid memory cube (HMC), etc.

[0152] If the integrated unit / module is implemented in the form of a software program module and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a memory, including a number of instructions to enable a computer device (which can be a personal computer, server or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned memory includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk and other media that can store program codes.

[0153] In the above embodiments, the description of each embodiment has its own emphasis. For the part not described in detail in a certain embodiment, please refer to the relevant description of other embodiments. The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, all possible combinations of the technical features in the above embodiments are not described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0154] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0155] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A blockchain transaction method, characterized in that: include: Determining, based on dynamic selection, a target prover node from participating nodes corresponding to a target transaction set, the participating node being associated with at least one transaction in the target transaction set; Distribute at least one transaction in the target transaction set to the target prover node.

2. The method according to claim 1, characterized in that The method of determining the target prover node from the participating nodes corresponding to the target transaction set based on dynamic selection includes: The target prover node is randomly determined from the participating nodes corresponding to the target transaction set.

3. The method according to claim 1, characterized in that The method of determining the target prover node from the participating nodes corresponding to the target transaction set based on dynamic selection includes: Obtaining a rotation rule for determining a target proving party node; According to the rotation rule, a target prover node is determined from the participating nodes corresponding to the target transaction set.

4. The method according to claim 3, characterized in that The rotation rule is based on the attribute parameters of each of the participating nodes, wherein the attribute parameters include at least one of a pledge parameter, a reputation parameter, and a certification number parameter; determining the target proving party node from the participating nodes corresponding to the target transaction set according to the rotation rule includes: Obtaining attribute parameters of each participating node and weights of the attribute parameters; Determining a target score for each participating node according to the attribute parameters of each participating node and the weight of the attribute parameters; According to the target score, a target prover node is determined from the participating nodes corresponding to the target transaction set.

5. The method according to claim 4, characterized in that Also includes: According to the transaction history of each participating node, the attribute parameters of each participating node and / or the weight of the attribute parameters of each participating node are updated.

6. The method according to claim 5, characterized in that Determining the target score of each participating node according to the attribute parameters of each participating node and the weight of the attribute parameters includes: Determining an initial score of each participating node according to the attribute parameters of each participating node and the weight of the attribute parameters; Obtaining the reward weight of each participating node, where the reward weight is inversely proportional to the number of times each participating node has submitted proofs in history; A target score for each participating node is determined according to the initial score and the reward weight.

7. A blockchain transaction method, characterized in that: include: Obtain at least one transaction distributed by the blockchain service provider; Generate a first block and a first block certificate of the first block according to at least one transaction distributed by the blockchain service provider; Based on the first block and the first block proof of the first block, a transaction is performed with a verifier node.

8. The method according to claim 7, characterized in that The step of generating a first block certificate of the first block according to at least one transaction distributed by the blockchain service provider includes: Obtaining a certification key and a ciphertext certificate of the first block, wherein the ciphertext certificate includes a public input and a private input; Generate a first block certificate for the first block according to the certification key and the encrypted certificate.

9. A blockchain transaction method, characterized in that: include: Obtaining a first block from the blockchain network, and a first block proof of the first block, wherein the first block comes from a target prover node; Verifying the first block proof; If the verification is successful, the transaction is performed according to the first block, and the transaction information of the transaction is recorded in the main chain of the blockchain.

10. The method according to claim 9, characterized in that The verifying the first block proof includes: Obtaining a verification key, a private input, and the first block certificate corresponding to the certification key; The first block proof is verified according to the verification key, the private input, and the first block proof.

11. A blockchain transaction device, characterized in that: include: a processing module, configured to determine, based on dynamic selection, a target prover node from participating nodes corresponding to a target transaction set, wherein the participating node is associated with at least one transaction in the target transaction set; The transceiver module is used to distribute at least one transaction in the target transaction set to the target prover node.

12. A blockchain transaction device, characterized in that: include: An acquisition module, used to acquire at least one transaction distributed by a blockchain service provider; A processing module, configured to generate a first block and a first block certificate of the first block according to at least one transaction distributed by the blockchain service provider; A control module is used to conduct a transaction with a verification node based on the first block and the first block proof of the first block.

13. A blockchain transaction device, characterized in that: include: An acquisition module, configured to acquire a first block and a first block certificate of the first block from the blockchain network, wherein the first block comes from a target prover node; A processing module, configured to verify the first block certificate; The control module is used to perform a transaction according to the first block if the verification is passed, and record the transaction information of the transaction in the main chain of the blockchain.

14. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 10.

15. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 10 when executed by a processor.

Images