KR20220091850A - Managing method for blockchain based on enhanced practical byzantine fault tolerance, blockchain system and node apparatus - Google Patents

Abstract

A practical byzantine fault tolerance (PBFT)-based blockchain information processing method comprises the steps of: transmitting, by a representative node of a blockchain that receives a first request from a client, a pre-preparation message to backup nodes; transmitting, by at least one node of the backup nodes, a preparation message to other nodes excluding itself, the at least one node that is successful in verifying the pre-preparation message; transmitting, by at least one node of the other nodes, a commit message to only a specific group of nodes excluding itself, the at least one node that receives the preparation message from nodes in a number greater than or equal to a first threshold number; and transmitting, by at least one node of the nodes that receive the commit message, a response message to the client, the at least one node that receives the commit message from the nodes in the number greater than or equal to the first threshold number.

Description

Improved PBFT-based blockchain management method, blockchain system and node device

The technology to be described below relates to a consensus technique in the block chain.

Blockchain is a decentralized system in which multiple nodes participate. Blockchain guarantees data integrity and various applications are being studied. Among blockchain technologies, the design of a consensus algorithm is a very important core technology.

The consensus algorithm is a technology that determines which information to select in order to maintain one common DB between nodes when information discrepancy occurs in a P2P network in which multiple nodes exist. The blockchain determines the block creation authority and the technique for forked blockchain selection through a consensus algorithm. Representative consensus algorithms include Proof of Work (PoW), Proof of Stake (PoS), and Practical Byzantine Fault Tolerance (PBFT).

Giuliana Santos Veronese, Efficient Byzantine Fault-Tolerance, IEEE Transactions on Computers Volume: 62, Issue: 1, Jan. 2013

When a block chain branching phenomenon occurs in which blocks with different data occur at the same timestamp, PoW and PoS select the longest-extended block chain thereafter. In such a case, PoW and PoS will lower the data reliability of the blockchain in a way that allows for temporary information inconsistency. On the other hand, PBFT prevents inconsistency of blockchain data by adding blocks to the blockchain only after the normal consensus among nodes for data to be added to the blockchain is completed, thereby improving data reliability. However, PBFT uses a method in which all nodes exchange messages during the consensus process, which causes a lot of load on message exchange. Therefore, it is known that the current PBFT-based blockchain can only be configured with dozens of nodes.

The technology to be described below is intended to provide a PBFT-based consensus technique that reduces the load of message exchange.

The improved PBFT-based blockchain management method comprises the steps of: a representative node of a blockchain that has received a first request from a client, delivers a pre-prepare message to backup nodes, the pre-prepare message among the backup nodes At least one node that has succeeded in verifying transmits a prepare message to the remaining nodes except for itself, and at least one node that receives the prepare message from more than a reference number of nodes among the remaining nodes transmitting a commit message only to nodes in a specific group except for, and at least one node receiving the commit message from nodes equal to or greater than the reference number of nodes receiving the commit message sends a response message to the client including the step of delivering.

The improved PBFT-based blockchain system includes a client device that forwards a first request to a blockchain and a plurality of nodes constituting the blockchain.

The representative node receives the first request, transmits a pre-preparation message to the backup nodes, and at least one node that has succeeded in verifying the pre-prepare message among the backup nodes is selected from among the plurality of nodes except for itself. It sends a ready message to the remaining nodes.

At least one node that receives the preparation message from nodes equal to or greater than the reference number among the remaining nodes transmits the commit message only to nodes of a specific group except itself.

A storage device that stores information about a specific group to which a program for PBFT-based consensus process processing and a commit message will be delivered, receives a preparation message from another node in the PBFT-based consensus process for a client's first request, and stores the commit message and a communication device that transmits to a specific group and a control device that controls to deliver the commit message to nodes belonging to the specific group when the preparation message is received from nodes equal to or greater than a reference number.

The number of nodes constituting the block chain is 3f+1 ≤ N, and the reference number is 2f. The specific group consists of 2f+1 nodes, where f is the threshold number allowed as a failed node in the block chain.

The technology described below limits the subject of message exchange in the PBFT consensus process, so that more nodes can participate in the blockchain. At the same time, the technology described below inherits the advantages of the conventional PBFT as it is.

1 is an example of a PBFT consensus process.
2 is an example of a new consensus process based on PBFT.
3 is an example of a node device of a PBFT-based blockchain.

The technology to be described below can apply various changes and can have various embodiments, and specific embodiments are illustrated in the drawings and described in detail. However, this is not intended to limit the technology described below to specific embodiments, and it should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the technology described below.

Terms such as first, second, A, and B may be used to describe various components, but the components are not limited by the above terms, and only for the purpose of distinguishing one component from other components. is used only as For example, a first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component without departing from the scope of the present invention. and/or includes a combination of a plurality of related listed items or any of a plurality of related listed items.

In terms of terms used herein, the singular expression should be understood to include the plural expression unless the context clearly dictates otherwise, and terms such as "comprises" include the described feature, number, step, operation, element. , parts or combinations thereof are to be understood, but not to exclude the possibility of the presence or addition of one or more other features or numbers, step operation components, parts or combinations thereof.

Prior to a detailed description of the drawings, it is intended to clarify that the classification of the constituent parts in the present specification is merely a division according to the main function each constituent unit is responsible for. That is, two or more components to be described below may be combined into one component, or one component may be divided into two or more for each more subdivided function. In addition, each of the constituent units to be described below may additionally perform some or all of the functions of other constituent units in addition to the main function it is responsible for. Of course, it can also be performed by being dedicated to it.

In addition, in performing the method or method of operation, each process constituting the method may occur differently from the specified order unless a specific order is clearly described in context. That is, each process may occur in the same order as specified, may be performed substantially simultaneously, or may be performed in the reverse order.

Blockchain refers to a chain-type, link-based distributed data storage environment in which small pieces of data called 'blocks' are created based on the P2P method. Blockchain can be divided into public block chain, consortium block chain, and private block chain according to the type of disclosure. The technology described below can be applied to various blockchains regardless of the type of disclosure.

A blockchain consists of multiple blockchain nodes. A blockchain node can be composed of a combination of various devices such as servers, personal terminals, IoT devices, and the like.

In the blockchain, certain data can be encrypted and delivered in the message exchange between nodes. Various encryption methods are applicable. Hereinafter, a public key encryption method as a representative encryption method will be mainly described. A public key and a private key are keys used in public key encryption. The public key is a key that encrypts data, and the private key is a key that decrypts the encrypted data. A public key and a private key are paired with each other and can be randomly generated using various public key encryption methods (eg, RSA, elliptic curve cryptography, etc.).

The technology to be described below relates to a PBFT-based consensus technique. The technology to be described below guarantees the same performance as the previous PBFT while reducing message exchange by improving the protocol of the PBFT.

First, the conventional PBFT consensus algorithm will be briefly described. 1 is an example of a PBFT consensus process 100 .

In the PBFT consensus algorithm, normal agreement is possible when the Byzantine Faulty nodes are below a certain percentage even in an asynchronous network where Byzantine Faulty nodes that do not perform the promised action can exist. A Byzantine faulty node, or simply a faulty node, is a node that does not operate according to the PBFT consensus algorithm. A faulty node may be a node that operates abnormally due to a physical error or an external attack.

The total number of nodes in the blockchain or the number of nodes participating in a specific cluster is called N. In this case, if the number of failed nodes is f, in PBFT, if f is (N-1)/3 or less, consensus can be successful. That is, if N ≥ 3f+1, normal agreement is possible even if a faulty node is included. Therefore, PBFT assumes that N ≥ 3f+1.

It is assumed that nodes participating in the blockchain are connected to each other by network and know the shared key of all other nodes in advance.

The PBFT consensus process 100 is a request step 110, a pre-prepare step 120, a prepare step 130, a commit step 140, and a reply (Reply) Step 140 may be configured.

A client is a device that delivers a certain transaction to the block chain. The client may be a device such as a PC, a smart device, or a server. 1 shows a client in the form of a PC.

Nodes are devices that are connected to a network and compose a blockchain. 1 exemplarily shows four nodes (node 1 to mode 4). A node that initially receives and processes a predetermined request from a client device among nodes is called a primary node. The representative node receives messages from the client and plays a role in determining the order of these messages. The representative node may be set in advance. 1 is an example in which node 1 (mode 1) is a representative node. A node excluding the representative node among the nodes is also called a backup node. In FIG. 1 , node 2 (node 2), node 3 (node 3), and node 4 (node 4) are backup nodes.

In the request step, the client transmits a certain request to the blockchain (or cluster) (110). In some cases, the client may forward a request to all nodes. According to the basic protocol of PBFT, it is assumed that the client forwards the request to the representative node.

A view is a unit of period during which a representative node acts as a representative node. A representative node of the view v may be v mod Nth node.

