Block chain transaction processing method, related device and medium

Abstract

The invention provides a block chain transaction processing method, a related device and a medium. The method comprises the steps of receiving a transaction processing request sent by a target object; if the target transaction is a non-blockchain management transaction, sending the target transaction to a blockchain node for blockchain node verification; if the target transaction is the block chain management transaction, determining a permission initiating node list corresponding to the transaction type of the target transaction; if the target object belongs to the permission initiating node list, sending the target transaction to other permission initiating nodes in the permission initiating node list; if a predetermined number of signature blocks of other authority initiating nodes for the target transaction are received, aggregating the signature blocks into a target signature, and sending the target signature to a block chain node for block chain node verification; and if the block chain node passes verification, executing the target transaction and chaining the target transaction. The security of transaction processing can be improved. The method and the device can be applied to various scenes such as big data, block chains and cloud technologies.

Description

Technical Field

[0001] This disclosure relates to the field of blockchain technology, and in particular to a blockchain transaction processing method, related apparatus and medium. Background Technology

[0002] Currently, in blockchain systems, all operational permissions are executed on-chain, and these permissions are not differentiated, leading to confusion between blockchain management-related permissions and user permissions. For example, a blockchain management-related permission might be to add or remove a block from the blockchain. A user permission, on the other hand, might be to count the resources recorded on the blockchain. These two are distinct.

[0003] Both of the aforementioned operations involve authorization verification by blockchain nodes. For the latter operation, since it doesn't involve altering the blockchain itself, if a blockchain node acts maliciously and allows verification to succeed when it shouldn't, the harm is minimal. However, for the former operation, because it involves changing the blockchain itself, if a blockchain node acts maliciously and allows verification to succeed when it shouldn't, it will cause changes to the blockchain itself, posing a greater risk. Some attackers can exploit this to modify configurations, resulting in low security for blockchain transactions. Summary of the Invention

[0004] This disclosure provides a blockchain transaction processing method, related apparatus, and medium that can improve the security of transaction processing.

[0005] According to one aspect of this disclosure, a blockchain transaction processing method is provided, the method comprising:

[0006] Receive a transaction processing request sent by the target object, wherein the transaction processing request is used to execute the target transaction and put the target transaction on the blockchain;

[0007] If the target transaction is a non-blockchain management transaction, the target transaction is sent to a blockchain node for blockchain node verification;

[0008] If the target transaction is a blockchain management transaction, determine the transaction type of the target transaction;

[0009] Obtain the list of nodes with permission to initiate the transaction type;

[0010] If the target object belongs to the list of authorized initiating nodes, the target transaction is sent to other authorized initiating nodes in the list of authorized initiating nodes;

[0011] If a predetermined number of signature blocks for the target transaction are received from other authorized initiating nodes, the signature blocks are aggregated into a target signature and sent to the blockchain node for blockchain node verification. The predetermined number is less than the total number of other authorized initiating nodes.

[0012] If the blockchain node verifies the transaction, the target transaction is executed and recorded on the blockchain.

[0013] According to one aspect of this disclosure, a blockchain transaction processing apparatus is provided, the apparatus comprising:

[0014] A receiving unit is configured to receive a transaction processing request sent by a target object, wherein the transaction processing request is used to execute the target transaction and put the target transaction on the blockchain;

[0015] The verification unit is used to send the target transaction to the blockchain node for blockchain node verification if the target transaction is a non-blockchain management transaction.

[0016] A determining unit is configured to determine the transaction type of the target transaction if the target transaction is a blockchain management transaction;

[0017] The acquisition unit is used to acquire a list of nodes with permission to initiate the transaction corresponding to the transaction type;

[0018] The sending unit is configured to send the target transaction to other authorized initiating nodes in the authorized initiating node list if the target object belongs to the authorized initiating node list.

[0019] An aggregation unit is configured to, if it receives a predetermined number of signature blocks from other authorized initiating nodes for the target transaction, aggregate the signature blocks into a target signature and send it to the blockchain node for blockchain node verification, wherein the predetermined number is less than the total number of other authorized initiating nodes.

[0020] An execution unit is used to execute the target transaction and upload the target transaction to the blockchain if the blockchain node verifies the transaction.

[0021] Optionally, the predetermined number is determined in the following way:

[0022] Based on the transaction type and content of the target transaction, determine the importance score of the target transaction;

[0023] The predetermined number is determined based on the importance score.

[0024] Optionally, the list of authorized initiating nodes corresponding to the transaction type is determined by the target contract of the blockchain in the following way:

[0025] During the initialization of the blockchain, the target field of the genesis block of the blockchain is parsed to obtain the signer information;

[0026] Based on the signer information, node registration is performed to obtain multiple authorized nodes corresponding to the transaction type;

[0027] Based on the node information of each authorized initiating node, a list of authorized initiating nodes is constructed.

[0028] Optionally, the aggregation unit includes:

[0029] The verification module is used to verify the blockchain contract for each of the signature blocks;

[0030] An aggregation module is used to aggregate the signature blocks into a target signature if the blockchain contract verification of the predetermined number of signature blocks passes.

[0031] Optionally, the verification module includes:

[0032] The formal verification module is used to perform formal verification on each of the signature blocks.

[0033] The content verification module is used to perform signature block content verification on the signature block if the formal verification passes.

[0034] The determination module is used to determine that the blockchain contract verification of the signature block is successful if the content of the signature block is verified.

[0035] Optionally, the content verification module is used for:

[0036] Obtain the target public key of the other authorized initiating node that provides the signature block, and verify the content of the signature block based on the target public key;

[0037] If the content of the signature block is verified, then the candidate public keys of multiple candidate authorized initiating nodes in the list of authorized initiating nodes corresponding to the target transaction are obtained, and the target public key and the multiple candidate public keys are matched and verified.

[0038] Optionally, the content verification of the signature block based on the target public key includes:

[0039] The signature block is designed based on the target public key to obtain the designing result.

[0040] The transaction processing request is digested based on a predetermined digest algorithm to obtain a transaction digest result.

[0041] If the designing result is consistent with the transaction digest result, then the content verification of the signature block is determined to be successful.

[0042] Optionally, the matching and verification of the target public key and the multiple candidate public keys includes:

[0043] The target public key and each of the candidate public keys are compared.

[0044] If there is a candidate public key that is the same as the target public key, then the target public key is determined to match one of the candidate public keys, and the matching verification is determined to be successful.

[0045] If no candidate public key matches the target public key, then the target public key is determined not to match any of the candidate public keys, and the matching is determined not to pass verification.

[0046] Optionally, the formal verification module is used for:

[0047] For each of the signature blocks, the format of the signature block is validated;

[0048] For each signature block, the validity of the generation timestamp of the signature block is verified.

[0049] Optionally, the step of validating the generation timestamp of each signature block includes:

[0050] For each of the other authorized initiating nodes, determine the signature block timestamp of each candidate signature block provided by the other authorized initiating node for the target transaction, wherein the signature block is one of the multiple candidate signature blocks;

[0051] If it is determined that the generated timestamp is not earlier than the latest timestamp of the signature block, then the generated timestamp is determined to be valid.

[0052] Optionally, the aggregation unit is used for:

[0053] Determine the generation timestamp of each of the signature blocks;

[0054] Based on the order of the generated timestamps, the predetermined number of signature blocks are sorted.

[0055] According to the sorting, the predetermined number of signature blocks are aggregated using a predetermined signature function to obtain the target signature.

[0056] Optionally, the aggregation unit is used for:

[0057] Determine the priority of each of the other authorized nodes;

[0058] The signature blocks are sorted based on the node priority;

[0059] According to the sorting, the predetermined number of signature blocks are aggregated using a predetermined signature function to obtain the target signature.

[0060] Optionally, determining the priority of each of the other authorized initiating nodes includes:

[0061] For each of the other authorized initiating nodes, determine the creation timestamp and reputation of the other authorized initiating node;

[0062] Based on the creation timestamp and the reputation score, determine the node scores of the other nodes that have the authority to initiate the node.

[0063] Based on the scores of multiple nodes, the priority of each of the other nodes with the authority to initiate a node is determined.

[0064] Optionally, the blockchain node verifies the target signature using the following method:

[0065] For each of the blockchain nodes, the target signature is formally verified;

[0066] If the formal verification of the target signature is found to be successful, the signature content is verified based on the predetermined public key.

[0067] If the first number of blockchain nodes determine that the signature content of the target signature has been verified, then the blockchain node verification for the target signature has been confirmed as successful.

[0068] Optionally, the blockchain node verifies the target transaction using the following methods:

[0069] Determine the request timestamp of the transaction processing request for the target transaction and the transaction information of the target transaction;

[0070] The request timestamp of the transaction processing request for the target transaction is first verified;

[0071] A second verification is performed on the transaction information of the target transaction.

[0072] Optionally, the blockchain transaction processing device further includes a deletion unit, the deletion unit being used for:

[0073] In response to a node revocation request for the blockchain, the target node's public key and target node address are determined for the authorized initiating node to be revoked;

[0074] The target node's public key and address are cleared from the blockchain's predetermined log via the target contract.

[0075] Optionally, the blockchain transaction processing device further includes a new unit, the new unit being used for:

[0076] In response to a request to add a node to the blockchain, the public key of the target node, the organization to which the node belongs, and the address of the target node are determined.

[0077] The target node's public key, the organization to which the node belongs, and the target node's address are recorded in the blockchain's predetermined log through the target contract of the blockchain.

[0078] According to one aspect of this disclosure, an electronic device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the blockchain transaction processing method as described above.

[0079] According to one aspect of this disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program that, when executed by a processor, implements the blockchain transaction processing method as described above.

[0080] According to one aspect of this disclosure, a computer program product is provided, the computer program product including a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the blockchain transaction processing method as described above.

[0081] In this embodiment, blockchain transactions are divided into operations related to blockchain management and operations unrelated to blockchain management (such as user operations). Since operations unrelated to blockchain management do not involve changes to the blockchain itself, allowing malicious nodes to pass verification when it shouldn't pose a significant risk. Therefore, blockchain nodes can directly verify these non-blockchain management transactions, improving transaction processing efficiency. However, for operations related to blockchain management, which involve changes to the blockchain itself, allowing malicious nodes to pass verification when it shouldn't pose a significant risk, the following approach is used: First, it's determined which type of blockchain management transaction the target transaction is. Then, a list of authorized initiating nodes is obtained based on the transaction type. The target object is authenticated according to this list. After successful authentication, the target transaction is sent to other authorized initiating nodes for signatures indicating their agreement to execute the target transaction. When there are sufficient signature blocks from multiple authorized initiating nodes agreeing to execute the target transaction, these signature blocks are aggregated into a target signature and sent to the blockchain node for verification. This method specifically sets up multiple verifications for blockchain management transactions, improving the security of blockchain management transaction processing. In addition, since the blockchain node receives a target signature that is an aggregation of signature blocks from multiple other authorized initiating nodes, this can reduce the processing pressure on the blockchain node to some extent.

[0082] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0083] The accompanying drawings are provided to further understand the technical solutions of this disclosure and constitute a part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0084] Figure 1 This is a system architecture diagram of a blockchain transaction processing method applied according to an embodiment of the present disclosure;

[0085] Figures 2A-2D A schematic diagram illustrating the application of a blockchain transaction processing method according to an embodiment of the present disclosure in a transaction execution scenario is shown.

[0086] Figure 3 This is a flowchart of a blockchain transaction processing method according to an embodiment of the present disclosure;

