Blockchain-based data processing method, apparatus, and related device

Abstract

The application provides a blockchain-based data processing method and device and related equipment, wherein the method comprises: obtaining a set of to-be-packed transactions from a transaction pool; determining at least one object corresponding to a to-be-packed transaction in the set of to-be-packed transactions, and determining a candidate transaction set corresponding to each object from the set of to-be-packed transactions; obtaining a charging type of a first object in the at least one object, and if the charging type is a first target charging type, determining N candidate transactions from the candidate transaction set corresponding to the first object according to a transaction restriction rule corresponding to the first object, wherein N is a positive integer, the transaction restriction rule comprises a concurrency degree and a single-transaction upper limit, the concurrency degree is used to indicate the maximum number of the N candidate transactions, and the single-transaction upper limit is used to indicate the maximum packing fee of a transaction; and packing the N candidate transactions into a target block. Through the embodiments of the application, abnormal transaction initiation behavior can be limited, thereby ensuring the stability of the blockchain network.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to blockchain-based data processing methods, blockchain-based data processing devices, data processing equipment, computer-readable storage media, and computer program products. Background Technology

[0002] With the continuous development and application of computer technology, blockchain technology has also developed rapidly. Because information stored on the blockchain cannot be forged or tampered with, using blockchain technology for business data processing has become a current trend. In a blockchain, the object initiating a transaction needs to be authenticated. After successful authentication, the transaction is allowed and packaged. However, even authenticated objects may pose potential risks, such as broadcasting a large number of spam transactions, potentially causing the entire blockchain network to become congested due to the actions of a single object.

[0003] Therefore, how to restrict abnormal transaction initiation behavior to ensure the stability of the blockchain network is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a data processing method, apparatus, and related equipment based on blockchain, which can restrict abnormal transaction initiation behavior, thereby ensuring the stability of the blockchain network.

[0005] This application provides a blockchain-based data processing method, which includes:

[0006] Retrieve the set of transactions to be packaged from the transaction pool;

[0007] Identify at least one object corresponding to the transaction to be packaged included in the above-mentioned transaction to be packaged set, and determine a candidate transaction set corresponding to each of the above-mentioned at least one object from the above-mentioned transaction to be packaged set;

[0008] Obtain the billing type of the first object. If the billing type is the first target billing type, then determine N candidate transactions from the candidate transaction set corresponding to the first object according to the transaction restriction rules corresponding to the first object. The first object is any one of the above at least one objects. N is a positive integer. The transaction restriction rules include concurrency and single transaction fee limit. The concurrency is used to indicate the maximum number of the above N candidate transactions. The single transaction fee limit is used to indicate the maximum package fee of the transaction.

[0009] Package the above N candidate transactions into the target block.

[0010] This application provides a blockchain-based data processing device, which includes:

[0011] The acquisition module is used to retrieve a set of transactions to be packaged from the transaction pool;

[0012] The processing module is used to determine at least one object corresponding to the transaction to be packaged included in the above-mentioned transaction to be packaged set, and to determine a candidate transaction set corresponding to each of the at least one object in the above-mentioned transaction to be packaged set.

[0013] The aforementioned processing module is further configured to obtain the billing type of the first object. If the billing type is the first target billing type, then N candidate transactions are determined from the candidate transaction set corresponding to the first object according to the transaction restriction rules corresponding to the first object. The first object is any one of the at least one of the above objects, and N is a positive integer. The transaction restriction rules include concurrency and single transaction fee limit. The concurrency is used to indicate the maximum number of the N candidate transactions, and the single transaction fee limit is used to indicate the maximum package fee of the transaction.

[0014] The packaging module is used to package the above N candidate transactions into the target block.

[0015] This application provides a data processing device, including a processor, a memory, and a network interface, which are interconnected. The memory stores a computer program, which includes program instructions. The processor is configured to invoke the program instructions to implement the steps of the blockchain-based data processing method.

[0016] This application provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which are executed by a processor to implement the steps of the blockchain-based data processing method described above.

[0017] This application provides a computer program product, which includes a computer program or computer instructions, which are executed by a processor to implement the steps of the blockchain-based data processing method described above.

[0018] This application divides the set of transactions to be packaged into transactions based on the object dimension, thereby obtaining a candidate transaction set corresponding to each object. This method facilitates differentiated billing management by analyzing information such as billing types and permissions of different objects, improving the intelligence of billing management. Furthermore, managing and analyzing the candidate transaction set corresponding to each object at the object dimension eliminates the need to analyze each transaction to be packaged separately, improving management and analysis efficiency, and consequently, the efficiency of subsequent transaction packaging. For any object in the set of transactions to be packaged, if the object's billing type is the first target billing type, candidate transactions that meet transaction restriction rules are determined from the candidate transaction set corresponding to that object. Transaction restriction rules may include, for example, concurrency and single-transaction fee limits. Concurrency indicates the maximum number of candidate transactions that can be selected for this packaging of the object, and the single-transaction fee limit indicates the maximum packaging fee for the transaction. This method effectively avoids packaging abnormal transactions such as extremely large transaction data, thereby limiting abnormal transaction initiation behavior and preventing blockchain network congestion. Packaging the candidate transactions filtered by the transaction restriction rules ensures the security and stability of the blockchain network. The above method allows objects of the first target billing type to avoid paying a separate package fee for each transaction when generating transactions, and eliminates concerns about account balance issues, thereby enabling better business planning and budgeting, while also improving the user experience of the objects. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0020] Figure 1A This is a schematic diagram of the architecture of a blockchain-based data processing system provided in an embodiment of this application;

[0021] Figure 1B This is a schematic diagram of a blockchain structure provided in an embodiment of this application;

[0022] Figure 1C This is a schematic diagram illustrating a process for generating a new block, provided in an embodiment of this application.

[0023] Figure 2 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application;

[0024] Figure 3 This is a flowchart illustrating another blockchain-based data processing method provided in an embodiment of this application;

[0025] Figure 4A This is a sequence diagram of an administrator managing subscription rules provided in an embodiment of this application;

[0026] Figure 4B This is a timing diagram of a subscription purchase rule provided in an embodiment of this application;

[0027] Figure 4C This is a timing diagram of a consensus node packaging transactions provided in an embodiment of this application;

[0028] Figure 5 This is a schematic block diagram of a blockchain-based data processing device provided in this embodiment;

[0029] Figure 6 This is a schematic block diagram of a data processing device provided in an embodiment of this application. Detailed Implementation

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

[0031] It should be noted that the terms "first," "second," etc., used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature specified with "first" or "second" may explicitly or implicitly include at least one of those features.

[0032] The following will explain some key terms that appear in the embodiments of this application.

[0033] In a blockchain, a block is divided into two main parts: the block header and the block body. The block header stores the block's header information, such as the hash value of the previous block (PreHash), the hash value of the current block body (Hash), and the timestamp (TimeStamp), etc. The block body stores the detailed data of this block, which includes several lines of records, which can be transaction information or some other type of information.

[0034] A digital signature, also known as a public-key digital signature, is a string of numbers that only the sender of the information can generate and that cannot be forged by other objects. This string of numbers also serves as valid proof of the authenticity of the information sent by the sender. A digital signature is similar to a physical signature written on paper, but it uses public-key cryptography techniques to achieve its purpose. It is a method for verifying digital information. A digital signature typically defines two complementary operations: one for signing and the other for verification. Digital signatures are an application of asymmetric key encryption technology and digital digest technology.

[0035] A consortium blockchain is a system architecture that falls between public and private blockchains, often controlled by multiple central entities. Several organizations collaborate to maintain a single blockchain, which requires restricted access and its information is protected; examples include supply chain organizations or banking consortia. A consortium blockchain can be viewed as a distributed escrow ledger system controlled by multiple "authoritative" nodes designated by the organization. These nodes manage and operate the system based on a consensus mechanism. Consortium blockchains can be considered "partially decentralized," allowing public access and transactions, but requiring consortium permission to verify transactions or publish smart contracts. A key characteristic of consortium blockchains is that each node typically has a corresponding entity, and joining or leaving the system requires consortium approval. Various stakeholders collaborate closely on the blockchain to maintain its healthy and stable development. In a consortium blockchain, nodes have an access control mechanism, and inter-node communication requires identity information (e.g., digital signatures). Only after verifying that the message originates from a valid node within the consortium (i.e., the signature verification process) can the message be accepted and processed by other nodes.

[0036] In traditional blockchains, object authentication is used to prevent objects from initiating a large number of spam transactions and clogging the network. Specifically, the blockchain requires authentication of the object initiating the transaction. Once authentication is successful, the transaction is allowed, and the transaction is packaged (in Fabric, for example, every object is an authenticated legitimate object; anonymous objects cannot initiate transactions. Fabric assumes that authenticated objects are not malicious, and no transaction fees are charged). This method can identify some abnormal objects and, to some extent, prevent blockchain network congestion. However, even authenticated objects may still pose potential risks, such as broadcasting spam transactions, thus potentially causing the entire blockchain network to be clogged due to the actions of a single object.

[0037] Based on the above, this application first proposes a method of paying transaction fees (packaging fees) for each individual transaction to prevent abnormal transaction behavior. Specifically, each transaction must include a certain transaction fee (e.g., Gas), and transactions without fees cannot be broadcast or packaged into the blockchain. For each transaction packaged into the blockchain, the corresponding transaction fee is deducted from the account of the transaction initiator. Since broadcasting a large number of spam transactions incurs expensive fees, this method can prevent abnormal entities from broadcasting a large number of spam transactions, thereby clogging the blockchain network. However, when using this method of paying transaction fees for each individual transaction, each entity must constantly monitor its account balance; if the balance is insufficient, it cannot initiate any more transactions, making it difficult to effectively plan its on-chain transaction activity and failing to meet real-world business and financial needs.

[0038] Based on this, this application improves and optimizes the above method, proposing a billing method based on blockchain transaction subscription rules (which can be understood as the "annual / monthly subscription" billing method in traditional commerce). This method uses a smart contract (i.e., a billing management contract) as the management object of the packages (i.e., subscription rules) (that is, managing package subscribers through smart contracts). Administrators publish multiple types of package packages (i.e., candidate subscription rules) by calling this smart contract, and subscribers can query, subscribe to, modify, and unsubscribe from packages by calling the smart contract. The blockchain transaction package-based billing method can coexist with a billing model that charges fees for individual transactions; transactions using both billing models can be mixed and packaged into a block. Specifically, after subscribing to a package, an object can use its address to initiate transactions on the blockchain network without paying fees for each transaction. To prevent abnormal objects from initiating a large number of transactions and clogging the network, consensus nodes will limit the number of transactions initiated by the same address (i.e., the same object) when packaging blocks, and will also limit excessively large single transactions by setting a single fee cap. Once the subscription expires, if a subscriber continues to initiate fee-free transactions, those transactions will no longer be broadcast or bundled. Individuals who have not subscribed to a subscription can choose to pay fees for individual transactions or purchase a subscription package, depending on their needs.

