WO2021064852A1 - トランザクション管理装置、トランザクション管理プログラム、及びトランザクション管理方法 - Google Patents

トランザクション管理装置、トランザクション管理プログラム、及びトランザクション管理方法 Download PDF

Info

Publication number
WO2021064852A1
WO2021064852A1 PCT/JP2019/038699 JP2019038699W WO2021064852A1 WO 2021064852 A1 WO2021064852 A1 WO 2021064852A1 JP 2019038699 W JP2019038699 W JP 2019038699W WO 2021064852 A1 WO2021064852 A1 WO 2021064852A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
blockchain
transaction
data
unit
Prior art date
Application number
PCT/JP2019/038699
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 JP2021550803A priority Critical patent/JPWO2021064852A1/ja
Priority to CN201980100757.9A priority patent/CN114450686A/zh
Priority to EP19947813.2A priority patent/EP4040323A4/en
Priority to PCT/JP2019/038699 priority patent/WO2021064852A1/ja
Publication of WO2021064852A1 publication Critical patent/WO2021064852A1/ja
Priority to US17/704,215 priority patent/US20220215386A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • 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
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • 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/3297—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 involving time stamps, e.g. generation of time stamps
    • 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

Definitions

  • the present invention relates to a transaction management device, a transaction management program, and a transaction management method.
  • One of the methods to eliminate the bloated data volume is, for example, a method of periodically transferring blockchain data to another system and restarting the transfer source blockchain each time it is transferred. Can be mentioned.
  • the transfer destination system is provided with a blockchain for registering the hash value of each transaction data and a database (DB; Database) for registering each transaction data.
  • DB database
  • the reference data is, for example, transaction data obtained by referencing (searching) a database. If the hash value obtained by performing a hash operation on the reference data matches the hash value registered on the blockchain, it can be determined that the data on the database has not been tampered with, and if they do not match. In addition, it can be determined that the data on the database has been tampered with.
  • one of the purposes of the present invention is to streamline tampering verification of transferred transactions.
  • the transaction management device may include a first registration unit and a second registration unit.
  • the first registration unit is a group based on the first information, regarding a first blockchain that stores a plurality of transactions to which the first information and the second information are associated, a plurality of the second information in the plurality of the transactions. It may be registered in the database in units.
  • the second registration unit may register the hash value obtained by hashing the plurality of second information in the group unit in the second blockchain.
  • FIG. 1 is a diagram showing an example of a blockchain system 100.
  • the data of the transfer source blockchain 111 in the transfer source system 110 is periodically (for example, once a year) collectively transferred to the transfer destination system 120 (see reference numeral (i)), and the transfer source blockchain 111 is re-transferred.
  • Start see code (ii)
  • the transfer source blockchain 111 and the transfer source blockchain 112 are referred to after the restart for convenience in order to distinguish before and after the restart (before and after the transfer). write.
  • the data to be transferred is one or more blocks in the source blockchain 111, and the transferred data is not transferred to the source blockchain 112 until the next restart of the source blockchain 112. It is stored (held) as a block.
  • the transfer source blockchain 112 is used for operations such as new data registration to the transfer source system 110 and untransferred data reference.
  • the transfer destination system 120 is used to refer to the transferred data, in other words, the archive data.
  • the transfer source blockchain 111 before restart may be referred to as “old blockchain 111”
  • the transfer source blockchain 112 used for operation after restart may be referred to as “operation blockchain 112”.
  • FIG. 2 is a diagram showing an example of the relocation destination system 120.
  • the relocation destination system 120 includes a blockchain 121 and a database (DB) 122.
  • the hash value of each transaction data is registered in the blockchain 121, and the data itself is registered in the DB 122 in a form in which the hash value registered in the blockchain 121 can be referred to.
  • the transaction ID when the hash value is registered in the blockchain 121 is added to each transaction data and registered in the DB 122.
  • the transaction ID is an example of identification information that uniquely identifies transaction data.
  • the block chain 121 includes one or more blocks connected in a chain shape such as blocks 121a, 121b, 121c, ....
  • One or more hash values of transaction data are registered in each of the blocks 121a, 121b, and 121c.
  • Tx1 and Tx2 are transaction IDs (hereinafter, may be referred to as "TxID").
  • Each hash value is a hash value obtained by hashing the data (data1) updated by the transaction of Tx1 and a hash value obtained by hashing the data (data2) updated by the transaction of Tx2. means.
  • FIG. 3 is a diagram showing an operation example of searching the update history of data A as reference data from the transfer destination system 120.
  • the user acquires the update history (A0, A1, A2) of the data A and these TxIDs (Tx1, Tx2, Tx3) from the DB 122 (see reference numeral (i)).
  • the TxID and the update history are shown as Tx1 / A0, Tx2 / A1, and Tx3 / A2.
  • the user acquires the hash value of the transaction data from the transfer destination blockchain 121 using each TxID acquired from the DB 122 as a key (see the code (ii)). Then, the user verifies the data tampering on the DB 122 by comparing each data (update history) acquired from the DB 122 with each hash value acquired from the blockchain 121 one by one (see code (iii)). ). As a result, by comparing the data registered in the DB 122 with the hash value registered in the blockchain 121, which is difficult to tamper with, the tampering verification of the data registered in the DB 122, which may be tampered with, is performed. Can be done.
  • FIG. 4 is a diagram showing an operation example when data is transferred from the old blockchain 111 to the transfer destination blockchain 121.
  • the data is hashed for each transaction in the old blockchain 111 and registered in the transfer destination blockchain 121.
  • Tx1 / A0 to Tx5 / A4 are hashed to Tx1'/ Hash (A0) to Tx5' / Hash (A4), respectively.
  • the user is aware (determines) which of the transfer source (operation) blockchain 112, the DB 122, and the transfer destination blockchain 121 refers to the transaction data. ) Will be done. However, it is difficult for the user to determine whether the data to be referred to exists in the transfer source system 110 or the transfer destination system 120.
  • FIG. 5 is a block diagram showing a functional configuration example of the blockchain system 1 as an example of the embodiment.
  • the blockchain system 1 has, as an example, a transfer source blockchain 2, a transfer destination blockchain 3, a transfer destination DB 4, a data transfer unit 5, a data registration unit 6, and data as functional configurations.
  • a reference unit 7 may be provided.
  • the blockchain is referred to as “Chain”, the block is referred to as “Blc”, and the transaction is referred to as “Trans”.
  • the transfer source blockchain 2 is an example of a first blockchain that stores a plurality of transactions associated with a key and a value.
  • the "key” may be a transaction processing target and is an example of the first information.
  • the "value” may be a key value (for example, an updated value) updated by transaction processing, and is an example of the second information.
  • the transaction is a transaction record, and the transaction data stored in the transfer source blockchain 2 can be rephrased as the key update history.
  • the transaction may not include the key and the value itself, and the value may be calculated from the record of one or more transactions for the same key.
  • the data of the transfer source blockchain 2 is transferred to the transfer destination blockchain 3 and the transfer destination DB4, and the data is transferred. It is assumed that the original blockchain 2 is initialized. A part of the transferred data and information about the transfer destination are registered in advance in the transfer source blockchain 2 after the initialization, and then the operation is restarted.
  • the transfer source blockchain 2 after initialization is an example of a third blockchain.
  • the transfer source blockchain 2 includes a blockchain control unit 21 and a ledger 22 as illustrated in FIG.
  • the blockchain control unit 21 controls processing such as transaction registration and reference to the ledger 22.
  • the blockchain control unit 21 may include a transmission / reception unit 21a.
  • the transmission / reception unit 21a updates and references (acquires) the ledger 22, transmits / receives data to / from the data transfer unit 5, the data registration unit 6, and the data reference unit 7.
  • the ledger 22 includes a blockchain that connects and stores one or more blocks.
  • the block may contain one or more transactions.
  • the ledger 22 may include a key-value format DB that stores a value (value) in association with a unique key.
  • the transaction execution history may be written to the blockchain by the transmission / reception unit 21a, and the latest state of the transaction execution result may be written to the DB.
  • the transaction may include a time stamp. Timestamps can be obtained and added by known methods.
  • the transaction stored in the ledger 22 may be one or both of a hash value and a non-hash value. When the hash value of the transaction is stored in the blockchain, the ledger 22 may further store, for example, the record of the transaction having a non-hash value.
  • the transfer destination blockchain 3 is one of the transfer destinations of transaction data from the transfer source blockchain 2, and is an example of the second blockchain. As illustrated in FIG. 5, the relocation destination blockchain 3 includes a blockchain control unit 31 and a ledger 32.
  • the blockchain control unit 31 controls processing such as transaction registration and reference to the ledger 32.
  • the blockchain control unit 31 may include a transmission / reception unit 31a.
  • the transmission / reception unit 31a updates and refers (acquires) the ledger 32, transmits / receives data to / from the data transfer unit 5 and the data reference unit 7.
  • the ledger 32 includes a blockchain that connects and stores one or more blocks.
  • the block may contain one or more transactions.
  • the ledger 32 may include a key-value format DB that stores a value (value) in association with a unique key.
  • the transaction execution history may be written to the blockchain by the transmission / reception unit 31a, and the latest state of the transaction execution result may be written to the DB.
  • the transaction may include a time stamp. Timestamps can be obtained and added by known methods.
  • the transaction stored in the ledger 32 may be a hash value.
  • the transfer destination DB4 is one of the transfer destinations of transaction data from the transfer source blockchain 2, and is an example of a database.
  • the relocation destination DB 4 may include a DB control unit 41 and a DB 42 as illustrated in FIG.
  • the DB control unit 41 controls processing such as data registration and reference to the DB 42.
  • the DB control unit 41 may include a data transmission / reception unit 41a.
  • the data transmission / reception unit 41a updates and references (acquires) the DB 42, transmits / receives data to / from the data transfer unit 5 and the data reference unit 7.
  • the DB 42 stores the update history of the key of the transfer source blockchain 2 and the transaction ID (TxID) registered in the transfer destination blockchain 3. For example, in the DB 42, the key update history and the TxID may be written by the data transmission / reception unit 41a.
  • the reason why the transfer destination DB4 is used without registering the data in the transfer destination blockchain 3 as it is is to reduce the amount of data.
  • the data transfer unit 5, the data registration unit 6, and the data reference unit 7 are executed as, for example, processes (data transfer process, data registration process, and data reference process) that are processing units by a computer processor, respectively. Good.
  • the processes of the data transfer unit 5, the data registration unit 6, and the data reference unit 7 may be executed by different computers, or two or more processes may be executed by a common computer.
  • the computer may be referred to as an information processing device or a transaction management device.
  • the transfer source blockchain 2 manages the wallet balance (value) of each customer for each key. Further, in the transfer destination blockchain 3, it is assumed that reading and writing of data transfer information to the blockchain is defined by a smart contract or the like, and when referring to the data of the transfer source and the transfer destination, the date and time range can be specified and referred to. To do. Furthermore, while the data is being transferred, the transfer source blockchain 2 will not accept registration or reference of new data.
  • the data transfer unit 5 collects the transaction data of the transfer source blockchain 2 for each data having the same key updated in the transaction, and transfers the transaction data to the transfer destination blockchain 3 and the transfer destination DB4.
  • the data transfer unit 5 may include a blockchain communication unit 51, a block data processing unit 52, and a DB communication unit 53.
  • the blockchain communication unit 51 communicates data between the transfer source blockchain 2 and the transfer destination blockchain 3, and includes a block acquisition unit 51a and a transaction transmission / reception unit 51b.
  • the block data processing unit 52 generates transaction data and hash values for data transfer based on the data received from the blockchain communication unit 51, and includes a data summarizing unit 52a and a data compression unit 52b.
  • the DB communication unit 53 communicates data with the transfer destination DB 4, and includes a data transmission / reception unit 53a.
  • the data transfer unit 5 may execute the following processes (i) to (iv) (corresponding to the symbols (i) to (iv) in FIG. 5) as an example.
  • the block acquisition unit 51a collectively acquires the block information of the transfer source blockchain 2, in other words, the transaction data, from the transmission / reception unit 21a of the transfer source blockchain 2.
  • the block acquisition unit 51a transmits (outputs) the acquired block information to the data summarization unit 52a.
  • the block acquisition unit 51a for example, from the transfer source blockchain 2 to the first (oldest) block to the last (latest) block in ascending order in chronological order, in other words, of a plurality of transactions. Transaction data may be acquired in each registration order.
  • the data summarizing unit 52a divides all the transaction data acquired in (i) above into group units based on the key and sums them up as an update history group.
  • the group may be, for example, a group in which data (values) associated with the same key are grouped according to a predetermined condition.
  • the number of values to be included in the group is set for each predetermined number, for each number for which the total data size of the values to be included in the group is equal to or less than the predetermined data size, and for each number included in the predetermined number of blocks. It may include at least one.
  • the predetermined number of cases, the predetermined data size, and the predetermined number (of the block) can be set in advance.
  • FIG. 6 is a diagram showing an example in which data having the same key for the keys A, B, and C of the transfer source blockchain 2 are collected as an update history group for every three update histories.
  • FIG. 6 shows a case where the predetermined condition sets the number of values to be included in the group to “for each predetermined number” and the predetermined number is set to “3”.
  • the blockchain 20 is a blockchain in the ledger 22, and at least blocks 20a to 20c (blocks 1 to 3) are registered.
  • the value of key C (balance of customer C) is updated to “40”, and the value of key A (balance of customer A) is updated to “200”.
  • the data summarizing unit 52a summarizes each value (balance) in transactions Tx1 to Tx5 as an update history group 50a to 50d for every three cases according to the update history of each key (customer).
  • the update history groups 50a and 50b indicate that the balance update history of customer A is in the order of 100 yen, 200 yen, 300 yen, 400 yen, and 500 yen (the last is the latest value).
  • the update order of the balance is appropriately reflected in the update history groups 50a and 50b.
  • the update history groups 50a to 50d may be managed in a storage area 50 such as a memory of a computer that executes a data transfer process, for example.
  • the data transfer unit 5 adds access information for accessing each transfer destination DB 42 (or transfer destination DB 4) to the hash values of the update history groups 50a to 50d, and the transfer destination blockchain 3 Register with.
  • Examples of the access information include URI (Uniform Resource Identifier) such as URL (Uniform Resource Locator) and IP (Internet Protocol) address of the transfer destination DB 42 or the transfer destination DB 4.
  • the data compression unit 52b calculates a hash value by performing a hash operation on each of the update history groups 50a to 50d collected by the data collection unit 52a.
  • the calculation of the hash value may be realized by a known method.
  • one block may be assigned to the transfer destination blockchain 3 for each hash value, and each block may be concatenated in the order of update history groups 50a to 50d.
  • the block data processing unit 52 transmits (outputs) to the transaction transmission / reception unit 51b a transfer transaction in which access information is added to the hash value calculated by the data compression unit 52b.
  • the transaction transmission / reception unit 51b When the transaction transmission / reception unit 51b receives (receives) the transfer transaction from the block data processing unit 52, the transaction transmission / reception unit 51b transmits the transfer transaction to the transmission / reception unit 31a of the transfer destination blockchain 3 together with the registration instruction in the ledger 32. Further, the transaction transmission / reception unit 51b receives the TxID (transfer TxID) when the transfer transaction is registered in the ledger 32 from the transmission / reception unit 31a and transmits it to the DB communication unit 53.
  • TxID transfer TxID
  • FIG. 7 is a diagram showing an example of data registered in the blockchain 30 and DB 42 of the transfer destination.
  • the relocation destination blockchain 30 is a blockchain in the ledger 32 of the relocation destination blockchain 3.
  • the block data processing unit 52 adds access information (DB1) to a hash value (Hash ( ⁇ A: [100,200,300] ⁇ )) obtained by hashing the update history group 50a. Is added.
  • the transaction transmission / reception unit 51b registers the transfer transaction in the block 30a of the blockchain 30 through the transmission / reception unit 31a. Since this transfer transaction is a transaction of transfer TxID: Tx1 in the blockchain 30, the transaction transmission / reception unit 51b notifies the data transmission / reception unit 53a of the transfer TxID: Tx1.
  • the block data processing unit 52 adds access information (DB1) to the hash value (Hash ( ⁇ A: [400,500] ⁇ )) obtained by hashing the update history group 50b.
  • the transaction transmission / reception unit 51b registers the transfer transaction in the block 30b connected to the block 30a through the transmission / reception unit 31a. Since this transfer transaction is a transaction of transfer TxID: Tx2 in the blockchain 30, the transaction transmission / reception unit 51b notifies the data transmission / reception unit 53a of the transfer TxID: Tx2.
  • hash values collected in group units are registered in blocks (blocks 30a to 30d in the example of FIG. 7). Therefore, for example, when the value of the key B is referred to, the update history of the same key B can be collectively verified by acquiring the transaction data of the block 30c, and the processing efficiency can be improved as compared with the example of FIG. ..
  • the blockchain communication unit 51 and the block data processing unit 52 are the second registration units that register the hash values obtained by hashing a plurality of values in group units based on the key in the transfer destination blockchain 3. This is an example.
  • the data transfer unit 5 provides TxID when each hash value is registered in the blockchain 30 in each update history group 50a to 50d, and access information for accessing the transfer destination blockchain 3 or the blockchain 30. Is added and registered in the transfer destination DB4. Examples of the access information include URIs such as URLs and IP addresses of the relocation destination blockchain 3 or blockchain 30.
  • the block data processing unit 52 transmits the key A of the update history group 50a and the value [100, 200, 300] of the update history group 50a, in other words, transaction data to the data transmission / reception unit 53a.
  • the data transmission / reception unit 53a transmits the transaction data received from the block data processing unit 52 and the transfer TxID received from the transaction transmission / reception unit 51b to the data transmission / reception unit 41a of the transfer destination DB4 together with the registration instruction to the DB 42. ..
  • the data transmission / reception unit 53a registers the key A of the update history group 50a in the key 42a of the DB 42 through the data transmission / reception unit 41a, and the value of the update history group 50a [100, 200, 300] is registered in the update history 42c of the DB 42. Further, the data transmission / reception unit 53a registers the TxID (Tx1) when the hash value of the update history group 50a is registered in the block 30a through the data transmission / reception unit 41a in the transfer TxID42d of the DB 42. Further, the data transmission / reception unit 53a registers the access information (Chain1) of the blockchain 30 in the reference destination URL 42e of the DB 42 through the data transmission / reception unit 41a.
  • the transfer TxID42d is information that can identify the registered position of the hash value in the blockchain 30, and is an example of the registered position information of the hash value.
  • the update history corresponding to TxID may be registered in the transfer TxID42d.
  • the data transmission / reception unit 53a adds the update history group to the update history 42c of the entry through the data transmission / reception unit 41a.
  • the value [400,500] of 50b is registered (added).
  • the data transmission / reception unit 53a registers the hash value of the update history group 50b in the block 30b in the transfer TxID42d of the entry matching the key A of the update history group 50b through the data transmission / reception unit 41a. Register (add) the TxID (Tx2) at the time.
  • the data transmission / reception unit 53a sets the latest value (for example, “500” in the case of key A) of the update history 42c for each key 42a through the transmission / reception unit 31a. It may be registered in the latest value 42b of the entry of.
  • the block data processing unit 52 and the DB communication unit 53 are the first registration units that register a plurality of values in a plurality of transactions in the transfer destination DB 4 in group units based on the key for the transfer source blockchain 2. This is an example.
  • the data transfer unit 5 executes the transaction data transfer process from the transfer source blockchain 2 to the transfer destination blockchain 3 and the transfer destination DB4.
  • the above-mentioned transfer process may be executed by, for example, when the processor receives a transfer process execution request from the user, the data transfer process is started, and the started data transfer process (data transfer unit 5).
  • the processor may initiate the data registration process.
  • the activated data registration process may initialize the transfer source blockchain 2 and take over the information of the update history groups 50a to 50d held by the storage area 50 by the data transfer process.
  • the data registration unit 6 may include a request transmission unit 61 as illustrated in FIG.
  • the request transmission unit 61 transmits a request such as a registration request for the update value of each key to the transfer source blockchain 2.
  • a request such as a registration request for the update value of each key
  • the request transmission unit 61 may generate and transmit a registration request when receiving a key update value from a user (client).
  • the data registration unit 6 may execute the following processing (v) (corresponding to the reference numeral (v) in FIG. 5) as an example.
  • the request transmission unit 61 registers the latest values of the update history groups 50a to 50d in the transfer source blockchain 2.
  • the request transmission unit 61 waits until the data is registered in the blockchain 30 and the DB 42 in the transfer process of the data transfer unit 5) and the initialization of the transfer source blockchain 2 is completed.
  • the request transmission unit 61 acquires the latest values of the update history groups 50a to 50d registered in the DB 42 from the data summarization unit 52a.
  • the data summarizing unit 52a may acquire the latest values from the update history groups 50a to 50d stored in the storage area 50, or each key 42a in the transfer destination DB 42 via the DB communication unit 53.
  • the latest value 42b (see FIG. 7) may be obtained.
  • the request transmission unit 61 transfers a transaction in which the latest value of each update history group 50a to 50d and a flag in which the update history of the key of each update history group 50a to 50d exists in the transfer destination DB4 are associated with each other.
  • the flag is an example of the third information indicating that a value older than the latest value among one or more values (update history) exists in the transfer destination DB4.
  • FIG. 8 is a diagram showing an example of data registered in the transfer source blockchain 2 after initialization.
  • the blocks 20a to 20c (see FIG. 6) before the initialization are deleted by the initialization.
  • the latest values (500, 3, 90) of the keys (keys A, B, C) of the update history groups 50b to 50d are registered in blocks 20a to 20c, respectively. Further, in each of the blocks 20a to 20c, a true indicating that the archive flag is ON is registered in the key Archive. As shown in FIG. 8, a time stamp may be registered in each block 20a to 20c (each transaction Tx1 to Tx3).
  • the request transmission unit 61 is an example of the third registration unit that registers the transaction in which the first information, the second information, and the third information are associated with the third blockchain.
  • the transfer source blockchain 2 By referring to the transfer source blockchain 2 by the flag, it is possible to easily detect (determine) that an update value older than the latest update value exists in the transfer destination DB4.
  • the request transmission unit 61 is an example of a fourth registration unit that registers a transaction related to a registration request following a transaction including a flag in response to a new transaction registration request after registration of a transaction including a flag. ..
  • the request transmission unit 61 is an example of a fourth registration unit that registers a transaction related to a registration request following a transaction including a flag in response to a new transaction registration request after registration of a transaction including a flag. ..
  • the case where the database resulting from the initialization of the transfer source blockchain 2 after the data transfer of the transfer source blockchain 2 is used (reused) as a new transfer source blockchain 2 is taken as an example.
  • the "new transfer source blockchain” another blockchain different from the transfer source blockchain 2 may be used.
  • the transfer source blockchain 2 as a new transfer source blockchain, or another blockchain different from the transfer source blockchain 2, is an example of the third blockchain.
  • the data reference process can be operated if the data transfer process and the data registration process are not operating and the transfer source blockchain 2, the transfer destination blockchain 3, and the transfer destination DB4 are activated.
  • the data reference process specifies the date and time range and acquires the update history group corresponding to the key in response to the data reference request from the user (client).
  • the user can refer to the update history group from one or both of the transfer source blockchain 2, the transfer destination blockchain 3, and the transfer destination DB4 without being aware of the data storage destination.
  • the data reference unit 7 performs falsification verification processing on the data received from the reference destination in response to the data reference request.
  • the data reference unit 7 may include a request destination control unit 71, a request transmission unit 72, and a falsification verification unit 73.
  • the request destination control unit 71 controls the request destination when referencing data.
  • the request transmission unit 72 makes a data reference request to one or both of the transfer source blockchain 2, the transfer destination blockchain 3, and the transfer destination DB 4 in response to the control by the request destination control unit 71. Send.
  • FIG. 9 is a diagram showing an example of the relationship between the date and time range of the data to be acquired and the acquisition destination.
  • the acquisition target data is, for example, data that matches the data reference conditions requested by the user (for example, the acquisition target key, the date and time range, etc.).
  • the request destination control unit 71 specifies the update history group for the key to be acquired in the date and time range, and refers to the oldest update history data of the key to be acquired from the transfer source blockchain 2 through the request transmission unit 72. ..
  • the request destination control unit 71 refers to the data of the block 20a.
  • the date and time (oldest transaction date and time) of the acquired (referenced) data shall be obtained from the time stamp registered in the block 20a.
  • the request destination control unit 71 sets the transfer source blockchain 2 as the reference destination of the update history data. decide.
  • the request destination control unit 71 When the oldest date and time in the date and time range of the acquisition target is newer than the oldest date and time of the transfer source blockchain 2, the request destination control unit 71 "from the oldest date and time of the acquisition target to the latest date and time of the acquisition target". It is determined that the data in the range of (I) is referenced from the reference destination (corresponding to the example of (I) in FIG. 9).
  • the request destination control unit 71 "acquires from the oldest date and time of the transfer source blockchain 2". It is determined that the data in the first range of "the latest date and time of the target" is referenced from the reference destination.
  • the data in the first range corresponds to the data in the range (III-1) in the example of (III) in FIG.
  • the request destination control unit 71 may use the transfer destination blockchain. 3 and the transfer destination DB4 are determined as the reference destination of the update history data.
  • the request destination control unit 71 refers to the data in the range of "the oldest date and time of the acquisition target to the latest date and time of the acquisition target" as the reference destination (transfer destination). It is decided to refer to from (corresponding to the example of (II) in Fig. 9).
  • the request destination control unit 71 "from the oldest date and time of the acquisition target to the oldest date and time of the transfer source blockchain 2". It is determined that the data in the second range of is referenced from the reference destination (transfer destination).
  • the data in the second range corresponds to the data in the range (III-2) in the example of (III) in FIG.
  • the request destination control unit 71 and the request transmission unit 72 are examples of the reference unit.
  • the reference unit refers to transaction data from the transfer source blockchain 2 based on the keys included in the plurality of transactions registered by the request transmission unit 61. Then, when the data reference is requested for the data past the referenced data, the reference unit refers to the past data from the transfer destination DB 4 based on the flag associated with the transaction of the referenced data. As a result, past transaction data can be referred to from the transfer destination blockchain 3 and the transfer destination DB4.
  • the falsification verification unit 73 verifies the falsification of the data acquired (referenced) in response to the reference request transmitted by the request transmission unit 72.
  • the falsification verification unit 73 uses one or more TxIDs associated with the update history data acquired in the example of (II) or (III-2) of FIG. 9 to block the transfer destination via the request transmission unit 72.
  • the hash value is acquired by referring to the update history data of the chain 3.
  • the falsification verification unit 73 calculates the hash value of the update history data, compares the calculated hash value with the hash value acquired from the transfer destination blockchain 3, and acquires it from the transfer destination DB 4 based on the comparison result. Verify the tampering with the data. For example, the tampering verification unit 73 determines that the data acquired from the transfer destination DB4 has not been tampered with if the comparison results match, and if the comparison results do not match, the data acquired from the transfer destination DB4 has been tampered with. It may be determined that it is.
  • the falsification verification unit 73 is an example of the first acquisition unit that acquires one or more data to which a predetermined TxID is added from the transfer destination DB4. Further, the falsification verification unit 73 is an example of a second acquisition unit that acquires a hash value corresponding to a predetermined TxID from the transfer destination blockchain 3. Further, the falsification verification unit 73 has one or more acquired from the transfer destination DB4 based on the hash value obtained by hashing one or more data acquired as the first acquisition unit and the hash value acquired as the second acquisition unit. This is an example of a verification unit that verifies falsification of the data in. In this way, according to the falsification verification unit 73, it is possible to improve the efficiency of falsification verification of the transferred transaction.
  • the block acquisition unit 51a collectively acquires the transaction data of the transfer source blockchain 2 in ascending order from the first block (step S1). ..
  • the data summarizing unit 52a collects all the transaction data acquired by the block acquisition unit 51a for each data having the same key updated in the transaction, and forms an update history group (step S2).
  • the data compression unit 52b calculates the hash value of each update history group, and the transaction transmission / reception unit 51b registers the calculated hash value in the transfer destination blockchain 3 (step S3).
  • the transaction transmission / reception unit 51b acquires the transfer TxID from the transfer destination blockchain 3, and the block data processing unit 52 adds the transfer TxID to each update history group. Then, the data transmission / reception unit 53a registers each update history group to which the transfer TxID is added in the transfer destination database 4 (step S4), and the process ends.
  • the data transfer unit 5 or the data registration unit 6 may initialize the transfer source blockchain 2 after the process of step S4 is completed.
  • the request transmission unit 61 acquires the latest value of each update history group, adds an archive flag to the latest value, registers it in the transfer source blockchain 2 (step S12), and ends the process.
  • the request destination control unit 71 specifies the update history group for the key to be acquired in the date and time range (step S21).
  • the request destination control unit 71 acquires the oldest update history data of the key from the transfer source blockchain 2 (step S22). Then, the request destination control unit 71 determines whether or not the latest date and time of the acquisition target is larger (new) than the oldest transaction date and time of the transfer source blockchain 2 (step S23).
  • step S23 the process proceeds to step S27 in FIG.
  • step S24 the request destination control unit 71 determines whether or not the oldest transaction date and time of the acquisition target is larger than the oldest transaction date and time of the transfer source blockchain 2 (step S24).
  • step S24 the request destination control unit 71 acquires update history data in the range from the oldest transaction date and time to the latest date and time to be acquired from the transfer source blockchain 2 through the request transmission unit 72 (step S25). .. Then, the process proceeds to step S27.
  • step S24 the request destination control unit 71 acquires the update history data in the range from the oldest date and time of the acquisition target to the latest date and time of the acquisition target from the transfer source blockchain 2 through the request transmission unit 72 ( Step S26), the process proceeds to step S27.
  • step S27 the request destination control unit 71 determines whether or not the oldest date and time of the acquisition target is smaller (older) than the oldest transaction date and time of the transfer source blockchain 2.
  • step S27 the request destination control unit 71 determines whether or not the latest date and time of the acquisition target is smaller than the oldest transaction date and time of the transfer source blockchain 2 (step S28).
  • step S28 the request destination control unit 71 acquires the update history data in the range from the oldest date and time of the acquisition target to the oldest transaction date and time of the transfer source blockchain 2 from the transfer destination DB4 through the request transmission unit 72. (Step S29). Then, the process proceeds to step S31.
  • step S28 the request destination control unit 71 acquires the update history data in the range from the oldest date and time of the acquisition target to the latest date and time of the acquisition target from the transfer destination DB4 through the request transmission unit 72 (step S30). , The process proceeds to step S31.
  • step S31 the falsification verification unit 73 refers to the update history data of the transfer destination blockchain 3 from the TxID associated with the acquired transaction data, and acquires a hash value from the update history data.
  • the falsification verification unit 73 compares the hash values of the update history data acquired from the transfer destination DB4 and the transfer destination blockchain 3, verifies the falsification of the data (step S32), and the process ends.
  • the first registration unit has a plurality of transactions for the transfer source blockchain 2 that stores a plurality of transactions associated with the first information and the second information.
  • the plurality of second information in the above is registered in the transfer destination DB4 in units of groups based on the first information.
  • the second registration unit registers the hash value obtained by hashing a plurality of second information in a group unit in the transfer destination blockchain 3.
  • the amount of data managed on the relocation destination blockchain 3 can be reduced.
  • the amount of blockchain data can be reduced to 1/100 or less (compression rate is 100 times or more) as compared with the case of hashing one by one.
  • the number of hash verifications when referencing data can be reduced to 1/100 or less. Therefore, the falsification verification of the data at the transfer destination can be easily performed, and the falsification verification can be made more efficient.
  • the group may be a group in which the second information associated with the same first information is grouped according to a predetermined condition.
  • the predetermined condition includes the number of the second information to be included in the group for each predetermined number, each number for which the total data size of the second information to be included in the group is equal to or less than the predetermined data size, and a predetermined number of blocks. It may be included that the number of the second information is at least one.
  • the first registration unit transfers the transfer TxID of the hash value of the group unit registered in the transfer destination blockchain 3 to the group corresponding to the hash value. It may be added to the included second information. As a result, the hash value corresponding to the reference data can be efficiently acquired.
  • the first acquisition unit acquires one or more second information to which the predetermined transfer TxID is added from the transfer destination DB4, and the second acquisition unit corresponds to the predetermined transfer TxID from the transfer destination blockchain 3. Get the hash value to do.
  • the verification unit acquires one or more from the transfer destination DB4 based on the hash value obtained by hashing one or more second information acquired by the first acquisition unit and the hash value acquired by the second acquisition unit. The falsification verification of the second information of the above may be performed. As a result, data tampering detection in the transfer destination blockchain 3 and the transfer destination DB 4 can be efficiently performed.
  • the reference unit refers to the second information from the transfer source blockchain 2 after the restart based on the first information included in the plurality of transactions registered by the third registration unit, and is earlier than the referenced second information.
  • the past second information may be referred to from the transfer destination DB4 based on the third information associated with the transaction of the referred second information.
  • the transfer source blockchain 2 is initialized and the latest value of the update history group is registered, and when the data is referenced, the reference destination is blocked by the transfer source blockchain 2, the transfer destination blockchain 3, and the transfer destination DB4.
  • the client can refer to the data without being aware of the reference destination.
  • FIG. 14 is a block diagram showing an HW (Hardware) configuration example of a computer 10 that realizes the functions of the blockchain system 1.
  • HW Hardware
  • the computer 10 has an HW configuration, for example, a processor 10a, a memory 10b, a storage unit 10c, an IF (Interface) unit 10d, an I / O (Input / Output) unit 10e, and a reading unit. It may be provided with 10f.
  • HW configuration for example, a processor 10a, a memory 10b, a storage unit 10c, an IF (Interface) unit 10d, an I / O (Input / Output) unit 10e, and a reading unit. It may be provided with 10f.
  • the processor 10a is an example of an arithmetic processing unit that performs various controls and operations.
  • the processor 10a may be connected to each block in the computer 10 so as to be able to communicate with each other by the bus 10i.
  • the processor 10a may be a multiprocessor including a plurality of processors, a multicore processor having a plurality of processor cores, or a configuration having a plurality of multicore processors.
  • Examples of the processor 10a include integrated circuits (ICs) such as CPUs, MPUs, GPUs, APUs, DSPs, ASICs, and FPGAs. A combination of two or more of these integrated circuits may be used as the processor 10a.
  • ICs integrated circuits
  • CPU is an abbreviation for Central Processing Unit
  • MPU is an abbreviation for Micro Processing Unit
  • GPU is an abbreviation for Graphics Processing Unit
  • APU is an abbreviation for Accelerated Processing Unit.
  • DSP is an abbreviation for Digital Signal Processor
  • ASIC is an abbreviation for Application Specific IC
  • FPGA is an abbreviation for Field-Programmable Gate Array.
  • the memory 10b is an example of an HW that stores information such as various data and programs. Examples of the memory 10b include volatile memories such as DRAM (Dynamic RAM).
  • the storage unit 10c is an example of an HW that stores information such as various data and programs.
  • Examples of the storage unit 10c include a magnetic disk device such as an HDD (Hard Disk Drive), a semiconductor drive device such as an SSD (Solid State Drive), and various storage devices such as a non-volatile memory.
  • Examples of the non-volatile memory include flash memory, SCM (Storage Class Memory), ROM (Read Only Memory) and the like.
  • the ledgers 22 and 32, the DB 42, and the storage area 50 (see FIG. 6) of the data transfer unit 5 illustrated in FIG. 5 utilize at least a part of the storage area of the memory 10b or the storage unit 10c, respectively. Good.
  • the storage unit 10c may store a program 10g (transaction management program) that realizes all or a part of various functions of the computer 10.
  • a program 10g transaction management program
  • the processor 10a expands and executes the program 10g stored in the storage unit 10c in the memory 10b, so that at least one of the data transfer process, the data registration process, and the data reference process provided by the program 10g. Can be executed. Further, at least one function of the blockchain control unit 21, the blockchain control unit 31, and the DB control unit 41 may also be provided by the program 10g.
  • the computer 10 is based on at least one of the transfer source blockchain 2, the transfer destination blockchain 3, the transfer destination DB 4, the data transfer unit 5, the data registration unit 6, and the data reference unit 7, or various combinations. It can operate as a transaction management device.
  • the transfer source blockchain 2 and the data transfer unit 5 may be realized by one computer 10, or the transfer source blockchain 2, the data transfer unit 5, the data registration unit 6, and the data transfer unit 5 may be realized.
  • the data reference unit 7 may be realized by one computer 10.
  • the transfer destination blockchain 3 and the transfer destination DB 4 may be realized by one computer each.
  • the IF unit 10d is an example of a communication IF that controls connection and communication with a network.
  • the IF unit 10d may include an adapter compliant with LAN (Local Area Network), optical communication (for example, FC (Fibre Channel)), or the like.
  • the adapter may support one or both wireless and wired communication methods.
  • the program 10g may be downloaded from the network to the computer 10 via the communication IF and stored in the storage unit 10c.
  • the computers 10 may be connected by the above network.
  • the I / O unit 10e may include one or both of an input device and an output device.
  • Examples of the input device include a keyboard, a mouse, a touch panel, and the like.
  • Examples of the output device include a monitor, a projector, a printer and the like.
  • the reading unit 10f is an example of a reader that reads data and program information recorded on the recording medium 10h.
  • the reading unit 10f may include a connection terminal or device to which the recording medium 10h can be connected or inserted.
  • Examples of the reading unit 10f include an adapter compliant with USB (Universal Serial Bus) and the like, a drive device for accessing a recording disk, a card reader for accessing a flash memory such as an SD card, and the like.
  • the program 10g may be stored in the recording medium 10h, or the reading unit 10f may read the program 10g from the recording medium 10h and store it in the storage unit 10c.
  • Examples of the recording medium 10h include a non-temporary computer-readable recording medium such as a magnetic / optical disk or a flash memory.
  • Examples of magnetic / optical disks include flexible discs, CDs (Compact Discs), DVDs (Digital Versatile Discs), Blu-ray discs, HVDs (Holographic Versatile Discs), and the like.
  • Examples of the flash memory include semiconductor memories such as USB memory and SD card.
  • the above-mentioned HW configuration of the computer 10 is an example. Therefore, the increase / decrease of HW (for example, addition or deletion of arbitrary blocks), division, integration in any combination, addition or deletion of buses, etc. in the computer 10 may be performed as appropriate.
  • the computer 10 at least one of the I / O unit 10e and the reading unit 10f may be omitted.
  • the blockchain system 1 as a cloud system may be configured by HW resources and NW (Network) resources composed of a plurality of computers 10 that are communicably connected to each other by a network (not shown).
  • HW resources and NW Network resources composed of a plurality of computers 10 that are communicably connected to each other by a network (not shown).
  • each of the nodes such as the transfer source block chain 2, the transfer destination block chain 3, the transfer destination DB 4, the data transfer unit 5, the data registration unit 6, and the data reference unit 7 included in the block chain system 1 is a plurality of computers. It may be realized by logically (virtually) or physically dividing the HW resource and the NW resource composed of 10 and allocating them to the nodes.
  • the blockchain system 1 is a processor resource (processor), a memory resource (memory), a storage resource (storage unit), and an IF resource (IF unit) as HW resources and NW resources provided by a plurality of computers 10. ), May be regarded as one transaction management device.
  • the blockchain system 1 as a transaction management device (computer) allocates processor resources, memory resources, storage resources, and IF resources to or to a node for realizing a specific functional block by scale-out processing. You can release the allocation of.
  • the program 10g for realizing the function as the blockchain system 1 is divided into execution units in each of a plurality of nodes, and the divided programs are distributed to a plurality of nodes. It may be arranged.
  • the plurality of nodes (functional blocks 2 to 7 in FIG. 5) are composed of a plurality of physical machines, a plurality of virtual machines (VMs), and a combination of one or more physical machines and one or more virtual machines. It may be either.
  • the program 10g can be regarded as one program that causes the transaction management device (computer) or the transaction management system to execute the function of the blockchain system 1 even if the program 10g is distributed and arranged on a plurality of nodes.
  • each functional block included in the blockchain system 1 shown in FIG. 5 may be merged or divided in any combination.
  • Blockchain system 2 Relocation source blockchain 20, 30 Blockchain 20a to 20c, 30a to 30d Block 21,31 Blockchain control unit 21a, 31a Transmission / reception unit 22,32 Ledger 4 Relocation destination database 41 Database control unit 41a, 53a Data Transmission / reception unit 42 Database 5 Data transfer unit 51 Blockchain communication unit 51a Block acquisition unit 51b Transaction transmission / reception unit 52 Block data processing unit 52a Data collection unit 52b Data compression unit 53 Database communication unit 50 Storage area 50a to 50e Update history group 6 Data registration Units 61, 72 Request transmission unit 7 Data reference unit 71 Request destination control unit 73 Tampering verification unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Economics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

