CN116032523A

CN116032523A - Trusted consensus block chain network management device and method based on trust degree

Info

Publication number: CN116032523A
Application number: CN202211329965.6A
Authority: CN
Inventors: 郑淙文; 高允永; 尹柱植
Original assignee: Industry Academic Cooperation Foundation of Yonsei University
Current assignee: Industry Academic Cooperation Foundation of Yonsei University
Priority date: 2021-10-27
Filing date: 2022-10-27
Publication date: 2023-04-28

Abstract

The present invention relates to selecting a ratio of nodes to be commissioned and nodes to be commissioned based on a degree of trust, whereby TPS can be improved while maintaining or improving security, the adjustment being such that the same node is not over-selected as a commissioned node to enable decentralised restrictions to be met. Thus, a delegated consensus blockchain network management apparatus and method are provided that enable blockchains to be stably utilized in environments such as IIoT networks that generate large-scale transactions and that require processing within a defined service time.

Description

Trusted consensus block chain network management device and method based on trust degree

Technical Field

The invention relates to a blockchain network management device and method, and a trust-based entrusted consensus blockchain network management device and method.

Background

Blockchains provide transparency and security to data management systems and can be applied in a variety of industrial fields (e.g., energy trading, intelligent factories, resource management). However, if an industrial internet of things (IIoT) network that generates huge real-time data based on a variety of applications is combined with a blockchain, the storage block chain system must meet stringent quality of service (QoS) requirements. Particularly in blockchain-capable real-time IIoT networks, there is a need to address the low throughput problem that occurs in consensus flows.

The bitcoin and ethernet as a typical blockchain system is set to support 3-4 and 14 transactions per second (Transaction Per Second: TPS below) with processing speeds significantly slower than the data generation speed and credit card throughput of the IIoT network. To address this low TPS problem, more developed scalable blockchain techniques are needed. Various blockchains that improve scalability are proposed according to these requirements. However, the existing technology for improving the expansibility has a problem that the influence of the malicious node may be increased and the security may be reduced.

That is, according to the three-dilemma (trilema) of the blockchain system, the blockchain system has the limitation of not being able to improve three features (decentralization, security, extensibility) of the blockchain at the same time. Therefore, a scheme capable of improving TPS to improve expansibility of a blockchain while maintaining or improving security is required.

[ Prior Art literature ]

[ patent literature ]

Korean laid-open patent No. 10-2020-010660 (2020.09.15 publication)

Disclosure of Invention

Technical problem

The invention aims to provide a trust-based entrusted consensus blockchain network management device and method for improving the TPS while maintaining or improving the security so as to improve the expansibility of a blockchain.

Another object of the present invention is to provide a delegation-consensus blockchain network management apparatus and method capable of satisfying a decentralization constraint while selecting a ratio of nodes to be delegated and the nodes to be delegated based on a degree of trust.

Technical proposal

The delegation-consensus blockchain network management device of the present embodiment for achieving the above object acquires state information including a degree of trust of each delegation node of a blockchain network, performs a neural network operation on the state information to determine an action including a delegation rate, generates a local belief opinion (hereinafter: LTO) matrix representing mutual subjectivity evaluation of each delegation node according to the determined action, and selects K delegation nodes according to the determined delegation rate among N nodes based on the degree of trust calculated using the LTO matrix.

The delegated consensus blockchain network management device may aggregate delegated consensus result (hereinafter DCR) records of grant messages regarding agreements or disagreements that are collected by selected delegated nodes during a practical bayer fault tolerance (hereinafter PBFT) consensus process, from the nodes, to generate the LTO matrix.

The processor of the delegation consensus blockchain network management device may calculate an average subjectivity trust value and a trust approximation for each delegation node based on the LTO matrix to calculate a trust of the delegation node.

The delegation-consensus blockchain network management device may acquire, as the state, data transmission rates among delegation nodes, calculation resources of the delegation nodes, the number of times the delegation nodes participate in delegation consensus, and malicious delegation node probability indicating a probability that the calculated malicious node with the degree of trust being equal to or less than a pre-specified trust degree threshold value is selected as the delegation node, in addition to the degree of trust of the delegation nodes.

The delegated consensus blockchain network management device may calculate a delay representing a time until a transaction is applied to the blockchain network and then enters a non-reversible state through a consensus process, determine a delay condition based on u consecutive blockintervals,

judging a security condition indicating a range of delegation rates in which the ratio of malicious nodes among delegated nodes participating in consensus according to the PBFT condition is smaller than a pre-specified ratio, calculating a coefficient of a kunit indicating a degree of imbalance in the number of times selected as delegated nodes among N nodes, and determining a coefficient condition such that the coefficient does not exceed a pre-specified decentralization threshold value, and calculating compensation when the determined motion satisfies the delay condition, the safety condition, and the coefficient condition.

The processor of the delegated consensus blockchain network management device can determine a block size (B) and a block interval (T) that maximize transactions per second TPS (Transaction Per Second) while satisfying the latency condition, the security condition, and the coefficient of Kennel condition _I ) Entrusting rate

To determine the action (A) ^t )。

To achieve the object, a delegated consensus blockchain network management method according to an embodiment includes the steps of obtaining state information including a degree of trust of each delegated node of a blockchain network; a step of performing a neural network operation on the state information to determine an action including a delegation rate; a step of generating a Local Trust Opinion (LTO) matrix representing subjective evaluation of each trust node according to the determined action; and

and selecting K delegated nodes according to the determined delegated rate from among N nodes based on the trust calculated by using the LTO matrix.

Technical effects

Therefore, the delegation-consensus blockchain network management device and method according to the embodiments of the present invention can improve TPS while maintaining or improving security by selecting a ratio of nodes to be delegated and the nodes to be delegated based on the degree of trust, and adjust so that the same node is not excessively selected as the delegation node so that the decentralization constraint is satisfied. Thus, blockchains can be stably utilized even in environments such as IIoT networks that require large-scale transactions to be generated and processed within a limited service time.

Drawings

Fig. 1 shows a brief structure of a delegated consensus-based blockchain network in an IIoT network environment.

Fig. 2 shows an example of a consensus flow using the PBFT consensus algorithm.

