Method and device for managing and controlling flow of block chain transaction pool

文档序号：1738609 发布日期：2019-12-20 浏览：29次中文

阅读说明：本技术 区块链交易池流量管控方法以及装置 (Method and device for managing and controlling flow of block chain transaction pool ) 是由刘攀李茂材王宗友蓝虎周开班于 2019-09-20 设计创作，主要内容包括：本申请实施例提供了一种区块链交易池流量管控方法以及装置,该方法包括：获取区块链节点对应的用户集合,以及区块链节点对应的交易池的最大缓存容量；交易池用于缓存区块链节点接收到的交易数据,交易数据与用户集合中所包含的用户相关联；根据最大缓存容量与用户集合中的用户总数量,为用户集合中的每个用户分别配置与交易池相关联的流量阈值；当交易池中与目标用户相关联的交易数据的总流量大于或等于所属流量阈值时,停止将目标用户对应的待缓存交易数据添加至交易池；目标用户为用户集合中的任一用户。采用本申请实施例,可以提高交易池资源的利用率。(The embodiment of the application provides a method and a device for managing and controlling the flow of a block chain transaction pool, wherein the method comprises the following steps: acquiring a user set corresponding to the block chain link point and the maximum cache capacity of a transaction pool corresponding to the block chain link point; the transaction pool is used for caching transaction data received by the block chain nodes, and the transaction data is associated with users contained in the user set; respectively configuring a flow threshold value associated with a transaction pool for each user in the user set according to the maximum cache capacity and the total number of the users in the user set; when the total flow of the transaction data associated with the target user in the transaction pool is greater than or equal to the flow threshold value, stopping adding the transaction data to be cached corresponding to the target user to the transaction pool; the target user is any user in the set of users. By adopting the embodiment of the application, the utilization rate of the resources of the transaction pool can be improved.)

1. A method for managing and controlling flow of a block chain transaction pool is characterized by comprising the following steps:

acquiring a user set corresponding to a block chain link point and the maximum cache capacity of a transaction pool corresponding to the block chain link point; the transaction pool is used for caching transaction data received by the block chain node, and the transaction data is associated with users contained in the user set;

respectively configuring a traffic threshold associated with the transaction pool for each user in the user set according to the maximum cache capacity and the total number of users in the user set;

when the total flow of the transaction data associated with the target user in the transaction pool is greater than or equal to the flow threshold value, stopping adding the transaction data to be cached corresponding to the target user to the transaction pool; the target user is any user in the user set.

2. The method of claim 1, wherein the configuring the traffic threshold associated with the transaction pool for each user in the set of users according to the maximum buffer capacity and the total number of users in the set of users comprises:

determining the cache capacity to be allocated corresponding to the transaction pool according to the maximum cache capacity; the cache capacity to be allocated is less than or equal to the maximum cache capacity;

acquiring the total number of users in the user set, determining a capacity average value of each user respectively associated with the transaction pool according to the to-be-allocated cache capacity and the total number of the users, and determining the capacity average value as the flow threshold value; and the flow thresholds corresponding to the users are equal.

3. The method of claim 1, wherein the configuring the traffic threshold associated with the transaction pool for each user in the set of users according to the maximum buffer capacity and the total number of users in the set of users comprises:

acquiring a service behavior attribute parameter of each user aiming at the transaction pool, and determining a flow distribution weight corresponding to each user based on the service behavior attribute parameter;

respectively configuring a traffic threshold value associated with the transaction pool for each user according to the traffic distribution weight, the total number of users in the user set and the cache capacity to be distributed; and the proportion between the flow threshold values respectively corresponding to each user is the same as the proportion between the flow distribution weights respectively corresponding to each user.

4. The method according to claim 3, wherein the determining, based on the service behavior attribute parameter, a traffic distribution weight corresponding to each user respectively comprises:

selecting any user from the user set as a user to be processed;

if the service behavior attribute parameter corresponding to the user to be processed belongs to a first parameter range, determining the service behavior attribute parameter belonging to the first parameter range as a first attribute grade, and determining the first attribute grade as the traffic distribution weight corresponding to the user to be processed;

and if the service behavior attribute parameter corresponding to the user to be processed belongs to a second parameter range, determining the service behavior attribute parameter belonging to the second parameter range as a second attribute grade, and determining the second attribute grade as the flow distribution weight corresponding to the user to be processed.

5. The method of claim 3, further comprising:

acquiring real-time behavior attribute parameters of the target user aiming at the transaction pool based on the time frequency parameters;

if the business behavior attribute parameter corresponding to the target user is smaller than the real-time behavior attribute parameter, increasing a flow threshold value associated with the target user and the transaction pool;

and if the business behavior attribute parameter corresponding to the target user is greater than the real-time behavior attribute parameter, reducing the flow threshold value associated with the target user and the transaction pool.

6. The method according to claim 3, wherein the obtaining the business behavior attribute parameters of each user for the transaction pool comprises:

respectively counting the uploading frequency of the transaction data corresponding to each user to the transaction pool;

and determining the activity degree corresponding to each user based on the uploading frequency, and determining the activity degree as the service behavior attribute parameter.

7. The method according to claim 3, wherein the obtaining the business behavior attribute parameters of each user for the transaction pool comprises:

in the transaction pool, acquiring transaction total data corresponding to each user respectively; the transaction total data comprises invalid data and valid data; the transaction total data respectively corresponding to each user is the transaction data respectively associated with each user in the transaction pool;

respectively determining an invalid ratio between the invalid data corresponding to each user and the transaction total data;

and determining the credit degree corresponding to each user based on the invalid ratio, and determining the credit degree as the service behavior attribute parameter.

8. The method of claim 1, further comprising:

when detecting that data adding behaviors aiming at a new user exist in the transaction pool, adding the new user to the user set, and updating the total number of users in the user set;

and respectively reconfiguring the traffic threshold value associated with the transaction pool for each user in the added user set based on the updated total number of the users and the maximum cache capacity corresponding to the transaction pool.

9. The method according to claim 1, wherein the stopping of adding the transaction data to be cached corresponding to the target user to the transaction pool when the total flow rate of the transaction data associated with the target user in the transaction pool is greater than or equal to the traffic threshold comprises:

determining transaction data associated with the target user in the transaction pool as transaction total data, and counting the total flow corresponding to the transaction total data;

if the total flow is greater than or equal to a flow threshold corresponding to the target user, performing anomaly detection on the transaction total data;

when abnormal transaction data exist in the transaction total data, deleting the abnormal transaction data from the transaction total data, and adding the cached transaction data to the transaction pool;

and when abnormal transaction data do not exist in the transaction total data, stopping adding the transaction data to be cached corresponding to the target user to the transaction pool.

10. A device for controlling the traffic of a blockchain transaction pool comprises:

the acquisition module is used for acquiring a user set corresponding to a block link point and the maximum cache capacity of a transaction pool corresponding to the block link point; the transaction pool is used for caching transaction data received by the block chain node, and the transaction data is associated with users contained in the user set;

a configuration module, configured to configure a traffic threshold associated with the transaction pool for each user in the user set according to the maximum cache capacity and the total number of users in the user set;

