KR102081159B1 - A Blockchain system and a method for a plurality of nodes in the Blockchain system to verify and propagate messages - Google Patents

Abstract

The present invention provides a block chain system and a method in which a plurality of nodes verify and propagate messages in the same which can efficiently use network resources and processing capabilities. According to an embodiment of the present invention, the method in which a plurality of nodes verify and propagate messages in a block chain system consisting of a distributed network of at least one logical node including a plurality of trusted nodes and at least one public node comprises: a step in which a first trusted node in the logical node receives a message propagated in a block chain network; a step in which the first trusted node verifies a trust relationship with a node which has transmitted the message; a step in which the first trusted node determines whether the validity of the message is verified by a second trusted node if the node which has transmitted the message is confirmed to be the public node; and a step in which the first trusted node propagates the message in the block chain network if the validity verification of the message by the second trusted node is confirmed and verifies the validity of the message to propagate a message with verified validity in the block chain network if the validity verification of the message by the second trusted node is not confirmed.

Description

A blockchain system and a method for a plurality of nodes in the Blockchain system to verify and propagate messages}

The present invention relates to a blockchain system, and to a method of verifying and propagating a message by a plurality of nodes in a blockchain system.

Blockchain originated from the method of linking blocks to blocks in Satoshi Nakamoto's Bitcoin: A Peer-to-Peer Electronic Cash System in 2008. Blockchain has been recognized as an indispensable technology in cryptocurrency because of its shared ledger among peers, its contents transparently disclosed, and its immutable nature. And now blockchain is showing not only the technology for cryptocurrency but also its applicability in various industries. Blockchain is based on a decentralized P2P network. P2P means 'peer-to-peer' and refers to a network in which each terminal communicates on an equal basis without a central server. Each terminal is both a server and a client at the same time. The peers that make up the blockchain network keep a copy of the ledger and decide on the behavior of the ledger. That is, nodes decide whether to accept a block, generate the next block, or propagate the received block back to neighboring nodes. Nodes are independent entities and do not need to trust other nodes connected to them. In other words, nodes that do not need to trust each other interact with each other according to the digital transaction technology through the blockchain, which is a distributed book, to achieve data integrity and authentication, and trust is naturally established accordingly. However, inefficiency of blockchain network resources and processing power appears in the process of data integrity and authentication. Each of the nodes performs multiple data replications for keeping a copy of the ledger. In addition, in accordance with the propagation of blocks and transactions between nodes, duplicate data transmission and validation of the same block are performed in each of the nodes, resulting in overlapping processing of block verification. This problem has been recognized as a difficult problem to solve in a blockchain system that guarantees the stability of transactions between nodes that do not trust each other through a distributed trust network. In order to solve the conventional problem, there have been efforts to increase the performance efficiency of the blockchain network by developing various consensus algorithms, optimizing existing consensus algorithms, and limiting the number of nodes having the right to create blocks. However, in the prior art, there are optimization conditions for consensus algorithm or block creation authority depending on the type of business model using blockchain technology, and these conditions sometimes do not correspond to network performance improvement. In addition, the fact that a specific algorithm for uniformly improving network performance cannot be uniformly applied to an enterprise service environment providing various services is a significant obstacle to solving the above-mentioned problems.

Korean Patent Publication No. 10-2018-0113140

An object of the present invention is to solve the problem that the one-way data transmission occurs in the blockchain system regardless of whether or not the data is retained by the other node, and that the same data is repeatedly delivered several times, thereby inefficiently operating the network.

In addition, an object of the present invention is to solve the inefficiency of the network operation by verifying the validity of the data every time the node itself every time data is received in the blockchain system.

In addition, an object of the present invention is to solve the inefficiency of the network operation of the existing blockchain system in the enterprise service environment in which the service provider operates a plurality of nodes for stable service operation.

That is, one object of the present invention is to provide a blockchain system that can efficiently use network resources and processing power among a plurality of nodes having a trust relationship with each other.