Fig. 3 illustrates a simplified structure of a plurality of nodes in a delegated consensus blockchain network in accordance with an embodiment of the present invention.

Fig. 4 shows a brief structure of a network management apparatus according to an embodiment of the present invention.

Fig. 5 shows an example of a specific configuration of the environment analysis module of fig. 4.

Fig. 6 is a diagram for explaining a method of calculating the trust level according to the trust level calculation module of fig. 5.

Fig. 7 illustrates a delegated consensus blockchain network management method in accordance with an embodiment.

FIG. 8 is a diagram illustrating a computing environment including computing, according to one embodiment.

Description of the reference numerals

10: IIOT network 20: block chain network

110: the communication module 120: control module

130: the block generation module 140: block verification module

150: the delegate consensus module 160: block storage module

170: the delegate setting module 210: memory module

220: agent module 230: environment analysis module

310: trust evaluation unit 311: LTO generation module

312: trust calculation module 313: malicious delegation probability calculation module

320: delay calculation module 330: security analysis module

340: the coefficient of foundation calculation module 350: compensation calculation module

Detailed Description

For a full understanding of the invention and of the advantages of the invention in operation and the objects attained by practice of the invention, reference should be made to the drawings and to the descriptions thereof which illustrate the preferred embodiments of the invention.

The preferred embodiments of the present invention will be described below to specifically explain the present invention by referring to the figures. The invention may be embodied in many different forms and is not limited to the embodiments described. In the drawings, like reference numerals denote like components, and parts irrelevant to the description are omitted for the purpose of clearly explaining the present invention.

When a certain component is referred to as being "included" in the specification, it is not intended to exclude other components unless specifically stated to the contrary, but it means that other components may also be included. Further, terms such as "…", "…", "module", "block", and the like in the specification mean a unit that processes at least one function or operation, and this may be implemented by hardware or software, or a combination of hardware and software.

Referring to fig. 1, in an IIoT network 10 in which various IIoT devices such as an intelligent factory, an intelligent home, a robot, a transportation means, and a monitoring device are arranged, each device performs a designated work, and communicates with each other to generate various transactions such as data storage and data sharing. And the generated large number of transactions are transmitted to the blockchain network 20.

Blockchain network 20 receives transactions from IIoT network 10 and stores them to blocks that function as a scatter ledger for trusted data management. As described above, all nodes of the existing blockchain network, called miners or validators (validators), participate in a consensus process to validate transmitted transactions. In this case, a large number of transactions are applied from the IIoT network 10, and a large number of nodes participate in the consensus flow, so that the time required until reaching the consensus becomes long, and thus the transactions cannot be processed within the required service time.

In contrast, the delegated shared blockchain network 20 of the present embodiment enables not all nodes but only some nodes to participate in the shared flow as delegated nodes 21 for transactions applied from the IIoT network 10, thereby greatly increasing the transaction processing speed (Transactions Per Second: hereinafter TPS).

In this embodiment, the network management device may increase the TPS of the delegated consensus blockchain network 20 according to the state of the delegated consensus blockchain network 20, and manage such that the security of the blockchain network is maintained or increased despite the increase of the TPS. That is, the expansibility of the blockchain network can be improved by optimizing the blockchain network. In particular, the network management apparatus according to the present embodiment adaptively optimizes the blockchain network for management according to the state of the blockchain network by deep reinforcement learning (Deep Reinforcement Learning: DRL below) learning.

Here, it is assumed that the delegated consensus blockchain network 20 includes N (N is a natural number) nodes. And according to the entrusting rate of N nodes

Wherein->

) With K (wherein->

As a function of the largest integer) participate in the consensus process as a delegated node 21. The K delegate nodes 21 are a delegate node set (N _D Wherein->

) Is an element of (a). Here, the request rate->

And a node selected as the delegate node 21 among the plurality of nodes is determined by the network management device along with deep reinforcement learning, which will be described later in detail.

In the present embodiment, the delegated consensus blockchain network 20 uses a practical bayer fault tolerance (Practical Byzantine Fault Tolerance: PBFT below) consensus algorithm as the consensus algorithm. The PBFT consensus algorithm utilizes low operation resources and has a fast consensus speed, so that the PBFT consensus algorithm is suitable for the IIOT network 10 with expansibility.

The IIoT network 10 and the blockchain network 20 are distinguished for ease of illustration above, but a plurality of IIoT devices of the IIoT network 10 may operate as nodes of the blockchain network 20. And the network management means may be embodied in at least one of the plurality of nodes.

Fig. 2 shows an example of a consensus flow using the PBFT consensus algorithm.

Referring to fig. 2, the pbft consensus algorithm may be composed of a Pre-preparation step (Pre), a preparation step (preparation), a grant step (command), and a Reply step (Reply).

As an example, fig. 2 shows an algorithm for executing a consensus flow from K delegated nodes 21 selected from a delegated consensus blockchain network 20 including N nodes. One of the K delegate nodes 21 is a master node (Primary node), which is a block constructor that generates a block according to a transaction request, and the other nodes are slave nodes (Replica node), which are verifiers that perform consensus verification on the block generated by the block constructor. One of the K delegated nodes may be randomly selected as a block constructor.

A block constructor in the PBFT consensus algorithm collects transactions generated by the IIOT network and generates blocks according to the blockchain parameters. The block constructor generates M-sized blocks from M requests of a pre-specified Batch size (Batch size). The block constructor transfers the generated block to the verifier and requests verification in the preparation step in advance. Where the block constructor generates message authentication codes (Message Authentication Code: MAC below) corresponding to K-1 authenticators and transmits to the authenticators to request authentication.

Each verifier in the preparing step, upon receiving a block from the block constructor, performs an operation on the MAC and propagates a confirmation message to the other verifier (confirmation message). Thereafter, each verifier verifies the validity of the transmitted block and propagates a grant message (grant message) in the grant step. Wherein valid blocks refer to blocks where the Herder content and transaction list are not forged and hash values (hash values) are not modified. Each verifier generates and transmits an intention message regarding agreement ("Yea") or disagreement ("Nay") to the other verifier as a verification result of the block generation at the approval step block. In the replying step, each of the plurality of authenticators judges that the block is a valid block and is connected to the chain of the produced block when receiving a grant message regarding approval ("Yea") from more than 2/3 of all the authenticators including itself, and replies a blockchain consensus result to the block constructor. And all nodes of the delegated consensus blockchain network 20 may confirm the outcome of the delegated consensus.