トランザクション管理装置は、第１情報及び第２情報が関連付けられたトランザクションを複数格納する第１のブロックチェーン（２）について、複数の前記トランザクションにおける複数の前記第２情報を、前記第１情報に基づくグループ単位でデータベース（４）に登録する第１登録部（５２，５３）と、前記グループ単位で前記複数の第２情報をハッシュ化して得られるハッシュ値を、第２のブロックチェーン（３）に登録する第２登録部（５１，５２）と、を備える。

Description

トランザクション管理装置、トランザクション管理プログラム、及びトランザクション管理方法
　本発明は、トランザクション管理装置、トランザクション管理プログラム、及びトランザクション管理方法に関する。
　ブロックチェーン（Blockchain）技術を利用したサービスが多種多様な業界において普及しつつある。
　ブロックチェーンの長期的な運用を試みる際、各ノードにブロック情報が蓄積されることによりデータ量が肥大化することが想定される。データ量肥大化を解消するための手法の１つとしては、例えば、定期的にブロックチェーンのデータを別システムにまとめて移転し、移転元のブロックチェーンを、移転の都度、再起動する手法が挙げられる。
　移転先のシステムには、各トランザクションデータのハッシュ値を登録するブロックチェーンと、各トランザクションデータを登録するデータベース（ＤＢ；Database）とが備えられる。
　移転先のシステムのデータを参照する際には、参照データと、ブロックチェーン上に登録されたハッシュ値とを比較することにより、データベース上のデータ改ざんを検知できる。参照データは、例えば、データベースを参照（検索）して得られるトランザクションデータである。当該参照データにハッシュ演算を行なって得られるハッシュ値と、ブロックチェーン上に登録されたハッシュ値とが一致する場合に、データベース上のデータが改ざんされていないデータであると判断でき、一致しない場合に、データベース上のデータが改ざんされたデータであると判断できる。
特表２０１８－５３７０２２号公報 特開２０１８－１４７０１６号公報 国際公開第２０１７／１７０９１２号パンフレット
　移転先のシステムでは、トランザクションデータごとにハッシュ化されるため、データベース上のデータの改ざん検証がトランザクション単位で行なわれることになり、処理効率が悪い。また、まとまったサイズのデータをハッシュ化する場合と比較して、トランザクションデータごとにハッシュ化されるため、移転先のシステムでの容量の圧縮効率が悪い。このように、トランザクションの改ざん検証に関して、検証の処理効率や、ハッシュデータ圧縮効率が非効率である。
　１つの側面では、本発明は、移転したトランザクションの改ざん検証を効率化することを目的の１つとする。
　１つの側面では、トランザクション管理装置は、第１登録部と、第２登録部と、を備えてよい。前記第１登録部は、第１情報及び第２情報が関連付けられたトランザクションを複数格納する第１のブロックチェーンについて、複数の前記トランザクションにおける複数の前記第２情報を、前記第１情報に基づくグループ単位でデータベースに登録してよい。前記第２登録部は、前記グループ単位で前記複数の第２情報をハッシュ化して得られるハッシュ値を、第２のブロックチェーンに登録してよい。
　１つの側面では、移転したトランザクションの改ざん検証を効率化することができる。
ブロックチェーンシステムの一例を示す図である。 移転先システムの一例を示す図である。 移転先システムから参照データとしてデータＡの更新履歴を検索する動作例を示す図である。 旧ブロックチェーンから移転先ブロックチェーンへデータ移転を行なう場合の動作例を示す図である。 一実施形態の一例としてのブロックチェーンシステムの機能構成例を示すブロック図である。 移転元ブロックチェーンのキーＡ、Ｂ、Ｃについて、キーが同じデータを更新履歴３件ごとに更新履歴群としてまとめる例を示す図である。 移転先のブロックチェーン及びＤＢに登録されるデータの一例を示す図である。 初期化後の移転元ブロックチェーンに登録されるデータの一例を示す図である。 取得対象データの日時範囲と取得先との関係の一例を示す図である。 データ移転プロセスの動作例を示すフローチャートである。 データ登録プロセスの動作例を示すフローチャートである。 データ参照プロセスの動作例を示すフローチャートである。 データ参照プロセスの動作例を示すフローチャートである。 一実施形態の一例としてのコンピュータのハードウェア構成例を示すブロック図である。
　以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、その趣旨を逸脱しない範囲で種々変形して実施することができる。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。
　〔１〕一実施形態
　図１は、ブロックチェーンシステム１００の一例を示す図である。図１を参照して、ブロックチェーンシステム１００におけるデータ量肥大化を解消する手法の一例を説明する。例えば、移転元システム１１０における移転元ブロックチェーン１１１のデータを、定期的に（例えば年に１度）移転先システム１２０にまとめて移転し（符号（ｉ）参照）、移転元ブロックチェーン１１１を再起動する（符号（ii）参照）。移転元ブロックチェーン１１１は、格納するブロックが再起動により変化する（例えば初期化される）ため、再起動前後（移転前後）を区別するために、便宜上、再起動後を移転元ブロックチェーン１１２と表記する。
　移転されるデータは、移転元ブロックチェーン１１１内の１つ以上のブロックであり、移転後のデータは、移転元ブロックチェーン１１２に、移転元ブロックチェーン１１２が次に再起動されるまで未移転のブロックとして格納（保持）される。
　移転元ブロックチェーン１１２は、移転元システム１１０に対する新規データ登録や、未移転のデータ参照等の運用に用いられる。一方、移転先システム１２０は、移転されたデータ、換言すればアーカイブデータの参照に用いられる。
　以下、再起動前の移転元ブロックチェーン１１１を、「旧ブロックチェーン１１１」と表記し、再起動後、運用に用いられる移転元ブロックチェーン１１２を「運用ブロックチェーン１１２」と表記する場合がある。
　図２は、移転先システム１２０の一例を示す図である。図２に例示するように、移転先システム１２０は、ブロックチェーン１２１と、データベース（ＤＢ）１２２とを備える。ブロックチェーン１２１には、各トランザクションデータのハッシュ値が登録され、ＤＢ１２２には、ブロックチェーン１２１に登録したハッシュ値を参照できる形でデータそのものが登録される。例えば、ＤＢ１２２には、各トランザクションデータに、そのハッシュ値をブロックチェーン１２１に登録した際のトランザクションＩＤが付加されて登録される。トランザクションＩＤは、トランザクションデータを一意に特定する識別情報の一例である。
　ブロックチェーン１２１は、ブロック１２１ａ、１２１ｂ、１２１ｃ、・・・のようにチェーン状に接続された１以上のブロックを含む。ブロック１２１ａ、１２１ｂ、１２１ｃには、それぞれ、トランザクションデータのハッシュ値が１つ以上登録される。図２の例では、ブロック１２１ａには、Ｔｘ１／Ｈａｓｈ（ｄａｔａ１）及びＴｘ２／Ｈａｓｈ（ｄａｔａ２）の２つのハッシュ値が登録される。Ｔｘ１及びＴｘ２は、トランザクションＩＤ（以下、「ＴｘＩＤ」と表記する場合がある）である。各ハッシュ値は、Ｔｘ１のトランザクションによる処理で更新されたデータ（data1）をハッシュ化したハッシュ値、及び、Ｔｘ２のトランザクションによる処理で更新されたデータ（data2）をハッシュ化したハッシュ値であることを意味する。
　図３は、移転先システム１２０から参照データとしてデータＡの更新履歴を検索する動作例を示す図である。図３に示すように、ユーザは、ＤＢ１２２から、データＡの更新履歴（Ａ０、Ａ１、Ａ２）と、これらのＴｘＩＤ（Ｔｘ１、Ｔｘ２、Ｔｘ３）とを取得する（符号（ｉ）参照）。なお、図３には、ＴｘＩＤ及び更新履歴を、Ｔｘ１／Ａ０、Ｔｘ２／Ａ１、Ｔｘ３／Ａ２と示す。
　また、ユーザは、ＤＢ１２２から取得した各ＴｘＩＤをキーとして、移転先ブロックチェーン１２１からトランザクションデータのハッシュ値を取得する（符号（ii）参照）。そして、ユーザは、ＤＢ１２２から取得した各データ（更新履歴）と、ブロックチェーン１２１から取得した各ハッシュ値とを１つずつ比較することにより、ＤＢ１２２上のデータ改ざんを検証する（符号（iii）参照）。これにより、ＤＢ１２２に登録されたデータと、ブロックチェーン１２１に登録された改ざんが困難であるハッシュ値とを比較することで、改ざんの虞がある、ＤＢ１２２に登録されたデータの改ざん検証を行なうことができる。
　しかし、図２に例示する移転先システム１２０においては、トランザクションデータを１つずつハッシュ化してブロックチェーン１２１に登録するため、ＤＢ１２２に登録されたデータに対する改ざん検知処理において、１つずつデータとハッシュ値との比較を行なうことになり、非効率である。
　図４は、旧ブロックチェーン１１１から移転先ブロックチェーン１２１へデータ移転を行なう場合の動作例を示す図である。図４に例示するように、移転先システム１２０において、旧ブロックチェーン１１１内のトランザクションごとに、データがハッシュ化され、移転先ブロックチェーン１２１に登録される。図４の例では、Ｔｘ１／Ａ０～Ｔｘ５／Ａ４が、それぞれ、Ｔｘ１′／Ｈａｓｈ（Ａ０）～Ｔｘ５′／Ｈａｓｈ（Ａ４）にハッシュ化される。
　しかし、図４のように、トランザクションデータ単位でハッシュ化されるため、ブロックチェーン１２１に登録されるトランザクション数は、ブロックチェーン１１１から減少しない。従って、例えば複数のトランザクションをまとめて圧縮するような場合と比較して、移転先ブロックチェーン１２１でのデータ量の圧縮効率が悪く、移転先システム１２０（移転先ブロックチェーン１２１）の記憶領域の容量削減効果が小さい。
　また、移転処理が行なわれた後、ユーザ（クライアント）は、移転元（運用）ブロックチェーン１１２と、ＤＢ１２２及び移転先ブロックチェーン１２１と、のうちのどちらからトランザクションデータを参照するかを意識（判定）することになる。しかし、参照するデータが移転元システム１１０及び移転先システム１２０のいずれに存在するのかをユーザが判断することは困難である。
　そこで、一実施形態では、ブロックチェーンで管理するデータ量を削減し、改ざん検証を効率的に実行できるようにブロックチェーンデータの移転（アーカイブ）を実現する手法を説明する。
　〔１－１〕一実施形態の機能構成例
　図５は、一実施形態の一例としてのブロックチェーンシステム１の機能構成例を示すブロック図である。図５に示すように、ブロックチェーンシステム１は、機能構成として、例示的に、移転元ブロックチェーン２、移転先ブロックチェーン３、移転先ＤＢ４、データ移転部５、データ登録部６、及び、データ参照部７を備えてよい。なお、図５では、ブロックチェーンを「Ｃｈａｉｎ」、ブロックを「Ｂｌｃ」、トランザクションを「Ｔｒａｎｓ」と表記する。
　移転元ブロックチェーン２は、キー及び値が関連付けられたトランザクションを複数格納する第１のブロックチェーンの一例である。「キー」は、トランザクションの処理対象であってよく、第１情報の一例である。「値」は、トランザクションの処理により更新された、キーの値（例えば更新値）であってよく、第２情報の一例である。
　トランザクションは取引の記録であり、移転元ブロックチェーン２が格納するトランザクションのデータは、キーの更新履歴と言い換えることができる。トランザクションには、キー及び値そのものが含まれなくてもよく、同じキーに対する１以上のトランザクションの記録から値が算出されてもよい。
　なお、一実施形態では、運用により蓄積される移転元ブロックチェーン２のデータの肥大化を解消するために、移転元ブロックチェーン２のデータを移転先ブロックチェーン３及び移転先ＤＢ４に移転させ、移転元ブロックチェーン２を初期化する動作を想定する。初期化後の移転元ブロックチェーン２には、移転したデータの一部と、移転先に関する情報とを予め登録しておき、その後に運用が再開される。初期化後の移転元ブロックチェーン２は、第３のブロックチェーンの一例である。
　移転元ブロックチェーン２は、図５に例示するように、ブロックチェーン制御部２１及び台帳２２を備える。
　ブロックチェーン制御部２１は、台帳２２に対するトランザクションの登録や参照等の処理を制御する。ブロックチェーン制御部２１は、送受信部２１ａを備えてよい。送受信部２１ａは、台帳２２に対する更新及び参照（取得）、データ移転部５、データ登録部６、並びに、データ参照部７との間のデータの送受信等を行なう。
　台帳２２は、１以上のブロックを連結して格納するブロックチェーンを備える。ブロックは、１以上のトランザクションを含んでよい。台帳２２は、値（バリュー）を一意のキーに紐付けて保存する、キー・バリュー形式のＤＢを備えてもよい。
　例えば、台帳２２では、送受信部２１ａにより、トランザクションの実行履歴がブロックチェーンに書き込まれ、トランザクションを実行した結果の最新の状態がＤＢに書き込まれてよい。なお、トランザクションはタイムスタンプを含んでもよい。タイムスタンプは、既知の手法により取得及び付加することが可能である。台帳２２に格納されるトランザクションは、ハッシュ値及び非ハッシュ値の一方又は双方であってよい。なお、ブロックチェーンにはトランザクションのハッシュ値が格納される場合、台帳２２は、例えば、非ハッシュ値のトランザクションの記録をさらに記憶してもよい。
　移転先ブロックチェーン３は、移転元ブロックチェーン２からのトランザクションデータの移転先の１つであり、第２のブロックチェーンの一例である。移転先ブロックチェーン３は、図５に例示するように、ブロックチェーン制御部３１及び台帳３２を備える。
　ブロックチェーン制御部３１は、台帳３２に対するトランザクションの登録や参照等の処理を制御する。ブロックチェーン制御部３１は、送受信部３１ａを備えてよい。送受信部３１ａは、台帳３２に対する更新及び参照（取得）、データ移転部５、並びに、データ参照部７との間のデータの送受信等を行なう。
　台帳３２は、１以上のブロックを連結して格納するブロックチェーンを備える。ブロックは、１以上のトランザクションを含んでよい。台帳３２は、値（バリュー）を一意のキーに紐付けて保存する、キー・バリュー形式のＤＢを備えてもよい。
　例えば、台帳３２では、送受信部３１ａにより、トランザクションの実行履歴がブロックチェーンに書き込まれ、トランザクションを実行した結果の最新の状態がＤＢに書き込まれてよい。なお、トランザクションはタイムスタンプを含んでもよい。タイムスタンプは、既知の手法により取得し及び付加することが可能である。台帳３２に格納されるトランザクションは、ハッシュ値であってよい。
　移転先ＤＢ４は、移転元ブロックチェーン２からのトランザクションデータの移転先の１つであり、データベースの一例である。移転先ＤＢ４は、図５に例示するように、ＤＢ制御部４１及びＤＢ４２を備えてよい。
　ＤＢ制御部４１は、ＤＢ４２に対するデータの登録や参照等の処理を制御する。ＤＢ制御部４１は、データ送受信部４１ａを備えてよい。データ送受信部４１ａは、ＤＢ４２に対する更新及び参照（取得）、データ移転部５、並びに、データ参照部７との間のデータの送受信等を行なう。
　ＤＢ４２は、移転元ブロックチェーン２のキーの更新履歴と、移転先ブロックチェーン３に登録されトランザクションＩＤ（ＴｘＩＤ）とを格納する。例えば、ＤＢ４２では、データ送受信部４１ａにより、キーの更新履歴、及び、ＴｘＩＤが書き込まれてよい。なお、移転先ブロックチェーン３にデータをそのまま登録せずに移転先ＤＢ４を用いるのは、データ量を削減するためである。
　データ移転部５、データ登録部６、及び、データ参照部７は、それぞれ、例えば、コンピュータのプロセッサによる処理単位であるプロセス（データ移転プロセス、データ登録プロセス、及び、データ参照プロセス）として実行されてよい。データ移転部５、データ登録部６、及び、データ参照部７の各プロセスは、互いに異なるコンピュータにより実行されてもよいし、２つ以上のプロセスが共通するコンピュータにより実行されてもよい。コンピュータは、情報処理装置、又は、トランザクション管理装置と称されてもよい。
　なお、一実施形態では、前提として、移転元ブロックチェーン２ではキーごとに各顧客のウォレット残高（値）が管理されているものとする。また、移転先ブロックチェーン３においては、スマートコントラクト等によってブロックチェーンへのデータ移転情報の読み書きが定義されているものとし、移転元及び移転先のデータ参照時には日時範囲を指定して参照できるものとする。さらに、データの移転が行なわれる間は、移転元ブロックチェーン２において新規データの登録や参照を受け付けないものとする。
　（データ移転部５の構成例）
　データ移転部５は、移転元ブロックチェーン２のトランザクションデータを、トランザクションにて更新されたキーが同じデータごとにまとめ、移転先ブロックチェーン３及び移転先ＤＢ４に移転する。
　データ移転部５は、図５に例示するように、ブロックチェーン通信部５１、ブロックデータ処理部５２、及び、ＤＢ通信部５３を備えてよい。
　ブロックチェーン通信部５１は、移転元ブロックチェーン２及び移転先ブロックチェーン３との間でデータの通信を行なうものであり、ブロック取得部５１ａ及びトランザクション送受信部５１ｂを備える。
　ブロックデータ処理部５２は、ブロックチェーン通信部５１から受信したデータに基づき、データ移転のトランザクションデータ及びハッシュ値を生成するものであり、データまとめ部５２ａ及びデータ圧縮部５２ｂを備える。
　ＤＢ通信部５３は、移転先ＤＢ４との間でデータの通信を行なうものであり、データ送受信部５３ａを備える。
　以下、データ移転部５が備える上述した機能ブロックの説明を、データ移転部５による処理の説明において行なう。データ移転部５は、例示的に、以下の（ｉ）～（iv）（図５の符号（ｉ）～（iv）に対応）の処理を実行してよい。
　（ｉ）ブロック取得部５１ａは、移転元ブロックチェーン２の送受信部２１ａから、移転元ブロックチェーン２のブロック情報、換言すれば、トランザクションデータを一括取得する。
　また、ブロック取得部５１ａは、取得したブロック情報をデータまとめ部５２ａに送信（出力）する。
　なお、ブロック取得部５１ａは、例えば、移転元ブロックチェーン２から、１番目の（最古の）ブロックから最後の（最新の）ブロックまでを時系列で昇順に、換言すれば、複数のトランザクションの各々の登録順に、トランザクションデータを取得してよい。
　（ii）データまとめ部５２ａは、上記（ｉ）で取得した全トランザクションデータについて、キーに基づくグループ単位で区切って、更新履歴群としてまとめる。グループは、例えば、同じキーが関連付けられたデータ（値）どうしを所定条件に従ってまとめたグループであってよい。
　所定条件としては、グループに含める値の件数を、所定の件数ごと、グループに含める値の合計データサイズが所定のデータサイズ以下となる件数ごと、及び、所定数のブロックに含まれる件数ごと、の少なくとも１つとすることを含んでよい。なお、所定の件数、所定のデータサイズ、及び、（ブロックの）所定数は、それぞれ、予め設定可能である。
　図６は、移転元ブロックチェーン２のキーＡ、Ｂ、Ｃについてキーが同じデータを更新履歴３件ごとに更新履歴群としてまとめる例を示す図である。図６では、所定条件が、グループに含める値の件数を「所定の件数ごと」とする場合であって、所定の件数が“３”に設定された場合を示す。なお、図６において、ブロックチェーン２０は、台帳２２内のブロックチェーンであり、少なくともブロック２０ａ～２０ｃ（ブロック１～３）が登録されていることを示す。
　図６に例示するように、ブロック２０ａにおいて、Ｔｘ２では、キーＣの値（顧客Ｃの残高）を“４０”に更新し、キーＡの値（顧客Ａの残高）を“２００”に更新している。データまとめ部５２ａは、トランザクションＴｘ１～Ｔｘ５における各値（残高）を、各キー（顧客）の更新履歴に従い３件ごとに、更新履歴群５０ａ～５０ｄとしてまとめる。
　一例として、更新履歴群５０ａ及び５０ｂは、顧客Ａの残高更新履歴が、１００円、２００円、３００円、４００円、５００円の順である（最後が最新値）ことを示す。図６の例では、上記（ｉ）において、トランザクションの登録順にトランザクションデータが取得されるため、残高の更新順序が更新履歴群５０ａ及び５０ｂに適切に反映されている。
　なお、図６において、更新履歴群５０ａ～５０ｄは、例えば、データ移転プロセスを実行するコンピュータのメモリ等の記憶領域５０で管理されてよい。
　（iii）データ移転部５は、各更新履歴群５０ａ～５０ｄのハッシュ値に、それぞれの移転先のＤＢ４２（或いは移転先ＤＢ４）にアクセスするためのアクセス情報を付加して、移転先ブロックチェーン３に登録する。アクセス情報としては、例えば、移転先のＤＢ４２又は移転先ＤＢ４のＵＲＬ（Uniform Resource Locator）やＩＰ（Internet Protocol）アドレス等のＵＲＩ（Uniform Resource Identifier）が挙げられる。
　例えば、データ圧縮部５２ｂは、データまとめ部５２ａがまとめた更新履歴群５０ａ～５０ｄのそれぞれについて、ハッシュ演算を行なうことでハッシュ値を算出する。ハッシュ値の算出は、既知の手法により実現されてよい。
　なお、移転先ブロックチェーン３には、１つのハッシュ値につき１つのブロックが割り当てられてよく、更新履歴群５０ａ～５０ｄの順に各ブロックが連結されてよい。
　ブロックデータ処理部５２は、データ圧縮部５２ｂが算出したハッシュ値にアクセス情報を付加した移転トランザクションを、トランザクション送受信部５１ｂに送信（出力）する。
　トランザクション送受信部５１ｂは、ブロックデータ処理部５２から、移転トランザクションを受信すると（受け取ると）、移転先ブロックチェーン３の送受信部３１ａに対して、移転トランザクションを台帳３２への登録指示とともに送信する。また、トランザクション送受信部５１ｂは、移転トランザクションが台帳３２に登録された際のＴｘＩＤ（移転ＴｘＩＤ）を送受信部３１ａから受信し、ＤＢ通信部５３に送信する。
　図７は、移転先のブロックチェーン３０及びＤＢ４２に登録されるデータの一例を示す図である。なお、図７において、移転先のブロックチェーン３０は、移転先ブロックチェーン３の台帳３２内のブロックチェーンである。
　一例として、ブロックデータ処理部５２は、図７に示すように、更新履歴群５０ａをハッシュ化したハッシュ値（Ｈａｓｈ（｛Ａ：［１００，２００，３００］｝））に、アクセス情報（ＤＢ１）を付加する。トランザクション送受信部５１ｂは、送受信部３１ａを通じて、移転トランザクションをブロックチェーン３０のブロック３０ａに登録する。この移転トランザクションは、ブロックチェーン３０において、移転ＴｘＩＤ：Ｔｘ１のトランザクションであるため、トランザクション送受信部５１ｂは、データ送受信部５３ａに移転ＴｘＩＤ：Ｔｘ１を通知する。
　また、例えば、ブロックデータ処理部５２は、更新履歴群５０ｂをハッシュ化したハッシュ値（Ｈａｓｈ（｛Ａ：［４００，５００］｝））に、アクセス情報（ＤＢ１）を付加する。トランザクション送受信部５１ｂは、送受信部３１ａを通じて、移転トランザクションを、ブロック３０ａに連結したブロック３０ｂに登録する。この移転トランザクションは、ブロックチェーン３０において、移転ＴｘＩＤ：Ｔｘ２のトランザクションであるため、トランザクション送受信部５１ｂは、データ送受信部５３ａに移転ＴｘＩＤ：Ｔｘ２を通知する。
　このように、ブロックチェーン３０では、グループ単位でまとめたハッシュ値がブロック（図７の例ではブロック３０ａ～３０ｄ）に登録される。このため、例えば、キーＢの値が参照される場合、ブロック３０ｃのトランザクションデータの取得により、同じキーＢの更新履歴をまとめて検証でき、図３の例と比較して、処理効率を向上できる。
　以上のことから、ブロックチェーン通信部５１及びブロックデータ処理部５２は、キーに基づくグループ単位で複数の値をハッシュ化して得られるハッシュ値を、移転先ブロックチェーン３に登録する第２登録部の一例である。
　（iv）データ移転部５は、各更新履歴群５０ａ～５０ｄに、ブロックチェーン３０に各ハッシュ値を登録した際のＴｘＩＤと、移転先ブロックチェーン３又はブロックチェーン３０にアクセスするためのアクセス情報とを付加して、移転先ＤＢ４に登録する。アクセス情報としては、例えば、移転先ブロックチェーン３又はブロックチェーン３０のＵＲＬやＩＰアドレス等のＵＲＩが挙げられる。
　一例として、ブロックデータ処理部５２は、更新履歴群５０ａのキーＡ及び更新履歴群５０ａの値［１００，２００，３００］、換言すれば、トランザクションデータを、データ送受信部５３ａに送信する。
　データ送受信部５３ａは、移転先ＤＢ４のデータ送受信部４１ａに対して、ブロックデータ処理部５２から受信したトランザクションデータと、トランザクション送受信部５１ｂから受信した移転ＴｘＩＤとを、ＤＢ４２への登録指示とともに送信する。
　一例として、データ送受信部５３ａは、図７に示すように、データ送受信部４１ａを通じて、更新履歴群５０ａのキーＡを、ＤＢ４２のキー４２ａに登録し、更新履歴群５０ａの値［１００，２００，３００］をＤＢ４２の更新履歴４２ｃに登録する。また、データ送受信部５３ａは、データ送受信部４１ａを通じて、ブロック３０ａに更新履歴群５０ａのハッシュ値を登録した際のＴｘＩＤ（Ｔｘ１）を、ＤＢ４２の移転ＴｘＩＤ４２ｄに登録する。さらに、データ送受信部５３ａは、データ送受信部４１ａを通じて、ブロックチェーン３０のアクセス情報（Ｃｈａｉｎ１）を、ＤＢ４２の参照先ＵＲＬ４２ｅに登録する。
　移転ＴｘＩＤ４２ｄは、ブロックチェーン３０におけるハッシュ値の登録位置を識別可能な情報であり、ハッシュ値の登録位置情報の一例である。なお、移転ＴｘＩＤ４２ｄには、ＴｘＩＤに加えて、ＴｘＩＤに対応する更新履歴が登録されてもよい。
　また、データ送受信部５３ａは、図７に示すように、更新履歴群５０ｂのキーＡに一致するエントリがＤＢ４２に存在する場合、データ送受信部４１ａを通じて、当該エントリの更新履歴４２ｃに、更新履歴群５０ｂの値［４００，５００］を登録（追加）する。さらに、データ送受信部５３ａは、図７に示すように、データ送受信部４１ａを通じて、更新履歴群５０ｂのキーＡに一致するエントリの移転ＴｘＩＤ４２ｄに、ブロック３０ｂに更新履歴群５０ｂのハッシュ値を登録した際のＴｘＩＤ（Ｔｘ２）を登録（追加）する。
　なお、データ送受信部５３ａは、図７に例示するように、送受信部３１ａを通じて、キー４２ａごとに、更新履歴４２ｃのうちの最新の値（例えばキーＡの場合、“５００”）を、当該キーのエントリの最新値４２ｂに登録してもよい。
　以上のことから、ブロックデータ処理部５２及びＤＢ通信部５３は、移転元ブロックチェーン２について、複数のトランザクションにおける複数の値を、キーに基づくグループ単位で移転先ＤＢ４に登録する第１登録部の一例である。
　以上のように、データ移転部５は、移転元ブロックチェーン２から、移転先ブロックチェーン３及び移転先ＤＢ４へのトランザクションデータの移転処理を実行する。
　上述した移転処理は、例えば、プロセッサが、ユーザから移転処理の実行要求を受信した場合に、データ移転プロセスを起動し、起動したデータ移動プロセス（データ移転部５）により実行されてよい。
　（データ登録部６の説明）
　移転処理の終了後、プロセッサは、データ登録プロセスを起動してよい。起動したデータ登録プロセス（データ登録部６）は、移転元ブロックチェーン２を初期化するとともに、データ移転プロセスにより記憶領域５０が保持する更新履歴群５０ａ～５０ｄの情報を引き継いでよい。
　データ登録部６は、図５に例示するように、リクエスト送信部６１を備えてよい。
　リクエスト送信部６１は、移転元ブロックチェーン２に対する各キーの更新値の登録要求等のリクエストを送信する。一例として、リクエスト送信部６１は、ユーザ（クライアント）から、キーの更新値を受信した場合に、登録要求を生成及び送信してよい。
　データ登録部６は、例示的に、以下の（ｖ）（図５の符号（ｖ）に対応）の処理を実行してよい。
　（ｖ）リクエスト送信部６１は、移転元ブロックチェーン２に更新履歴群５０ａ～５０ｄの最新値を登録する。
　例えば、リクエスト送信部６１は、データ移転部５の移転処理におけるブロックチェーン３０及びＤＢ４２へのデータの登録）、並びに、移転元ブロックチェーン２の初期化が終了するまで待機する。
　移転処理及び初期化の終了後、リクエスト送信部６１は、データまとめ部５２ａから、ＤＢ４２に登録された各更新履歴群５０ａ～５０ｄの最新値を取得する。データまとめ部５２ａは、記憶領域５０に保存された各更新履歴群５０ａ～５０ｄから、それぞれの最新値を取得してもよいし、ＤＢ通信部５３を介して、移転先のＤＢ４２における各キー４２ａの最新値４２ｂ（図７参照）を取得してもよい。
　また、リクエスト送信部６１は、各更新履歴群５０ａ～５０ｄの最新値と、移転先ＤＢ４に各更新履歴群５０ａ～５０ｄのキーの更新履歴が存在するフラグと、を関連付けたトランザクションを、移転元ブロックチェーンに登録する。フラグ（アーカイブフラグ）は、１以上の値（更新履歴）のうちの最新の値よりも過去の値が移転先ＤＢ４に存在することを示す第３情報の一例である。
　図８は、初期化後の移転元ブロックチェーン２に登録されるデータの一例を示す図である。なお、移転元ブロックチェーン２では、初期化により、初期化前のブロック２０ａ～２０ｃ（図６参照）が削除される。
　初期化後の移転元ブロックチェーン２には、更新履歴群５０ｂ～５０ｄのキー（キーＡ、Ｂ、Ｃ）の最新値（５００、３、９０）が、それぞれブロック２０ａ～２０ｃに登録される。また、ブロック２０ａ～２０ｃには、それぞれ、キーＡｒｃｈｉｖｅに、アーカイブフラグがＯＮであることを示すｔｒｕｅが登録される。なお、図８に示すように、各ブロック２０ａ～２０ｃ（各トランザクションＴｘ１～Ｔｘ３）には、タイムスタンプが登録されてよい。
　以上のように、リクエスト送信部６１は、第１情報と、第２情報と、第３情報と、を関連付けたトランザクションを、第３のブロックチェーンに登録する第３登録部の一例である。フラグにより、移転元ブロックチェーン２を参照することで、最新の更新値よりも過去の更新値が移転先ＤＢ４に存在することを容易に検出（判別）可能となる。
　また、リクエスト送信部６１は、フラグを含むトランザクションの登録後に、新たなトランザクションの登録要求に応じて、フラグを含むトランザクションに続けて、登録要求に係るトランザクションを登録する第４登録部の一例である。これにより、移転元ブロックチェーン２における、移転前後のトランザクションの整合性を担保できる。
　なお、ここまで、移転元ブロックチェーン２のデータ移転後に、移転元ブロックチェーン２を初期化した結果であるデータベースを、新たな移転元ブロックチェーン２として利用する（再利用する）場合を例に挙げて説明したが、これに限定されるものではない。「新たな移転元ブロックチェーン」としては、移転元ブロックチェーン２とは異なる他のブロックチェーンが利用されてもよい。新たな移転元ブロックチェーンとしての、移転元ブロックチェーン２、又は、移転元ブロックチェーン２とは異なる他のブロックチェーンは、第３のブロックチェーンの一例である。
　（データ参照部７の説明）
　データ参照プロセスは、データ移転プロセス及びデータ登録プロセスが動作しておらず、移転元ブロックチェーン２、移転先ブロックチェーン３、及び移転先ＤＢ４が起動していれば動作可能である。例えば、データ参照プロセス（データ参照部７）は、ユーザ（クライアント）からのデータ参照の要求に応じて、日時範囲を指定してキーに対応する更新履歴群を取得する。ユーザは、データの格納先を意識せずに、移転元ブロックチェーン２と、移転先ブロックチェーン３及び移転先ＤＢ４と、のうちの一方又は双方から更新履歴群を参照できる。
　また、データ参照部７は、データ参照要求に応じて参照先から受信したデータに対する、改ざん検証処理を行なう。
　データ参照部７は、図５に例示するように、リクエスト先制御部７１、リクエスト送信部７２、及び改ざん検証部７３を備えてよい。
　リクエスト先制御部７１は、データ参照の際のリクエスト先を制御する。
　リクエスト送信部７２は、リクエスト先制御部７１による制御に応じて、移転元ブロックチェーン２と、移転先ブロックチェーン３及び移転先ＤＢ４と、のうちの一方又は双方に対して、データの参照要求を送信する。
　図９は、取得対象データの日時範囲と取得先との関係の一例を示す図である。取得対象データは、例えば、ユーザから要求されたデータ参照の条件（例えば取得対象のキー及び日時範囲等）に一致するデータである。
　例えば、リクエスト先制御部７１は、取得対象のキーに対する更新履歴群を日時範囲で指定し、リクエスト送信部７２を通じて、移転元ブロックチェーン２から取得対象のキーの最古の更新履歴データを参照する。図８の例では、対象キーがキーＡである場合、リクエスト先制御部７１は、ブロック２０ａのデータを参照する。なお、以下の説明において、取得（参照）したデータの日時（最古のトランザクション日時）は、ブロック２０ａに登録されたタイムスタンプから求められるものとする。
　図９に例示するように、リクエスト先制御部７１は、取得対象の日時範囲のうちの最新日時が、取得したデータの日時よりも新しい場合、移転元ブロックチェーン２を更新履歴データの参照先に決定する。
　リクエスト先制御部７１は、取得対象の日時範囲のうちの最古の日時が移転元ブロックチェーン２の最古の日時よりも新しい場合、「取得対象の最古の日時～取得対象の最新日時」の範囲のデータを、参照先から参照すると決定する（図９の（Ｉ）の例に該当）。
　一方、取得対象の日時範囲のうちの最古の日時が移転元ブロックチェーン２の最古の日時よりも古い場合、リクエスト先制御部７１は、「移転元ブロックチェーン２の最古の日時～取得対象の最新日時」の第１範囲のデータを、参照先から参照すると決定する。第１範囲のデータは、図９の（III）の例における、（III-1）の範囲のデータに該当する。
　また、リクエスト先制御部７１は、取得対象の最古の日時が移転元ブロックチェーン２の最古の日時よりも古く、且つ、取得したデータにアーカイブフラグが付加されている場合、移転先ブロックチェーン３及び移転先ＤＢ４を更新履歴データの参照先に決定する。
　リクエスト先制御部７１は、取得対象の最新日時が取得したデータの日時よりも古い場合、「取得対象の最古の日時～取得対象の最新日時」の範囲のデータを、参照先（移転先）から参照すると決定する（図９の（II）の例に該当）。
　一方、リクエスト先制御部７１は、取得対象の最新日時が移転元ブロックチェーン２の最古の日時よりも新しい場合、「取得対象の最古の日時～移転元ブロックチェーン２の最古の日時」の第２範囲のデータを、参照先（移転先）から参照すると決定する。第２範囲のデータは、図９の（III）の例における、（III-2）の範囲のデータに該当する。
　以上のように、リクエスト先制御部７１及びリクエスト送信部７２は、参照部の一例である。当該参照部は、移転元ブロックチェーン２から、リクエスト送信部６１が登録した複数のトランザクションに含まれるキーに基づきトランザクションデータを参照する。そして、当該参照部は、参照したデータよりも過去のデータがデータ参照で要求される場合、参照したデータのトランザクションに関連付けられたフラグに基づき、移転先ＤＢ４から過去のデータを参照する。これにより、移転先ブロックチェーン３及び移転先ＤＢ４から、過去のトランザクションデータの参照を行なうことが可能となる。
　改ざん検証部７３は、リクエスト送信部７２が送信した参照要求に応じて取得された（参照した）データの改ざん検証を行なう。
　例えば、改ざん検証部７３は、図９の（II）又は（III-2）の例において取得した更新履歴データに紐付く１以上のＴｘＩＤを用いて、リクエスト送信部７２を介して、移転先ブロックチェーン３の更新履歴データを参照し、ハッシュ値を取得する。
　そして、改ざん検証部７３は、上記更新履歴データのハッシュ値を算出し、算出したハッシュ値と、移転先ブロックチェーン３から取得したハッシュ値とを比較し、比較結果に基づき、移転先ＤＢ４から取得したデータの改ざんを検証する。例えば、改ざん検証部７３は、比較結果が一致する場合は、移転先ＤＢ４から取得したデータが改ざんされていないと判定し、比較結果が一致しない場合は、移転先ＤＢ４から取得したデータが改ざんされていると判定してよい。
　以上のように、改ざん検証部７３は、移転先ＤＢ４から、所定のＴｘＩＤが付加された１以上のデータを取得する第１取得部の一例である。また、改ざん検証部７３は、移転先ブロックチェーン３から、所定のＴｘＩＤに対応するハッシュ値を取得する第２取得部の一例である。さらに、改ざん検証部７３は、第１取得部として取得した１以上のデータをハッシュ化して得られるハッシュ値と、第２取得部として取得したハッシュ値とに基づき、移転先ＤＢ４から取得した１以上のデータの改ざん検証を行なう検証部の一例である。このように、改ざん検証部７３によれば、移転したトランザクションの改ざん検証を効率化することができる。
　〔１－２〕一実施形態の動作例
　次に、図１０～図１３を参照して、一実施形態に係るブロックチェーンシステム１の動作例を説明する。
　〔１－２－１〕データ移転プロセスの動作例
　図１０に例示するように、ブロック取得部５１ａは、移転元ブロックチェーン２のトランザクションデータを、先頭のブロックから昇順に一括取得する（ステップＳ１）。
　データまとめ部５２ａは、ブロック取得部５１ａが取得した全トランザクションデータを、トランザクションにて更新されたキーが同じであるデータごとにまとめて、更新履歴群とする（ステップＳ２）。
　データ圧縮部５２ｂが各更新履歴群のハッシュ値を算出し、トランザクション送受信部５１ｂは、算出したハッシュ値を移転先ブロックチェーン３に登録する（ステップＳ３）。
　トランザクション送受信部５１ｂが移転先ブロックチェーン３から移転ＴｘＩＤを取得し、ブロックデータ処理部５２が各更新履歴群に移転ＴｘＩＤを付加する。そして、データ送受信部５３ａは、移転ＴｘＩＤが付加された各更新履歴群を、移転先データベース４に登録し（ステップＳ４）、処理が終了する。
　なお、データ移転部５又はデータ登録部６は、ステップＳ４の処理が完了した後、移転元ブロックチェーン２を初期化してよい。
　〔１－２－２〕データ登録プロセスの動作例
　図１１に例示するように、データ登録部６は、データ移転プロセスが終了し、且つ、移転元ブロックチェーン２の初期化が終了するまで待機する（ステップＳ１１）。
　リクエスト送信部６１は、各更新履歴群の最新値を取得し、最新値にアーカイブフラグを付加して、移転元ブロックチェーン２に登録し（ステップＳ１２）、処理が終了する。
　〔１－２－３〕データ参照プロセスの動作例
　図１２に例示するように、リクエスト先制御部７１は、取得対象のキーに対する更新履歴群を日時範囲で指定する（ステップＳ２１）。
　また、リクエスト先制御部７１は、移転元ブロックチェーン２から、当該キーの最古の更新履歴データを取得する（ステップＳ２２）。そして、リクエスト先制御部７１は、取得対象の最新日時が、移転元ブロックチェーン２の最古のトランザクション日時よりも大きい（新しい）か否かを判定する（ステップＳ２３）。
　ステップＳ２３でＮｏの場合、処理が図１３のステップＳ２７に移行する。一方、ステップＳ２３でＹｅｓの場合、リクエスト先制御部７１は、取得対象の最古日時が、移転元ブロックチェーン２の最古トランザクション日時よりも大きいか否かを判定する（ステップＳ２４）。
　ステップＳ２４でＮｏの場合、リクエスト先制御部７１は、リクエスト送信部７２を通じて、移転元ブロックチェーン２から、最古トランザクション日時～取得対象の最新日時の範囲の更新履歴データを取得する（ステップＳ２５）。そして、処理がステップＳ２７に移行する。
　ステップＳ２４でＹｅｓの場合、リクエスト先制御部７１は、リクエスト送信部７２を通じて、移転元ブロックチェーン２から、取得対象の最古日時～取得対象の最新日時、の範囲の更新履歴データを取得し（ステップＳ２６）、処理がステップＳ２７に移行する。
　図１３に例示するように、ステップＳ２７において、リクエスト先制御部７１は、取得対象の最古日時が、移転元ブロックチェーン２の最古トランザクション日時よりも小さい（古い）か否かを判定する。
　ステップＳ２７でＮｏの場合、処理が終了する。一方、ステップＳ２７でＹｅｓの場合、リクエスト先制御部７１は、取得対象の最新日時が、移転元ブロックチェーン２の最古トランザクション日時よりも小さいか否かを判定する（ステップＳ２８）。
　ステップＳ２８でＮｏの場合、リクエスト先制御部７１は、リクエスト送信部７２を通じて、移転先ＤＢ４から、取得対象の最古日時～移転元ブロックチェーン２の最古トランザクション日時の範囲の更新履歴データを取得する（ステップＳ２９）。そして、処理がステップＳ３１に移行する。
　ステップＳ２８でＹｅｓの場合、リクエスト先制御部７１は、リクエスト送信部７２を通じて、移転先ＤＢ４から、取得対象の最古日時～取得対象の最新日時の範囲の更新履歴データを取得し（ステップＳ３０）、処理がステップＳ３１に移行する。
　ステップＳ３１では、改ざん検証部７３は、取得したトランザクションデータに紐付くＴｘＩＤから、移転先ブロックチェーン３の更新履歴データを参照し、更新履歴データからハッシュ値を取得する。
　そして、改ざん検証部７３は、移転先ＤＢ４、移転先ブロックチェーン３から取得した更新履歴データのハッシュ値を比較し、データの改ざんを検証して（ステップＳ３２）、処理が終了する。
　以上のように、一実施形態に係るブロックチェーンシステム１によれば、第１登録部は、第１情報及び第２情報が関連付けられたトランザクションを複数格納する移転元ブロックチェーン２について、複数のトランザクションにおける複数の第２情報を、第１情報に基づくグループ単位で移転先ＤＢ４に登録する。また、第２登録部は、グループ単位で複数の第２情報をハッシュ化して得られるハッシュ値を、移転先ブロックチェーン３に登録する。
　これにより、移転先ブロックチェーン３上で管理するデータ量を削減することができる。例えば、１００個のトランザクションデータをまとめてハッシュ化する場合、１個ずつハッシュ化する場合に比べて、ブロックチェーンのデータ量を１／１００以下（圧縮率を１００倍以上）とすることができ、データ参照の際のハッシュ検証回数を１／１００以下とすることができる。従って、移転先におけるデータの改ざん検証を容易に行なうことができ、改ざん検証を効率化することができる。
　また、グループは、同じ第１情報が関連付けられた第２情報どうしを所定条件に従ってまとめたグループであってよい。これにより、移転先ブロックチェーン３で管理されるハッシュ値の数を削減でき、移転先ブロックチェーン３の参照を容易とすることができる。
　さらに、所定条件は、グループに含める第２情報の数を、所定の数ごと、グループに含める第２情報の合計データサイズが所定のデータサイズ以下となる数ごと、及び、所定数のブロックに含まれる第２情報の数ごと、の少なくとも１つとすることを含んでよい。
　これにより、まとめてハッシュ化するデータの件数が制限されることで、改ざん検証の際の処理負荷（例えば参照データのハッシュ演算負荷）の増加を抑制できる。
　また、第１登録部は、複数の第２情報を移転先ＤＢ４に登録する際に、移転先ブロックチェーン３に登録されたグループ単位のハッシュ値の移転ＴｘＩＤを、当該ハッシュ値に対応するグループに含まれる第２情報に付加してよい。これにより、参照データに対応するハッシュ値の取得を効率的に行なうことができる。
　さらに、第１取得部は、移転先ＤＢ４から、所定の移転ＴｘＩＤが付加された１以上の第２情報を取得し、第２取得部は、移転先ブロックチェーン３から、所定の移転ＴｘＩＤに対応するハッシュ値を取得する。また、検証部が、第１取得部が取得した１以上の第２情報をハッシュ化して得られるハッシュ値と、第２取得部が取得したハッシュ値とに基づき、移転先ＤＢ４から取得した１以上の第２情報の改ざん検証を行なってよい。これにより、移転先ブロックチェーン３及び移転先ＤＢ４における、データの改ざん検知を効率よく行なうことができる。
　また、参照部は、再起動後の移転元ブロックチェーン２から、第３登録部が登録した複数のトランザクションに含まれる第１情報に基づき第２情報を参照し、参照した第２情報よりも過去の第２情報が要求される場合、参照した第２情報のトランザクションに関連付けられた第３情報に基づき、移転先ＤＢ４から過去の第２情報を参照してよい。
　このように、移転元ブロックチェーン２を初期化して更新履歴群の最新値を登録し、データ参照時には、参照先を移転元ブロックチェーン２と、移転先ブロックチェーン３及び移転先ＤＢ４と、にブロックチェーンに基づき振り分けることにより、クライアントがデータの参照先を意識することなく参照できる。
　〔１－３〕一実施形態のハードウェア構成例
　図１４は、ブロックチェーンシステム１の機能を実現するコンピュータ１０のＨＷ（Hardware）構成例を示すブロック図である。ブロックチェーンシステム１の機能を実現するＨＷリソースとして、複数のコンピュータが用いられる場合は、各コンピュータが図１４に例示するＨＷ構成を備えてよい。
　図１４に示すように、コンピュータ１０は、ＨＷ構成として、例示的に、プロセッサ１０ａ、メモリ１０ｂ、記憶部１０ｃ、ＩＦ（Interface）部１０ｄ、Ｉ／Ｏ（Input / Output）部１０ｅ、及び読取部１０ｆを備えてよい。
　プロセッサ１０ａは、種々の制御や演算を行なう演算処理装置の一例である。プロセッサ１０ａは、コンピュータ１０内の各ブロックとバス１０ｉで相互に通信可能に接続されてよい。なお、プロセッサ１０ａは、複数のプロセッサを含むマルチプロセッサであってもよいし、複数のプロセッサコアを有するマルチコアプロセッサであってもよく、或いは、マルチコアプロセッサを複数有する構成であってもよい。
　プロセッサ１０ａとしては、例えば、ＣＰＵ、ＭＰＵ、ＧＰＵ、ＡＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡ等の集積回路（ＩＣ；Integrated Circuit）が挙げられる。なお、プロセッサ１０ａとして、これらの集積回路の２以上の組み合わせが用いられてもよい。ＣＰＵはCentral Processing Unitの略称であり、ＭＰＵはMicro Processing Unitの略称である。ＧＰＵはGraphics Processing Unitの略称であり、ＡＰＵはAccelerated Processing Unitの略称である。ＤＳＰはDigital Signal Processorの略称であり、ＡＳＩＣはApplication Specific ICの略称であり、ＦＰＧＡはField-Programmable Gate Arrayの略称である。
　メモリ１０ｂは、種々のデータやプログラム等の情報を格納するＨＷの一例である。メモリ１０ｂとしては、例えばＤＲＡＭ（Dynamic RAM）等の揮発性メモリが挙げられる。
　記憶部１０ｃは、種々のデータやプログラム等の情報を格納するＨＷの一例である。記憶部１０ｃとしては、ＨＤＤ（Hard Disk Drive）等の磁気ディスク装置、ＳＳＤ（Solid State Drive）等の半導体ドライブ装置、不揮発性メモリ等の各種記憶装置が挙げられる。不揮発性メモリとしては、例えば、フラッシュメモリ、ＳＣＭ（Storage Class Memory）、ＲＯＭ（Read Only Memory）等が挙げられる。
　図５に例示する台帳２２及び３２、ＤＢ４２、並びに、データ移転部５が有する記憶領域５０（図６参照）は、それぞれ、メモリ１０ｂ又は記憶部１０ｃが有する記憶領域の少なくとも一部が利用されてよい。
　また、記憶部１０ｃは、コンピュータ１０の各種機能の全部若しくは一部を実現するプログラム１０ｇ（トランザクション管理プログラム）を格納してよい。
　例えば、プロセッサ１０ａは、記憶部１０ｃに格納されたプログラム１０ｇをメモリ１０ｂに展開して実行することにより、プログラム１０ｇにより提供される、データ移転プロセス、データ登録プロセス、及びデータ参照プロセスの少なくとも１つを実行できる。また、ブロックチェーン制御部２１、ブロックチェーン制御部３１、及びＤＢ制御部４１の少なくとも１つの機能も、プログラム１０ｇにより提供されてよい。
　換言すれば、コンピュータ１０は、移転元ブロックチェーン２、移転先ブロックチェーン３、移転先ＤＢ４、データ移転部５、データ登録部６、及びデータ参照部７の少なくとも１つ、又は、種々の組み合わせによるトランザクション管理装置として動作できる。非限定的な一例としては、移転元ブロックチェーン２及びデータ移転部５が１台のコンピュータ１０により実現されてもよく、或いは、移転元ブロックチェーン２、データ移転部５、データ登録部６、及びデータ参照部７が１台のコンピュータ１０により実現されてもよい。また、移転先ブロックチェーン３及び移転先ＤＢ４がそれぞれ１台のコンピュータ１０により実現されてもよい。
　ＩＦ部１０ｄは、ネットワークとの間の接続及び通信の制御等を行なう通信ＩＦの一例である。例えば、ＩＦ部１０ｄは、ＬＡＮ（Local Area Network）、或いは、光通信（例えばＦＣ（Fibre Channel））等に準拠したアダプタを含んでよい。当該アダプタは、無線及び有線の一方又は双方の通信方式に対応してよい。例えば、プログラム１０ｇは、当該通信ＩＦを介して、ネットワークからコンピュータ１０にダウンロードされ、記憶部１０ｃに格納されてもよい。
　なお、ブロックチェーンシステム１が複数のコンピュータ１０により実現される場合には、コンピュータ１０間が上記ネットワークで接続されてもよい。
　Ｉ／Ｏ部１０ｅは、入力装置、及び、出力装置、の一方又は双方を含んでよい。入力装置としては、例えば、キーボード、マウス、タッチパネル等が挙げられる。出力装置としては、例えば、モニタ、プロジェクタ、プリンタ等が挙げられる。
　読取部１０ｆは、記録媒体１０ｈに記録されたデータやプログラムの情報を読み出すリーダの一例である。読取部１０ｆは、記録媒体１０ｈを接続可能又は挿入可能な接続端子又は装置を含んでよい。読取部１０ｆとしては、例えば、ＵＳＢ（Universal Serial Bus）等に準拠したアダプタ、記録ディスクへのアクセスを行なうドライブ装置、ＳＤカード等のフラッシュメモリへのアクセスを行なうカードリーダ等が挙げられる。なお、記録媒体１０ｈにはプログラム１０ｇが格納されてもよく、読取部１０ｆが記録媒体１０ｈからプログラム１０ｇを読み出して記憶部１０ｃに格納してもよい。
　記録媒体１０ｈとしては、例示的に、磁気／光ディスクやフラッシュメモリ等の非一時的なコンピュータ読取可能な記録媒体が挙げられる。磁気／光ディスクとしては、例示的に、フレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク、ＨＶＤ（Holographic Versatile Disc）等が挙げられる。フラッシュメモリとしては、例示的に、ＵＳＢメモリやＳＤカード等の半導体メモリが挙げられる。
　上述したコンピュータ１０のＨＷ構成は例示である。従って、コンピュータ１０内でのＨＷの増減（例えば任意のブロックの追加や削除）、分割、任意の組み合わせでの統合、又は、バスの追加若しくは削除等は適宜行なわれてもよい。例えば、コンピュータ１０において、Ｉ／Ｏ部１０ｅ及び読取部１０ｆの少なくとも一方は、省略されてもよい。
　なお、図示しないネットワークによって相互に通信可能に接続された複数のコンピュータ１０により構成されるＨＷ資源及びＮＷ（Network）資源によって、例えば、クラウドシステムとしてのブロックチェーンシステム１が構成されてもよい。
　この場合、ブロックチェーンシステム１が備える移転元ブロックチェーン２、移転先ブロックチェーン３、移転先ＤＢ４、データ移転部５、データ登録部６、及びデータ参照部７等のノードの各々は、複数のコンピュータ１０により構成されるＨＷ資源及びＮＷ資源を、論理的に（仮想的に）又は物理的に分割してノードに割り当てることにより実現されてよい。
　換言すれば、ブロックチェーンシステム１は、複数のコンピュータ１０により提供されるＨＷ資源及びＮＷ資源としての、プロセッサ資源（プロセッサ）、メモリ資源（メモリ）、記憶資源（記憶部）、ＩＦ資源（ＩＦ部）、を備える１つのトランザクション管理装置であると捉えてもよい。トランザクション管理装置（コンピュータ）としてのブロックチェーンシステム１は、スケールアウト処理によって、プロセッサ資源、メモリ資源、記憶資源、及びＩＦ資源を、特定の機能ブロックを実現するためのノードに割り当てたり、或いはノードへの割り当てを解放したりすることができる。
　また、クラウドシステムとしてのブロックチェーンシステム１においては、ブロックチェーンシステム１としての機能を実現するためのプログラム１０ｇを、複数のノードの各々における実行単位に分割し、分割したプログラムを複数のノードに分散して配置してもよい。なお、複数のノード（図５の機能ブロック２～７）は、複数の物理マシン、複数の仮想マシン（ＶＭ；Virtual Machine）、及び、１以上の物理マシン及び１以上の仮想マシンの組み合わせ、のいずれであってもよい。
　すなわち、プログラム１０ｇは、複数のノードに分散して配置されたとしても、ブロックチェーンシステム１の機能を、トランザクション管理装置（コンピュータ）又はトランザクション管理システムに実行させる１つのプログラムと捉えることができる。
　〔２〕その他
　上述した一実施形態に係る技術は、以下のように変形、変更して実施することができる。
　例えば、図５に示すブロックチェーンシステム１が備える各機能ブロックは、任意の組み合わせで併合してもよく、それぞれ分割してもよい。
　１　　ブロックチェーンシステム
　２　　移転元ブロックチェーン
　２０、３０　　ブロックチェーン
　２０ａ～２０ｃ、３０ａ～３０ｄ　　ブロック
　２１、３１　　ブロックチェーン制御部
　２１ａ、３１ａ　　送受信部
　２２、３２　　台帳
　４　　移転先データベース
　４１　　データベース制御部
　４１ａ、５３ａ　　データ送受信部
　４２　　データベース
　５　　データ移転部
　５１　　ブロックチェーン通信部
　５１ａ　　ブロック取得部
　５１ｂ　　トランザクション送受信部
　５２　　ブロックデータ処理部
　５２ａ　　データまとめ部
　５２ｂ　　データ圧縮部
　５３　　データベース通信部
　５０　　記憶領域
　５０ａ～５０ｅ　　更新履歴群
　６　　データ登録部
　６１、７２　　リクエスト送信部
　７　　データ参照部
　７１　　リクエスト先制御部
　７３　　改ざん検証部

