A charging method, device and storage medium

Abstract

The present invention discloses a charging method, device and storage medium, the method comprising: determining at least one node in a blockchain network; identifying at least one node in the blockchain network and determining the node type; the node types include: first-type nodes and second-type nodes; determining the first quota of each first-type node and the second quota of each second-type node; dividing the at least one node using a preset division algorithm according to the first quota of each first-type node and the second quota of each second-type node to obtain at least one alliance that meets preset conditions; performing fee settlement on the nodes included in each alliance in at least one alliance; wherein the alliance that meets the preset conditions indicates that the difference between the first total quota and the second total quota corresponding to the alliance is lower than a preset threshold; the nodes in the alliance can transfer quotas to each other.

Description

Technical Field

[0001] The present invention relates to the field of business support, and in particular to a charging method, device and storage medium. Background Art

[0002] In recent years, cloud services have flourished in various fields and are changing the world in many ways. As the number of users involved in cloud services increases, higher requirements are put forward for the flexible allocation and flexible billing of cloud service resources. Summary of the invention

[0003] In view of this, the main purpose of the present invention is to provide a billing method, device and storage medium.

[0004] To achieve the above object, the technical solution of the present invention is achieved as follows:

[0005] An embodiment of the present invention provides a charging method, which is applied to a server, and the method includes:

[0006] Identifying at least one node in a blockchain network;

[0007] Identify at least one node in the blockchain network and determine the node type; the node type includes: a first type node and a second type node;

[0008] Determine a first quota for each node of the first category, and determine a second quota for each node of the second category; divide the at least one node using a preset division algorithm according to the first quota of each node of the first category and the second quota of each node of the second category, to obtain at least one alliance that meets preset conditions;

[0009] Performing fee settlement for nodes included in each of the at least one alliance;

[0010] Among them, the alliance that meets the preset conditions represents that the difference between the first total amount and the second total amount corresponding to the alliance is lower than the preset threshold; the nodes in the alliance can transfer quotas to each other.

[0011] In the above solution, the determining of the first amount of each first-type node and the determining of the second amount of each second-type node include:

[0012] Calculate a weighted average redundancy amount based on the historical data of each of the first-type nodes and the weight corresponding to each business cycle in the historical data as a first amount;

[0013] Based on the historical data of each of the second-category nodes and the weight corresponding to each business cycle in the historical data, a weighted average additional demand quota is calculated as the second quota.

[0014] In the above scheme, the method further includes:

[0015] Receiving a distributed ledger sent by the alliance; the distributed ledger is associated with at least two nodes;

[0016] updating states corresponding to the at least two nodes associated with the distributed ledger according to the distributed ledger;

[0017] The performing fee settlement on the nodes included in each of the at least one alliance comprises:

[0018] According to the updated status, fee settlement is performed for nodes included in each of the at least one alliance.

[0019] In the above solution, identifying at least one node in the blockchain network and determining the node type includes:

[0020] Acquire historical data corresponding to each node in the at least one node, identify the historical data using a preset classification model, and determine whether the corresponding node is a first-category node or a second-category node;

[0021] The classification model is used to determine whether each node is a first-category node or a second-category node.

[0022] An embodiment of the present invention provides a charging method, which is applied to a first node. The method includes:

[0023] Determine a service request, and broadcast the service request;

[0024] After receiving the business proposal response from the second node, conducting a business transaction with the second node;

[0025] The first node and the second node belong to the same alliance; when the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node.

[0026] An embodiment of the present invention provides a charging method, which is applied to a second node. The method includes:

[0027] Obtaining a service request of the first node;

[0028] After sending a business proposal response to the business request, performing a business transaction with the first node;

[0029] The first node and the second node belong to the same alliance; when the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node.

[0030] An embodiment of the present invention provides a charging method, which is applied to a third node. The method includes:

[0031] Determine at least two nodes for completing the business transaction;

[0032] Generate a distributed ledger based on the completed business transaction; the distributed ledger is associated with at least two nodes;

[0033] Sending the distributed ledger to a server; the distributed ledger is used by the server to update the states corresponding to the at least two nodes, and to settle fees according to the updated states;

[0034] The third node and the at least two nodes that complete the business transaction belong to the same alliance.

[0035] An embodiment of the present invention provides a charging device, which is applied to a server, and the device includes:

[0036] A first processing module, configured to determine at least one node in a blockchain network;

[0037] A second processing module is used to identify at least one node in the blockchain network and determine the node type; the node type includes: a first type node and a second type node;

[0038] A third processing module is used to determine a first quota of each of the first-type nodes and a second quota of each of the second-type nodes; and to divide the at least one node using a preset division algorithm according to the first quota of each of the first-type nodes and the second quota of each of the second-type nodes, so as to obtain at least one alliance that meets a preset condition;

[0039] A fourth processing module, used for performing fee settlement for nodes included in each of the at least one alliance;

[0040] The alliance that meets the preset conditions represents that the difference between the first total amount and the second total amount corresponding to the alliance is lower than a preset threshold.

[0041] In the above solution, the third processing module is used to calculate the weighted average redundancy amount as the first amount based on the historical data of each of the first-type nodes and the weight corresponding to each business cycle in the historical data;

[0042] Based on the historical data of each of the second-category nodes and the weight corresponding to each business cycle in the historical data, a weighted average additional demand quota is calculated as the second quota.

[0043] In the above solution, the fourth processing module is further used to receive a distributed ledger sent by the alliance; the distributed ledger is related to at least two nodes;

[0044] updating states corresponding to the at least two nodes associated with the distributed ledger according to the distributed ledger;

[0045] Correspondingly, the fourth processing module is used to settle fees for each node included in at least one alliance according to the updated status.

[0046] In the above solution, the second processing module is used to obtain the historical order data corresponding to each node in the at least one node, identify the historical order data using a preset classification model, and determine whether the corresponding node is a first-type node or a second-type node;

[0047] The classification model is used to determine whether each node is a first-category node or a second-category node.

[0048] An embodiment of the present invention provides a charging device, which is applied to a first node, and the device includes:

[0049] A first sending module, used for determining a service request and broadcasting the service request;

[0050] A first receiving module, configured to perform a business transaction with the second node after receiving a business proposal response from the second node;

[0051] The first node and the second node belong to the same alliance; when the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node.

[0052] An embodiment of the present invention provides a charging device, which is applied to a second node, and the device includes:

[0053] A second sending module, used to obtain a service request of the first node;

[0054] A second receiving module, configured to perform a business transaction with the first node after sending a business proposal response to the business request;

[0055] The first node and the second node belong to the same alliance; when the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node.

[0056] An embodiment of the present invention provides a charging device, which is applied to a third node, and the device includes:

[0057] A determination module, configured to determine at least two nodes that have completed a business transaction; generate a distributed ledger based on the completed business transaction; the distributed ledger being associated with the at least two nodes;

[0058] A third sending module is used to send the distributed ledger to the server; the distributed ledger is used by the server to update the status corresponding to the at least two nodes, and perform fee settlement according to the updated status;

[0059] The third node and the at least two nodes that complete the business transaction belong to the same alliance.

[0060] An embodiment of the present invention provides a charging device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps of any one of the charging methods executed by the server side are implemented; or,

[0061] When the processor executes the program, the steps of the charging method executed by the first node side are implemented; or,

[0062] When the processor executes the program, the steps of the charging method executed by the second node side are implemented; or,

[0063] When the processor executes the program, the steps of the charging method executed by the third node side are implemented.

[0064] An embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the steps of any one of the billing methods executed by the server side are implemented; or,

[0065] When the computer program is executed by the processor, the steps of the charging method executed by the first node side are implemented; or,

[0066] When the computer program is executed by the processor, the steps of the charging method executed by the second node side are implemented; or,

[0067] When the computer program is executed by the processor, the steps of the charging method executed by the third node side are implemented.

[0068] A charging method, device and storage medium provided by an embodiment of the present invention include: a server determines at least one node in a blockchain network; identifies at least one node in the blockchain network and determines the node type; the node types include: first-class nodes and second-class nodes; determines the first quota of each first-class node and the second quota of each second-class node; divides the at least one node according to the first quota of each first-class node and the second quota of each second-class node using a preset division algorithm to obtain at least one alliance that meets preset conditions; settles fees for nodes included in each alliance in at least one alliance; wherein the alliance that meets the preset conditions indicates that the difference between the first total quota and the second total quota corresponding to the alliance is lower than a preset threshold; the nodes in the alliance can transfer quotas to each other; in this way, by using blockchain technology, without changing the original cloud service tariff system of the operator, the cloud service quota is flexibly allocated according to the historical usage quota of each node; and by classifying the nodes and dividing the blockchain alliance, the blockchain network performance is optimized and the blockchain file storage overhead is reduced.