An embodiment is a method of a plurality of nodes verifying and propagating a message in a blockchain system consisting of at least one logical node comprising a plurality of trusted nodes and a distributed network of at least one public node, the method comprising: a first node in the logical node; The trusted node receiving a message propagated on the blockchain network; Verifying, by the first trusted node, a trust relationship with the node that transmitted the message; If it is determined that the node that transmitted the message is the public node, the first trusted node determines whether to validate the message by a second trusted node; And if the first trusted node propagates the message on the blockchain network when the validation of the message by the second trusted node is confirmed, and if the validation of the message by the second trusted node is not verified Providing a validity of the message and propagating the validated message on the blockchain network may provide a method for verifying and propagating a message by a plurality of nodes in a blockchain system.

In another aspect, the receiving of a message propagated on the blockchain network by the first trusted node may include: sending the message to the logical node by the public node accessing the logical node through an address identifying the logical node. Making; The logical node selecting the first trusted node of the plurality of trusted nodes; And transmitting, by the logical node, the message to the selected first trusted node. The method may provide a method for verifying and propagating a message by a plurality of nodes in a blockchain system.

In another aspect, the first trusted node to verify the trust relationship with the node that sent the message, the first trusted node in response to receiving the message, the IP address list information, the pre-stored information in response to receiving the message, A blockchain that verifies the trust relationship with the node that transmitted the message based on at least one of receiving a certificate from the transmitting node, a blockchain address of the node that transmitted the message, and signature information according to the validity of the message. A plurality of nodes in a system can provide a method for verifying and propagating a message.

In another aspect, the first trust node determines whether the message is validated by a second trust node, wherein the first trust node stores the message on a database shared with the second trust node. Confirming; And when the storage of the message is confirmed, determining that the validation of the message is completed. The method may provide a method for verifying and propagating a message by a plurality of nodes in a blockchain system.

In another aspect, propagating a message on the blockchain network, wherein the first trust node is the message to at least some of the nodes other than trust nodes in the logical node of the plurality of nodes. In a blockchain system that propagates, a plurality of nodes may provide a method for verifying and propagating a message.

In another aspect, the group of nodes of the plurality of nodes sharing a database in which a local copy of the blockchain is stored in the logical node; further comprising a plurality of nodes in the blockchain system to verify and propagate the message It may provide a method.

The present invention can provide a method for verifying a trust relationship between a plurality of physical nodes in a logical node.

In addition, the present invention can reduce the computing power of the logical node by preventing the redundant processing of data validation among the physical nodes in the logical node.

In addition, the present invention can add new trusted nodes and handle more traffic without having to secure a large amount of storage space in the logical node.

In addition, the present invention can reduce the amount of data transfer between physical nodes in a logical node.

In addition, the present invention reduces the possibility of blockchain system paralysis caused by generating a large amount of malicious packets or requests by increasing the number of physical nodes in a logical node and increases the possibility of avoiding from external attacks.

In addition, the present invention can reduce the traffic according to the blockchain system running in an enterprise business environment that requires a large number of servers, such as online game services. Therefore, the network speed of business services can be prevented from being lowered and network operation maintenance costs can be reduced.

The effects obtainable in the present invention are not limited to the above-mentioned effects, and other effects not mentioned may be clearly understood from the following description.

1 and 2 show an overview of a blockchain system composed of a distributed network of a plurality of nodes.
3 is an exemplary flowchart for a method for verifying and propagating a message by a plurality of nodes in a blockchain system according to an embodiment of the present invention.
4 is an exemplary flowchart for a method of verifying and propagating a transaction history when the message of FIG. 3 is a transaction history.
5 is an exemplary flowchart for a method of verifying and propagating a block when the message of FIG. 3 is a block.
FIG. 6 is another exemplary flowchart for a method of verifying and propagating a block when the message of FIG. 3 is a block.