As described above, K delegated nodes 21 among the N nodes in the present embodiment execute the consensus flow according to the PBFT consensus algorithm.

The following description regards the construction of multiple nodes of the delegated consensus blockchain network 20.

Referring to fig. 3, the plurality of 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 delegate consensus module 150, and a block storage module 160, respectively.

The communication module 110 enables the network management device to communicate with other nodes on the delegated consensus blockchain network 20. The control module 120 transmits data between the respective components internally through the respective components of the control node, and transmits and receives data to and from other nodes through the control communication module 110.

The block generation module 130 collects transaction generation blocks to be processed from the IIOT network 10 when the corresponding node is selected as a block constructor. Wherein the block constructor may be randomly selected by the blockchain network management device, as described above. And, the generated block is propagated to the validators that are other delegated nodes of the blockchain network through the communication module 110. The generated block is declared as the final block if the TD-PBFT (Trust based Delegated PBFT) consensus flow of the plurality of delegated nodes of the delegated consensus blockchain network 20 in fig. 2 gains more than 2/3 consent, and is connected to the blockchain previously stored in each node.

In the case where the delegated node selected as the block constructor generates and propagates a block, the block verification module 140 transmits a confirmation message to the other delegated nodes of the blockchain network through the communication module 110. And verifies the validity of the transmitted block and generates a license message regarding approval ("Yea") or disapproval ("Nay") as a result of the verification, and propagates the generated license message to other verifiers.

The delegated consensus module 150 aggregates its own license message as a verification result with license messages propagated from other verifiers to derive a delegated consensus result (Delegated Consensus Result: DCR). Here, as shown in fig. 6 (a), the aggregated license message may be referred to as a DCR record. The delegated consensus module 150 gathers the own license message and the license message transmitted from the other validators to acquire the DCR record, and determines that the block generated as a result of the delegated consensus is a valid block when the license message about agreement ("Yea") is transmitted by at least 2/3 of the acquired DCR records.

The block storage module 160 receives and stores the block determined to be valid by the delegated consensus module 150. Here, the block storage module 160 stores the applied block connected to the previously stored blockchain. And, the stored blockchain may be propagated to other nodes of the blockchain network.

In addition, the delegated common blockchain network 20 of the present embodiment may further include a network management device for enhancing TPS of the blockchain network. The network management device determines a delegation rate as a ratio of delegation nodes among the plurality of nodes

Maximizing TPS to improve expansibility while setting to meet security and decentralization in three-dilemma of blockchain networks, according to set delegation rate ≡>

The delegate node 21 is selected.

Fig. 4 shows a schematic structure of a network management device according to an embodiment of the present invention, fig. 5 shows an example of a specific configuration of the environment analysis module of fig. 4, and fig. 6 is a diagram for explaining a method in which the trust level calculation module of fig. 5 calculates a trust level based on a delegated consensus result.

The network management device may be configured as a separate device from the plurality of nodes delegating the consensus blockchain network 20, but at least one of the plurality of nodes may also function as a network management device. When a node of the delegated consensus blockchain network 20 operates as a network management device, the node may further include a delegate setting module 170 as shown in fig. 3.

The network management device (or the delegate setting module 170) in this embodiment may be implemented to include an artificial neural network that is learned in advance by deep reinforcement learning (deep reinforcement learning: DRL). As an example, the network management device in this embodiment may be configured based on a rainbow DQN (Rainbow Deep Q Network) learned by the DRL method in an artificial neural network.

Referring to fig. 4, the network management device (or proxy setting module 170) may include a memory module 210, a proxy module 220, and an environment analysis module 230.

The memory module 210 stores state information corresponding to each Epoch (t) as an environment match for the trust-based delegated consensus blockchain network 20 (S ^t ) And corresponds to the state information (S ^t ) Action (A) of (a) ^t ). The agent module 220 determines that the data is based on the status information (S ^t ) Action (A) of (a) ^t ). The environment analysis module 230 is based on the state information (S ^t ) And based on the state information (S ^t ) Action determined (A) ^t ) Calculate the next state information (S ^t+1 ) And corresponds to the next state information (S ^t+1 ) Is compensated for (R) ^t )。

First, the environment analysis module 230 calculates next state information (S ^t+1 ) And compensation (R ^t ) The trust evaluation module 310, the delay computation module 320, the security analysis module 330, the coefficient of kunit computation module 340, and the compensation computation module 350 may be included as shown in fig. 5.

Wherein the trust level evaluation module 310 calculates the trust level for each of the plurality of nodes, the delay calculation module 320, the security analysis module 330, the coefficient of kunit calculation module 340 calculate the delay and the security and the kunit in order to consider expansibility, security and decentralization, respectively, as a dilemma of the blockchain network. Further, the compensation meter The computing module 350 is based on the determined action (A ^t ) According to the next state information (S ^t+1 ) Whether or not the conditional calculation compensation (R ^t )。

The trust level evaluation module 310 aggregates DCR records derived from the plurality of delegate nodes, generates a local trust opinion (Local Trust Opinion: LTO below) matrix representing subjective evaluations of the plurality of delegate nodes with respect to each other based on the aggregated DCR records, and evaluates trust levels for each of the plurality of nodes based on the generated LTO matrix.

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.

The LTO generation module 311 aggregates DCR records obtained from multiple delegate nodes to generate an LTO matrix. Each row in the LTO matrix is a delegation node that performs subjective evaluation of the delegation node, and represents the delegation node that generated the DCR record, and each column is a delegation node that is evaluated, and represents a delegation node that is included in the transfer permission message of the DCR record. I.e. the elements (L) in the LTO matrix _i，j ) The subjective trust level of the delegate node (i) on the delegate node (j) is represented. Wherein i, j are respectively delegated node identifications, and the position coordinates used as LTO matrix are (i, j E [1,2, …, K) ]). Elements (L) of the LTO matrix _i，j ) Can be calculated according to the formula 1.