[0039] This application will be illustrated through the following examples:

[0040] Please see Figure 1A This is a schematic diagram of the architecture of a blockchain-based data processing system provided in an embodiment of this application. The blockchain-based data processing system includes a blockchain network 10 and a client 102, wherein:

[0041] Blockchain network 10 refers to a network used for data sharing between nodes. The blockchain network may include multiple nodes 101, among which consensus nodes may be included. Each node 101, in its normal operation, receives input information and maintains shared data (i.e., the blockchain) within the blockchain network based on the received input information. Each node in the blockchain network stores the same blockchain, which consists of a series of blocks sequentially generated in chronological order, such as... Figure 1A As shown in the diagram, blocks 1, M-1, etc., are blocks that, once added to the blockchain, will not be removed. Blocks record the data submitted by nodes in the blockchain network. To ensure information exchange within the blockchain network, each node can be connected to another node, enabling peer-to-peer (P2P) communication between any two nodes. This P2P communication can be conducted via wired or wireless communication links. For example, when any node in the blockchain network receives input information, other nodes retrieve this input information according to the consensus algorithm and store it as part of the shared data, ensuring consistency of data stored on all nodes in the blockchain network.

[0042] Client 102 can access the blockchain network and communicate with nodes in the blockchain network, such as sending transaction data to nodes. The terminal where client 102 is located can be a smartphone, tablet, laptop, desktop computer, in-vehicle smart terminal, etc., and this embodiment of the application does not limit the specific device.

[0043] It should be noted that, Figure 1A The number of nodes shown is merely illustrative. Any number of nodes can be deployed as needed. A node can refer to any form of computing device connected to the network, such as a server or user terminal.

[0044] Each node in the blockchain network has a corresponding node identifier, and each node can also store the node identifiers of other nodes in the blockchain network. This allows for the subsequent broadcasting of generated blocks to other nodes in the blockchain network based on their node identifiers. Each node can maintain a node identifier list as shown in the table below, storing the node name and node identifier in this list. The node identifier can be an Internet Protocol (IP) address or any other information that can be used to identify the node; the table only uses IP addresses as an example.

[0045] Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258

[0046] In this blockchain network, each node stores an identical copy of the blockchain. A blockchain consists of multiple blocks; see [link to blockchain documentation]. Figure 1B A blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information feature values, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature values ​​of the current block, the block header feature values ​​of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0047] When generating the various blocks in the blockchain, see [link / reference]. Figure 1C When a node in the blockchain receives input information, it verifies the input information. After verification, it stores the input information in a memory pool and updates its hash tree used to record the input information. Then, it updates the timestamp to the time the input information was received and tries different random numbers multiple times to calculate the feature value, ensuring that the calculated feature value satisfies the following formula:

[0048] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET

[0049] Wherein, SHA256 is the feature value algorithm used to calculate the feature value; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header feature value of the parent block of the current block; merkle_root is the feature value of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value for a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the feature value threshold, which can be determined based on nbits.

[0050] Thus, when a random number satisfying the above formula is calculated, the information can be stored accordingly, generating a block header and a block body to obtain the current block. Subsequently, the node containing the blockchain sends the newly generated block to other nodes in its blockchain network based on the node identifiers of other nodes in the blockchain network. The other nodes verify the newly generated block and, after verification, add the newly generated block to their stored blockchain.

[0051] In a blockchain network, smart contracts can run on nodes, enabling various transactions. A smart contract is an immutable, automatically executing computer program that runs on the blockchain. It's code that executes when certain conditions are met. Developers can define contract logic using programming languages, publish it to the blockchain (smart contract registration), and execute it based on the contract terms, triggered by keys or other events. The blockchain also provides functions for upgrading and deregistering smart contracts.

[0052] In some feasible implementations, any node 101 of the blockchain network can obtain transaction data from a client. This transaction data may carry the client's identity identifier, which can be determined based on the client's identity certificate. Node 101 can query the client's identity certificate from the smart contract based on the identity identifier. If the client's identity certificate is found in the smart contract, and the identity certificate determines that the client has the authority to execute the transaction operation corresponding to the transaction data on the blockchain, then node 101 can execute the transaction operation corresponding to the transaction data on the blockchain. By utilizing the mapping relationship between the identity identifier carried in the transaction data and the identity certificate recorded in the smart contract, the corresponding identity certificate of the client can be determined, and the transaction operation can be performed according to the permissions indicated in the identity certificate, thereby improving the security of data processing on the blockchain. Carrying only the identity identifier in the transaction data, while ensuring that the corresponding identity certificate can be obtained, can reduce the amount of transaction data compared to carrying the complete identity certificate in the transaction data, which is conducive to the rapid transmission of transaction data.

[0053] Typically, it is also necessary to generate transaction blocks for the transaction data and put the blocks on the blockchain (store the blocks on the blockchain). Since only the identity identifier is carried, the amount of transaction data can be reduced compared to carrying the complete identity certificate in the transaction data, while ensuring that the corresponding identity certificate can be obtained. This can achieve a certain degree of data compression, thereby reducing the consumption of blockchain storage resources.

[0054] It is understood that in the specific implementation of this application, data related to transactions to be packaged and subscription information are involved. When the above data is used in specific products or technologies in the embodiments of this application, user permission or consent is required. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0055] The implementation details of the technical solutions in the embodiments of this application will be described in detail below:

[0056] Please see Figure 2 , Figure 2This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. The data processing method in this embodiment is described from the perspective of the consensus node side. This blockchain-based data processing method may include:

[0057] S201. Obtain the set of transactions to be packaged from the transaction pool.

[0058] In this embodiment, the transaction pool includes multiple transactions to be packaged. When transaction data generated within a certain time period is broadcast, the consensus node stores the received transaction data in the transaction pool, which acts like a buffer. During the transaction packaging phase, the consensus node retrieves a set of transactions to be packaged from the transaction pool and packages them. The set of transactions to be packaged includes multiple transactions to be packaged.

[0059] S202. Determine at least one object corresponding to the transaction to be packaged included in the transaction to be packaged set, and determine the candidate transaction set corresponding to each object in the at least one object in the transaction to be packaged set.

[0060] In this embodiment, the multiple transactions to be packaged in the transaction set may be generated by a single object or by multiple objects. An object refers to the transaction initiating object. Since each object can purchase different subscription rules (which can be understood as a time-based package used to pay for transaction packaging fees), and different objects may have different object permissions (e.g., ordinary object permissions, administrator permissions, etc.), the consensus node needs to determine at least one object corresponding to each transaction in the transaction set to be packaged, and determine the candidate transaction set corresponding to each object within that at least one object. This method allows the transaction set to be packaged to be divided based on objects, facilitating differentiated billing management by analyzing the billing types, object permissions, and other information of different objects, thereby improving the intelligence of billing management. Furthermore, by managing and analyzing the candidate transaction set corresponding to each divided object at the object level, the consensus node does not need to analyze each transaction to be packaged separately, improving management and analysis efficiency, and thus improving the efficiency of subsequent transaction packaging.

[0061] S203. Obtain the billing type of the first object. If the billing type is the first target billing type, determine N candidate transactions from the candidate transaction set corresponding to the first object according to the transaction restriction rules corresponding to the first object. The first object is any one of at least one object, and N is a positive integer. The transaction restriction rules include concurrency and single transaction fee limit. Concurrency is used to indicate the maximum number of N candidate transactions, and single transaction fee limit is used to indicate the maximum packaged fee of the transaction.

[0062] In this embodiment, the billing type may include a first target billing type and a second target billing type. The first target billing type may be a time-based package billing (the first target billing type may include multiple subscription rules, which can be understood as a package corresponding to a transaction restriction rule. The transaction restriction rule can limit concurrency, single transaction fee limit, etc., and abnormal transactions can be filtered through the transaction restriction rule). The second target billing type is single transaction billing (that is, paying a package fee separately for each transaction). Each object can correspond to one billing type. If the billing type is the first target billing type, the consensus node determines N candidate transactions from the candidate transaction set corresponding to the first object according to the transaction restriction rule corresponding to the first object.

[0063] The transaction restriction rules corresponding to the first object are also the transaction restriction rules corresponding to the subscription rules purchased by the first object. These rules eliminate transactions from the candidate transaction set corresponding to the first object that do not meet the restrictions (where N candidate transactions are the transactions to be packaged after being filtered by the transaction restriction rules), effectively preventing the packaging of abnormal transactions such as extremely large transaction data. This method restricts abnormal transaction initiation behavior, thereby avoiding blockchain network congestion and ensuring the security and stability of blockchain transactions. Furthermore, this method allows objects of the first target billing type to avoid paying separate packaging fees for each transaction when generating transactions, eliminating concerns about account balances and enabling better business and budget planning, while also improving the user experience.

[0064] In one embodiment, transactions to be packaged in the transaction pool can carry a billing type tag indicating the transaction payment type (the billing type tag indicates a first target billing type or a second target billing type). The first target billing type is a time-based package billing (by purchasing a package, no individual transaction packaging fee is required within a certain time period), and the second target billing type is a single-transaction billing (i.e., paying the packaging fee separately for each transaction). Based on this, consensus nodes can determine the billing type of a transaction to be packaged based on whether the transaction to be packaged of an object (e.g., the transaction initiator) has a transaction billing type tag. It is worth noting that when an object constructs a transaction, it determines the transaction type (first target billing type or second target billing type; the data structure differs depending on the billing type), then signs the constructed transaction and stores it in the transaction pool. Finally, the consensus node retrieves the transaction from the transaction pool.

[0065] In one embodiment, for any object (e.g., the first object) whose billing type is the first target billing type, the candidate transaction set corresponding to the first object may include one or both of the candidate transactions marked with the billing type and the candidate transactions without the billing type mark. That is to say, the first object may choose to package some transactions using the single transaction billing method and select some transactions to package using the time-based package billing method.

[0066] Based on this, the above-mentioned determination of N candidate transactions from the candidate transaction set corresponding to the first object according to the transaction restriction rules corresponding to the first object can be achieved through the following steps.

[0067] (1) Obtain M candidate transactions with billing type tags from the candidate transaction set corresponding to the first object, where M is a positive integer.

[0068] (2) Based on the transaction restriction rules corresponding to the first object, determine N candidate transactions from M candidate transactions. Where M is a positive integer.