[0087] Figure 4This is a schematic diagram illustrating the implementation process of dividing blockchain-managed transactions and non-blockchain-managed transactions according to an embodiment of this disclosure;

[0088] Figure 5 This is a schematic diagram of a list of authorized initiating nodes for blockchain management transactions according to an embodiment of this disclosure;

[0089] Figure 6 This is a flowchart illustrating the process of sending a target transaction to a blockchain node for blockchain node verification, according to an embodiment of this disclosure.

[0090] Figure 7 This is a flowchart of aggregating individual signature blocks into a target signature according to an embodiment of the present disclosure;

[0091] Figure 8 This is a flowchart of blockchain contract verification for each signature block according to an embodiment of the present disclosure;

[0092] Figure 9 This is a flowchart of formal verification of a signature block according to an embodiment of the present disclosure;

[0093] Figure 10 This is a flowchart of verifying the content of a signature block according to an embodiment of the present disclosure;

[0094] Figure 11 This is a flowchart illustrating content verification of a signature block based on a target public key according to an embodiment of this disclosure;

[0095] Figure 12 This is a flowchart illustrating the matching and verification of a target public key and multiple candidate public keys according to an embodiment of the present disclosure.

[0096] Figure 13 This is a flowchart of aggregating individual signature blocks into a target signature according to an embodiment of the present disclosure;

[0097] Figure 14 This is a flowchart of aggregating individual signature blocks into a target signature according to another embodiment of the present disclosure;

[0098] Figure 15 This is a flowchart illustrating the process of determining the priority of other authorized initiating nodes according to an embodiment of this disclosure;

[0099] Figure 16 This is a schematic diagram illustrating the implementation process of determining the priority of other authorized initiating nodes according to an embodiment of this disclosure;

[0100] Figure 17 This is a flowchart of blockchain node verification for a target signature according to an embodiment of the present disclosure;

[0101] Figure 18 This is a flowchart of the overall verification process for a target transaction according to an embodiment of the present disclosure;

[0102] Figure 19 This is a flowchart illustrating the construction of a list of authorized initiating nodes according to an embodiment of this disclosure;

[0103] Figure 20A This is a simplified schematic diagram of a target contract according to an embodiment of the present disclosure;

[0104] Figure 20B This is a schematic diagram illustrating the implementation process of registering an authorized initiating node according to an embodiment of this disclosure;

[0105] Figure 21 This is a flowchart illustrating the addition of a new authorized initiating node according to an embodiment of this disclosure;

[0106] Figures 22A-22B This is a schematic diagram illustrating the implementation process of adding a new authorized initiating node according to an embodiment of this disclosure;

[0107] Figure 23 This is a flowchart illustrating the revocation of an authorized initiating node according to an embodiment of this disclosure;

[0108] Figures 24A-24B This is a schematic diagram illustrating the process of revoking an authorized initiating node according to an embodiment of the present disclosure;

[0109] Figure 25 This is a schematic diagram illustrating the implementation details of a blockchain transaction processing method according to an embodiment of the present disclosure;

[0110] Figure 26 This is a block diagram of a blockchain transaction processing apparatus according to an embodiment of the present disclosure;

[0111] Figure 27 This is a terminal structure diagram of a blockchain transaction processing method according to an embodiment of the present disclosure;

[0112] Figure 28 This is a server architecture diagram of a blockchain transaction processing method according to an embodiment of the present disclosure. Detailed Implementation

[0113] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0114] Before providing a further detailed description of the embodiments of this disclosure, the terms and concepts used in these embodiments are explained, and they are subject to the following interpretations:

[0115] Artificial Intelligence (AI) is the theory, methods, technology, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to achieve optimal results. In other words, AI is a comprehensive technology within computer science that attempts to understand the essence of intelligence and produce a new kind of intelligent machine that can react in a way similar to human intelligence. AI studies the design principles and implementation methods of various intelligent machines, enabling them to have perception, reasoning, and decision-making capabilities. AI technology is a comprehensive discipline involving a wide range of fields, encompassing both hardware and software technologies. Fundamental AI technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, pre-trained model technology, operating / interactive systems, and mechatronics. Pre-trained models, also known as large models or foundational models, can be widely applied to downstream tasks in various AI fields after fine-tuning. AI software technologies mainly include computer vision, speech processing, natural language processing, and machine learning / deep learning. With the research and advancement of artificial intelligence (AI) technology, AI is being studied and applied in various fields, such as smart homes, smart wearable devices, virtual assistants, smart speakers, smart marketing, autonomous driving, drones, robots, smart healthcare, and smart customer service. It is believed that with the development of technology, AI will be applied in more fields and play an increasingly important role.

[0116] Blockchain: Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of transactions, used to verify the validity of the information (anti-counterfeiting) and to link it to the previous block.

[0117] System architecture and scenario description of the embodiments disclosed herein

[0118] Figure 1 This is a system architecture diagram of the blockchain transaction processing method applied according to embodiments of this disclosure. It includes an object terminal 140, an Internet 130, a gateway 120, a blockchain server 110, etc.

[0119] The object terminal 140 includes various forms such as desktop computers, laptops, PDAs (personal digital assistants), mobile phones, vehicle terminals, home theater terminals, and dedicated terminals. Furthermore, it can be a single device or a collection of multiple devices. The object terminal 140 can communicate with the Internet 130 via wired or wireless means to exchange data. Specifically, the object terminal 140 is used by various objects to submit transaction processing requests to the blockchain to execute various activities on the blockchain. The object terminal 140 has a transaction processing platform, which is used by objects to submit transaction processing requests to the blockchain and displays the blockchain server's feedback on various requests to the objects.

[0120] See Figure 1 The blockchain server 110 shown includes a consensus network 160. The consensus network 160 refers to the network that reaches a consensus on transactions to be added to the blockchain before adding them to the blockchain; it includes multiple consensus nodes. A consensus node is also a blockchain node. A consensus node or blockchain node can be a server in the blockchain network or an object terminal connected to the blockchain network; the specific form of the consensus node or blockchain node is not limited here.

[0121] Furthermore, the blockchain server 110 also includes a target contract 150, which is used to verify transaction processing requests submitted by objects related to blockchain management, so as to reduce the processing pressure on the blockchain nodes.

[0122] Gateway 120, also known as an internetwork connector or protocol converter, is a computer system or device that acts as a translator, enabling network interconnection at the transport layer. It bridges the gap between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateways can also provide filtering and security functions. Messages sent from object terminal 140 to blockchain server 110 are forwarded to the corresponding blockchain server 110 via gateway 120. Messages sent from blockchain server 110 to object terminal 140 are also forwarded to the corresponding object terminal 140 via gateway 120.

[0123] The embodiments disclosed herein can be applied in various scenarios, such as Figures 2A-2D The transaction execution scenarios shown are examples of this.

[0124] like Figure 2AAs shown, when an object wants to add a new blockchain node, it logs into the transaction processing platform on its terminal and triggers the transaction processing flow for adding the blockchain node. At this time, a prompt field "Please enter the node information for the new blockchain node" will appear on the page, providing editing areas for entering the node identifier and for entering the contract that the node verification depends on. Based on this, the object enters "K77" in the editing area for the node identifier and "Contract 1" in the editing area for the contract that the node verification depends on, and clicks the "Confirm" button to confirm the addition of a new blockchain node with the node identifier K77, which will be verified based on Contract 1.

[0125] like Figure 2B As shown, when the object clicks the "Confirm" button, the server will authenticate the object. After authentication, a prompt window will be displayed on the page: "Sorry, you do not have permission to add a blockchain node. This operation cannot be performed." This indicates that the object does not have permission to perform the operation. At this time, the object clicks the "OK" button, and the transaction of adding a blockchain node on the blockchain fails to be executed normally.

[0126] like Figure 2C As shown, when the object clicks the "Confirm" button, the server will authenticate the object. After authentication, a prompt window will be displayed on the page: "After verification, you have the permission to add a blockchain node. The request has been submitted to other signer parties for verification and permission. Please wait patiently..." This indicates that the object has submitted the request to add a blockchain node, but it needs further verification and permission from other objects with operation permissions before the transaction can be executed.

[0127] like Figure 2D As shown, after a period of time, a prompt window will appear on the page saying "Other objects with operation permissions have been verified and a node with node identifier K77 has been added to the blockchain as requested," indicating that the request has been executed. At this time, the object clicks the "OK" button to complete the operation of adding a blockchain node to the blockchain.

[0128] General Description of Embodiments in this Disclosure

[0129] According to one embodiment of this disclosure, a blockchain transaction processing method is provided.

[0130] This blockchain transaction processing method is generally applied in business scenarios where blockchain management-related operations are frequent, such as... Figures 2A-2DThe scenario illustrated is a transaction execution scenario. This disclosure provides a scheme to divide transactions to be processed into blockchain-managed transactions and non-blockchain-managed transactions, and to verify and execute them separately according to the division results, thereby improving the security of blockchain transaction processing.

[0131] like Figure 3 As shown, a blockchain transaction processing method according to an embodiment of this disclosure may include:

[0132] Step 310: Receive the transaction processing request sent by the target object;

[0133] Step 320: If the target transaction is a non-blockchain-managed transaction, send the target transaction to the blockchain node for blockchain node verification;

[0134] Step 330: If the target transaction is a blockchain-managed transaction, determine the transaction type of the target transaction;

[0135] Step 340: Obtain the list of nodes with permission to initiate transactions corresponding to the transaction type;

[0136] Step 350: If the target object belongs to the list of authorized initiating nodes, send the target transaction to other authorized initiating nodes in the list.

[0137] Step 360: If a predetermined number of signature blocks for the target transaction are received from other authorized initiating nodes, aggregate the signature blocks into the target signature and send it to the blockchain node for blockchain node verification.

[0138] Step 370: If the blockchain node verification is successful, execute the target transaction and upload the target transaction to the blockchain.

[0139] Steps 310-370 are described in detail below.

[0140] In step 310, a transaction processing request sent by the target object is received.

[0141] The target objects refer to users, organizations, etc., who submit various requests and perform various blockchain operations on the blockchain.

[0142] A transaction processing request is used to execute the target transaction and put the target transaction on the blockchain.

[0143] A target transaction refers to a series of transactions executed on the blockchain. For example, target transactions include, but are not limited to, resource interaction, information interaction, blockchain block updates, node additions and deletions, and resource queries.

[0144] In this specific implementation, when a target object wants to execute a transaction on the blockchain, it sends a transaction processing request to the blockchain and provides relevant transaction information related to the target transaction to be executed. Based on this, the blockchain server receives the transaction processing request sent by the target object, as well as the relevant transaction information provided by the target object.

[0145] In step 320, if the target transaction is a non-blockchain-managed transaction, the target transaction is sent to the blockchain node for blockchain node verification.

[0146] Non-blockchain management transactions refer to transactions that do not involve changes to the blockchain itself. They generally refer to transactions related to user operation permissions. For example, non-blockchain management transactions include, but are not limited to, counting the number of resources recorded on the blockchain, querying information recorded on the blockchain, and managing smart contracts on the blockchain.

[0147] A blockchain node refers to a consensus node on a blockchain, which is used to record various transactions submitted to the blockchain onto the chain.

[0148] To save space, the specific process of sending the target transaction to the blockchain node for blockchain node verification, as described in this embodiment, will be described in detail below. It will not be repeated here.

[0149] In step 330, if the target transaction is a blockchain management transaction, the transaction type of the target transaction is determined.