As the invention allows for various changes and numerous embodiments, particular embodiments will be illustrated in the drawings and described in detail in the written description. Effects and features of the present invention, and methods for achieving them will be apparent with reference to the embodiments described below in detail in conjunction with the drawings. However, the present invention is not limited to the embodiments disclosed below but may be implemented in various forms. In the following embodiments, the terms first, second, etc. are used for the purpose of distinguishing one component from other components rather than a restrictive meaning. Also, the singular forms “a”, “an” and “the” include plural forms unless the context clearly indicates otherwise. In addition, the terms including or have means that the features or components described in the specification are present, and does not exclude in advance the possibility that one or more other features or components will be added. In addition, in the drawings, the components may be exaggerated or reduced in size for convenience of description. For example, the size and thickness of each component shown in the drawings are arbitrarily shown for convenience of description, and thus the present invention is not necessarily limited to the illustrated.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings, and the same or corresponding components will be denoted by the same reference numerals, and redundant description thereof will be omitted. .

1 and 2 show an overview of a blockchain system composed of a distributed network of a plurality of nodes.

The system described below constitutes a peer-to-peer network architecture structure on a network. That is, all users participating in the system have equal status, no special nodes exist, and all nodes share the role of configuring network services. Multiple nodes on a network are connected to each other in a mesh network with equivalent topologies. Even if the nodes in the network are at equal places, their roles may differ depending on the functionality they support.

Every node has a routing function in the network and may include other functions. Every node can perform the function of verifying and propagating various data, including messages (data) about transactions and blocks, and maintaining a connection with neighboring nodes. Transactions herein include not only financial transactions or virtual currency transactions but also various transactions according to smart contracts. Therefore, it should be noted that the meaning of a transaction herein is not limited to a specific transaction.

Users can vary from ordinary individuals to organizations, communities, large groups, and can contain other types of entities.

Nodes connected to the network can be defined as physical nodes that are independent devices. Some of the physical nodes may be grouped into logical nodes. Nodes not grouped into logical nodes can be defined as public nodes. There may be at least one logical node on the network. There may be a plurality of physical nodes within a logical node. Physical nodes grouped into logical nodes may be defined as trusted nodes that trust each other through a process of verifying a certain trust relationship, and public nodes not grouped into logical nodes may be defined as untrusted nodes. In addition, at least some physical nodes within a logical node may share a database that is a common repository. Alternatively, public nodes, which are untrusted nodes, may have a database that is their own repository.

As shown in FIG. 1, the blockchain system 10 may be composed of first to nth public nodes 101a to 101n and first to nth logical nodes 103a to 103n connected to a blockchain network. . Each of the first to nth logical nodes 103a to 103n may include a plurality of physical nodes. The first logical node 103a may include first to mth physical nodes 102a to 102m.

Although a plurality of physical nodes in one logical node are individual nodes on the blockchain network, a trust relationship may be formed between them through a predetermined verification process during the operation of the blockchain system. By way of example, the owners of a plurality of physical nodes in either logical node may be the same.

In some embodiments, each of the affiliates in any parent company may be a node of each of the affiliates it manages.

In some embodiments, a plurality of physical nodes within any one logical node may be in a relationship sharing at least one database.

In some embodiments, multiple physical nodes may be viewed as either logical node when grouped according to a particular criterion.

In some embodiments, the plurality of physical nodes may be nodes installed in a facility that aggregates and centralizes servers that are the core of an Internet connection, such as the Internet Data Center. However, at least some of the plurality of physical nodes may not be concentrated in a certain area, but may be nodes installed at a geographically remote location.

In some embodiments, a user, such as an enterprise, may have multiple physical nodes as one logical node for the purpose of responding to a DDOS attack, distributing load, etc. and allowing these multiple physical nodes to be separate nodes on a blockchain system. Can be.

In some embodiments, a plurality of physical nodes within a logical node monopolizes the right to create a block, a block generation right is granted to the logical node in various ways, such as when the frequency of having a block generation right is higher than that of the public nodes or by inference. In this case, it increases the likelihood that a malicious attack to negatively affect the operation of the blockchain system will be concentrated on the logical node. Thus, having multiple physical nodes within a logical node reduces the likelihood of system paralysis resulting from malicious mass packets or requests, and increases the likelihood of evasion from external attacks by distributing block creation rights to multiple physical nodes. In addition, even when a logical node delegates a block generation authority to an arbitrary node, any one of a plurality of physical nodes within the logical node may allow a node to delegate block generation authority to an arbitrary node. Lower the likelihood of inhibition of usefulness.