[0069] Specifically, the transaction restriction rules only apply to transactions of the first object that are billed under a time-based package. Transactions of the first object that are billed as single transactions can still be packaged normally. By filtering all transactions to be packaged in the candidate transaction set corresponding to the first object through the transaction restriction rules, the candidate transactions that meet the packaging conditions can be obtained. These candidate transactions are then packaged into the target block to complete the generation of the new block.

[0070] In one embodiment, if an object has purchased a subscription rule, it is classified as the first target billing type. In this case, the object can choose to use the first target billing type without paying a package fee, or it can choose to use the second target billing type to pay the package fee for each transaction. If an object has not purchased a subscription rule, it is classified as the second target billing type. In this case, the object can only use the second target billing type to pay the package fee for each transaction. For example, if the first target billing type is a time-based package billing (which the object has already purchased in advance), and the second target billing type is a single-transaction billing (which always exists and does not require purchase), then the first target billing type can be used as the default billing type. When the object has a need (such as when the package fee for the transaction to be bundled exceeds the single-transaction fee cap of the first target billing type), the second target billing type will be used for processing.

[0071] In one embodiment, each object can correspond to multiple transaction restriction rules, meaning an object may purchase multiple subscription rules. The consensus node can then combine these multiple transaction restriction rules to filter the candidate transactions in the object's transaction set, thereby determining N candidate transactions. For example, if an object purchases multiple subscription rules (including a first subscription rule and a second subscription rule), the consensus node can determine candidate transactions by combining the transaction restriction rules of these multiple subscription rules (e.g., the single-transaction fee cap for the first subscription rule is 20, and the single-transaction fee cap for the second subscription rule is 40). (For example, transactions with a packaging fee less than or equal to 40 in the candidate transaction set are considered transactions that satisfy the single-transaction fee caps of multiple subscription rules.) Following this approach, the consensus node can further filter transactions with single-transaction fee caps based on parameters such as concurrency in the multiple subscription rules, ultimately obtaining N candidate transactions.

[0072] In one embodiment, the above-mentioned acquisition of the billing type of the first object can be achieved through the following two methods.

[0073] The first method is to query the billing type of the first object from the billing management contract by calling the data query method of the billing management contract based on the object identifier of the first object.

[0074] The billing management contract stores relational data of each object and its corresponding billing type. For example, the correspondence between the object identifier of the first object (i.e., the ID of the first object) and the billing type of the first object (e.g., the first billing type, i.e., time-based package billing). Consensus nodes can query the billing type of the first object from the corresponding database through the billing management contract.

[0075] The second method is to query whether there are candidate transactions with billing type tags in the candidate transaction set corresponding to the first object, obtain the query results, and determine the billing type of the first object based on the query results.

[0076] In this embodiment of the application, if at least one candidate transaction with a billing type tag is found in the candidate transaction set corresponding to the first object, it indicates that the first object has purchased a time-limited package, and the billing type of the first object is the first target billing type; if no candidate transaction with a billing type tag is found in the candidate transaction set corresponding to the first object, it indicates that the first object has not purchased a time-limited package, and the billing type of the first object is the second target billing type.

[0077] Specifically, if there is at least one candidate transaction with a billing type tag in the candidate transaction set corresponding to the first object, then it is determined that the object has purchased the subscription rule, that is, the billing type of the first object is the first target billing type.

[0078] In this system, each candidate transaction in the candidate transaction set corresponding to the first object represents a transaction within a certain time period. If the first object has purchased a subscription rule, then at least one candidate transaction in the candidate transaction set corresponding to the first object will have a billing type tag; if the first object has not purchased a subscription rule, then none of the candidate transactions in the candidate transaction set corresponding to the first object will have a billing type tag. Therefore, the billing type of the first object can be determined using the above method without needing to judge the billing type tags of all candidate transactions in the candidate transaction set corresponding to the first object, thus improving the efficiency of obtaining the billing type.

[0079] S204. Package the N candidate transactions into the target block.

[0080] In this embodiment, all transactions to be packaged in the candidate transaction set corresponding to the first object are filtered by the transaction restriction rules corresponding to the first object to obtain candidate transactions that meet the packaging conditions. These candidate transactions are then packaged into the target block to complete the generation of the new block. Packaging based on the filtered candidate transactions avoids packaging abnormal transactions, thereby ensuring the security and stability of blockchain transactions. Furthermore, the filtered candidate transactions do not contain excessively large amounts of transaction data, reducing the possibility of blockchain network congestion.

[0081] In one embodiment, through steps S201-S203, N candidate transactions belonging to the first target billing type (i.e., time-based package billing) after the first object is filtered by the transaction restriction rules can be obtained. Then, the above N candidate transactions, as well as the transactions belonging to the second target billing type (i.e., single transaction billing) in the candidate transaction set of the first object, are packaged together into the target block.

[0082] In one embodiment, after a consensus node packages N candidate transactions into a target block, other nodes need to reach a consensus on that target block. Since the target block received by other nodes may be packaged by the current master node responsible for block production, or it may not be packaged by the current master node (e.g., a block packaged by an abnormal node), to ensure blockchain security, the consensus node can add a node identifier when packaging the N candidate transactions into the target block. When other nodes verify that the node identifier of the received target block matches the identifier of the current master node responsible for block production, they perform blockchain operations based on the received target block, thereby ensuring data security.

[0083] The beneficial effects of this application are as follows.

[0084] This application divides the set of transactions to be packaged into transactions based on the object dimension, thereby obtaining a candidate transaction set corresponding to each object. This method facilitates differentiated billing management by analyzing information such as billing types and permissions of different objects, improving the intelligence of billing management. Furthermore, managing and analyzing the candidate transaction set corresponding to each object at the object dimension eliminates the need to analyze each transaction to be packaged separately, improving management and analysis efficiency, and consequently increasing the efficiency of subsequent transaction packaging.

[0085] For any object corresponding to the set of transactions to be packaged, if the billing type of that object is the first target billing type, candidate transactions that meet the transaction restriction rules are determined from the candidate transaction set corresponding to that object. This method effectively avoids packaging abnormal transactions such as extremely large transaction data, thereby restricting the initiation of abnormal transactions and preventing blockchain network congestion. Then, the candidate transactions filtered by the transaction restriction rules are packaged to ensure the security and stability of blockchain transactions. This application also proposes that each object can simultaneously have multiple transaction restriction rules corresponding to various subscription rules, and consensus nodes can combine the transaction restriction rules of multiple subscription rules to determine the candidate transactions corresponding to that object.

[0086] The first target billing type can be a time-based package billing (the first target billing type can include a variety of subscription rules, which can be understood as a package corresponding to a transaction restriction rule. The transaction restriction rule can limit concurrency, single transaction fee limit, etc., and filter abnormal transactions). The second target billing type is single transaction billing (that is, paying a package fee separately for each transaction).

[0087] This application also proposes that consensus nodes can add node identifiers when packaging candidate transactions into target blocks. When other nodes verify that the node identifier of the received target block is the identifier of the node currently responsible for producing the block, they will perform blockchain operations based on the received target block. By verifying the node identifier, data security can be guaranteed.

[0088] The above method allows objects of the first target billing type to avoid paying a separate package fee for each transaction when generating transactions, and eliminates concerns about account balance issues, thereby enabling better business planning and budgeting, while also improving the user experience of the objects.

[0089] Please see Figure 3 , Figure 3 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. The data processing method in this embodiment is described from the perspective of the consensus node side. This blockchain-based data processing method may include:

[0090] S301. Obtain the transaction request of the second object, which includes the pending transaction.

[0091] In this embodiment, the second object can initiate a transaction by sending a transaction request. The transaction request includes data such as the transaction to be processed and object information. The second object assembles the above data and sends it to the consensus node. The transaction to be processed is a transaction generated by the second object that needs to be packaged. However, the transaction to be processed is first stored in the transaction pool by the consensus node, waiting to be packaged.

[0092] In one embodiment, the second object can further assemble the aforementioned data, digitally sign it, and then send the data and the corresponding digital signature together to the consensus node, so that the consensus node can verify the received data based on the digital signature. The digital signature method serves two purposes: verification and encryption. Verification refers to verifying the identity of the message sender to prevent forgery; encryption refers to encrypting the plaintext (i.e., data such as the transaction to be processed and object information) to prevent leakage to non-message recipients. Digital signatures can be implemented using either symmetric or asymmetric encryption methods. Through these methods, the correctness of the received data can be verified.

[0093] S302. Determine the billing type corresponding to the transaction to be processed.

[0094] In this embodiment, the transaction to be processed can be either a transaction with a time-based billing package (i.e., the first target billing type) or a transaction with a single-transaction billing type (i.e., the second target billing type). The consensus node determines the billing type corresponding to the transaction to be processed, and then marks the transaction with a billing type based on that type. Subsequently, this billing type marking allows for the rapid acquisition of the billing type for each transaction to be processed, thereby enabling differentiated billing management for each transaction and improving processing efficiency and the intelligence of billing management.