the judging module is used for stopping adding the transaction data to be cached corresponding to the target user to the transaction pool when the total flow of the transaction data associated with the target user in the transaction pool is greater than or equal to the flow threshold value; the target user is any user in the user set.

11. A computer arrangement comprising a memory and a processor, the memory storing a computer program which, when executed by the processor, causes the processor to carry out the steps of the method according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program comprising program instructions which, when executed by a processor, perform the steps of the method according to any one of claims 1 to 9.

Technical Field

The application relates to the technical field of internet, in particular to a method and a device for managing and controlling flow of a block chain transaction pool.

Background

In the block chain network, after the block chain nodes receive the transaction data, the transaction data can be put into a transaction pool for caching, and part of the transaction data in the transaction pool is packaged to generate the blocks.

Disclosure of Invention

The embodiment of the application provides a method and a device for managing and controlling the flow of a block chain trading pool, which can improve the utilization rate of trading pool resources.

An embodiment of the present application provides a method for managing and controlling flow in a blockchain transaction pool, including:

respectively configuring a traffic threshold associated with the transaction pool for each user in the user set according to the maximum cache capacity and the total number of users in the user set;

Wherein the configuring, for each user in the user set, a traffic threshold associated with the transaction pool according to the maximum cache capacity and the total number of users in the user set comprises:

Wherein the determining, based on the service behavior attribute parameter, the traffic distribution weight corresponding to each user respectively includes:

selecting any user from the user set as a user to be processed;

Wherein the method further comprises:

acquiring real-time behavior attribute parameters of the target user aiming at the transaction pool based on the time frequency parameters;

Wherein the obtaining of the service behavior attribute parameters of each user for the transaction pool includes:

respectively counting the uploading frequency of the transaction data corresponding to each user to the transaction pool;

and determining the activity degree corresponding to each user based on the uploading frequency, and determining the activity degree as the service behavior attribute parameter.

Wherein the obtaining of the service behavior attribute parameters of each user for the transaction pool includes:

respectively determining an invalid ratio between the invalid data corresponding to each user and the transaction total data;

and determining the credit degree corresponding to each user based on the invalid ratio, and determining the credit degree as the service behavior attribute parameter.

Wherein the method further comprises:

when detecting that data adding behaviors aiming at a new user exist in the transaction pool, adding the new user to the user set, and updating the total number of users in the user set;

When the total flow of the transaction data associated with the target user in the transaction pool is greater than or equal to the flow threshold, stopping adding the transaction data to be cached corresponding to the target user to the transaction pool, including:

determining transaction data associated with the target user in the transaction pool as transaction total data, and counting the total flow corresponding to the transaction total data;

if the total flow is greater than or equal to a flow threshold corresponding to the target user, performing anomaly detection on the transaction total data;

and when abnormal transaction data do not exist in the transaction total data, stopping adding the transaction data to be cached corresponding to the target user to the transaction pool.

An aspect of the present application provides a device for managing and controlling a flow of a blockchain transaction pool, including:

Wherein the configuration module comprises:

a to-be-allocated capacity determining unit, configured to determine, according to the maximum cache capacity, a to-be-allocated cache capacity corresponding to the transaction pool; the cache capacity to be allocated is less than or equal to the maximum cache capacity;

a first traffic threshold determining unit, configured to obtain a total number of users in the user set, determine, according to the to-be-allocated cache capacity and the total number of users, a capacity average value that each user is respectively associated with the transaction pool, and determine the capacity average value as the traffic threshold; and the flow thresholds corresponding to the users are equal.

Wherein the configuration module comprises:

the to-be-allocated capacity determining unit is used for determining the to-be-allocated cache capacity corresponding to the transaction pool according to the maximum cache capacity; the cache capacity to be allocated is less than or equal to the maximum cache capacity;

the weight determining unit is used for acquiring the business behavior attribute parameters of each user aiming at the transaction pool, and determining the flow distribution weight corresponding to each user based on the business behavior attribute parameters;

a second traffic threshold determining unit, configured to configure, according to the traffic distribution weight, the total number of users in the user set, and the to-be-distributed cache capacity, a traffic threshold associated with the transaction pool for each user respectively; and the proportion between the flow threshold values respectively corresponding to each user is the same as the proportion between the flow distribution weights respectively corresponding to each user.

Wherein the weight determination unit includes:

the selection subunit is used for selecting any user from the user set as a user to be processed;

a first comparing subunit, configured to determine, if the service behavior attribute parameter corresponding to the user to be processed belongs to a first parameter range, the service behavior attribute parameter belonging to the first parameter range as a first attribute level, and determine the first attribute level as a traffic distribution weight corresponding to the user to be processed;

and the second comparing subunit is configured to, if the service behavior attribute parameter corresponding to the user to be processed belongs to a second parameter range, determine the service behavior attribute parameter belonging to the second parameter range as a second attribute level, and determine the second attribute level as a traffic distribution weight corresponding to the user to be processed.

Wherein the apparatus further comprises:

the parameter acquisition module is used for acquiring real-time behavior attribute parameters of the target user aiming at the transaction pool based on the time frequency parameters;

a traffic increasing module, configured to increase a traffic threshold associated with the transaction pool by the target user if the service behavior attribute parameter corresponding to the target user is smaller than the real-time behavior attribute parameter;

and the traffic reduction module is used for reducing the traffic threshold value associated with the target user and the transaction pool if the business behavior attribute parameter corresponding to the target user is greater than the real-time behavior attribute parameter.

Wherein the weight determination unit includes:

the frequency counting subunit is used for respectively counting the uploading frequency of the transaction data corresponding to each user to the transaction pool;

and the activity determining subunit is configured to determine, based on the uploading frequency, an activity corresponding to each user, and determine the activity as the service behavior attribute parameter.

Wherein the weight determination unit includes:

the total data acquisition subunit is configured to acquire, in the transaction pool, transaction total data corresponding to each user; the transaction total data comprises invalid data and valid data; the transaction total data respectively corresponding to each user is the transaction data respectively associated with each user in the transaction pool;

a ratio determining subunit, configured to determine an invalid ratio between the invalid data corresponding to each user and the transaction total data respectively;

and the credit determining subunit is configured to determine the respective credits corresponding to each user based on the invalid ratio, and determine the credits as the service behavior attribute parameters.

Wherein the apparatus further comprises:

the user adding module is used for adding a new user to the user set and updating the total number of the users in the user set when detecting that data adding behaviors aiming at the new user exist in the transaction pool;

and the reconfiguration module is used for respectively reconfiguring the flow threshold value associated with the transaction pool for each user in the added user set based on the updated total number of the users and the maximum cache capacity corresponding to the transaction pool.

Wherein, the judging module comprises:

the total flow counting unit is used for determining transaction data associated with the target user in the transaction pool as transaction total data and counting the total flow corresponding to the transaction total data;

the abnormality detection unit is used for performing abnormality detection on the transaction total data if the total flow is greater than or equal to a flow threshold corresponding to the target user;

the deleting unit is used for deleting abnormal transaction data from the transaction total data and adding the cache transaction data to the transaction pool when the abnormal transaction data exist in the transaction total data;

and the adding stopping unit is used for stopping adding the transaction data to be cached corresponding to the target user to the transaction pool when abnormal transaction data does not exist in the transaction total data.

An aspect of the embodiments of the present application provides a computer device, including a memory and a processor, where the memory stores a computer program, and the computer program, when executed by the processor, causes the processor to execute the steps of the method in an aspect of the embodiments of the present application.

An aspect of embodiments of the present application provides a computer-readable storage medium storing a computer program comprising program instructions that, when executed by a processor, perform the steps of the method as described in an aspect of embodiments of the present application.

According to the embodiment of the application, the user set corresponding to the block chain link point and the maximum cache capacity of the transaction pool corresponding to the block chain link point are obtained, then based on the maximum cache capacity of the transaction pool and the total number of users in the user set, a traffic threshold value associated with the transaction pool is configured for each user in the user set, and when the total traffic of transaction data associated with a target user in the transaction pool is greater than the traffic threshold value corresponding to the target user, the transaction data to be cached corresponding to the target user is stopped being added to the transaction pool. Therefore, in the transaction pool of the block chain link points, different flow thresholds are set for different users, so that the block chain nodes can be prevented from being attacked and trapped by the same user, and the utilization rate of the transaction pool resources can be improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

Fig. 1 is a schematic diagram of a data processing scenario of a blockchain transaction pool according to an embodiment of the present disclosure;

fig. 2 is a schematic flow chart of a method for managing flow of a blockchain transaction pool according to an embodiment of the present disclosure;

FIG. 3 is a schematic diagram of a transaction data signature provided by an embodiment of the present application;

fig. 4 is a schematic flow chart of another method for managing flow of a blockchain transaction pool according to an embodiment of the present disclosure;

fig. 5 is a schematic flow chart of another method for managing flow of a blockchain transaction pool according to an embodiment of the present disclosure;

FIG. 6 is a schematic diagram of training an initial generative model according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a device for managing and controlling flow of a blockchain transaction pool according to an embodiment of the present disclosure;

fig. 8 is a schematic structural diagram of a computer device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission (P2P transmission), a consensus mechanism, an encryption algorithm and the like, and is essentially a decentralized database; the blockchain can be composed of a plurality of serial transaction records (also called blocks) which are connected in series by cryptography and protect the contents, and the distributed accounts connected in series by the blockchain can effectively record the transaction by multiple parties and can permanently check the transaction (can not be tampered). The consensus mechanism is a mathematical algorithm for establishing trust and obtaining rights and interests among different nodes in the block chain network; in other words, the consensus mechanism is a mathematical algorithm commonly recognized by network nodes of the blockchain.

The transaction pool (txpool) is used for temporarily storing transaction records that have not been added to the block, and may also be referred to as a memory pool. Each node in the block chain network has a corresponding transaction pool, and when a new transaction is generated, the generated new transaction can be sent to an adjacent node in the block chain network, so that the transaction can be propagated in the block chain network. After the adjacent node receives the new transaction, the new transaction needs to be verified, the new transaction passing the verification is added into the transaction pool corresponding to the adjacent node, meanwhile, the adjacent node can also broadcast the new transaction into the blockchain network, other nodes in the blockchain network also need to verify the new transaction, and the new transaction is also added into the respective transaction pool after the new transaction is confirmed to be correct. In other words, after receiving the transaction data, the node in the blockchain network does not immediately pack the received transaction data into blocks, but temporarily stores the transaction data in the transaction pool, and further extracts a part of the data from the transaction pool according to the data selection rule (e.g., according to the sequence of the commission fees) and packs the data into blocks, and after the blocks are identified, the blocks are added into the blockchain to complete the uplink process of the transaction.

Fig. 1 is a schematic view of a data processing scenario of a blockchain transaction pool according to an embodiment of the present disclosure. The data processing process of the blockchain transaction pool can be applied to different application scenarios, such as a transaction scenario of game resources, a transaction scenario of electronic tickets, a transaction scenario of digital currency, an uplink scenario of user house purchasing data, and the like. For convenience of description, in the embodiment of the present application, a transaction scenario of a game resource is taken as an example, and a data processing process of a transaction pool is specifically described. As shown in fig. 1, the server 10a may be represented as any blockchain node in the blockchain network, and the terminal device 10b, the terminal device 10c, and the terminal device 10d may be represented as user terminals that upload transaction data, that is, the terminal device 10b, the terminal device 10c, and the terminal device 10d may each transmit the generated transaction data to the blockchain node in the blockchain network, that is, the server 10 a. If user 1 with account number bbb123 wants to purchase coins from user 2 with account number aaa123, user 1 can achieve the transaction intention with user 2. The user 2 may create first transaction data through the terminal device 10b, and upload the first transaction data to the blockchain network, that is, transmit the first transaction data to the server 10a, where the first transaction data may include an initiator (i.e., the user 2 corresponding to the terminal device 10b that created the first transaction data, such as an account number of the user 2), a receiver (i.e., the user 1 that purchased the gaming chips, such as an account number of the user 1), and transaction content (e.g., 10 gaming chips are transferred from an account of the initiator to an account of the receiver), and the first transaction data is used to instruct the blockchain network to transfer 10 gaming chips from an account of the user 2 to an account of the user 1. Similarly, when the user 3 with the account number bbb456 wants to purchase coins from the user 4 with the account number aaa456, after both parties reach the transaction intention, second transaction data may be created by the terminal device 10c and uploaded to the server 10a to instruct the blockchain network to transfer 100 coins from the account of the user 4 to the account of the user 3, where the second transaction data may also include the initiator, the receiver and the transaction content; when the user 5 with account number bbb789 wants to purchase coins from the user 6 with account number aaa789, a third transaction data may be created by the terminal device 10d and uploaded to the server 10a after both parties reach the transaction intent, so as to instruct the blockchain network to transfer 5 coins from the account of the user 6 to the account of the user 5. It is understood that the first transaction data, the second transaction data and the third transaction data may be uploaded to the server 10a at the same time or may be uploaded to the server 10a at different times, which is associated with the time of creation of each transaction data. For example, if the first transaction data, the second transaction data, and the third transaction data are created at the same time, they may be uploaded to the server 10a at the same time by the corresponding terminal devices.