Claims (20)

  1. 　第１情報及び第２情報が関連付けられたトランザクションを複数格納する第１のブロックチェーンについて、複数の前記トランザクションにおける複数の前記第２情報を、前記第１情報に基づくグループ単位でデータベースに登録する第１登録部と、
    　前記グループ単位で前記複数の第２情報をハッシュ化して得られるハッシュ値を、第２のブロックチェーンに登録する第２登録部と、を備える、
    トランザクション管理装置。
  2. 　前記グループは、同じ第１情報が関連付けられた第２情報どうしを所定条件に従ってまとめたグループである、
    請求項１に記載のトランザクション管理装置。
  3. 　前記所定条件は、前記グループに含める第２情報の数を、所定の数ごと、前記グループに含める第２情報の合計データサイズが所定のデータサイズ以下となる数ごと、及び、所定数のブロックに含まれる第２情報の数ごと、の少なくとも１つとすることを含む、
    請求項２に記載のトランザクション管理装置。
  4. 　前記第１登録部は、前記複数の第２情報を前記データベースに登録する際に、前記第２のブロックチェーンに登録された前記グループ単位のハッシュ値の登録位置情報を、当該ハッシュ値に対応するグループに含まれる第２情報に付加する、
    請求項１～３のいずれか１項に記載のトランザクション管理装置。
  5. 　前記データベースから、所定の登録位置情報が付加された１以上の第２情報を取得する第１取得部と、
    　前記第２のブロックチェーンから、前記所定の登録位置情報に対応するハッシュ値を取得する第２取得部と、
    　前記第１取得部が取得した前記１以上の第２情報をハッシュ化して得られるハッシュ値と、前記第２取得部が取得した前記ハッシュ値とに基づき、前記データベースから取得した前記１以上の第２情報の改ざん検証を行なう検証部と、を備える、
    請求項４に記載のトランザクション管理装置。
  6. 　前記第１登録部による前記登録後、且つ、前記第２登録部による前記登録後に、前記複数のトランザクションに含まれる前記第１情報と、前記第１情報に関連付けられた１以上の第２情報のうちの最新の第２情報と、前記１以上の第２情報のうちの前記最新の第２情報よりも過去の第２情報が前記データベースに存在することを示す第３情報と、を関連付けたトランザクションを、第３のブロックチェーンに登録する第３登録部、を備える、
    請求項１～５のいずれか１項に記載のトランザクション管理装置。
  7. 　前記第３登録部による前記登録後に、第１情報及び第２情報の新たな組み合わせが関連付けられたトランザクションの登録要求に応じて、前記第３登録部により登録された前記トランザクションに続けて、前記登録要求に係るトランザクションを前記第３のブロックチェーンに登録する第４登録部、を備える、
    請求項６に記載のトランザクション管理装置。
  8. 　前記第３のブロックチェーンから、前記第３登録部が前記登録した複数の前記トランザクションに含まれる前記第１情報に基づき前記第２情報を参照し、参照した前記第２情報よりも過去の第２情報が要求される場合、前記参照した第２情報のトランザクションに関連付けられた前記第３情報に基づき、前記データベースから前記過去の第２情報を参照する参照部、を備える、
    請求項６又は請求項７に記載のトランザクション管理装置。
  9. 　前記第３のブロックチェーンは、前記第１のブロックチェーンを初期化した結果のブロックチェーンである、
    請求項６～８のいずれか１項に記載のトランザクション管理装置。
  10. 　前記トランザクションに関連付けられた前記第１情報は、前記トランザクションの処理対象のキーであり、
    　前記トランザクションに関連付けられた前記第２情報は、前記トランザクションの処理により更新された、前記キーの値である、
    請求項１～９のいずれか１項に記載のトランザクション管理装置。
  11. 　第１情報及び第２情報が関連付けられたトランザクションを複数格納する第１のブロックチェーンについて、複数の前記トランザクションにおける複数の前記第２情報を、前記第１情報に基づくグループ単位でデータベースに登録し、
    　前記グループ単位で前記複数の第２情報をハッシュ化して得られるハッシュ値を、第２のブロックチェーンに登録する、
    処理をコンピュータに実行させる、トランザクション管理プログラム。
  12. 　前記グループは、同じ第１情報が関連付けられた第２情報どうしを所定条件に従ってまとめたグループである、
    請求項１１に記載のトランザクション管理プログラム。
  13. 　前記所定条件は、前記グループに含める第２情報の数を、所定の数ごと、前記グループに含める第２情報の合計データサイズが所定のデータサイズ以下となる数ごと、及び、所定数のブロックに含まれる第２情報の数ごと、の少なくとも１つとすることを含む、
    請求項１２に記載のトランザクション管理プログラム。
  14. 　前記複数の第２情報を前記データベースに登録する際に、前記第２のブロックチェーンに登録された前記グループ単位のハッシュ値の登録位置情報を、当該ハッシュ値に対応するグループに含まれる第２情報に付加する、
    処理を前記コンピュータ実行させる、請求項１１～１３のいずれか１項に記載のトランザクション管理プログラム。
  15. 　前記データベースから、所定の登録位置情報が付加された１以上の第２情報を取得し、
    　前記第２のブロックチェーンから、前記所定の登録位置情報に対応するハッシュ値を取得し、
    　前記取得した前記１以上の第２情報をハッシュ化して得られるハッシュ値と、前記第２のブロックチェーンから取得した前記ハッシュ値とに基づき、前記データベースから取得した前記１以上の第２情報の改ざん検証を行なう、
    処理を前記コンピュータに実行させる、請求項１４に記載のトランザクション管理プログラム。
  16. 　前記データベースに対する前記登録後、且つ、前記第２のブロックチェーンに対する前記登録後に、前記複数のトランザクションに含まれる前記第１情報と、前記第１情報に関連付けられた１以上の第２情報のうちの最新の第２情報と、前記１以上の第２情報のうちの前記最新の第２情報よりも過去の第２情報が前記データベースに存在することを示す第３情報と、を関連付けたトランザクションを、第３のブロックチェーンに登録する、
    処理を前記コンピュータに実行させる、請求項１１～１５のいずれか１項に記載のトランザクション管理プログラム。
  17. 　前記第３のブロックチェーンに対する前記登録後に、第１情報及び第２情報の新たな組み合わせが関連付けられたトランザクションの登録要求に応じて、前記登録された前記トランザクションに続けて、前記登録要求に係るトランザクションを前記第３のブロックチェーンに登録する、
    処理を前記コンピュータに実行させる、請求項１６に記載のトランザクション管理プログラム。
  18. 　前記第３のブロックチェーンから、前記登録した複数の前記トランザクションに含まれる前記第１情報に基づき前記第２情報を参照し、
    　参照した前記第２情報よりも過去の第２情報が要求される場合、前記参照した第２情報のトランザクションに関連付けられた前記第３情報に基づき、前記データベースから前記過去の第２情報を参照する、
    処理を前記コンピュータに実行させる、請求項１６又は請求項１７に記載のトランザクション管理プログラム。
  19. 　第１情報及び第２情報が関連付けられたトランザクションを複数格納する第１のブロックチェーンについて、複数の前記トランザクションにおける複数の前記第２情報を、前記第１情報に基づくグループ単位でデータベースに登録し、
    　前記グループ単位で前記複数の第２情報をハッシュ化して得られるハッシュ値を、第２のブロックチェーンに登録する、
    処理をコンピュータが実行する、トランザクション管理方法。
  20. 　前記グループは、同じ第１情報が関連付けられた第２情報どうしを所定条件に従ってまとめたグループである、
    請求項１９に記載のトランザクション管理方法。