[0095] It should be noted that in the first embodiment (i.e., steps S201-S204), the transaction billing type identifier is determined by the transaction initiator when creating the transaction (i.e., the transaction initiator determines the transaction type when constructing the transaction, and different billing types have different data structures; transactions belonging to the first target billing type carry a billing type identifier, which can be a field in the data structure; the billing type of the transaction can be determined by querying whether the transaction's data structure has this field). In the second embodiment (i.e., steps S301-S309), the transaction billing type identifier is marked by the consensus node after obtaining the transaction created by the transaction initiator, according to the billing type indicated by the transaction initiator. That is to say, the consensus node queries the transaction initiator through the billing management contract, or determines the transaction's billing type through the received billing type selection information of the transaction initiator, and then selects whether to mark the transaction with a billing type based on the determined billing type.

[0096] In one embodiment, in order to improve the flexibility of obtaining the billing type of the transaction to be processed and to realize the use of different methods to obtain the billing type in different transaction processing environments, thereby improving the efficiency of obtaining the billing type of the transaction to be processed, this application provides the following two implementation methods for the above-mentioned step of determining the billing type corresponding to the transaction to be processed.

[0097] The first method is to query the billing type of the second object from the billing management contract by calling the data query method of the billing management contract based on the object identifier of the second object, and use the billing type of the second object as the billing type corresponding to the transaction to be processed.

[0098] The billing management contract stores relationship data between various objects and their corresponding billing types. For example, it stores the correspondence between the object identifier (i.e., the ID of the second object) and the billing type (e.g., the first billing type, i.e., time-based package billing). Using this method, consensus nodes only need to obtain the object identifier to quickly query the corresponding billing type from the billing management contract, thus improving query efficiency.

[0099] The second method is to obtain the billing type selection information of the second object input included in the transaction request, and determine the billing type corresponding to the transaction to be processed based on the billing type selection information. The billing type selection information is used to indicate the first target billing type or the second target billing type.

[0100] The billing type selection information is an indication input by the second object, specifying the billing type (first target billing type or second target billing type) by which the transaction to be processed will be charged. The billing type corresponding to the transaction to be processed is determined by the billing type indicated by the billing type selection information. For example, the consensus node can display multiple billing types (including first target billing type and second target billing type) to the terminal device where the second object is located, and based on the billing type selection information of the second object (e.g., the second object selects the first target billing type and generates billing type selection information indicating the first target billing type), finally determine the billing type (e.g., the first target billing type) corresponding to the transaction to be processed.

[0101] S303. If the billing type corresponding to the transaction to be processed is the first target billing type, then the transaction to be processed is marked with a billing type, and the transaction to be processed after the billing type marking is added to the transaction pool.

[0102] In this embodiment of the application, transactions to be processed with the first target billing type are marked with a billing type and added to the transaction pool. The above method enables the consensus node to quickly determine the billing type of the transaction to be packaged based on whether the transaction to be packaged has a billing type mark when obtaining the set of transactions to be packaged from the transaction pool, without having to query the billing type of the transaction to be packaged by calling the billing management contract, thus improving the efficiency of transaction packaging.

[0103] In one embodiment, the above-mentioned billing type marking process for the transaction to be processed can be implemented according to the following steps.

[0104] (1) Obtain the package fee of the pending transaction and the single fee limit included in the transaction restriction rules corresponding to the second object.

[0105] The packaging fee for pending transactions can refer to the amount of Gas required to package the transaction. Since the billing type corresponding to the pending transactions of the second object is the first target billing type, it means that the second object has purchased at least one subscription rule, and the consensus node can obtain the single-transaction fee limit from the transaction limit rule of that subscription rule.

[0106] (2) If the packaged cost of the transaction to be processed is less than or equal to the single cost limit included in the transaction restriction rules corresponding to the second object, then add a billing type mark to the transaction to be processed.

[0107] If the package fee for the pending transaction is less than or equal to the single transaction fee limit mentioned above, it means that the package fee for the pending transaction has not exceeded the maximum fee threshold specified in the subscription rules. The pending transaction can be paid using the subscription rules already purchased by the second object, without having to pay the package fee separately for the pending transaction.

[0108] (3) If the packaged cost of the pending transaction is greater than the single-transaction cost limit included in the transaction restriction rules corresponding to the second object, no billing type mark will be added to the pending transaction.

[0109] If the package fee for a pending transaction exceeds the single-transaction fee cap mentioned above, it means that the package fee for the pending transaction exceeds the maximum fee threshold specified in the subscription rules. The pending transaction cannot be paid using the subscription rules already purchased by the second object, and a separate package fee needs to be paid for the pending transaction.

[0110] The above methods can effectively prevent entities from using subscription rules to package abnormal transactions, such as extremely large transaction data, after purchasing subscription rules, thereby restricting the initiation of abnormal transactions, thus avoiding blockchain network congestion and ensuring the security and stability of blockchain transactions.

[0111] In one embodiment, the above-mentioned billing type marking process for transactions to be processed can also involve the consensus node marking transactions to be processed with a first target billing type as a first mark, and transactions to be processed with a second target billing type as a second mark. Based on this, when the consensus node obtains a set of transactions to be packaged from the transaction pool, it determines the billing type of the transactions to be packaged based on the billing type markings of the transactions to be packaged (for example, if a transaction to be packaged has a first mark, then the transaction to be packaged is of the first target billing type).

[0112] In one embodiment, in addition to the first and second target billing types, a third billing type may also exist. The third billing type is essentially a combination of the first and second target billing types. For example, the bundled fee for transactions to be processed that is less than or equal to the aforementioned single-transaction fee cap is paid using the purchased subscription rules (i.e., the first billing type); the bundled fee for transactions to be processed that is greater than the aforementioned single-transaction fee cap is paid using individual transaction billing (i.e., the second billing type). This method improves the flexibility of bundled fee payment and diversifies payment methods.

[0113] In one embodiment, for an object of the second target billing type (i.e., an object that has purchased a subscription rule), the data structure in which it initiates a blockchain transaction may include the following fields.

[0114]

[0115] For objects of the first target billing type (i.e., objects that have not purchased subscription rules), the data structure initiating a blockchain transaction may include the following fields.

[0116]

[0117]

[0118] The single transaction limit field in the transaction can be an integer type. To better accommodate this data type, the number "1" can be used to fill in the single transaction limit field, indicating the use of the Flag for the second target billing type. The billing type flag mentioned in this application can refer to the subscription rule Flag in the transaction data structure of the first target billing type.

[0119] In subsequent embodiments, the billing type flag refers to the use subscription rule Flag in the transaction data structure of the first target billing type.

[0120] The following section will introduce the various parameters in the transaction restriction rules.

[0121] Subscription rule ID refers to the unique identifier of a subscription rule.

[0122] Concurrency refers to the maximum number of transactions from the same address (i.e., the same object) that can be packaged in a block. It should be noted that concurrency only limits the number of transactions from the same user using the subscription rules in a block, and does not limit the number of transactions billed as a single transaction in this scheme.

[0123] The single transaction limit (Gas limit) refers to the maximum Gas consumption of each transaction of an object of the first target billing type during execution. If the Gas consumption of a transaction initiated by the object exceeds this limit when it is packaged, the transaction will fail.

[0124] The validity period refers to the duration for which you can initiate transactions for free after purchasing a subscription rule. Common durations include 1 month, 2 months, 3 months, 6 months, 1 year, and 2 years. Administrators can flexibly set these durations based on actual business needs.

[0125] The cost of a subscription rule refers to the number of Gases that an object needs to pay at once if it subscribes to this subscription rule.

[0126] In one embodiment, a consensus node can package transactions of multiple objects into a single block. These transactions can be mixed (i.e., for one object, transactions belonging to a first target billing type and transactions belonging to a second target billing type can be packaged into the same block). Furthermore, the concurrency of the subscription rules can limit the maximum number of transactions from the same object belonging to the first target billing type that can be packaged in a single block. If the number of transactions belonging to the first target billing type for that object in a block does not exceed the concurrency limit, it can be packaged normally by the consensus node, and the object does not need to pay a separate packaging fee.

[0127] For example, the set of transactions to be packaged by the consensus node includes transactions corresponding to objects U1, U2, and U3. Object U1 includes transaction 11 belonging to the first target billing type; object U2 includes transactions 21 and 22 belonging to the first target billing type, and transactions 23 and 24 belonging to the second target billing type; object U3 includes transactions 31, 32, 33, and 34 belonging to the first target billing type. If objects U1, U2, and U3 all purchase a subscription rule with a concurrency level of 2, then when the consensus node packages transactions, it will package transactions 11, 21, 22, 23, 24, 31, and 32 into the same block (specific process: for object U1, the number of transactions belonging to the first target billing type does not exceed the concurrency level, so transaction 11 can be packaged; for object U2, the number of transactions belonging to the first target billing type does not exceed the concurrency level, and there is no restriction on the number of transactions belonging to the second target billing type, so transactions 21, 22, 23, and 24 can be packaged; for object U3, the number of transactions belonging to the first target billing type exceeds the concurrency level, so only transactions that meet the concurrency level of 2 can be selected from object U3's transactions for packaging, such as transactions 31 and 32).

[0128] S304. If the billing type corresponding to the transaction to be processed is the second target billing type, then add the transaction to be processed to the transaction pool.

[0129] In this embodiment of the application, if the billing type corresponding to the transaction to be processed is the second target billing type, the consensus node does not mark the billing type of the transaction to be processed, but directly adds the transaction to the transaction pool.

[0130] In one embodiment, the consensus node may also mark pending transactions with a first target billing type as a first mark and pending transactions with a second target billing type as a second mark. Based on this, when the consensus node obtains a set of transactions to be packaged from the transaction pool, it determines the billing type of the transactions to be packaged according to the billing type mark of the transactions to be packaged (for example, if the transactions to be packaged have a first mark, then the transactions to be packaged are of the first target billing type).

[0131] S305. Obtain the set of transactions to be packaged from the transaction pool.

[0132] S306. Determine at least one object corresponding to the transaction to be packaged included in the transaction to be packaged set, and determine a candidate transaction set corresponding to each object in the at least one object in the transaction to be packaged set.

[0133] The specific implementation methods of steps S305 to S306 are described in the relevant descriptions of steps S201 to S202 in the aforementioned embodiments, and will not be repeated here.

[0134] S307. Obtain the billing type of the first object. If the billing type is the first target billing type, obtain the M candidate transactions marked with the billing type in the candidate transaction set corresponding to the first object, and obtain the package fee of each candidate transaction in the M candidate transactions. Then, determine the candidate transactions whose package fee is less than or equal to the single fee limit from the candidate transaction set corresponding to the first object.

[0135] In this embodiment, the consensus node needs to perform the following two steps to determine N candidate transactions from the candidate transaction set corresponding to the first object based on the transaction restriction rules corresponding to the first object: First, the consensus node filters the M candidate transactions with billing type tags in the candidate transaction set corresponding to the first object based on the single-transaction fee limit, ensuring that the packaged fee is less than or equal to the single-transaction fee limit. Second, the consensus node further filters the filtered candidate transactions based on concurrency. Step S307 describes the first step, and step S308 describes the second step.

[0136] In the first step, the consensus node first obtains the packaging fee of each candidate transaction among the M candidate transactions corresponding to the first object, then obtains the single fee limit corresponding to the subscription rule purchased by the first object, and determines the candidate transactions whose packaging fee is less than or equal to the single fee limit from the M candidate transactions corresponding to the first object based on the single fee limit.

[0137] In one embodiment, the above-mentioned acquisition of the billing type of the first object can be achieved through the following two methods.

[0138] The first method is to query the billing type of the first object from the billing management contract by calling the data query method of the billing management contract based on the object identifier of the first object.

[0139] The billing management contract stores relationship data between various objects and their corresponding billing types. For example, it stores the correspondence between the object identifier (i.e., the ID of the second object) and the billing type of the second object (e.g., the first target billing type, i.e., time-based package billing). Using this method, consensus nodes only need to obtain the object identifier to quickly query the corresponding billing type from the billing management contract, thus improving query efficiency.

[0140] The second method is to obtain the billing type tag of any candidate transaction in the candidate transaction set corresponding to the first object, and determine the billing type of the first object based on the billing type tag of any candidate transaction.

[0141] In this system, each candidate transaction in the candidate transaction set corresponding to the first object represents a transaction within a specific time period. If the first object has purchased a subscription rule, then every candidate transaction in the candidate transaction set corresponding to the first object will have a billing type tag; if the first object has not purchased a subscription rule, then none of the candidate transactions in the candidate transaction set corresponding to the first object will have a billing type tag. Therefore, the consensus node can determine the billing type of the first object by obtaining the billing type tag of any candidate transaction in the candidate transaction set corresponding to the first object, without needing to determine the billing type tags of all candidate transactions in the candidate transaction set corresponding to the first object, thus improving the efficiency of obtaining the billing type.

[0142] In one embodiment, when a first object purchases a subscription rule, and there is a candidate transaction with an extremely high package fee in the candidate transaction set corresponding to the first object, this extremely high candidate transaction may not meet the single-transaction fee limit of the subscription rule purchased by the first object, and therefore, no billing type label will be provided. Therefore, in the above-mentioned billing type labeling process for transactions to be processed, the consensus node can label transactions with a first target billing type as the first label, and transactions with a second target billing type as the second label. By obtaining the billing type label of any candidate transaction in the candidate transaction set corresponding to the first object, the billing type of the first object can be determined (if any candidate transaction has a first label, then the billing type of the first object is the first target billing type; if any candidate transaction has a second label, then the billing type of the first object is the second target billing type).

[0143] In addition, consensus nodes can also set a fee judgment threshold (when the packaging fee of a transaction is less than the fee judgment threshold, the transaction will not lack a billing type label because it exceeds the single-transaction fee limit of the subscription rule purchased by the first object; this fee judgment threshold can be a small threshold set based on experience). Based on this, when using the second method mentioned above (i.e., determining the billing type of the first object based on the billing type label of any candidate transaction), a candidate transaction can be randomly selected from the candidate transaction set corresponding to the first object. At this time, it is judged whether the packaging fee of the transaction is less than or equal to the fee judgment threshold; if not, a candidate transaction is randomly selected again from the candidate transaction set corresponding to the first object, until a candidate transaction with a packaging fee less than or equal to the fee judgment threshold is obtained. The billing type of the first object is determined by the obtained candidate transaction that meets the condition. Through the above method, it is not necessary to judge the billing type label of each candidate transaction in the candidate transaction set one by one, thereby improving the efficiency of determining the billing type and thus improving the efficiency of packaging transactions.

[0144] S308. Determine N candidate transactions from the candidate transactions whose packaged cost is less than or equal to the single transaction cost limit based on the concurrency. The concurrency is used to indicate the upper limit of the number of transactions. The first object is any one of at least one objects. N is a positive integer. The transaction restriction rules include concurrency and single transaction cost limit. The concurrency is used to indicate the maximum number of N candidate transactions. The single transaction cost limit is used to indicate the maximum packaged cost of the transaction.

[0145] This application describes a second step that needs to be performed when determining N candidate transactions from the candidate transaction set corresponding to the first object according to the transaction restriction rules corresponding to the first object, namely, further filtering the filtered candidate transactions by using concurrency.

[0146] In the second step, concurrency is used to indicate the upper limit of the number of transactions from the same object when a transaction is packaged in a single transaction. The consensus node first obtains the concurrency from the subscription rules purchased by the first object, and then determines N candidate transactions that meet the concurrency requirement from among the candidate transactions whose packaging fee is less than or equal to the single transaction fee limit.

[0147] S309. Package N candidate transactions into the target block.

[0148] The specific implementation of step S309 is described in the relevant description of step S203 in the foregoing embodiments, and will not be repeated here.

[0149] In one embodiment, if the third object is the object of the pre-purchase subscription rule, then the above method may further include the following steps.

[0150] (1) Obtain at least one candidate subscription rule included in the first target billing type in the billing management contract, and send at least one candidate subscription rule to the terminal device corresponding to the third object; wherein, each candidate subscription rule in the at least one candidate subscription rule corresponds to a transaction restriction rule, and the transaction restriction rule corresponding to each candidate subscription rule includes one or more of concurrency, single fee limit and validity period.

[0151] In this embodiment, the administrator object can preset multiple types of candidate subscription rules for the first target billing type. Candidate subscription rules can be understood as subscription rules corresponding to a transaction restriction rule (including concurrency, single transaction fee limit, validity period, etc.). The consensus node obtains the multiple candidate subscription rules included in the first target billing type from the billing management contract and sends these multiple candidate subscription rules to the terminal device corresponding to the third object. The consensus node receives a subscription transaction sent by the terminal device corresponding to the third object. The subscription transaction can include the identification information (i.e., subscription rule ID) of the target subscription rule selected by the third object from the multiple candidate subscription rules, as well as parameters such as the subscription rule's effective date and expiration date.

[0152] (2) Receive a subscription transaction sent by the terminal device corresponding to the third object, wherein the subscription transaction includes the identification information of the target subscription rule selected by the third object from at least one candidate subscription rule.

[0153] In this embodiment of the application, the target subscription rule is the subscription rule selected by the third object. In the subscription transaction, the subscription rule purchased by the third object is recorded with the identification information of the target subscription rule.

[0154] (3) Deduct the cost of the target subscription rule and the package fee of the subscription transaction from the third party's account.

[0155] In this embodiment, each candidate subscription rule corresponds to a subscription rule fee. This fee is used to package transactions using the subscription rule within its validity period, without having to pay a separate packaging fee for each transaction. The packaging fee for subscription transactions refers to the fee that a third party needs to pay for packaging subscription transactions that include the purchased subscription rule, when no subscription rule has been purchased, on a per-transaction basis.

[0156] In one embodiment, if the consensus node detects that the cost of the third object's transfer is less than the sum of the cost of the target subscription rule and the cost of packaging the subscription transaction, it will refuse to perform subsequent operations such as writing the subscription transaction into the blockchain. In this case, the consensus node can send a prompt message to the third object indicating that the purchase of the subscription rule has failed, thereby improving the user experience of the object.

[0157] In one embodiment, after deducting the corresponding fees from the third party's account, the process may further include the following steps: broadcasting the third party's subscription information to other nodes in the blockchain network, so that other nodes can reach a consensus based on the third party's subscription information. Through this method, after the consensus node reaches a consensus with other nodes in the blockchain network on the subscription information, the subscription transaction is written into the blockchain, thus ensuring the security and stability of the data on the blockchain.

[0158] (4) Write the subscription transaction into the blockchain and add the subscription information of the third object to the billing management contract by calling the subscription information creation method of the billing management contract.

[0159] In this embodiment, the consensus node can add the subscription information of a third object to the billing management contract by calling the subscription information creation method of the billing management contract. This allows other nodes to quickly query the subscription information of the target object through the billing management contract, thereby improving data query efficiency. The subscription information creation method of the billing management contract will be described in detail in subsequent embodiments and will not be repeated here.

[0160] In one embodiment, the fourth object is an administrator object that manages subscription rules, and the above method may further include the following steps.

[0161] (1) The consensus node obtains the rule management transaction submitted by the fourth object. The rule management transaction is any one of the rule creation transaction, rule modification transaction, and rule deletion transaction.

[0162] In this embodiment, the rule management transaction is essentially a transaction initiated by a fourth object, used to manage subscription rules within the billing management contract. The rule management transaction may include parameters such as the concurrency required to manage a subscription rule, the maximum fee per transaction, and the validity period. The fourth object can be a superuser with management permissions for the billing management contract.

[0163] (2) When the rule management transaction creates a rule transaction, the consensus node creates at least one candidate subscription rule by calling the rule creation method of the billing management contract. Each candidate subscription rule corresponds to a subscription rule with transaction restriction rules (including concurrency, single transaction fee limit, validity period, etc.).

[0164] (3) When the rule management transaction is a rule modification transaction, the transaction restriction rule corresponding to the created candidate subscription rule is modified by calling the rule modification method of the billing management contract.

[0165] (4) When the rule management transaction is a rule deletion transaction, the consensus node deletes the created candidate subscription rule by calling the rule deletion method of the billing management contract.

[0166] The following section will describe in detail the method for managing transactions according to the consensus node response rules, using the billing management contract as an example. The billing management contract proposed in this application is an embedded contract within the blockchain system. It starts when the blockchain network launches, requiring no installation by the object. Users access relevant functionalities by calling the functions of the billing management contract. The billing management contract can provide various functions for objects with different permissions.

[0167] In one embodiment, when the billing type of the first object is the second target billing type, the above method may further include the following steps.

[0168] (1) If the billing type is the second target billing type, then the target candidate transaction is determined from the candidate transaction set corresponding to the first object.

[0169] (2) After deducting the packaging fee of the target candidate transaction from the account corresponding to the first object, the target candidate transaction is packaged into the target block.

[0170] In this embodiment, the second target billing type is single-transaction billing, which requires separate payment of packaging fees for each transaction. The consensus node can determine one candidate transaction from the candidate transaction set corresponding to the first object as the target candidate transaction, and then deduct the packaging fee of the target candidate transaction from the account corresponding to the first object before packaging the target candidate transaction into the target block.

[0171] The following will introduce the subscription rule creation function, subscription rule modification function, and subscription rule deletion function provided by the billing management contract for the administrator object. (In the above steps (2)-(4), the rule creation method is to call the subscription rule creation function to create the subscription rule; the rule modification method is to call the subscription rule modification function to modify the subscription rule; and the rule deletion method is to call the subscription rule deletion function to delete the subscription rule.)

[0172] The first function is the subscription rule creation function. This function verifies that the calling object is an administrator object. The input parameters include the concurrency required to define a subscription rule, the single fee limit (i.e., the gas limit), the validity period, the cost of the subscription rule, and a description. This function will create a new subscription rule object in the subscription rule list in the state database corresponding to the billing management contract and return a subscription rule identifier (i.e., subscription rule ID) that uniquely represents that subscription rule.

[0173] The second function is the subscription rule modification function. This function verifies that the calling object is an administrator object. The input parameters include the subscription rule ID required to modify a subscription rule, the concurrency level, the single-transaction fee limit (i.e., the gas limit), the validity period, the subscription rule fee, and a description. This function will find the subscription rule object in the subscription rule list in the status database corresponding to the billing management contract, based on the subscription rule ID, modify the subscription rule, and then return a status code indicating whether the modification was successful or failed.

[0174] The third function is the subscription rule deletion function. This function verifies that the calling object is an administrator object. The input parameters include the subscription rule ID required to delete a subscription rule. This function will find the subscription rule object in the subscription rule list in the status database corresponding to the billing management contract, based on the subscription rule ID, and delete the subscription rule. Then, it will return a status code indicating whether the modification was successful or failed. After this type of subscription rule is deleted, the object can no longer purchase that subscription rule.

[0175] It should be noted that when consensus nodes create, modify, or delete a subscription rule using the methods described above, it will not affect the use of objects that have already purchased the subscription rule. This reduces the object cooperation cost when modifying the preset subscription rules in the billing management contract and improves the user experience of the objects.

[0176] Please see Figure 4A This diagram illustrates a sequence diagram of an administrator managing subscription rules as proposed in this application embodiment. The administrator first determines the parameters required to create (or modify) a subscription rule, such as concurrency, single-transaction fee cap, and validity period (corresponding to step 1 in the diagram); then, the administrator calls the billing management contract to pre-create (or modify) the subscription rule (corresponding to step 2 in the diagram); the billing management contract first checks the permission information of the initiating object of creating (or modifying) the subscription rule, as well as the data validity (corresponding to step 3 in the diagram); if the billing management contract verifies that the initiating object is an administrator and the parameter information for creating (or modifying) the subscription rule is valid, then it performs the creation (or modification) operation of the subscription rule based on the received parameter information (corresponding to step 4 in the diagram); finally, the billing management contract saves the created (or modified) subscription rule to the blockchain ledger (corresponding to step 5 in the diagram).

[0177] The following describes the subscription rule query function, subscription rule purchase function, and subscription rule unsubscription function provided by the billing management contract for administrator objects and ordinary objects. (The data query method of the billing management contract in this application embodiment is to call the subscription rule query function to query the subscription rules; the method of the consensus node to purchase subscription rules for the third object based on the subscription transaction of the third object is to call the subscription rule purchase function to purchase the subscription rules; in addition, administrator objects or ordinary objects can also call the subscription rule unsubscription function to unsubscribe from the purchased subscription rules.)

[0178] The first function is the subscription rule query function. This function verifies that the calling object can be an administrator object or a regular object. The input parameters include the object identifier (i.e., object ID) of the subscription rules existing in the object being queried. It queries the list of currently active subscription rules, historical subscription rules, etc., for the object corresponding to that object ID.

[0179] Specifically, after an object purchases subscription rules, the billing management contract records the relationship data between the purchasing object and the purchased subscription rules. An administrator object (or a regular object) can retrieve the object's purchased subscription rules by calling the subscription rule query function, using the object's object identifier (i.e., object ID). Furthermore, if the object has valid subscription rules, its billing type is the first target billing type (i.e., time-based package billing); if the object does not have valid subscription rules, its billing type is the second target billing type (i.e., single transaction billing).

[0180] The second function is the subscription rule purchase function. This function verifies that the calling object can be an administrator object or a regular object. The input parameters include the subscription rule ID required to purchase a subscription rule. Simultaneously, during this subscription transaction initiated by the object, the account balance (e.g., Gas) under its own account needs to be transferred to the billing management contract. The subscription rule purchase function will create a new subscription rule purchase object in the subscription rule purchase list record in the state database corresponding to the billing management contract. The attributes of this subscription rule purchase object include: package ID, concurrency level, single transaction fee limit (i.e., Gas limit), validity period (including (subscription rule effective date, subscription rule expiration date), subscription rule fee, and purchase object identifier (generally referring to the purchase object's address on the blockchain). If the Gas transferred by the purchase object matches the corresponding subscription rule purchased, the subscription rule purchase is successful, and a unique ID identifying this subscription rule purchase record is returned; if the Gas transferred by the purchase object does not match the corresponding subscription rule purchased, a purchase failure message is returned.

[0181] It should be noted that the same object can purchase multiple different types of subscription rules within a time period, but only one subscription rule of the object is active within that time period.

[0182] The third function is the subscription rule unsubscription function. This function verifies that the calling object can be an administrator object or a regular object. This function does not require parameters. The consensus node can obtain the address of the object that calls the subscription rule unsubscription function, and then query the active subscription rule purchase records of that object. Then, it modifies the status of the subscription rule purchase record in the state database to unsubscribe, and returns Gas according to certain rules (for example, returning a portion of Gas based on the time used).

[0183] It should be noted that, in addition to providing administrators and ordinary users with functions for querying, purchasing, and unsubscribing from subscription rules, the billing management contract also offers functions such as subscription rule renewal and subscription rule expansion. Furthermore, the validity period of subscription rules can be freely set, such as one year, one month, one hour, one day, two days, one week, etc.

[0184] Please see Figure 4BThis diagram is a sequence diagram of an object purchasing subscription rules according to an embodiment of this application. The purchase of subscription rules by an object (e.g., a non-administrator) involves two steps: querying the subscription rule list (corresponding to step 1 in the diagram) and purchasing the subscription rule (corresponding to step 2 in the diagram). In step one, the object first calls the billing management contract (corresponding to step 1.1 in the diagram); then, it uses the billing management contract to query the blockchain ledger (corresponding to step 1.2 in the diagram); the blockchain ledger queries the subscription rule list for purchasable candidate subscription rules based on the query request (corresponding to step 1.3 in the diagram); finally, the blockchain ledger returns the query results to the object (corresponding to step 1.4 in the diagram), the query results including one or more purchasable candidate subscription rules.

[0185] After the object receives the candidate subscription rules returned by the blockchain ledger, it can proceed to step two, which is to purchase the subscription rule. In step one, the object first calls the billing management contract to pre-purchase the subscription rule (corresponding to step 2.1 in the diagram); the billing management contract checks the legality of the transaction data sent by the object for purchasing the subscription rule (corresponding to step 2.2 in the diagram); the billing management contract determines whether conditions such as gas transfer are met (corresponding to step 2.3 in the diagram); if the requirements are met, the billing management contract generates subscription rule purchase information (corresponding to step 2.4 in the diagram), which includes information such as the purchase object identifier, subscription rule ID, and validity period; the billing management contract sends the subscription rule purchase information to the blockchain ledger (corresponding to step 2.5 in the diagram); finally, the blockchain ledger records the subscription rule purchase information (corresponding to step 2.6 in the diagram).

[0186] Please see Figure 4C This diagram illustrates a timing sequence of transaction packaging by a consensus node, as proposed in this embodiment. The diagram includes four main components: an object (e.g., a non-administrator transaction initiator of the first billing type), a consensus node, a billing management contract, and a transaction pool. The transaction initiator first constructs a transaction of the first billing type (corresponding to step 1 in the diagram); then broadcasts the constructed transaction of the first billing type to the consensus node (corresponding to step 2 in the diagram); upon receiving the broadcast information, the consensus node verifies whether the transaction is valid and has not been packaged (corresponding to step 3 in the diagram); if the transaction is valid and has not been packaged, it saves the transaction to the transaction pool (corresponding to step 4 in the diagram).

[0187] When preparing to generate a new block, the consensus node retrieves a set of transactions to be packaged from the transaction pool for contract execution and consensus (corresponding to step 5 in the diagram). For any transaction in the set of transactions to be packaged, the node first checks the subscription rule purchase status of that transaction initiator (corresponding to step 6 in the diagram). Specifically, the consensus node calls the billing management contract (corresponding to step 6.1 in the diagram) so that the billing management contract can query the subscription rule purchase information of the transaction initiator (corresponding to step 6.2 in the diagram), and the billing management contract then returns the query results including the subscription rule purchase information (corresponding to step 6.3 in the diagram). After receiving the query result, the consensus node obtains the concurrency level from the subscription rule purchase information and determines whether the number of transactions to be packaged belonging to the transaction initiator in the transaction set exceeds the concurrency level (corresponding to step 7 in the figure). The consensus node returns the transactions that exceed the concurrency level to the transaction pool (corresponding to step 8 in the figure) so that the transaction pool can save the received unpackaged transactions (corresponding to step 9 in the figure). After the transaction pool returns the saving success information to the consensus node (corresponding to step 10 in the figure), the consensus node packages the transactions that do not exceed the concurrency level (corresponding to step 11 in the figure).

[0188] In one embodiment, the above method is mainly applied to open consortium blockchain scenarios with gas control. For public blockchains, the collection and distribution of consensus node transaction fees also involves the issue. Specifically, reward and punishment measures can be introduced for consensus nodes. For example, by having consensus nodes pay a deposit, additional rewards can be given when transactions of the first target billing type (i.e., time-based billing packages) are packaged; and the deposit can be deducted when transactions of the first target billing type (i.e., time-based billing packages) are intentionally not packaged. This method can improve the fairness of consensus nodes packaging transactions on the blockchain, thereby improving the stability of the blockchain.

[0189] The beneficial effects of this application are as follows.

[0190] In the first embodiment, this application proposes to obtain the billing type through the pending transaction data structure sent by the object, thereby improving the efficiency of obtaining the billing type of pending transactions. In this embodiment, it is proposed to add pending transactions of the first target billing type to the transaction pool after marking them with a billing type; and to directly add pending transactions of the second target billing type to the transaction pool. The above method allows consensus nodes to quickly determine the billing type of pending transactions when obtaining the set of transactions to be packaged from the transaction pool based on whether the pending transactions have a billing type mark, without needing to query the billing type of each pending transaction by calling the billing management contract, thus improving the efficiency of transaction packaging.

[0191] This application also proposes two methods for determining the billing type corresponding to a pending transaction: querying the billing type using a billing management contract based on the object identifier, and determining the billing type based on the object's billing type selection information. It also proposes two methods for obtaining the billing type of a first object: querying the billing type using a billing management contract based on the object identifier, and determining the billing type based on the billing type tag of any candidate transaction in the candidate transaction set. These methods improve the flexibility of billing types and enable the acquisition of billing types in different ways within different transaction processing environments, thereby improving the efficiency of obtaining the billing type of pending transactions.

[0192] This application also proposes that during the billing type marking process, if the packaged cost of the pending transaction does not exceed the single-transaction cost limit, then the transaction is marked; if the packaged cost of the pending transaction exceeds the single-transaction cost limit, then the transaction is not marked. This method effectively prevents entities from using subscription rules to package abnormal transactions, such as extremely large transaction data, after purchasing subscription rules, thus restricting abnormal transaction initiation behavior, preventing blockchain network congestion, and ensuring the security and stability of blockchain transactions.

[0193] This application proposes that, when the object is a second target billing type, the consensus node, after paying the packaging fee for each candidate transaction in the candidate transaction set, packages the paid transactions into the target block. This application also proposes a fusion payment type combining the first and second target billing types, improving the flexibility of packaging fee payment and the diversification of payment methods.

[0194] For objects that have pre-purchased subscription rules, this application proposes sending multiple candidate subscription rules to the object, then determining the target subscription rule based on the subscription transaction sent by the object, and writing the subscription information into the billing management contract after successful deduction. Other nodes can quickly query the object's subscription information through the billing management contract, thereby improving data query efficiency. For administrator objects that manage subscription rules, this application proposes executing rule creation, rule modification, and rule deletion transactions as instructed by the rule management transaction through the rule management transaction submitted by the object. Furthermore, the above operations will not affect the use of objects that have already purchased the subscription rule, thereby reducing the object's cooperation cost when modifying the preset subscription rules in the billing management contract and improving the object's user experience.

[0195] Please see Figure 5 This figure is a schematic diagram of a blockchain-based data processing device provided in an embodiment of this application. The data processing device described in this embodiment can be applied to the above embodiments, including:

[0196] The acquisition module 501 is used to obtain a set of transactions to be packaged from the transaction pool;

[0197] Processing module 502 is used to determine at least one object corresponding to the transaction to be packaged included in the above-mentioned transaction to be packaged set, and to determine a candidate transaction set corresponding to each of the at least one object in the above-mentioned transaction to be packaged set.

[0198] The aforementioned processing module 502 is further configured to obtain the billing type of the first object. If the billing type is the first target billing type, then N candidate transactions are determined from the candidate transaction set corresponding to the first object according to the transaction restriction rules corresponding to the first object. The first object is any one of the above at least one object, and N is a positive integer. The transaction restriction rules include concurrency and single transaction fee limit. The concurrency is used to indicate the maximum number of the above N candidate transactions, and the single transaction fee limit is used to indicate the maximum package fee of the transaction.

[0199] The packaging module 503 is used to package the above N candidate transactions into the target block.

[0200] Optionally, the candidate transaction set corresponding to the first object includes one or both of the following: candidate transactions with billing type tags and candidate transactions without billing type tags. The processing module 502, when determining N candidate transactions from the candidate transaction set corresponding to the first object according to the transaction restriction rules, specifically performs the following:

[0201] Obtain M candidate transactions with billing type tags from the candidate transaction set corresponding to the first object mentioned above, where M is a positive integer;

[0202] Based on the transaction restriction rules corresponding to the first object mentioned above, N candidate transactions are determined from the M candidate transactions mentioned above.

[0203] Optionally, the processing module 502 described above, when used to obtain the billing type of the first object, is specifically used for:

[0204] Based on the object identifier of the first object, the billing type of the first object is retrieved from the billing management contract by calling the data query method of the billing management contract;

[0205] Alternatively, query whether there is a candidate transaction with a billing type tag in the candidate transaction set corresponding to the first object, obtain the query results, and determine the billing type of the first object based on the query results.

[0206] Optionally, when the processing module 502 determines N candidate transactions from the M candidate transactions according to the transaction restriction rules corresponding to the first object, it is specifically used for:

[0207] Obtain the package cost of each candidate transaction among the above M candidate transactions, and determine the candidate transactions whose package cost is less than or equal to the above single transaction cost limit from the candidate transaction set corresponding to the above first object.

[0208] Based on the concurrency level mentioned above, N candidate transactions are determined from the candidate transactions whose packaged cost is less than or equal to the single transaction cost limit mentioned above. The concurrency level mentioned above is used to indicate the upper limit of the number of transactions.

[0209] Optionally, the acquisition module 501 described above is further used for:

[0210] Obtain a transaction request from a second object, the transaction request including pending transactions;

[0211] The aforementioned processing module 502 is also used for:

[0212] Determine the billing type corresponding to the above pending transactions;

[0213] If the billing type corresponding to the above pending transaction is the first target billing type, then the above pending transaction is marked with a billing type and the billing type marked pending transaction is added to the transaction pool;

[0214] If the billing type corresponding to the above pending transaction is the second target billing type, then the above pending transaction will be added to the above transaction pool.

[0215] Optionally, the processing module 502, when determining the billing type corresponding to the transaction to be processed, is specifically used for:

[0216] Based on the object identifier of the second object, the billing type of the second object is queried from the billing management contract by calling the data query method of the billing management contract, and the billing type of the second object is used as the billing type corresponding to the transaction to be processed.

[0217] Alternatively, the billing type selection information of the second object input included in the transaction request can be obtained, and the billing type corresponding to the transaction to be processed can be determined according to the billing type selection information. The billing type selection information is used to indicate the first target billing type or the second target billing type.

[0218] Optionally, when the processing module 502 performs billing type marking processing on the transaction to be processed, it is specifically used for:

[0219] Obtain the package fee for the above pending transactions, and the single-transaction fee limit included in the transaction restriction rules corresponding to the above second object;

[0220] If the packaged cost of the above pending transactions is less than or equal to the single-transaction cost limit included in the transaction restriction rules corresponding to the above second object, then add a billing type mark to the above pending transactions.

[0221] If the packaged cost of the above pending transactions exceeds the single-transaction cost limit included in the transaction restriction rules corresponding to the second object, then no billing type mark will be added to the above pending transactions.

[0222] Optionally, the above-mentioned processing module 502 is further configured to:

[0223] Obtain at least one candidate subscription rule included in the first target billing type in the billing management contract, and send the at least one candidate subscription rule to the terminal device corresponding to the third object;

[0224] The device receives a subscription transaction sent by the terminal device corresponding to the third object, wherein the subscription transaction includes the identification information of the target subscription rule selected by the third object from the at least one candidate subscription rule;

[0225] The fees for the aforementioned target subscription rules and the bundled fees for the aforementioned subscription transactions shall be deducted from the account of the aforementioned third party.

[0226] The aforementioned subscription transactions are written into the blockchain, and the subscription information of the aforementioned third object is added to the aforementioned billing management contract by calling the subscription information creation method of the billing management contract;

[0227] Among them, each of the above-mentioned candidate subscription rules corresponds to a transaction restriction rule, and the transaction restriction rule corresponding to each candidate subscription rule includes one or more of the following: concurrency, single transaction fee limit, and validity period.

[0228] Optionally, the packaging module 503 described above is also used for:

[0229] The subscription information of the aforementioned third object is broadcast to other nodes in the blockchain network so that the other nodes can reach a consensus based on the subscription information of the aforementioned third object.

[0230] Optionally, the above-mentioned processing module 502 is further configured to:

[0231] Obtain the rule management transaction submitted by the fourth object, where the rule management transaction is any one of the rule creation transaction, rule modification transaction, and rule deletion transaction;

[0232] When the above rule management transaction creates a transaction for a rule, at least one candidate subscription rule is created by calling the rule creation method of the billing management contract;

[0233] When the above rule management transaction is a rule modification transaction, the transaction restriction rule corresponding to the created candidate subscription rule is modified by calling the rule modification method of the billing management contract.

[0234] When the above rule management transaction is a rule deletion transaction, the created candidate subscription rule is deleted by calling the rule deletion method of the billing management contract.

[0235] Optionally, the above-mentioned processing module 502 is further configured to:

[0236] If the above billing type is the second target billing type, then the target candidate transaction is determined from the candidate transaction set corresponding to the first object.

[0237] The aforementioned packaging module 503 is also used for:

[0238] After deducting the packaging fee of the target candidate transaction from the account corresponding to the first object, the target candidate transaction is packaged into the target block.

[0239] It should be noted that the functions of each functional module of the data processing device in this application embodiment can be specifically implemented according to the methods in the above method embodiments. The specific implementation process can be referred to the relevant descriptions in the above method embodiments, which will not be repeated here.

[0240] Please see Figure 6 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application. The data processing device described in this embodiment includes: a processor 601, a memory 602, and a network interface 603. The processor 601, the memory 602, and the network interface 603 can exchange data.

[0241] The processor 601 described above can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0242] The aforementioned memory 602 may include read-only memory and random access memory, and provides program instructions and data to the processor 601. A portion of memory 602 may also include non-volatile random access memory. In feasible embodiments, this data processing device can be applied to the embodiments described above, wherein the processor 601, when invoking the aforementioned program instructions, executes:

[0243] Retrieve the set of transactions to be packaged from the transaction pool;

[0244] Identify at least one object corresponding to the transaction to be packaged included in the above-mentioned transaction to be packaged set, and determine a candidate transaction set corresponding to each of the above-mentioned at least one object from the above-mentioned transaction to be packaged set;

[0245] Obtain the billing type of the first object. If the billing type is the first target billing type, then determine N candidate transactions from the candidate transaction set corresponding to the first object according to the transaction restriction rules corresponding to the first object. The first object is any one of the above at least one objects. N is a positive integer. The transaction restriction rules include concurrency and single transaction fee limit. The concurrency is used to indicate the maximum number of the above N candidate transactions. The single transaction fee limit is used to indicate the maximum package fee of the transaction.

[0246] Package the above N candidate transactions into the target block.

[0247] Optionally, the candidate transaction set corresponding to the first object includes one or both of the following: candidate transactions with billing type tags and candidate transactions without billing type tags. When the processor 601 determines N candidate transactions from the candidate transaction set corresponding to the first object according to the transaction restriction rules, it specifically performs the following:

[0248] Obtain M candidate transactions with billing type tags from the candidate transaction set corresponding to the first object mentioned above, where M is a positive integer;

[0249] Based on the transaction restriction rules corresponding to the first object mentioned above, N candidate transactions are determined from the M candidate transactions mentioned above.

[0250] Optionally, the processor 601 described above, when used to obtain the billing type of the first object, is specifically used for:

[0251] Based on the object identifier of the first object, the billing type of the first object is retrieved from the billing management contract by calling the data query method of the billing management contract;

[0252] Alternatively, query whether there is a candidate transaction with a billing type tag in the candidate transaction set corresponding to the first object, obtain the query results, and determine the billing type of the first object based on the query results.

[0253] Optionally, when the processor 601 is used to determine N candidate transactions from the M candidate transactions according to the transaction restriction rules corresponding to the first object, it is specifically used for:

[0254] Obtain the package cost of each candidate transaction among the above M candidate transactions, and determine the candidate transactions whose package cost is less than or equal to the above single transaction cost limit from the candidate transaction set corresponding to the above first object.

[0255] Based on the concurrency level mentioned above, N candidate transactions are determined from the candidate transactions whose packaged cost is less than or equal to the single transaction cost limit mentioned above. The concurrency level mentioned above is used to indicate the upper limit of the number of transactions.

[0256] Optionally, the processor 601 described above is also used for:

[0257] Obtain a transaction request from a second object, the transaction request including pending transactions;

[0258] The aforementioned processor 601 is also used for:

[0259] Determine the billing type corresponding to the above pending transactions;

[0260] If the billing type corresponding to the above pending transaction is the first target billing type, then the above pending transaction is marked with a billing type and the billing type marked pending transaction is added to the transaction pool;

[0261] If the billing type corresponding to the above pending transaction is the second target billing type, then the above pending transaction will be added to the above transaction pool.

[0262] Optionally, the processor 601, when determining the billing type corresponding to the transaction to be processed, is specifically used for:

[0263] Based on the object identifier of the second object, the billing type of the second object is queried from the billing management contract by calling the data query method of the billing management contract, and the billing type of the second object is used as the billing type corresponding to the transaction to be processed.

[0264] Alternatively, the billing type selection information of the second object input included in the transaction request can be obtained, and the billing type corresponding to the transaction to be processed can be determined according to the billing type selection information. The billing type selection information is used to indicate the first target billing type or the second target billing type.

[0265] Optionally, when the processor 601 performs billing type marking processing on the transaction to be processed, it is specifically used for:

[0266] Obtain the package fee for the above pending transactions, and the single-transaction fee limit included in the transaction restriction rules corresponding to the above second object;

[0267] If the packaged cost of the above pending transactions is less than or equal to the single-transaction cost limit included in the transaction restriction rules corresponding to the above second object, then add a billing type mark to the above pending transactions.

[0268] If the packaged cost of the above pending transactions exceeds the single-transaction cost limit included in the transaction restriction rules corresponding to the second object, then no billing type mark will be added to the above pending transactions.

[0269] Optionally, the processor 601 described above is also used for:

[0270] Obtain at least one candidate subscription rule included in the first target billing type in the billing management contract, and send the at least one candidate subscription rule to the terminal device corresponding to the third object;

[0271] The device receives a subscription transaction sent by the terminal device corresponding to the third object, wherein the subscription transaction includes the identification information of the target subscription rule selected by the third object from the at least one candidate subscription rule;

[0272] The fees for the aforementioned target subscription rules and the bundled fees for the aforementioned subscription transactions shall be deducted from the account of the aforementioned third party.

[0273] The aforementioned subscription transactions are written into the blockchain, and the subscription information of the aforementioned third object is added to the aforementioned billing management contract by calling the subscription information creation method of the billing management contract;

[0274] Among them, each of the above-mentioned candidate subscription rules corresponds to a transaction restriction rule, and the transaction restriction rule corresponding to each candidate subscription rule includes one or more of the following: concurrency, single transaction fee limit, and validity period.

[0275] Optionally, the processor 601 described above is also used for:

[0276] The subscription information of the aforementioned third object is broadcast to other nodes in the blockchain network so that the other nodes can reach a consensus based on the subscription information of the aforementioned third object.

[0277] Optionally, the processor 601 described above is also used for:

[0278] Obtain the rule management transaction submitted by the fourth object, where the rule management transaction is any one of the rule creation transaction, rule modification transaction, and rule deletion transaction;

[0279] When the above rule management transaction creates a transaction for a rule, at least one candidate subscription rule is created by calling the rule creation method of the billing management contract;

[0280] When the above rule management transaction is a rule modification transaction, the transaction restriction rule corresponding to the created candidate subscription rule is modified by calling the rule modification method of the billing management contract.

[0281] When the above rule management transaction is a rule deletion transaction, the created candidate subscription rule is deleted by calling the rule deletion method of the billing management contract.

[0282] Optionally, the processor 601 described above is also used for:

[0283] If the above billing type is the second target billing type, then the target candidate transaction is determined from the candidate transaction set corresponding to the first object.

[0284] The aforementioned processor 601 is also used for:

[0285] After deducting the packaging fee of the target candidate transaction from the account corresponding to the first object, the target candidate transaction is packaged into the target block.

[0286] In specific implementations, the processor 601, memory 602, and network interface 603 described in the embodiments of this application can execute the embodiments of this application. Figure 2 or Figure 3 The implementation methods described in the relevant embodiments of the provided data processing method can also be used to execute the embodiments of this application. Figure 5 The implementation methods described in the relevant embodiments of the provided data processing device will not be repeated here.

[0287] In the several embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, and systems can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and other division methods may exist in actual implementation; 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, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0288] This application also provides a computer-readable storage medium storing program instructions, which, when executed, may include, for example... Figure 2 or Figure 3Some or all of the steps of the blockchain-based data processing method in the corresponding embodiments.

[0289] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0290] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0291] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. The server's processor reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the server to perform the steps described in the embodiments of the above methods.

