Patent Application
20190036702
The present invention relates to a node device and a computer program for a private node/public node, in particular to a network mechanism that takes in transactions in each of which information regarding a transaction is described into a distributed database after forming a block from the transactions.
A technology called blockchain is known. The technology is called in this way because it is a mechanism that synchronizes the same records among many nodes on a network and blocks serving as recording units are added one after another in a chain while taking over content (hash) of the preceding block when a new record is added to an existing record. In general, the term “blockchain” may refer to a structure of a database in which blocks are linked in a chain, but in some cases the term is used in a broad sense including a mechanism that operates as a P2P network and a mechanism of approval of a transaction. Thus, at present, a definition of the term is not certain. Therefore, in the present specification, “blockchain” is used when being used in a narrow sense as in the former, and “blockchain technology” is used when being used in a broad sense as in the latter, in order to prevent confusion.
The blockchain technology has many advantages such as zero downtime, difficulty of falsification, and low cost. Therefore, besides virtual currency including bitcoin and currency derived from bitcoin, the blockchain technology is beginning to be noticed as a method for managing information regarding various assets as a transaction. For example, Non Patent Literature 1 discloses use of the blockchain that can play an important role for establishing reliability for proof of existence of various documents and identity verification.
A blockchain technology mainly includes a public node method and a private node method. The public node method is a method in which anyone can participate as a node on a network and is adopted also in bitcoin and the like. The fact that anyone can participate means that there can be an unreliable node. Therefore, to prevent falsification of data and the like, a high cost and slow consensus algorithm such as proof of work (POW) or proof of stake (POS) is required. On the other hand, the private node method is a method in which only a person authorized as the node on the network can participate. This method includes only reliable nodes. Therefore, sufficient reliability can be secured without use of an advanced consensus algorithm as in the public method. In a case where a system is constructed that can deal with transactions of various assets using the blockchain technology, the private node method is better to secure high reliability. However, the private node method has a disadvantage that application areas are limited due to limitation of the node as described above. On the other hand, the public node method can flexibly deal with various application areas. However, the public node method has problems such as the falsification of data by the unreliable node, and therefore is disadvantageous in terms of reliability of recording.
The present invention has been made in view of such circumstances, and an object of the present invention is to compatibly secure the reliability of recording and expandability of application areas in a network that takes in transactions in each of which transaction information is described into a distributed database after forming a block from the transactions.
In order to achieve the above object, a first aspect of the invention provides a node device for a private node in a transaction processing network including: a plurality of public nodes for generating a transaction in which transaction information is described; a plurality of private nodes with a limited number of nodes; and a distributed database in which the same record content is held synchronously in each node and blocks serving as recording units are linked according to recording order. The node device includes a block generation unit, an approval request unit, and a block finalization unit. The block generation unit generates a first block including a first transaction generated by a first public node. The approval request unit transmits an approval request of the first block to a group of predetermined m (m≥2) private nodes after attaching a signature by a secret key of an own node to the first block. In a case where the block finalization unit receives an approval result of the first block from the private node serving as a request destination of approval, the block finalization unit finalizes, after verifying validity of a signature attached to the approval result using a public key of the request destination of approval, addition of the first block to the distributed database on condition that approvals of n (m≥n≥1) or more nodes among a group of m private nodes are obtained.
Here, in the first aspect of the invention, it is preferable that the block finalization unit notifies the first public node of a processing result of the first transaction in the case where the addition of the first block to the distributed database is finalized.
In the first aspect of the invention, an approval response unit may be further provided. In a case where the approval response unit receives the approval request of the first block from the private node serving as a request source of approval, the approval response unit verifies, after verifying validity of the signature attached to the approval request using a public key of the request source of approval, content of the first block that is related to the approval request by referring to data regarding a transaction stored in a processing standby area of the own node, and also transmits the approval result with a signature by a secret key of the own node to the private node serving as the request source of approval.
In the first aspect of the invention, it is preferable that n is a majority of m. In addition, in a case where the first block is generated by the own node, the block generation unit may stand by without continuously transmitting an approval request of a new block at least until finalization of addition of another block generated by another node to the distributed database. Furthermore, in the transaction processing network, it is preferable that a protocol that adds or invalidates a public key of the private node is prepared in advance.
A second aspect of the invention provides a node device for a public node in a transaction processing network including: a plurality of public nodes for generating a transaction in which transaction information is described; a plurality of private nodes with a limited number of nodes; and a distributed database in which the same record content is held synchronously in each node and blocks serving as recording units are linked according to recording order. The node device includes a transaction generation unit, a recording request unit, and a result reception unit. The transaction generation unit generates a first transaction. The recording request unit transmits the first transaction to at least one private node and requests recording of the first transaction. Regarding a first block including the first transaction that is generated by one of the private nodes that received the first transaction, in a case where a block finalization condition is satisfied and addition of the first block to the distributed database is finalized, the result reception unit receives a processing result indicating that the recording of the first transaction transmitted by one of the private nodes that received the first transaction is completed. The block finalization condition is that approvals of n (m≥n≥1) or more nodes among a group of predetermined m (m≥2) private nodes are obtained by an approval protocol between the private nodes using multisignature by public key cryptography.
A third aspect of the invention provides a computer program for a private node in a transaction processing network including: a plurality of public nodes configured to generate a transaction in which transaction information is described; a plurality of private nodes with a limited number of nodes; and a distributed database in which the same record content is held synchronously in each node and blocks serving as recording units are linked according to recording order. The computer program causes a computer to execute processing including: a first step of generating a first block including a first transaction generated by a first public node; a second step of transmitting an approval request of the first block to predetermined m (m≥2) private nodes after attaching a signature by a secret key of an own node to the first block; and a third step of finalizing, in a case where an approval result of the first block is received from the private node serving as a request destination of approval, addition of the first block to a distributed database after verifying validity of a signature attached to the approval result using a public key of the request destination of approval, on condition that approvals of n (m≥n≥1) among m private nodes are obtained.
Here, in the third aspect of the invention, it is preferable that the third step includes a step of notifying the first public node of a processing result of the first transaction in the case where the addition of the first block to the distributed database is finalized.
The third aspect of the invention may further includes a fourth step of, in a case where the approval request of the first block is received from the private node serving as a request source of approval, verifying, after verifying validity of the signature attached to the approval request using a public key of the request source of approval, content of the first block that is related to the approval request by referring to data regarding a transaction stored in a processing standby area of the own node, and also transmitting the approval result with a signature by a secret key of the own node to the private node serving as the request source of approval.
In the third aspect of the invention, it is preferable that n is a majority of m. In addition, in a case where the first block is generated by the own node, the first step may include a step of standing by without continuously transmitting an approval request of a new block at least until finalization of addition of another block generated by another node to the distributed database. Furthermore, in the transaction processing network, it is preferable that a protocol that adds or invalidates a public key of the private node is prepared in advance.
A fourth aspect of the invention provides a computer program for a public node in a transaction processing network including: a plurality of public nodes configured to generate a transaction in which transaction information is described; a plurality of private nodes with a limited number of nodes; and a distributed database in which the same record content is held synchronously in each node and blocks serving as recording units are linked according to recording order. The computer program causes a computer to execute processing including: a first step of generating a first transaction; a second step of transmitting the first transaction to at least one of the private nodes and requesting recording of the first transaction; and a third step of receiving a processing result indicating that the recording of the first transaction transmitted by one of the private nodes that received the first transaction is completed in a case where addition of a first block to the distributed database is finalized on condition that, for a block that is generated by one of the private nodes that received the first transaction and including the first transaction, approvals of n (m≥n≥1) or more among predetermined m (m≥2) private nodes are obtained by an approval protocol between the private nodes using multisignature by public key cryptography.
According to an aspect of the present invention, nodes constituting a transaction processing network are divided into a public node and a private node. The public node plays a role of generating a transaction in which transaction information is described, and subsequent processing is performed by cooperation of private nodes using a low cost and quick consensus algorithm called multisignature (multisig) using public key cryptography. Regarding the generation of the transaction, while widely recognizing that the public node can include an unreliable node, the subsequent processing such as generation and finalization of a block is limited to the reliable private node. This makes it possible to compatibly secure expandability of application areas, which is an advantage of a public node method, and reliability of recording, which is an advantage of a private node method.
For example, “remitting 100 million yen from A to B” or “receiving 500 specified shares from A to B” means the transferring (flow) of the asset and can be regarded as a transaction in one direction. “A has a deposit of 100 million yen” or “A has 500 specified shares” can be regarded as the asset itself or the concept of retaining (stock) of the state of the asset. “A purchases US dollars for 100 million yen from B” or “A purchases 500 specified shares for 1,000 yen per share from B” can be regarded as a transaction in two directions in which two types of transfer (flow) of the asset occur simultaneously.
The transaction processing network 1 is a peer to peer (P2P) type network and includes not only a pure P2P but also a so-called hybrid type (which includes a client server type configuration in part). Nodes 2 participating in (connecting to) the transaction processing network 1 performs communication (P2P communication) in a one-to-one, equal relationship. Each node 2 includes a computer 3 and a database 4a as a node device. The information regarding a transaction is managed by a distributed database 4 on the network 1, that is, an aggregation of the databases 4a provided for each node 2. All the databases 4a existing on the network 1 are synchronized by a blockchain technology and basically hold the same record content. In a case where the authorized node 2 updates the distributed database 4, another node 2 connected to an own node 2 is notified thereof. Thereafter, by repetition of the P2P communication between the nodes, the notification finally spreads throughout the network 1. As a result, the databases 4a of all the nodes 2 are updated and shared as the same record content.
The P2P communication in the network 1 is performed by SSL communication in order to secure security. In addition, validity of the transaction exchanged among the nodes 2 is verified by a digital signature using public key cryptography. As a premise for that, each node 2 holds a secret key (personal identification number) of an address managed by itself (an owner of a network address=an owner of the secret key). A public key is uniquely specified by a secret key. As the network address, the public key itself may be used, or a public key which is hashed and to which a checksum is added as in bitcoin and the like may be used. A transmitter of the transaction (a source of the asset) transmits the transaction after attaching a signature by the secret key of the address managed by itself to the transaction to be sent. A recipient of the transaction verifies validity of the signature attached to the received transaction by the public key corresponding to the secret key. Note that the public key cryptography used here is different from public key cryptography of multisignature (multisig) regarding an approval of a block to be described later. A secret key of the multisig is owned only by a private node 2b irrespective of the above network address.
Note that
Note that, for example, at the time of retrieval such as calculation of a balance of a certain address, in order to speed up processing, the record content of the database 4a may be managed with an index at part of a plurality of public nodes 2a. Since data in the distributed database 4 is basically a Key-Value type, there is a disadvantage that a conditional query takes a very long time. An application range can be extended by providing a node with an own index for retrieval to eliminate the disadvantage.
The private nodes 2b are reliable nodes with a number limit, and perform the recording processing of the transaction requested by a public node 2a to the distributed database 4. The recording processing is performed by cooperation of the group of private nodes 2b as will be described later. In a case where the recording processing is completed, a processing result is notified to the public node 2a serving as a request source. What is important for the private node 2b is that the transactions are added to the distributed database 4 after approving transactions and forming a block from the transactions, and a reward (incentive) such as mining commission employed in virtual currencies such as bitcoin is not always necessary.
A plurality of private nodes 2b approves a block by the multisignature (multisig) regarding an approval of a block using the public key cryptography. Therefore, as illustrated in
On the premise that the signature can be verified as valid, the transaction processing unit 23 records the transaction in the distributed database 4 in a case where a predetermined condition is satisfied. The transaction processing unit 23 includes a block generation unit 23a, an approval request unit 23b, a block finalization unit 23c, and an approval response unit 23d.
Here, the private node device 21 plays two roles. One is a role in which an own node 2b generates a block and requests another node 2b to approve the block, and as configurations for the role, the block generation unit 23a, the approval request unit 23b, and the block finalization unit 23c are included. The other is a role of approving the block generated by the other private node 2b, and as a configuration for the role, the approval response unit 23d is included. Thus the private node 2b can be both of a request side that requests the other node 2b to approve the block generated by the own node 2b, and an approval side that approves, by the own node 2b, the block generated by the other node 2b.
The block generation unit 23a generates a block by combining a plurality of transactions, a request for recording processing of which is received from the public node 2a serving as a request source of the recording of the transaction. The approval request unit 23b transmits, after attaching a signature by a secret key of the own node 2b to the block generated by the block generation unit 23a, an approval request of the block to a group of predetermined m (m≥2) private nodes 2b as config of the system. The node serving as a request destination of approval may include the own node. In a case where the block finalization unit 23c receives an approval result of the block from the private node 2b serving as the request destination of approval, the block finalization unit 23c determines whether or not the following block finalization condition is satisfied after verifying validity of a signature attached to the approval result using a public key corresponding to the secret key of the request destination of approval.
Approvals of n (m≥n≥1) or more among m (m≥2) private nodes 2b are obtained
In this block finalization condition, it is preferable that n is a majority of m. With this condition, reliability of the approval can be secured within a reasonable and realistic range. For example, in a case where there are four private nodes 2b as illustrated in
It is preferable that m is equal to or smaller than a limited number of one digit, two digits, or the like, and it may be preferable that m is an odd number such as 5, 9 or the like depending on the block finalization condition. In addition to being the majority of m, it may be preferable that n is a specified predetermined number of equal to or more than the majority of m.
As for the block finalization condition, although one node is allowed to make one approval by one vote in the above description, it is also possible to give an arbitrary positive real number of votes to each node and determine that the approvals are obtained by the votes of a majority. Note that, in this case, the “majority” is the number exceeding half of the total number of votes.
In a case where the block relating to the approval request satisfies the block finalization condition, addition of the block to the distributed database 4 is finalized, and in a case where the condition is not satisfied, addition of the block to the distributed database 4 is not performed. The block finalization unit 23c notifies the public node 2a serving as the request source of the recording of the transaction of a processing result (OK/NG) of the transaction. In the case where the addition of the block to the distributed database 4 is finalized, it is notified to all the nodes 2 of the transaction processing network 1 that the block is added to the database 4a of the own node 2b and a new block is added in accordance with the finalization of the block. With this notification, the databases 4a of all the nodes 2, that is, the distributed database 4 is updated.
Although the notification is required to be issued to all the nodes 2 directly or indirectly, there may be also cases where the notification is issued to all of the private nodes 2b and part of the public nodes 2a, all of the private nodes 2b, part of the private nodes 2b and part of the public nodes 2a, or part of the private nodes 2b, besides a case where the notification that the new block is added in accordance with the finalization of the block is issued to all the nodes 2 directly.
Meanwhile, in a case where the approval response unit 23d receives the approval request of the block from the private node 2b serving as the request source of approval, the approval response unit 23d verifies validity of the signature attached to the approval request using a public key (corresponding to the secret key of the request source of approval). In addition, the approval response unit 23d refers to data regarding the transactions recorded in the own node 2b to verify content of the block relating to the approval request (including consistency of the transactions in the block). Then, in a case where a verification result that the content is valid is obtained, the approval response unit 23d transmits an approval result with a signature by a secret key of the own node 2b to the private node 2b serving as the request source of approval.
Note that, as measures against hacking of the private node 2b, that is, for a time when the private node 2b is hacked, in a case where one block is generated by the own node 2b, the block generation unit 23a stands by without continuously transmitting an approval request of a new block at least until finalization of addition of another block generated by another node 2b to the distributed database 4. That is, it is prohibited to continuously perform processing of finalizing the block in the same private node 2b.
Next, a flow of transaction recording processing will be described with reference to
Each of the private nodes 2b that received the recording request of the transaction Tr verifies the signature attached to the recording request using a public key corresponding to the secret key of the source of the transfer (Step 3). As illustrated in
In Step 5, a block is generated in one of the private nodes 2b. The block is a combination of a plurality of transactions Tr stored in the processing standby area of the own node 2b. Then, in Step 6, an approval request with a signature having a data structure as illustrated in
Steps 7 to 9 are processing of the private node 2b that received the approval request of the block, that is, the request destinations B to D of approval. First, in Step 7, validity of the signature “A” and the like attached to the approval request is verified using the public key of the node A and the like serving as the request source of approval (Step 7). In Step 7, not only the node A but also other signatures attached at the time of the verification are verified together. Basically, the signatures are attached in the order such as node A→B→C→D, and the block is finalized when the signatures of a majority (n) are obtained. Various implementation methods are conceivable as to how to maintain the order. Note that the verification itself of the signature of the block is performed not only in the private node 2b but also in all the public nodes 2a so as not to trust a hacked block. In a case where it is determined that the request source of approval is valid, the processing proceeds to Step 8, and in a case where it is determined to be not valid, processing after Step 8 is not performed.
In Step 8, content of the block relating to the approval request is verified. Specifically, the transactions stored in the processing standby area of the own node 2b are referred to, and in a case where the content of the block satisfies at least the following approval conditions, the block is approved. In a case where it is determined that the content of the block is valid, the processing proceeds to Step 9, and in a case where it is determined to be not valid, processing after Step 9 is not performed (a processing result=NG).
(1) All the transactions Tr in the block are unprocessed in the own node 2b (prevention of duplicate recording)
(2) The content of all the transactions Tr in the block match the content of the transaction Tr stored in the processing standby area of the own node 2b (prevention of falsification of data)
(3) The asset of the individual transaction Tr is not used (prohibition of double-use of the asset)
In Step 9, an approval result with a signature is generated. In a case where the block can be approved, as illustrated in
Steps 10 to 12 are processing of the private node 2b that received the approval result of the block, that is, the request source A of approval. First, in Step 10, validity of the signature attached to the approval result is verified using public keys of the request sources B to D of approval (Step 10). In a case where it is determined that the request destination of approval is valid, the processing proceeds to Step 11, and in a case where it is determined to be not valid, the processing after Step 12 is not performed.
In Step 11, in a case where approvals of n (m≥n≥1) or more among m private nodes are obtained, the block finalization condition is satisfied and addition of the block to the distributed database 4 is finalized. An example of
In the case where the block finalization condition is satisfied, processing of recording the finalized block in the distributed database 4 is performed by the request source A of approval. Specifically, first, in the own node A, the transaction Tr included in the finalized block is deleted from the processing standby area, and the finalized block is added to the own database 4. Further, a notification that the finalized block is newly added is transmitted to the whole of the transaction processing network 1 including the other nodes B to D connected to the own node A. Upon receiving the notification of the finalized block, all the nodes 2 add the finalized block to the own database 4a after verifying a signature of a notification source. In addition, with this notification, all the nodes 2 (including the nodes B to D) holding unprocessed transaction Tr in the processing standby area deletes the transaction Tr included in the finalized block from the processing standby area (Step 13). On the other hand, in a case where the block finalization condition is not satisfied, the block generated this time is canceled. As a result, the unprocessed transaction Tr in the processing standby area is continuously held and stands by for subsequent opportunity of generation of a block.
Then, in Step 12, a processing result (OK/NG) of the transaction Tr relating to the recording request is notified from one of the private nodes 2b (request source A of approval) to the public node 2a serving as the request source of the recording of the transaction Tr. The public node 2a receives the processing result and presents the processing result to a user (Step 14). Through the above series of processing, the transaction recording processing is completed.
Note that, in the transaction recording processing as described above, there is a possibility that a plurality of private nodes 2b simultaneously generates separate blocks including the same transaction, that is, a possibility that conflict of processing between the private nodes 2b is occur. Such a problem can be solved by performing exclusive control by assigning order of block generation among the private nodes 2b as a round robin, for example. In addition, priority order may be assigned to the group of private nodes 2b, and in a case where the above conflict occurs, only the private node 2b with higher priority may be allowed to perform re-processing of the conflicting transactions.
As described above, according to the present embodiment, the nodes 2 constituting the transaction processing network 1 are divided into the public node 2a and the private node 2b. The public node 2a plays a role of generating the transaction to be recorded, and the subsequent recording processing to the distributed database 4 is performed by cooperation of the group of private nodes 2b. Regarding the generation of the transaction, while widely recognizing that the public node 2a can include an unreliable node, the recording processing to the distributed database 4 is limited to the reliable private node 2b. In this way, by separating the roles of the public node 2a and the private node 2b, it is possible to compatibly secure expandability of application areas, which is an advantage of a public node method, and reliability of recording, which is an advantage of a private node method.
In addition, according to the present embodiment, as a mutual authentication method between the reliable private nodes 2b, a relatively simple consensus algorithm called multisignature (multisig) using public key cryptography is used instead of a costly and slow consensus algorithm such as POW or POS. This makes it possible to process a large amount of transaction quickly and reliably without impairing reliability of recording.
Furthermore, according to the present embodiment, in order to prevent that a generation frequency of the block by a specific private node 2b becomes extremely high, it is prohibited that the same private node 2b sequentially transmits the approval requests of the block. This makes it possible to effectively deal with hacking acts such as applying an excessive load on the specific private node 2b by causing the specific private node 2b to continuously generate the block.
Note that the present invention can also be regarded as a computer program that implements the public node device 20 or the private node device 21 described above.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2016-071341 | Mar 2016 | JP | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/JP2017/012875 | 3/29/2017 | WO | 00 |