Each node may comprise a server, an interface, a system, a database, an agent, a peer, an engine, a controller, or any other type of computing device that works individually or collectively, or may be configured with any suitable combination of computing devices to read all computing languages. Can be. The computing device may include a processor configured to execute software instructions stored on a non-transitory computer readable storage medium (eg, hard drive, solid state drive, RAM, flash, ROM, etc.). Preferably, the software instructions are configured so that the computing device can provide the various functions described below. In addition, the disclosed techniques may be embodied as a computer program product including a non-transitory computer readable medium storing software instructions for causing a processor to execute the disclosed steps. Preferably, various servers, systems, databases and interfaces may exchange data using HTTP, HTTPS, AES, public / private key exchange, web services APIs, known financial transaction protocols or other electronic based standardized protocols or algorithms. Can be. Preferably, the data exchange may be performed via a packet switched network, the Internet, a LAN, a WAN, a VPN or other type of packet switched network.

New physical nodes that do not belong to a logical node or within a particular logical node may participate in the system 10.

A new node may first search for other nodes present on the network to join the system 10. To begin this process, a new node may need to discover and connect to at least one existing node on the network. Each node can connect a TCP connection to a specific numbered port or to an alternate port, so that the new node connects to a known neighbor. The new node may respond to the request by sending a connection request message to the neighbor node and the neighbor node sends a grant message to the new node when the neighbor node approves the connection request. After one or more connections are established, the new node can send address messages containing its IP addresses to neighboring nodes. In turn, neighboring nodes can send the received address message to their neighboring nodes so that the newly connected node is better known and connected with other nodes. In addition, the newly connected node may request that the IP address list of other neighbor nodes be transmitted again by sending an address request message to the neighbor nodes. In this way, a node can search for neighboring nodes that are connected to it and can promote its presence on the network so that other nodes can search for it.

At least some of the nodes of the plurality of nodes may store a copy of the entire blockchain or at least a copy corresponding to a subset of the blockchain in their respective databases. In addition, multiple physical nodes within a logical node may share a database. And there can be multiple databases shared.

Blockchain consists of a decentralized computer system consisting of immutable blocks made up of transactions. Each block in the blockchain contains the hash of the previous block, so the blocks are linked together to create a record of all transactions written to the blockchain from the beginning. Blocks are dependent on previous blocks, making them nearly impossible to disassemble, modify, and reconstruct, and they are distributed and robust because each node owns them. In some embodiments, at least one transaction history is recorded in one block. Transaction history may be configured to be a hash so that no forgery occurs. Each block and transaction can manage the hash value and the timestamp of when the data occurred, preventing tampering and tracking the transaction history. In addition, in financial transactions, such as virtual currency, nodes store blockchain ledgers and wallet applications, allowing users to perform transactions and other related functions over the network in a secure and reliable manner.

When a transaction is sent to one node connected to the blockchain network, the transaction can be validated by that node. Once a transaction has been validated, it can be propagated to other nodes connected to that node and at the same time a success message can be sent to the producer. If the transaction is not valid, the node can reject the acknowledgment and at the same time a reject message can be returned to the producer. Blockchain network is a P2P based network. This means that each node starts up and is connected to several other nodes found through the P2P protocol. The entire network forms a loosely connected mesh without a fixed topology or specific structure, so that all nodes can have the same topology. Messages such as transactions and blocks are propagated from each node to other neighboring nodes connected to them. Validation transactions newly added to nodes on the network are sent to a plurality of neighboring nodes, and each transaction is again sent to a plurality of neighboring nodes, and the process is repeated. In this way, a valid transaction will create an exponential wave of propagation in a matter of seconds, and eventually all connected nodes will receive the transaction.

Each of the plurality of trusted nodes in the logical node has its own IP address and the IP address can be published on the blockchain network. Thus, any public node can send messages such as transactions and blocks to at least one of the plurality of trusted nodes in a particular logical node via the blockchain network. That is, since the plurality of trusted nodes in the logical node are recognized as individual nodes on the blockchain system 10, the public nodes can recognize each of the plurality of trusted nodes as individual nodes.