[0292] The foregoing has provided a detailed description of a blockchain-based data processing method, apparatus, device, and medium. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A data processing method based on blockchain, characterized in that, The method includes: Retrieve the set of transactions to be packaged from the transaction pool; Determine at least one object corresponding to the transaction to be packaged included in the transaction to be packaged set, and determine a candidate transaction set corresponding to each of the at least one object from the transaction to be packaged set; Obtain the billing type of the first object. If the billing type is the first target billing type, determine N candidate transactions from the candidate transaction set corresponding to the first object according to the transaction restriction rules corresponding to the first object. The first object is any one of the at least one objects, and N is a positive integer. The transaction restriction rules include concurrency and single transaction fee limit. The concurrency is used to indicate the maximum number of the N candidate transactions, and the single transaction fee limit is used to indicate the maximum package fee of the transaction. Package the N candidate transactions into the target block.

2. The method according to claim 1, characterized in that, The candidate transaction set corresponding to the first object includes one or both of the following: candidate transactions with billing type tags and candidate transactions without billing type tags; determining N candidate transactions from the candidate transaction set corresponding to the first object according to the transaction restriction rules corresponding to the first object includes: Obtain M candidate transactions with billing type tags from the candidate transaction set corresponding to the first object, where M is a positive integer; Based on the transaction restriction rules corresponding to the first object, N candidate transactions are determined from the M candidate transactions.