[ math 1 ]

Wherein Σ is _i (Yea) and Σ _i (Nay) is the number of agreements ("Yea") and disagreements ("Nay") in the DCR of the delegated node (i), respectively. For example, the delegation node (i) receives a grant message of grant ("Yea") from the delegation node (j), and if the ratio of grant ("Yea") in DCR of the delegation node (i) is 75%, the calculated element (L) of the LTO matrix _i，j ) 0.75.

After generating the LTO matrix, the trust calculation module 312 calculates a trust level for each of the plurality of delegate nodes based on the generated LTO matrix. Here, the delegation setting module 170 may calculate an average subjectivity trust value (average subjective trust value) (μ) and a trust similarity (ν) for each delegation node from the LTO matrix.

Wherein the average subjectivity trust value represents an average value of subjectivity trust levels of multiple delegate nodes for evaluation by a particular delegate node (i), and the trust approximation (v) represents an approximation between subjective evaluation by each delegate node for evaluation by multiple delegate nodes.

The confidence calculation module 312 may calculate an average subjectivity confidence value (μ) for the delegate node (i) according to equation 2 _i )。

[ formula 2 ]

(wherein L _j，i Represents the (j, i) element of the LTO matrix. )

Average subjectivity confidence value (μ) for math figure 2 _i ) Indicating that the delegation node (i) submitted an accurate grant message at the time of block verification. If a valid block is generated, the normal commit node transmits a grant message of grant ("Yea"). While the malicious delegation node transmits a disagreement ("Nay") grant message. In the case where the malicious delegation node transmits a grant message of disagreement ("Nay") as above, since the rate of disagreement ("Nay") is small compared to the agreement ("Yea"), the average subjectivity trust value (μ) with respect to the malicious node _i ) Will be lower.

In addition, the trust approximation (v) for the delegate node (i) can be obtained by computing the average of cosine approximations of row vectors in the LTO matrix as shown in equation 3 _i )。

[ formula 3 ]

Where L is an absolute value function, L _i L and L _j The i and j th row vectors of the LTO matrix are represented, respectively. The trust approximation (v) may be used to penalize the trusted node 21 that falsifies the DCR record. In the case where a malicious node falsifies a permission message to generate a DCR record to reduce the trust level of a normal node, the trust approximation (v) of equation 3 _i ) Will drop.

And the confidence calculation module 312 calculates the average subjectivity confidence value (μ) from the values calculated according to equations 2 and 3 as equation 4 _i ) And trust proximity (v) _i ) The trust level (tau) of each delegate node is calculated.

[ math figure 4 ]

τ _i ＝μ _i ν _i

That is, the trust level calculation module 312 decreases the average subjectivity trust value (μ) in the case where the malicious delegation node falsifies the license message as a result of the block verification, decreases the trust approximation (ν) in the case where the DCR record obtained by collecting the license message is falsified, such that the trust level (τ) with respect to the malicious delegation node decreases, and increases in the case of a normal delegation node transmitting a normal license message and the DCR record, using the LTO matrix.

The network management apparatus (or the delegation setting module 170) in this embodiment may select a delegation node with different probabilities according to the trust level (τ) of each of the plurality of nodes. That is, the probability that a node with a high degree of trust (τ) is selected as a delegate node may be increased, and the probability that a node with a low degree of trust (τ) is selected as a delegate node may be reduced to reduce the likelihood that a malicious node is selected as a delegate node.

Wherein the initial trust level (τ) of the plurality of nodes may be set to 0.5 (τ=0.5).

Further, the malicious delegation probability calculation module 313 may estimate that a malicious node may be included in the delegation node set (N _D ) Is a probability of (2). Among them, a node whose trust level (τ) is equal to or less than a pre-designated trust level threshold value (ψ) is referred to as a malicious node. Assuming that the initial trust level (τ) of each node is set to 0.5, as described above, the trust level (τ) of a normal node increases while the trust level (τ) of a malicious node decreases when the trust level is calculated, and thusNodes with a trust level (τ) of less than 0.5 may be considered malicious nodes.

Further, it can be calculated as equation 5 that the malicious node may be included in the delegation node set (N _D ) Probability of delegation of malicious nodes of (a)

[ formula 5 ]

Where n (-) is a count function that counts the number of conditions that meet (-).

That is, malicious node delegation probability

Representation is relative to the dependence of the delegation rate>

Is included in the delegated node set (N) _D ) Trust in node (tau) _i ) Is below a threshold value (phi) (tau _i And +.ψ) of the number of nodes.

In addition, the delegated common blockchain network 20 according to the present embodiment should have scalability such that the required TPS performance can still be achieved with an increased number of nodes. The TPS performance analysis to ensure scalability should take into account both the message exchange between the delegated nodes and the delay time that occurs during the validity of the checking of the blocks. In addition, the scalability of the blockchain network 20 and the decentralization and security that are naturally required as a dilemma are also considered.

In this regard, first, the condition of TPS for extensibility should be considered, and in order to consider the condition about TPS, the delay calculation module 320 calculates a delay (T) representing the time until the consensus process becomes irreversible after the transaction is applied to the blockchain network 20 _latency )。

Assuming that the block constructor in the blockchain network 20 generates a B byte block including a block Header of H bytes, the maximum TPS may be calculated as in equation 6.

[ formula 6 ]

Wherein T is _I Is the block generation interval, b represents the average transaction size.

Delay (T) _latency ) Is the time required for a transaction to be applied to the blockchain network to connect to the blockchain, is the block generation interval (T _I ) And consensus time (T) _consensus ) And (3) summing. Consensus time (T) _consensus ) Reusable validity checking time (T _v ) Message transmission time (T _p ) Therefore, the delay calculation module 320 can calculate the delay (T) using equation 7 _latency )。

[ formula 7 ]

T _latency ＝T _I +T _consensus

＝T _I +T _v +T _p

One of the K entrusted nodes in the TP-PBFT entrusted consensus flow is a block constructor, and the remaining K-1 entrusted nodes operate as verifiers, so the validity check time (T) in equation 7 _v ) The computation may be divided into a block constructor and a verifier.