Meanwhile, if the transaction details of the messages propagated between the nodes in the blockchain system 10 are verified by more than a predetermined number of nodes, the corresponding transaction details may be approved. That is, when more than a predetermined number of nodes verify the validity of the transaction history, the transaction history becomes a trusted transaction history on the blockchain network, and a transaction related to the transaction history may be finally approved. In this case, if any one physical node in the logical node recognizes the specific transaction details as valid, all the physical nodes that have received the corresponding transaction details consequently validate the corresponding transaction details. Therefore, as the number of physical nodes included in the logical node increases, the number of nodes that have validated the transaction details easily meets the preset criteria for final approval of the transaction. Therefore, as the number of physical nodes grouped into logical nodes increases, the reference number of nodes that have recognized the validity of the transaction details for the final approval of the transaction may also increase. In contrast, when some of the physical nodes grouped into logical nodes are removed, the corresponding reference number may decrease. That is, it is possible to maintain the stability of the approval of the transaction details by allowing the reference number of the nodes that recognize the validity of the transaction details for the final approval of the transaction to be dynamically changed to the number of physical nodes in the logical node.

In some embodiments, a logical node may have a representative IP address representing all trusted nodes belonging to it. The representative IP address can be published on the blockchain network, and the public node can send a message to the logical node via the representative IP address. Thus, each of the plurality of logical nodes on the blockchain system 10 may be recognized as a separate node. In other words, the public nodes may recognize the logical nodes themselves as one node instead of the trusted nodes in the logical nodes as individual nodes.

Referring to FIG. 2, for example, the first logical node 103a includes the first to mth physical nodes 102a to 102m, and the first logical node 103a includes the first to mth physical nodes ( 102a to 102m) may have a representative IP. In addition, the first logical node 103a may include a message distribution device 200. When receiving the message transmitted from the blockchain network, the message distribution device 200 may select any one of the first to mth physical nodes 102a to 102m and transmit the received message to the selected node.

The message distribution device 200 may be any one of a router, a switch, and a hub, but is not limited thereto. When a message is received through a node connected through a representative IP, the message distribution device 200 selects one of the trusted nodes and selects one of the trusted nodes. Any device capable of sending messages is possible.

In some embodiments, the public node may query the DNS server for an IP address corresponding to a particular domain and send a message to a logical node or a trusted node within the logical node via the IP address received from the DNS server.

Referring to FIG. 2, an IP address of each of the first to mth physical nodes 102a to 102m in the first logical node 103a may be registered in the DNS server 300. The DNS server 300 may transmit an IP address of each of the first to m th physical nodes 102a to 102m to the corresponding node in response to a query from the node. At this time, the DNS server 300 may return the IP address registered in a round robin manner. However, it is not limited thereto. The node receiving the IP address from the DNS server 300 may transmit a message to the node matching the received IP address.

In some embodiments, the DNS server 300 may register a representative IP address of the first logical node 103a. The public node may request the representative IP address of the first logical node 103a from the DNS server 300. DNS server 300 may send a representative IP address to the public node in response to this request. The public node may send a message to the first logical node 103a via the received representative IP address. Upon receiving the message, the first logical node 103a may select one of the first to mth physical nodes 102a to 102m in the first logical node 103a and transmit the received message to the selected physical node. In some embodiments, the message distribution device 200 may be a load balancer. The IP address of the load balancer may become a representative IP address of the logical node and may be registered in the DNS server 300. When the message is received, the load balancer may select any one of the plurality of physical nodes determined according to the performance ratio of the plurality of physical nodes in the preset logical node and transmit the received message to the selected physical node.

FIG. 3 is an exemplary flowchart illustrating a method of verifying and propagating a message by a plurality of nodes in a blockchain system according to an exemplary embodiment of the present invention. FIG. 4 is a flowchart illustrating a transaction history when the message of FIG. 3 is a transaction history. 5 is an exemplary flow chart of a method of propagating and verifying a block when the message of FIG. 3 is a block, and FIG. 6 is a block diagram of a block when the message of FIG. 3 is a block. Another exemplary flow chart for a method of verifying and propagating.

Referring to FIG. 3, a method S100 of verifying and propagating a message by a plurality of nodes in a blockchain system according to an exemplary embodiment of the present invention will be described.

When the first physical node 102a in the first logical node 103a receives the message (S110), it may verify (S120) a trust relationship between the node that sent the message and itself.

A method of verifying a trust relationship between a trusted node (first node) that has received a message and a node (second node) that has transmitted a message and itself is described. In exemplary embodiments, each of the physical nodes in the logical node may retain IP address list information for the physical nodes in the logical node. The IP address list information may be stored on a database shared by a plurality of physical nodes. The first node may search whether there is an IP address of the second node on the IP address list information, and recognize the second node as a public node when the IP address of the second node does not exist on the IP address list information. In contrast, when the IP address of the second node exists on the IP address list information, the second node may be recognized as a trusted node. In some embodiments, the first node identifies the second node based on the blockchain address of the second node and the signature information according to the validation of the message or the certificate information issued by the second node and establishes a trust relationship with the second node. You can also verify

In some embodiments, the first node may verify the trust relationship by verifying that it shares the database with the second node. In some embodiments, the first node may verify the trust relationship with the second node by querying the trust relationship of the second node from another node whose trust relationship has been verified. In some embodiments, the first node may query the second node at the management server managing the logical node to verify the trust relationship with the second node.

The first physical node 102a verifies the trust relationship with the node that sent the message, that is, if it verifies that the node that sent the message is another trusted node within the first logical node 103a, the validity of the received message is validated. The received message can be propagated on the blockchain network (S130) without proceeding with the procedure and the procedure for storing the received message in the database. That is, since the received message has already been validated by another trusted node and propagated to itself, the duplicated verification and duplicate storage of validity are omitted.

Alternatively, if the trust relationship between the first physical node 102a and the node that sent the message is not verified, then the first physical node 102a is not connected to the same message by another trusted node in the first logical node 103a. It may be determined whether the validation has been performed (S140). The physical nodes 102a-102m in the first logical node 103a may share a database. When receiving a message, any trusted node may verify the validity of the message (S150), store the validated message in a database (S180), and propagate the message (S130). If the message is not validated, the message is not stored in the database but discarded (S170) and does not propagate on the blockchain network.

The first physical node 102a may determine whether the same message has been validated by another trusted node by checking whether the same message as the received message is stored in the database. That is, since the same message is validated by another trust node and the message is stored in the database, the first physical node 102a does not perform duplicate verification and duplicate storage of the received message.

Referring to FIG. 4, when the message is a transaction history (S200), when a trusted node in a logical node receives a transaction history from an arbitrary node (S210), the trusted node has a trust relationship with the node that has transmitted the transaction history. It may be verified (S220). Once the trust relationship is verified, the received transaction details may be propagated to another node (S230). In contrast, if it is determined that there is no trust relationship, it may be determined whether or not the corresponding transaction details are validated (S240). If it is determined that the validity of the transaction details has already been completed, the transaction details may be propagated to another node (S230). In contrast, if it is determined that the validity of the transaction details is not performed, the validity of the transaction details may be verified (S250). If it is not valid by determining whether the transaction details are valid (S260), the received transaction details may be discarded (S270). Alternatively, if the transaction details are recognized as valid, the transaction details may be added to the transaction pool (S280). The transaction pool keeps track of transactions that have been validated and not yet included in the approval block. And the transaction pool can be a predetermined storage area on a database shared by trusted nodes. The transaction details may be propagated to another node (S230).

Referring to FIG. 5, in some embodiments, when the message is a block (S300), when the trusted node receives the block (S310), the trust relationship between the node that transmitted the block and itself is verified (S320) and trusted. If the relationship exists, the block may be propagated to another node (S330). In contrast, if it is determined that there is no trust relationship, it may be determined whether the corresponding block is validated (S340). If it is determined that the validation has been performed, the trusted node may propagate the node to another node (S330). In contrast, if it is determined that the validation is not performed, the validity of the corresponding block may be verified (S350). If the validity of the block is determined (S360), and the block is recognized as an invalid block, the block may be discarded (S370). On the contrary, if it is recognized that the block is valid, the block may be updated in the blockchain (S382) and the block may be propagated to another node (S330).

With regard to validity of the message, if the message is a block, the first physical node 102a may determine whether the same block as the received block exists on the local copy of the blockchain stored on the database. The block existing on the blockchain may be an agreed approval block or a block before it is recognized as a valid block according to any proof algorithm. In some embodiments, if any one of the candidate blocks is approved according to the proof-of-work algorithm, three types of blocks may be stored in the database. One is a block connected to the main blockchain, the other is a block coming out of the main blockchain to form a branch, and the other can be a block without a known parent in a known chain.

If the message is a transaction history, the first physical node 102a may determine whether the same message as the received message is stored in the database.

If the first physical node 102a confirms that the message received by the other trusted node has been validated, the first physical node 102a may propagate it through the blockchain network without storing the received message again in the database.

If the first physical node 102s determines that the message received by the other trusted node has not been validated, the first physical node 102s may proceed with a validation procedure of the received message (S150). If the validity of the received message is not verified by determining whether to validate the received message (S160), the corresponding message may be discarded (S170). In other words, the received message is not stored in the database nor propagated on the blockchain network.

In contrast, if the received message is validated, the first physical node 102a may store the validated message in a database and propagate it through the blockchain network (S180). In some embodiments, first physical node 102a may reduce traffic between trusted nodes by propagating a message to at least some of the public nodes other than the trusted node.

With regard to validity of the message, if the message is a transaction history, the node may verify the transaction history based on a predetermined checklist. For example, a process of verifying the syntax and data structure of a transaction is correct, verifying whether an input value or output value list is not empty, verifying whether a transaction size in bytes is smaller than a preset standard, and the like. However, items in the checklist may be added or changed depending on the object of the transaction.

If the message is a block, the node may verify the block based on a predetermined checklist. For example, verification may be performed that the data structure of the block is grammatically valid, verification that the time stamp of the block is within a preset time, verification that the size of the block is within an allowable limit, and the like. However, items in the checklist may be further added or changed. In addition, the validity of all transaction details contained in the block may be verified by way of example as described above.

On the other hand, the physical nodes in the logical node may share a database, and the procedure of validating the message and storing the message may be performed by any one of the physical nodes. Therefore, only messages that do not overlap each other are accumulated on the database.

At least some of all nodes in the blockchain system 10 may have the authority to create a block. Nodes with the right to create blocks may collect the received transaction details and generate a candidate block including the collected transaction details. And, the generated candidate block may be an approval block if approved according to the agreement.

If a node with block creation authority (or a node without block creation authority) receives a candidate block from another node during the process of collecting transaction details, it checks all the transaction details within the candidate block and the transaction history collected by itself. Transaction details that are not included). In addition, the common transaction history may be detected through the comparison process, and the detected transaction history may be removed from the database. Uncommon transaction history remains unremoved in the database. This transaction history then waits to be written to the new block. In this case, the time point at which the common transaction history is removed from the database may be after updating to the blockchain stored on the received database.

Referring to FIG. 6, for example, the first physical node 102a may detect common transaction details common to the transaction details in a block received from the public node among transaction details stored on the database (S381). Then, after updating the block received from the public node to the blockchain on the database (S382), the detected common transaction details may be removed (S383). Thus, there is no period for the common transaction history to disappear completely from the database. This is because, when the first physical node 102a detects the common transaction history, if the second physical node 102b receives the common transaction history from another node, whether there is a common transaction history received in the block on the blockchain. Alternatively, it is possible to check whether a common transaction history exists in the collected transaction history, thereby preventing duplicate validation of validity of the received transaction history or duplicate storage of the transaction history.

According to the embodiment of the present invention, it is possible to efficiently use the resources and processing power of the blockchain network. Thus, blockchain network performance can be improved. Here, the blockchain network performance means the overall performance of the blockchain network and the network performance of the logical node. In detail, if the maximum number of nodes that can join the blockchain network is limited (for example, a private blockchain), the overall performance of the blockchain network is improved when the presence of logical nodes or the number of trusted nodes grouped into logical nodes increases. However, if the maximum number of nodes that can join the blockchain network is not limited (for example, a public blockchain), the nodes grouped into logical nodes may be only some of the nodes. Therefore, the network performance improvement of the logical node is less likely to greatly affect the overall performance of the blockchain network. However, the economic value of the overall network performance of the blockchain system is not something that a specific user should consider. On the contrary, the economic value of the network performance of the node itself is much more important to the user. From this point of view, the economic benefits of improving the network performance of a logical node can be very large for a block generation node or a specific user or a group of users requiring high performance.