[0069] A billing method, device and storage medium provided by an embodiment of the present invention include: a first node determines a service request and broadcasts the service request; after receiving a service proposal response from a second node, a service transaction is performed with the second node; the first node and the second node belong to the same alliance; when the first node is a first-class node, the second node is a second-class node; when the second node is a first-class node, the first node is a second-class node; in this way, the nodes within the alliance transfer quotas to each other, thereby optimizing the performance of the blockchain network and reducing the storage overhead of blockchain files.

[0070] A billing method, device and storage medium provided by an embodiment of the present invention include: a second node obtains a service request from a first node; after sending a service proposal response to the service request, a service transaction is performed with the first node; the first node and the second node belong to the same alliance; when the first node is a first-class node, the second node is a second-class node; when the second node is a first-class node, the first node is a second-class node; in this way, the nodes within the alliance transfer quotas to each other, thereby optimizing the performance of the blockchain network and reducing the storage overhead of blockchain files.

[0071] A billing method, device and storage medium provided by an embodiment of the present invention include: a third node determines at least two nodes that complete a business transaction; a distributed ledger is generated according to the completed business transaction; the distributed ledger is related to at least two nodes; the distributed ledger is sent to a server; the distributed ledger is used by the server to update the status corresponding to the at least two nodes, and settle fees according to the updated status; the third node and the at least two nodes that complete the business transaction belong to the same alliance; in this way, the nodes within the alliance transfer quotas to each other, thereby optimizing the performance of the blockchain network and reducing the storage overhead of blockchain files. BRIEF DESCRIPTION OF THE DRAWINGS

[0072] Figure 1 A flowchart of a charging method provided by an embodiment of the present invention;

[0073] Figure 2 A flowchart of another charging method provided by an embodiment of the present invention;

[0074] Figure 3 A flowchart of another charging method provided by an embodiment of the present invention;

[0075] Figure 4 A flowchart of another charging method provided by an embodiment of the present invention;

[0076] Figure 5 A flowchart of a cloud service billing method provided by an embodiment of the present invention;

[0077] Figure 6 A schematic diagram of the structure of a charging device provided by an embodiment of the present invention;

[0078] Figure 7 A schematic diagram of the structure of another charging device provided by an embodiment of the present invention;

[0079] Figure 8 A schematic diagram of the structure of another charging device provided in an embodiment of the present invention;

[0080] Fig. 9 A schematic diagram of the structure of another charging device provided in an embodiment of the present invention;

[0081] Fig.10 A schematic diagram of the structure of a charging device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0082] The present invention is further described in detail below with reference to the embodiments.

[0083] The blockchain technology is described as follows:

[0084] It is a joint innovative application of four technologies: smart contracts, peer-to-peer networks, encryption algorithms, and consensus mechanisms. Blockchain is essentially a linked list storage structure based on timestamps, also known as a distributed ledger or decentralized database, because the nodes of the blockchain form a peer-to-peer network, showing decentralized characteristics. The blockchain determines the writer based on the consensus mechanism, while ensuring the consistency of data among nodes in the entire network; it ensures data security and reliability based on encryption algorithms, and uses smart contracts deployed on nodes for automated transaction processing. In summary, blockchain has the characteristics of decentralization, collective maintenance, cross-validation, openness and transparency, non-tamperability, and data traceability. It is used in various application scenarios that require new database support, multi-subject business, lack of mutual trust among subjects, and no trusted third party. Typical examples include digital finance, food and drug traceability, and judicial evidence storage.

[0085] As mentioned above, there are currently higher requirements for the flexible allocation of cloud service resources and the flexible billing of cloud service resources. Regarding cloud service billing methods, there are currently the following problems:

[0086] 1. The problem of flexible allocation of cloud service resources. Specifically, some users who subscribe to higher-level cloud service packages (including but not limited to cloud service bandwidth, traffic, or cloud service storage space) do not use up their quota, resulting in a waste of resources, while other users who subscribe to lower-level cloud service packages do not use up their quota. At the same time, these users consider that upgrading their packages will lead to a waste of resources and therefore have no intention to upgrade their packages.

[0087] 2. Flexible billing of cloud service charges. Specifically, the charges for non-fixed quota packages are currently higher than those for fixed quota packages. When users subscribe to fixed quota packages, the flexible billing method based on the user's quota usage is relatively complicated, the billing cost is high, and operators lack the motivation to flexibly bill.

[0088] 3. In the related technologies, user transactions are recorded through blockchain technology; therefore, it also involves the transaction issues after users join the blockchain and the blockchain file storage overhead issues. Specifically, as the blockchain network expands, blockchain business transactions are often slow, non-specific transaction objects are difficult to find, and the larger the blockchain network, the higher the storage overhead required for blockchain files.

[0089] Based on this, the method provided by the embodiment of the present invention is that the server determines at least one node in the blockchain network; identifies at least one node in the blockchain network and determines the node type; the node types include: first-type nodes and second-type nodes; determines the first quota of each first-type node, and determines the second quota of each second-type node; according to the first quota of each first-type node and the second quota of each second-type node, the at least one node is divided using a preset division algorithm to obtain at least one alliance that meets preset conditions; settles fees for the nodes included in each alliance in at least one alliance; wherein the alliance that meets the preset conditions represents that the difference between the first total quota and the second total quota corresponding to the alliance is lower than a preset threshold; the nodes in the alliance can transfer quotas to each other.

[0090] The present invention will be further described in detail below in conjunction with the embodiments.

[0091] Figure 1 A flowchart of a charging method provided by an embodiment of the present invention; Figure 1 As shown, the method is applied to a server, and the server may be set up and managed by a cloud service provider. The method includes:

[0092] Step 101: Determine at least one node in the blockchain network;

[0093] Step 102: Identify at least one node in the blockchain network and determine the node type; the node type includes: first type node and second type node;

[0094] Step 103: determining a first quota of each of the first-category nodes, and determining a second quota of each of the second-category nodes; dividing the at least one node using a preset division algorithm according to the first quota of each of the first-category nodes and the second quota of each of the second-category nodes, to obtain at least one alliance that meets preset conditions;

[0095] The alliance that meets the preset condition represents that the difference between the first total amount and the second total amount corresponding to the alliance is lower than the preset threshold;

[0096] Nodes in the alliance can transfer quotas to each other;

[0097] Step 104: Perform fee settlement for each node included in at least one alliance.

[0098] Specifically, in step 101, the cloud service provider, as the management organization of the blockchain network, creates and starts the blockchain network. The cloud service provider itself does not participate in actual business transactions, but acts as a core enterprise to guarantee transactions and settle at the end of each business cycle. That is, the server does not involve direct transactions between nodes, but only acts as a fee settlement party.

[0099] Here, the blockchain network includes: at least one node. Each node can be a terminal held by each user.

[0100] At least one node classification is divided into two types. Specifically, when the first type of node represents that the corresponding node is a lessee, the second type of node represents that the corresponding node is a transferor; conversely, when the second type of node represents that the corresponding node is a lessee, the first type of node represents that the corresponding node is a transferor.

[0101] A consortium chain is built based on the access principle of subscribing to cloud service packages. That is, users are eligible to join the blockchain only after they subscribe to the blockchain through their own nodes (the nodes are any intelligent terminals, such as smartphones, tablets, etc., which require cloud services). That is, the blockchain is a permissioned blockchain network (consortium chain).

[0102] Each cloud service package subscription transaction written to the blockchain (i.e., the addition / modification of package amounts described below) will generate an "account receivable" on the server. Based on this account, the server can first provide cloud service services to the user's corresponding node for the user to use, and bill and settle the node at the end of the service cycle.

[0103] In some embodiments, the performing fee settlement on the nodes included in each of the at least one alliance includes:

[0104] According to a preset business cycle, fee settlement is performed for each node included in at least one alliance.

[0105] The business cycle may be different for different business types; for example, one week is a business cycle (such as ordering a 7-day traffic package), one month is a business cycle (such as ordering a monthly traffic package), half a year is a business cycle (such as ordering a half-year card service), one year is a business cycle (such as ordering an annual card service), etc.

[0106] Specifically, the alliance that meets the preset condition represents that the difference between the first total amount and the second total amount corresponding to the alliance is lower than a preset threshold.

[0107] The server may predetermine the partitioning algorithm based on demand to obtain an alliance that meets preset conditions.

[0108] The partitioning algorithm can be set by the developer based on the requirements. Specifically, the following conditions can be set:

