Trust-based delegated consensus blockchain network management device and method

Abstract

This invention relates to a ratio of delegated nodes selected based on trust levels and the delegated nodes themselves, thereby improving TPS while maintaining or enhancing security, and adjusting the selection so that the same node is not over-selected as a delegated node to meet decentralization constraints. Therefore, it provides a delegated consensus blockchain network management apparatus and method that enables stable utilization of blockchain in environments such as IIoT networks that generate large-scale transactions and need to be processed within limited service hours.

Description

Technical Field

[0001] This invention relates to a blockchain network management device and method, and a trust-based delegated consensus blockchain network management device and method. Background Technology

[0002] Blockchain provides transparency and security for data management systems and can be applied in various industrial sectors (such as energy trading, smart factories, and resource management). However, when combining blockchain with Industrial Internet of Things (IIoT) networks that generate massive amounts of real-time data based on multiple applications, the database storage blockchain system must meet stringent Quality of Service (QoS) requirements. Particularly in blockchain-enabled real-time IIoT networks, the issue of low processing volume during the consensus process needs to be addressed.

[0003] Bitcoin and Ethereum, as typical blockchain systems, are designed to support 3-4 and 14 transactions per second (TPS), respectively, which is significantly slower than the data generation speed of IIoT networks and the volume of credit card processing. To address this low TPS issue, more advanced and scalable blockchain technologies are needed. Several blockchains have been proposed to improve scalability based on these requirements. However, existing scalability-enhancing technologies have a problem: the influence of malicious nodes may increase, potentially leading to a decrease in security.

[0004] In other words, according to the blockchain trilema, blockchain systems have the limitation of not being able to simultaneously improve all three characteristics of blockchain (decentralization, security, and scalability). Therefore, there is a need for solutions that can improve TPS (transactions per second) while maintaining or enhancing security in order to improve blockchain scalability.

[0005] [Existing Technical Documents]

[0006] [Patent Documents]

[0007] Korean Patent Publication No. 10-2020-010660 (published on September 15, 2020) Summary of the Invention

[0008] Technical issues

[0009] The purpose of this invention is to provide a trust-based delegated consensus blockchain network management device and method that improves TPS while maintaining or enhancing security, thereby improving the scalability of the blockchain.

[0010] Another objective of this invention is to provide a delegated consensus blockchain network management device and method that can simultaneously satisfy decentralization constraints by selecting the ratio of delegated nodes based on trust levels and the delegated nodes.

[0011] Technical solution

[0012] The delegated consensus blockchain network management device of this embodiment, used to achieve the above objectives, acquires state information including the trust level of each delegated node in the blockchain network, performs neural network operations on the state information to determine actions including the delegation rate, generates a Local Trust Opinion (LTO) matrix representing the subjective evaluation between each delegated node based on the determined actions, and selects K delegated nodes from N nodes based on the trust level calculated using the LTO matrix and the determined delegation rate.

[0013] The delegated consensus blockchain network management device can aggregate the delegated consensus results (DCR) records of permission messages regarding agreement or disagreement propagated from the nodes during the Practical Byzantine Fault Tolerance (PBFT) consensus process collected by the selected delegated nodes to generate the LTO matrix.

[0014] The processor of the delegated consensus blockchain network management device can calculate the trust level of the delegated node by calculating the average subjective trust value and trust approximation of each delegated node based on the LTO matrix.

[0015] In addition to the trust level of each delegate node, the delegate consensus blockchain network management device can also obtain the data transmission rate between delegate nodes, the computing resources of each delegate node, the number of times a delegate node participates in the delegate consensus, and the probability of a malicious delegate node being selected as a delegate node, which represents the probability that the calculated trust level is below a pre-specified trust level threshold. The state information is used as the state.

[0016] The delegated consensus blockchain network management device can calculate the delay representing the time until a transaction becomes irreversible after being applied to the blockchain network and undergoes the consensus process, and determine the delay based on the delay condition of u consecutive block intervals.

[0017] The determination is based on a security condition where the proportion of malicious nodes among the delegated nodes participating in consensus according to the PBFT condition is less than a pre-specified delegation rate. The Gini coefficient is calculated to represent the degree of imbalance in the number of times N nodes are selected as delegated nodes. The determination is based on a Gini coefficient condition where the Gini coefficient does not exceed a pre-specified decentralization threshold. The compensation is calculated if the determined action satisfies the delay condition, the security condition, and the Gini coefficient condition.

[0018] The processor of the delegated consensus blockchain network management device can determine whether the latency condition, the security condition, and the Gini coefficient condition are met, while maximizing the block size (B) and block interval (T) that achieve the highest TPS (Transactions Per Second). I) and commission rate To determine the action (A) t ).

[0019] To achieve the aforementioned objective, a delegated consensus blockchain network management method according to one embodiment includes the steps of: obtaining state information including the trust levels of each delegated node in the blockchain network; performing neural network operations on the state information to determine actions including the delegation rate; generating a Local Trust Opinion (LTO) matrix representing the mutual subjective evaluations of each delegated node based on the determined actions; and...

[0020] The step of selecting K delegate nodes from N nodes based on the trust level calculated using the LTO matrix and the determined delegate rate.

[0021] Technical effect

[0022] Therefore, the delegated consensus blockchain network management device and method according to embodiments of the present invention, by selecting the ratio of delegated nodes and the delegated nodes based on trust levels, can improve TPS while maintaining or improving security, and adjust the selection so that the same node is not over-selected as a delegated node, thus satisfying the decentralization constraint. Therefore, it enables stable utilization of blockchain even in environments like IIoT networks that require generating large-scale transactions and processing them within limited service time. Attached Figure Description

[0023] Figure 1 This illustrates a simplified structure of a blockchain network based on delegated consensus in an IIoT network environment.

[0024] Figure 2 This illustrates an example of a consensus process using the PBFT consensus algorithm.

[0025] Figure 3 A simplified structure of multiple nodes in a delegated consensus blockchain network according to an embodiment of the present invention is shown.

[0026] Figure 4 A simplified structure of a network management device according to an embodiment of the present invention is shown.

[0027] Figure 5 Show Figure 4 This is an example of the specific structure of the environmental analysis module.

[0028] Figure 6 For illustrative purposes Figure 5 The attached diagram shows the method by which the trust calculation module calculates trust based on the delegated consensus results.

[0029] Figure 7 This illustrates a delegated consensus blockchain network management method according to one embodiment.

[0030] Figure 8 The accompanying drawings are for illustrating a computing environment including computation according to one embodiment.

[0031] Explanation of reference numerals in the attached figures

[0032] 10: IIoT Network; 20: Blockchain Network