Embodiments according to the present invention described above can be implemented in the form of program instructions that can be executed by various computer components, and recorded in a computer-readable recording medium. The computer-readable recording medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the computer readable recording medium may be specially designed and configured for the present invention, or may be known and available to those skilled in the computer software field. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks and magnetic tape, optical recording media such as CD-ROMs and DVDs, and magneto-optical media such as floptical disks. medium) and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. Hardware devices may be modified with one or more software modules to perform the processing according to the present invention, and vice versa.

Particular implementations described in the present invention are embodiments and do not limit the scope of the present invention in any way. For brevity of description, descriptions of conventional electronic configurations, control systems, software, and other functional aspects of the systems may be omitted. In addition, the connection or connection members of the lines between the components shown in the drawings are illustrative of the functional connection and / or physical or circuit connections as an example, in the actual device replaceable or additional various functional connections, physical It can be represented as a connection, or circuit connections. In addition, unless specifically mentioned, such as "essential", "important" may not be a necessary component for the application of the present invention.

In addition, although the detailed description of the present invention has been described with reference to a preferred embodiment of the present invention, those skilled in the art or those skilled in the art having ordinary knowledge in the technical field described in the claims to be described later It will be understood that various modifications and variations can be made in the present invention without departing from the scope of the present invention. Therefore, the technical scope of the present invention should not be limited to the contents described in the detailed description of the specification but should be defined by the claims.

Claims (6)

A method in which a plurality of nodes verify and propagate a message in a blockchain system composed of at least one logical node including a plurality of trusted nodes and a distributed network of at least one public node,
Receiving a message propagated on a blockchain network by a first trusted node in the logical node;
Verifying, by the first trusted node, a trust relationship with the node that transmitted the message;
If it is determined that the node that sent the message is the public node, the first trusted node determines whether validation of the message by another trusted node in the logical node has been performed; And
The first trust node propagates the message on the blockchain network without performing the validation of the message when the first trust node confirms that the validation of the message by the other trust node is completed, and the first trust node propagates the message by the other trust node. Validating the message if it is not confirmed that the validation of the message is completed;
Discarding the message if the message is not validated and propagating the validated message on the blockchain network if the message is validated.
The message is a transaction history or block
How multiple nodes verify and propagate messages in a blockchain system. According to claim 1,
Receiving the message propagated on the blockchain network by the first trusted node,
Sending the message to the logical node by the public node accessing the logical node via an address identifying the logical node;
The logical node selecting the first trusted node of the plurality of trusted nodes; And
The logical node sending the message to the selected first trusted node;
How multiple nodes verify and propagate messages in a blockchain system. According to claim 1,
The first trusted node verifies the trust relationship with the node that transmitted the message.
The first trusted node in response to receiving the message
Pre-stored IP address list information,
Whether to receive a certificate from the node that sent the message, and
Among the blockchain address of the node that sent the message and signature information according to the validation of the message
Verifying a trust relationship with the node that sent the message based on at least one;
How multiple nodes verify and propagate messages in a blockchain system. According to claim 1,
The first trusted node determines whether the message is validated by the other trusted node,
Confirming, by the first trusted node, whether the message is stored on a database shared with the other trusted node; And
Determining that the validation of the message is completed when the storage of the message is confirmed.
How multiple nodes verify and propagate messages in a blockchain system. According to claim 1,
Propagating a message on the blockchain network,
The first trusted node propagates the message to at least some of the public nodes other than trusted nodes in the logical node of the plurality of nodes.
How multiple nodes verify and propagate messages in a blockchain system. According to claim 1,
Grouping nodes among the plurality of nodes that share a database in which a local copy of a blockchain is stored, into the logical node;
How multiple nodes verify and propagate messages in a blockchain system.

Images