PCT/JP2019/038699 2019-10-01 2019-10-01 トランザクション管理装置、トランザクション管理プログラム、及びトランザクション管理方法 WO2021064852A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2021550803A JPWO2021064852A1 (ja) 2019-10-01 2019-10-01
CN201980100757.9A CN114450686A (zh) 2019-10-01 2019-10-01 事务管理装置、事务管理程序和事务管理方法
EP19947813.2A EP4040323A4 (en) 2019-10-01 2019-10-01 TRANSACTION MANAGEMENT DEVICE, TRANSACTION MANAGEMENT PROGRAM AND TRANSACTION MANAGEMENT METHOD
PCT/JP2019/038699 WO2021064852A1 (ja) 2019-10-01 2019-10-01 トランザクション管理装置、トランザクション管理プログラム、及びトランザクション管理方法
US17/704,215 US20220215386A1 (en) 2019-10-01 2022-03-25 Transaction management device, non-transitory computer-readable recording medium having stored therein transaction management program, and transaction management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2019/038699 WO2021064852A1 (ja) 2019-10-01 2019-10-01 トランザクション管理装置、トランザクション管理プログラム、及びトランザクション管理方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/704,215 Continuation US20220215386A1 (en) 2019-10-01 2022-03-25 Transaction management device, non-transitory computer-readable recording medium having stored therein transaction management program, and transaction management method