[0150] Blockchain management transactions refer to transactions that involve changes to the blockchain itself. Generally, they refer to blockchain management-related transactions, such as updating blocks in the blockchain, adding or deleting blockchain nodes, and modifying the block production interval of each consensus node in the blockchain.

[0151] The transaction type is used to indicate the category to which the target transaction belongs in the blockchain.

[0152] In the specific implementation of this embodiment, since blockchain management transactions include multiple different types of transactions—for example, modifying the block interval and adding or deleting blockchain nodes belong to different blockchain management transactions—it is necessary to determine the transaction type of the target transaction based on its content after determining that the target transaction is a blockchain management transaction.

[0153] For example, if the target transaction's content is to modify the blockchain's block interval to 30 seconds, and the target transaction is related to blockchain management, then the target transaction is determined to be a blockchain management transaction, and the transaction type is determined to be block interval modification.

[0154] like Figure 4The diagram illustrates the division of blockchain transactions into blockchain-managed transactions and non-blockchain-managed transactions before executing blockchain transaction processing methods. Specifically, blockchain-managed transactions are recorded in system contracts and include, but are not limited to, block updates (block_update), node additions (node_id_add), node deletions (node_id_delete), trust root additions (trust_root_add), and trust root updates (trust_root_update). For blockchain-managed transactions, only the administrator (first object admin) on the blockchain is granted the operation permission. For non-blockchain-managed transactions, they are recorded outside of system contracts and include, but are not limited to, contract management transactions and file management transactions. Contract management transactions include block update initialization contracts (initcontract) and contract services (contract invoke), while file management transactions include dumping, restoring, and querying. For non-blockchain-managed transactions, operation permissions are granted simultaneously to both the administrator (first object admin) and ordinary users (second object catenin) on the blockchain.

[0155] In step 340, the list of nodes with permission to initiate transactions corresponding to the transaction type is obtained.

[0156] The list of nodes with permission to initiate a transaction refers to a list of objects that have the permission to initiate the target transaction.

[0157] Having the authority to initiate a node generally refers to any object that engages in various blockchain activities on the blockchain.

[0158] In this specific implementation, since different transaction types in blockchain management transactions have their own distinct objects with operational permissions, these objects with operational permissions for each transaction type are recorded in the list of authorized initiating nodes corresponding to that transaction type. Therefore, for transaction processing security, object verification is performed on the target object to determine whether it truly possesses the operational permission to initiate the target transaction. Specifically, with authorization, based on the transaction type of the target transaction, the list of authorized initiating nodes corresponding to each type of blockchain management transaction is retrieved from the list of authorized initiating nodes on the blockchain.

[0159] like Figure 5As shown, for blockchain management transactions, when a node is added, the nodes with permission to initiate the transaction are Object 1, Object 2, and Object 3. When a node is deleted, the nodes with permission to initiate the transaction are Object 1, Object 2, and Object 3. When the block interval is modified, the nodes with permission to initiate the transaction are Object 1, Object 2, Object 3, Object 4, Object 5, Object 6, and Object 7. When a block is updated, the nodes with permission to initiate the transaction are Object 3, Object 5, and Object 7. Therefore, it is evident that for different types of blockchain management transactions, the nodes with permission to initiate the transaction may be the same or different.

[0160] In step 350, if the target object belongs to the list of authorized initiating nodes, the target transaction is sent to other authorized initiating nodes in the list.

[0161] Other authorized initiating nodes refer to other objects that are distinct from the target object and have the authority to initiate the target transaction.

[0162] In this specific implementation, firstly, the target object is compared with the list of authorized initiating nodes corresponding to the transaction type. If there is an authorized initiating node that matches the target object, the target object is considered to belong to the list of authorized initiating nodes. Based on this, the target transaction is sent to other authorized initiating nodes in the list so that they can determine whether to grant permission to execute the target transaction. Furthermore, if there is no authorized initiating node that matches the target object, the target object is considered not to belong to the list of authorized initiating nodes, indicating that the target object does not have permission to initiate the target transaction.

[0163] It should be noted that when determining whether the authorized initiating node is consistent with the target object, the judgment can be made based on the consistency of the index, identifier, or blockchain address of the authorized initiating node and the target object.

[0164] In step 360, if a predetermined number of signature blocks for the target transaction from other authorized initiating nodes are received, the signature blocks are aggregated into the target signature and sent to the blockchain node for blockchain node verification.

[0165] The predetermined number refers to the pre-set threshold for triggering signature block aggregation.

[0166] The signature block is used to indicate the approval status of other authorized nodes for executing the target transaction.

[0167] The target signature refers to the joint signature result of multiple authorized initiating nodes in the authorized initiating node list for the target transaction.

[0168] To save space, the specific process of aggregating the various signature blocks into a target signature and the specific process of verifying the target signature by blockchain nodes in this embodiment of the disclosure will be described in detail below. They will not be repeated here.

[0169] In step 370, if the blockchain node verification is successful, the target transaction is executed and uploaded to the blockchain.

[0170] In this specific implementation, if the blockchain node verification passes, it indicates that the number of blockchain nodes agreeing to execute the target transaction has reached the required level, and the target transaction can be executed on the blockchain. Based on this, the target transaction is executed on the blockchain and recorded on the chain. Conversely, if the blockchain node verification fails, it indicates that the number of blockchain nodes agreeing to execute the target transaction has not reached the required level, and executing the target transaction on the blockchain would pose a threat to the blockchain's security. Based on this, a message rejecting the transaction processing request is returned to the target object.

[0171] Through steps 310-370 above, this embodiment of the disclosure divides blockchain transactions into operations related to blockchain management and operations unrelated to blockchain management (such as user operations). Since operations unrelated to blockchain management do not involve changes to the blockchain itself, allowing a malicious node to pass verification when it should not pose a significant risk. Therefore, blockchain nodes can directly perform blockchain node verification for this type of non-blockchain management transaction, improving transaction processing efficiency. However, for operations related to blockchain management, which involve changes to the blockchain itself, allowing a malicious node to pass verification when it should pose a greater risk, the first step is to determine which type of blockchain management transaction the target transaction is, and then obtain a list of authorized nodes that can initiate the target transaction based on the transaction type. The target object is authenticated based on the list of authorized initiating nodes. After successful authentication, the target transaction is sent to other authorized initiating nodes for signatures indicating their agreement to execute the transaction. When there are enough signature blocks from multiple authorized initiating nodes agreeing to execute the target transaction, these signature blocks are aggregated into a target signature and sent to the blockchain node for verification. This method specifically sets up multi-layered verification for blockchain-managed transactions, which can improve the security of blockchain transaction processing. In addition, since the blockchain node receives a target signature aggregated from signature blocks from multiple authorized initiating nodes, this can also reduce the processing load on the blockchain node to some extent.

[0172] The above is a general description of steps 310-370. Since steps 310, 330-350 and 370 have been detailed in the above general description, the specific implementations of steps 320 and 360 will be described in detail below.

[0173] Detailed description of step 320

[0174] In step 320, if the target transaction is a non-blockchain-managed transaction, the target transaction is sent to the blockchain node for blockchain node verification.

[0175] In the specific implementation of this embodiment, if the target transaction is a non-blockchain-managed transaction, then if the blockchain node acts maliciously and allows the verification to pass even when it should not, the harm is not significant. Therefore, in order to improve transaction processing efficiency, the target transaction can be directly sent to the blockchain node for blockchain node verification.

[0176] Please refer to Figure 6 In some embodiments, blockchain nodes verify the target transaction in the following ways:

[0177] Step 610: Determine the request timestamp of the transaction processing request for the target transaction and the transaction information of the target transaction;

[0178] Step 620: Perform the first verification on the request timestamp of the transaction processing request for the target transaction;

[0179] Step 630: Perform a second verification on the transaction information of the target transaction.

[0180] Steps 610-630 are described in detail below.

[0181] In step 610, the request timestamp of the transaction processing request for the target transaction and the transaction information of the target transaction are determined.

[0182] The request timestamp is used to indicate the point in time when the transaction request was generated.

[0183] Transaction information indicates to the user the specific content and type of the target transaction.

[0184] In this specific implementation, since the request timestamp is carried in the transaction processing request, and the transaction information of the target transaction is provided by the target object when sending the transaction processing request, the transaction processing request can be parsed with authorization to obtain the request timestamp and the transaction information of the target transaction.

[0185] In step 620, the request timestamp of the transaction processing request for the target transaction is first verified.

[0186] In this specific implementation, firstly, the time difference between the requested timestamp and the current time is calculated; then, if the time difference meets a predetermined condition, the first verification of the target transaction is considered successful. If the time difference does not meet a predetermined condition, the first verification of the target transaction is considered unsuccessful, and a message indicating that the transaction processing request is rejected is returned to the target object.

[0187] In step 630, the transaction information of the target transaction is verified a second time.

[0188] In this specific implementation, firstly, the rules and format that the transaction information of the target transaction must follow are determined. Next, a formal verification of the target transaction information is performed based on the determined rules and format. If the target transaction information meets the requirements of the rules and format, the second verification of the target transaction is considered successful, and the blockchain node verification for the target transaction is determined to be successful. If the target transaction information does not meet the requirements of the rules and format, the second verification of the target transaction is considered unsuccessful, the blockchain node verification for the target transaction is determined to be unsuccessful, and a message rejecting the transaction processing request is returned to the target object.

[0189] The advantage of this embodiment is that it verifies the timeliness of the transaction processing request of the target transaction based on the request timestamp, and verifies the format and content of the target transaction based on the transaction information. In order to execute the target transaction when it is determined that the timeliness and correctness of the target transaction meet the requirements, the security of blockchain transaction processing can be improved.

[0190] Detailed description of step 360

[0191] In step 360, if a predetermined number of signature blocks for the target transaction from other authorized initiating nodes are received, the signature blocks are aggregated into the target signature and sent to the blockchain node for blockchain node verification.

[0192] In some embodiments, the predetermined number is determined in the following manner:

[0193] Based on the transaction type and content of the target transaction, determine the importance score of the target transaction;

[0194] The predetermined number is determined based on the importance score.

[0195] The transaction content indicates the specific content of the target transaction and what needs to be performed. The importance score indicates the degree of importance of the target transaction in blockchain management.

[0196] In the specific implementation of this embodiment, since transaction type and transaction content are often consistent, both referring to a type of blockchain management transaction, the transaction type is macroscopic, while the transaction content is concrete. Based on this, according to the transaction type and transaction content, the score corresponding to the transaction type of the target transaction is looked up in a predetermined lookup table indicating the correspondence between different types of blockchain management transactions and scores. The found score is used as the importance score of the target transaction. Next, the importance score is input into a preset function, and the output of the preset function is used as a predetermined number. The preset function is an increasing function with the transaction importance score as the independent variable and the predetermined number as the dependent variable.

[0197] For example, when the target transaction is a block interval modification, the importance score is lower, and the pre-assigned number is also lower. When the target transaction is a block update on the blockchain, or the addition or deletion of authorized nodes, the importance score is higher, and the pre-assigned number is also higher. However, the pre-assigned number is less than the total number of other authorized nodes in the authorized node list for the target transaction.

[0198] The advantage of this embodiment is that when the target transaction is a blockchain management transaction, different predetermined numbers are set for different types of blockchain management transactions according to the importance of the target transaction. For blockchain management transactions with high importance, it is desirable to generate an aggregate signature with more signer authorizations. For blockchain management transactions with lower importance, an aggregate signature is generated with relatively fewer signer authorizations. This improves the flexibility and rationality of setting the predetermined number and can improve the accuracy of aggregate signature generation.