The block constructor generates M-sized blocks that are propagated to the verifier, so the block constructor should perform a total of M signature (signature) verifications and 2m+4 (K-1) Message Authentication Code (MAC) generation or verification jobs during the consensus process. And, the verifier should perform M signature verification and m+4 (K-1) Message Authentication Code (MAC) verification jobs.

Thus, the validity check time (T) of each of the block constructor and the verifier can be calculated by using the equations 8 and 9 _v _ _bp ，T _v _ _val )。

[ math figure 8 ]

[ formula 9 ]

Where θ represents a CPU period required for signature verification, α represents a CPU period required for message authentication code generation or verification, c _bp And c _i The calculation resources of the block constructor and the i-th verifier are represented, respectively, to represent the calculation speed.

And the block constructor and the verifier can independently perform the validity check, so that the validity check time (T _v ) Validity checking time (T _{v_bp} ，T _{v_val} ) The maximum value of (2) can be calculated as shown in equation 10.

[ math.10 ]

In addition, the message transmission time (T _p ) Representing the time (T) required for a message to arrive according to the stages (Pre-prepare, prepare, commit, reply) of the consensus process illustrated in FIG. 2 _Pre-prepare 、T _Prepare 、T _Commit 、T _Reply ) Sum (T) _p ＝T _Pre-prepare +T _Prepare +T _Commit +T _Reply ). Here, in order to prevent the unresponsive node, i.e., the node that does not transmit the message, from causing excessive delay in the consensus process in each step, each step restriction time (ζ) may be set.

In this regard, the message transmission time (T) can be calculated according to equation 11 _p )。

[ formula 11 ]

Wherein the subscript bp denotes a block constructor, client represents an uncommitted node. And R is _i，j Is the data transmission rate in the message exchange process between the i delegated node and the j delegated node, and can be quantized into R levels (r= { R ₁ ，R ₂ ，…，R _r }) represents a state transition probability matrix (state transition probability matrix) ([ p) assuming a finite state Markov chain model (fine-state Markovchannel model) is applicable _R (t)] _r×r ) Available p _R (t)＝Pr[R _i，j (t+1)＝R _b |R _i，j (t)＝R _a ]And (5) calculating to obtain the product. Pr []As a conditional probability function, R _a ，R _b ∈R。

But should be performed at u consecutive block intervals (uT) _I ) Since the transaction consensus flow is completed in the internal, the delay calculated by equation 7 in the delay calculation block 320 (T _latency ) Equation 12 should be satisfied.

[ formula 12 ]

T _latency ＝T _I +T _v +T _p ≤uT _I

In addition, the security analysis module 330 may normally perform consensus when (3f+1). Ltoreq.N security conditions are satisfied when there are f malicious nodes among the N nodes participating in the consensus as known in the PBFT-based consensus algorithm in terms of security.

However, in the delegated consensus blockchain network of the present embodiment, K nodes among N nodes participate in the consensus process as delegation nodes, so the delegation rate should be determined at the level that the security condition of PBFT is satisfied

To a trust rate for ensuring security

In the case where p is the probability that each node is a malicious node, the worst case may be considered to be the case where all malicious nodes are selected as the delegate node. In order to be able to meet the security conditions even in this worst case, according to the commission Rate of support->

The number of delegated nodes selected ∈>

Should exceed three times the number (Np) of malicious nodes according to the probability (p) among all nodes (N). And since the maximum value of the delegation is 1, the delegation is +.>

The range of (c) should be set to satisfy equation 13./>

[ formula 13 ]

However, as described above, the request rate according to equation 13

Is to consider that all malicious nodes contain a set of delegated nodes (N _D ) Is calculated as the worst case. While the trusted delegation node is selected based on the trust level of each of the plurality of nodes in the trusted delegation-based common blockchain network 20 of the present embodiment, the malicious node is not included in the delegation node set (N _D ) Is high.

Therefore, not all nodes need to be considered but the delegated node set (N _D ) The probability (p _d ) Mathematical formula 13 is modified. For this purpose, the number of entrusted nodes can be used

Weighting probability (p _d ) Calculate->

To obtain the information contained in the node set (N _D ) Is a malicious node of (a)Number, thus trust-based delegation rate according to security conditions in the delegated consensus blockchain network 20>

Is determined to satisfy equation 14.

[ formula 14 ]

Conditions concerning TPS for extensibility in a three-dilemma for blockchain networks and delegation rate for security are confirmed

After the condition for the decentration, the condition for the decentration needs to be confirmed.

Various methods of measuring the decentralization of the blockchain network 20 are known, but unlike the prior art, the coefficient of background (Gini coefficient) used in various fields as an index for evaluating the level of inequality is utilized herein. In the trust-based delegated consensus blockchain network 20, a delegate node may be selected based on the trust level of the node, and thus, there is a high probability that a particular node is repeatedly selected as a delegate node, which may be an element that hinders decentralization.

In this regard, the coefficient calculation module 340 calculates the degree of imbalance in the number of times between N nodes selected as the delegate node, that is, the coefficient of the foundation (G (δ)) representing the unevenness. That is, a coefficient of a base (G (δ)) representing a deviation of a ratio of the number of times (δ) that each node participates in the delegate consensus with respect to other nodes is calculated according to the equation 15.

[ math 15 ]

The coefficient of the foundation (G (delta)) has a value between 0 and 1, and is more unequal as it approaches 1, so that a particular node (i) participates in the delegation consensus less frequently than a node Number (delta) _i ) More, thus indicating that decentration is hindered. Therefore, the decentering threshold value (η) is set so that the restriction on decentering can be satisfied in the case where the coefficient of kunning (G (δ)) as in the equation 16 does not exceed the decentering threshold value (η).

[ math.16 ]

G(δ)≤η

At this time, the method of limiting the coefficient of base (G (δ)) not to exceed the decentralization threshold value (η) is limited such that the specific node (i) is not repeatedly selected and the delegation rate is increased

More nodes are made to participate in the method of delegated consensus.

For example, it is assumed that the request rate is increased for decentralization

The method of enabling more nodes to participate in delegated consensus is not limited thereto.