Publications (1)

Publication Number Publication Date
WO2021064852A1 true WO2021064852A1 (ja) 2021-04-08

Family

ID=75337810

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/038699 WO2021064852A1 (ja) 2019-10-01 2019-10-01 トランザクション管理装置、トランザクション管理プログラム、及びトランザクション管理方法

Country Status (5)

Country Link
US (1) US20220215386A1 (ja)
EP (1) EP4040323A4 (ja)
JP (1) JPWO2021064852A1 (ja)
CN (1) CN114450686A (ja)
WO (1) WO2021064852A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11669772B2 (en) 2019-11-05 2023-06-06 Vmware, Inc. 3D printer device management using machine learning
US20220011743A1 (en) * 2020-07-08 2022-01-13 Vmware, Inc. Malicious object detection in 3d printer device management

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017170912A1 (ja) 2016-03-31 2017-10-05 株式会社ｂｉｔＦｌｙｅｒ トランザクション処理装置、トランザクション処理方法、及びそのためのプログラム
JP2018147016A (ja) 2017-03-01 2018-09-20 Kddi株式会社 検出システム、検出方法及び検出プログラム
WO2018204939A1 (en) * 2017-05-05 2018-11-08 Jeff Stollman Systems and methods for extending the utility of blockchains through use of related child blockchains
JP2018537022A (ja) 2015-10-14 2018-12-13 ケンブリッジ ブロックチェーン，エルエルシー デジタルアイデンティティを管理するためのシステム及び方法
US20190243572A1 (en) * 2018-02-02 2019-08-08 Bank Of America Corporation Blockchain architecture for optimizing system performance and data storage
US20190260579A1 (en) * 2016-08-30 2019-08-22 Workday, Inc. Secure storage decryption system
US20190287101A1 (en) * 2018-12-28 2019-09-19 Alibaba Group Holding Limited Parallel execution of transactions in a blockchain network

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018126344A1 (zh) * 2017-01-03 2018-07-12 华为技术有限公司 一种数据处理方法及相关设备
US10776361B2 (en) * 2017-04-07 2020-09-15 Salesforce.Com, Inc. Time series database search system
EP3740890A4 (en) * 2018-01-19 2022-01-12 Nasdaq, Inc. SYSTEMS AND METHODS FOR CERTIFYING AND VERIFYING DIGITAL CONTENT USING CRYPTOGRAPHY AND BLOCKCHAIN
US10698892B2 (en) * 2018-04-10 2020-06-30 Sap Se Order-independent multi-record hash generation and data filtering
US20200090795A1 (en) * 2018-09-14 2020-03-19 Htc Corporation Method and system for sharing privacy data based on smart contracts
KR20200088995A (ko) * 2019-01-16 2020-07-24 휴렛-팩커드 디벨롭먼트 컴퍼니, 엘.피. 화상 형성 장치에서 블록체인을 기반한 문서의 보안 및 무결성 검증
WO2019228550A2 (en) * 2019-08-20 2019-12-05 Alibaba Group Holding Limited Blockchain data storage based on shared nodes and error correction code

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018537022A (ja) 2015-10-14 2018-12-13 ケンブリッジ ブロックチェーン，エルエルシー デジタルアイデンティティを管理するためのシステム及び方法
WO2017170912A1 (ja) 2016-03-31 2017-10-05 株式会社ｂｉｔＦｌｙｅｒ トランザクション処理装置、トランザクション処理方法、及びそのためのプログラム
US20190260579A1 (en) * 2016-08-30 2019-08-22 Workday, Inc. Secure storage decryption system
JP2018147016A (ja) 2017-03-01 2018-09-20 Kddi株式会社 検出システム、検出方法及び検出プログラム
WO2018204939A1 (en) * 2017-05-05 2018-11-08 Jeff Stollman Systems and methods for extending the utility of blockchains through use of related child blockchains
US20190243572A1 (en) * 2018-02-02 2019-08-08 Bank Of America Corporation Blockchain architecture for optimizing system performance and data storage
US20190287101A1 (en) * 2018-12-28 2019-09-19 Alibaba Group Holding Limited Parallel execution of transactions in a blockchain network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4040323A4

Also Published As

Publication number Publication date
JPWO2021064852A1 (ja) 2021-04-08
CN114450686A (zh) 2022-05-06
EP4040323A4 (en) 2022-09-07
US20220215386A1 (en) 2022-07-07
EP4040323A1 (en) 2022-08-10

Similar Documents

Publication Publication Date Title
TW202101237A (zh) 基於雲端的資料保護服務之後處理
US9817710B2 (en) Self-describing data blocks stored with atomic write
US10467246B2 (en) Content-based replication of data in scale out system
US8352490B2 (en) Method and system for locating update operations in a virtual machine disk image
CN110045912B (zh) 数据处理方法和装置
US10127242B1 (en) Data de-duplication for information storage systems
CN111356996B (zh) 用于版本验证的系统和计算机实现的方法
US7937369B1 (en) Data mover discovery of object extent
JP6097880B2 (ja) ビザンチン故障耐性データ複製を行う方法およびシステム
JP6445049B2 (ja) ログの管理方法及び計算機システム
JP2007521528A (ja) ボリュームイメージを生成すること
US20220215386A1 (en) Transaction management device, non-transitory computer-readable recording medium having stored therein transaction management program, and transaction management method
US10452644B2 (en) Computer system, method for verifying data, and computer
US10346077B2 (en) Region-integrated data deduplication
JP6990055B2 (ja) 分散コンピューティングシステムにおけるデータをリカバリする方法およびシステム
CN114556320A (zh) 切换到最终一致的数据库副本
CN113553098A (zh) Flink SQL作业的提交方法、装置及计算机设备
US20200026463A1 (en) Method and system for accessing virtual machine state while virtual machine restoration is underway
JP5772527B2 (ja) データ管理システム及び情報処理装置
US20180225362A1 (en) Data processing system and data processing method
US11422733B2 (en) Incremental replication between foreign system dataset stores
US10956399B1 (en) Transaction pipelining in a journaled database
WO2015194027A1 (ja) 計算機システム、データ更新方法、および仮想化サーバ
CN117891794A (zh) 日志的生成方法、装置、终端设备及存储介质
JP2021184252A (ja) データ管理システム

Legal Events

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

Ref document number: 19947813

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021550803

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019947813

Country of ref document: EP

Effective date: 20220502