[0033] 110: Communication module; 120: Control module

[0034] 130: Block generation module; 140: Block verification module

[0035] 150: Delegated Consensus Module; 160: Block Storage Module

[0036] 170: Delegated Setup Module; 210: Memory Module

[0037] 220: Proxy Module 230: Environment Analysis Module

[0038] 310: Trust Evaluation Department; 311: LTO Generation Module

[0039] 312: Trust Calculation Module; 313: Malicious Delegation Probability Calculation Module

[0040] 320: Delay Calculation Module; 330: Security Analysis Module

[0041] 340: Gini coefficient calculation module; 350: Compensation calculation module Detailed Implementation

[0042] To fully understand the present invention, its advantages, and the objectives achieved by practicing it, reference should be made to the accompanying drawings illustrating preferred embodiments of the invention and the contents described therein.

[0043] The preferred embodiments of the present invention are described below with reference to the accompanying drawings to illustrate the invention in detail. However, the present invention can be implemented in many different ways and is not limited to the embodiments described. Furthermore, parts unrelated to the description are omitted for clarity, and the same reference numerals in the drawings indicate the same parts.

[0044] When the entire specification mentions that a certain part "includes" a certain component, it does not exclude other components unless specifically stated otherwise; rather, it indicates that other components may also be included. Furthermore, terms such as "...part," "...device," "module," and "block" used in the specification indicate a unit that performs at least one function or operation, which can be implemented through hardware, software, or a combination of both.

[0045] Figure 1This illustrates a simplified structure of a blockchain network based on delegated consensus in an IIoT network environment.

[0046] Reference Figure 1 In an IIoT network 10 equipped with various IIoT devices such as smart factories, smart homes, robots, transportation vehicles, and monitoring devices, each device performs designated tasks and communicates with each other to generate various transactions such as data storage and data sharing. Furthermore, a large number of these transactions are transmitted to a blockchain network 20.

[0047] Blockchain network 20 receives transactions from IIoT network 10 and stores them in blocks that act as a distributed ledger for trusted data management. As mentioned above, in existing blockchain networks, all nodes, called miners or validators, participate in a consensus process to verify the transmitted transactions. In this case, a large number of transactions are imposed from IIoT network 10, and a large number of nodes participate in the consensus process, thus increasing the time required to reach consensus and making it impossible to process transactions within the required service time.

[0048] In this regard, the delegated consensus blockchain network 20 of this embodiment enables only a portion of the nodes, rather than all nodes, to participate in the consensus process as delegated nodes 21 for transactions imposed from the IIoT network 10, thereby significantly improving the transaction processing speed (Transactions Per Second: hereinafter TPS).

[0049] In this embodiment, the network management device can improve the TPS of the delegated consensus blockchain network 20 based on its state, ensuring that the security of the blockchain network is maintained or further improved despite the increased TPS. That is, the scalability of the blockchain network can be improved by optimizing it. Specifically, the network management device in this embodiment learns through Deep Reinforcement Learning (DRL) and adaptively optimizes the blockchain network based on its state for management.

[0050] Here, we assume that the delegated consensus blockchain network 20 contains N (N is a natural number) nodes. Furthermore, based on the delegation rate among the N nodes (… in ) Use K (of which Nodes whose value is a function of the largest integer (K) participate in the consensus process as delegate nodes 21. These K delegate nodes 21 form the delegate node set (N). D ,in The element of ). Here, the delegation rate The node selected as delegate node 21 from among multiple nodes is determined by the network management device through deep reinforcement learning, which will be explained in detail later.

[0051] Furthermore, in this embodiment, the delegated consensus blockchain network 20 utilizes the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm as its consensus algorithm. The PBFT consensus algorithm utilizes low computational resources and has a fast consensus speed, making it suitable for scalable IIoT networks 10.

[0052] For ease of explanation, the IIoT network 10 and the blockchain network 20 have been distinguished above, but multiple IIoT devices in the IIoT network 10 can function as nodes in the blockchain network 20. Furthermore, the network management device can be included in at least one of the multiple nodes.

[0053] Figure 2 This illustrates an example of a consensus process using the PBFT consensus algorithm.

[0054] Reference Figure 2 The PBFT consensus algorithm consists of a pre-prepare step, a prepare step, a commit step, and a reply step.

[0055] As an example, Figure 2 The algorithm illustrates the process of executing a consensus flow from K delegate nodes 21 selected from a delegated consensus blockchain network 20 comprising N nodes. One of the K delegate nodes 21 is the primary node, which is the block builder that generates blocks based on transaction requests. The remaining nodes are replica nodes, which are validators that perform consensus verification on the blocks generated by the block builder. One of the K delegate nodes may be randomly selected as the block builder.

[0056] In the PBFT consensus algorithm, the block builder collects transactions generated by the IIOT network and generates blocks according to blockchain parameters. The block builder generates blocks of size M based on M requests with a pre-specified batch size. In the pre-preparation step, the block builder transmits the generated blocks to the validators and requests verification. Here, the block builder generates Message Authentication Codes (MACs) corresponding to K-1 validators and transmits them to the validators to request verification.

[0057] In the preparation step, upon receiving a block from the block builder, each validator performs a MAC operation and propagates a confirmation message to other validators. Next, in the permission step, each validator verifies the validity of the transmitted block and propagates a commit message. A valid block is defined as one whose Herder content and transaction list have not been forged and whose hash value has not been modified. In the permission step, each validator generates a message indicating agreement ("Yea") or disagreement ("Nay") as a verification result of the block generation and transmits it to other validators. In the response step, multiple validators, upon receiving a consent message ("Yea") from more than two-thirds of all validators (including themselves), determine that the block is valid and connect to the chain of the produced block, replying to the block builder with the blockchain consensus result. Furthermore, all nodes in the delegated consensus blockchain network 20 can confirm the result of the delegated consensus.

[0058] As described above, in this embodiment, K delegate nodes 21 out of N nodes execute the consensus process according to the PBFT consensus algorithm.

[0059] The following explains the composition of multiple nodes in the delegated consensus blockchain network 20.

[0060] Figure 3 A simplified structure of multiple nodes in a delegated consensus blockchain network according to an embodiment of the present invention is shown.

[0061] Reference Figure 3 The multiple nodes of the blockchain network 20 may include a communication module 110, a control module 120, a block generation module 130, a block verification module 140, a delegated consensus module 150, and a block storage module 160, respectively.

[0062] The communication module 110 enables the network management device to communicate with other nodes on the delegated consensus blockchain network 20. Furthermore, the control module 120 not only controls the internal data transmission between the constituent elements of the control node, but also controls the sending and receiving of data with other nodes through the communication module 110.