The compensation calculation module 350 calculates a compensation value corresponding to the compensation value based on the action (a) determined by the agent module 220 ^t ) Acquired next state information (S ^t+1 ) Is compensated for (R) ^t ). The compensation calculation module 350 can calculate the compensation value based on the determined action (A ^t ) Whether or not the delay (T) of equation 12 regarding expandability as a three-difficulty dilemma of the blockchain network is satisfied _latency ) The conditions and the safety conditions of equation 14 for safety and the coefficient of the radix coefficient (G (δ)) conditions of equation 16 for decentration provide compensation (R ^t ). In which compensation (R ^t ) The maximum TPS calculated according to equation 6 may be used.

Referring again to fig. 4, the memory module 210, as an environment of the trust-based delegated consensus blockchain network 20, may store data transfer rates (r= { R _i，j -j) and the operation resource (c= { c) of each delegate node _i -j), number of times the delegate node participates in the delegate consensus (δ= { δ) _i Trust level of each delegate node τ= { τ) _i Probability of malicious delegated node)

Status information of->

And the memory module 210 can correspond to a plurality of status information (S ^t ) Will include the block size determined by proxy module 220

Block interval->

Entrusting rate

Action of->

Together match storage.

Furthermore, the memory module 210 may store status information (S) under a specific Epoch (t) together ^t ) And an action (A) determined in correspondence with the same ^t ) Status information at the next Epoch (t+1) determined by the context analysis module 230

Corresponding to the next state information (S ^t+1 ) Is compensated for (R) ^t )。

That is, the memory module 210 may match state information of the blockchain network 20 at each Epoch interval (S ^t ) And an action (A) corresponding to the same ^t ) According to action (A) ^t ) Is the next state information (S ^t+1 ) Compensation (R) ^t ) And storing the same. Wherein the state information stored together with the memory module 210 is matched (S ^t ) And action (A) ^t ) Next state information (S ^t+1 ) Compensation(R ^t ) Referred to as a Transition set.

The agent module 220 is implemented as an artificial neural network learned in a reinforcement learning manner, determines state information under a specific Epoch (t) applied by the memory module 210 (S ^t ) Corresponding action (A) ^t ). The proxy module 220 generates a proxy for the status information (S ^t ) Data transmission rate (R) between nodes, computing resource (c) of each node, number of times of authorized consensus participation (delta), trust level (tau) of node, and probability of malicious authorized node

The block size (B) and the block interval (T) are estimated and optimized by performing a neural network operation according to a learning method _I ) Entrusting rate->

And outputting.

The proxy module 220 can estimate the block size (B), block interval (T _I ) Entrusting rate

Output at least one action (a) of (a).

And the agent module 220 may select a delay (T) of mathematical formula 12 satisfying expansibility about a dilemma as a blockchain network from at least one action (a) as estimated by mathematical formula 17 _latency ) Condition and safety condition of equation 14 for safety and one action (a) of the coefficient of key (G (δ)) condition of equation 16 for decentration ^t )。

[ math 17 ]

The object is:

restriction T _latency ＝T _I +T _v +T _p ≤uT _I

Restriction:

restriction G (d) is less than or equal to eta

Where Q (S, a) is an action-value function (action-value function) representing the work performed by the agent module 220, is a function that outputs a value of each of a plurality of actions (a) determinable by the agent module 220 in response to the state information (S), and is calculated using equation 18.

[ formula 18 ]

Where V (S) and A (S, A) are a value function (value function) and a dominance function (advantage function), respectively, according to the rainbow DQN, a' represents an alternative action candidate.

Proxy module 220 and selects a delegation rate determined by an action with different probabilities based on the trust level (τ) of each node

K corresponding->

The node is set as the delegated node.

In this regard, the compensation calculation module 350 of the environment analysis module 230 may calculate as compensation (R) as in equation 19 if all the constraints of equation 17 are satisfied ^t ) Is not equal to the maximum TPS of (a).

[ formula 19 ]

That is, the network management apparatus of the present embodiment can maintain security and decentralization while maximizing the TPS of the blockchain network 20 to improve the expansibility of the blockchain network 20.

In the illustrated embodiment, each of the components may have different functions and capabilities other than those described below, and may include additional components other than those described below. In addition, in an embodiment, each structure may be implemented by one or more devices physically separated, or by one or more processors or a combination of one or more processors and software, which may not be clearly separated in terms of specific operations unlike the illustrated example.

And the nodes of the blockchain network and network management devices illustrated in fig. 3-5 may be implemented in logic circuitry, either in hardware, firmware, software, or in combinations of them, or using general-purpose or special-purpose computers. The apparatus may be implemented using fixed wire (hard) devices, field programmable gate arrays (Field Programmable Gate Array, FPGAs), on-demand semiconductors (Application Specific Integrated Circuit, ASICs), or the like. In addition, the device may be implemented by a System on Chip (SoC) including more than one processor and controller.

Furthermore, the nodes of the blockchain network and the network management device may be loaded in software, hardware, or a combination thereof, to a computing device or server having hardware elements. The computing device or server may refer to a part or right of a communication device including a communication modem or the like for communicating with various devices or wired and wireless communication networks, a memory storing data for running a program, a microprocessor for running a program to perform operations and commands, and the like.

Describing a delegated consensus blockchain network management method according to an embodiment with reference to fig. 1 to 6, first, state information under a current Epoch (t) is acquired (S ^t ) (410). Wherein the status information includes data transmission rate (R) between the entrusted nodes, computing resource (c) of each entrusted node, number of times (delta) of entrusted nodes participating in entrusted consensus, trust level (tau) of each entrusted node and probability of malicious entrusted node

Acquiring state information (S ^t ) In this case, the acquired state information (S ^t ) By the following steps ofThe artificial neural network for reinforcement learning mode performs a neural network operation to estimate the corresponding state information (S ^t ) Is performed (420). Wherein each of the estimated at least one action (A) may include a block size (B), a block interval (T _I ) Entrusting rate

Then, the block size (B) and the block interval (T _I ) Entrusting rate