3. The method according to claim 1, characterized in that, The billing type for obtaining the first object includes: Based on the object identifier of the first object, the billing type of the first object is queried from the billing management contract by invoking the data query method of the billing management contract; Alternatively, query whether there is a candidate transaction with a billing type tag in the candidate transaction set corresponding to the first object, obtain the query result, and determine the billing type of the first object based on the query result.

4. The method according to claim 2, characterized in that, The step of determining N candidate transactions from the M candidate transactions according to the transaction restriction rules corresponding to the first object includes: Obtain the package cost of each candidate transaction among the M candidate transactions, and determine the candidate transactions whose package cost is less than or equal to the single transaction cost limit from the candidate transaction set corresponding to the first object; Based on the concurrency level, N candidate transactions are determined from the candidate transactions whose packaged cost is less than or equal to the single transaction cost limit, where the concurrency level is used to indicate the upper limit of the number of transactions.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: Obtain a transaction request from a second object, the transaction request including pending transactions; Determine the billing type corresponding to the transaction to be processed; If the billing type corresponding to the pending transaction is the first target billing type, then the pending transaction is marked with a billing type and the billing type marked pending transaction is added to the transaction pool. If the billing type corresponding to the pending transaction is the second target billing type, then the pending transaction is added to the transaction pool.