[0063] When a node is selected as a block builder, the block generation module 130 collects transaction-generating blocks from the IIIOT network 10. As described above, the block builder can be randomly selected by the blockchain network management device. The generated blocks are then propagated to validators, which are other delegating nodes in the blockchain network, via the communication module 110. The generated blocks are as follows: Figure 2A block is declared the final block and connected to the previously stored blockchain on each node when it receives more than two-thirds of the TD-PBFT (Trust-based Delegated PBFT) consensus process of multiple delegated nodes in the Delegated Consensus Blockchain Network 20.

[0064] When a delegated node selected as a block builder generates and propagates a block, the block verification module 140 transmits a confirmation message to other delegated nodes in the blockchain network via the communication module 110. It also verifies the validity of the transmitted block and generates a permission message indicating agreement (“Yea”) or disagreement (“Nay”) as the verification result, and propagates the generated permission message to other validators.

[0065] The delegated consensus module 150 gathers its own permission messages as verification results and permission messages propagated from other validators to derive the delegated consensus result (DCR). Here, as... Figure 6 As shown in (a), the aggregated permission messages can be referred to as DCR records. The delegated consensus module 150 aggregates its own permission messages and permission messages propagated from other validators to obtain DCR records. If more than 2 / 3 of the validators in the obtained DCR records have transmitted permission messages regarding agreement (“Yea”), the block generated as a result of the delegated consensus is determined to be a valid block.

[0066] Block storage module 160 receives blocks deemed valid by delegated consensus module 150 and stores them. Here, block storage module 160 links the applied block to the previously stored blockchain for storage. Furthermore, the stored blockchain can be propagated to other nodes in the blockchain network.

[0067] Additionally, the delegated consensus blockchain network 20 in this embodiment may also include a network management device for improving the TPS of the blockchain network. The network management device uses the delegation rate, which is the ratio of delegated nodes among multiple nodes, as its function. The system is configured to satisfy the blockchain network's trilemma of security and decentralization while maximizing TPS to improve scalability, based on the set delegation rate. Select delegate node 21.

[0068] Figure 4 A simplified structure of a network management device according to an embodiment of the present invention is shown. Figure 5 Show Figure 4 An example of the specific components of an environmental analysis module. Figure 6 For illustrative purposes Figure 5 The attached diagram shows the method by which the trust calculation module calculates trust based on the delegated consensus results.

[0069] The network management device can be configured as a separate device independent of the multiple nodes of the delegated consensus blockchain network 20, but at least one of the multiple nodes can also function as the network management device. Furthermore, when a node of the delegated consensus blockchain network 20 operates as the network management device, that node... Figure 3 As shown, it may also include a delegated settings module 170.

[0070] In this embodiment, the network management device (or delegated setting module 170) can be implemented as an artificial neural network that has been pre-learned through deep reinforcement learning (DRL). As an example, in this embodiment, the network management device can be based on Rainbow Deep Q Network (DRL), an artificial neural network learned through DRL.

[0071] Reference Figure 4 The network management device (or delegated setting module 170) may include a memory module 210, an agent module 220, and an environment analysis module 230.

[0072] Memory module 210 serves as the environment matching storage for the trust-based delegated consensus blockchain network 20, storing the state information (S) corresponding to each Epoch(t). t ) and corresponding state information (S) t ) action (A t Agent module 220 determines based on status information (S) t ) action (A t The environmental analysis module 230 is based on state information (S). t ) and based on state information (S t ) Determined action (A) t ) Calculate the next state information (S) t+1 ) and the corresponding next state information (S t+1 Compensation (R) t ).

[0073] First, the environmental analysis module 230 calculates the next state information (S). t+1 ) and compensation (R t ), can be like Figure 5 It includes a trust evaluation module 310, a delay calculation module 320, a security analysis module 330, a Gini coefficient calculation module 340, and a compensation calculation module 350.

[0074] The trust evaluation module 310 calculates the trust level for each of the multiple nodes. The latency calculation module 320, security analysis module 330, and Gini coefficient calculation module 340 calculate latency, security, and the Gini coefficient to respectively consider the scalability, security, and decentralization trilemmas of a blockchain network. Furthermore, the compensation calculation module 350 is based on a determined action (A... t According to the next state information (S) t+1 Does it meet the respective conditions regarding delay, safety, and Gini coefficient for calculating compensation (R)? t ).

[0075] The trust evaluation module 310 collects DCR records exported from multiple delegate nodes, generates a Local Trust Opinion (LTO) matrix representing the subjective evaluations between multiple delegate nodes based on the collected DCR records, and evaluates the trust level of each of the multiple nodes based on the generated LTO matrix.

[0076] The trust evaluation module 310 may include an LTO generation module 311, a trust calculation module 312, and a malicious delegation probability calculation module 313.

[0077] LTO generation module 311 gathers DCR records obtained from multiple delegate nodes to generate an LTO matrix. Each row in the LTO matrix represents the delegate node that performed the subjective evaluation of the delegate nodes, indicating the delegate node that generated the DCR record. Each column represents the delegate node that was evaluated, indicating the delegate node whose transmission permission message is included in the DCR record. That is, each element in the LTO matrix (L... i，j Let represent the degree of subjective trust that delegating node (i) has in delegating node (j). Here, i and j are the delegating node identifiers, and represent the position coordinates of the LTO matrix (i, j ∈ [1, 2, ..., K]). Each element of the LTO matrix (L... i，j It can be calculated according to mathematical formula 1.

[0078]

Mathematical Formula 1

[0079]

[0080] Where, Σ i (Yea) and Σ i (Nay) represent the number of agree ("Yea") and disagree ("Nay") messages in the DCR of the delegating node (i), respectively. As an example, when delegating node (i) receives a permission message from delegating node (j) with agree ("Yea") messages, and the percentage of agree ("Yea") messages in the DCR of delegating node (i) is 75%, the elements (L) of the calculated LTO matrix are... i，j The value is 0.75.

[0081] After generating the LTO matrix, the trust calculation module 312 calculates the trust level for each of the multiple delegation nodes based on the generated LTO matrix. Here, the delegation setting module 170 can calculate the average subjective trust value (μ) and trust similarity (ν) for each delegation node from the LTO matrix.

[0082] The average subjective trust value represents the average subjective trust level of multiple delegated nodes in their evaluation of a specific delegated node (i), and the trust approximation (ν) represents the approximation between the subjective evaluations of each delegated node in their evaluation of multiple delegated nodes.

[0083] Trust calculation module 312 can calculate the average subjective trust value (μ) for the delegate node (i) according to mathematical formula 2. i ).

[0084]

Mathematical Formula 2

[0085]

[0086] (where L) j，i This represents the (j, i) element of the LTO matrix.

[0087] The average subjective trust value (μ) of formula 2 i The ') indicates that the delegating node (i) submitted an accurate permission message during block verification. If a valid block is generated, a normal delegating node transmits a permission message of agreement ("Yea"). A malicious delegating node, however, transmits a permission message of disagreement ("Nay"). When a malicious delegating node transmits a permission message of disagreement ("Nay"), the ratio of disagreement ("Nay") to agreement ("Yea") is smaller, therefore the average subjective trust value (μ) for that malicious node is lower. i The result will be lower.

[0088] Alternatively, the trust approximation (ν) of the row vectors in the LTO matrix can be calculated as shown in Equation 3 to obtain the average of the cosine approximations of the delegate node (i). i ).

[0089]

Mathematical Expression 3

[0090]

[0091] Where ||·|| is the absolute value function, L i and L jLet represent the i-th and j-th row vectors of the LTO matrix, respectively. The trust approximation (ν) can be used to penalize delegate node 21 forging DCR records. In the case where a malicious node forges permission messages to generate DCR records to lower the trust level of normal nodes, the trust approximation (ν) in Equation 3... i It will decrease.

[0092] Furthermore, the trust calculation module 312, as shown in Formula 4, calculates the average subjective trust value (μ) according to Formulas 2 and 3. i ) and trust approximation (ν i Calculate the trust level (τ) of each delegate node.

[0093]

Mathematical Expression 4

[0094] τ i =μ i ν i

[0095] That is, the trust calculation module 312 uses the LTO matrix to reduce the average subjective trust value (μ) when a malicious delegate node forges a permission message as a result of block verification, and to reduce the trust approximation (ν) when a DCR record obtained by collecting permission messages is forged, thereby reducing the trust value (τ) about the malicious delegate node and increasing the trust value (τ) when a normal delegate node transmits normal permission messages and DCR records.

[0096] In this embodiment, the network management device (or delegation setting module 170) can select a delegation node with different probabilities based on the trust level (τ) of each of the multiple nodes. That is, it can increase the probability that a node with a high trust level (τ) is selected as a delegation node and decrease the probability that a node with a low trust level (τ) is selected as a delegation node, thereby reducing the possibility that a malicious node is selected as a delegation node.

[0097] The initial trust level (τ) of multiple nodes can be set to 0.5 (τ = 0.5).

[0098] In addition, the malicious delegation probability calculation module 313 can infer that a malicious node may be included in the delegation node set (N). D The probability of ) is calculated. Nodes with a trust level (τ) below a pre-specified trust threshold (ψ) are considered malicious nodes. Assuming the initial trust level (τ) of each node is set to 0.5, as mentioned above, when calculating trust level, the trust level (τ) of normal nodes increases, while the trust level (τ) of malicious nodes decreases. Therefore, nodes with a trust level (τ) less than 0.5 can be considered malicious nodes.

[0099] Furthermore, it is possible to calculate, as shown in mathematical formula 5, that malicious nodes may be included in the set of delegated nodes (N). DMalicious node delegation probability

[0100]

Mathematical Expression 5

[0101]

[0102] Where n(·) is a counting function that counts the number of conditions that satisfy (·).

[0103] That is, the probability of malicious node delegation. Indicates relative to the commission rate The number of delegate nodes (K) is contained in the set of delegate nodes (N). D Trust level (τ) in nodes i ) is below the threshold value (ψ) (τ) i The ratio of the number of nodes ≤ψ).

[0104] Furthermore, the delegated consensus blockchain network 20 according to this embodiment should be scalable enough to achieve the required TPS performance even as the number of nodes increases. The TPS performance analysis used to ensure scalability should simultaneously consider the latency during message exchange between delegated nodes and the validity checks of blocks. Moreover, the scalability of the blockchain network 20 and the decentralization and security inherent in the trilemma also need to be considered.

[0105] In this regard, the conditions for TPS used for scalability should be considered first. To take into account the conditions for TPS, the delay calculation module 320 calculates the delay (T) representing the time from when a transaction is applied to the blockchain network 20 until it becomes irreversible through the consensus process. latency ).

[0106] Assuming that when the block builder in blockchain network 20 generates a B-byte block including an H-byte block header, the maximum TPS can be calculated as shown in mathematical formula 6.

[0107]

Mathematical Expression 6

[0108]

[0109] Where T I 'b' represents the block generation interval, and 'b' represents the average transaction size.

[0110] Delay (T) latency The time required for a transaction to be applied to the blockchain network and connected to the blockchain is the block generation interval (T). I ) and consensus time (T) consensus The sum of ) . Consensus time (T) consensus The validity check time (T) can be reused. v ) and message transmission time (T) pThe sum of ) represents the delay, therefore the delay calculation module 320 can use mathematical formula 7 to calculate the delay (T). latency ).

[0111]

Mathematical Expression 7

[0112] T latency =T I +T consensus

[0113] =T I +T v +T p

[0114] In the aforementioned TP-PBFT delegated consensus process, one of the K delegate nodes is a block constructor, and the remaining K-1 delegate nodes act as validators. Therefore, the validity check time (T) in Equation 7 is... v The computation can be divided into block constructors and verifiers.

[0115] The block builder generates M blocks of size and propagates them to the validators. Therefore, during the consensus process, the block builder should perform a total of M signature verifications and 2M+4(K-1) message authentication code (MAC) generation or verification tasks. Furthermore, the validators should perform M signature verifications and M+4(K-1) message authentication code (MAC) verification tasks.

[0116] Therefore, mathematical formulas 8 and 9 can be used to calculate the validity check time (T) for the block constructor and validator, respectively. v _ bp T v _ val ).

[0117]

Mathematical Expression 8

[0118]

[0119]

Mathematical Expression 9

[0120]

[0121] Where θ represents the CPU cycles required for signature verification, α represents the CPU cycles required for message authentication code generation or verification, and c bp and c i represents the computational resources of the block constructor and the i-th verifier, respectively, and represents the computational speed.

[0122] Furthermore, the block builder and validator can perform validity checks independently, therefore the validity check time (T) is reduced. v ) is the validity check time for the block constructor and validator (T) v_bp T v_valThe maximum value in () can be calculated as shown in mathematical formula 10.

[0123]

Mathematical Formula 10

[0124]

[0125] Additionally, message transmission time (T) p ) indicates that the message is based on Figure 2 The diagram illustrates the time (T) required to reach each stage of the consensus process (Pre-prepare, Prepare, Commit, Reply). Pre-prepare T Prepare T Commit T Reply The sum of (T) p =T Pre-prepare +T Prepare +T Commit +T Reply To prevent unresponsive nodes (nodes that do not transmit messages) from causing excessive delays in the consensus process, a time limit (ζ) can be set for each step.

[0126] In this regard, the message transmission time (T) can be calculated according to mathematical formula 11. p ).

[0127]

Mathematical Expression 11

[0128]

[0129] Here, the subscript bp represents the block constructor, and client represents an undelegated node. And R i，j It is the data transfer rate during message exchange between delegate node i and delegate node j, which can be quantified into r levels (R = {R1, R2, ..., R...}). r}) represents the state transition probability matrix ([p) when assuming the application of a finite-state Markov channel model. R (t)] r×r (p can be used) R (t)=Pr[R i，j (t+1)=R b |R i，j (t)=R a The calculation is obtained. Pr[] is the conditional probability function, R a R b ∈R.

[0130] However, based on the characteristics of blockchain, it should be within u consecutive block intervals (uT).I The transaction consensus process is completed within a certain timeframe. Therefore, the delay (T) is calculated in the delay calculation module 320 using mathematical formula 7. latency It should satisfy mathematical expression 12.

[0131]

Mathematical Expression 12

[0132] T latency =T I +T v +T p ≤uT I

[0133] In addition, the security analysis module 330, as is known in the PBFT consensus algorithm in terms of security, can execute consensus normally when there are f malicious nodes among the N nodes participating in the consensus and the security condition (3f+1)≤N is met.

[0134] However, in the delegated consensus blockchain network of this embodiment, K nodes out of N nodes participate in the consensus process as delegated nodes. Therefore, the delegation rate should be determined at the level of satisfying the security conditions of PBFT.

[0135] The rate of delegation for ensuring security In this case, assuming the probability of each node being malicious is p, the worst-case scenario can be considered where all malicious nodes are selected as delegate nodes. To ensure security even in this worst-case scenario, based on the delegation rate... Number of selected delegate nodes It should exceed three times the number of malicious nodes (Np) out of all nodes (N) based on probability (p). And since the maximum delegation rate is 1, therefore the delegation rate... The range should be set to satisfy mathematical expression 13.

[0136]

Mathematical Expression 13

[0137]

[0138] However, as mentioned above, according to the commission rate of mathematical formula 13 The scope is to take into account all malicious nodes, including the set of delegated nodes (N). D The result is calculated based on the worst-case scenario. In the trust-based delegated consensus blockchain network 20 of this embodiment, the delegated node is selected based on the trust level of each of the multiple nodes; therefore, malicious nodes are not included in the delegated node set (N). D The probability is high.

[0139] Therefore, it is necessary to consider not all nodes, but the set of delegating nodes (N). DThe probability (p) of the delegated node being a malicious node included in ) d Modify mathematical expression 13. This can be achieved by considering the number of delegate nodes. The weighted probability of a malicious node (p) d )calculate Get the set of nodes (N) D The number of malicious nodes, and thus the delegation rate in a trust-based delegated consensus blockchain network 20 according to security conditions. The range should be determined to satisfy mathematical expression 14.

[0140]

Mathematical Expression 14

[0141]

[0142] The conditions regarding TPS for scalability in the trilemma used in blockchain networks and the delegation rate for security were confirmed. After determining the conditions, it is necessary to confirm the conditions used for decentralization.

[0143] Various methods for measuring the decentralization of a blockchain network 20 are known, but unlike existing technologies, this paper utilizes the Gini coefficient, an indicator used in various fields to assess the level of inequality. In a trust-based delegated consensus blockchain network 20, delegated nodes may be selected based on the trust level of the nodes, thus the possibility of a particular node being repeatedly selected as a delegated node is high, which can become a factor hindering decentralization.

[0144] In this embodiment, the Gini coefficient calculation module 340 calculates the degree of imbalance in the number of times N nodes are selected as delegate nodes, which represents the inequality, namely the Gini coefficient (G(δ)). That is, according to mathematical formula 15, the Gini coefficient (G(δ)) is calculated as the deviation of the ratio of the number of times each node participates in the delegated consensus (δ) compared with other nodes.

[0145]

Mathematical Expression 15

[0146]

[0147] The Gini coefficient (G(δ)) has values ​​between 0 and 1, with values ​​closer to 1 indicating greater inequality. Therefore, a specific node (i) is related to the number of times it participates in delegated consensus (δ). i The more Gini coefficient (G(δ)) is, the more decentralization is hindered. Therefore, a decentralization threshold (η) is set such that the Gini coefficient (G(δ)) as shown in Equation 16 does not exceed the decentralization threshold (η), which satisfies the restriction on decentralization.

[0148]

Mathematical Expression 16

[0149] G(δ)≤η

[0150] At this point, methods that restrict the Gini coefficient (G(δ)) from exceeding the decentralization threshold (η) include limiting methods to prevent specific nodes (i) from being repeatedly selected and improving delegation rates. A method to enable more nodes to participate in delegated consensus.

[0151] As an example, suppose we use methods to increase delegation rates in order to achieve decentralization. Methods to enable more nodes to participate in delegated consensus, but not limited to these.

[0152] The compensation calculation module 350 calculates the corresponding action (A) determined by the agent module 220. t The next state information (S) obtained t+1 Compensation (R) t In this compensation calculation module 350, the determined action (A) can be used to calculate the compensation. t Does it satisfy the mathematical formula 12 regarding the scalability of the trilemma as a blockchain network, with a delay (T)? latency The security conditions and the Gini coefficient (G(δ)) conditions of formula 14 for security and formula 16 for decentralization provide compensation (R). t ). Among them, compensation (R) t It can be the maximum TPS calculated according to mathematical formula 6.

[0153] Refer again Figure 4 The memory module 210, serving as the environment for the trust-based delegated consensus blockchain network 20, can store data transfer rates (R = {R_t}) between delegated nodes in each Epoch(t). i，j}) and the computing resources of each delegate node (c={c i}), the number of times the delegated node participates in the delegated consensus (δ={δ i}), the trust level of each delegate node (τ={τ i}) and the probability of malicious delegated nodes Multiple state information

[0154] Furthermore, the memory module 210 can correspond to multiple status information (S) t Each of these will include a block size determined by the proxy module 220. Block Interval and commission rate action Match and store together.

[0155] Furthermore, the memory module 210 can also store state information (S) at a specific Epoch(t).t ) and the corresponding determined action (A) t The state information for the next Epoch (t+1) determined by the environment analysis module 230. and the corresponding next state information (S) t+1 Compensation (R) t ).