[0199] Please refer to Figure 7 In some embodiments, step 360 specifically includes:

[0200] Step 710: Verify the blockchain contract for each signature block;

[0201] Step 720: If the blockchain contract verification of the predetermined number of signature blocks passes, then aggregate the signature blocks into the target signature.

[0202] Steps 710-720 are described in detail below.

[0203] In step 710, blockchain contract verification refers to the verification of the signature blocks submitted by the target contract in the blockchain against the signature blocks submitted by other authorized initiating nodes.

[0204] To improve the correctness and security of transaction processing, the validity of the signature information of the signature block is often verified during the blockchain contract verification process. This verification process includes, but is not limited to, verifying the format, content, and timestamp of the signature information of the signature block.

[0205] To save space, the specific process of blockchain contract verification for each signature block in this embodiment of the disclosure will be described in detail below. It will not be repeated here.

[0206] In step 720, if the blockchain contract verification of a predetermined number of signature blocks passes, it indicates that the number of valid signature blocks for the target transaction has reached the condition for triggering signature aggregation. Based on this, the predetermined number of signature blocks are aggregated into a single signature according to a fixed aggregation rule, and the aggregated signature is used as the target signature.

[0207] To save space, the specific process of aggregating the various signature blocks into a target signature according to the embodiments of this disclosure will be described in detail below. It will not be repeated here.

[0208] The advantage of this embodiment is that the same verification process is adopted for each signature block, and both formal and substantive verification of the signature information of the signature block are performed, resulting in good verification comprehensiveness. Furthermore, only when a predetermined number of verified signature blocks accumulate to trigger signature aggregation are these predetermined number of valid signature blocks aggregated to form a target signature (aggregated signature) corresponding to the target transaction. This realizes a transaction processing method where the target contract generates a single signature based on signature blocks provided by multiple signers, without requiring each signer to send their signature blocks individually to the blockchain node for verification. This reduces the burden of network transmission and the signature verification pressure on the blockchain node to some extent, thus improving the transaction processing performance and efficiency of the blockchain.

[0209] Please refer to Figure 8 In some embodiments, the specific process of performing blockchain contract verification for each signature block includes, but is not limited to, the following steps 810-830:

[0210] Step 810: Perform formal verification on each signature block;

[0211] Step 820: If the formal verification passes, then verify the content of the signature block.

[0212] Step 830: If the signature block content verification passes, the blockchain contract verification of the signature block is confirmed to be successful.

[0213] Steps 810-830 are described in detail below.

[0214] In step 810, a formal verification is performed on each signature block.

[0215] Formal verification refers to verifying the format, timestamp, and other information of the signature information in a signature block, but does not involve verifying the substantive content of the signature block.

[0216] Formal verification is used to verify whether the signature block meets the predetermined rules and format, and to verify whether the timestamp of the signature block is up-to-date.

[0217] To save space, the specific process of formally verifying the signature block according to the embodiments of this disclosure will be described in detail below. It will not be repeated here.

[0218] In step 820, if the formal verification passes, the signature block content is verified.

[0219] Signature block content verification refers to the authentication of the authorized node that provides the signature block and the verification of the substantive content of the signature information in the signature block.

[0220] The signature block content verification is used to verify whether the signature block was genuinely provided by the authorized initiating node corresponding to the target transaction, and to verify that the signature content in the signature block is consistent with the target transaction.

[0221] In the specific implementation of this embodiment, if the formal verification passes, it indicates that the signature information of the signature block conforms to the pre-set rules and format requirements, and the timestamp of the signature block is the latest. Then, the signature block content verification is further performed to verify the substantive content of the signature information of the signature block.

[0222] In addition, if the formal verification of the signature block fails, it indicates that the signature information of the signature block does not meet the pre-set rules and format requirements, or that the timestamp of the signature block is not up-to-date. In this case, the blockchain contract verification of the signature block is directly determined to be unsuccessful, and the signature block is invalid.

[0223] To save space, the specific process of verifying the signature block content in this embodiment of the present disclosure will be described in detail below. It will not be repeated here.

[0224] In step 830, if the signature block content verification passes, it indicates that the signature block meets the requirements in both form and substance, and the signature block is valid. Based on this, it is determined that the blockchain contract verification of the signature block has passed.

[0225] In addition, if the signature block content verification passes, it means that the signature block meets the requirements in form, but does not meet the requirements in substance. The signature block is invalid, and based on this, it is determined that the blockchain contract verification of the signature block fails.

[0226] The advantage of this embodiment is that the same verification process is adopted for each signature block, performing formal verification and substantive content verification on the signature information of each signature block, resulting in good verification comprehensiveness. Furthermore, during verification, the target contract first performs formal verification on each signature block, and only performs substantive verification after the formal verification passes. This serial verification approach effectively improves the rationality and standardization of verification.

[0227] Please refer to Figure 9 In some embodiments, the specific process of formally verifying the signature block includes, but is not limited to, the following steps 910-920:

[0228] Step 910: For each signature block, perform format verification on the signature block;

[0229] Step 920: For each signature block, verify the validity of the generation timestamp of the signature block.

[0230] Steps 910-920 are described in detail below.

[0231] In step 910, the format of each signature block is validated.

[0232] Format verification is used to verify whether the signature content of the signature block conforms to the predetermined format requirements.

[0233] In this specific implementation, when verifying the format of the signature block, the system verifies whether the signature block includes the public key of the authorized initiating node, a predetermined digest algorithm for performing a digest operation on the target transaction, and a signature result obtained by signing the digest result using the private key of the authorized initiating node. If the signature block contains all of the above information (public key, predetermined digest algorithm, signature result), the signature content of the signature block is considered to conform to the predetermined format requirements, and the format verification of the signature block passes. Conversely, if the signature block lacks at least one of the above information, the signature content of the signature block is considered to not conform to the predetermined format requirements, and the format verification of the signature block fails.

[0234] In step 920, for each signature block, the validity of the generation timestamp of the signature block is verified.

[0235] The timestamp of the signature block generation is used to indicate the time when other authorized nodes generated the signature block.

[0236] Since the signature blocks provided by each other permission-initiating node carry a generation timestamp, the signature blocks can be parsed with authorization to obtain the generation timestamp of the signature block.

[0237] The validity verification of the generation timestamp of the signature block is used to verify whether the generation timestamp of the signature block is the latest, that is, to verify whether the signature block is the last signature block generated by other authorized initiating nodes for the target transaction.

[0238] Specifically, the process of validating the generation timestamp of the signature block includes, but is not limited to, the following steps:

[0239] For each other authorized initiating node, determine the timestamp of the signature block for each candidate signature block for the target transaction provided by the other authorized initiating node. The signature block is one of multiple candidate signature blocks.

[0240] If it is determined that the generated timestamp is not earlier than the latest signature block timestamp, then the generated timestamp is considered valid.

[0241] Among them, the candidate signature block is the result of the authorized initiating node signing the target transaction at different points in time, and the product of the authorized initiating node repeatedly signing the target transaction.

[0242] In this specific implementation, for each other authorized initiating node, with authorization granted, firstly, the signature block timestamps of all candidate signature blocks for the target transaction provided by this authorized initiating node are obtained. Next, the latest signature block timestamp is determined from among the multiple signature block timestamps. Further, the generation timestamp of the signature block to be used to generate the aggregate signature is compared with this latest signature block timestamp. If the generation timestamp and the latest signature block timestamp are the same, then the generation timestamp is not earlier than the latest signature block timestamp, indicating that the selected signature block is the last candidate signature block generated by the authorized initiating node, and its generation timestamp is the most recent. Therefore, the generation timestamp of the signature block is determined to be valid, and the formal verification of the signature block passes.

[0243] Conversely, if the generation timestamp is different from the latest signature block timestamp, and the generation timestamp is earlier than the latest signature block timestamp, it indicates that the selected signature block is not the last candidate signature block generated by the authorized initiating node, and the generation timestamp is not the latest. Therefore, the generation timestamp of the signature block is determined to be invalid, and the formal verification of the signature block fails.

[0244] For example, if an authorized initiating node does not approve the execution of the target transaction at an earlier point in time, it will provide a candidate signature block indicating its disagreement with the signature result. However, if, after some time, this authorized initiating node changes its mind and approves the execution of the target transaction, wanting to change the signature, it will provide a candidate signature block at a later time, indicating its agreement with the signature result. In this case, the candidate signature block with the later timestamp should be used as the final signature block.

[0245] The advantage of this embodiment is that when performing formal verification on the signature block, the format and timestamp of the signature block are verified accordingly. Only when it is determined that the format of the signature block meets the requirements and the signature block is up-to-date, further verification of the signature block is then performed. This allows for verification of the signature block from multiple dimensions, improving the accuracy of signature block verification.

[0246] Please refer to Figure 10 In some embodiments, the specific process of verifying the content of the signature block includes, but is not limited to, the following steps 1010-1020:

[0247] Step 1010: Obtain the target public key of other authorized initiating nodes that provide the signature block, and verify the content of the signature block based on the target public key;

[0248] Step 1020: If the content of the signature block is verified, obtain the candidate public keys of multiple candidate authorized initiating nodes in the list of authorized initiating nodes corresponding to the target transaction, and match and verify the target public key and the multiple candidate public keys.

[0249] Steps 1010-1020 are described in detail below.

[0250] In step 1010, the target public key of other authorized initiating nodes that provide the signature block is obtained, and the content of the signature block is verified based on the target public key.

[0251] The target public key refers to the public key corresponding to the private key used by other authorized nodes to sign various transactions to be added to the blockchain. The target public key is generally publicly available.

[0252] In this specific implementation, firstly, the target public key publicly disclosed by another authorized initiating node is obtained from an authorized initiating node or a trusted third-party platform. Next, the signature block is designed using the target public key, and the designing result is verified to determine that the signature content of the signature block is correct.

[0253] To save space, the specific process of verifying the content of the signature block based on the target public key in this embodiment of the present disclosure will be described in detail below. It will not be repeated here.

[0254] In step 1020, if the content of the signature block is verified, the candidate public keys of multiple candidate authorized initiating nodes in the list of authorized initiating nodes corresponding to the target transaction are obtained, and the target public key and the multiple candidate public keys are matched and verified.

[0255] Candidate authorized initiating nodes refer to the nodes in the same authorized initiating node list that have the authority to initiate a transaction for a specific transaction type.

[0256] Candidate public keys refer to the keys that each candidate authorized initiating node publicly discloses, and correspond to the private keys used by the candidate authorized initiating nodes when signing each transaction to be added to the chain.

[0257] Match verification is used to determine whether other authorized initiating nodes are among the candidate authorized initiating nodes based on the matching of the target public key and the candidate public key.

[0258] In this specific implementation, if the content verification of the signature block passes, it indicates that the signature content of the signature block is correct. Based on this, the identity of the authorized initiating node that submitted the signature block is further verified. The specific process of obtaining the candidate public keys of multiple candidate authorized initiating nodes in the list of authorized initiating nodes corresponding to the target transaction is similar to the specific process of obtaining the target public key in step 1010 above. To save space, it will not be described in detail.

[0259] The specific process of matching and verifying the target public key and multiple candidate public keys according to the embodiments of this disclosure is described in detail below. It will not be repeated here.