6. The method according to claim 5, characterized in that, Determining the billing type corresponding to the pending transaction includes: Based on the object identifier of the second object, the billing type of the second object is queried from the billing management contract by calling the data query method of the billing management contract, and the billing type of the second object is used as the billing type corresponding to the transaction to be processed; Alternatively, the billing type selection information of the second object input included in the transaction request can be obtained, and the billing type corresponding to the transaction to be processed can be determined according to the billing type selection information. The billing type selection information is used to indicate the first target billing type or the second target billing type.

7. The method according to claim 5, characterized in that, The billing type marking process for the pending transaction includes: Obtain the package fee of the pending transaction, and the single-transaction fee limit included in the transaction restriction rules corresponding to the second object; If the packaged cost of the pending transaction is less than or equal to the single-transaction cost limit included in the transaction restriction rules corresponding to the second object, then a billing type tag is added to the pending transaction. If the packaged cost of the pending transaction is greater than the single-transaction cost limit included in the transaction restriction rules corresponding to the second object, then no billing type mark will be added to the pending transaction.

8. The method according to any one of claims 1-4, characterized in that, The method further includes: Obtain at least one candidate subscription rule included in the first target billing type in the billing management contract, and send the at least one candidate subscription rule to the terminal device corresponding to the third object; The system receives a subscription transaction sent by the terminal device corresponding to the third object, the subscription transaction including the identification information of the target subscription rule selected by the third object from the at least one candidate subscription rule; The cost of the target subscription rule and the bundled cost of the subscription transaction shall be deducted from the account of the third party. The subscription transaction is written into the blockchain, and the subscription information of the third object is added to the billing management contract by calling the subscription information creation method of the billing management contract; Each of the at least one candidate subscription rule corresponds to a transaction restriction rule, and the transaction restriction rule corresponding to each candidate subscription rule includes one or more of concurrency, single transaction fee limit and validity period.