The server 10a may verify the transaction data after receiving the transaction data uploaded by the terminal device, for example, after receiving the first transaction data, the server 10a needs to verify the first transaction data, and the purpose of the verification is mainly to determine whether the first transaction data is maliciously tampered in the uploading process, for example, whether the first transaction data received by the server 10a is the first transaction data actually uploaded by the terminal device 10b, or whether both transaction parties in the received first transaction data are both transaction parties in the first transaction data actually uploaded by the terminal device 10b, or the like. After the first transaction data passes the verification, the server 10a may perform flow statistics on the first transaction data, so that a flow statistic value of the first transaction data is 2 megabits, and further, an available flow of the user 2 corresponding to the account aaa123 (i.e., an initiator in the first transaction data) in the transaction pool 10a is 10 megabits from the transaction pool 10e corresponding to the server 10a, because the available flow is greater than the flow statistic value of the first transaction data, the first transaction data may be added to the transaction pool 10e, so that an n +1 th transaction data record in the transaction pool 10e is obtained (before the first transaction data is received, n records of the transaction data are already stored in the transaction pool 10 e), and the available flow of the user 2 corresponding to the account aaa123 is updated in the transaction pool 10 e. Similarly, the server 10a may perform flow statistics on the second transaction data that passes the verification, where the obtained flow statistics is 3 megabits, and the available flow of the account aaa456 corresponding to the user 4 obtained from the transaction pool 10e is 1 megabits, and because the available flow is smaller than the flow statistics of the second transaction data, the second transaction data is determined to be invalid data and is not added to the transaction pool 10 e; the server 10a may perform flow statistics on the third transaction data that passes the verification, so that an obtained flow statistic value is 2.5 million, an available flow of the account aaa789 corresponding to the user 6 obtained from the transaction pool 10e is 20 million, and because the available flow is greater than the flow statistic value of the third transaction data, the third transaction data may be added to the transaction pool 10e, so that an n +2 th transaction data record in the transaction pool 10e is obtained (the time when the default server 10a receives the first transaction data is earlier than the time when the second transaction data is received), and the available flow of the account aaa789 corresponding to the user 6 is updated in the transaction pool 10 e.

All users corresponding to the server 10a can be obtained based on the transaction data history record stored in the transaction pool 10e, and then a traffic threshold value associated with the transaction pool 10e can be allocated to each user, when the total amount of transaction data of a certain user in the transaction pool 10e exceeds the traffic threshold value allocated by the user, new transaction data corresponding to the user is stopped being added to the transaction pool 10e, so that the transaction pool 10e can be prevented from being viciously attacked by the certain user. When new transaction data is added to the transaction pool 10e or data in the transaction pool is packed into blocks, the traffic cache profile of the user in the transaction pool 10e needs to be updated in real time. The flow threshold corresponding to each user may be the same or different, and is not limited herein.

Fig. 2 is a schematic flow chart of a method for managing traffic of a blockchain transaction pool according to an embodiment of the present disclosure. As shown in fig. 2, the method for controlling flow of blockchain transaction pool may include:

step S101, acquiring a user set corresponding to a block chain link point and the maximum cache capacity of a transaction pool corresponding to the block chain link point; the transaction pool is used for caching transaction data received by the block chain node, and the transaction data is associated with users contained in the user set;

specifically, the node server (corresponding to the server 10a in the embodiment corresponding to fig. 1) may obtain a user set corresponding to a block link point, and obtain a maximum cache capacity of the transaction pool corresponding to the block link point. It should be understood that in the blockchain network, each blockchain node may receive transaction data from different users (for the blockchain node, different users may be determined based on user account numbers or user network addresses, that is, one user corresponds to the same account number or one user corresponds to the same network address), and temporarily store the received transaction data in a transaction pool, that is, the transaction pool corresponding to each blockchain node is used for caching the transaction data received by the blockchain node, and the blockchain network platform sets a maximum cache capacity for the transaction pool. The transaction data stored in the transaction pool may include transaction data created by the block link node and transaction data obtained by other block link nodes through broadcasting, an initiating user in each transaction data record is obtained through the transaction data records stored in the transaction pool, the transaction initiating user is added to the user set, and then the user set corresponding to the block link node is obtained. Optionally, the uploading clients corresponding to each piece of transaction data respectively can be obtained according to the transaction data records stored in the transaction pool, and the user set is determined according to the uploading clients, that is, the transaction data uploaded by the same client is understood as the transaction data of the same user.

Step S102, respectively configuring a flow threshold value associated with the transaction pool for each user in the user set according to the maximum cache capacity and the total number of the users in the user set;

specifically, the node server may configure a traffic threshold associated with the transaction pool for each user in the user set according to the maximum cache capacity of the transaction pool and the total number of users in the user set. The user traffic threshold configuration criteria in the transaction pool may include: determining the cache capacity to be allocated corresponding to the transaction pool according to the maximum cache capacity corresponding to the transaction pool; the cache capacity to be allocated is less than or equal to the maximum cache capacity; acquiring the total number of users in a user set, determining a capacity average value of each user respectively associated with a transaction pool according to the to-be-allocated cache capacity and the total number of the users, and determining the capacity average value as a flow threshold; the flow thresholds corresponding to each user are all equal. In other words, the maximum cache capacity corresponding to the transaction pool is divided into two parts, one part is determined as the cache capacity to be allocated, and the other part is used as the capacity to be used; and dividing the cache capacity to be allocated by the total number of users in the user set to obtain a capacity average value corresponding to each user, and determining the capacity average value as a flow threshold value corresponding to each user respectively. It should be understood that when transaction data of a new user is added in the transaction pool, the user may be added to the user set, the total number of users corresponding to the user set is updated, the cache capacity to be allocated is divided by the updated total number of users, and the obtained average value of the capacities is used as the traffic threshold value corresponding to each user, that is, when the total number of users changes, the traffic threshold value corresponding to each user changes; or, the same traffic threshold as the allocated traffic user (i.e., the remaining users except the new user in the user set) is obtained from the capacity to be used as the traffic threshold of the new user, that is, when the new user is added to the user set, the traffic threshold corresponding to each user does not change, and the traffic threshold is allocated to the new user from the capacity to be used.

For example, if the maximum cache capacity of the transaction pool corresponding to a certain block link point is 100 megabytes and the total number of users in the user set corresponding to the block link point is 7, the node server may divide the maximum cache capacity of the transaction pool into two parts, where the first part is 70% of the maximum cache capacity, that is, 70 megabytes, and the second part is 30% of the maximum cache capacity, that is, 30 megabytes; the first part may be determined as the to-be-allocated cache capacity, the second part may be determined as the to-be-used capacity, and the to-be-allocated cache capacity is divided by the total number of the users, so that the traffic threshold corresponding to each user is 10 megabytes. When the transaction data of a new user is added into the transaction pool, the total number of the users is updated from 7 to 8, and then 70 million of the buffer capacity to be allocated can be divided by the total data of the users 8, and 8.6 million can be used as the flow threshold value after each user is updated. Optionally, when transaction data of a new user is added to the transaction pool, 10 megaflows can be allocated from the capacity to be used as the flow threshold corresponding to the new user.

Step S103, when the total flow of the transaction data associated with the target user in the transaction pool is greater than or equal to the flow threshold value, stopping adding the transaction data to be cached corresponding to the target user to the transaction pool; the target user is any user in the user set.