[0260] The advantage of this embodiment is that when verifying the signature content of the signature block, the designing result of the signature block and the identity of the node that submitted the signature block with the authority to initiate it are both verified accordingly. If it is determined that the signature content in the signature block is for the target transaction and the node that submitted the signature block with the authority to initiate it is indeed a node with the authority to initiate the target transaction, the contract verification of the signature block is determined to be successful. The signature block can be verified in multiple dimensions, thereby improving the accuracy of the signature block verification.

[0261] Please refer to Figure 11 In some embodiments, the specific process of verifying the content of the signature block based on the target public key includes, but is not limited to, the following steps 1110-1130:

[0262] Step 1110: Design the signature block based on the target public key to obtain the designing result;

[0263] Step 1120: Perform a digest operation on the transaction processing request based on the predetermined digest algorithm to obtain the transaction digest result;

[0264] Step 1130: For each signature block, verify the validity of the generation timestamp of the signature block.

[0265] Steps 1110-1130 are described in detail below.

[0266] In step 1110, the signature block is de-signed based on the target public key to obtain the de-signing result.

[0267] The decryption result is used to indicate what the unencrypted content of the signed block actually looks like.

[0268] In the specific implementation of this embodiment, the target public key is used to decrypt the signature block in order to perform the designing process of the signature block, and the result after decryption is used as the designing result.

[0269] Since the signature block is usually obtained by the authorized initiating node using a predefined digest algorithm to perform a digest operation on the message and encrypting the digest result with its own private key, the designing result is generally a digest value.

[0270] In step 1120, a digest operation is performed on the transaction processing request based on a predetermined digest algorithm to obtain the transaction digest result.

[0271] A predefined hash algorithm indicates the algorithm used to perform hash operations on a blockchain management transaction of a specific transaction type. A predefined hash algorithm is a hash function that maps input data of arbitrary length to output data of fixed length; the output data is the hash. Different types of blockchain management transactions may use the same or different predefined hash algorithms.

[0272] It should be noted that the predefined hash algorithm includes, but is not limited to, Message Digest Algorithm (MD5), Secure Hash Algorithm (SHA), etc., without specific restrictions.

[0273] The transaction summary result indicates the summary value obtained after the target transaction has undergone a summary operation. The transaction summary result is used to uniquely represent the target transaction as a random string.

[0274] In this specific implementation, firstly, the various contents of the transaction processing request are concatenated in the same order as those followed when generating the signature block, resulting in a concatenated result. Next, a predetermined digest algorithm is used to perform a digest operation on the concatenated result, converting it into a fixed-length random string, thus obtaining the transaction digest result.

[0275] In step 1130, if the designing result is consistent with the transaction digest result, then the content verification of the signature block is determined to be successful.

[0276] In this specific implementation, firstly, the designing result is compared with the transaction digest result. Next, if the designing result matches the transaction digest result, it indicates that the signature content of the signature block is digested and signed for the target transaction, and the content verification of the signature block is determined to be successful. Conversely, if the designing result does not match the transaction digest result, it indicates that the signature content of the signature block is not digested and signed for the target transaction, and the content verification of the signature block is determined to be unsuccessful.

[0277] The advantage of this embodiment is that when performing blockchain contract verification on the signature block, it takes into account the verification of the correctness of the signature content of the signature block, decrypts the signature content of the signature block to obtain the digest result of the authorized initiating node for a transaction, and uses the same predetermined digest algorithm to calculate the digest result of the target transaction. Based on the consistency of the two digest results, it determines whether the signed transaction is the target transaction, which can improve the efficiency and convenience of verifying the correctness of the signature content.

[0278] Please refer to Figure 12 In some embodiments, the specific process of matching and verifying the target public key and multiple candidate public keys includes, but is not limited to, the following steps 1210-1230:

[0279] Step 1210: Compare the target public key with each candidate public key;

[0280] Step 1220: If there is a candidate public key that is the same as the target public key, then determine that the target public key matches one of the multiple candidate public keys, and determine that the matching verification is successful;

[0281] Step 1230: If no candidate public key is the same as the target public key, then it is determined that the target public key does not match multiple candidate public keys, and the matching verification fails.

[0282] Steps 1210-1230 are described in detail below.

[0283] In step 1210, the target public key and each candidate public key are compared.

[0284] In the specific implementation of this embodiment, for each candidate public key, the candidate public key is compared with the target public key to determine whether the candidate public key and the target public key are the same.

[0285] In step 1220, if there is a candidate public key that is the same as the target public key, then the target public key is determined to match one of the multiple candidate public keys, and the matching verification is confirmed to be successful.

[0286] In this specific implementation, if a candidate public key is identical to the target public key, it indicates that the other authorized initiating node providing the signature block is a candidate authorized initiating node from the list of authorized initiating nodes corresponding to the target transaction, and the signature block provided by this other authorized initiating node is valid. Therefore, it is determined that the target public key matches one of the multiple candidate public keys, and the matching verification is confirmed to be successful.

[0287] In step 1230, if no candidate public key is the same as the target public key, it is determined that the target public key does not match multiple candidate public keys, and the matching verification fails.

[0288] In this specific implementation, if no candidate public key matches the target public key, it indicates that the other authorized initiating node providing the signature block is not a candidate authorized initiating node in the list of authorized initiating nodes corresponding to the target transaction, and the signature block provided by this other authorized initiating node is invalid. Therefore, it is determined that the target public key does not match multiple candidate public keys, and the matching verification fails.

[0289] For example, Figure 5 In this scenario, when the target transaction is a node deletion transaction, the authorized initiating nodes for the target transaction include Object 1, Object 2, and Object 3. If a transaction processing request for the target transaction is mistakenly sent to Object 4, and Object 4 provides a signature block for the target transaction, without authenticating Object 4, the signature block provided by Object 4 will be aggregated with signature blocks provided by other objects to form the target signature, assuming the signature content is correct. This will lead to an error in the target signature. Therefore, an authentication step for Object 4 is introduced. After Object 4 provides its signature block, its public key is compared with the public keys of Object 1, Object 2, and Object 3. It is found that Object 4's public key is different from all the other public keys, indicating that Object 4 is not a node in the list of authorized initiating nodes for the target transaction, and its provided signature block is invalid.

[0290] The advantage of this embodiment is that by comparing the target public key with the candidate public keys of each candidate authorized initiating node in the list of authorized initiating nodes for the target transaction, the node identity of other authorized initiating nodes that provide the signature block can be clearly and concisely determined. This can exclude signature blocks incorrectly provided by the list of authorized initiating nodes that are not related to the target transaction from the signature aggregation, reduce the risk of using incorrect or invalid signature blocks to achieve signature aggregation, and improve the accuracy of the validity verification of the signature block.

[0291] Please refer to Figure 13 In some embodiments, the specific process of aggregating the individual signature blocks into a target signature includes, but is not limited to, the following steps 1310-1330:

[0292] Step 1310: Determine the generation timestamp of each signature block;

[0293] Step 1320: Sort a predetermined number of signature blocks based on the time of their generation timestamps;

[0294] Step 1330: For each signature block, verify the validity of the generation timestamp of the signature block.

[0295] Steps 1310-1330 are described in detail below.

[0296] In step 1310, the generation timestamp of each signature block is determined.

[0297] In the specific implementation of this embodiment, the process of step 1310 is similar to that of step 920 described above. To save space, it will not be described again.

[0298] In step 1320, a predetermined number of signature blocks are sorted based on the time of generation of the timestamp.

[0299] In this specific implementation, firstly, the generation timestamps of each signature block are compared to determine their order of origin. Next, a predetermined number of signature blocks are arranged in ascending order of their generation timestamps, resulting in a sorting. In this sorting, signature blocks with earlier generation timestamps are placed at the beginning, and those with later generation timestamps are placed at the end.

[0300] In step 1330, according to the sorting, a predetermined number of signature blocks are aggregated using a predetermined signature function to obtain the target signature.

[0301] A predefined signature function is a function constructed according to signature reconstruction rules, and its execution method is consistent with the signature reconstruction rules. Signature reconstruction rules are used to instruct how to reassemble multiple signature blocks to derive a complete signature, and signature reconstruction rules often depend on the execution of signature functions.

[0302] In this specific implementation, firstly, multiple signature blocks are input into a predetermined signature function in order. The predetermined signature function analyzes the signature content of the multiple signature blocks, derives the dependencies between the signature blocks, and further derives the missing signature content needed to generate the target signature, thereby achieving the reorganization of multiple signature blocks and the completion of signature content. Finally, the output of the predetermined signature function is used as the target signature.

[0303] The advantage of this embodiment is that when aggregating multiple signature blocks, the generation time of each signature block is taken into account. By aggregating a predetermined number of signature blocks according to the order of their generation time, the aggregated target signature can have better continuity in the time dimension, thereby improving the signature quality of the aggregated target signature.

[0304] Please refer to Figure 14 In some embodiments, the specific process of aggregating the individual signature blocks into a target signature includes, but is not limited to, the following steps 1410-1430:

[0305] Step 1410: Determine the priority of each other node that has the authority to initiate a node;

[0306] Step 1420: Sort the signature blocks based on node priority;

[0307] Step 1430: According to the sorting, use the pre-defined signature function to aggregate a predetermined number of signature blocks to obtain the target signature.

[0308] Steps 1410-1430 are described in detail below.

[0309] In step 1410, the priority of each other node with the authority to initiate a node is determined.

[0310] Node priority is used to indicate the importance of other authorized nodes. The more important the other authorized node, the higher its priority.

[0311] To save space, the specific process for determining the priority of other authorized initiating nodes in this embodiment will be described in detail below. It will not be repeated here.

[0312] In step 1420, the signature blocks are sorted based on node priority.

[0313] In this specific implementation, firstly, the node priorities of each signature block are compared to determine the priority of each generated timestamp. Next, based on the order of the generated timestamps, a predetermined number of signature blocks are arranged in descending order of node priority, resulting in a sort. In this sort, signature blocks with higher node priorities are placed earlier, and those with lower node priorities are placed later.

[0314] In step 1430, according to the sorting, a predetermined number of signature blocks are aggregated using a predetermined signature function to obtain the target signature.

[0315] In the specific implementation of this embodiment, the specific process of step 1430 is similar to that of step 1330 described above. To save space, it will not be described again.

[0316] The advantage of this embodiment is that when aggregating multiple signature blocks, the priority of the authorized initiating nodes that generated each signature block is taken into account. By aggregating a predetermined number of signature blocks according to the priority of the authorized initiating nodes, the important signature content of the aggregated target signature becomes more prominent, and the distinguishability of the aggregated target signature originating from signature information from different authorized initiating nodes is improved.

[0317] Please refer to Figure 15 In some embodiments, the specific process for determining the priority of each other authorized initiating node includes, but is not limited to, the following steps 1510-1530:

[0318] Step 1510: For each other authorized initiating node, determine the creation timestamp and reputation of the other authorized initiating nodes;

[0319] Step 1520: Based on the creation timestamp and reputation, determine the scores of other nodes that have the authority to initiate nodes;

[0320] Step 1530: Based on the scores of multiple nodes, determine the priority of each other node that has the authority to initiate a node.

[0321] Steps 1510-1530 are described in detail below.

[0322] In step 1510, for each other authorized initiating node, the creation timestamp and reputation of the other authorized initiating node are determined.

[0323] A timestamp is created to indicate the point in time when other authorized nodes join the blockchain.

[0324] Reputation is used to indicate the creditworthiness of other authorized nodes in blockchain activities.