9. The method according to claim 8, characterized in that, The method further includes: The subscription information of the third object is broadcast to other nodes in the blockchain network so that the other nodes can reach a consensus based on the subscription information of the third object.

10. The method according to claim 8, characterized in that, The method further includes: Obtain the rule management transaction submitted by the fourth object, wherein the rule management transaction is any one of the rule creation transaction, rule modification transaction, and rule deletion transaction; When the rule management transaction creates a rule transaction, at least one candidate subscription rule is created by calling the rule creation method of the billing management contract; When the rule management transaction is a rule modification transaction, the transaction restriction rule corresponding to the created candidate subscription rule is modified by calling the rule modification method of the billing management contract; When the rule management transaction is a rule deletion transaction, the created candidate subscription rule is deleted by calling the rule deletion method of the billing management contract.

11. The method according to any one of claims 1-4, characterized in that, The method further includes: If the billing type is the second target billing type, then the target candidate transaction is determined from the candidate transaction set corresponding to the first object; After deducting the packaging fee of the target candidate transaction from the account corresponding to the first object, the target candidate transaction is packaged into the target block.

12. A data processing device based on blockchain, characterized in that, The device includes: The acquisition module is used to retrieve a set of transactions to be packaged from the transaction pool; The processing module is used to determine at least one object corresponding to the transaction to be packaged included in the transaction to be packaged set, and to determine a candidate transaction set corresponding to each of the at least one object in the transaction to be packaged set; The processing module is further configured to obtain the billing type of the first object; if the billing type is the first target billing type, then determine N candidate transactions from the candidate transaction set corresponding to the first object according to the transaction restriction rules corresponding to the first object, wherein the first object is any one of the at least one object, and N is a positive integer; the transaction restriction rules include concurrency and single transaction fee limit; the concurrency is used to indicate the maximum number of the N candidate transactions, and the single transaction fee limit is used to indicate the maximum packaged fee of the transaction. The packaging module is used to package the N candidate transactions into the target block.

13. A data processing device, characterized in that, The system includes a processor, a memory, and a network interface, which are interconnected. The memory stores a computer program, which includes program instructions. The processor is configured to invoke the program instructions to implement the blockchain-based data processing method as described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions, which, when executed by a processor, cause a computer device having the processor to implement the blockchain-based data processing method as described in any one of claims 1 to 11.

15. A computer program product, characterized in that, The computer program product includes a computer program or computer instructions, which, when executed by a processor, implement the blockchain-based data processing method as described in any one of claims 1 to 11.

Images