Specifically, when the total traffic of the transaction data associated with the target user stored in the transaction pool is greater than or equal to the traffic threshold of the target user, the transaction data to be cached corresponding to the target user (i.e., the transaction data that has not been added to the transaction pool by the node server after verification) is stopped being added to the transaction pool, where the target user may refer to any user in the user set. When the node server receives transaction data to be cached of a target user, a signature of the received transaction data to be cached needs to be checked, and a specific process of the signature checking can be shown in fig. 3, which is a signature checking schematic diagram of the transaction data provided by the embodiment of the application. As shown in fig. 3, after receiving transaction data 20a to be cached uploaded by a client (i.e., transaction data to be cached corresponding to a target user), a node server 10a may obtain a digital signature 20b carried by the transaction data 20a to be cached, and decrypt the digital signature 20b by using a public key 20c corresponding to the client that uploads the transaction data 20a to be cached, so as to obtain a hash value 1, and then the node server 10a may perform hash operation on the transaction data 20a to be cached by using a hash algorithm 20d (the hash algorithm 20d is a hash algorithm used by the client to generate the digital signature), so as to obtain a hash value 2 corresponding to the transaction data 20a to be cached, and if the hash value 1 is equal to the hash value 2, it indicates that the transaction data 20a to be cached is not tampered in the uploading process, and the signature passes the verification; if the hash value 1 is not equal to the hash value 2, it indicates that there may be tampering with the actual transaction data in the transaction data to be cached 20a in the uploading process, and the verification fails, and the transaction data to be cached 20a is deleted. It should be understood that, before the client uploads the transaction data 20a to be cached, the node server 10a is already notified of the public key 20c and the hash algorithm 20d used for generating the digital signature 20b, and if the transaction data 20a to be cached is tampered during the uploading process and the digital signature 20b received by the node server 10a is not the digital signature originally generated by the client, the node server 10a cannot solve the problem when decrypting the digital signature 20b by using the public key 20c corresponding to the client. The hashing algorithm 20d may include, but is not limited to, SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512, among others.

After the transaction data to be cached passes the signature verification, the node server can determine the transaction data associated with the target user in the transaction pool as transaction total data, and count total flow corresponding to the transaction total data; if the total flow is greater than or equal to a flow threshold corresponding to the target user, that is, the available flow corresponding to the target user in the transaction pool (that is, the difference between the flow threshold corresponding to the target user and the total flow) is less than the flow of the transaction data to be cached, performing anomaly detection on the transaction total data; when abnormal transaction data (the abnormal transaction data can comprise illegal transaction data, uplink transaction data and the like) exist in the transaction total data, deleting the abnormal transaction data from the transaction total data, and only when the available flow of a target user after deleting the abnormal transaction data is larger than the flow corresponding to the transaction data to be cached, adding the cached transaction data into a transaction pool; and when abnormal transaction data does not exist in the transaction total data or the available flow corresponding to the target user is still smaller than the flow corresponding to the transaction data to be cached after the transaction data is deleted, stopping adding the transaction data to be cached corresponding to the target user into the transaction pool.

Fig. 4 is a schematic flow chart of another method for managing flow of a blockchain transaction pool according to an embodiment of the present disclosure. In the embodiment corresponding to fig. 2, it is described that the same traffic threshold is allocated to each user according to the cache capacity to be allocated, and in the embodiment of the present application, different traffic thresholds may be set for each user respectively based on the historical transaction data record of each user in the transaction pool. As shown in fig. 4, the method for controlling flow of blockchain transaction pool may include:

step S201, acquiring a user set corresponding to a block chain link point and the maximum cache capacity of a transaction pool corresponding to the block chain link point; the transaction pool is used for caching transaction data received by the block chain node, and the transaction data is associated with users contained in the user set;

step S202, determining the cache capacity to be allocated corresponding to the transaction pool according to the maximum cache capacity; the cache capacity to be allocated is less than or equal to the maximum cache capacity;

for a specific implementation manner of steps S201 to S202, reference may be made to the description of steps S101 to S102 in the embodiment corresponding to fig. 2, and details are not repeated here.

Step S203, acquiring the service behavior attribute parameters of each user aiming at the transaction pool, and determining the flow distribution weight corresponding to each user respectively based on the service behavior attribute parameters;

specifically, the node server may obtain a service behavior attribute parameter of each user for the transaction pool according to a history of transaction data uploaded by each user in the transaction pool, and determine a traffic distribution weight for each user based on the service behavior attribute parameter, where the service behavior attribute parameter may include liveness and/or credibility.

When the business behavior attribute parameters are liveness, the uploading frequency of the transaction data corresponding to each user uploaded to the transaction pool can be respectively counted, the liveness corresponding to each user is determined according to the uploading frequency, the more times that the client side corresponding to the user uploads the transaction data are within the same counting time period, the greater the uploading frequency corresponding to the user is, the greater the liveness of the user is, and further the traffic distribution weight corresponding to the user is increased. The determination process of the traffic assignment weight may be: the node server can select any user from the user set as a user to be processed; if the activity degree corresponding to the user to be processed belongs to the first parameter range, determining the activity degree belonging to the first parameter range as a first attribute grade, and determining the first attribute grade as the flow distribution weight corresponding to the user to be processed; and if the activity degree corresponding to the user to be processed belongs to the second parameter range, determining the activity degree belonging to the second parameter range as a second attribute grade, and determining the second attribute grade as the flow distribution weight corresponding to the user to be processed. It should be understood that the node server may divide the activity corresponding to the user into a plurality of parameter ranges, each parameter range corresponding to a level, and the level may be determined to assign a weight to the traffic of the user.

For example, if the activity corresponding to the user is divided into three parameter ranges, which are the first parameter range 0 to 0.4, the second parameter range 0.4 to 0.7, and the third parameter range 0.7 to 1.0. Selecting any user from a user set as a user to be processed, wherein if the activity degree corresponding to the user to be processed is 0.22, the activity degree corresponding to the user to be processed belongs to a first parameter range, namely the activity degree corresponding to the user to be processed is a first level, and a value 1 can be used as a traffic distribution weight corresponding to the user to be processed; if the activity degree corresponding to the user to be processed is 0.50, the activity degree corresponding to the user to be processed belongs to a second parameter range, that is, the activity degree corresponding to the user to be processed is a second level, and a value 2 can be used as the traffic distribution weight corresponding to the user to be processed; if the activity degree corresponding to the user to be processed is 0.85, the activity degree corresponding to the user to be processed belongs to a third parameter range, that is, the activity degree corresponding to the user to be processed is a third level, and a value of 3 may be used as the traffic distribution weight corresponding to the user to be processed. In other words, users with liveness belonging to the same parameter range have the same traffic assignment weight. Of course, the node server may also set a traffic distribution weight for each user according to the activity degree corresponding to each user, that is, only users with the same activity degree have the same traffic distribution weight. The division of the activity level (including how many levels the activity level is divided into, and the parameter range corresponding to each level, etc.) may be set according to the actual application, and is not limited herein.

The node server may obtain a real-time activity of each user in the user set for the transaction pool according to the time frequency parameter, that is, the activity of all users is counted every certain period of time (e.g., every 3 hours), and may dynamically adjust the traffic distribution weight of the user according to the obtained real-time activity, and if the activity of the user 1 increases from the first parameter range to the second parameter range, the traffic distribution weight corresponding to the user 1 may be increased; and if the activity of the user 2 is reduced from the third parameter range to the second parameter range, the traffic distribution weight corresponding to the user 2 can be reduced.

Please refer to fig. 5, which is a schematic diagram of a method for allocating traffic of a blockchain transaction pool according to an embodiment of the present disclosure. Taking the service behavior attribute parameter as the activity, as an example, a traffic threshold is allocated to each user in the user set, as shown in fig. 5, the node server 10a obtains 112 times of uploading transaction data of the user 1 through statistics of n transaction data records stored in the transaction pool for 5 hours, and finally obtains the activity corresponding to the user 1 as 0.85 through calculation; counting to obtain 90 times of uploading transaction data of the user 2, and finally calculating to obtain the activity degree of 0.69 corresponding to the user 2; counting is always carried out to obtain the activity degree corresponding to each user in the user set (the total number of the users in the user set is m, namely the activity degree corresponding to the user m is obtained through calculation), and if the user does not upload transaction data in about 5 hours, the flow threshold of the user is set to be the lowest flow threshold standard (such as 5 million). Based on the activity corresponding to each user, the buffer capacity to be allocated of the transaction pool, and the total number of users, a traffic threshold of 30 mb may be configured for user 1, a traffic threshold of 25 mb may be configured for user 2, and so on.

Optionally, when the service behavior attribute parameter is credit, total transaction data corresponding to each user may be obtained in the transaction pool; the transaction total data can include invalid data and invalid data, and the transaction total data respectively corresponding to each user is the transaction data respectively associated with each user in the transaction pool; respectively determining an invalid ratio between invalid data corresponding to each user and transaction total data; and determining the credit degree corresponding to each user respectively based on the invalid ratio. The valid data is data which can be used for indicating the blockchain network to execute the transaction between the initiator and the receiver in the transaction pool; invalid data refers to data in the transaction pool that cannot indicate the blockchain network to complete a transaction between the initiator and the receiver, or data that has been written in the blockchain in a packed manner, for example, some transaction data is: if 10 coins are transferred from the account of USER-1 to the account of USER-2, but less than 10 coins are in the balance of USER-1, the transaction data may be determined to be invalid data.

It can be understood that the larger the invalid ratio corresponding to the user is, the smaller the credit degree of the user is, and the traffic distribution weight corresponding to the user also becomes smaller. The determination process of the traffic assignment weight may be: the node server can select any user from the user set as a user to be processed; if the credit degree corresponding to the user to be processed belongs to the first parameter range, determining the credit degree belonging to the first parameter range as a first attribute grade, and determining the first attribute grade as the flow distribution weight corresponding to the user to be processed; and if the credit corresponding to the user to be processed belongs to the second parameter range, determining the credit belonging to the second parameter range as a second attribute grade, and determining the second attribute grade as the flow distribution weight corresponding to the user to be processed. It should be understood that the node server may divide the credit corresponding to the user into a plurality of parameter ranges, each parameter range corresponding to a grade, and the grade may be determined to assign a weight to the traffic of the user.

For example, if the credit corresponding to the user is divided into three parameter ranges, the first parameter range is 0.7 to 1.0, the second parameter range is 0.4 to 0.7, and the third parameter range is 0 to 0.4. Selecting any user from a user set as a user to be processed, wherein if the credit degree corresponding to the user to be processed is 0.75, the credit degree corresponding to the user to be processed belongs to a first parameter range, that is, the credit degree corresponding to the user to be processed is a first grade, and a value 1 can be used as a traffic distribution weight corresponding to the user to be processed; if the credit degree corresponding to the user to be processed is 0.50, the credit degree corresponding to the user to be processed belongs to a second parameter range, that is, the credit degree corresponding to the user to be processed is a second level, and a value 2 can be used as a traffic distribution weight corresponding to the user to be processed; if the credit corresponding to the user to be processed is 0.1, the credit corresponding to the user to be processed belongs to a third parameter range, that is, the credit corresponding to the user to be processed is a third level, and a value 3 may be used as the traffic distribution weight corresponding to the user to be processed. In other words, users whose credits belong to the same parameter range have the same traffic assignment weight. Of course, the node server may also set a traffic distribution weight for each user according to the credit degree corresponding to each user, that is, only users with the same credit degree have the same traffic distribution weight. The credit rating (including how many ratings the credit rating is divided into, and the parameter range corresponding to each rating) may be set according to the actual application, and is not limited herein.

The node server may count the real-time credit of each user in the user set for the transaction pool according to the time frequency parameter, that is, the credit of all users is counted once every period of time (for example, every 3 hours), and may dynamically adjust the traffic distribution weight of the user according to the obtained real-time credit, and if the credit of the user 1 is decreased from the first parameter range to the second parameter range, the traffic distribution weight corresponding to the user 1 may be increased; and if the credit degree of the user 2 is increased from the third parameter range to the second parameter range, the traffic distribution weight corresponding to the user 2 can be reduced.

Please refer to fig. 6, which is a schematic diagram of another method for allocating traffic of a blockchain transaction pool according to an embodiment of the present disclosure. Taking the service behavior attribute parameter as the credit, allocating a flow threshold to each user in the user set, as shown in fig. 6, the node server 10a obtains 120 times of uploading transaction data of the user 1 by performing statistics on n transaction data records stored in the transaction pool for 5 hours, wherein the number of invalid data is 18, and finally, the credit corresponding to the user 1 is obtained by calculation and is 0.85; counting to obtain 90 times of uploading transaction data of the user 2, wherein 6 times of invalid data, and finally calculating to obtain that the credit degree corresponding to the user 2 is 0.93; until the credit degrees corresponding to each user in the user set are obtained through statistics (the total number of the users in the user set is m, namely the credit degrees corresponding to the user m are obtained through calculation), if the user does not upload transaction data in about 5 hours, one capacity value can be randomly selected as the traffic threshold of the user, or the average value of the traffic thresholds of the rest users is determined as the traffic threshold of the user, and the like. Based on the credit corresponding to each user, the buffer capacity to be allocated of the transaction pool, and the total number of users, a traffic threshold of 30 mb may be configured for user 1, a traffic threshold of 40 mb may be configured for user 2, and so on.

Optionally, when the service behavior attribute parameter is liveness and credit, not only the uploading frequency of the transaction data corresponding to each user uploaded to the transaction pool needs to be respectively counted to obtain the liveness corresponding to each user, but also the invalid ratio between the invalid data corresponding to each user and the transaction total data needs to be respectively counted to obtain the credit corresponding to each user, and the traffic distribution weight corresponding to each user is determined based on the liveness and the credit. The process of determining the traffic distribution weight is similar to the above description process, and only when the service behavior attribute parameters are activity and credit, the corresponding traffic distribution weight is configured only when both the activity and the credit of the user satisfy respective parameter ranges. Similarly, the real-time activity and the real-time credit of each user in the user set for the transaction pool can be counted according to the time frequency parameters, and the traffic distribution weight of the user is dynamically adjusted according to the real-time activity and the real-time credit. When the real-time liveness is increased and the real-time credit is increased, the corresponding flow distribution weight of the user can be improved; when the real-time liveness is reduced and the real-time credit is reduced, the corresponding flow distribution weight of the user can be reduced; when only one of the real-time liveness and the real-time credit is increased or decreased, the traffic distribution weight of the user is not changed.

Step S204, respectively configuring a traffic threshold value associated with the transaction pool for each user according to the traffic distribution weight, the total number of users in the user set and the cache capacity to be distributed; the proportion between the flow threshold values respectively corresponding to each user is the same as the proportion between the flow distribution weights respectively corresponding to each user;

specifically, the node server may configure traffic thresholds associated with the transaction pool for each user according to the traffic distribution weight, the total number of users in the user set, and the to-be-distributed cache capacity corresponding to the transaction pool, where a sum of the traffic thresholds corresponding to all users in the user set is less than or equal to the to-be-distributed cache capacity in the transaction pool, and a ratio between the traffic thresholds corresponding to each user is the same as a ratio between the traffic distribution weights corresponding to each user. For example, the to-be-allocated cache capacity corresponding to the transaction pool is 60 megabytes, the total number of users in the user set is 3, and the total number is a user a, a user B, and a user B; the traffic distribution weight corresponding to user a is 1, the traffic distribution weight corresponding to user B is 2, and the traffic distribution weight corresponding to user C is 3. The node server may determine that the traffic threshold corresponding to the user a is 10 megabits, the traffic threshold corresponding to the user B is 20 megabits, and the traffic threshold corresponding to the user C is 30 megabits, based on traffic distribution weights, to-be-distributed cache capacities of 60 megabits, and the total number of users 3 respectively corresponding to the user a, the user B, and the user B.

When the flow distribution weight is adjusted based on the real-time liveness and/or the real-time credit and the flow threshold corresponding to the user is adjusted according to the flow distribution weight, the to-be-distributed cache capacity of the transaction pool is used as a reference, if the sum of the flow thresholds of all the users is smaller than the to-be-distributed cache capacity, the flow threshold of the user can be directly allowed to be improved, but the maximum capacity is used as a reference for the improved upper limit; if the sum of the traffic thresholds of all users is equal to the to-be-allocated cache capacity, the traffic thresholds of other users are allowed to be increased only when the traffic threshold of a user is reduced, and the increased upper limit is also referred to the maximum capacity. For example, when the activity of some users is reduced, the traffic of those users with high activity can be increased (that is, the traffic threshold of the users with low activity is reduced, and the traffic threshold of the users with high activity is increased at the same time), so as to achieve the effect of fully utilizing the resources.

Optionally, the node server may further detect a hardware condition and a network condition of the node server, and if the hardware condition and the network condition are relatively good, the maximum cache capacity of the transaction pool may be increased, and meanwhile, the cache capacity to be allocated corresponding to the transaction pool is also correspondingly increased based on the increased maximum cache capacity, so that a traffic threshold of the user may be increased; if the hardware condition and the network condition are poor, the maximum cache capacity can be reduced, and meanwhile, the cache capacity to be allocated corresponding to the transaction pool is correspondingly reduced based on the reduced maximum cache capacity, so that the flow threshold of the user can be reduced.

Step S205, when the total flow of the transaction data associated with the target user in the transaction pool is greater than or equal to the flow threshold, stopping adding the transaction data to be cached corresponding to the target user to the transaction pool; the target user is any user in the user set.

The specific implementation manner of step S205 may refer to the description of step S103 in the embodiment corresponding to fig. 2, and is not described herein again.

Fig. 7 is a schematic structural diagram of a device for controlling flow of a blockchain transaction pool according to an embodiment of the present disclosure. As shown in fig. 7, the blockchain transaction pool traffic management apparatus 1 may include: the device comprises an acquisition module 11, a configuration module 12 and a judgment module 13;

an obtaining module 11, configured to obtain a user set corresponding to a block link point and a maximum cache capacity of a transaction pool corresponding to the block link point; the transaction pool is used for caching transaction data received by the block chain node, and the transaction data is associated with users contained in the user set;

a configuration module 12, configured to configure a traffic threshold associated with the transaction pool for each user in the user set according to the maximum cache capacity and the total number of users in the user set;

the judging module 13 is configured to stop adding the transaction data to be cached corresponding to the target user to the transaction pool when a total flow of the transaction data associated with the target user in the transaction pool is greater than or equal to the flow threshold to which the target user belongs; the target user is any user in the user set.

The specific functional implementation manners of the obtaining module 11, the configuring module 12, and the determining module 13 may refer to steps S101 to S103 in the embodiment corresponding to fig. 2, which is not described herein again.

Referring to fig. 7, the blockchain transaction pool traffic management apparatus 1 may further include: a parameter obtaining module 14, a flow increasing module 15, a flow decreasing module 16, a user adding module 17 and a reconfiguration module 18;

a parameter obtaining module 14, configured to obtain, based on the time-frequency parameter, a real-time behavior attribute parameter of the target user for the transaction pool;

a traffic increasing module 15, configured to increase a traffic threshold associated with the transaction pool by the target user if the service behavior attribute parameter corresponding to the target user is smaller than the real-time behavior attribute parameter;

a traffic reduction module 16, configured to reduce a traffic threshold associated with the transaction pool by the target user if the service behavior attribute parameter corresponding to the target user is greater than the real-time behavior attribute parameter;

a user adding module 17, configured to, when it is detected that data adding behavior for a new user exists in the transaction pool, add the new user to the user set, and update the total number of users in the user set;

a reconfiguration module 18, configured to reconfigure, based on the updated total number of users and the maximum cache capacity corresponding to the transaction pool, a traffic threshold associated with the transaction pool for each user in the added user set respectively.

For specific functional implementation manners of the parameter obtaining module 14, the traffic increasing module 15, the traffic decreasing module 16, the user adding module 17, and the reconfiguring module 18, reference may be made to step S204 in the embodiment corresponding to fig. 4, which is not described herein again. The flow increasing module 15 and the flow decreasing module 16 independently perform corresponding operations, that is, when the flow increasing module 15 performs the corresponding operations, the flow decreasing module 16 suspends performing the operations; the flow increasing module 15 suspends the execution of the operation while the flow decreasing module 16 is executing the corresponding operation.

Referring also to fig. 7, the configuration module 12 may include: a capacity to be allocated determining unit 121, a first traffic threshold determining unit 122, a weight determining unit 123, a second traffic threshold determining unit 124;

a to-be-allocated capacity determining unit 121, configured to determine, according to the maximum cache capacity, a to-be-allocated cache capacity corresponding to the transaction pool; the cache capacity to be allocated is less than or equal to the maximum cache capacity;

a first traffic threshold determining unit 122, configured to obtain a total number of users in the user set, determine, according to the to-be-allocated cache capacity and the total number of users, a capacity average value that each user is respectively associated with the transaction pool, and determine the capacity average value as the traffic threshold; the flow threshold values respectively corresponding to each user are equal;

a weight determining unit 123, configured to obtain a service behavior attribute parameter of each user for the transaction pool, and determine, based on the service behavior attribute parameter, a traffic distribution weight corresponding to each user;

a second traffic threshold determining unit 124, configured to configure, according to the traffic distribution weight, the total number of users in the user set, and the to-be-distributed cache capacity, a traffic threshold associated with the transaction pool for each user respectively; and the proportion between the flow threshold values respectively corresponding to each user is the same as the proportion between the flow distribution weights respectively corresponding to each user.

The specific functional implementation manners of the to-be-allocated capacity determining unit 121 and the first traffic threshold determining unit 122 may refer to step S102, the weight determining unit 123, and the second traffic threshold determining unit 124 in the embodiment corresponding to fig. 2, and may refer to step S203 to step S204 in the embodiment corresponding to fig. 4, which is not described herein again. Wherein, when the first traffic threshold determination unit 122 is performing the corresponding operation, the weight determination unit 123, the second traffic threshold determination unit 124 each suspend performing the corresponding operation; when the weight determination unit 123, the second traffic threshold determination unit 124 are performing the respective operations, the first traffic threshold determination unit 122 suspends the performance of the respective operations. The first flow threshold determining unit 122 and the second flow threshold determining unit 124 may be combined into one flow threshold determining unit.

Referring to fig. 7, the determining module 13 may include: a total flow rate counting unit 131, an abnormality detecting unit 132, a deleting unit 133, and a stop adding unit 134;

a total flow rate counting unit 131, configured to determine, as total transaction data, transaction data associated with the target user in the transaction pool, and count the total flow rate corresponding to the total transaction data;

an anomaly detection unit 132, configured to perform anomaly detection on the transaction total data if the total traffic is greater than or equal to a traffic threshold corresponding to the target user;

a deleting unit 133, configured to delete abnormal transaction data from the total transaction data and add the cached transaction data to the transaction pool when the abnormal transaction data exists in the total transaction data;

and the adding stopping unit 134 is configured to stop adding the transaction data to be cached corresponding to the target user to the transaction pool when the abnormal transaction data does not exist in the transaction total data.

The specific functional implementation manners of the total flow statistics unit 131, the abnormality detection unit 132, the deletion unit 133, and the stop adding unit 134 may refer to step S103 in the embodiment corresponding to fig. 2, which is not described herein again.

Referring to fig. 7 together, the weight determination unit 123 may include: a frequency statistics subunit 1231, an activity determination subunit 1232, a total data acquisition subunit 1233, a ratio determination subunit 1234, a credit determination subunit 1235, a selection subunit 1236, a first comparison subunit 1237, and a second comparison subunit 1238;

a frequency statistics subunit 1231, configured to separately count an upload frequency at which the transaction data corresponding to each user is uploaded to the transaction pool;

an activity determination subunit 1232, configured to determine, based on the upload frequency, an activity corresponding to each user, and determine the activity as the service behavior attribute parameter;

a total data obtaining subunit 1233, configured to obtain, in the transaction pool, total transaction data corresponding to each user; the transaction total data comprises invalid data and valid data; the transaction total data respectively corresponding to each user is the transaction data respectively associated with each user in the transaction pool;

a ratio determining subunit 1234, configured to respectively determine an invalid ratio between the invalid data corresponding to each user and the total transaction data;

a credit determining subunit 1235, configured to determine credits corresponding to each user based on the invalid ratio, and determine the credits as the service behavior attribute parameters;

a selecting subunit 1236, configured to select any user from the user set as a user to be processed;

a first comparing subunit 1237, configured to, if the service behavior attribute parameter corresponding to the user to be processed belongs to a first parameter range, determine the service behavior attribute parameter belonging to the first parameter range as a first attribute level, and determine the first attribute level as a traffic distribution weight corresponding to the user to be processed;

a second comparing subunit 1238, configured to, if the service behavior attribute parameter corresponding to the user to be processed belongs to a second parameter range, determine the service behavior attribute parameter belonging to the second parameter range as a second attribute level, and determine the second attribute level as a traffic distribution weight corresponding to the user to be processed.

The specific functional implementation manners of the frequency statistics subunit 1231, the activity determination subunit 1232, the total data acquisition subunit 1233, the ratio determination subunit 1234, the credit determination subunit 1235, the selection subunit 1236, the first comparison subunit 1237, and the second comparison subunit 1238 may refer to step S203 in the embodiment corresponding to fig. 4, which is not described herein again. When the frequency statistics subunit 1231 and the activity determination subunit 1232 execute corresponding operations, the total data acquisition subunit 1233, the ratio determination subunit 1234 and the credit determination subunit 1235 all suspend executing the operations; when the total data acquiring sub-unit 1233, the ratio determining sub-unit 1234, and the credit determining sub-unit 1235 are performing the corresponding operations, the frequency statistics sub-unit 1231, and the activity determining sub-unit 1232 all suspend performing the operations.

Please refer to fig. 8, which is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 8, the computer apparatus 1000 may include: the processor 1001, the network interface 1004, and the memory 1005, and the computer apparatus 1000 may further include: a user interface 1003, and at least one communication bus 1002. Wherein a communication bus 1002 is used to enable connective communication between these components. The user interface 1003 may include a Display screen (Display) and a Keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a standard wireless interface. The network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 1004 may be a high-speed RAM memory or a non-volatile memory (e.g., at least one disk memory). The memory 1005 may optionally be at least one memory device located remotely from the processor 1001. As shown in fig. 8, a memory 1005, which is a kind of computer-readable storage medium, may include therein an operating system, a network communication module, a user interface module, and a device control application program.

In the computer device 1000 shown in fig. 8, the network interface 1004 may provide a network communication function; the user interface 1003 is an interface for providing a user with input; and the processor 1001 may be used to invoke a device control application stored in the memory 1005 to implement:

respectively configuring a traffic threshold associated with the transaction pool for each user in the user set according to the maximum cache capacity and the total number of users in the user set;

It should be understood that the computer device 1000 described in this embodiment of the present application may perform the description of the method for controlling flow of the blockchain transaction pool in the embodiment corresponding to any one of fig. 2 and fig. 4, and may also perform the description of the device 1 for controlling flow of the blockchain transaction pool in the embodiment corresponding to fig. 7, which is not described herein again. In addition, the beneficial effects of the same method are not described in detail.

Further, here, it is to be noted that: an embodiment of the present application further provides a computer-readable storage medium, where a computer program executed by the device 1 for controlling a flow of a blockchain transaction pool mentioned above is stored in the computer-readable storage medium, and the computer program includes program instructions, and when the processor executes the program instructions, the description of the method for controlling a flow of a blockchain transaction pool in the embodiment corresponding to any one of fig. 2 and fig. 4 can be executed, so that details are not repeated here. In addition, the beneficial effects of the same method are not described in detail. For technical details not disclosed in embodiments of the computer-readable storage medium referred to in the present application, reference is made to the description of embodiments of the method of the present application.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.

The above disclosure is only for the purpose of illustrating the preferred embodiments of the present application and is not to be construed as limiting the scope of the present application, so that the present application is not limited thereto, and all equivalent variations and modifications can be made to the present application.

28页详细技术资料下载

Method and device for managing and controlling flow of block chain transaction pool

相关技术

网友询问留言