[0325] In this specific implementation, since the creation timestamps and reputation information of each authorized initiating node are recorded in the background log of the blockchain server, with authorization, the creation timestamps and reputation information of each authorized initiating node can be extracted from the background log of the blockchain server.

[0326] In step 1520, the node scores of other authorized nodes are determined based on the creation timestamp and reputation.

[0327] Node scores are used to quantify the importance of other authorized nodes in deciding whether to execute a target transaction.

[0328] In this specific implementation, firstly, a first score is determined based on the creation timestamp; then, a second score is determined based on reputation; finally, the scores of other nodes with the authority to initiate nodes are determined based on the weighted sum of the first and second scores.

[0329] Specifically, first, a preset mapping table is obtained, which contains multiple time intervals and their corresponding scores. Next, the time interval containing the creation timestamp is found in the preset mapping table, and the score corresponding to that time interval is used as the first score. Further, the reputation scores of other authorized initiating nodes are substituted into a preset function, and the output of this function is used as the second score. This preset function is an increasing function with reputation score as the independent variable and the second score as the dependent variable. Finally, according to preset first and second weights, the product of the first weight and the first score, and the product of the second weight and the second score, are added together to obtain the node scores of the other authorized initiating nodes.

[0330] In step 1530, the priority of each other authorized node is determined based on the scores of multiple nodes.

[0331] In the specific implementation of this embodiment, firstly, based on the node scores of each other authorized initiating node, the other authorized initiating nodes are arranged in descending order of their node scores. Next, according to the sorting order, the node priority of each other authorized initiating node is determined.

[0332] like Figure 16 The table shown is a mapping between the reputation, creation time, and node score of authorized nodes initiating a target transaction. Specifically, both the first and second weights are set to 0.5. Based on this, for object 1 with a first score of 88 and a second score of 80, the node score is 84. For object 2 with a first score of 90 and a second score of 82, the node score is 86. For object 3 with a first score of 76 and a second score of 78, the node score is 77. For object 4 with a first score of 65 and a second score of 75, the node score is 70. For object 5 with a first score of 78 and a second score of 84, the node score is 81. For object 6 with a first score of 44 and a second score of 66, the node score is 55. For object 7 with a first score of 82 and a second score of 86, the node score is 84.

[0333] The advantage of this embodiment is that, when determining the priority of each other authorized initiating node, it integrates the creation timestamp and reputation of each other authorized initiating node, realizing multi-parameter priority judgment. At the same time, it introduces scoring mechanisms and weighted calculations to quantify the importance of other authorized initiating nodes in deciding whether to execute the target transaction, thereby determining the node priority based on the node score, which can improve the accuracy of determining the node priority.

[0334] Please refer to Figure 17 In some embodiments, blockchain nodes verify the target signature using the following methods:

[0335] Step 1710: For each blockchain node, perform formal verification of the target signature;

[0336] Step 1720: If the formal verification of the target signature is successful, then verify the signature content of the target signature based on the predetermined public key;

[0337] Step 1730: If the first number of blockchain nodes determine that the signature content of the target signature has been verified, then the blockchain node verification of the target signature has been confirmed.

[0338] Steps 1710-1730 are described in detail below.

[0339] In step 1710, the target signature is formally verified for each blockchain node.

[0340] In the specific implementation of this embodiment, the process of step 1710 is similar to that of steps 910-920 described above. To save space, it will not be described again.

[0341] In step 1720, if the formal verification of the target signature is found to be successful, the signature content of the target signature is verified based on the predetermined public key.

[0342] In the specific implementation of this embodiment, the process of step 1720 is similar to that of steps 1010-1020 described above. To save space, it will not be described again.

[0343] In step 1730, if the first number of blockchain nodes determine that the signature content of the target signature has been verified, then the blockchain node verification of the target signature has been determined to be successful.

[0344] The first number is used to define the conditions for triggering the execution and on-chain recording of the target transaction based on the signature verification of blockchain nodes. The value of the first number is often set to more than half of the total number of blockchain nodes.

[0345] In this specific implementation, if a first number of blockchain nodes determine that the signature content of the target signature has passed verification, it indicates that more than half of the blockchain nodes determine that the target signature is valid. Based on this, the blockchain nodes that have verified the target signature have passed verification, and the target transaction is executed and uploaded to the blockchain. Conversely, if the number of blockchain nodes that have verified the signature content of the target signature is less than the first number, it indicates that less than half of the blockchain nodes have determined that the target signature is valid. The blockchain nodes that have verified the target signature have failed verification, the target transaction is not executed, and a message indicating refusal to execute the transaction processing request is returned to the target object.

[0346] The advantage of this embodiment is that, for the signature verification of a target transaction, the blockchain node only needs to verify one target signature, instead of verifying the signature blocks submitted by each signer (other authorized initiating nodes) separately. This reduces the complexity of signature verification and also reduces the signature verification pressure on the blockchain node. Compared to multi-signature, the target signature only needs to be verified once, and compared to single signature, the target signature is jointly determined by multiple signers. This approach can improve the security and reliability of blockchain node verification while reducing network transmission pressure and node computing pressure.

[0347] like Figure 18 The diagram illustrates the overall implementation process of transaction execution and on-chain processing for blockchain management transactions. Specifically, the other authorized initiating nodes in the list of authorized initiating nodes for the target transaction include First Object 1, First Object 2, and First Object 3. First Object 1, First Object 2, and First Object 3 each send a signature block `sign(x)` for the target transaction to the target contract ASM, where `x` is the digest result of the digest operation on the target transaction. Next, the target contract verifies each signature block according to the transaction permission rules for the target transaction recorded in the system contract. If the signature block verification fails, it is marked as failed, and the verification result is directly returned to the First Object that submitted the signature block. If the signature block verification passes, it is marked as valid, and the specific process is similar to steps 810-830 above. Furthermore, when the number of valid signature blocks reaches the aggregate signature threshold, an aggregate signature is generated based on a predetermined number of valid signature blocks. Finally, the generated target signature is submitted to the blockchain node for signature verification, a process similar to steps 1710-1730 above. Once signature verification is successful, the target transaction is executed and recorded on the blockchain. To save space, further details are omitted.

[0348] Detailed description of an embodiment of this disclosure of constructing a list of authorized initiating nodes.

[0349] Since the blockchain system maintains signer information for different transaction types during the initialization phase, and this signer information includes the signer path, the organization to which the signer belongs, etc., in order to improve the accuracy and efficiency of constructing the list of authorized initiating nodes for each transaction, this disclosure provides a scheme for constructing the list based on the initialization information of the blockchain system.

[0350] The authorized initiating node category in this disclosure is created by the target contract in the blockchain and stored on the blockchain.

[0351] Please refer to Figure 19 In some embodiments, the specific process by which the target contract constructs the list of authorized nodes may include, but is not limited to, the following steps 1910-1930:

[0352] Step 1910: During blockchain initialization, the target field of the genesis block of the blockchain is parsed to obtain the signer information;

[0353] Step 1920: Register nodes based on the signer information to obtain multiple authorized nodes corresponding to the transaction type;

[0354] Step 1930: Based on the node information of each authorized initiating node, construct a list of authorized initiating nodes.

[0355] Steps 1910-1930 are described in detail below.

[0356] In step 1910, during blockchain initialization, the target field of the genesis block of the blockchain is parsed to obtain the signer information.

[0357] The genesis block refers to the first block on the blockchain.

[0358] The target field refers to the trusted root node field (trust_roots) in the genesis block.

[0359] Signer information refers to the information recorded in the genesis block about the objects or nodes on the blockchain that have the authority to initiate transactions of a certain type from the very beginning.

[0360] In the specific implementation of this embodiment, during blockchain initialization, the target contract automatically parses the target field of the blockchain's genesis block, obtains the current list of administrators from the target field on the blockchain, and uses the relevant information of each administrator recorded in the administrator list as the signer information.

[0361] In step 1920, node registration is performed based on the signer information to obtain multiple authorized nodes corresponding to the transaction type.

[0362] Node registration refers to generating a list of authorized nodes for each transaction type based on the signer information, which means writing the signer information into the target contract.

[0363] In this specific implementation, the target contract stores a node registration method. Based on this, the node registration method of the target contract is first called to parse the signer information, obtaining information such as the transaction types that each signer has the authority to initiate, the signer's public key, and the signer's address. Then, based on the transaction types that each signer has the authority to initiate, the signer's public key, and the signer's address, multiple authorized initiating nodes corresponding to each transaction type are determined.

[0364] In step 1930, a list of authorized initiating nodes is constructed based on the node information of each authorized initiating node.

[0365] Node information refers to information such as the public key and address of the signer for each authorized node.

[0366] In this specific implementation, based on the node information of each authorized initiating node, the node information of the authorized initiating node and the transaction types that the authorized initiating node has the authority to initiate are stored in the form of key-value pairs to obtain a list of authorized initiating nodes. In this list, the transaction type that each authorized initiating node has the authority to initiate is the key, and the public key and address of the signer of the authorized initiating node are the value.

[0367] like Figure 20A The diagram shown is a simplified representation of the target contract. This disclosed target contract can also be called the Aggregate SignatureManager contract. The target contract implements methods such as signer registration, signer revocation, and signature block verification. The signer registration process involves information such as the signer's public key (pubkey) and address. The aggregate signature threshold process involves information such as the threshold value. The signer revocation process involves information such as the signer's public key (pubkey) and address.

[0368] like Figure 20BAs shown, during the initialization of the blockchain cluster, the target field `trust_roots` records the information of the current administrators. These administrators include First Object 1 (admin1) belonging to Organization 1 (org1), First Object 2 (admin2) belonging to Organization 2 (org2), and so on. Next, based on the information extracted from the target field, First Object 1, First Object 2, and First Object 3 are designated as three authorized initiating nodes, and the registration method of the target contract ASM is called to register the nodes.

[0369] The advantage of this embodiment is that the target contract automatically constructs a list of authorized initiating nodes for each transaction based on the relevant information of the administrator list in the target field of the blockchain, thereby improving the accuracy and efficiency of constructing the list of authorized initiating nodes for each transaction.

[0370] Detailed description of adding or removing authorized initiating nodes according to an embodiment of this disclosure

[0371] Because the permissions of various objects on the blockchain often need to be adjusted at different times—for example, if an object has poor credibility but still possesses the relevant operational permissions for blockchain transaction management, it will lead to a decrease in the security of blockchain transaction processing—this disclosure provides a scheme for adding and deleting authorized nodes. This improves the convenience of permission changes and the accuracy of permission updates, thereby enhancing the security of blockchain transaction processing.

[0372] Please refer to Figure 21 In some embodiments, the specific process of adding a new authorized initiating node on the blockchain may include, but is not limited to, the following steps 2110-2120:

[0373] Step 2110: In response to a request to add a new node for the blockchain, determine the public key of the target node, the organization to which the node belongs, and the address of the target node for which the authorized node to be added is located.

[0374] Step 2120: Through the target contract of the blockchain, record the public key of the target node, the organization to which the node belongs, and the address of the target node in the predetermined log of the blockchain.

[0375] Steps 2110-2120 are described in detail below.

[0376] In step 2110, when the target object wants to add an administrator to the blockchain, it initiates a node addition request on the blockchain, providing information such as the public key of the authorized node to be added, the organization to which the node belongs, and the address of the target node. Based on this, the server responds to the node addition request on the blockchain, receiving the public key of the authorized node to be added, the organization to which the node belongs, and the address of the target node.