Node 1, the representative node, receives the request message <REQUEST, o, t, c>s _c from the client. o is the operation requested by the client, t is a time stamp, and c is an identifier that can identify the client. The client sends its request message with its signature sc with o, t and _c .

When the node 1 receives a valid request in the pre-preparation step 120 , it assigns a sequence number n indicating the order of the corresponding request. Node 1 can verify that the message is valid by decrypting the signature _sc with the public key. In the pre-preparation step 120 , node 1 delivers (distributes) a pre-prepare message <PRE-PREPARE, v, n, D(m)>s _p to the backup node. n is a sequence number, v is the view to which the current message is transmitted, and D(m) is the summary of the request message m. D(m) may be a hashing value of message m delivered by the client. Node 1 sends its own signature _sp along with v, n, and D(m) and sends a pre-preparation message.

In the preparation step 130, each of the backup nodes (node 2 ~ node 4) verifies the pre-preparation message delivered by the representative node (node 1), and if the verification result is true, each of the other nodes transmits the Prepare message do. The backup node verifies whether D(m), V, and N correspond to each other. As a result of verification, if the values do not correspond to each other, the backup node does not accept the pre-ready message. If the result is true, the backup node generates a ready message <PREPARE, v, n, d, i)>s _i and forwards it to all other nodes in the network. n is a sequence number, v is the view to which the current message is transmitted, D(m) is the summary of the request message m, and i is the identifier of the backup node. s _i is the signature of node i. For example, in FIG. 1 , node 2 verifies the pre-preparation message, and if the verification result is true, the node 2 transmits the ready message to all other nodes, i.e., Node 1, Node 3, and Node 4.

Each node collects pre-ready messages and ready messages to determine the number of received messages. If the number of pre-prepared messages is 2f+1 and the number of ready messages is 2f or more, the backup node determines that it is a prepared certificate.

Each node that has received the preparation message in the commit step 140 transmits a commit message to other nodes when it is in the readiness verification state. That is, if the node has more than 2f Prepare messages and the prepare message is true, the node delivers the commit message <COMMIT, v, n, D(m), i)>s _i . n is a sequence number, v is the view to which the current message is transmitted, D(m) is the summary of the request message m, and i is the identifier of the backup node. s _i is the signature of node i.

Each of the nodes receiving the commit message counts the number of received commit messages. Each node determines that it is a commit certificate if more than 2f+1 commit messages including itself are received. In the response step 150 , each node transmits a response message to the client when it is in the commit verification state. That is, in the response step 150 , when the number of received commit messages is 2f+1 or more, each node transmits the response message to the client. Also in the response step 150 , each node may verify whether D(m), V, and N correspond to each other.

In response step 150, each node delivers the response message <RELPY, v, t, c, i, r)>s _ic to the client when the commit message is true and the number of commit messages it has received is 2f+1 or more do. v is the view where the current message is transmitted, t is the time stamp, c is the client identifier, i is the node identifier, and r is the execution result. s _ic is the signature of the node forwarding the response message. Also, when each node receives a commit message of the same value from 2f+1 or more other nodes, it can add the block of the transaction created by the client to the chain.

In response step 150, when the client receives the same response message from f+1 or more nodes, it confirms that the result according to its request has been processed.

2 is an example of a new consensus process 200 based on PBFT. Figure 2 corresponds to the consensus process in the blockchain system.

The total number of nodes in the blockchain or the number of nodes participating in a specific cluster is called N. In this case, if the number of failed nodes is f, in PBFT, if f is (N-1)/3 or less, consensus can be successful. That is, if N ≥ 3f+1, normal agreement is possible even if a faulty node is included. Therefore, PBFT assumes that N ≥ 3f+1. 2 is a case in which node 1 (node 1) is a faulty node.

It is assumed that nodes participating in the blockchain are connected to each other by network and know the shared key of all other nodes in advance.

The new PBFT consensus process 200 includes a request step 210, a pre-prepare step 220, a prepare step 230, a commit step 240, and a reply ) step 240 .

A client is a device that delivers a certain transaction to the blockchain. The client may be a device such as a PC, a smart device, or a server. 2 shows a client in the form of a PC.

Nodes are devices that are connected to a network and compose a blockchain. 2 exemplarily shows four nodes (nodes 1 to 4). The representative node receives messages from the client and plays a role in determining the order of these messages. In view v, the representative node may be v mod Nth node. 2 is an example in which node 1 is a representative node.

A node excluding the representative node among the nodes is also called a backup node. In FIG. 1 , node 2 (node 2), node 3 (node 3), and node 4 (node 4) are backup nodes.

In the request step, the client transmits a certain request to the block chain (or cluster) (210). In some cases, the client may forward a request to all nodes. According to the basic protocol of PBFT, it is assumed that the client forwards the request to the representative node.

Node 1, the representative node, receives the request message <REQUEST, o, t, c>s _c from the client. o is the operation requested by the client, t is a time stamp, and c is an identifier that can identify the client. The client sends its request message with its signature sc with o, t and _c .

In the pre-preparation step 220 , when receiving a valid request, node 1 assigns a sequence number n indicating the order of the request. Node 1 can verify that the message is valid by decrypting the signature _sc with the public key. In the pre-preparation step 120 , node 1 delivers (distributes) the pre-preparation message <PRE-PREPARE, v, n, D(m)>s _p to the backup node. n is the sequence number, v is the view to which the current message is transmitted, and D(m) is the summary of the request message m. D(m) may be a hashing value of the message m delivered by the client. Node 1 sends its own signature _sp along with v, n, and D(m) and sends a pre-preparation message.

In the preparation step 230 , each of the backup nodes (node 2 to node 4) verifies the pre-preparation message delivered by the representative node (node 1), and if the verification result is true, each of the backup nodes (node 2 to node 4) transmits the preparation message to the remaining nodes. The backup node verifies whether D(m), V, and N correspond to each other. As a result of verification, if the values do not correspond to each other, the backup node does not accept the pre-ready message. If the result is true, the backup node generates a ready message <PREPARE, v, n, d, i)>s _i and forwards it to all other nodes in the network. n is a sequence number, v is the view to which the current message is transmitted, D(m) is the summary of the request message m, and i is the identifier of the backup node. s _i is the signature of node i. For example, in FIG. 2 , node 2 verifies the pre-preparation message, and if the verification result is true, the node 2 transmits the ready message to all other nodes, i.e., node 1, node 3, and node 4.

Each node collects pre-ready messages and ready messages to determine the number of received messages. If the number of pre-ready messages is 2f+1 and the number of ready messages is 2f or more, the backup node determines that it is readiness verification.

Each node that has received the preparation message in the commit step 240 transmits the commit message to other nodes when it is in the readiness verification state. At this time, each node does not deliver the commit message to all other nodes, but only delivers the commit message to specific nodes. Here, a group composed of specific nodes is called a commit group. That is, in the consensus process of FIG. 2 , unlike FIG. 1 , a target for transmitting a commit message is limited.

A commit group consists of 2f+1 nodes. Members of a commit group can be set in advance. The commit group may be determined to be any 2f+1 nodes among all nodes at the time the representative node is determined. Accordingly, the commit group may be updated again when the view is changed. 2 is an example in which node 1, node 2, and node 3 constitute a commit group.

Each node has 2f or more Prepare messages, and if the prepare message is true, the commit message <COMMIT, v, n, D(m), i)>s _i is delivered to the commit group. n is a sequence number, v is the view to which the current message is transmitted, D(m) is the summary of the request message m, and i is the identifier of the backup node. s _i is the signature of node i.

Each of the nodes receiving the commit message counts the number of received commit messages. Each node determines that it is a commit certificate when there are 2f+1 or more received commit messages. In response step 250 , each node transmits a response message to the client when it is in the commit verification state. That is, in response step 250 , each node transmits a response message to the client when the number of received commit messages is 2f+1 or more. In the response step 250 , each node may verify whether D(m), V, and N correspond to each other.

In response step 250, each node delivers the response message <RELPY, v, t, c, i, r)>s _ic to the client when the commit message is true and the number of commit messages it has received is 2f+1 or more do. v is the view where the current message is transmitted, t is the time stamp, c is the client identifier, i is the node identifier, and r is the execution result. s _ic is the signature of the node forwarding the response message. Also, when each node receives a commit message of the same value from 2f+1 or more other nodes, it can add the block of the transaction created by the client to the chain.

Also, a node that does not belong to the commit group (Node 4) can deliver a response message to the client. Assume that the sequence number for the message currently requested by the client is 101. Node 4 receives a message (at least one of a request message, a pre-ready message, or a ready message) for a subsequent request (sequence number 102) in the state that there are 2f or more ready messages (sequence number 101) according to the client's current request. case, a response message to the previous preparation message (sequence number 101) may be delivered to the client (indicated by a dotted arrow in FIG. 2).

In response step 250, when the client receives the same response message from 2f+1 or more nodes, it confirms that the result according to its request has been processed. A client may wait until it receives 2f+1 identical response messages.

Although the number of message exchanges in the commit phase of FIG. 1 is (3f) ² , the number of message exchanges in the commit phase of FIG. 2 is (3f) × (2f). Accordingly, according to the consensus process of FIG. 2, the number of message exchanges is reduced.

Meanwhile, in the response step of FIG. 2 , the client must receive 2f+1 or more response messages to confirm that the processing of its own request is completed.

The blockchain consensus process in Fig. 2 satisfies the conditions for the factors necessary for decision-making in traditional PBFT. Accordingly, the consensus process of FIG. 2 may be performed in the same manner as in the conventional PBFT.

3 is an example of a node device 300 of a PBFT-based blockchain. The node device 300 is a constituting node that is a block chain. The node device 300 may be a representative node or a backup node. The node device 300 may be any one of various types, such as a smart device, a PC, or a server on a network.

The node device 300 may include a storage device 310 , a memory 320 , an arithmetic device 330 , an interface device 340 , a communication device 350 , and an output device 360 .

The storage device 310 stores a program for processing the PFBT-based consensus process.

The storage device 310 may store information (eg, an identifier) on a specific group (commit group) to which a commit message is to be transmitted.

The storage device 310 may store blocks of transactions.

The memory 320 may store temporary data generated while the node device 300 processes a request and a message.

The interface device 340 is a device that receives a predetermined command or information from a user or an external input device.

The communication device 350 refers to a configuration for receiving and transmitting predetermined information through a network. Communication device 350 may receive certain requests from client devices. Communication device 350 may receive messages from other nodes. For example, the communication device 350 may receive a pre-preparation message, a prep message, and a commit message.

The communication device 350 may receive information about the commit group. When the representative node determines the commit group, the communication device 350 may receive information about the commit group from the representative node.

The communication device 350 may transmit a message generated during the consensus process to another node or a client device. For example, the communication device 350 may transmit a pre-prepare message, a prepare message, and a commit message to another node. The communication device 350 may send a response message to the client device.

The control device 330 is a device that processes an input message and controls the operation of the node device 300 . The control device 330 may be a device such as a processor, an AP, or a program embedded chip that processes data and processes a predetermined operation.

The control device 330 may verify the received message. The control device 330 may hash the received request message m and compare it with D(m) included in the current message. Also, the control device 330 may decrypt the signature included in the message and verify whether the identifier of the node that transmitted the message is correct.

The control device 330 may determine a commit group by selecting arbitrary nodes from among candidate nodes when the view v is changed. The control device 330 may select 2f+1 nodes to determine a commit group.

The control device 330 may generate a specific message in each step of the consensus process and transmit it to another node through the communication device 250 .

When the current node device 300 does not belong to the commit group, the control device 330 receives the preparation message (first sequence number) for the first request from 2f or more nodes, When a preparation message for the second request having the second sequence number is received, a response message for the first request is transmitted to the client device through the communication device 350 .

The output device 360 may output certain information.

In addition, the blockchain consensus method or the operation method of the node device as described above may be implemented as a program (or application) including an executable algorithm that can be executed in a computer. The program may be provided by being stored in a temporary or non-transitory computer readable medium.

The non-transitory readable medium refers to a medium that stores data semi-permanently, rather than a medium that stores data for a short moment, such as a register, cache, memory, and the like, and can be read by a device. Specifically, the above-described various applications or programs are CD, DVD, hard disk, Blu-ray disk, USB, memory card, ROM (read-only memory), PROM (programmable read only memory), EPROM (Erasable PROM, EPROM) Alternatively, it may be provided by being stored in a non-transitory readable medium such as an EEPROM (Electrically EPROM) or flash memory.

Temporarily readable media include Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (Enhanced) SDRAM, ESDRAM), Synchronous DRAM (Synclink DRAM, SLDRAM) and Direct Rambus RAM (Direct Rambus RAM, DRRAM) refers to a variety of RAM.

This embodiment and the drawings attached to this specification only clearly show a part of the technical idea included in the above-described technology, and within the scope of the technical idea included in the specification and drawings of the aforementioned technology, those skilled in the art can easily It will be said that it is obvious that all inferred modified examples and specific embodiments are included in the scope of the above-described technology.

Claims (13)

transmitting a pre-prepare message to the backup nodes by the representative node of the block chain that has received the first request from the client;
at least one node that has succeeded in verifying the pre-preparation message among the backup nodes transmits a prepare message to the remaining nodes except for itself;
transmitting, by at least one node receiving the preparation message from nodes equal to or greater than the reference number of the remaining nodes, a commit message only to nodes of a specific group except itself; and
At least one node receiving the commit message from nodes equal to or greater than the reference number among the nodes receiving the commit message transmits a response message to the client,
The representative node and the backup nodes constitute the block chain,
The improved PBFT-based blockchain management method in which the specific group consists of a number of nodes less than the total number of nodes belonging to the block chain - 1. According to claim 1,
The number of nodes constituting the block chain is 3f+1 ≤ N,
The reference number is 2f, and f is the threshold number allowed as a faulty node in the blockchain. An improved PBFT-based blockchain management method. According to claim 1,
The number of nodes constituting the block chain is 3f+1 ≤ N,
The specific group consists of 2f+1 nodes, and f is the threshold number allowed as a failed node in the blockchain. An improved PBFT-based blockchain management method. According to claim 1,
The number of nodes constituting the block chain is 3f+1 ≤ N,
The client determines that the first request has been processed normally when the number of nodes that transmit the response message is 2f+1 or more, and f is an improved PBFT-based block that is the threshold number allowed as a failed node in the block chain. How to manage the chain. 5. The method of claim 4,
At least one node that does not belong to the specific group
When a preparation message for a second request having a sequence number after the first request is received in a state in which the preparation message is received from the nodes of the first threshold number or more, a response message to the first request is sent to the client An improved PBFT-based blockchain management method to deliver. According to claim 1,
The improved PBFT-based blockchain management method in which the specific group is arbitrarily determined from among the nodes constituting the blockchain, and the configuration of the specific group is updated when the representative node of the blockchain is changed. a client device forwarding the first request to the blockchain; and
Including a plurality of nodes constituting the block chain,
The plurality of nodes includes a representative node and a backup node,
The representative node receives the first request, transmits a pre-prepare message to the backup nodes, and at least one node that succeeds in verifying the pre-prepare message among the backup nodes is selected from the plurality of Delivers a Prepare message to the remaining nodes except for itself among the nodes,
At least one node that receives the preparation message from nodes equal to or greater than the reference number among the remaining nodes transmits a commit message only to nodes in a specific group except for itself,
An improved PBFT-based blockchain system in which the specific group is composed of a number of nodes less than the total number of nodes belonging to the blockchain. 8. The method of claim 7,
The number of nodes constituting the block chain is 3f+1 ≤ N,
The specific group consists of 2f+1 nodes, and f is the threshold number allowed as a failed node in the blockchain. An improved PBFT-based blockchain system. 8. The method of claim 7,
The number of nodes constituting the block chain is 3f+1 ≤ N,
The improved PBFT-based blockchain system in which the client device determines that the first request has been normally processed when the number of nodes that transmit a response message is 2f+1 or more, and f is a faulty node in the blockchain. 10. The method of claim 9,
At least one node that does not belong to the specific group
When a preparation message for a second request having a sequence number after the first request is received in a state in which the preparation message is received from the nodes of the first threshold number or more, a response message to the first request is sent to the client An improved PBFT-based blockchain system that delivers. a storage device for storing information about a specific group to which a program and a commit message for PBFT (Practical Byzantine Fault Tolerance)-based consensus process processing will be delivered;
a communication device for receiving a Prepare message from another node in a PBFT-based consensus process for a client's first request, and transmitting the commit message to the specific group; and
Including a control device for controlling to deliver the commit message to the nodes belonging to the specific group when the preparation message is received from nodes greater than or equal to a reference number,
The number of nodes constituting the block chain is 3f+1 ≤ N, and the reference number is 2f,
The specific group consists of 2f+1 nodes, and f is a node device of a blockchain operating with an improved PBFT-based consensus algorithm, which is the threshold number allowed as a failed node in the blockchain. 12. The method of claim 11,
If the node device does not belong to the specific group,
the control device
When receiving a preparation message for a second request having a sequence number subsequent to the first request in a state in which the preparation message is received from the nodes equal to or greater than the reference number, a response message to the first request is sent to the communication device A node device in the blockchain that operates with an improved PBFT-based consensus algorithm that delivers it to the client through 12. The method of claim 11,
The information on the specific group is a node device of a block chain that operates with an improved PBFT-based consensus algorithm that is arbitrarily determined at the time of setting or changing the representative node of the block chain.

Images