[0109] The maximum total number of nodes included in the alliance;

[0110] A preset threshold for determining the difference between the first total amount and the second total amount within the alliance.

[0111] For example, the partitioning algorithm adopted by the server includes: the node group whose maximum total number of nodes does not exceed a predetermined value P, the initial number does not exceed aP, and the stable number does not exceed bP is demarcated as an alliance (also called alliance chain) in the blockchain.

[0112] Here, the specific values ​​of a and b depend on the actual business needs and are not limited. A reference value of a and b is given as: a=0.5, b=0.9.

[0113] The partitioning algorithm adopted by the server includes: the sum M (i.e., M is the first total amount) of the basic transferable amount m (i.e., a first amount) of all nodes belonging to the transferor (here, assuming that the first type of nodes are the transferor's nodes) is roughly equal to the sum N (i.e., N is the second total amount) of the basic rental amount n (i.e., a second amount) of all nodes belonging to the borrower (i.e., the second type of nodes are the borrower's nodes), i.e., N≈M. Here, a reference floating value x% can be provided, i.e., N / M=1±x%; the x% can be modified according to the actual business situation, for example, it can be 2%, 4%, 5%, 6%, etc., which is not limited here.

[0114] In some embodiments, the method further comprises:

[0115] Receiving a distributed ledger sent by the alliance; the distributed ledger is associated with at least two nodes;

[0116] updating states corresponding to the at least two nodes associated with the distributed ledger according to the distributed ledger;

[0117] The performing fee settlement on the nodes included in each of the at least one alliance comprises:

[0118] According to the updated status, fee settlement is performed for nodes included in each of the at least one alliance.

[0119] Here, each node in the alliance can transfer quotas to each other. Therefore, after each transaction (such as a node transfers quota and another node rents quota accordingly), a distributed ledger is generated; the server updates the status of the relevant nodes based on the received distributed ledger; accordingly, when settling fees, the fees are settled according to the updated status.

[0120] In some embodiments, identifying at least one node in the blockchain network and determining the node type includes:

[0121] Acquire historical data corresponding to each node in the at least one node, identify the historical order data using a preset classification model, and determine whether the corresponding node is a first-category node or a second-category node;

[0122] The classification model is used to determine whether each node is a first-category node or a second-category node.

[0123] The historical data includes: historical order data and historical quota usage data.

[0124] Based on the historical data corresponding to each node, determine the estimated demand amount for each node.

[0125] Specifically, historical data corresponding to each node in the at least one node is obtained, an estimated demand amount of each node is determined based on the historical data corresponding to each node, the estimated demand amount is identified using a preset classification model, and the corresponding node is determined to be a first-category node or a second-category node.

[0126] Determining the estimated demand amount of each node according to the historical data corresponding to each node includes:

[0127] According to the historical data, obtain the record corresponding to at least one historical business cycle, and determine the usage quota of at least one unit time in each business cycle;

[0128] Determine the usage quota per unit time corresponding to each historical business cycle;

[0129] Determine the maximum usage quota per unit time corresponding to each historical business cycle;

[0130] Determine the average maximum usage per unit time corresponding to the historical business cycle;

[0131] Based on the determined average value, determine the amount required for each business cycle as the estimated demand amount.

[0132] That is, the estimated demand amount is the amount required in each business cycle calculated based on the average maximum usage amount per unit time.

[0133] In some embodiments, the method further comprises: generating the classification model; the generating the classification model comprises:

[0134] Acquire at least one training sample, and obtain a training sample set based on the at least one training sample;

[0135] The training sample set is used to train a preset target model to obtain a trained target model as the classification model.

[0136] Each training sample includes: the sample estimated demand amount of the corresponding node and the corresponding label; the label includes: first-category nodes and second-category nodes.

[0137] When the first type of node represents that the corresponding node is a lessee, the second type of node represents that the corresponding node is a transferor; conversely, when the second type of node represents that the corresponding node is a lessee, the first type of node represents that the corresponding node is a transferor.

[0138] Here, there is no restriction on the specific implementation of the classification model, and machine learning or deep learning related algorithms can be used, such as support vector machine (SVM) and its improved algorithm, back propagation (BP) neural network and its improved algorithm, convolutional neural network (CNN) and its improved algorithm, etc. That is, the preset target model can be SVM, BP neural network, CNN, etc.

[0139] Here, the training sample set is composed of historical user data stored in the server of the cloud service provider. In addition, after each service cycle, incremental training is performed based on the user's actual subscription package quota, actual usage quota, and actual payment fee to update the classification model.

[0140] The determination index of the classification model may be an estimated demand amount (indicated by symbol K).

[0141] Acquiring each of the training samples at least includes: acquiring the sample estimated demand amount and the corresponding label (ie, the first type of node or the second type of node) corresponding to each node.

[0142] For each node, obtaining the sample estimated demand amount corresponding to each node includes:

[0143] According to the historical data corresponding to each node, obtain the record corresponding to at least one historical business cycle, and determine the usage quota of at least one unit time in each historical business cycle;

[0144] Determine the usage quota per unit time corresponding to each historical business cycle;

[0145] Determine the maximum usage quota per unit time corresponding to each historical business cycle;

[0146] Determine the average maximum usage per unit time corresponding to the historical business cycle;

[0147] Based on the determined average value, determine the amount required for each business cycle as a sample estimated demand amount.

[0148] The usage quota per unit time corresponding to each historical business cycle may be determined based on the actual usage quota in the historical data.

[0149] Specifically, suppose there are a total of A business cycles in the historical data. In each business cycle T, the first i unit time t i The usage amount is m i ;

[0150] Usage amount per unit time k i Defined as time t i The average usage per unit time; i.e.

[0151] Maximum usage per unit time k max Defined as all k in each business cycle T i The maximum value of k max =max(k i ,i∈T)

[0152] Average maximum usage per unit time Defined as all k in all A business cycles max The average value of

[0153] That is, the estimated demand quota K is defined as the quota required in each business cycle T calculated according to the average maximum unit time usage quota, that is,

[0154] The estimated demand amount for samples and the estimated demand amount required for actual identification are determined using the above method, which will not be elaborated here.

[0155] Here, the service cycle is different for different services. For example, for data traffic services, the service cycle can be 1 month; for video services with annual cards, the service cycle can be 1 year; the unit time setting can also be different, for example, it can be 1 day, 1 week, etc.

[0156] It should be noted that according to the general usage rules of cloud service business, as the end date of the business cycle approaches, users will adjust their usage strategies according to the consumed quota. Users with more redundancy will try every means to increase the quota consumption, and users with almost exhausted balances will suppress the frequency of use. That is, the consumption generated by users at the beginning of a business cycle is the most reflective of the user's own needs. For data traffic business, the data traffic quota is sufficient in the early stage, and users can use it as needed, but in the later stage, they may consider insufficient quota and suppress usage. Therefore, here we select the usage quota of at least the first unit time (that is, the first i units of time) that can reflect the user's needs.

[0157] Moreover, the meaning of K above is the estimated demand value when the quota consumption frequency is covered throughout the business cycle.

[0158] Specifically, the type discrimination criteria adopted by the classification model are as follows:

[0159] Based on the historical data of the user, determine that in all business cycles (denoted as A business cycles), the total sum of all ordered package quotas is M tot ;

[0160] Corresponding to M tot ≥KA, determine the node as the transferor; it can also be determined that its basic transfer quota is (M tot -KA) / A;

[0161] Corresponding to M tot <KA, determine the node as the lessee; it can also be determined that its basic demand quota is (KA - M tot ) / A.

[0162] The total sum of all the above ordered package quotas can be determined based on the actual ordered package quota and the actual payment in the user's historical data.

[0163] That is, based on the above criteria, the estimated demand quota of the samples in the training samples can be determined, and it can be determined whether the node corresponding to the sample estimated demand quota is the transferor or the lessee, and combined with the label corresponding to the node for model training, so as to obtain a classification model that can classify nodes based on the above type discrimination criteria.

[0164] In one embodiment, the first type of node is the transferor and the second type of node is the lessee; the determining the first quota of each of the first type of nodes and the second quota of each of the second type of nodes includes:

[0165] For the first type of nodes, determine the first quota according to the total ordered package quota and the number of business cycles within one or more business cycles; for example, combined with the above example, the first quota can be (M tot -KA) / A;

[0166] For the second type of nodes, determine the second quota according to the total ordered package quota and the number of business cycles within one or more business cycles; for example, combined with the above example, the second quota can be (KA - M tot ) / A.

[0167] In another embodiment, the first type of node is the transferor and the second type of node is the lessee;

[0168] The determining the first quota of each of the first type of nodes and the second quota of each of the second type of nodes includes:

[0169] Based on the historical data of each of the first-category nodes and the weight corresponding to each business cycle in the historical data, a weighted average redundancy amount is calculated as the first amount (i.e., the basic transferable amount);

[0170] Based on the historical data of each of the second-type nodes and the weight corresponding to each business cycle in the historical data, a weighted average additional required amount is calculated as the second amount (ie, the basic required rental amount).

[0171] The step of calculating the weighted average redundancy amount based on the historical data of each of the first-type nodes and the weight corresponding to each business cycle in the historical data includes:

[0172] Obtaining historical data of a corresponding node within a preset time period; the preset time period includes at least one historical business cycle; the historical data includes: sub-historical data corresponding to each historical business cycle; the sub-historical data includes: a first historical quota and a second historical quota; the first historical quota represents a redundant quota; the second historical quota represents an available quota;

[0173] Assign corresponding weights to each historical business cycle;

[0174] According to the weight corresponding to each historical business cycle, the first historical quota corresponding to each historical business cycle is weighted to obtain the weighted first historical quota corresponding to each historical business cycle as the first target historical quota;

[0175] According to the first target historical quota corresponding to each historical business cycle, the basic transferable quota corresponding to the corresponding node is determined. For example, the first target historical quota corresponding to each historical business cycle is averaged.

[0176] The step of calculating the weighted average redundancy amount based on the historical data of each of the first-type nodes and the weight corresponding to each business cycle in the historical data includes:

[0177] Obtaining historical data of a corresponding node within a preset time period; the preset time period includes at least one historical business cycle; the historical data includes: sub-historical data corresponding to each historical business cycle; the sub-historical data includes: a third historical quota and a fourth historical quota; the third historical quota represents an excess quota; the fourth historical quota represents an available quota;

[0178] Assign corresponding weights to each historical business cycle;

[0179] According to the weight corresponding to each historical business cycle, the third historical quota corresponding to each historical business cycle is weighted to obtain the weighted third historical quota corresponding to each historical business cycle as the third target historical quota;

[0180] According to the third target historical quota corresponding to each historical business cycle, the basic rental quota corresponding to the corresponding node is determined. For example, the third target historical quota corresponding to each historical business cycle is averaged.

[0181] It should be noted that when a user uses a node to obtain cloud service services, he or she can register in advance and obtain a unique account, and the cloud service provider provides corresponding services for the account. Accordingly, the historical data of the corresponding node mentioned above refers to the historical data corresponding to the account used by the node, that is, the historical data corresponding to the account owned by the user.

[0182] Here, a corresponding weight is assigned to each historical business cycle, and the weight assignment is performed based on preset rules. The preset rules may be weight division for the first historical quota and the second historical quota of each historical business cycle of the corresponding node; or, a weight assignment model may be pre-trained, and the weight assignment model may be used to analyze the first historical quota and the second historical quota of each historical business cycle, and weight assignment is performed based on the analysis results. A high weight indicates that the reference value of the first historical quota of the corresponding historical business cycle is higher, and conversely, a low weight indicates that the reference value of the first historical quota of the corresponding historical business cycle is relatively low.

[0183] Taking the first-class nodes as an example, for a first-class node, with a business cycle of one month, the second historical quota in the first month is 100G, and the redundant quota, that is, the first historical quota is 80G; the second historical quota in the second month is 20G, and the first historical quota is 5G; it can be seen that the user may actually only need a quota of about 15G-20G. Although there is 80G redundancy in the first month, 80G is obviously too high for the calculation of the basic transferable quota, and its reference value is relatively low. Therefore, the corresponding weight allocated in the first month should be lower than the corresponding weight allocated in the second month.

[0184] Figure 2 A flowchart of another charging method provided by an embodiment of the present invention; Figure 2 As shown, the method is applied to a first node, and the method includes:

[0185] Step 201: determine a service request and broadcast the service request;

[0186] Step 202: After receiving the business proposal response from the second node, conduct a business transaction with the second node;

[0187] wherein the first node and the second node belong to the same alliance;

[0188] When the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node.

[0189] Figure 3 A flowchart of another charging method provided by an embodiment of the present invention; Figure 3 As shown, the method is applied to the second node, and the method includes:

[0190] Step 301: Obtain a service request of a first node;

[0191] Step 302: After sending a business proposal response to the business request, conduct a business transaction with the first node;

[0192] wherein the first node and the second node belong to the same alliance;

[0193] When the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node.

[0194] against Figure 2 and Figure 3 For the method shown, when the first node is the borrower, the second node can be the transferor; accordingly, when the first node determines that its own credit limit is insufficient, it can determine a business request, which includes: requesting a credit limit to be borrowed; broadcasting the corresponding business request; after receiving the business request, other nodes in the alliance can respond based on their own situation, and a certain node (i.e., the second node) responds to the business request and sends a business proposal response to the business request, and then can conduct a business transaction with the first node. In this way, the first node and the second node have performed a credit limit transfer and credit limit borrowing.

[0195] The first node sends a service request, and the second node sends a service proposal response to the service request, which can be performed after confirmation by the user holding the corresponding node. That is, the user confirms and sends the service request and confirms and sends the service proposal response through the human-computer interaction interface of the node held by the user.

[0196] On the contrary, when the first node is the transferor, the second node may be the borrower; the execution operation is the same as described above and will not be repeated here.

[0197] Figure 4 A flowchart of another charging method provided by an embodiment of the present invention is shown; Figure 4 As shown, the method is applied to a third node, and the method includes:

[0198] Step 401: Determine at least two nodes that complete the business transaction;

[0199] Step 402: Generate a distributed ledger based on the completed business transaction; the distributed ledger is associated with at least two nodes;

[0200] Step 403: Send the distributed ledger to the server; the distributed ledger is used by the server to update the status corresponding to the at least two nodes, and perform fee settlement according to the updated status;

[0201] The third node and the at least two nodes that complete the business transaction belong to the same alliance.

[0202] Here, each alliance chain (i.e., the above-mentioned alliance) is equipped with an enterprise node, i.e., the third node. The enterprise node is not involved in credit transactions and is only used for accounting and interacting with the server.

[0203] After at least two nodes related to a business transaction (such as the first node and the second node mentioned above) conduct a quota transaction, a third node generates a distributed ledger based on the completed business transaction and sends the distributed ledger to the server; the server updates the corresponding status of at least two nodes related to the distributed ledger (i.e., at least two nodes conducting the transaction) according to the distributed ledger, and settles the fees according to the updated status. The third node can be set by the server when dividing the alliance.

[0204] Specifically, the nodes in the alliance (such as the first node and the second node mentioned above) can be smart terminals held by corresponding users, such as mobile phones, tablet computers, computers, wearable devices, etc.

[0205] After each node joins the blockchain, it deploys smart contract S on the node it owns. Smart contract S has at least three functional interfaces: status query interface, add / modify package quota interface, and transfer / rent package quota interface. In addition to these three interfaces, the smart contract should be scalable and add functional interfaces according to actual business needs.

[0206] Status query interface: Users can perform corresponding operations through the node's human-computer interaction interface. The node determines to call the status query interface on the smart contract based on the operation, submits a query transaction, and queries the world status on all distributed ledgers owned by the user, that is, the actual settlement fee of the current package and the actual available amount of the current package.

[0207] Add / modify package quota interface: Users perform corresponding operations through the human-computer interaction interface of the node. The node determines to call the add / modify package quota interface on the smart contract based on the operation, and can submit an update transaction. Users submit to order new packages or modify existing packages based on the business package standards provided by the cloud service provider, and submit the order or modification results as an update transaction to the blockchain.

[0208] Transfer / rental package quota interface: The user performs corresponding operations through the human-computer interaction interface of the node. The node determines to call the transfer / rental package quota interface on the smart contract based on the operation, and can submit a two-stage business transaction. Here, the business transaction is divided into two steps. First, the user calls the transfer / rental package quota interface, and initiates a transfer / rental transaction request to a non-specific target user based on the existing quota and its actual quota demand. Then, after the user obtains the transaction proposal response from the target user, he calls the transfer / rental package quota interface again, submits an agreed quota transfer / rental transaction, and submits the transaction result to the blockchain after the transaction is completed.

[0209] In a business transaction, the non-specific target user of the transferor can only be the lessee, and the non-specific target user of the lessee can only be the transferor; that is, when the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node.

[0210] The broadcast of the first phase of the transaction should be considered a query transaction, which is used to query the tradable objects and propose a transaction plan. The second phase of the transaction should be considered an update transaction, which is used to modify the distributed ledger world state of both parties to the transaction.

[0211] Figure 5 A flowchart of a cloud service billing method provided by an embodiment of the present invention; Figure 5 As shown, the method includes:

[0212] Step 501: The cloud service provider creates and starts a blockchain network.

[0213] Here, the cloud service provider acts as the management organization of the blockchain network, and the cloud service provider creates and starts the blockchain network. The subscription of cloud service packages is used as the admission principle to build a consortium chain.

[0214] The cloud service provider is the manager of the blockchain network. It does not participate in actual business transactions itself, but acts as a core enterprise to guarantee transactions and perform settlement at the end of each business cycle.

[0215] Users are eligible to join the blockchain only after they subscribe to the blockchain through the nodes they hold (such as mobile phones, tablets, computers, wearable devices and other terminals), that is, the blockchain is a permissioned blockchain network (i.e. the consortium chain).

[0216] Every cloud service package subscription transaction written to the blockchain (such as adding a new package quota, modifying a package quota) will generate an "account receivable" at the cloud service provider. The cloud service provider can provide cloud service services to users in advance based on this account, and bill and settle users at the end of the service cycle.

[0217] Step 502: Identify at least one node in the blockchain network and classify the at least one node into a first type of node or a second type of node;

[0218] Among them, the number of the first type of nodes is at least one; the first type of node is the transferor; the transferor refers to a node whose subscription package quota exceeds the actual usage quota of the user, that is, a node with redundant quota that can be rented out and transferred.

[0219] The number of the second type of nodes is at least one; the second type of node is a lessee; the lessee refers to a user whose package quota is used up at an earlier period within the package usage limit, and the node needs to control the quota usage, or order additional quota to meet its own usage needs.

[0220] Specifically, the step 502 includes:

[0221] The historical data of each node in the at least one node is obtained, and the historical data is identified using a preset classification model to determine whether the corresponding node is a first-category node or a second-category node.

[0222] Here, before step 502, the method further includes: using the historical data of the node (including historical ordering data and cloud service quota usage data) to train a classification model, wherein the classification model is used to determine whether the node is a first-class node or a second-class node. The model training process has been Figure 1 The method is described in detail and will not be repeated here.

[0223] Step 503: determine the basic transferable amount of each first-category node in at least one first-category node, and determine the basic rental amount of each second-category node in at least one second-category node.

[0224] The step 503 includes:

[0225] Based on the historical data of each of the first-type nodes and the weight corresponding to each business cycle in the historical data, a weighted average redundancy amount is calculated as the basic transferable amount;

[0226] Based on the historical data of each of the second-category nodes and the weight corresponding to each business cycle in the historical data, a weighted average additional demand amount is calculated as the basic required rental amount.

[0227] The step of calculating the weighted average redundancy amount m based on the historical data of each of the first-type nodes and the weight corresponding to each business cycle in the historical data includes:

[0228] Obtaining historical data of a corresponding node within a preset time period; the preset time period includes at least one historical business cycle; the historical data includes: sub-historical data corresponding to each historical business cycle; the sub-historical data includes: a first historical quota and a second historical quota; the first historical quota represents a redundant quota; the second historical quota represents an available quota;

[0229] Assign corresponding weights to each historical business cycle;

[0230] According to the weight corresponding to each historical business cycle, the first historical quota corresponding to each historical business cycle is weighted to obtain the weighted first historical quota corresponding to each historical business cycle as the first target quota;

[0231] According to the first target quota corresponding to each historical business cycle, the basic transferable quota m corresponding to the corresponding node is determined.

[0232] The step of calculating the weighted average additional demand amount n based on the historical data of each of the second-type nodes and the weight corresponding to each business cycle in the historical data includes:

[0233] Obtaining historical data of a corresponding node within a preset time period; the preset time period includes at least one historical business cycle; the historical data includes: sub-historical data corresponding to each historical business cycle; the sub-historical data includes: a third historical quota and a fourth historical quota; the third historical quota represents an excess quota; the fourth historical quota represents an available quota;

[0234] Assign corresponding weights to each historical business cycle;

[0235] According to the weight corresponding to each historical business cycle, the third historical quota corresponding to each historical business cycle is weighted to obtain the weighted third historical quota corresponding to each historical business cycle as the third target quota;

[0236] According to the third target amount corresponding to each historical business cycle, the basic rental amount n corresponding to the corresponding node is determined.

[0237] Here, a corresponding weight is assigned to each historical business cycle, and the weight allocation is performed based on preset rules. The preset rules may be weight division based on the first historical quota and the second historical quota of each historical business cycle of the corresponding user; or, a weight allocation model may be pre-trained, and the weight allocation model may be used to analyze the first historical quota and the second historical quota of each historical business cycle, and weight division is performed based on the analysis results. A high weight indicates that the reference value of the first historical quota of the corresponding historical business cycle is higher, and conversely, a low weight indicates that the reference value of the first historical quota of the corresponding historical business cycle is relatively low.

[0238] Taking the first type of nodes as an example, for a certain first type of node, with a monthly business cycle, the second quota in its first month is 100G, and the redundant quota, that is, the first historical quota, is 80G; the second historical quota in the second month is 20G, and the first historical quota is 5G; it can be seen that the user may actually only need about 15G - 20G of quota. Although there is a redundancy of 80G in the first month, for the calculation of the basic transferable quota, 80G is significantly too high and its reference value is relatively low. Then the weight assigned to the first month should be lower than the weight assigned to the second month.

[0239] Step 504: According to the basic transferable quota of each first type of node and the basic lease quota required by each second type of node, use a preset partitioning algorithm to partition at least one node to obtain a coalition that meets the preset conditions; the coalition that meets the preset conditions represents that the difference between the total first quota and the total second quota corresponding to the coalition is lower than the preset threshold.

[0240] The server, based on a preset partitioning algorithm, designates a group of nodes with a total quantity not exceeding a predetermined value P, an initial quantity not exceeding aP, and a stable quantity not exceeding bP as a coalition in the blockchain. Here, the specific values of a and b depend on the actual business requirements and are not limited. Here, a reference value for a and b is given: a = 0.5, b = 0.9.

[0241] The partitioning algorithm can satisfy that in this coalition, the sum M of the basic transferable quotas m of all nodes belonging to the transferors is approximately equal to the sum N of the basic lease quotas n of all nodes belonging to the lessees, that is, N≈M. Here, a reference floating value x% can be provided, that is: N / M = 1 ± x%; the x% can be modified according to the actual business situation. For example, it can be 4%, 5%, 6%, etc., which is not limited here.

[0242] The significance of partitioning the coalition using the above partitioning algorithm is to balance the demands and redundancies of the nodes of each user in the coalition and尽可能 meet the transfer / lease demands of each member in the coalition. At the same time, controlling the size of the coalition not to exceed P can reduce the size of the sub-blockchain ledger formed by the coalition and减轻 the blockchain file storage overhead.

[0243] After the coalition is formed, other nodes can join the coalition that has not reached the stable quantity. The admission principle of the coalition is: in the current coalition, if M≥N, that is, "supply exceeds demand" and the total redundant quota exceeds the total demand quota, then this coalition only allows nodes determined to be lessees to join, and nodes determined to be transferors cannot join this coalition. If M<N, that is, "demand exceeds supply" and the total redundant quota is lower than the total demand quota, then this coalition only allows nodes determined to be transferors to join, and nodes determined to be lessees cannot join this coalition.

[0244] The difference between the stable quantity bP and the rated total quantity P is the design redundancy. When a large amount of quota redundancy or quota demand occurs in an alliance that has reached a stable quantity due to changes in user packages, this part can be used to rebalance the quota demand.

[0245] The method comprises:

[0246] Step 505: For each alliance, process the business transaction corresponding to the first target node.

[0247] Here, after each user joins the blockchain, he deploys the smart contract S on the node he owns.

[0248] Smart contract S has at least three functional interfaces: status query interface S1, add or modify package quota interface S2, transfer or rent package quota interface S3. In addition to these three interfaces, smart contracts should be scalable and add functional interfaces according to actual business needs.

[0249] Among them, status query interface S1: users can perform corresponding operations through the human-computer interaction interface of the node. The node determines to call the S1 interface on the smart contract based on the operation, and can submit a query transaction to query the world status on all distributed ledgers owned by the user, that is, the actual settlement fee of the current package and the actual available amount of the current package.

[0250] Add or modify package quota interface S2: Users can perform corresponding operations through the human-computer interaction interface of the node. The node determines to call the S2 interface on the smart contract based on the operation and can submit an update transaction. Users submit to order new packages or modify existing packages based on the business package standards provided by the cloud service provider, and submit the ordering / modification results as an update transaction to the blockchain.

[0251] Transfer or lease package quota interface S3: Users can perform corresponding operations through the node's human-computer interaction interface. The node determines to call the S3 interface on the smart contract based on the operation and can submit a two-stage business transaction.

[0252] Here, the first target node is a node in the alliance that is determined to have a service request.

[0253] The step 505 includes:

[0254] 01. Receive a business request; send a transfer transaction request or a lease transaction request to a non-specific target user in the alliance according to the business request;

[0255] Here, the user can call the transfer or rental package quota interface to initiate a transfer transaction request or a rental transaction request to a non-specific second target node (the target node that can conduct transactions with the first target node is referred to as the second target node) based on the existing quota and its actual quota needs.

[0256] 02. After obtaining the transaction proposal response from the second target node, call the transfer or lease package quota interface again, submit an agreed quota transfer transaction or quota lease transaction, and submit the transaction result to the blockchain after the transaction is completed.

[0257] In a business transaction, the non-specific target node of the transferor can only be the lessee, and the non-specific target node of the lessee can only be the transferor.

[0258] The broadcast of the first phase of the transaction should be considered a query transaction, which is used to query the tradable objects and propose a transaction plan. The second phase of the transaction should be considered an update transaction, which is used to modify the distributed ledger world state of both parties to the transaction.

[0259] Step 506: When a node joins an alliance of the blockchain network and submits a transaction to add or modify the package quota according to the subscribed cloud service package, the cloud service provider allocates the quota corresponding to the package to the node for the corresponding user to use.

[0260] Step 507: When the third target node completes a transaction of transferring or renting a package quota, the cloud service provider will query the distributed ledgers of both parties to the transaction and reallocate the quota based on the updated world state.

[0261] Step 508: At the end of each business cycle, each node needs to pay fees to the cloud service provider based on its current world state recorded in the distributed ledger.

[0262] If payment is overdue, the cloud service provider can freeze the account of the node according to the terms of use, submit the data retained in the distributed ledger to the credit reporting agency, and take corresponding measures against the defaulting node.

[0263] Step 509: After the settlement of each new business cycle is completed, the blockchain network deletes all blockchain data of the Xth business cycle before the current cycle.

[0264] Here is a reference value for X: when a business cycle is one month, X = 6. That is, all blockchain data in each business cycle is retained for 6 months and deleted uniformly six months after the business cycle is completed. The specific value of X can be adjusted based on the specific business cycle and business needs of the cloud service provider.

[0265] The embodiment of the present invention further provides a cloud service billing device, the device at least comprising:

[0266] The user behavior determination model (equivalent to the above-mentioned classification model) is used to analyze the node's past ordering service behavior data (equivalent to the above-mentioned historical data), and determine whether the corresponding node is a transferor or a borrower based on the analysis results, and determine the corresponding basic transferable amount or basic rental amount.

[0267] The blockchain network is used to upload the ordering information of cloud service nodes to the chain (the chain refers to writing the corresponding data into the blockchain), and to regulate and manage package ordering information, user quotas, transfer or lease transactions of quotas, etc. through smart contracts.

[0268] The cloud service flexible billing unit is used to implement the functions involved in cloud services, including: node classification, node joining blockchain and alliance, node exiting blockchain and alliance, initiating quota transfer transactions, initiating quota leasing transactions, adding cloud service packages, modifying cloud service packages, etc.

[0269] The specific implementation method has been Figure 1 The method is described in detail and will not be repeated here.

[0270] The present invention provides another cloud service billing device in real time, which includes at least: a user information management module, a cloud service subscription modification module, a blockchain operation module, a settlement module, and a cloud service connection module.

[0271] Among them, the user information management module is used to realize user registration, record user information, modify information, etc.; and classify users according to user historical data and provide user analysis results, so that users can have an intuitive grasp of their own consumption needs.

[0272] The cloud service subscription modification module serves as a transaction interface for users to directly reach a cloud service subscription transaction with the cloud service provider. After the transaction is reached, the cloud service provider will allocate the quota corresponding to the package to the node for the user holding the node to use. In addition, users can add and modify packages at any time through this module, and all package changes completed in this module will be applicable in the next business cycle.

[0273] The blockchain operation module allows users to perform operations such as node joining / exiting the blockchain and alliance, initiating quota transfer / rental transactions, submitting new / modifying cloud service packages, and submitting user operation results to the blockchain.

[0274] The cloud service connection module is the interface between the device and the relevant cloud service system subscribed by the user. The user uses the cloud service by calling the cloud service connection module. The cloud service system obtains various information of the user, including cloud service packages and quotas, by calling the cloud service connection module, and provides services to the user accordingly.

[0275] The settlement module is used to settle the cloud service packages and quotas used by each user.

[0276] Figure 6 A schematic diagram of the structure of a charging device provided by an embodiment of the present invention; Figure 6 As shown, the device is applied to a server of a cloud service provider, and the device includes:

[0277] A first processing module, configured to determine at least one node in a blockchain network;

[0278] A second processing module is used to identify at least one node in the blockchain network and determine the node type; the node type includes: a first type node and a second type node;

[0279] A third processing module is used to determine a first quota of each of the first-type nodes and a second quota of each of the second-type nodes; and to divide the at least one node using a preset division algorithm according to the first quota of each of the first-type nodes and the second quota of each of the second-type nodes, so as to obtain at least one alliance that meets a preset condition;

[0280] A fourth processing module, used for performing fee settlement for nodes included in each of the at least one alliance;

[0281] The alliance that meets the preset conditions represents that the difference between the first total amount and the second total amount corresponding to the alliance is lower than a preset threshold.

[0282] Specifically, the third processing module is used to calculate the weighted average redundancy amount as the first amount based on the historical data of each first-type node and the weight corresponding to each business cycle in the historical data; and calculate the weighted average additional demand amount as the second amount based on the historical data of each second-type node and the weight corresponding to each business cycle in the historical data.

[0283] Specifically, the fourth processing module is used to perform fee settlement for each node included in at least one alliance according to a preset business cycle.

[0284] The fourth processing module is further configured to receive a distributed ledger sent by the alliance; the distributed ledger is associated with at least two nodes;

[0285] updating states corresponding to the at least two nodes associated with the distributed ledger according to the distributed ledger;

[0286] Correspondingly, the fourth processing module is used to settle fees for each node included in at least one alliance according to the updated status.

[0287] Specifically, the second processing module is used to obtain the historical order data corresponding to each node in the at least one node, identify the historical order data using a preset classification model, and determine whether the corresponding node is a first-type node or a second-type node;

[0288] The classification model is used to determine whether each node is a first-category node or a second-category node.

[0289] It should be noted that: the billing device provided in the above embodiment only uses the division of the above program modules as an example to illustrate when implementing the corresponding billing method. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the server is divided into different program modules to complete all or part of the processing described above. In addition, the device provided in the above embodiment and the embodiment of the corresponding method belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0290] Figure 7 A schematic diagram of the structure of another charging device provided by an embodiment of the present invention; Figure 7 As shown, the device is applied to a first node, and the device includes:

[0291] A first sending module, used for determining a service request and broadcasting the service request;

[0292] A first receiving module, configured to perform a business transaction with the second node after receiving a business proposal response from the second node;

[0293] The first node and the second node belong to the same alliance; when the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node.

[0294] It should be noted that: the billing device provided in the above embodiment only uses the division of the above program modules as an example to illustrate when implementing the corresponding billing method. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the first node is divided into different program modules to complete all or part of the processing described above. In addition, the device provided in the above embodiment and the embodiment of the corresponding method belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0295] Figure 8 A schematic diagram of the structure of another charging device provided in an embodiment of the present invention; Figure 8 As shown, the device is applied to a second node, and the device includes:

[0296] A second sending module, used to obtain a service request of the first node;

[0297] A second receiving module, configured to perform a business transaction with the first node after sending a business proposal response to the business request;

[0298] The first node and the second node belong to the same alliance; when the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node.

[0299] It should be noted that: the billing device provided in the above embodiment only uses the division of the above program modules as an example when implementing the corresponding billing method. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the second node is divided into different program modules to complete all or part of the processing described above. In addition, the device provided in the above embodiment and the embodiment of the corresponding method belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0300] Fig. 9 A schematic diagram of the structure of another charging device provided in an embodiment of the present invention; Fig. 9 As shown, the device is applied to a third node, and the device includes:

[0301] A determination module, configured to determine at least two nodes that have completed a business transaction; generate a distributed ledger based on the completed business transaction; the distributed ledger being associated with the at least two nodes;

[0302] A third sending module is used to send the distributed ledger to the server; the distributed ledger is used by the server to update the status corresponding to the at least two nodes, and perform fee settlement according to the updated status;

[0303] The third node and the at least two nodes that complete the business transaction belong to the same alliance.

[0304] It should be noted that: the billing device provided in the above embodiment only uses the division of the above program modules as an example when implementing the corresponding billing method. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the third node is divided into different program modules to complete all or part of the processing described above. In addition, the device provided in the above embodiment and the embodiment of the corresponding method belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0305] Fig.10 A schematic diagram of a charging device according to an embodiment of the present invention is shown in FIG. Fig.10As shown, the apparatus 100 comprises: a processor 1001 and a memory 1002 for storing a computer program that can be run on the processor;

[0306] Corresponding to when the device is applied to a server, when the processor 1001 is used to run the computer program, the following is performed: determining at least one node in a blockchain network; identifying at least one node in a blockchain network and determining the node type; the node types include: first-type nodes and second-type nodes; determining the first amount of each first-type node and the second amount of each second-type node; dividing the at least one node using a preset division algorithm according to the first amount of each first-type node and the second amount of each second-type node to obtain at least one alliance that meets preset conditions; performing fee settlement for each node included in the at least one alliance; wherein the alliance that meets the preset conditions indicates that the difference between the first total amount and the second total amount corresponding to the alliance is lower than a preset threshold; the nodes in the alliance can transfer amounts to each other.

[0307] In one embodiment, the processor 1001 is also used to execute the following when running the computer program: calculating a weighted average redundancy amount as a first amount based on the historical data of each first-category node and the weight corresponding to each business cycle in the historical data; calculating a weighted average additional demand amount as a second amount based on the historical data of each second-category node and the weight corresponding to each business cycle in the historical data.

[0308] In one embodiment, the processor 1001 is further used to execute the following when running the computer program: receiving a distributed ledger sent by the alliance; the distributed ledger is associated with at least two nodes; updating the status corresponding to the at least two nodes associated with the distributed ledger according to the distributed ledger; and, according to the updated status, performing fee settlement for each node included in at least one alliance.

[0309] In one embodiment, the processor 1001 is also used to execute the following when running the computer program: obtaining historical order data corresponding to each node in the at least one node, using a preset classification model to identify the historical order data, and determining whether the corresponding node is a first-category node or a second-category node; the classification model is used to determine whether each node is a first-category node or a second-category node.

[0310] Corresponding to when the device is applied to the first node, the processor 1001 is used to run the computer program to execute: determining a business request and broadcasting the business request; after receiving a business proposal response from the second node, conducting a business transaction with the second node; the first node and the second node belong to the same alliance; when the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node.

[0311] Corresponding to when the device is applied to the second node, the processor 1001 is used to run the computer program to execute: obtaining a business request from the first node; after sending a business proposal response to the business request, conducting a business transaction with the first node; the first node and the second node belong to the same alliance; when the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node.

[0312] Corresponding to when the device is applied to the third node, the processor 1001 is used to execute the computer program to: determine at least two nodes that have completed a business transaction; generate a distributed ledger based on the completed business transaction; the distributed ledger is related to at least two nodes; send the distributed ledger to a server; the distributed ledger is used by the server to update the status corresponding to the at least two nodes, and settle fees based on the updated status; the third node and the at least two nodes that have completed the business transaction belong to the same alliance.

[0313] In actual application, the device 100 may further include: at least one network interface 1003. The various components in the device 100 are coupled together via a bus system 1004. It is understood that the bus system 1004 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 1004 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, Fig.10 In the figure, various buses are marked as bus system 1004. There may be at least one processor 1001. The network interface 1003 is used for wired or wireless communication between the apparatus 100 and other devices.

[0314] The memory 1002 in the embodiment of the present invention is used to store various types of data to support the operation of the device 100 .

[0315] The method disclosed in the above embodiment of the present invention can be applied to the processor 1001, or implemented by the processor 1001. The processor 1001 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit in the processor 1001 or the instruction in the form of software. The above processor 1001 may be a general processor, a digital signal processor (DSP, DiGital Signal Processor), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The processor 1001 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiment of the present invention. The general processor can be a microprocessor or any conventional processor, etc. In combination with the steps of the method disclosed in the embodiment of the present invention, it can be directly embodied as a hardware decoding processor to execute, or it can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium, which is located in the memory 1002. The processor 1001 reads the information in the memory 1002 and completes the steps of the above method in combination with its hardware.

[0316] In an exemplary embodiment, the device 100 can be implemented by one or more application specific integrated circuits (ASIC), DSP, programmable logic device (PLD), complex programmable logic device (CPLD), field programmable gate array (FPGA), general processor, controller, microcontroller (MCU), microprocessor, or other electronic components to execute the aforementioned method.

[0317] An embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon;

[0318] Corresponding to the computer program stored and applied to the server, when the computer program is run by the processor, the following is performed: determining at least one node in the blockchain network; identifying at least one node in the blockchain network and determining the node type; the node types include: first-type nodes and second-type nodes; determining the first amount of each first-type node and the second amount of each second-type node; dividing the at least one node using a preset division algorithm according to the first amount of each first-type node and the second amount of each second-type node to obtain at least one alliance that meets preset conditions; settling fees for each node included in the at least one alliance; wherein the alliance that meets the preset conditions indicates that the difference between the first total amount and the second total amount corresponding to the alliance is lower than a preset threshold; the nodes in the alliance can transfer amounts to each other.

[0319] In one embodiment, when the computer program is executed by the processor, it executes: based on the historical data of each first-category node and the weight corresponding to each business cycle in the historical data, a weighted average redundancy amount is calculated as a first amount; based on the historical data of each second-category node and the weight corresponding to each business cycle in the historical data, a weighted average additional demand amount is calculated as a second amount.

[0320] In one embodiment, when the computer program is executed by a processor, the computer program performs: receiving a distributed ledger sent by the alliance; the distributed ledger is associated with at least two nodes; updating the status corresponding to the at least two nodes associated with the distributed ledger according to the distributed ledger; and, according to the updated status, performing fee settlement for each node included in at least one alliance.

[0321] In one embodiment, when the computer program is executed by the processor, the following is performed: obtaining the historical ordering data corresponding to each node in the at least one node, identifying the historical ordering data using a preset classification model, and determining whether the corresponding node is a first-category node or a second-category node; the classification model is used to determine whether each node is a first-category node or a second-category node.

[0322] Corresponding to the storage of a computer program applied to a first node, when the computer program is executed by a processor, the following is performed: determining a business request and broadcasting the business request; after receiving a business proposal response from a second node, conducting a business transaction with the second node; the first node and the second node belong to the same alliance; when the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node.

[0323] Corresponding to the storage of a computer program applied to a second node, when the computer program is executed by the processor, the following is performed: obtaining a business request from the first node; after sending a business proposal response to the business request, conducting a business transaction with the first node; the first node and the second node belong to the same alliance; when the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node.

[0324] Corresponding to the computer program stored and applied to the third node, when the computer program is executed by the processor, the following is performed: determining at least two nodes that have completed the business transaction; generating a distributed ledger based on the completed business transaction; the distributed ledger is related to the at least two nodes; sending the distributed ledger to the server; the distributed ledger is used by the server to update the status corresponding to the at least two nodes, and settle fees based on the updated status; the third node and the at least two nodes that have completed the business transaction belong to the same alliance.

[0325] In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented in other ways. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored, or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0326] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0327] In addition, all functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may be separately used as a unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0328] A person skilled in the art can understand that: all or part of the steps of implementing the above method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), disks or optical disks, etc. Various media that can store program codes.

[0329] Alternatively, if the above-mentioned integrated unit of the present invention is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present invention can be essentially or partly reflected in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROM, RAM, magnetic disks or optical disks.

[0330] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims

1. A charging method, characterized in that: Applied to a server, the method comprises: Identifying at least one node in a blockchain network; Identify at least one node in the blockchain network and determine the node type; the node type includes: a first type node and a second type node; wherein the first type node is a transferor and the second type node is a borrower, or the second type node is a transferor and the first type node is a borrower; Determine a first quota for each node of the first category, and determine a second quota for each node of the second category; divide the at least one node using a preset division algorithm according to the first quota for each node of the first category and the second quota for each node of the second category, to obtain at least one alliance that meets preset conditions; Performing fee settlement for nodes included in each of the at least one alliance; Among them, the alliance that meets the preset conditions represents that the difference between the first total amount and the second total amount corresponding to the alliance is lower than the preset threshold, the first total amount includes the sum of the first amount of all first-category nodes corresponding to the alliance, and the second total amount includes the sum of the second amount of all second-category nodes corresponding to the alliance; the nodes in the alliance can transfer amount to each other.

2. The method according to claim 1, characterized in that The determining of the first quota of each of the first-type nodes and the determining of the second quota of each of the second-type nodes includes: Calculate a weighted average redundancy amount based on the historical data of each of the first-type nodes and the weight corresponding to each business cycle in the historical data as a first amount; Based on the historical data of each of the second-category nodes and the weight corresponding to each business cycle in the historical data, a weighted average additional demand quota is calculated as the second quota.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: Receiving a distributed ledger sent by the alliance; the distributed ledger is associated with at least two nodes; updating states corresponding to the at least two nodes associated with the distributed ledger according to the distributed ledger; The performing fee settlement on the nodes included in each of the at least one alliance comprises: According to the updated status, fee settlement is performed for nodes included in each of the at least one alliance.

4. The method according to claim 1, characterized in that: The step of identifying at least one node in the blockchain network and determining the node type includes: Acquire historical data corresponding to each node in the at least one node, identify the historical data using a preset classification model, and determine whether the corresponding node is a first-category node or a second-category node; The classification model is used to determine whether each node is a first-category node or a second-category node.

5. A charging method, characterized in that: Applied to the first node, the method comprises: Determine a business request, and broadcast the business request; the business request includes a transfer transaction request or a lease transaction request; After receiving the business proposal response from the second node, conducting a business transaction with the second node; The first node and the second node belong to the same alliance; when the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node; wherein, the first-type node is the transferor and the second-type node is the borrower, or the second-type node is the transferor and the first-type node is the borrower; the difference between the first total amount and the second total amount corresponding to the alliance to which the first node and the second node belong is lower than a preset threshold, the first total amount includes the sum of the first amounts of all first-type nodes corresponding to the alliance, and the second total amount includes the sum of the second amounts of all second-type nodes corresponding to the alliance.

6. A charging method, characterized in that: Applied to the second node, the method comprises: Acquire a business request of the first node; the business request includes a transfer transaction request or a lease transaction request; After sending a business proposal response to the business request, performing a business transaction with the first node; The first node and the second node belong to the same alliance; when the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node; wherein, the first-type node is the transferor and the second-type node is the borrower, or the second-type node is the transferor and the first-type node is the borrower; the difference between the first total amount and the second total amount corresponding to the alliance to which the first node and the second node belong is lower than a preset threshold, the first total amount includes the sum of the first amounts of all first-type nodes corresponding to the alliance, and the second total amount includes the sum of the second amounts of all second-type nodes corresponding to the alliance.

7. A charging method, characterized in that: Applied to the third node, the method includes: Determine at least two nodes for completing the business transaction; Generate a distributed ledger based on the completed business transaction; the distributed ledger is associated with at least two nodes; Sending the distributed ledger to a server; the distributed ledger is used by the server to update the states corresponding to the at least two nodes, and to settle fees according to the updated states; The third node and the at least two nodes that complete the business transaction belong to the same alliance; wherein, the difference between the first total amount and the second total amount corresponding to the alliance to which the third node and the at least two nodes that complete the business transaction belong is lower than a preset threshold, the first total amount includes the sum of the first amounts of all first-type nodes corresponding to the alliance, and the second total amount includes the sum of the second amounts of all second-type nodes corresponding to the alliance; the first-type node is the transferor and the second-type node is the lessee, or the second-type node is the transferor and the first-type node is the lessee.

8. A charging device, characterized in that: Applied to a server, the device comprises: A first processing module, configured to determine at least one node in a blockchain network; A second processing module is used to identify at least one node in the blockchain network and determine the node type; the node type includes: a first type node and a second type node; wherein the first type node is a transferor and the second type node is a borrower, or the second type node is a transferor and the first type node is a borrower; A third processing module is used to determine a first quota of each of the first-type nodes and a second quota of each of the second-type nodes; and to divide the at least one node using a preset division algorithm according to the first quota of each of the first-type nodes and the second quota of each of the second-type nodes, so as to obtain at least one alliance that meets a preset condition; A fourth processing module, used for performing fee settlement for nodes included in each of the at least one alliance; Among them, the alliance that meets the preset conditions represents that the difference between the first total amount and the second total amount corresponding to the alliance is lower than the preset threshold, the first total amount includes the sum of the first amounts of all first-type nodes corresponding to the alliance, and the second total amount includes the sum of the second amounts of all second-type nodes corresponding to the alliance.

9. The device according to claim 8, characterized in that The third processing module is used to calculate a weighted average redundancy quota as a first quota based on the historical data of each of the first-type nodes and the weight corresponding to each business cycle in the historical data; Based on the historical data of each of the second-category nodes and the weight corresponding to each business cycle in the historical data, a weighted average additional demand quota is calculated as the second quota.

10. The device according to claim 8 or 9, characterized in that The fourth processing module is further configured to receive a distributed ledger sent by the alliance; the distributed ledger is associated with at least two nodes; updating states corresponding to the at least two nodes associated with the distributed ledger according to the distributed ledger; Correspondingly, the fourth processing module is used to settle fees for each node included in at least one alliance according to the updated status.

11. The device according to claim 8, characterized in that The second processing module is used to obtain the historical order data corresponding to each node in the at least one node, identify the historical order data using a preset classification model, and determine whether the corresponding node is a first-type node or a second-type node; The classification model is used to determine whether each node is a first-category node or a second-category node.

12. A charging device, characterized in that: Applied to a first node, the device comprises: A first sending module, used for determining a business request and broadcasting the business request; the business request includes a transfer transaction request or a lease transaction request; A first receiving module, configured to perform a business transaction with the second node after receiving a business proposal response from the second node; The first node and the second node belong to the same alliance; when the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node; wherein, the first-type node is the transferor and the second-type node is the borrower, or the second-type node is the transferor and the first-type node is the borrower; the difference between the first total amount and the second total amount corresponding to the alliance to which the first node and the second node belong is lower than a preset threshold, the first total amount includes the sum of the first amounts of all first-type nodes corresponding to the alliance, and the second total amount includes the sum of the second amounts of all second-type nodes corresponding to the alliance.

13. A charging device, characterized in that: Applied to a second node, the device comprises: A second sending module is used to obtain a business request of the first node; the business request includes a transfer transaction request or a lease transaction request; A second receiving module, configured to perform a business transaction with the first node after sending a business proposal response to the business request; The first node and the second node belong to the same alliance; when the first node is a first-type node, the second node is a second-type node; when the second node is a first-type node, the first node is a second-type node; wherein, the first-type node is the transferor and the second-type node is the borrower, or the second-type node is the transferor and the first-type node is the borrower; the difference between the first total amount and the second total amount corresponding to the alliance to which the first node and the second node belong is lower than a preset threshold, the first total amount includes the sum of the first amounts of all first-type nodes corresponding to the alliance, and the second total amount includes the sum of the second amounts of all second-type nodes corresponding to the alliance.

14. A charging device, characterized in that: Applied to a third node, the device comprises: A determination module, configured to determine at least two nodes that have completed a business transaction; generate a distributed ledger based on the completed business transaction; the distributed ledger being associated with the at least two nodes; A third sending module is used to send the distributed ledger to the server; the distributed ledger is used by the server to update the status corresponding to the at least two nodes, and perform fee settlement according to the updated status; The third node and the at least two nodes that complete the business transaction belong to the same alliance; wherein, the difference between the first total amount and the second total amount corresponding to the alliance to which the third node and the at least two nodes that complete the business transaction belong is lower than a preset threshold, the first total amount includes the sum of the first amounts of all first-type nodes corresponding to the alliance, and the second total amount includes the sum of the second amounts of all second-type nodes corresponding to the alliance; the first-type node is the transferor and the second-type node is the lessee, or the second-type node is the transferor and the first-type node is the lessee.

15. A charging device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the steps of the method according to any one of claims 1 to 4 are implemented; or, When the processor executes the program, the steps of the method according to claim 5 are implemented; or, When the processor executes the program, the steps of the method according to claim 6 are implemented; or, When the processor executes the program, the steps of the method according to claim 7 are implemented.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 4 are implemented; or When the computer program is executed by a processor, the steps of the method according to claim 5 are implemented; or When the computer program is executed by a processor, the steps of the method according to claim 6 are implemented; or When the computer program is executed by a processor, the steps of the method according to claim 7 are implemented.

Images