After the at least one action (A) is different, one action meeting the specified limiting condition in the at least one estimated action (A) can be selected to be determined as the action (A) of the current Epoch ^t ) (430). Here, a delay (T) satisfying equation 12 regarding expandability of the three-way dilemma as the blockchain network may be selected from the estimated at least one action (a) _latency ) Condition and safety condition of equation 14 for safety and one action (a) of the coefficient of key (G (δ)) condition of equation 16 for decentration ^t )。

And thus based on the state information (S ^t ) Data transmission rate (R) between delegation nodes, computing resource (c) of each delegation node, number of times (delta) that delegation node participates in delegation consensus, trust degree (tau) based on each delegation node and probability of malicious delegation node

Confirm the content in the action (A) ^t ) Block size (B), block interval (T _I ) Entrusting rate->

And, the determined action (A ^t ) Can be associated with status information (S ^t ) Is matingly stored to the memory module 210.

Selection action (A) ^t ) Determining a delegation rate

In the case of (1), DCR records derived from a plurality of principal nodes are collected, and an LTO matrix (450) indicating subjective evaluation of the principal nodes is generated based on the collected DCR records according to equation 1.

At this time, each row of the LTO matrix generated is a delegation node that performs subjective evaluation on the delegation node, and represents the delegation node that generated the DCR record, and each column is a delegation node that is evaluated, and represents the delegation node that transmitted the grant message included in the DCR record.

After generating the LTO matrix, a degree of trust is calculated for each of the plurality of delegate nodes based on the generated LTO matrix (460). The trust degree for each delegate node is calculated from the LTO matrix according to equation 4 and the trust degree (τ) for each delegate node is calculated from the average subjective trust value (μ) and the trust approximation (ν), which can be calculated according to equations 2 and 3, respectively.

After calculating the trust level (tau) of each entrusted node, according to the determined entrusted rate

Selecting a number of N nodes participating in a consensus with different probabilities based on a confidence level (tau)>

And a delegation node (470).

Determines the state information (S) according to the current Epoch (t) ^t ) Action (A) of (a) ^t ) When the trusted node is selected with different probabilities according to the trust level (tau) of each of the plurality of nodes, the data transmission rate (R) between the selected trusted nodes and the computing resource (c) of each trusted node, the number of times (delta) that the trusted node participates in the trusted consensus, the trust level (tau) of each trusted node and the probability of malicious trusted node are used for the trusted node

Performing analysis to confirm the status information (S) about the next Epoch (t+1) ^t+1 ) At the same time calculate the acquisition compensation (R ^t ) (480). Object of the network management method of the embodimentIs to maximize TPS of the blockchain network 20 to improve scalability of the blockchain network 20 while maintaining security and decentralization, so that (R ^t ) Calculated as maximum TPS.

While the sequential execution of the processes is illustrated in fig. 7, this is merely an example, and those skilled in the art can apply to various modifications and variations without departing from the essential characteristics of the embodiments of the present invention, such as changing the sequential execution or parallel execution of one or more processes described in fig. 7, or adding other processes.

FIG. 8 is a diagram illustrating a computing environment including a computing device according to one embodiment.

In the illustrated embodiment, each component may have different functions and capabilities other than those described below, and additional components may be included in addition to those described below. The illustrated computing environment 600 includes a computing device 610 that can perform the network management method illustrated in fig. 7. In one embodiment, the computing device 610 may be one or more of the constituent elements included in the nodes and network management devices of the blockchain networks illustrated in fig. 3-5.

The computing device 610 includes at least one processor 620, a computer-readable storage medium 630, and a communication bus 650. The processor 620 may cause the computing device 610 to operate in accordance with the exemplary embodiments described above. For example, the processor 620 may execute one or more programs 640 stored on the computer readable storage medium 630. The one or more programs 640 may include one or more computer-executable instructions that may be configured to cause the computing device 610, when executed by the processor 620, to perform the operations of the exemplary embodiments. And the storage medium 630 may be constituted by a memory.

Communication bus 650 interconnects various components of computing device 610 including processor 620 and computer-readable storage medium 630.

Computing device 610 may also include one or more input-output interfaces 660 providing an interface to one or more input-output devices 680 and one or more communication interfaces 670. Input/output interface 660 and communication interface 670 are coupled to communication bus 650. The input-output device 680 may be connected to other components of the computing device 610 through the input-output interface 660. Exemplary input/output devices 680 may include a pointing device (mouse or track pad, etc.), a keyboard, a touch input device (touch pad or touch screen, etc.), voice or sound input devices, input devices such as various sensors and/or cameras, and/or output devices such as display devices, printers, speakers, and/or network cards. The example input-output device 680 may be included within the computing device 610 as a component of the computing device 610 or may be connected to the computing device 610 as another device separate from the computing device 610.

While the invention has been described in detail with reference to the exemplary embodiments thereof, it will be apparent to one skilled in the art that various changes can be made and equivalents can be substituted for elements thereof. The true scope of the invention should be determined based on the technical idea of the scope of the claims.

Claims

1. A delegated consensus blockchain network management device, the device comprising one or more processors and a memory storing one or more programs that are executed by the one or more processors, wherein the processors are configured to:

status information including the trust level of each delegate node of the blockchain network is obtained,

performing a neural network operation on the state information to determine an action including a delegation rate,

generating a local trust opinion LTO matrix representing mutual subjectivity assessment of the delegate nodes based on the determined actions,

k delegate nodes of the N nodes according to the determined delegate rate are selected based on the calculated confidence level using the LTO matrix.

2. The delegated consensus blockchain network management device of claim 1, wherein the processor is to:

the LTO matrix is generated by aggregating delegated consensus result DCR records of consent or disagreement grant messages transmitted from nodes collected by selected delegated nodes during the utility bayer fault tolerant PBFT consensus process.

3. The delegated consensus blockchain network management device of claim 1, wherein the processor is to:

aggregating the DCR records collected by each of the delegate nodes from the plurality of delegate nodes obtained with consent ("Yea") or disagreement ("Nay") transmitted intent messages, and passing the mathematical formula from the aggregated DCR records:

Calculate the element (L) of the LTO matrix _i，j )，