[0377] In step 2120, after the node addition request is verified in steps 310-370 above, the node registration process in steps 1910-1930 above is executed using the target contract of the blockchain. The target node's public key, the organization to which the node belongs, and the target node's address are recorded in the blockchain's predetermined log. The latest administrator information is stored in the target field trust_roots of the predetermined log.

[0378] like Figure 22A As shown, when the first object 3 (admin3) is added as a new authorized initiating node on the blockchain, the process of adding authorized initiating nodes is triggered. The signer registration method of the target contract ASM is called to add the relevant information of the first object 3 to the list of authorized initiating nodes. At this time, the relevant information of the first object 3, "org_3:org3;root:admin3", will be added to the target field on the blockchain to mark the administrator 3 belonging to organization 3 as an authorized initiating node.

[0379] like Figure 22B The diagram illustrates the process of adding a node (added by the administrator) to the list of authorized initiating nodes corresponding to the transaction type of the target transaction. Specifically, the list of authorized initiating nodes corresponding to the transaction type of the target transaction contains 7 authorized initiating nodes (objects), each with its public key (pubkey) and address (address). Therefore, when adding an authorized initiating node for the target transaction, the target contract records the public key 8 and the address Dqfkqe31 of the new authorized initiating node (object 8) into the list of authorized initiating nodes.

[0380] The advantage of this embodiment is that it takes into account the addition of authorized initiating nodes, and uses the target contract to register and record new authorized initiating nodes (new administrators), which can achieve timely updates of the list of authorized initiating nodes, thereby improving the security of blockchain transaction processing.

[0381] Please refer to Figure 23 In some embodiments, the specific process of deleting a node with the authority to initiate an action on the blockchain may include, but is not limited to, the following steps 2310-2320:

[0382] Step 2310: In response to a node revocation request for the blockchain, determine the public key of the target node and the address of the node to be revoked.

[0383] Step 2320: Through the target contract of the blockchain, clear the target node's public key and target node address from the blockchain's predetermined log.

[0384] Steps 2310-2320 are described in detail below.

[0385] In step 2310, when the target object wants to delete the administrator on the blockchain, it initiates a node revocation request for the blockchain, providing the public key of the authorized node to be revoked and the address of the target node. Based on this, the server responds to the node revocation request for the blockchain, receiving the public key of the authorized node to be revoked and the address of the target node.

[0386] In step 2320, after the node revocation request has been verified in steps 310-370 above, the signer revocation method in the target contract of the blockchain is used to clear the target node's public key, the organization to which the node belongs, and the target node's address from the blockchain's pre-defined log, so that the latest administrator information stored in the target field trust_roots of the pre-defined log no longer includes the relevant information of the authorized node to be revoked.

[0387] like Figure 24A As shown, when the initiation permission of the first object 2 (admin2) on the blockchain is revoked, the process of deleting the authorized initiation node is triggered. The revocation method of the signer of the target contract ASM is called to clear the relevant information of the first object 2 from the list of authorized initiation nodes. At this time, the relevant information of the first object 2 originally recorded in the target field of the blockchain, "org_2:org2;root:admin2", will be deleted to mark that the administrator 2 belonging to organization 2 is no longer an authorized initiation node.

[0388] like Figure 24BThe diagram illustrates the process of deleting (revoking) a node from the list of authorized initiating nodes corresponding to the transaction type of the target transaction. Specifically, the list of authorized initiating nodes corresponding to the transaction type of the target transaction contains 7 authorized initiating nodes (objects), each with its public key (pubkey) and address (address). Therefore, when revoking the initiating permissions of two authorized initiating nodes for the target transaction, the target contract deletes the public key 4 and node address (cnad14) of object 4, and the public key 5 and node address (quncqo51) of object 5 from the list of authorized initiating nodes, thereby revoking the initiating permissions of objects 4 and 5 for the target transaction.

[0389] The advantage of this embodiment is that it takes into account the deletion of authorized initiating nodes according to actual needs, and uses the revocation process of the target contract to clearly identify the node information of the authorized initiating nodes to be revoked. This enables timely updates to the list of authorized initiating nodes, ensuring the accuracy and consistency of node information, thereby improving the security and reliability of blockchain transaction processing.

[0390] Detailed implementation diagrams of the blockchain transaction processing method according to embodiments of this disclosure.

[0391] The following reference Figure 25 The implementation details of the blockchain transaction processing method according to the embodiments of this disclosure are described in detail.

[0392] like Figure 25 The diagram illustrates the transaction processing flow for blockchain management transactions. Specifically, first, a transaction processing request related to a blockchain-managed transaction is received from the target object. Next, it is determined whether the target object is a node with the authority to initiate the target transaction. If the target object is not, a permission-unauthorized operation message is returned to it. If the target object is a node with the authority to initiate the target transaction, the target contract ASM collects signature blocks from various signers (other authorized initiating nodes) for the target transaction, a process similar to steps 310-350 above. Further, the target contract determines whether the collected signature blocks reach a threshold. If the collected valid signature blocks reach the threshold, a target signature (aggregate signature) is generated, a process similar to steps 710-720 above. Next, the target signature is sent to each blockchain node, which verifies it and determines whether the number of consensus nodes confirming the signature's verification has reached a threshold. If the threshold is not reached, an "unauthorized operation" message is returned to the target object. If the threshold is reached, the target transaction is executed and uploaded to the blockchain, similar to steps 1710-1730 and 370 above. For brevity, these details will not be elaborated further.

[0393] The advantages of this embodiment are as follows: First, it divides blockchain transactions into blockchain management transactions and non-blockchain management transactions, separating the system permissions corresponding to blockchain management transactions from the non-system permissions corresponding to non-blockchain management transactions. This solves the problem of confusion between blockchain management-related permissions and user permissions. This separation makes permission management clearer and more controllable, avoiding the abuse or inadequacy of permissions and improving the security and controllability of the system. Furthermore, it introduces aggregated signature technology into the processing of blockchain management transactions. First, since aggregated signatures only require transmitting a single signature to the blockchain node instead of multiple signatures, it reduces the amount of data communicated, lowers network transmission costs and latency, and thus alleviates the burden on network transmission. Second, since aggregated signatures only require storing a single signature instead of multiple signatures, it saves blockchain storage space. Third, when blockchain nodes perform signature verification, they only need to verify a single signature instead of verifying multiple signatures one by one, reducing the computational workload, improving the efficiency and performance of signature verification, and also reducing the complexity of signature verification. In addition, if the target contract verification block does not reach the threshold, the target signature will not be generated and sent to the blockchain node. Therefore, this method can also reduce the pressure on the blockchain node caused by erroneous signature data.

[0394] Description of apparatus and devices according to embodiments of this disclosure

[0395] It is understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this embodiment, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0396] It should be noted that in various specific embodiments of this application, when processing is required based on data related to the characteristics of the target object, such as target object attribute information or a set of attribute information, the permission or consent of the target object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require obtaining target object attribute information, separate permission or consent from the target object will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the target object's separate permission or consent will the necessary target object-related data for the normal operation of the embodiments of this application be obtained.

[0397] Figure 26 A schematic diagram of the structure of a blockchain transaction processing device 2600 provided in an embodiment of this disclosure. The blockchain transaction processing device 2600 includes:

[0398] The receiving unit 2610 is used to receive a transaction processing request sent by the target object, wherein the transaction processing request is used to execute the target transaction and put the target transaction on the blockchain;

[0399] Verification unit 2620 is used to send the target transaction to the blockchain node for blockchain node verification if the target transaction is a non-blockchain management transaction.

[0400] The determining unit 2630 is used to determine the transaction type of the target transaction if the target transaction is a blockchain management transaction;

[0401] Acquisition unit 2640 is used to obtain the list of nodes with permission to initiate transactions corresponding to the transaction type;

[0402] Sending unit 2650 is used to send the target transaction to other authorized initiating nodes in the authorized initiating node list if the target object belongs to the authorized initiating node list.

[0403] The aggregation unit 2660 is used to aggregate the signature blocks into a target signature and send it to the blockchain node for blockchain node verification if it receives a predetermined number of signature blocks from other authorized initiating nodes for the target transaction. The predetermined number is less than the total number of other authorized initiating nodes.

[0404] Execution unit 2670 is used to execute the target transaction and put the target transaction on the blockchain if the blockchain node verifies it.

[0405] Optionally, the number of reservations is determined in the following way:

[0406] Based on the transaction type and content of the target transaction, determine the importance score of the target transaction;

[0407] The predetermined number is determined based on the importance score.

[0408] Optionally, the list of authorized initiating nodes corresponding to the transaction type is determined by the target contract of the blockchain in the following way:

[0409] During blockchain initialization, the target fields of the genesis block are parsed to obtain the signer information;

[0410] Node registration is performed based on the signer information, resulting in multiple authorized nodes corresponding to the transaction type;

[0411] Based on the node information of each authorized initiating node, a list of authorized initiating nodes is constructed.

[0412] Optionally, the aggregation unit 2660 includes:

[0413] A verification module (not shown) is used to verify the blockchain contract for each signature block;

[0414] An aggregation module (not shown) is used to aggregate the signature blocks into a target signature if the blockchain contract verification of a predetermined number of signature blocks passes.

[0415] Optionally, the verification module (not shown) includes:

[0416] A formal verification module (not shown) is used to perform formal verification on each signature block.

[0417] A content verification module (not shown) is used to perform signature block content verification on the signature block if the formal verification passes.

[0418] The determination module is used to determine whether the blockchain contract verification of the signature block is successful if the content verification of the signature block is successful.

[0419] Optionally, the content verification module (not shown) is used for:

[0420] Obtain the target public key of other authorized initiating nodes that provide the signature block, and verify the content of the signature block based on the target public key;

[0421] If the content of the signature block is verified, the candidate public keys of multiple candidate authorized initiating nodes in the list of authorized initiating nodes corresponding to the target transaction are obtained, and the target public key and multiple candidate public keys are matched and verified.

[0422] Optionally, content verification of the signed block is performed based on the target public key, including:

[0423] The signature block is designed based on the target public key to obtain the designing result.

[0424] A transaction digest is generated by performing a digest operation on the transaction processing request based on a predefined digest algorithm.

[0425] If the designing result matches the transaction summary result, then the content of the signature block has been verified.

[0426] Optionally, the target public key and multiple candidate public keys are matched and verified, including:

[0427] The target public key is compared with each candidate public key;

[0428] If a candidate public key is found to be the same as the target public key, then the target public key is determined to match one of the multiple candidate public keys, and the matching verification is confirmed to be successful.

[0429] If no candidate public key matches the target public key, it is determined that the target public key does not match multiple candidate public keys, and the matching is determined to fail verification.

[0430] Optionally, the formal verification module (not shown) is used for:

[0431] For each signature block, perform format validation on the signature block;

[0432] For each signature block, the validity of the generation timestamp of the signature block is verified.

[0433] Optionally, for each signature block, the validity of the generation timestamp of the signature block is verified, including:

[0434] For each other authorized initiating node, determine the timestamp of the signature block for each candidate signature block for the target transaction provided by the other authorized initiating node. The signature block is one of multiple candidate signature blocks.

[0435] If it is determined that the generated timestamp is not earlier than the latest signature block timestamp, then the generated timestamp is considered valid.

[0436] Optionally, the aggregation unit 2660 is used for:

[0437] Determine the generation timestamp of each signature block;

[0438] Based on the order of the generated timestamps, a predetermined number of signature blocks are sorted.

[0439] According to the sorting, a predetermined number of signature blocks are aggregated using a predefined signature function to obtain the target signature.

[0440] Optionally, the aggregation unit 2660 is used for:

[0441] Determine the priority of each other node that has the authority to initiate the process;

[0442] The signature blocks are sorted based on node priority;

[0443] According to the sorting, a predetermined number of signature blocks are aggregated using a predefined signature function to obtain the target signature.

[0444] Optionally, the priority of each other node with the authority to initiate the node is determined, including:

[0445] For each other authorized initiating node, determine the creation timestamp and reputation of the other authorized initiating nodes;

[0446] Based on the creation timestamp and reputation, determine the scores of other nodes that have the authority to initiate nodes;

[0447] Based on the scores of multiple nodes, the priority of each other node with the authority to initiate a node is determined.

[0448] Optionally, the blockchain node verifies the target signature using the following methods:

[0449] For each blockchain node, perform formal verification of the target signature;

[0450] If the formal verification of the target signature is successful, the signature content is verified based on the predefined public key.

[0451] If the first number of blockchain nodes determine that the signature content of the target signature has been verified, then the blockchain node verification of the target signature has been confirmed.

[0452] Optionally, blockchain nodes verify the target transaction using the following methods:

[0453] Determine the request timestamp of the transaction processing request for the target transaction, and the transaction information of the target transaction;

[0454] Perform the first verification on the request timestamp of the transaction processing request for the target transaction;

[0455] Perform a second verification on the transaction information of the target transaction.

[0456] Optionally, the blockchain transaction processing device 2600 further includes a deletion unit (not shown), which is used for:

[0457] In response to a node revocation request for the blockchain, determine the target node's public key and target node address for the authorized node to be revoked;

[0458] The target node's public key and address are cleared from the blockchain's predetermined log through the target contract.

[0459] Optionally, the blockchain transaction processing device 2600 also includes a new unit (not shown), which is used for:

[0460] In response to a request to add a new node to the blockchain, determine the target node's public key, the organization to which the node belongs, and the target node's address for the authorized node to be added;

[0461] The target contract on the blockchain records the target node's public key, the organization to which the node belongs, and the target node's address in the blockchain's predetermined log.

[0462] Reference Figure 27 , Figure 27 To implement the structural block diagram of the terminal portion of the blockchain transaction processing method according to embodiments of this disclosure, the terminal includes: a radio frequency (RF) circuit 2710, a memory 2715, an input unit 2730, a display unit 2740, a sensor 2750, an audio circuit 2760, a wireless fidelity (WiFi) module 2770, a processor 2780, and a power supply 2790, etc. Those skilled in the art will understand that... Figure 27 The terminal structure shown does not constitute a limitation on mobile phones or computers and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0463] The RF circuit 2710 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 2780; in addition, it transmits uplink data to the base station.

[0464] The memory 2715 can be used to store software programs and modules, and the processor 2780 executes various functional applications and data processing of the target terminal by running the software programs and modules stored in the memory 2715.

[0465] The input unit 2730 can be used to receive input numeric or character information, and to generate key signal inputs related to the settings and function control of the target terminal. Specifically, the input unit 2730 may include a touch panel 2731 and other input devices 2732.

[0466] Display unit 2740 can be used to display input or provided information, as well as various menus of the target terminal. Display unit 2740 may include display panel 2741.

[0467] Audio circuitry 2760, speaker 2761, and microphone 2762 provide an audio interface.

[0468] In this embodiment, the processor 2780 included in the terminal can execute the blockchain transaction processing method of the previous embodiment.

[0469] The terminals disclosed in this embodiment include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The embodiments of this invention can be applied to various scenarios, including but not limited to data security, blockchain, data storage, and information technology.

[0470] Figure 28 This is a partial structural block diagram of a server for implementing the blockchain transaction processing method of this disclosure. The server can vary significantly due to different configurations or performance, and may include one or more central processing units (CPUs) 2822 (e.g., one or more processors) and memory 2832, and one or more storage media 2830 (e.g., one or more mass storage devices) for storing application programs 2842 or data 2844. The memory 2832 and storage media 2830 can be temporary or persistent storage. The program stored in the storage media 2830 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 2822 may be configured to communicate with the storage media 2830 and execute the series of instruction operations in the storage media 2830 on the server.

[0471] The server may also include one or more power supplies 2826, one or more wired or wireless network interfaces 2850, one or more input / output interfaces 2858, and / or one or more operating systems 2841, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0472] The central processing unit 2822 in the server can be used to execute the blockchain transaction processing method of the present disclosure embodiments.

[0473] This disclosure also provides a computer-readable storage medium for storing program code for executing the blockchain transaction processing methods of the foregoing embodiments.

[0474] This disclosure also provides a computer program product comprising a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the blockchain transaction processing method described above.

[0475] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the foregoing drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0476] It should be understood that in this disclosure, "at least one item" means one or more, and "more than one" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0477] It should be understood that in the description of the embodiments disclosed herein, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0478] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0479] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0480] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0481] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, 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. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0482] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects.

[0483] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A blockchain transaction processing method, characterized in that, The method includes: Receive a transaction processing request sent by the target object, wherein the transaction processing request is used to execute the target transaction and put the target transaction on the blockchain; If the target transaction is a non-blockchain management transaction, the target transaction is sent to a blockchain node for blockchain node verification; If the target transaction is a blockchain management transaction, determine the transaction type of the target transaction; Obtain the list of nodes with permission to initiate the transaction type; If the target object belongs to the list of authorized initiating nodes, the target transaction is sent to other authorized initiating nodes in the list of authorized initiating nodes; If a predetermined number of signature blocks for the target transaction are received from other authorized initiating nodes, the signature blocks are aggregated into a target signature and sent to the blockchain node for blockchain node verification. The predetermined number is less than the total number of other authorized initiating nodes. If the blockchain node verifies the transaction, the target transaction is executed and recorded on the blockchain.

2. The blockchain transaction processing method according to claim 1, characterized in that, The step of aggregating the individual signature blocks into a target signature includes: Perform blockchain contract verification on each of the aforementioned signature blocks; If the blockchain contract verification of the predetermined number of signature blocks passes, then the individual signature blocks are aggregated into a target signature.

3. The blockchain transaction processing method according to claim 2, characterized in that, The blockchain contract verification for each of the signature blocks includes: For each of the aforementioned signature blocks, a formal verification is performed on the signature block; If the formal verification passes, then the signature block content verification is performed. If the content of the signature block is verified, it is determined that the blockchain contract of the signature block has been verified.

4. The blockchain transaction processing method according to claim 3, characterized in that, The verification of the signature block content includes: Obtain the target public key of the other authorized initiating node that provides the signature block, and verify the content of the signature block based on the target public key; If the content of the signature block is verified, then the candidate public keys of multiple candidate authorized initiating nodes in the list of authorized initiating nodes corresponding to the target transaction are obtained, and the target public key and the multiple candidate public keys are matched and verified.

5. The blockchain transaction processing method according to claim 4, characterized in that, The content verification of the signature block based on the target public key includes: The signature block is designed based on the target public key to obtain the designing result. The transaction processing request is digested based on a predetermined digest algorithm to obtain a transaction digest result. If the designing result is consistent with the transaction digest result, then the content verification of the signature block is determined to be successful.

6. The blockchain transaction processing method according to claim 4, characterized in that, The matching and verification of the target public key and multiple candidate public keys includes: The target public key and each of the candidate public keys are compared. If there is a candidate public key that is the same as the target public key, then the target public key is determined to match one of the candidate public keys, and the matching verification is determined to be successful. If no candidate public key matches the target public key, then the target public key is determined not to match any of the candidate public keys, and the matching is determined not to pass verification.

7. The blockchain transaction processing method according to claim 3, characterized in that, The formal verification of each signature block includes: For each of the signature blocks, the format of the signature block is validated; For each signature block, the validity of the generation timestamp of the signature block is verified.

8. The blockchain transaction processing method according to claim 7, characterized in that, The step of validating the generation timestamp of each signature block includes: For each of the other authorized initiating nodes, determine the signature block timestamp of each candidate signature block provided by the other authorized initiating node for the target transaction, wherein the signature block is one of the multiple candidate signature blocks; If it is determined that the generated timestamp is not earlier than the latest timestamp of the signature block, then the generated timestamp is determined to be valid.

9. The blockchain transaction processing method according to claim 1, characterized in that, The step of aggregating the individual signature blocks into a target signature includes: Determine the generation timestamp of each of the signature blocks; Based on the order of the generated timestamps, the predetermined number of signature blocks are sorted. According to the sorting, the predetermined number of signature blocks are aggregated using a predetermined signature function to obtain the target signature.

10. The blockchain transaction processing method according to claim 1, characterized in that, The step of aggregating the individual signature blocks into a target signature includes: Determine the priority of each of the other authorized nodes; The signature blocks are sorted based on the node priority; According to the sorting, the predetermined number of signature blocks are aggregated using a predetermined signature function to obtain the target signature.

11. The blockchain transaction processing method according to claim 1, characterized in that, The blockchain node verifies the target signature using the following method: For each of the blockchain nodes, the target signature is formally verified; If the formal verification of the target signature is found to be successful, the signature content is verified based on the predetermined public key. If the first number of blockchain nodes determine that the signature content of the target signature has been verified, then the blockchain node verification for the target signature has been confirmed as successful.

12. The blockchain transaction processing method according to claim 1, characterized in that, The blockchain node verifies the target transaction using the following methods: Determine the request timestamp of the transaction processing request for the target transaction and the transaction information of the target transaction; The request timestamp of the transaction processing request for the target transaction is first verified; A second verification is performed on the transaction information of the target transaction.

13. The blockchain transaction processing method according to claim 1, characterized in that, After aggregating the individual signature blocks into a target signature, the method further includes: In response to a node revocation request for the blockchain, the target node's public key and target node address are determined for the authorized initiating node to be revoked; The target node's public key and address are cleared from the blockchain's predetermined log via the target contract.

14. The blockchain transaction processing method according to claim 1, characterized in that, After aggregating the individual signature blocks into a target signature, the method further includes: In response to a request to add a node to the blockchain, the public key of the target node, the organization to which the node belongs, and the address of the target node are determined. The target node's public key, the organization to which the node belongs, and the target node's address are recorded in the blockchain's predetermined log through the target contract of the blockchain.

15. A blockchain transaction processing device, characterized in that, The device includes: A receiving unit is configured to receive a transaction processing request sent by a target object, wherein the transaction processing request is used to execute the target transaction and put the target transaction on the blockchain; The verification unit is used to send the target transaction to the blockchain node for blockchain node verification if the target transaction is a non-blockchain management transaction. A determining unit is configured to determine the transaction type of the target transaction if the target transaction is a blockchain management transaction; The acquisition unit is used to acquire a list of nodes with permission to initiate the transaction corresponding to the transaction type; The sending unit is configured to send the target transaction to other authorized initiating nodes in the authorized initiating node list if the target object belongs to the authorized initiating node list. An aggregation unit is configured to, if it receives a predetermined number of signature blocks from other authorized initiating nodes for the target transaction, aggregate the signature blocks into a target signature and send it to the blockchain node for blockchain node verification, wherein the predetermined number is less than the total number of other authorized initiating nodes. An execution unit is used to execute the target transaction and upload the target transaction to the blockchain if the blockchain node verifies the transaction.

16. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the blockchain transaction processing method according to any one of claims 1 to 14.

17. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the blockchain transaction processing method according to any one of claims 1 to 14.

18. A computer program product comprising a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the blockchain transaction processing method according to any one of claims 1 to 14.

Images