[0156] That is, the memory module 210 can match the state information (S) of the blockchain network 20 at each epoch interval. t ) and its corresponding action (A) t ) and according to the action (A) t The next state information (S) t+1 ) and compensation (R t The status information (S) that is matched and stored together with the memory module 210 will be stored together. t ) and action (A t ), next state information (S) t+1 ) and compensation (R t This is called the transition set.

[0157] Agent module 220 is implemented as an artificial neural network that learns in a reinforcement learning manner to determine the state information (S) at a specific Epoch(t) applied by memory module 210. t The corresponding action (A) t Agent module 220 includes state information (S) t The data transfer rate (R) between nodes, the computing resources (c) of each node, the number of times the delegated consensus is participated in (δ), the trust level of the node (τ), and the probability of a malicious delegated node are all considered. The block size (B) and block spacing (T) are estimated and optimized based on the neural network operation learned. I ) and commission rate Output the results.

[0158] The proxy module 220 can estimate the block size (B) and block spacing (T) respectively. I ) and commission rate At least one action (A) is output.

[0159] Furthermore, the proxy module 220 can select from at least one action (A) presumed as mathematical formula 17 a delay (T) that satisfies mathematical formula 12 regarding the scalability of the trilemma as a blockchain network. latency The security conditions and the Gini coefficient (G(δ)) conditions for decentralization in formula 16, and an action (A) of the security condition for formula 14 and the Gini coefficient (G(δ)) conditions for decentralization. t ).

[0160]

Mathematical Expression 17

[0161] Target:

[0162] Restriction: T latency =T I +T v +T p ≤uT I

[0163] limit:

[0164] Restriction: G(d)≤η

[0165] Where Q(S, A) is the action-value function representing the work performed by the agent module 220. It is a function that outputs the value of each of the multiple actions (A) that can be determined by the agent module 220 in response to the state information (S), and is calculated using mathematical formula 18.

[0166]

Mathematical Expression 18

[0167]

[0168] Where V(S) and A(S, A) are the value function and advantage function according to Rainbow DQN, respectively, and a' represents the alternative action.

[0169] The agent module 220 selects the delegation rate determined by the action with different probabilities based on the trust level (τ) of each node. The corresponding K Set the node as a delegate node.

[0170] In response, the compensation calculation module 350 of the environmental analysis module 230, under the condition that all the constraints of mathematical formula 17 are met, can calculate the compensation (R) as shown in mathematical formula 19. t The maximum TPS.

[0171]

Mathematical Expression 19

[0172]

[0173] That is, the network management device in this embodiment can maximize the scalability of the blockchain network 20 while maintaining security and decentralization by maximizing the TPS of the blockchain network 20.

[0174] In the illustrated embodiments, each component may have different functions and capabilities in addition to those described below, and may also include additional components in addition to those described below. Furthermore, in one embodiment, each component may be implemented using one or more physically distinct devices, or by one or more processors or a combination of one or more processors and software, unlike the illustrated examples, in specific operation they may not be clearly distinguished.

[0175] and Figures 3 to 5 The nodes and network management devices of the illustrated blockchain network can be implemented within logic circuits using hardware, firmware, software, or a combination thereof, or using general-purpose or special-purpose computers. The devices can be implemented using hardwired devices, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc. Furthermore, the devices can be implemented as system-on-chips (SoCs) including one or more processors and controllers.

[0176] Furthermore, the nodes and network management devices of a blockchain network can be loaded into computing devices or servers with hardware elements in the form of software, hardware, or a combination thereof. The computing device or server can refer to a part or all of the following: communication devices such as communication modems for communicating with various devices or wired / wireless communication networks; memory for storing data for running programs; and microprocessors for running programs to perform calculations and commands.

[0177] Figure 7 This illustrates a delegated consensus blockchain network management method according to one embodiment.

[0178] Reference Figures 1 to 6 The delegated consensus blockchain network management method according to the embodiment will be described firstly, obtaining the state information (S) under the current Epoch(t). t (410). The status information may include the data transfer rate (R) between delegate nodes, the computing resources (c) of each delegate node, the number of times a delegate node participates in delegated consensus (δ), the trust level (τ) of each delegate node, and the probability of a malicious delegate node.

[0179] Obtain status information (S) t When ), the acquired status information (S) t The corresponding state information (S) is inferred by performing neural network operations through an artificial neural network that learns in a reinforcement learning manner. tAt least one action (A) (420). Each of the presumed at least one action (A) may include block size (B), block spacing (T) I ) and commission rate

[0180] Furthermore, the block size (B) and block spacing (T) are estimated. I ) and commission rate After at least one distinct action (A), one of the at least one presumed action (A) that satisfies the specified constraints can be selected as the action (A) for the current Epoch. t (430). Here, a delay (T) that satisfies the mathematical formula 12 regarding the scalability of the trilemma as a blockchain network can be selected from at least one presumed action (A). latency The security conditions and the Gini coefficient (G(δ)) conditions for decentralization in formula 16, and an action (A) of the security condition for formula 14 and the Gini coefficient (G(δ)) conditions for decentralization. t ).

[0181] Therefore, based on state information (S) t The data transfer rate (R) between delegate nodes, the computing resources (c) of each delegate node, the number of times a delegate node participates in delegated consensus (δ), the trust level (τ) of each delegate node, and the probability of a malicious delegate node are all considered. Determine if it is included in action (A) t Block size (B), block spacing (T) I ) and commission rate Furthermore, the definite action (A) t ) can be combined with status information (S t The data is stored in the memory module 210 in a matching manner.

[0182] Select action (A) t Determine the commission rate In the case of DCR records derived from multiple delegate nodes, an LTO matrix (450) representing the subjective evaluations between multiple delegate nodes is generated based on the aggregated DCR records according to mathematical formula 1.

[0183] At this point, each row of the generated LTO matrix represents the delegate node that performed the subjective evaluation of the delegate node, indicating the delegate node that generated the DCR record, and each column represents the delegate node that was evaluated, indicating the delegate node that transmitted the license message contained in the DCR record.

[0184] After generating the LTO matrix, the trust level (460) for each of the multiple delegate nodes is calculated based on the generated LTO matrix. The trust level for each delegate node is calculated from the LTO matrix according to Equation 4, and the trust level (τ) for each delegate node is calculated from the average subjective trust value (μ) and the trust approximation (ν), which can be obtained according to Equations 2 and 3, respectively.

[0185] After calculating the trust level (τ) for each delegate node, based on the determined delegation rate... Selecting from N nodes to participate in consensus with different probabilities based on trust level (τ). One delegated node (470).

[0186] The state information (S) under the current Epoch(t) has been determined. t ) action (A t Given that a delegate node is selected with different probabilities based on the trust level (τ) of each of the multiple nodes, the following factors are considered: data transfer rate (R) between the selected delegate nodes, computing resources (c) of each delegate node, number of times a delegate node participates in delegated consensus (δ), trust level (τ) of each delegate node, and probability of a malicious delegate node. Analyze and confirm the state information (S) for the next Epoch (t+1). t+1 Simultaneously calculate and obtain compensation (R) t (480). The purpose of the network management method in this embodiment is to maximize the TPS of the blockchain network 20 to improve the scalability of the blockchain network 20 while maintaining security and decentralization. Therefore, compensation can be made here (R t The maximum TPS is calculated.

[0187] Figure 7 The sequential execution of each process has been described, but this is only an exemplary description. Those skilled in the art can make various modifications and variations without departing from the essential characteristics of the embodiments of the present invention, such as changes. Figure 7 The recorded sequence can be executed or executed in parallel, or additional processes can be added.

[0188] Figure 8 The accompanying drawings are for illustrating a computing environment including a computing device according to one embodiment.

[0189] In the illustrated embodiment, each component may have different functions and capabilities in addition to those described below, and additional components may be included for processing purposes other than those described below. The illustrated computing environment 600 includes a computing device 610 capable of executing... Figure 7 The diagram illustrates a network management method. In one embodiment, the computing device 610 may be... Figures 3 to 5The illustrated blockchain network includes more than one of the following components in its nodes and network management device.

[0190] The computing device 610 includes at least one processor 620, a computer-readable storage medium 630, and a communication bus 650. The processor 620 enables the computing device 610 to operate according to the exemplary embodiments described above. For example, the processor 620 can run one or more programs 640 stored in the computer-readable storage medium 630. The one or more programs 640 may include one or more computer-executable instructions configured to cause the computing device 610 to perform the operations of the exemplary embodiments when executed by the processor 620. Furthermore, the storage medium 630 may be a memory.

[0191] The communication bus 650 interconnects various components of the computing device 610, including the processor 620 and the computer-readable storage medium 630.

[0192] The computing device 610 may also include one or more input / output interfaces 660 and one or more communication interfaces 670, providing an interface for one or more input / output devices 680. The input / output interfaces 660 and communication interfaces 670 are connected to a communication bus 650. The input / output devices 680 can be connected to other components of the computing device 610 via the input / output interfaces 660. Exemplary input / output devices 680 may include pointing devices (mouse or trackpad, etc.), keyboards, touch input devices (touchpad or touchscreen, etc.), voice or sound input devices, various sensors and / or imaging devices, and / or display devices, printers, speakers, and / or network cards, etc. Exemplary input / output devices 680 may be included within the computing device 610 as a component of the computing device 610, or they may be connected to the computing device 610 as separate devices distinct from the computing device 610.

[0193] The present invention has been described in detail above through typical embodiments, but those skilled in the art should understand that various modifications and equivalent embodiments can be obtained therefrom. Therefore, the true scope of protection of the present invention should be determined based on the technical concept outlined in the claims.

Claims

1. A delegated consensus blockchain network management device, comprising one or more processors and a memory storing one or more programs running through the one or more processors, wherein, The processor is used for: Obtain status information including the trust level of each delegated node in the blockchain network. Perform neural network operations on the state information to determine actions including the delegation rate. Based on the determined actions, a local trust opinion matrix is ​​generated, representing the subjective evaluations between each delegating node. Based on the trust level calculated using the local trust opinion matrix, select K delegation nodes from N nodes according to the determined delegation rate. Specifically, the processor calculates the average subjective trust value and trust approximation for each delegated node based on the local trust opinion matrix to determine the trust level of the delegated node. The processor is used to determine the mathematical formula: Calculate the average subjective trust value μ for each of the aforementioned delegated nodes. i , Where L j，i This represents the (j, i) element of the local trust opinion matrix. According to the mathematical formula: Calculate the trust approximation ν with respect to the delegate node. i , Where ||·|| is the absolute value function, L i and L j This represents the i-th and j-th row vectors of the local trust opinion matrix. According to the mathematical formula: 𝜏 i =μ i v i Calculate the trust level (T) of each delegate node. i .

2. The delegated consensus blockchain network management device according to claim 1, wherein, The processor is used for: The local trust opinion matrix is ​​generated by aggregating the delegation consensus result records of permission messages regarding agreement or disagreement propagated from the nodes during the practical Byzantine fault-tolerant consensus process collected by the selected delegation nodes.

3. The delegated consensus blockchain network management device according to claim 2, wherein, The processor is used for: The delegation consensus result records obtained by collecting intention messages transmitted from multiple delegation nodes with either agreement ("Yea") or disagreement ("Nay") from each of the delegation nodes are aggregated, and the aggregated delegation consensus result records are then analyzed using a mathematical formula: Calculate the elements of the local trust opinion matrix. Where i and j are the delegate node identifiers, i, j∈[1,2,…,K], Σ i (Yea) and Σ i (Nay) is the number of those who agree ("Yea") and disagree ("Nay") in the delegation consensus results of each delegation node, and Li,j is an element of the local trust opinion matrix.

4. The delegated consensus blockchain network management device according to claim 1, wherein, The processor is used for: In addition to the trust level of each delegate node, the data transmission rate between delegate nodes, the computing resources of each delegate node, the number of times a delegate node participates in the delegate consensus, and the probability of a malicious node being selected as a delegate node, which represents the probability that the calculated trust level is below a pre-specified trust level threshold, are used as the state information.

5. The delegated consensus blockchain network management device according to claim 4, wherein, The processor is used for: According to the mathematical formula: Calculate the probability of obtaining the malicious node delegation. Where, N D For the set of delegate nodes, 𝜏 i Let n be the trust level of the delegate node, n(·) be the counting function that counts the number of nodes that satisfy the condition (·), and ψ be the threshold value.

6. The delegated consensus blockchain network management device according to claim 5, wherein, The processor is used for: The calculation represents the delay until the transaction becomes irreversible after the consensus process is completed following its application to the blockchain network, and is determined based on a delay condition of u consecutive block intervals. The discriminant represents a security condition that makes the proportion of malicious nodes among the delegated nodes participating in consensus according to the practical Byzantine fault tolerance condition less than a pre-specified delegation rate. Calculate the Gini coefficient, which represents the degree of imbalance in the number of times N nodes are selected as delegate nodes, and determine the Gini coefficient condition that ensures the Gini coefficient does not exceed a pre-specified decentralization threshold. Compensation is calculated if the determined action satisfies the delay condition, the safety condition, and the Gini coefficient condition.

7. The delegated consensus blockchain network management device according to claim 6, wherein, The processor is used for: The delay is calculated as the sum of the block generation interval (representing the interval between block generation by block constructors among multiple delegated nodes), the validity check time (representing the validity of generated blocks by multiple delegated nodes), and the message transmission time (representing the validity check result). The delay condition is set such that the calculated delay is less than or equal to the consecutive block intervals. Based on the probability that the delegated node selected according to the delegation rate is a malicious node, according to the mathematical formula: The security condition is set such that the number of delegated nodes exceeds the number of malicious nodes within the delegated nodes. Three times, K is the number of delegated nodes. The Gini coefficient condition is set to G(δ)≤η, such that based on the number of times each of the N nodes is selected as a delegate node to participate in the delegated consensus, according to the mathematical formula: The calculated Gini coefficient is below the aforementioned decentralization threshold. Where η is the decentralization threshold, and δ is the number of times each of the N nodes is selected as a delegate node to participate in the delegated consensus. It's the commission rate, p d It represents the probability that the selected delegate node is a malicious node.

8. The delegated consensus blockchain network management device according to claim 6, wherein, The processor is used for: The action is determined by determining the maximum block size, block interval, and delegation rate per second that satisfy the latency condition, the security condition, and the Gini coefficient condition.

9. The delegated consensus blockchain network management device according to claim 8, wherein, The processor is used for: As the compensation R t Using mathematical formulas: Calculate the maximum number of transactions per second in the delegated consensus blockchain network. Where T I Here, B represents the block generation interval, H represents the block header size, b represents the average transaction size, and A represents the block generation interval. t For the action, S t This is status information.

10. A delegated consensus blockchain network management method, executed by a computing device comprising one or more processors and a memory storing one or more programs running through the one or more processors, wherein... include: The steps to obtain state information including the trust level of each delegated node in the blockchain network; The steps of performing neural network operations on the state information to determine actions including the delegation rate; The steps are as follows: generating a local trust opinion matrix representing the subjective evaluation between each delegated node based on the determined actions; as well as The step of selecting K delegation nodes from N nodes based on the trust level calculated using the local trust opinion matrix and the determined delegation rate. In the step of selecting the delegated node, the average subjective trust value and trust approximation degree for each delegated node are calculated based on the local trust opinion matrix to determine the trust degree of the delegated node. In the step of selecting the delegate node, according to the mathematical formula: Calculate the average subjective trust value μ for each of the aforementioned delegated nodes. i , Where L j，i This represents the (j, i) element of the local trust opinion matrix. According to the mathematical formula: Calculate the trust approximation ν with respect to the delegate node. i , Where ||·|| is the absolute value function, L i and L j This represents the i-th and j-th row vectors of the local trust opinion matrix. According to the mathematical formula: 𝜏 i =μ i v i Calculate the trust level (T) of each delegate node. i .

11. The delegated consensus blockchain network management method according to claim 10, wherein, In the step of generating the local trust opinion matrix: The local trust opinion matrix is ​​generated by aggregating the delegation consensus result records of permission messages regarding agreement or disagreement propagated from the nodes during the practical Byzantine fault-tolerant consensus process collected by the selected delegation nodes.

12. The delegated consensus blockchain network management method according to claim 11, wherein, In the step of generating the local trust opinion matrix: The delegation consensus result records obtained by collecting intention messages transmitted from multiple delegation nodes with either agreement ("Yea") or disagreement ("Nay") from each of the delegation nodes are aggregated, and the aggregated delegation consensus result records are then analyzed using a mathematical formula: Calculate the elements of the local trust opinion matrix. Where i and j are the delegate node identifiers, i, j∈[1,2,…,K], Σ i (Yea) and Σ i (Nay) is the number of those who agree ("Yea") and disagree ("Nay") in the delegation consensus results of each delegation node, and Li,j is an element of the local trust opinion matrix.

13. The delegated consensus blockchain network management method according to claim 10, wherein, In the step of obtaining the status information: In addition to the trust level of each delegate node, the data transmission rate between delegate nodes, the computing resources of each delegate node, the number of times a delegate node participates in the delegate consensus, and the probability of a malicious node being selected as a delegate node, which represents the probability that the calculated trust level is below a pre-specified trust level threshold, are used as the state information.

14. The delegated consensus blockchain network management method according to claim 13, further comprising: The steps for obtaining the next state information and compensation based on the determined action; In the steps of obtaining the next state information and compensation, according to the mathematical formula: Calculate the probability of malicious node delegation. Where, N D For the set of delegate nodes, 𝜏 i Let n be the trust level of the delegate node, n(·) be the counting function that counts the number of nodes that satisfy the condition (·), and ψ be the threshold value.

15. The delegated consensus blockchain network management method according to claim 14, wherein, In the steps of obtaining the next state information and compensation The calculation represents the delay until the transaction becomes irreversible after the consensus process is completed following its application to the blockchain network, and is determined based on a delay condition of u consecutive block intervals. The discriminant represents a security condition that makes the proportion of malicious nodes among the delegated nodes participating in consensus according to the practical Byzantine fault tolerance condition less than a pre-specified delegation rate. Calculate the Gini coefficient, which represents the degree of imbalance in the number of times N nodes are selected as delegate nodes, and determine the Gini coefficient condition that ensures the Gini coefficient does not exceed a pre-specified decentralization threshold. Compensation is calculated if the determined action satisfies the delay condition, the safety condition, and the Gini coefficient condition.

16. The delegated consensus blockchain network management method according to claim 15, wherein, In the steps of obtaining the next state information and compensation The delay is calculated as the sum of the block generation interval (representing the interval between block generation by block constructors among multiple delegated nodes), the validity check time (representing the validity of generated blocks by multiple delegated nodes), and the message transmission time (representing the validity check result). The delay condition is set such that the calculated delay is less than or equal to the consecutive block intervals. Based on the probability that the delegated node selected according to the delegation rate is a malicious node, according to the mathematical formula: The security condition is set such that the number of delegated nodes exceeds the number of malicious nodes within the delegated nodes. Three times, K is the number of delegated nodes. The Gini coefficient condition is set to G(δ)≤η, such that based on the number of times each of the N nodes is selected as a delegate node to participate in the delegated consensus, according to the mathematical formula: The calculated Gini coefficient is below the aforementioned decentralization threshold. Where η is the decentralization threshold, and δ is the number of times each of the N nodes is selected as a delegate node to participate in the delegated consensus. It's the commission rate, p d It represents the probability that the selected delegate node is a malicious node.

Images