Wherein i, j are delegated node identifications, i, j e [1,2, …, K respectively]，Σ _i (Yea) and Σ _i (Nay) is the number of agreements ("Yea") and disagreements ("Nay") in the DCR of each delegate node (i).

4. The delegated consensus blockchain network management device of claim 1, wherein the processor is to:

an average subjectivity trust value and a trust approximation for each delegate node is calculated based on the LTO matrix to calculate the trust of the delegate node.

5. The delegated common blockchain network management device of claim 4, wherein the processor is to:

according to the mathematical formula:

calculating an average subjectivity trust value (mu) for each of said delegate nodes (i) _i )，

Wherein L is _j，i The (j, i) element representing the LTO matrix,

according to the mathematical formula:

calculating a trust approximation (v) about the delegate node (i) _i )，

Where I are absolute value functions, L _i L and L _j Representing the ith and jth row vectors of the LTO matrix,

according to the mathematical formula:

τ _i ＝μ _i v _i

calculating trust level (τ) of each delegate node _i )。

6. The delegated consensus blockchain network management device of claim 1, wherein the processor is to:

and acquiring data transmission rates among the delegation nodes, operation resources of the delegation nodes, the number of times the delegation nodes participate in delegation consensus, and probability of malicious delegation nodes representing the probability that the calculated trust is less than a pre-designated trust threshold value and is selected as the delegation nodes as the state information.

7. The delegated common blockchain network management device of claim 6, wherein the processor is to:

according to the mathematical formula:

calculating and obtaining the malicious node entrusting probability

Wherein N is _D In order to delegate the collection of nodes,

τ _i to delegate the trust of a node, n (·) is a count function that counts the number of conditions that satisfy (·).

8. The delegated common blockchain network management device of claim 7, wherein the processor is to:

calculating a delay representing a time until a transaction becomes irreversible through a consensus process after being applied to the blockchain network, discriminating a delay condition according to u consecutive block intervals,

judging a security condition indicating a range of delegation rates in which the ratio of malicious nodes among delegated nodes participating in consensus according to the PBFT condition is smaller than a pre-specified ratio,

a coefficient of a kunit representing the degree of imbalance in the number of times a delegate node is selected among the N nodes is calculated, judging the condition of the coefficient of the base, which makes the coefficient of the base not exceed a pre-designated decentralization threshold value,

the determined action calculates a compensation if the delay condition and the safety condition and the coefficient of the key condition are satisfied.

9. The delegated common blockchain network management device of claim 8, wherein the processor is to:

calculating a block generation interval (T) representing an interval of a block generator generating blocks among the plurality of delegate nodes _I ) A validity check time (T) for checking validity of the generated block by the plurality of delegated nodes _v ) And a message transmission time (T _p ) The sum is taken as the delay (T _latency ) The delay condition is set to a calculated delay (T _latency ) For consecutive block intervals (uT _I ) In the following the procedure is described,

based on the rate of delegation

Probability (p) that the selected delegate node is a malicious node _d ) According to the mathematical formula:

setting the security condition such that the number of delegated nodes exceeds the number of malicious nodes within the delegated node

Three times (1)>

Setting the coefficient of foundation condition to G (delta) < eta N so that the number of times (delta) that the node participates in the delegation consensus according to N nodes is selected as the delegation node respectively according to a mathematical formula:

/>

the calculated coefficient of kunning is less than the de-centering threshold (eta).

10. The delegated common blockchain network management device of claim 8, wherein the processor is to:

determining a block size (B) and a block interval (T) that maximize transactions per second TPS (Transaction Per Second) while satisfying the latency condition and the security condition and the coefficient of the key condition _I ) Entrusting rate

To determine the action (A) ^t )。

11. The delegated consensus blockchain network management device of claim 10, wherein the processor is to:

as said compensation (R ^t ) Using the mathematical formula:

calculating a maximum TPS of the delegated consensus blockchain network,

wherein T is _I Is the block generation interval, B represents the block size, H represents the block Herder size, and B represents the average transaction size.

12. A method of delegated consensus blockchain network management, the method performed by a computing device comprising one or more processors and memory storing one or more programs executed by the one or more processors, comprising:

acquiring state information including trust of each delegate node of the blockchain network;

a step of performing a neural network operation on the state information to determine an action including a delegation rate;

generating a local trust opinion LTO matrix representing subjective evaluation of each trust node according to the determined actions; and

13. The delegated consensus blockchain network management method of claim 12, wherein in the step of generating the LTO matrix:

14. The delegated consensus blockchain network management method of claim 12, wherein in the step of generating the LTO matrix:

calculate the element (L) of the LTO matrix _i，j )，

15. The delegated common blockchain network management method of claim 12, wherein in the step of selecting the delegate node:

16. The delegated common blockchain network management method of claim 15, wherein in the step of selecting the delegate node:

According to the mathematical formula:

Wherein L is _j，i The (j, i) element representing the LTO matrix,

according to the mathematical formula:

calculating a trust approximation (v) about the delegate node (i) _i )，

according to the mathematical formula:

τ _i ＝μ _i v _i

calculating trust level (τ) of each delegate node _i )。

17. The delegated common blockchain network management method of claim 12, wherein in the step of obtaining the status information:

and acquiring data transmission rates among the delegation nodes, operation resources of the delegation nodes, the number of times the delegation nodes participate in delegation consensus, and probability of malicious delegation nodes representing the probability that the calculated trust is less than a pre-designated trust threshold value and is selected as the delegation nodes, as the state information, in addition to the trust of the delegation nodes.

18. The delegated consensus blockchain network management method of claim 17, further comprising:

acquiring next state information and compensation according to the determined action;

in the step of obtaining the next state information and compensation, according to the mathematical formula:

Calculating the malicious node delegation probability

Wherein N is _D In order to delegate the collection of nodes,

19. The delegated common blockchain network management method of claim 18, wherein in the step of obtaining the next state information and compensation,

20. The delegated common blockchain network management method of claim 19, wherein in the step of obtaining the next state information and compensation,

based on the basis of delegationRate of

Three times (1)>

Setting the coefficient condition to G (delta) eta < N so that the N nodes are respectively selected as the times (delta) for delegation nodes to participate in delegation consensus according to the mathematical formula: