WO2017170679A1 - プライベートノード、プライベートノードにおける処理方法、及びそのためのプログラム - Google Patents

プライベートノード、プライベートノードにおける処理方法、及びそのためのプログラム Download PDF

Info

Publication number
WO2017170679A1
WO2017170679A1 PCT/JP2017/012875 JP2017012875W WO2017170679A1 WO 2017170679 A1 WO2017170679 A1 WO 2017170679A1 JP 2017012875 W JP2017012875 W JP 2017012875W WO 2017170679 A1 WO2017170679 A1 WO 2017170679A1
Authority
WO
WIPO (PCT)
Prior art keywords
private
block
node
transaction
nodes
Prior art date
Application number
PCT/JP2017/012875
Other languages
English (en)
French (fr)
Inventor
裕三 加納
峰史 小宮山
Original Assignee
株式会社ｂｉｔＦｌｙｅｒ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社ｂｉｔＦｌｙｅｒ filed Critical 株式会社ｂｉｔＦｌｙｅｒ
Priority to US16/077,032 priority Critical patent/US20190036702A1/en
Priority to EP17775213.6A priority patent/EP3439231A4/en
Priority to CN201780033768.0A priority patent/CN109219940B/zh
Publication of WO2017170679A1 publication Critical patent/WO2017170679A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD

Definitions

  • the present invention relates to a node device and a computer program for a private node / public node, and more particularly to a network mechanism that blocks a transaction in which information related to a transaction is recorded and imports it into a distributed database.
  • block chain is a mechanism to synchronize the same record among a large number of nodes on the network.
  • the block that becomes the record unit uses the contents (hash) of the immediately preceding block. It is called in this way because it is added one after another while taking over.
  • the term block chain may refer to the structure of a database in which blocks are connected in a chain, but it may also be used in a broad sense including the mechanism that operates as a P2P network and the mechanism for transaction approval. Yes, at the moment its definition is not clear. Therefore, in this specification, in order to prevent confusion between the two, the term “block chain” is used when the former is used in a narrow sense, and the term “block chain technology” is used when the latter is used in a broad sense.
  • Non-Patent Document 1 describes that a block chain that can play an important role for establishing reliability is used for existence proof and identity proof of various documents.
  • Blockchain builds a trust relationship in cyber space-the important meanings of “proof of existence” and “identity proof”, [online], [searched on March 28, 2016], Internet ⁇ URL: http: / /diamond.jp/articles /-/ 53050>
  • Blockchain technology mainly includes public node method and private node method.
  • the public node method is a method in which anyone can participate as a node on the network, and is also adopted by Bitcoin and the like. The fact that anyone can participate is that there can be unreliable nodes, so in order to prevent data tampering, etc., high-cost and slow consensus algorithms such as POW (Proof Of Stake) and POS (Proof Of Stake) Is required.
  • the private node method is a method in which only those who are permitted as nodes on the network can participate. Since this method is composed only of reliable nodes, sufficient reliability can be ensured without using an advanced consensus algorithm like the public method.
  • the private node method is superior to ensure a high level of reliability.
  • application fields are limited due to restrictions.
  • the public node method can flexibly cope with various application fields, but has a problem of data alteration by an unreliable node, and has a difficulty in recording reliability.
  • the present invention has been made in view of such circumstances, and an object of the present invention is to achieve both the reliability of recording and the expandability of application fields in a network that blocks transactions containing transaction information and imports them into a distributed database. It is to plan.
  • the first invention is to synchronize a plurality of public nodes that generate a transaction describing transaction information, a plurality of private nodes with a limited number of nodes, and the same recorded contents in each node.
  • the node device includes a block generation unit, an approval request unit, and a block determination unit.
  • the block generation unit generates a first block including a first transaction generated by the first public node.
  • the approval request unit attaches a signature with the private key of the own node to the first block, and issues an approval request for the first block to m (m ⁇ 2) private node groups set in advance. Send.
  • the block confirmation unit receives the approval result of the first block from the private node that is the approval request destination, the block confirmation unit verifies the validity of the signature attached to the approval result using the public key of the approval request destination Above, it is determined that the first block is added to the distributed database on condition that n (m ⁇ n ⁇ 1) or more approvals of m private node groups are obtained.
  • the block determination unit when it is determined that the first block is to be added to the distributed database, notifies the first public node of the processing result of the first transaction. It is preferable.
  • an approval response unit may be further provided.
  • the approval response unit receives the first block approval request from the private node that is the approval request source
  • the approval response unit verifies the validity of the signature attached to the approval request using the public key of the approval request source. Then, referring to the data related to the transaction stored in the processing waiting area of the own node, the contents of the first block relating to the approval request are verified, and the approval result with the signature by the private key of the own node is displayed. Sent to the private node that is the request source for approval.
  • n is preferably a majority of m.
  • the block generation unit when the block generation unit generates the first block at its own node, at least until it is confirmed that another block generated by another node is added to the distributed database, an approval request for a new block is issued. You may stand by without transmitting continuously.
  • a protocol for adding or revoking the public key of the private node is prepared in advance in the transaction processing network.
  • the second invention is a plurality of public nodes that generate a transaction describing transaction information, a plurality of private nodes with a limited number of nodes, and each node holds the same recorded contents in synchronization
  • 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.
  • the result receiving unit may be added to the distributed database by satisfying the block definite condition for the first block generated in any of the private nodes that have received the first transaction and including the first transaction. If it is confirmed, a processing result indicating that recording of the first transaction is completed, which is transmitted from any of the private nodes that have received the first transaction, is received.
  • the block confirmation condition is set to n (m ⁇ n ⁇ 1) or more of m (m ⁇ 2) private nodes set in advance by an approval protocol between private nodes using multiple signatures by public key cryptography. Approval has been obtained.
  • the third invention is a plurality of public nodes that generate a transaction describing transaction information, a plurality of private nodes with a limited number of nodes, and each node holds the same recorded contents in synchronization, and Provided is a computer program for a private node in a transaction processing network having a distributed database in which blocks serving as recording units are connected according to a recording order.
  • the computer program includes a first step of generating a first block including a first transaction generated by a first public node, and a signature with the private key of the own node attached to the first block.
  • m (m ⁇ 2) private nodes set in advance
  • the validity of the signature attached to the approval result is verified using the public key of the approval request destination, and then n (m> n ⁇ 1) of m private nodes.
  • the computer is caused to execute a process including a third step for confirming that the first block is added to the distributed database.
  • the third step when it is determined that the first block is added to the distributed database, the third step notifies the first public node of the processing result of the first transaction. It is preferable to include the step of carrying out.
  • the third invention when the approval request of the first block is received from the private node that is the approval request source, the validity of the signature attached to the approval request is verified using the public key of the approval request source Then, referring to the data related to the transaction stored in the processing waiting area of the own node, the contents of the first block relating to the approval request are verified, and the approval result with the signature by the private key of the own node is displayed.
  • a fourth step of transmitting to the private node as the approval request source may be further provided.
  • n is preferably a majority of m.
  • an approval request for a new block is made until it is determined that at least another block generated by another node is added to the distributed database. May be included without waiting for continuous transmission.
  • a protocol for adding or revoking the public key of the private node is prepared in advance.
  • generates the transaction which described transaction information
  • the computer program includes: a first step for generating a first transaction; a second step for sending the first transaction to at least one private node to request recording of the first transaction;
  • the block including the first transaction and generated in any of the private nodes that received the transaction of (1) is set in advance by an approval protocol between the private nodes using multiple signatures by public key cryptography (m ⁇ m ⁇ 2) If it is confirmed that the first block is added to the distributed database on condition that n (m ⁇ n ⁇ 1) or more approvals among the private nodes are obtained, the first transaction Sent from any of the private nodes that received the Transaction records to execute processing and a third step of receiving a processing result indicative of the completion to the computer.
  • the nodes constituting the transaction processing network are divided into public nodes and private nodes.
  • the public node plays a role of generating a transaction describing transaction information, and the subsequent processing is performed by the private nodes using a low-cost and high-speed consensus algorithm called multi-signature using public key cryptography. Done by working.
  • the generation of a transaction is widely recognized as a public node that can include an unreliable node, and subsequent processes such as block generation and determination are limited to a reliable private node. Thereby, it is possible to achieve both the scalability of application fields, which is an advantage of the public node method, and the reliability of recording, which is an advantage of the private node method.
  • FIG. 1 is a physical configuration diagram of a transaction processing network according to an embodiment of the present invention.
  • the transaction processing network 1 is used as a management system that manages information related to transactions.
  • the type of transaction to be managed is determined in advance as a system specification according to its use. For example, in the case of a bank system, real currency transactions are targeted, and in the case of a securities system, securities transactions are targeted.
  • “transaction” means an asset such as real currency, virtual currency, securities, real estate, etc., or maintenance of this asset state (stock), transfer of assets (flow), and also a contract, A contract can be both an asset and a liability.
  • a wider range of transactions can be defined.
  • “Remit 100 million yen from A to B” or “Receive 500 shares of specified stock from A to B” is synonymous with asset transfer (flow) and can be regarded as a one-way transaction. it can.
  • “A has a deposit of 100 million yen” and “A has 500 shares of specified stock” can be regarded as an asset itself, and the concept of holding the state of assets (stock) Can also be understood.
  • “A buys 100 million yen from B for US dollars” and “A buys 500 specific shares from B for 1,000 yen per share” means that two asset transfers (flows) occur simultaneously. It can be understood as a two-way transaction.
  • the transaction processing network 1 is a P2P (Peer-to-Peer) type network, and includes not only pure P2P but also a so-called hybrid type (partly including a client-server type configuration).
  • Nodes 2 participating (connected) in the transaction processing network 1 perform communication (P2P communication) in a one-to-one relationship.
  • Each node 2 has a computer 3 and a database 4a as node devices.
  • Information relating to transactions is managed by a distributed database 4 on the network 1, that is, a collection of databases 4 a provided for each node 2. All the databases 4a existing on the network 1 are synchronized by the block chain technology and basically hold the same recorded contents.
  • the authorized node 2 updates the distributed database 4, the fact is notified to the other nodes 2 connected to the own node 2, and the P2P communication between the nodes is repeated thereafter. Notifications are distributed throughout 1. As a result, the databases 4a of all the nodes 2 are updated and shared as the same recorded content.
  • P2P communication in the network 1 is performed by SSL communication in order to ensure security. Further, the validity of a transaction passed between the nodes 2 is verified by an electronic signature using public key cryptography.
  • the public key is uniquely identified from the secret key.
  • the public key itself may be used, or the public key may be used after hashing the public key and adding a checksum, similarly to bitcoin or the like.
  • the transaction sender source of asset transfer
  • the receiver of the transaction verifies the validity of the signature attached to the received transaction with the public key corresponding to this secret key.
  • the public key cryptography used here is separate from the multi-signature (multi-sig) public key cryptography related to block approval, which will be described later.
  • the multisig private key is held only by the private node 2b regardless of the network address.
  • FIG. 1 shows a full-connect type in which each node 2 is connected to all other nodes 2, but this is an example, and any topology may be adopted.
  • a protocol that allows direct transmission to a destination by specifying an address instead of indirect transmission by P2P communication may be introduced.
  • FIG. 2 is a logical configuration diagram of the transaction processing network 1 according to an embodiment.
  • the node 2 constituting the transaction processing network 1 includes a public node 2a and a private node 2b.
  • the public node 2a is an application node that is the subject of the transaction (can include untrusted nodes).
  • the public node 2a generates a transaction describing information related to the transaction, signs it, and transmits it directly or indirectly to the private node 2b group.
  • the public node 2a only makes a transaction recording request to the private node 2b group, and does not perform the recording process to the distributed database 4 itself. What is important for the public node 2a is that it can be queried (because it is not up-to-date), sign a newly created transaction, and ask the private node 2b group to approve the transaction.
  • the recorded contents of the database 4a may be managed with an index in a part of the plurality of public nodes 2a. Since the data in the distributed database 4 is basically a key-value type, there is a disadvantage that it takes a very long time for a conditional query.
  • the application range can be expanded by providing a node having a unique index for searching for the solution.
  • the private node 2b is a reliable node with a limited number of nodes, and records the transaction requested by the public node 2a in the distributed database 4. As will be described later, this recording process is performed by cooperation of the private node 2b group. When the recording process is completed, the processing result is notified to the requesting public node 2a.
  • the important thing for the private node 2b is to approve and block the transaction and add it to the distributed database 4, and it is a reward (incentive) such as mining and commission adopted in virtual currency such as bitcoin. Is not necessarily required.
  • the multiple private nodes 2b use public key cryptography to approve blocks using multiple signatures (multi-sig) related to block approval. Therefore, as shown in FIG. 3, each private node 2b has its own private key.
  • the public key is shared between the private nodes 2b by reading the configuration file in which the public key is described when the system is started.
  • a protocol for adding or revoking the public key of the private node 2b is prepared. By executing this protocol, the public key can be added or revoked without rewriting the configuration file. Since information related to the public key is required to be strictly managed, it is exchanged by SSL or the like in order to ensure safety.
  • FIG. 4 is a functional block diagram of a node device for the public node 2a (hereinafter referred to as “public node device 20”).
  • the public node device 20 includes a transaction generation unit 20a, a recording request unit 20b, and a result reception unit 20c.
  • the transaction generation unit 20a generates a transaction in which information related to the transaction is written according to a predetermined format. Information relating to the transaction is acquired from, for example, input information input by the user in accordance with an instruction on the display screen or received information received through another network.
  • the recording request unit 20b attaches a signature generated by the secret key of the address managed by the transaction generated by the transaction generating unit 20a to the private node 2b group via P2P communication between the nodes 2, The private node 2b group is requested to record the transaction.
  • the result receiving unit 20c receives the transaction processing result transmitted from one of the private nodes 2b and presents it to the user.
  • FIG. 5 is a functional block diagram of a node device for the private node 2b (hereinafter referred to as “private node device 21”).
  • the private node device 21 has a signature verification unit 22 and a transaction processing unit 23.
  • the signature verification unit 22 verifies the validity of the signature attached to the transaction received as a recording request from the public node 2a using the public key corresponding to the secret key. In addition to the signature, it is also verified that the asset is not used twice.
  • the transaction processing unit 23 records a transaction in the distributed database 4 when a predetermined condition is satisfied on the assumption that the signature can be verified as valid.
  • the transaction processing unit 23 includes a block generation unit 23a, an approval request unit 23b, a block determination unit 23c, and an approval response unit 23d.
  • the private node device 21 has two roles. One is a role in which the own node 2b generates a block and requests the other node 2b to approve the block. As a configuration for this, the block generating unit 23a, the approval requesting unit 23b, and the block determining unit 23c include Exists. The other is a role of approving a block generated by another private node 2b, and an approval response unit 23d exists as a configuration for that purpose. As described above, the private node 2b is either the requesting method for requesting the other node 2b to approve the block generated by the own node 2b or the approval method in which the own node 2b approves the block generated by the other node 2b. Can also be.
  • the block generation unit 23a generates a block by collecting a plurality of transactions that have received a recording processing request from the public node 2a that is a transaction recording request source.
  • the approval request unit 23b attaches a signature generated by the private key of the node 2b to the block generated by the block generation unit 23a, and then sets m (m ⁇ 2) other private nodes set in advance as a system configuration.
  • a block approval request is transmitted to the group 2b.
  • the node requesting approval may include its own node.
  • the block confirmation unit 23c receives the block approval result from the private node 2b as the approval request destination, the block confirmation unit 23c displays the validity of the signature attached to the approval result as the public key corresponding to the secret key of the approval request destination. And verifying whether or not the following block definite condition is satisfied.
  • n is preferably a majority of m.
  • M is preferably equal to or less than a limited number such as one digit or two digits, and may be preferably an odd number such as 5 or 9, depending on the block determination condition.
  • n may preferably be a specified predetermined number that is greater than or equal to the majority.
  • the block determination unit 23c notifies the transaction processing result (OK / NG) to the public node 2a, which is the transaction recording request source.
  • the addition of a block to the distributed database 4 is confirmed, the addition of a block to the database 4a of the own node 2b and the addition of a new block with the confirmation of the block are all nodes 2 of the transaction processing network 1. Be notified. By this notification, the database 4a of all the nodes 2, that is, the distributed database 4 is updated.
  • the private node 2b It may be possible to notify all and part of the public node 2a, all of the private node 2b, part of the private node 2b and part of the public node 2a, or part of the private node 2b.
  • the approval response unit 23d when the approval response unit 23d receives a block approval request from the private node 2b as the approval request source, the approval response unit 23d uses the public key (the private key of the approval request source) as the validity of the signature attached to the approval request. That correspond to the above). Further, the approval response unit 23d verifies the contents of the block related to the approval request (including the consistency of the transactions in the block) with reference to the data related to the transaction recorded in the own node 2b. When the verification result that the contents are valid is obtained, the approval response unit 23d transmits the approval result with the signature by the private key of the node 2b to the private node 2b that is the request source of the approval.
  • the block generation unit 23a generates at least the other node 2b as a countermeasure against hacking of the private node 2b, that is, when the private node 2b generates one block for the hacking of the private node 2b. Until another block is confirmed to be added to the distributed database 4, it waits without continuously transmitting new block approval requests. That is, it is prohibited to perform block determination processing continuously in the same private node 2b.
  • a transaction Tr in which information related to a transaction is written is generated (step 1).
  • a private node 2b group is assigned.
  • a request for recording the transaction Tr is transmitted (step 2). For example, as shown in FIG. 7, a transaction “Tr1” related to the asset migration source “a” is given a signature “a” with a secret key of an address managed by the migration source “a”, and transactions Tr2 and Tr3 are similarly signed. .
  • Each private node 2b that receives the transaction Tr recording request verifies the signature attached to the recording request using the public key corresponding to the private key of the source (Step 3). As shown in FIG. 7, the signature “a” attached to the transaction Tr1 is verified using the public key corresponding to the private key of the source a, and the transactions Tr2 and Tr3 are similarly verified. As described above, in addition to the signature, it is verified that the asset is not used twice. If the validity of the signature can be confirmed in each private node 2b, the transactions Tr1 to Tr3 are temporarily stored in a predetermined storage area (processing waiting area) in the storage device of the own node 2b (step 4). ). If it is determined in step 4 that the asset transfer source is not valid, the request is sent to the public node 2a serving as the request source.
  • a predetermined storage area processing waiting area
  • a block is generated in any private node 2b.
  • This block is a collection of a plurality of transactions Tr stored in the processing waiting area of the own node 2b.
  • an approval request with a signature having a data structure as shown in FIG. 8A is generated.
  • This data structure includes a signature field of a request source requesting block approval, a block body in which a plurality of transactions Tr are collected, and a signature field of a block approval destination.
  • the configuration shown in the figure is for convenience of explanation, and it is not actually necessary to separate the request source / approval destination signature fields.
  • the signature “A” by the private key is entered, and the approval destination signature column (the column in which the signatures of the nodes B to D are entered) is blank.
  • the approval request generated at the node A is transmitted to the other private node 2b, that is, the three nodes BD.
  • Steps 7 to 9 are processes of the private node 2b that has received the block approval request, that is, the approval request destinations B to D.
  • step 7 the validity of the signature “A” or the like attached to the approval request is verified using the public key of the node A or the like that is the approval request source (step 7).
  • step 7 not only the node A but also other signatures attached at the time of verification are verified together.
  • the signatures are sequentially made in the order of nodes A ⁇ B ⁇ C ⁇ D, and are determined when a majority (n) signatures are obtained.
  • the verification of the block signature itself is performed not only on the private node 2b but also on all public nodes 2a so as not to trust the hacked block. If it is determined that the approval request source is valid, the process proceeds to step 8. If it is determined that the approval request source is not valid, the processes after step 8 are not performed.
  • step 9 a signed approval result is generated.
  • a signature with its own private key is entered in the field assigned to the own node 2b in the approval destination signature field.
  • the approval result with the signature is transmitted to the approval request source A.
  • Steps 10 to 12 are processing of the private node 2b that has received the block approval result, that is, the approval request source A.
  • step 10 the validity of the signature attached to the approval result is verified using the public keys of the approval request sources B to D (step 10). If it is determined that the approval request destination is valid, the process proceeds to step 11. If it is determined that the approval request is not valid, the processes after step 12 are not performed.
  • step 11 when n (m ⁇ n ⁇ 1) or more approvals among m private nodes are obtained, the block determination condition is satisfied, and it is determined to add a block to the distributed database 4. .
  • the approval request source A performs processing for recording the confirmed block in the distributed database 4. Specifically, first, in the own node A, the transaction Tr included in the confirmed block is deleted from the processing waiting area, and the confirmed block is added to the own database 4. In addition, a notification indicating that a confirmed block is newly added is transmitted to the entire transaction processing network 1 including the other nodes B to D connected to the own node A. All nodes 2 receive the confirmation of the confirmed block, verify the signature of the notification source, and add the confirmed block to their own database 4a. Further, all the nodes 2 (including nodes B to D) holding the unprocessed transaction Tr in the processing waiting area delete the transaction Tr included in the confirmed block from the processing waiting area with this notification (Step S1). 13). On the other hand, when the block determination condition is not satisfied, the block generated this time is canceled. As a result, the unprocessed transaction Tr in the processing waiting area is continuously held, and the next generation and subsequent block generation opportunities are awaited.
  • FIG. 9 is an explanatory diagram of the structure of the database 4a.
  • blocks serving as recording units are connected in a chain according to the recording order.
  • Each block (determined block) has a plurality of transactions and a hash of the previous block.
  • a certain block 2 includes the hash H1 of the previous block 1 inherited from the previous block 1.
  • the hash H2 of the block 2 is calculated in a form including the transaction group of the own block 2 and the hash H1 inherited from the previous block 1, and this hash H2 is succeeded to the next block.
  • the individual blocks are connected in a chain according to the recording order, and the recorded contents have consistent continuity. Effectively prevent falsification of recorded contents. If past recorded contents are changed, the hash of the block will be different from that before the change, and in order to make the altered block appear correct, all subsequent blocks must be recreated. Is very difficult.
  • step 12 the processing result (OK / NG) of the transaction Tr related to the recording request is sent from any private node 2b (approval requesting source A) to the public node 2a that is the recording requesting source of the transaction Tr. Be notified.
  • the public node 2a receives the processing result and presents the processing result to the user (step 14).
  • the transaction recording process is completed through the above series of processes.
  • the node 2 constituting the transaction processing network 1 is divided into the public node 2a and the private node 2b.
  • the public node 2a plays a role of generating a transaction to be recorded, and subsequent recording processing to the distributed database 4 is performed by cooperation of the private node 2b group.
  • the generation of a transaction is widely recognized as a public node 2a that can include an unreliable node, while the recording process to the distributed database 4 is limited to a reliable private node 2b.
  • a relatively simple consensus of multiple signatures (multisig) using public key cryptography instead of high-cost and slow consensus algorithms such as POW and POS is used as a reliable authentication method for the private node 2b.
  • An algorithm is used.
  • the same private node 2b is prohibited from continuously transmitting block approval requests so that the frequency of block generation by a specific private node 2b does not become extremely high. Thereby, it is possible to effectively cope with a hacking act such as causing a specific private node 2b to always generate a block and applying an excessive load.
  • the present invention can also be understood as a computer program that implements the public node device 20 or the private node device 21 described above.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

取引情報が記されたトランザクションをブロック化して分散データベースに取り込むネットワークにおいて、記録の信頼性と応用分野の拡張性との両立を図る。ネットワークを構成するノードを、パブリックノード２ａと、プライベートノード２ｂとに区分する。パブリックノード２ａは、記録すべきトランザクションを生成する役割を担い、その後の分散データベースへの記録処理は、複数のプライベートノード２ｂが協働することによって行われる。トランザクションの生成については、信頼できないノードを含み得るパブリックノード２ａとして広く認めつつ、分散データベースへの記録処理については信頼できるプライベートノード２ｂに限定する。

Description

プライベートノード、プライベートノードにおける処理方法、及びそのためのプログラム
　本発明は、プライベートノード／パブリックノード用のノード装置およびコンピュータプログラムに係り、特に、取引に関する情報を記したトランザクションをブロック化した上で、分散データベースに取り込むネットワークの仕組みに関する。
　従来、ブロックチェーンと称される技術が知られている。この技術は、ネットワーク上の多数のノード間で同一の記録を同期させる仕組みであって、既存の記録に新しい記録を追加する場合、記録単位となるブロックが、直前のブロックの内容（ハッシュ）を引き継ぎながら、チェーン状に次々と追加されていくことから、このように称されている。一般に、ブロックチェーンという用語は、ブロックがチェーン状に繋がったデータベースの構造を指すこともあるが、Ｐ２Ｐネットワークとして稼働する仕組みや、トランザクションの承認の仕組みなども含めた広義の意味で用いられることもあり、現時点において、その定義は定かではない。そこで、本明細書では、両者の混同を防ぐために、前者の狭義の意味で用いる場合は「ブロックチェーン」、後者の広義の意味で用いる場合は「ブロックチェーン技術」とそれぞれ称することとする。
　ブロックチェーン技術は、ゼロダウンタイム、改ざんの困難性、低コストといった多くの利点を有しているため、ビットコイン（bitcoin）やその派生通貨を含む仮想通貨にとどまらず、様々な資産（asset）に関する情報をトランザクションとして管理する手法としても注目され始めている。例えば、非特許文献１には、信頼性確立のために重要な役割を果たし得るブロックチェーンを、様々な文書の存在証明やアイデンティティ証明に使うことが記載されている。
ブロックチェーンはサイバー空間での信頼関係を築く――「存在証明」や「アイデンティティ証明」が持つ重要な意味、［online］、［平成２８年３月２８日検索］、インターネット＜URL：http://diamond.jp/articles/-/53050＞
　ブロックチェーン技術には、主に、パブリックノード方式と、プライベートノード方式とが存在する。パブリックノード方式は、ネットワーク上のノードとして誰もが参加可能な方式であり、ビットコインなどでも採用されている。誰もが参加可能であるということは、信頼できないノードが存在し得るため、データの改ざん等を防止するために、ＰＯＷ（Proof Of Work）やＰＯＳ（Proof Of Stake）といった高コストで遅いコンセンサスアルゴリズムが必要になる。一方、プライベートノード方式は、ネットワーク上のノードとして許可された者のみが参加可能な方式である。この方式は、信頼できるノードのみで構成されることから、パブリック方式のような高度なコンセンサスアルゴリズムを用いなくとも、十分な信頼性を確保できる。ブロックチェーン技術を用いて、様々な資産の取引に対応可能なシステムを構築する場合、高度な信頼性を確保するためには、ブライベートノード方式の方が優れているが、上記のようなノードの制約上、応用分野が限られてしまうといった不都合がある。一方、パブリックノード方式は、様々な応用分野に柔軟に対応できる反面、信頼できないノードによるデータの改ざん等が問題となり、記録の信頼性の点で難がある。
　本発明は、かかる事情に鑑みてなされたものであり、その目的は、取引情報が記されたトランザクションをブロック化して分散データベースに取り込むネットワークにおいて、記録の信頼性と応用分野の拡張性との両立を図ることである。
　かかる課題を解決すべく、第１の発明は、取引情報を記したトランザクションを生成する複数のパブリックノードと、ノード数が制限された複数のプライベートノードと、それぞれのノードが同一の記録内容を同期して保持し、かつ、記録単位となるブロックが記録順序にしたがい繋がった分散データベースとを有するトランザクション処理ネットワークにおける、プライベートノード用のノード装置を提供する。このノード装置は、ブロック生成部と、承認依頼部と、ブロック確定部とを有する。ブロック生成部は、第１のパブリックノードによって生成された第１のトランザクションを含む第１のブロックを生成する。承認依頼部は、第１のブロックに自ノードの秘密鍵による署名を付した上で、予め設定されたｍ（ｍ≧２）個のプライベートノード群に対して、第１のブロックの承認依頼を送信する。ブロック確定部は、承認の依頼先となるプライベートノードより第１のブロックの承認結果を受信した場合、この承認結果に付された署名の正当性を承認の依頼先の公開鍵を用いて検証した上で、ｍ個のプライベートノード群のうちのｎ（ｍ≧ｎ≧１）個以上の承認が得られたことを条件として、分散データベースに第１のブロックを追加することを確定する。
　ここで、第１の発明において、上記ブロック確定部は、分散データベースに第１のブロックを追加することが確定した場合、第１のパブリックノードに対して、第１のトランザクションの処理結果を通知することが好ましい。
　第１の発明において、承認応答部をさらに設けてもよい。この承認応答部は、承認の依頼元となるプライベートノードより第１のブロックの承認依頼を受信した場合、この承認依頼に付された署名の正当性を承認の依頼元の公開鍵を用いて検証した上で、自ノードの処理待ち領域に格納されたトランザクションに関するデータを参照して、承認依頼に係る第１のブロックの内容を検証すると共に、自ノードの秘密鍵による署名を付した承認結果を承認の依頼元となるプライベートノードに送信する。
　第１の発明において、上記ｎは、上記ｍの過半数であることが好ましい。また、上記ブロック生成部は、自ノードで第１のブロックを生成した場合、少なくとも、他ノードによって生成された他のブロックを分散データベースに追加することが確定するまで、新たなブロックの承認依頼を連続して送信することなく待機してもよい。さらに、トランザクション処理ネットワークにおいて、プライベートノードの公開鍵を追加または失効させるプロトコルが予め用意されていることが好ましい。
　第２の発明は、取引情報を記したトランザクションを生成する複数のパブリックノードと、ノード数が制限された複数のプライベートノードと、それぞれのノードが同一の記録内容を同期して保持し、かつ、記録単位となるブロックが記録順序にしたがい繋がった分散データベースとを有するトランザクション処理ネットワークにおける、パブリックノード用のノード装置を提供する。このノード装置は、トランザクション生成部と、記録依頼部と、結果受領部とを有する。トランザクション生成部は、第１のトランザクションを生成する。記録依頼部は、第１のトランザクションを少なくとも一つのプライベートノードに送信して、第１のトランザクションの記録を依頼する。結果受領部は、第１のトランザクションを受信したプライベートノードのいずれかにおいて生成され、かつ、第１のトランザクションを含む第１のブロックについて、ブロック確定条件を満たすことで、分散データベースに追加することが確定した場合、第１のトランザクションを受信したプライベートノードのいずれかより送信される、第１のトランザクションの記録が完了した旨の処理結果を受領する。ブロック確定条件は、公開鍵暗号による多重署名を用いたプライベートノード間の承認プロトコルによって、予め設定されたｍ（ｍ≧２）個のプライベートノードのうちのｎ（ｍ≧ｎ≧１）個以上の承認が得られたことである。
　第３の発明は、取引情報を記したトランザクションを生成する複数のパブリックノードと、ノード数が制限された複数のプライベートノードと、それぞれのノードが同一の記録内容を同期して保持し、かつ、記録単位となるブロックが記録順序にしたがい繋がった分散データベースとを有するトランザクション処理ネットワークにおける、プライベートノード用のコンピュータプログラムを提供する。このコンピュータプログラムは、第１のパブリックノードによって生成された第１のトランザクションを含む第１のブロックを生成する第１のステップと、第１のブロックに自ノードの秘密鍵による署名を付した上で、予め設定されたｍ（ｍ≧２）個のプライベートノードに対して、第１のブロックの承認依頼を送信する第２のステップと、承認の依頼先となるプライベートノードより第１のブロックの承認結果を受信した場合、この承認結果に付された署名の正当性を承認の依頼先の公開鍵を用いて検証した上で、ｍ個のプライベートノードのうちのｎ（ｍ＞ｎ≧１）個以上の承認が得られたことを条件として、分散データベースに第１のブロックを追加することを確定する第３のステップとを有する処理をコンピュータに実行させる。
　ここで、第３の発明において、上記第３のステップは、分散データベースに第１のブロックを追加することが確定した場合、第１のパブリックノードに対して、第１のトランザクションの処理結果を通知するステップを含むことが好ましい。
　第３の発明において、承認の依頼元となるプライベートノードより第１のブロックの承認依頼を受信した場合、この承認依頼に付された署名の正当性を承認の依頼元の公開鍵を用いて検証した上で、自ノードの処理待ち領域に格納されたトランザクションに関するデータを参照して、承認依頼に係る第１のブロックの内容を検証すると共に、自ノードの秘密鍵による署名を付した承認結果を承認の依頼元となるプライベートノードに送信する第４のステップをさらに設けてもよい。
　第３の発明において、上記ｎは、上記ｍの過半数であることが好ましい。また、上記第１のステップは、自ノードで第１のブロックを生成した場合、少なくとも、他ノードによって生成された他のブロックを分散データベースに追加することが確定するまで、新たなブロックの承認依頼を連続して送信することなく待機するステップを含んでいてもよい。さらに、上記トランザクション処理ネットワークにおいて、プライベートノードの公開鍵を追加または失効させるプロトコルが予め用意されていることが好ましい。
　第４の発明は、取引情報を記したトランザクションを生成する複数のパブリックノードと、ノード数が制限された複数のプライベートノードと、それぞれのノードが同一の記録内容を同期して保持し、かつ、記録単位となるブロックが記録順序にしたがい繋がった分散データベースとを有するトランザクション処理ネットワークにおける、パブリックノード用のコンピュータプログラムを提供する。このコンピュータプログラムは、第１のトランザクションを生成する第１のステップと、第１のトランザクションを少なくとも一つのプライベートノードに送信して、第１のトランザクションの記録を依頼する第２のステップと、第１のトランザクションを受信したプライベートノードのいずれかにおいて生成され、かつ、第１のトランザクションを含むブロックについて、公開鍵暗号による多重署名を用いたプライベートノード間の承認プロトコルによって、予め設定されたｍ（ｍ≧２）個のプライベートノードのうちのｎ（ｍ≧ｎ≧１）個以上の承認が得られたことを条件として、分散データベースに第１のブロックを追加することが確定した場合、第１のトランザクションを受信したプライベートノードのいずれかより送信される、第１のトランザクションの記録が完了した旨の処理結果を受領する第３のステップとを有する処理をコンピュータに実行させる。
　本発明によれば、トランザクション処理ネットワークを構成するノードを、パブリックノードと、プライベートノードとに区分している。パブリックノードは、取引情報を記したトランザクションを生成する役割を担い、その後の処理は、公開鍵暗号を用いた多重署名（マルチシグ）という低コストかつ高速なコンセンサスアルゴリズムを用いて、プライベートノード同士が協働することによって行われる。トランザクションの生成については、信頼できないノードを含み得るパブリックノードとして広く認めつつ、その後のブロックの生成や確定といった処理は、信頼できるプライベートノードに制限する。これにより、パブリックノード方式の利点である応用分野の拡張性と、プライベートノード方式の利点である記録の信頼性との両立を図ることができる。
トランザクション処理ネットワークの物理的な構成図 トランザクション処理ネットワークの論理的な構成図 プライベートノードにおける公開鍵の設定方法の説明図 パブリックノード用のノード装置の機能的なブロック図 プライベートノード用のノード装置の機能的なブロック図 トランザクションの記録処理のフローを示す図 トランザクションの処理待ち状態を示す図 多重署名によるブロック承認の説明図 データベース構造の説明図
　図１は、本発明の一実施形態に係るトランザクション処理ネットワークの物理的な構成図である。このトランザクション処理ネットワーク１は、取引に関する情報を管理する管理システムとして用いられる。どのような取引を管理の対象とするかは、その用途に応じて、システムの仕様として予め決められている。例えば、銀行システムであれば、実通貨の取引が対象となり、証券システムであれば証券の取引が対象となる。本明細書において、「取引」とは、実通貨、仮想通貨、証券、不動産等の資産ないしこの資産の状態の保持（ストック）、資産の移転（フロー）はもとより、契約も含む概念をいい、契約は、資産にも負債にもなり得る。また、デリバティブの概念を導入することで、より広い範囲の取引を定義できる。
　例えば、「ＡからＢへ１億円を送金する」や「ＡからＢへ特定株を５００株受け取る」といったことは、資産の移転（フロー）と同義であり、１方向の取引として捉えることができる。「Ａは１億円の預金を保有している」や「Ａは特定株を５００株持っている」といったことは、資産そのものとも捉えることができるし、資産の状態の保持（ストック）という概念としても捉えることができる。「ＡはＢから米ドルを１億円分購入する」や「ＡはＢから特定株を５００株分、１株１０００円で購入する」といったことは、資産の移転（フロー）が２つ同時に起こる２方向の取引として捉えることができる。
　トランザクション処理ネットワーク１は、Ｐ２Ｐ（Peer to Peer）型のネットワークであり、純粋なＰ２Ｐのみならず、いわゆるハイブリッド型（一部にクライアントサーバ型の構成を含むもの）も含まれる。トランザクション処理ネットワーク１に参加（接続）するノード２は、１対１の対等の関係で通信（Ｐ２Ｐ通信）を行う。それぞれのノード２は、ノード装置として、コンピュータ３と、データベース４ａとを有している。取引に関する情報は、ネットワーク１上の分散データベース４、すなわち、ノード２毎に設けられたデータベース４ａの集合体によって管理される。ネットワーク１上に存在するすべてのデータベース４ａは、ブロックチェーン技術によって同期しており、基本的に、同一の記録内容を保持している。権限を有するノード２が分散データベース４を更新する場合、自ノード２に接続されている他ノード２にその旨が通知され、以後、ノード間のＰ２Ｐ通信が繰り返されることによって、最終的に、ネットワーク１の全体に通知が行き渡る。これにより、すべてのノード２のデータベース４ａが更新され、同一の記録内容として共有されることになる。
　ネットワーク１におけるＰ２Ｐ通信は、セキュリティを確保すべく、ＳＳＬ通信にて行われる。また、ノード２間で受け渡しされるトランザクションの正当性については、公開鍵暗号を用いた電子署名によって検証される。その前提として、それぞれのノード２は、自己が管理するアドレスの秘密鍵（暗証番号）を保持している（ネットワークアドレスの所有者＝秘密鍵の保有者）。公開鍵は、秘密鍵より一義的に特定される。ネットワークアドレスは、公開鍵そのものを用いてもよいし、ビットコイン等と同様、公開鍵をハッシュしてチェックサムを加えたものを用いてもよい。トランザクションの送り手（資産の移動元）は、送ろうとするトランザクションに自己が管理するアドレスの秘密鍵による署名を付した上で送信する。トランザクションの受け手は、受け取ったトランザクションに付された署名の正当性を、この秘密鍵に対応する公開鍵にて検証する。なお、ここで用いられる公開鍵暗号は、後述するブロックの承認に関する多重署名（マルチシグ）の公開鍵暗号とは別個のものである。マルチシグの秘密鍵は、上記のネットワークアドレスとは関係なく、プライベートノード２ｂのみが保有する。
　なお、図１は、個々のノード２が他の全ノード２に接続されたフルコネクト型を示しているが、これは一例であって、どのようなトポロジーを採用してもよい。また、特定のノード２に情報を送信する場合、Ｐ２Ｐ通信による間接的な送信ではなく、アドレスを指定して送信先に直接送信できるようなプロトコルを導入してもよい。
　図２は、一実施形態におけるトランザクション処理ネットワーク１の論理的な構成図である。本実施形態において、トランザクション処理ネットワーク１を構成するノード２には、パブリックノード２ａと、プライベートノード２ｂとが存在する。パブリックノード２ａは、取引の主体となるアプリケーションノードである（信頼できないノードを含み得る）。パブリックノード２ａは、取引に関する情報を記したトランザクションを生成し、これに署名した上で、プライベートノード２ｂ群に直接的または間接的に送信する。パブリックノード２ａは、プライベートノード２ｂ群へのトランザクションの記録依頼のみ行い、自身では、分散データベース４への記録処理は行わない。パブリックノード２ａにとって重要なことは、（最新でなくてもいいので）クエリーができること、新規に作成したトランザクションに署名すること、および、トランザクションの承認をプライベートノード２ｂ群に依頼することである。
　なお、例えば、あるアドレスの残高を算出するといった検索時に、処理の高速化を図るべく、複数のパブリックノード２ａの一部において、データベース４ａの記録内容をインデックス付きで管理してもよい。分散データベース４のデータは基本的にKey-Value型なので、条件付の照会に非常に時間がかかるという欠点がある。その解決のために検索用の独自のインデックスを持ったノードを設けることで、応用範囲を拡張できる。
　プライベートノード２ｂは、ノード数が制限された信頼できるノードであって、パブリックノード２ａより依頼されたトランザクションについて、分散データベース４への記録処理を行う。この記録処理は、後述するように、プライベートノード２ｂ群が協働することによって行われる。記録処理が完了した場合、処理結果が依頼元のパブリックノード２ａに通知される。プライベートノード２ｂにとって重要なことは、トランザクションを承認してブロック化した上で、分散データベース４に追加することであって、ビットコインなどの仮想通貨で採用されているマイニングや手数料といった報酬（インセンティブ）は、必ずしも必要ではない。
　複数のプライベートノード２ｂは、公開鍵暗号を用いて、ブロックの承認に関する多重署名（マルチシグ）によるブロックの承認を行う。そのため、図３に示すように、それぞれのプライベートノード２ｂは、自ノードの秘密鍵を有している。それとともに、公開鍵が記述されたコンフィグファイルをシステムの起動時に読み込むことによって、プライベートノード２ｂの間で公開鍵が共有されている。また、プライベートノード２ｂの公開鍵を追加または失効させるプロトコルが用意されており、このプロトコルを実行することで、コンフィグファイルを書き換えなくても、公開鍵を追加または失効させることができる。この公開鍵に関する情報は、厳密な管理が要求されるので、安全性を確保すべく、ＳＳＬ等によってやり取りされる。
　図４は、パブリックノード２ａ用のノード装置（以下、「パブリックノード装置２０」という。）の機能的なブロック図である。このパブリックノード装置２０は、トランザクション生成部２０ａと、記録依頼部２０ｂと、結果受領部２０ｃとを有する。トランザクション生成部２０ａは、所定のフォーマットにしたがい、取引に関する情報が記されたトランザクションを生成する。取引に関する情報は、例えば、表示画面の指示にしたがいユーザが入力した入力情報より、あるいは、別のネットワークを通じて受信した受信情報より取得される。記録依頼部２０ｂは、トランザクション生成部２０ａによって生成されたトランザクションに、自己が管理するアドレスの秘密鍵による署名を付した上で、ノード2間のＰ２Ｐ通信を介してプライベートノード２ｂ群に送信し、トランザクションを記録すべき旨をプライベートノード２ｂ群に依頼する。結果受領部２０ｃは、いずれかのプライベートノード２ｂより送信されたトランザクションの処理結果を受領し、これをユーザに提示する。
　図５は、プライベートノード２ｂ用のノード装置（以下、「プライベートノード装置２１」という。）の機能的なブロック図である。このプライベートノード装置２１は、署名検証部２２と、トランザクション処理部２３とを有する。署名検証部２２は、パブリックノード２ａより記録依頼として受け付けたトランザクションに付された署名の正当性を、秘密鍵に対応する公開鍵を用いて検証する。なお、署名の他に、その資産が二重使用されていないことなども併せて検証される。
　トランザクション処理部２３は、署名が正当であると検証できたことを前提として、所定の条件を満たす場合に、トランザクションを分散データベース４に記録する。このトランザクション処理部２３は、ブロック生成部２３ａと、承認依頼部２３ｂと、ブロック確定部２３ｃと、承認応答部２３ｄとを有する。
　ここで、プライベートノード装置２１は、２つの役割を担っている。一つは、自ノード２ｂがブロックを生成し、他ノード２ｂにブロックの承認を依頼する役割であり、そのための構成として、ブロック生成部２３ａと、承認依頼部２３ｂと、ブロック確定部２３ｃとが存在する。そして、もう一つは、他のプライベートノード２ｂが生成したブロックを承認する役割であり、そのための構成として、承認応答部２３ｄが存在する。このように、プライベートノード２ｂは、自ノード２ｂが生成したブロックの承認を他ノード２ｂに依頼する依頼方、および、他ノード２ｂによって生成されたブロックの承認を自ノード２ｂが行う承認方のどちらにもなり得る。
　ブロック生成部２３ａは、トランザクションの記録の依頼元となるパブリックノード２ａより記録処理の依頼を受けたトランザクションを複数まとめることによって、ブロックを生成する。承認依頼部２３ｂは、ブロック生成部２３ａによって生成されたブロックに自ノード２ｂの秘密鍵による署名を付した上で、システムのコンフィグとして予め設定されたｍ（ｍ≧２）個の他のプライベートノード群２ｂに対して、ブロックの承認依頼を送信する。承認の依頼先のノードには、自ノードを含めてもよい。ブロック確定部２３ｃは、承認の依頼先となるプライベートノード２ｂよりブロックの承認結果を受信した場合、この承認結果に付された署名の正当性を、承認の依頼先の秘密鍵に対応する公開鍵を用いて検証した上で、以下のブロック確定条件を満たすか否かを判定する。
［ブロック確定条件］
　ｍ（ｍ≧２）個のプライベートノード２ｂのうち、
　ｎ（ｍ≧ｎ≧１）個以上の承認が得られたこと
　このブロック確定条件において、ｎはｍの過半数であることが好ましい。これにより、合理的かつ現実的な範囲で承認の信頼性を確保することができる。例えば、図２に示した４つのプライベートノード２ｂが存在するケースでは、３個（ｍ＝３）のプライベートノード２ｂに承認を依頼し、そのうちの２個（ｎ＝２）以上の承認が得られたことをもって、ブロック確定条件が満たされることになる。
　ｍは、一桁、二桁等の限られた数以下であることが好ましく、ブロック確定条件に応じて、５個、９個等の奇数個であることが好ましいことがある。ｎは、ｍの過半数であることに加えて、過半数以上の指定された所定の数であることが好ましいことがある。
　ブロック確定条件としては、上述の説明では一ノード一票の承認が可能とされているところ、各ノードに任意の正の実数の票を与え、その過半数によって承認が得られたことと判定することもできる。この場合、「過半数」とは、総票数に対する半数を超える数であることを付言する。
　承認依頼に係るブロックがブロック確定条件を満たす場合には、このブロックを分散データベース４に追加することが確定し、これを満たさない場合には、分散データベース４へのブロックの追加は行われない。ブロック確定部２３ｃは、トランザクションの記録の依頼元となるパブリックノード２ａに対して、トランザクションの処理結果（ＯＫ／ＮＧ）を通知する。分散データベース４へのブロックの追加が確定した場合、自ノード２ｂのデータベース４ａにブロックが追加されると共に、ブロックの確定に伴い新たなブロックを追加する旨が、トランザクション処理ネットワーク１の全ノード２に通知される。この通知によって、すべてのノード２のデータベース４ａ、すなわち、分散データベース４が更新される。
　全ノード２に直接的又は間接的に通知されることが求められるが、ブロックの確定に伴い新たなブロックを追加する旨が全ノード２に直接的に通知される場合のほか、プライベートノード２ｂの全て及びパブリックノード２ａの一部、プライベートノード２ｂの全て、プライベートノード２ｂの一部及びパブリックノード２ａの一部、又はプライベートノード２ｂの一部に通知される場合も考えられる。
　一方、承認応答部２３ｄは、承認の依頼元となるプライベートノード２ｂよりブロックの承認依頼を受信した場合、この承認依頼に付された署名の正当性を、公開鍵（承認の依頼元の秘密鍵に対応するもの）を用いて検証する。また、承認応答部２３ｄは、自ノード２ｂに記録されているトランザクションに関するデータを参照して、承認依頼に係るブロックの内容(ブロック中のトランザクションの整合性を含む。)を検証する。そして、内容が正当であるとの検証結果が得られた場合、承認応答部２３ｄは、自ノード２ｂの秘密鍵による署名を付した承認結果を承認の依頼元となるプライベートノード２ｂに送信する。
　なお、ブロック生成部２３ａは、プライベートノード２ｂのハッキング対策として、すなわち、プライベートノード２ｂがハッキングされたときのために、自ノード２ｂで一のブロックを生成した場合、少なくとも、他ノード２ｂによって生成された他のブロックを分散データベース４に追加することが確定するまで、新たなブロックの承認依頼を連続して送信することなく待機する。すなわち、同一のプライベートノード２ｂにおいて、ブロック確定の処理を連続して行うことは禁止されている。
　つぎに、図６を参照しながら、トランザクションの記録処理のフローについて説明する。まず、あるパブリックノード２ａにおいて、取引に関する情報が記されたトランザクションＴｒが生成され（ステップ１）、このトランザクションＴｒに自己が管理するアドレスの秘密鍵による署名を付した上で、プライベートノード２ｂ群にトランザクションＴｒの記録依頼が送信される（ステップ２）。例えば、図７に示すように、資産の移動元ａに関するトランザクションＴｒ１については、移動元ａが管理するアドレスの秘密鍵による署名「ａ」が付され、トランザクションＴｒ２，Ｔｒ３についても同様に署名される。
　トランザクションＴｒの記録依頼を受信したプライベートノード２ｂのそれぞれは、記録依頼に付された署名を、移動元の秘密鍵に対応する公開鍵を用いて検証する（ステップ３）。図７に示したように、トランザクションＴｒ１に付された署名「ａ」については、移動元ａの秘密鍵に対応する公開鍵を用いて検証され、トランザクションＴｒ２，Ｔｒ３についても同様に検証される。なお、署名の他に、その資産が二重使用されていないことなども併せて検証されることは上述したとおりである。それぞれのプライベートノード２ｂにおいて、署名の正当性などが確認できた場合、トランザクションＴｒ１～Ｔｒ３は、自ノード２ｂの記憶装置における所定の記憶領域（処理待ち領域）に一時的に格納される（ステップ４）。また、このステップ４において、資産の移動元が正当でないとされた場合、依頼元となるパブリックノード２ａに対して、その旨が通知される。
　ステップ５では、いずれかのプライベートノード２ｂにおいて、ブロックが生成される。このブロックは、自ノード２ｂの処理待ち領域に格納されている複数のトランザクションＴｒをまとめたものである。そして、ステップ６において、図８（ａ）に示すようなデータ構造を有する署名付の承認依頼が生成される。このデータ構造は、ブロックの承認を依頼する依頼元の署名欄と、複数のトランザクションＴｒをまとめたブロック本体と、ブロックの承認先の署名欄とを有する。ただし、同図の構成は、説明の便宜上のものであって、実際には、依頼元／承認先の署名欄を別ける必要はない。図２に示した４つのプライベートノード２ｂ群（ノード名をＡ～Ｄとする。）のうち、ノードＡがブロックを生成した場合、図８（ａ）の依頼元署名欄には、ノードＡの秘密鍵による署名「Ａ」が記入され、承認先署名欄（ノードＢ～Ｄの署名が記入される欄）はブランクとされる。ノードＡにて生成された承認依頼は、他のプライベートノード２ｂ、すなわち、３つのノードＢ～Ｄに送信される。
　ステップ７～９は、ブロックの承認依頼を受信したプライベートノード２ｂ、すなわち、承認の依頼先Ｂ～Ｄの処理である。まず、ステップ７において、承認依頼に付された署名「Ａ」等の正当性が、承認の依頼元であるノードＡ等の公開鍵を用いて検証される（ステップ７）。このステップ７では、ノードＡだけでなく、その検証時点で付されている他の署名も一緒に検証される。基本的に、ノードＡ→Ｂ→Ｃ→Ｄのように順番に署名していき、過半数（ｎ）の署名が得られた時点で確定する。どのようにして順番を保つかについては、様々な実装方法が考えられる。なお、ブロックの署名の検証自体は、ハッキングされたブロックを信用することがないように、プライベートノード２ｂのみならず、すべてのパブリックノード２ａでも行われる。承認の依頼元が正当であるとされた場合には、ステップ８に進み、正当でないとされた場合には、ステップ８以降の処理は行われない。
　ステップ８において、承認依頼に係るブロックの内容が検証される。具体的には、自ノード２ｂの処理待ち領域に格納されたトランザクションを参照して、ブロックの内容が少なくとも以下の承認条件を満たす場合に、ブロックを承認する。ブロックの内容が正当であるとされた場合には、ステップ９に進み、正当でないとされた場合には、ステップ９の処理は行われない（処理結果＝ＮＧ）。
［ブロックの承認条件］
（１）ブロック中のすべてのトランザクションＴｒが自ノード２ｂにおいて未処理であること（重複記録の防止）
（２）ブロック中のすべてのトランザクションＴｒの内容が、自ノード２ｂの処理待ち領域に格納されたトランザクションＴｒの内容と一致すること（データの改ざん防止）
（３）個々のトランザクションＴｒの資産が未使用であること（資産の二重使用の禁止）
　ステップ９において、署名付の承認結果が生成される。承認可の場合には、図８（ｂ）に示すように、承認先署名欄のうちの自ノード２ｂに割り当てられた欄に自己の秘密鍵による署名が記入される。署名が付された承認結果は、承認の依頼元Ａに送信される。
　ステップ１０～１２は、ブロックの承認結果を受信したプライベートノード２ｂ、すなわち、承認の依頼元Ａの処理である。まず、ステップ１０において、承認結果に付された署名の正当性が、承認の依頼元Ｂ～Ｄの公開鍵を用いて検証される（ステップ１０）。承認の依頼先が正当であるとされた場合には、ステップ１１に進み、正当でないとされた場合には、ステップ１２以降の処理は行われない。
　ステップ１１において、ｍ個のプライベートノードのうちのｎ（ｍ≧ｎ≧１）個以上の承認が得られた場合、ブロック確定条件が満たされて、分散データベース４にブロックを追加することが確定する。図８（ｂ）の例では、承認を依頼した３つのノードＢ～Ｄのうち、２つのノードＢ，Ｃの承認は得られたが、ノードＤの承認は得られなかったことを意味している。この場合、ブロック確定条件が過半数以上の承認であるならば、ｎ／ｍ＝２／３となって条件を満たすことになる。逆に、ｎ＝０，１の場合には、ブロック確定条件は満たされない。
　ブロック確定条件が満たされた場合、承認の依頼元Ａによって、確定したブロックを分散データベース４に記録する処理が行われる。具体的には、まず、自ノードＡにおいて、処理待ち領域から確定ブロックに含まれるトランザクションＴｒが削除され、自己のデータベース４に確定したブロックが追加される。また、自ノードＡに接続されている他ノードＢ～Ｄを含めて、トランザクション処理ネットワーク１の全体に、確定したブロックを新規に追加する旨の通知が送信される。すべてのノード２は、この確定ブロックの通知を受けた時点で、通知元の署名の検証を行った上で、自己のデータベース４ａに確定ブロックを追加する。また、処理待ち領域に未処理トランザクションＴｒを保持しているすべてのノード２（ノードＢ～Ｄを含む。）は、この通知をもって、確定ブロックに含まれるトランザクションＴｒを処理待ち領域から削除する（ステップ１３）。これに対して、ブロック確定条件が満たされない場合、今回生成したブロックはキャンセルされる。これによって、処理待ち領域の未処理トランザクションＴｒは引き続き保持され、次回以降のブロックの生成機会を待つことになる。
　図９は、データベース４ａの構造の説明図である。この構造において、記録単位となるブロックは記録順序にしたがいチェーン状に繋がっている。それぞれのブロック（確定ブロック）は、複数のトランザクションと、直前のブロックのハッシュとを有している。具体的には、あるブロック２には、その前のブロック１から引き継いだ前ブロック１のハッシュＨ１が含まれている。そして、ブロック２のハッシュＨ２は、自ブロック２のトランザクション群と、前ブロック１から引き継がれたハッシュＨ１とを含めた形で算出され、このハッシュＨ２は、その次のブロックに引き継がれる。このように、直前のブロックの内容をハッシュとして引き継ぎながら（Ｈ０，Ｈ１，・・・）、記録順序にしたがい個々のブロックをチェーン状に繋げ、記録内容に一貫した連続性を持たせることで、記録内容の改ざんを有効に防止する。過去の記録内容が変更された場合、ブロックのハッシュが変更前と異なる値になり、改ざんしたブロックを正しいものとみせかけるには、それ以降のブロックすべてを作り直さなければならず、この作業は現実的には非常に困難である。
　そして、ステップ１２において、いずれかのプライベートノード２ｂ（承認の依頼元Ａ）から、トランザクションＴｒの記録の依頼元となるパブリックノード２ａに、記録依頼に係るトランザクションＴｒの処理結果（ＯＫ／ＮＧ）が通知される。このパブリックノード２ａは、処理結果を受領し、ユーザに対して処理結果を提示する（ステップ１４）。以上の一連のプロセスを経て、トランザクションの記録処理が完了する。
　なお、以上のようなトランザクションの記録処理では、複数のプライベートノード２ｂが同一のトランザクションを含む別個のブロックを同時に生成してしまう可能性、すなわち、プライベートノード２ｂ同士の処理の競合が生じる可能性がある。かかる問題は、例えば、ラウンドロビン（round robin）のように、プライベートノード２ｂ間でブロック生成の順番を割り当てて排他制御を行うことで、解決することができる。また、プライベートノード２ｂ群に優先順位を割り当てて、上記競合が生じた場合には、優先順位の高いプライベートノード２ｂのみに、競合したトランザクションの再処理を認めてもよい。
　このように、本実施形態によれば、トランザクション処理ネットワーク１を構成するノード２を、パブリックノード２ａと、プライベートノード２ｂとに区分している。パブリックノード２ａは、記録すべきトランザクションを生成する役割を担い、その後の分散データベース４への記録処理は、プライベートノード２ｂ群が協働することによって行われる。トランザクションの生成については、信頼できないノードを含み得るパブリックノード２ａとして広く認めつつ、分散データベース４への記録処理については信頼できるプライベートノード２ｂに限定する。このように、パブリックノード２ａの役割と、プライベートノード２ｂの役割とを別けることで、パブリックノード方式の利点である応用分野の拡張性と、プライベートノード方式の利点である記録の信頼性との両立を図ることができる。
　また、本実施形態によれば、信頼できるプライベートノード２ｂ相互の認証手法として、ＰＯＷやＰＯＳといった高コストで遅いコンセンサスアルゴリズムではなく、公開鍵暗号を用いた多重署名（マルチシグ）という比較的簡素なコンセンサスアルゴリズムを用いている。これにより、記録の信頼性を損なうことなく、大量のトランザクションを高速かつ確実に処理することが可能になる。
　さらに、本実施形態によれば、特定のプライベートノード２ｂによるブロックの生成頻度が極端に高くならないように、同一のプライベートノード２ｂがブロックの承認依頼を連続して送信することを禁止している。これにより、特定のプライベートノード２ｂにブロックを常に生成させ続けて過剰な負荷をかけるなどのハッキング行為に対しても、有効に対処することができる。
　なお、本発明は、上述したパブリックノード装置２０またはプライベートノード装置２１を実現するコンピュータプログラムとしても捉えることができる。
　１　トランザクション処理ネットワーク
　２　ノード
　２ａ　パブリックノード
　２ｂ　プライベートノード
　３　コンピュータ
　４　分散データベース
　４ａ　データベース
　２０　パブリックノード装置
　２０ａ　トランザクション生成部
　２０ｂ　記録依頼部
　２０ｃ　結果受領部
　２１　プライベートノード装置
　２２　署名検証部
　２３　トランザクション処理部
　２３ａ　ブロック生成部
　２３ｂ　承認依頼部
　２３ｃ　ブロック確定部
　２３ｄ　承認応答部

Claims (10)

  1. 　パブリックノード群とプライベートノード群とを有するネットワークにおいて前記プライベートノード群を構成するプライベートノードにおける処理方法であって、
    　複数のトランザクションを有するブロックを生成するステップと、
    　前記ブロックの承認依頼を前記プライベートノード群に送信するステップと、
    　前記プライベートノード群のうちの少なくともいずれかから承認結果を受け取るステップと、
    　前記プライベートノード群のうちの所定の数により承認が得られたことを条件に前記ブロックを確定させてブロックチェーンに追加するステップと
    を含むことを特徴とする処理方法。
  2. 　ブロックの新たな承認依頼は、前記プライベートノード群を構成する他のプライベートノードにおけるブロックの確定がなされるまで待機することを特徴とする請求項１に記載の処理方法。
  3. 前記プライベートノード群は、それを構成するプライベートノードの数が制限されていることを特徴とする請求項１又は２に記載の処理方法。
  4. 　前記プライベートノードの数は、二桁であることを特徴とする請求項３に記載の処理方法。
  5. 　前記所定の数は、一桁の奇数であることを特徴とする請求項１乃至４のいずれかに記載の処理方法。
  6. 　前記ブロックの前記追加がなされた旨を前記プライベートノード群の全て及び前記パブリックノード群の一部に通知するステップをさらに含むことを特徴とする請求項１乃至５のいずれかに記載の処理方法。
  7. 　前記ブロックの前記追加がなされた旨を前記プライベートノード群の一部に通知するステップをさらに含むことを特徴とする請求項１乃至５のいずれかに記載の処理方法。
  8. 　前記プライベートノード群を構成するプライベートノード間でそれぞれの公開鍵が共有されることを特徴とする請求項７に記載の処理方法。
  9. 　コンピュータに、パブリックノード群とプライベートノード群とを有するネットワークにおいて前記プライベートノード群を構成するプライベートノードにおける処理方法を実行されるためのプログラムであって、前記処理方法は、
    　複数のトランザクションを有するブロックを生成するステップと、
    　前記ブロックの承認依頼を前記プライベートノード群に送信するステップと、
    　前記プライベートノード群のうちの少なくともいずれかから承認結果を受け取るステップと、
    　前記プライベートノード群のうちの所定の数により承認が得られたことを条件に前記ブロックを確定させてブロックチェーンに追加するステップと
    を含むことを特徴とするプログラム。
  10. 　パブリックノード群とプライベートノード群とを有するネットワークにおいて前記プライベートノード群を構成するプライベートノードであって、
    　複数のトランザクションを有するブロックを生成して、前記ブロックの承認依頼を前記プライベートノード群に送信し、
    　前記プライベートノード群のうちの少なくともいずれかから承認結果を受け取って、前記プライベートノード群のうちの所定の数により承認が得られたことを条件に前記ブロックを確定させてブロックチェーンに追加することを特徴とするプライベートノード。
PCT/JP2017/012875 2016-03-31 2017-03-29 プライベートノード、プライベートノードにおける処理方法、及びそのためのプログラム WO2017170679A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US16/077,032 US20190036702A1 (en) 2016-03-31 2017-03-29 Private node, processing method for private node, and program for same
EP17775213.6A EP3439231A4 (en) 2016-03-31 2017-03-29 PRIVATE NODE, PROCESSING PROCESS FOR PRIVATE NODES AND PROGRAM THEREFOR
CN201780033768.0A CN109219940B (zh) 2016-03-31 2017-03-29 私有节点以及私有节点中的处理方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016-071341 2016-03-31
JP2016071341 2016-03-31

Publications (1)

Publication Number Publication Date
WO2017170679A1 true WO2017170679A1 (ja) 2017-10-05

Family

ID=59965941

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/012875 WO2017170679A1 (ja) 2016-03-31 2017-03-29 プライベートノード、プライベートノードにおける処理方法、及びそのためのプログラム

Country Status (4)

Country Link
US (1) US20190036702A1 (ja)
EP (1) EP3439231A4 (ja)
CN (1) CN109219940B (ja)
WO (1) WO2017170679A1 (ja)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109040014A (zh) * 2018-06-13 2018-12-18 湖南搜云网络科技股份有限公司 区块链处理方法及装置、区块链节点及存储介质
CN109377364A (zh) * 2018-09-27 2019-02-22 中国联合网络通信集团有限公司 一种建组方法和装置、交易方法和系统
JP6487091B1 (ja) * 2018-03-29 2019-03-20 株式会社電通 Ｉｃｏ管理方法、通信デバイス、ｉｃｏ管理システム及びプログラム
WO2019111506A1 (ja) * 2017-12-04 2019-06-13 ソニー株式会社 情報処理装置、情報処理方法およびプログラム
WO2019193820A1 (ja) * 2018-04-02 2019-10-10 ソニー株式会社 情報処理装置、情報処理方法、およびプログラム
KR20200003625A (ko) * 2018-07-02 2020-01-10 김도영 블록체인 및 분산 인프라 P2P 모델 기반 PoR 증명을 이용한 인터넷 서비스 제공 방법
JP2020511809A (ja) * 2018-12-21 2020-04-16 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ パブリックサイドチェーンを使用してコンソーシアムブロックチェーンに記憶されたデータの完全性を検証すること
WO2020138606A1 (ko) * 2018-12-28 2020-07-02 연세대학교 산학협력단 블록체인 네트워크의 합의 방해요인 제거를 위한 장애 허용 합의 방법
CN111630542A (zh) * 2017-12-08 2020-09-04 科雷莱杰公司 执行交易的方法
JP2020145681A (ja) * 2018-12-21 2020-09-10 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ パブリックサイドチェーンを使用してコンソーシアムブロックチェーンに記憶されたデータの完全性を検証すること
JP2021509780A (ja) * 2017-11-15 2021-04-01 オッポ広東移動通信有限公司Ｇｕａｎｇｄｏｎｇ Ｏｐｐｏ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．， Ｌｔｄ． 非競合ランダムアクセスリソースの決定方法、ネットワークデバイス及び端末デバイス
JP2021515952A (ja) * 2018-04-27 2021-06-24 ▲騰▼▲訊▼科技（深▲セン▼）有限公司 信用調査システム、信用調査データの記憶方法、装置及びコンピュータプログラム

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US9967096B2 (en) 2016-05-23 2018-05-08 Accenture Global Solutions Limited Rewritable blockchain
US11481360B2 (en) * 2017-04-07 2022-10-25 Hwa-Shang CHANG Blockchain network and method of operation thereof
US10560270B2 (en) 2017-05-03 2020-02-11 International Business Machines Corporation Optimal data storage configuration in a blockchain
US10749670B2 (en) * 2017-05-18 2020-08-18 Bank Of America Corporation Block chain decoding with fair delay for distributed network devices
US10868673B2 (en) * 2017-09-25 2020-12-15 Sap Se Network access control based on distributed ledger
WO2019081086A1 (de) * 2017-10-23 2019-05-02 Siemens Aktiengesellschaft Verfahren und steuersystem zum steuern und/oder überwachen von geräten
US10701053B2 (en) * 2018-02-28 2020-06-30 Bank Of America Corporation Authentication and approval control system for distributed ledger platform
US11336430B2 (en) 2018-09-07 2022-05-17 Sap Se Blockchain-incorporating distributed authentication system
US10938573B2 (en) * 2018-11-06 2021-03-02 Accenture Global Solutions Limited Distributed transaction processing
US11012506B2 (en) * 2019-03-15 2021-05-18 Microsoft Technology Licensing, Llc Node and cluster management on distributed self-governed ecosystem
US11159308B2 (en) * 2019-03-20 2021-10-26 PolySign, Inc. Preventing an erroneous transmission of a copy of a record of data to a distributed ledger system
JP6650157B1 (ja) * 2019-05-08 2020-02-19 株式会社モールサービス 情報管理システム、情報管理方法及び情報管理プログラム
CN111275395A (zh) * 2020-01-19 2020-06-12 重庆科技学院 一种基于区块链的去中心化的企业绩效考核方法
US11915014B2 (en) * 2021-08-18 2024-02-27 Microsoft Technology Licensing Consensus based determination of stable configuration

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150332283A1 (en) * 2014-05-13 2015-11-19 Nant Holdings Ip, Llc Healthcare transaction validation via blockchain proof-of-work, systems and methods
JP5858506B1 (ja) * 2015-04-09 2016-02-10 株式会社Ｏｒｂ 仮想通貨管理プログラム、及び仮想通貨管理方法

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050144516A1 (en) * 2003-12-30 2005-06-30 Gonzalez Carlos J. Adaptive deterministic grouping of blocks into multi-block units
KR100612255B1 (ko) * 2005-01-11 2006-08-14 삼성전자주식회사 무선 네트워크 시스템에서의 데이터 보안장치 및 그 방법
US20080065835A1 (en) * 2006-09-11 2008-03-13 Sun Microsystems, Inc. Offloading operations for maintaining data coherence across a plurality of nodes
US20100111298A1 (en) * 2008-10-27 2010-05-06 Advanced Micro Devices, Inc. Block cipher decryption apparatus and method
US20180315046A1 (en) * 2013-06-17 2018-11-01 Raymond Anthony Joao Apparatus and method for providing transaction security and/or account security
US9553982B2 (en) * 2013-07-06 2017-01-24 Newvoicemedia, Ltd. System and methods for tamper proof interaction recording and timestamping
US11055707B2 (en) * 2014-06-24 2021-07-06 Visa International Service Association Cryptocurrency infrastructure system
CN104935657A (zh) * 2015-06-15 2015-09-23 清华大学深圳研究生院 主动推送信息的方法和嵌入式节点操作系统
US10402792B2 (en) * 2015-08-13 2019-09-03 The Toronto-Dominion Bank Systems and method for tracking enterprise events using hybrid public-private blockchain ledgers
WO2017066002A1 (en) * 2015-10-17 2017-04-20 Banqu, Inc. Blockchain-based identity and transaction platform
US20170116693A1 (en) * 2015-10-27 2017-04-27 Verimatrix, Inc. Systems and Methods for Decentralizing Commerce and Rights Management for Digital Assets Using a Blockchain Rights Ledger
US20170132625A1 (en) * 2015-11-05 2017-05-11 Mastercard International Incorporated Method and system for use of a blockchain in a transaction processing network
US20170132620A1 (en) * 2015-11-06 2017-05-11 SWFL, Inc., d/b/a "Filament" Systems and methods for autonomous device transacting
US20170213221A1 (en) * 2016-01-26 2017-07-27 Bank Of America Corporation System for tracking and validation of multiple instances of an entity in a process data network
US10447478B2 (en) * 2016-06-06 2019-10-15 Microsoft Technology Licensing, Llc Cryptographic applications for a blockchain system
US11146535B2 (en) * 2016-10-12 2021-10-12 Bank Of America Corporation System for managing a virtual private ledger and distributing workflow of authenticated transactions within a blockchain distributed network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150332283A1 (en) * 2014-05-13 2015-11-19 Nant Holdings Ip, Llc Healthcare transaction validation via blockchain proof-of-work, systems and methods
JP5858506B1 (ja) * 2015-04-09 2016-02-10 株式会社Ｏｒｂ 仮想通貨管理プログラム、及び仮想通貨管理方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
AKIHITO AKUTSU ET AL.: "User o Kando saseru Epoch Making na Service Soshutsu eno Chosen Kyogi no Kando o Sekaiju de Kyoyu dekiru Service ni", NTT GIJUTSU JOURNAL, vol. 27, no. 5, 1 May 2015 (2015-05-01), pages 10 - 14, XP009508781 *
See also references of EP3439231A4 *

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021509780A (ja) * 2017-11-15 2021-04-01 オッポ広東移動通信有限公司Ｇｕａｎｇｄｏｎｇ Ｏｐｐｏ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．， Ｌｔｄ． 非競合ランダムアクセスリソースの決定方法、ネットワークデバイス及び端末デバイス
JP7287279B2 (ja) 2017-12-04 2023-06-06 ソニーグループ株式会社 情報処理装置、情報処理方法およびプログラム
WO2019111506A1 (ja) * 2017-12-04 2019-06-13 ソニー株式会社 情報処理装置、情報処理方法およびプログラム
US11388230B2 (en) 2017-12-04 2022-07-12 Sony Corporation Information processing apparatus, information processing method, and program
JPWO2019111506A1 (ja) * 2017-12-04 2020-11-26 ソニー株式会社 情報処理装置、情報処理方法およびプログラム
CN111630542A (zh) * 2017-12-08 2020-09-04 科雷莱杰公司 执行交易的方法
JP6487091B1 (ja) * 2018-03-29 2019-03-20 株式会社電通 Ｉｃｏ管理方法、通信デバイス、ｉｃｏ管理システム及びプログラム
JP2019175249A (ja) * 2018-03-29 2019-10-10 株式会社電通 Ｉｃｏ管理方法、通信デバイス、ｉｃｏ管理システム及びプログラム
WO2019193820A1 (ja) * 2018-04-02 2019-10-10 ソニー株式会社 情報処理装置、情報処理方法、およびプログラム
JP2021515952A (ja) * 2018-04-27 2021-06-24 ▲騰▼▲訊▼科技（深▲セン▼）有限公司 信用調査システム、信用調査データの記憶方法、装置及びコンピュータプログラム
JP7011083B2 (ja) 2018-04-27 2022-01-26 ▲騰▼▲訊▼科技（深▲セン▼）有限公司 信用調査システム、信用調査データの記憶方法、装置及びコンピュータプログラム
US11244393B2 (en) 2018-04-27 2022-02-08 Tencent Technology (Shenzhen) Company Limited Credit blockchain system, credit data storage method, device, and medium
CN109040014A (zh) * 2018-06-13 2018-12-18 湖南搜云网络科技股份有限公司 区块链处理方法及装置、区块链节点及存储介质
KR102107237B1 (ko) 2018-07-02 2020-06-03 김도영 블록체인 및 분산 인프라 P2P 모델 기반 PoR 증명을 이용한 인터넷 서비스 제공 방법
KR20200003625A (ko) * 2018-07-02 2020-01-10 김도영 블록체인 및 분산 인프라 P2P 모델 기반 PoR 증명을 이용한 인터넷 서비스 제공 방법
CN109377364A (zh) * 2018-09-27 2019-02-22 中国联合网络通信集团有限公司 一种建组方法和装置、交易方法和系统
US10691835B1 (en) 2018-12-21 2020-06-23 Alibaba Group Holding Limited Verifying integrity of data stored in a consortium blockchain using a public sidechain
JP2020145681A (ja) * 2018-12-21 2020-09-10 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ パブリックサイドチェーンを使用してコンソーシアムブロックチェーンに記憶されたデータの完全性を検証すること
JP2020511809A (ja) * 2018-12-21 2020-04-16 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ パブリックサイドチェーンを使用してコンソーシアムブロックチェーンに記憶されたデータの完全性を検証すること
WO2020138606A1 (ko) * 2018-12-28 2020-07-02 연세대학교 산학협력단 블록체인 네트워크의 합의 방해요인 제거를 위한 장애 허용 합의 방법

Also Published As

Publication number Publication date
EP3439231A4 (en) 2019-11-13
CN109219940B (zh) 2022-01-11
EP3439231A1 (en) 2019-02-06
US20190036702A1 (en) 2019-01-31
CN109219940A (zh) 2019-01-15

Similar Documents

Publication Publication Date Title
JP6199518B1 (ja) プライベートノード、プライベートノードにおける処理方法、及びそのためのプログラム
WO2017170679A1 (ja) プライベートノード、プライベートノードにおける処理方法、及びそのためのプログラム
JP6389350B2 (ja) トランザクション処理装置、トランザクション処理方法、及びそのためのプログラム
JP6370016B2 (ja) 階層型ネットワークシステム、これに用いられるノード及びプログラム
JP2017200196A (ja) プライベートノード、プライベートノードにおける処理方法、及びそのためのプログラム
Sarmah Understanding blockchain technology
US20230070963A1 (en) Blockchain-implemented method for control and distribution of digital content
US20160162897A1 (en) System and method for user authentication using crypto-currency transactions as access tokens
JP2020068388A (ja) コンテンツ契約システム、コンテンツ契約方法、権利者端末、譲受人端末、制御端末、コンテンツ蓄積サーバ、権利者プログラム、譲受人プログラム、制御プログラムおよびコンテンツ蓄積プログラム
WO2021197092A1 (zh) 区块链账户余额的存证、恢复
JP6296630B1 (ja) 分散型台帳システムおよびプログラム
KR102627868B1 (ko) 블록체인에서 생성된 데이터를 인증하는 방법 및 시스템
US20220067125A1 (en) Method for distributing certificate of right to use digital content, and computer program stored in medium in order to carry out method
CN115136543A (zh) 在区块链网络中使用的认证服务
Elagin et al. Development and analysis of a blockchain system based on JavaScript
CN114631110A (zh) 使用区块链交易分配数字资产
CN118118178A (zh) 基于区块链的数字资源处理方法、装置和计算机设备
TW202207134A (zh) 密碼貨幣交易系統

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2017775213

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2017775213

Country of ref document: EP

Effective date: 20181031

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17775213

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP