WO2020100602A1 - ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム - Google Patents

ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム Download PDF

Info

Publication number
WO2020100602A1
WO2020100602A1 PCT/JP2019/042658 JP2019042658W WO2020100602A1 WO 2020100602 A1 WO2020100602 A1 WO 2020100602A1 JP 2019042658 W JP2019042658 W JP 2019042658W WO 2020100602 A1 WO2020100602 A1 WO 2020100602A1
Authority
WO
WIPO (PCT)
Prior art keywords
block
transaction
value
block number
variable
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/JP2019/042658
Other languages
English (en)
French (fr)
Inventor
大喜 渡邊
達郎 石田
盛徳 大橋
滋 藤村
篤 中平
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Inc
Original Assignee
Nippon Telegraph and Telephone Corp
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 Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to US17/293,583 priority Critical patent/US12124475B2/en
Publication of WO2020100602A1 publication Critical patent/WO2020100602A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06F16/275—Synchronous replication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06F16/278—Data partitioning, e.g. horizontal or vertical partitioning
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • 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 technology for managing the history of a smart contract type blockchain.
  • a mechanism that can ensure reliability without the need for centralized management is becoming popular mainly in digital virtual currency Bitcoin.
  • this mechanism called blockchain, the reliability of the exchanged information is ensured by the process of consensus building within the distributed network, and the integrity is maintained by preventing fraud such as falsification and double use throughout the system. Be drunk
  • transaction information between participants is collected in units called “blocks”, and each block is linked in a string and managed in chronological order. Approval of new blocks is formed by consensus algorithms in distributed networks such as Proof Work. Approval of the new block indicates that the transactions recorded within the block have been agreed upon throughout the system.
  • the book of a series of transaction information managed using this block chain is called a "distributed ledger", and each terminal participating in the network holds the same distributed ledger.
  • blockchain-based technology has also been developed in which advanced script code is registered in the distributed ledger, and execution of the script code and agreement on the result can be agreed.
  • the blockchain infrastructure called Ethereum executes a script code with a transaction as an input, stores the execution result in a tree-structured key-value store (called a state DB), and also records the representative value of the store at that time in a block.
  • a state DB tree-structured key-value store
  • the script code registered on the block chain in this way and registered and executed in each terminal is called a "smart contract”.
  • each block is managed in association with the state DB of the smart contract at the time of the block (Non-Patent Document 1).
  • an external database such as RDBMS
  • drop all the data extracted from the blockchain into the external database and use it on the external database.
  • a method of constructing an index and searching / tracking desired data can be considered.
  • building and maintaining a search system using an external database requires high costs for general users.
  • the present invention has been made in view of the above problems, and an object of the present invention is to provide a technique that enables a data history to be easily traced on a block chain.
  • one aspect of the present invention is a block chain system including a user terminal and an approval terminal, wherein the user terminal issues a transaction for updating a value of a variable of a smart contract.
  • a transaction issuing unit is provided, and the approval terminal generates a block including the transaction and updates the value of the variable, and the block and the update block number of the block in which the value of the variable is updated.
  • the system includes a block generation unit that reflects the distributed ledger of the terminals of the system.
  • One aspect of the present invention is an approval terminal that approves a transaction in a blockchain system, a receiving unit that receives a transaction that updates the value of a variable of a smart contract, a block that includes the transaction, and a block that includes the transaction.
  • a block generation unit that updates the value and reflects the block and the updated block number of the block that updated the value of the variable in the distributed ledger of the terminals of the block chain system.
  • One aspect of the present invention is a user terminal in a blockchain system, in which a distributed ledger of a blockchain, a transaction issuing unit that issues a transaction for updating a value of a variable of a smart contract, and a distributed ledger of the variable
  • the value of the variable of the smart contract and the update block number of the block at the time point of the search block number are specified by obtaining the update block number of the block whose value is updated and designating the search block number calculated from the update block number.
  • a history search unit that acquires from the distributed ledger.
  • One aspect of the present invention is a history management method for managing a history of a block chain, wherein a user terminal performs a transaction issuing step of issuing a transaction for updating a value of a variable of a smart contract, and an approval terminal is A generating step of generating a block including a transaction and updating the value of the variable, the block, and an update block number of the block in which the value of the variable is updated, and a distributed ledger of terminals connected to a block chain network. And the synchronization step to be reflected in.
  • One aspect of the present invention is a smart contract registration program characterized by causing a computer to function as the approval terminal.
  • FIG. 1 It is a figure showing the whole block chain system composition concerning an embodiment of the present invention. It is a figure which shows the structure of a distributed ledger. It is a block diagram which shows the structure of a block issuing part. It is explanatory drawing explaining the setting method of the update block number of state DB. It is a sequence diagram which shows block generation and history search. It is a figure which shows an example of a transaction.
  • FIG. 1 is a diagram showing the overall configuration of the block chain system of this embodiment.
  • the blockchain of this embodiment is a smart contract type blockchain, and uses Ethereum, which is one of the blockchain-based technologies. Ethereum is an application development platform for using blockchain as a distributed ledger for recording state transitions. However, the present invention is not limited to Ethereum and may be used in a block chain other than Ethereum.
  • the blockchain system shown in FIG. 1 includes a user terminal 1 and an approval terminal 2. These terminals 1 and 2 are autonomously and decentrally connected to a block chain network 4 (hereinafter referred to as "network") which is a P2P network. In addition to the terminals 1 and 2 shown in the figure, a plurality of terminals are connected to the network 4. For example, a plurality of user terminals 1 and a plurality of approval terminals 2 may be connected.
  • the terminal connected to the network 4 includes a distributed ledger 11, a block chain control unit 12 and a transaction issuing unit 13, which will be described later, and mutually verifies data and transactions recorded in the distributed ledger 11 to maintain the system. ..
  • the user terminal 1 is a terminal (node) used by a user who uses the block chain and the smart contract.
  • the user terminal 1 includes a distributed ledger 11, a block chain control unit 12, a transaction issuing unit 13, and a history search unit 14.
  • the distributed ledger 11 stores the latest blockchain in a near real-time manner by gently synchronizing with all terminals connected to the network 4 via the blockchain control unit 12.
  • the distributed ledger 11 of this embodiment stores a block chain and a data set managed by the block chain.
  • the block chain control unit 12 maintains a block chain system in a distributed and autonomous manner in cooperation with terminals connected to the network 4.
  • the block chain control unit 12 accesses the distributed ledger 11 to read or update the block chain and the data set of the distributed ledger 11.
  • the transaction issuing unit 13 issues a transaction to the network 4.
  • the transaction issuing unit 13 issues a transaction for updating the value of the state (variable) of the smart contract.
  • the history search unit 14 acquires the update block number of the block in which the state value of the smart contract is updated from the distributed ledger 11 of its own, and specifies the search block number calculated from the update block number to specify the search block number.
  • the state value of the smart contract and the updated block number in the block at the time point are acquired from the distributed ledger 11.
  • the history search unit 14 accesses the distributed ledger 11 via the block chain control unit 12.
  • the approval terminal 2 is a terminal used by a verifier of a transaction called, for example, a miner, collects the transactions transmitted to the network 4, confirms the validity, and generates a block through the approval work.
  • the approval terminal 2 includes a distributed ledger 11, a block chain control unit 12, a transaction issuing unit 13, and a block issuing unit 15.
  • the distributed ledger 11, the block chain control unit 12, and the transaction issuing unit 13 of the approval terminal 2 are the same as the distributed ledger 11, the block chain control unit 12, and the transaction issuing unit 13 of the user terminal 1.
  • the block issuing unit 15 verifies the transaction issued on the network 4 and tries to generate a block according to a consensus algorithm (agreement algorithm) for block generation such as Proof of Work.
  • a consensus algorithm for block generation such as Proof of Work.
  • FIG. 2 is a configuration diagram showing a configuration of the block issuing unit 15 included in the approval terminal 2.
  • the block issuing unit 15 illustrated includes a consensus executing unit 151, a transaction verifying unit 152, and a block generating unit 153.
  • the consensus executing unit 151 executes calculations necessary for consensus (agreement) such as hash calculation.
  • consensus uses other consensus algorithms for block generation, such as Proof of Stake that uses the amount of coins in possession as a resource, PBFT that is a consensus algorithm for Byzantine failures, etc. May be.
  • the transaction verification unit 152 Upon receiving the transaction from the network 4, the transaction verification unit 152 verifies the transaction such as the validity of the electronic signature of the received transaction. ..
  • the block generation unit 153 collects transactions issued on the network 4 within a predetermined time to generate one block. That is, when the verification by the transaction verification unit 152 is successful, the block generation unit 153 generates a block including the transaction, and reflects the generated block in the distributed ledger 11 of all terminals connected to the network 4.
  • the block generation unit 153 of the present exemplary embodiment generates a block including a transaction that updates the value of the state (variable) of the smart contract, updates the value of the state, and updates the block and the value of the state.
  • the updated block number and the updated block number are reflected in the distributed ledger of the terminals in the blockchain system.
  • the block generation unit 153 updates the state DB, which is one of the data sets of the distributed ledger 11 of itself, based on the transaction that updates the value of the state of the smart contract, and updates the state DB of the updated state DB.
  • FIG. 3 shows the configuration of the distributed ledger 11 of each terminal.
  • the distributed ledger 11 of the present embodiment includes a block chain composed of a plurality of blocks 111, and a data set 112 managed corresponding to each block.
  • the block 111 has a block header 113, a transaction list 114, and the like.
  • a summary of the entire distributed ledger 11 at the time of the block is set.
  • a summary value (hash value of the state DB, hash value of the transaction set, etc.) of the data set 112 is set in the block header 113 as a snapshot of the data set 112 at a certain point. For example, when the data set is stored in a tree structure such as a Merkle tree, the root hash of the Merkle tree is set as the summary value.
  • the transaction list 114 is a list of transactions included in the block 111.
  • the use and purpose of the data set 112 are not limited.
  • the distributed ledger 11 shown in the figure includes a state DB and a transaction set DB as the data set 112.
  • State DB is a DB for managing the value or state of the state (variable) of the smart contract at the time of a certain block.
  • the state DB stores the bytecode of the smart contract.
  • information is recorded in the state DB in data units called tokens.
  • a token is a data structure represented by a smart contract, data that has at least parameters such as "token ID" and "owner's address”, and token transfer is managed on the blockchain by the owner's authority. Indicates. That is, the state DB of this embodiment stores the value of the state of the smart contract (for example, the address of the owner) for each token.
  • the block generation unit 153 of the approval terminal 2 associates, for each token, an updated block number, which is a block number of a block whose state value has been updated, with the updated state value. Is set.
  • the state DB functions as a Key-Value Store (KVS), and when identification information that uniquely specifies a token (for example, token ID) is input, the state value of the token and the update block number are output.
  • KVS Key-Value Store
  • identification information indicating the smart contract is added. Since the transaction can be transmitted in response to the identification information, the identification information of the smart contract is also called an address. The difference from remittance to the user's address is that when a transaction is sent to the smart contract address, the smart contract is executed.
  • Transaction set DB is a DB that shows the set of transactions at a certain block.
  • a set of transactions means a Merkle tree composed of all the transactions at the time of a block.
  • FIG. 4 is a schematic diagram for explaining the process of adding the update block number to the state value.
  • blocks up to # 26001 are registered in the distributed ledger 11 of each terminal.
  • the distributed ledger 11 of this embodiment holds blocks and state DBs in association with each other.
  • the state DB 51 of the block # 25768, the state DB 52 of the block # 25770, the state DB 53 of # 26000, and the state DB 54 of # 26001 are shown.
  • Each state DB shown in the figure has a token ID, an owner address, and an update block number for each token.
  • the token ID is used as the state key, but the state key is not limited to the token ID.
  • the token may be either a non-replaceable token (Non-Fungible Token) or a replaceable token (Fungible Token).
  • the owner address is a state (variable).
  • the owner address is set to the address of the owner of the token at the time of the corresponding block.
  • the update block number is set to the block number when the owner of the token is updated (changed).
  • block # 25769 the owner addresses of the token IDs: 0005 and 0006 are not updated due to the transaction included in the block.
  • the block numbers set in the update block numbers of the immediately preceding block # 25768 are continuously set in the update block numbers of the token IDs 0005 and 0006 of the state DB (not shown). Further, as the owner addresses of the token IDs: 0005 and 0006, the address set as the owner address of the immediately preceding block is continuously set.
  • the approval terminal 2 updates the owner addresses of the token IDs: 0005 and 0006, and also updates the update block number. Specifically, the approval terminal 2 sets the block number (# 25770) of the block to the updated block numbers of the token IDs: 0005 and 0006.
  • blocks # 25771 to # 25999 the owner addresses of the token IDs: 0005 and 0006 are not updated due to the transactions included in each block.
  • the block number set as the update block number of the immediately preceding block is continuously set. That is, in the state DBs of blocks # 25771 to # 25999, the same owner address and updated block number as those of the state DB 52 of # 25770 are continuously set for the token IDs: 0005 and 0006.
  • the approval terminal 2 updates the owner address of the token ID: 0005 and updates the update block number. Specifically, the approval terminal 2 sets the block number (# 26000) of the block to the token ID: 0005 update block number. For the token ID: 0006, the approval terminal 2 sets the same owner address and updated block number as the immediately preceding block.
  • the update block number is set together with the value of the state (owner address) for the key (token ID).
  • the user terminal 1 can acquire the updated block number that has been changed last by referring to the latest state DB 54. For example, when the token ID is 0006, # 25770 can be acquired.
  • the user terminal 1 specifies the search block number calculated from the update block number, and acquires the owner address and the update block number specified by the search block number.
  • the search block number is a block number obtained by subtracting 1 from the update block number.
  • the search block number # 25769 obtained by subtracting 1 from the update block number # 25770 is designated, and the owner address (user D) and the update block number (# 24991) set in the block number are specified.
  • the search cost can be significantly reduced and the change history of the state value can be easily acquired. ..
  • FIG. 5 is a sequence diagram showing block generation and history search according to this embodiment.
  • user A moves (transfers) a token to user B
  • user B searches the history of tokens received from user A.
  • the user terminal 1A of the user A generates a transaction for moving a predetermined token from the user A to the user B, and issues the transaction (S11). Specifically, the user terminal 1A broadcasts the transaction on the network 4. As a result, the transaction is propagated to all terminals connected to the network 4.
  • FIG. 6 is a diagram showing an example of the transaction of S11.
  • the illustrated transaction has a destination, a payment amount, data, and a digital signature.
  • the address of the smart contract is set in the destination.
  • the payment amount is set to the amount (fee) paid for executing the smart contract.
  • ⁇ Data is set with data that specifies executing a function that provides the function of "moving ownership of a specified token to a specified address" in the smart contract.
  • the token ID and the user B address are specified as arguments.
  • a signature value obtained by signing the transaction with the private key of the user A who is the issuer of the transaction is set.
  • the approval terminal 2 (block issuing unit 15) verifies (mines) the transaction transmitted in S11 (S12). Then, the approval terminal 2 combines the transaction with other transactions that have occurred within a predetermined time period to generate one block. The block is added to the block chain of its own distributed ledger 11 through mining of nonces (S13). When the approval terminal 2 succeeds in generating the block, the transaction transmitted in S11 is confirmed (approved).
  • the approval terminal 2 updates each DB of the data set of its own distributed ledger 11 based on the transaction of S11, and sets the hash value of each updated DB in the block header of the block to be generated.
  • the approval terminal 2 when updating the state DB of the data set, updates / changes the owner address of the token whose ownership has been transferred from the address of the user A to the address of the user B according to the transaction of S11. To do. Further, in the present embodiment, the approval terminal 2 stores the block number of the block whose owner address has been updated in the state DB. For example, as shown in the state DB 54 of FIG. 4, when the token ID of the token for transferring the ownership is 0005 and the generated block is # 26000, the approval terminal 2 sets the owner address to the address of the user B. Then, the update block number is set to the block number # 26000 in the state DB.
  • the approval terminal 2 sets the updated state DB hash value in the block header of the block to be generated.
  • S13 is a process performed by the terminal that succeeds in generating the block earliest among all the terminals connected to the network.
  • the block including the transaction transmitted in S11 is reflected in the distributed ledger 11 of all the terminals connected to the network 4 (S14, S15). That is, the block chain control units 12 of all terminals add a block including the transaction of S11 to the distributed ledger 11 held by itself. Further, the block chain control units 12 of all terminals update the state DB of the data set of their own distributed ledger 11 based on the transaction included in the block, as in the approval terminal 2.
  • the processing after S16 is performed. Specifically, the user terminal 1B inquires of its own distributed ledger about the owner address (state value) of the token in the latest block (S16), and the latest block owner address from the distributed ledger, The updated block number and is acquired (S17).
  • the user terminal 1B refers to the state DB 54 of its own distributed ledger, and the address of the user B as the owner, Get # 26000 as the update block number. Thereby, the user B can confirm that the owner of the current token is himself and that the owner is updated in the block # 26000.
  • the process of S18 and S19 is repeated. That is, the user terminal 1B calculates the search block number based on the update block number acquired in S17. Here, the block number obtained by subtracting “1” from the updated block number is set as the search block number. Then, the user terminal 1B designates the search block number, inquires the owner address of the token in the search block number to its own distributed ledger (S18), the owner address in the block designated from the distributed ledger, and the update block. And the number (S19).
  • the user terminal 1B specifies the block number # 259999 obtained by subtracting “1” from # 26000, and distributes it. Contact the ledger.
  • the state DB of # 259999 is not shown in FIG. 4, since the update of the token ID: 0005 is not performed from # 25771 to # 259999, the state of # 259999 related to the token ID: 0005 is the state of # 25770. It is the same as DB52. Therefore, the user terminal 1B refers to the state DB of the distributed ledger # 259999, and acquires the address of the user A as the owner address and # 25770 as the update block number. Thereby, the user B can confirm that the owner before the token ID: 0005 is the user A and that the owner change to the user A was performed in the block # 25770. it can.
  • the user terminal 1B repeats the processing of S18 and S19 when it wants to retrieve the past history before that. Thereby, the user B can efficiently follow the past history of the token.
  • the block chain system includes the user terminal 1 and the approval terminal 2, and the user terminal 1 issues a transaction for updating the value of the state (variable) of the smart contract.
  • the issuing terminal 13 is provided, and the approval terminal 2 generates a block including the transaction and updates the value of the state, and the block and the updated block number of the block in which the value of the state is updated.
  • the block generation unit 153 is included in the distributed ledger 11 of the terminal.
  • the update block number of the updated block is updated. Assign to a value.
  • the user can easily trace the data history on the distributed ledger (block chain) by referring to the updated block number without referring to all past blocks and transactions. That is, in this embodiment, the past history and transition of the value of the state of the smart contract can be easily acquired.
  • the traceability of the state is improved by adding the block number at the time of block generation (at the time of mining) to the value of the state to be traced as a change point of the value of the state in the state DB. be able to.
  • the user terminal 1 and the approval terminal 2 described above are, for example, a CPU (Central Processing Unit, processor), a memory, a storage (HDD: Hard Disk Drive, SSD: Solid State Drive), a communication device, and a communication device.
  • a general-purpose computer system including an input device and an output device can be used.
  • each function of each device is realized by the CPU executing a predetermined program loaded on the memory.
  • the CPU of the user terminal 1 in the case of the program for the user terminal 1 and the CPU of the approval terminal 2 in the case of the program for the approval terminal 2, respectively. It is realized by executing.
  • program for the user terminal 1 and the program for the approval terminal 2 can be stored in a computer-readable recording medium such as an HDD, SSD, USB memory, CD-ROM, DVD-ROM, MO, or the like. It can also be delivered via.
  • the present invention is not limited to the above-described embodiment, and various modifications can be made within the scope of the gist thereof.
  • the approval terminal 2 sets the block number of the block whose state value has been updated as the update block number in the state DB as the update block number.
  • the search block number may be set in the state DB. That is, the approval terminal 2 may set the search block number obtained by subtracting “1” from the update block number in the state DB instead of the update block number.
  • the user terminal 1 uses the search block number acquired from the distributed ledger as it is, without calculating the search block number from the update block number when acquiring the past history of the state (S18 of FIG. 5). Therefore, the past history can be traced.
  • the state DB of the present embodiment holds one state (owner address) as shown in FIG. 4 and one update block number corresponding to the state.
  • the state DB may hold a plurality of states. In this case, when each of a plurality of states is tracked, the state DB has an update block number for each state.

Landscapes

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

Abstract

ブロックチェーン上で、データの履歴を容易に追跡することを可能とする。利用者端末１と、承認端末２とを備えるブロックチェーンシステムであって、利用者端末１は、スマートコントラクトの変数の値を更新するトランザクションを発行するトランザクション発行部１３を備え、承認端末２は、トランザクションを含むブロックを生成するとともに変数の値を更新し、前記ブロックと、前記変数の値を更新した当該ブロックの更新ブロック番号とをブロックチェーンシステムの端末の分散台帳１１に反映させるブロック生成部１５３を備える。

Description

ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム
　本発明は、スマートコントラクト型のブロックチェーンの履歴を管理する技術に関する。
　中央集権的な管理を必要とせずに、信頼性を担保可能な仕組みがデジタル仮想通貨ビットコインを中心に普及しつつある。ブロックチェーンと呼ばれるこの仕組みにおいては、やり取りされる情報の信頼性が分散ネットワーク内の合意形成のプロセスによって担保され、かつ、改ざんや二重使用などの不正を系全体で防ぐことで健全性が保たれる。
　ブロックチェーンでは、参加者間の取引情報（トランザクション）が「ブロック」という単位でまとめられ、各ブロックは数珠つなぎとなって時系列順に管理される。新たなブロックの承認は、Proof of Workなどの分散ネットワークにおける合意アルゴリズムによって形成される。新たなブロックの承認は、ブロック内部に記録された取引が系全体で合意されたことを示す。
　このブロックチェーンを用いて管理される一連の取引情報の帳簿を「分散台帳」と呼び、ネットワークに参加する各端末は同一の分散台帳を保持している。近年では、分散台帳に高度なスクリプトコードを登録し、スクリプトコードの実行とその結果についても合意を得るブロックチェーン基盤技術も開発されている。例えばEthereumと呼ばれるブロックチェーン基盤は、トランザクションを入力としてスクリプトコードを実行し、その実行結果をツリー構造のキーバリュー型ストア（ステートDBと呼ぶ）に格納し、その時のストアの代表値もブロックに記録する分散台帳を持つ。このようにブロックチェーン上に登録され、各端末に登録および実行されるスクリプトコードは「スマートコントラクト」と呼ばれている。
　スマートコントラクト型のブロックチェーンは、各ブロックと、そのブロック時点でスマートコントラクトのステートDBとが対応づけて管理されている（非特許文献１）。
「JavaScript API・ethereum/wiki　Wiki・GitHub」、https://github.com/ethereum/wiki/wiki/JavaScript-API#contract-methods
　ブロックチェーンのデータ構造上、ブロック番号を指定し、そのブロック時点のステートを参照することは容易である。しかしながら、当該ブロックのステートの値が、過去のどのブロックでどのように遷移したのかを知ることは困難である。特に、情報のトレーサビリティを確保するという観点において、この問題は重要である。
　例えば、ステートのある値の変化を追跡する等の高度な探索・追跡を行う場合、RDBMS等の外部データベースを用意して、ブロックチェーンから抽出した全てのデータを外部データベースに落とし込み、外部データベース上でインデックスを構築し所望のデータを探索・追跡する方法が考えられる。しかしながら、外部データベースを用いた探索システムを構築および維持することは、一般ユーザにとって高いコストを要することになる。
　本発明は、上記課題を鑑みてなされたものであり、本発明の目的は、ブロックチェーン上で、データの履歴を容易に追跡することを可能とする技術を提供することにある。
　上記目的を達成するため、本発明の一態様は、利用者端末と、承認端末とを備えるブロックチェーンシステムであって、前記利用者端末は、スマートコントラクトの変数の値を更新するトランザクションを発行するトランザクション発行部を備え、前記承認端末は、前記トランザクションを含むブロックを生成するとともに前記変数の値を更新し、前記ブロックと、前記変数の値を更新した当該ブロックの更新ブロック番号とを前記ブロックチェーンシステムの端末の分散台帳に反映させるブロック生成部を備える。
　本発明の一態様は、ブロックチェーンシステムにおいてトランザクションを承認する承認端末であって、スマートコントラクトの変数の値を更新するトランザクションを受信する受信部と、前記トランザクションを含むブロックを生成するとともに前記変数の値を更新し、前記ブロックと、前記変数の値を更新した当該ブロックの更新ブロック番号とを前記ブロックチェーンシステムの端末の分散台帳に反映させるブロック生成部と、を備える。
　本発明の一態様は、ブロックチェーンシステムにおける利用者端末であって、ブロックチェーンの分散台帳と、スマートコントラクトの変数の値を更新するトランザクションを発行するトランザクション発行部と、前記分散台帳から前記変数の値が更新されたブロックの更新ブロック番号を取得し、前記更新ブロック番号から算出される検索ブロック番号を指定して、前記検索ブロック番号の時点のブロックにおける前記スマートコントラクトの変数の値および更新ブロック番号を、前記分散台帳から取得する履歴検索部と、を備える。
　本発明の一態様は、ブロックチェーンの履歴を管理する履歴管理方法であって、利用者端末は、スマートコントラクトの変数の値を更新するトランザクションを発行するトランザクション発行ステップを行い、承認端末は、前記トランザクションを含むブロックを生成し、前記変数の値を更新する生成ステップと、前記ブロックと、前記変数の値を更新した当該ブロックの更新ブロック番号とを、ブロックチェーンネットワークに接続された端末の分散台帳に反映させる同期ステップとを行う。
　本発明の一態様は、上記承認端末として、コンピュータを機能させることを特徴とするスマートコントラクト登録プログラムである。
　本発明によれば、ブロックチェーン上で、データの履歴を容易に追跡することを可能とする技術を提供することができる。
本発明の実施形態に係るブロックチェーンシステムの全体構成を示す図である。 分散台帳の構成を示す図である。 ブロック発行部の構成を示す構成図である。 ステートDBの更新ブロック番号の設定方法を説明する説明図である。 ブロック生成および履歴検索を示すシーケンス図である。 トランザクションの一例を示す図である。
　以下、本発明の実施の形態について、図面を参照して説明する。
　図１は、本実施形態のブロックチェーンシステムの全体構成を示す図である。本実施形態のブロックチェーンは、スマートコントラクト型ブロックチェーンであって、ブロックチェーン基盤技術の１つであるEthereumを用いる。Ethereumは、ブロックチェーンを、状態遷移を記録する分散台帳として用いるためのアプリケーション開発プラットフォームである。ただし、本願発明は、Ethereumに限定されるものではなく、Ethereum以外のブロックチェーンに用いてもよい。
　図１に示すブロックチェーンシステムは、利用者端末１と、承認端末２とを備える。これらの端末１、２は、P2Pネットワークであるブロックチェーンネットワーク４（以下、「ネットワーク」という）に自律分散的に接続される。なお、ネットワーク４には、図示する端末１、２の他にも、複数の端末が接続される。例えば、複数の利用者端末１、および、複数の承認端末２が接続されていてもよい。ネットワーク４に接続される端末は、後述する分散台帳１１、ブロックチェーン制御部１２およびトランザクション発行部１３を備え、分散台帳１１に記録されたデータおよびトランザクションを相互に検証し、系を維持している。
　利用者端末１は、ブロックチェーンおよびスマートコントラクトを利用する利用者が使用する端末（ノード）である。利用者端末１は、分散台帳１１と、ブロックチェーン制御部１２と、トランザクション発行部１３と、履歴検索部１４とを備える。
　分散台帳１１には、ブロックチェーン制御部１２を介して、ネットワーク４に接続された全ての端末と緩やかに同期することによって、リアルタイムに近い形で最新状態のブロックチェーンが記憶されている。本実施形態の分散台帳１１には、ブロックチェーンと、ブロックチェーンで管理されるデータ集合とが記憶されている。
　ブロックチェーン制御部１２は、ネットワーク４に接続された端末と自律分散的に協調してブロックチェーンの系を維持する。ブロックチェーン制御部１２は、分散台帳１１にアクセスし、分散台帳１１のブロックチェーンおよびデータ集合を読み出し、または、更新する。
　トランザクション発行部１３は、トランザクションをネットワーク４に発行する。本実施形態では、トランザクション発行部１３は、スマートコントラクトのステート（変数）の値を更新するトランザクションを発行する。
　履歴検索部１４は、自身の分散台帳１１からスマートコントラクトのステートの値が更新されたブロックの更新ブロック番号を取得し、更新ブロック番号から算出される検索ブロック番号を指定して、検索ブロック番号の時点のブロックにおけるスマートコントラクトのステートの値および更新ブロック番号を、分散台帳１１から取得する。履歴検索部１４は、ブロックチェーン制御部１２を介して、分散台帳１１にアクセスする。
　承認端末２は、例えばマイナーと呼ばれるトランザクションの検証者が使用する端末であって、ネットワーク４に送信されたトランザクションを収集し、正当性を確認後に、承認作業を通じてブロックを生成する。承認端末２は、分散台帳１１と、ブロックチェーン制御部１２と、トランザクション発行部１３と、ブロック発行部１５とを備える。承認端末２の分散台帳１１、ブロックチェーン制御部１２およびトランザクション発行部１３は、利用者端末１の分散台帳１１、ブロックチェーン制御部１２およびトランザクション発行部１３と同様である。
　ブロック発行部１５は、ネットワーク４上に発行されたトランザクションを検証し、Proof of Workなどのブロック生成のためのコンセンサスアルゴリズム（合意アルゴリズム）に従い、ブロックの生成を試みる。
　図２は、承認端末２が備えるブロック発行部１５の構成を示す構成図である。図示するブロック発行部１５は、コンセンサス実行部１５１と、トランザクション検証部１５２と、ブロック生成部１５３とを備える。
　コンセンサス実行部１５１は、ハッシュ演算などコンセンサス（合意）に必要な計算を実施する。コンセンサスアルゴリズムは、ビットコインで用いられているProof of Work以外にも、所持コイン量をリソースとしたProof of Stake、ビザンチン故障における合意アルゴリズムであるPBFTなど、その他のブロック生成のためのコンセンサスアルゴリズムを用いても良い。
　トランザクション検証部１５２は、ネットワーク４よりトランザクションを受け取ると、受け取ったトランザクションの電子署名の正当性などのトランザクションの検証を行う。　
　ブロック生成部１５３は、所定の時間内にネットワーク４上で発行されたトランザクションをまとめて１つのブロックを生成する。すなわち、ブロック生成部１５３は、トランザクション検証部１５２による検証に成功した場合、当該トランザクションを含むブロックを生成し、ネットワーク４に接続される全ての端末の分散台帳１１に生成したブロックを反映させる。
　本実施形態のブロック生成部１５３は、スマートコントラクトのステート（変数）の値を更新するトランザクションを含むブロックを生成するとともに前記ステートの値を更新し、前記ブロックと、前記ステートの値を更新した当該ブロックの更新ブロック番号とをブロックチェーンシステムの端末の分散台帳に反映させる。
　具体的には、ブロック生成部１５３は、スマートコントラクトのステートの値を更新するトランザクションに基づいて、自身の分散台帳１１のデータ集合の１つであるステートDBを更新し、更新後のステートDBのハッシュ値を、生成するブロックのブロックヘッダに設定する。すなわち、ブロック生成部１５３は、トランザクションに従って更新したステートの値と、更新を行った当該ブロックの更新ブロック番号とをステートDBに設定する。
　図３は、各端末の分散台帳１１の構成を示す。本実施形態の分散台帳１１は、複数のブロック１１１から構成されるブロックチェーンと、各ブロックに対応して管理されるデータ集合１１２とを備える。
　ブロック１１１は、ブロックヘッダ１１３、トランザクションリスト１１４などを有する。ブロックヘッダ１１３には、当該ブロックの時点の分散台帳１１全体の要約が設定される。図示する例では、ブロックヘッダ１１３には、データ集合１１２のある時点のスナップショットとして、データ集合１１２の要約値（ステートDBのハッシュ値、トランザクション集合のハッシュ値など）が設定される。例えば、データ集合がマークルツリーなどのツリー構造で格納されている場合、要約値として、マークルツリーのルートハッシュが設定される。トランザクションリスト１１４は、当該ブロック１１１に含まれるトランザクションのリストである。 
　データ集合１１２は、その用途および目的は限定されない。図示する分散台帳１１では、データ集合１１２として、ステートDBと、トランザクション集合DBとを備える。
　ステートDBは、あるブロックの時点でのスマートコントラクトのステート（変数）の値または状態を管理するためのDBである。また、ステートDBには、スマートコントラクトのバイトコードが格納される。本実施形態では、トークンというデータ単位でステートDBに情報が記録されている。ここでトークンとはスマートコントラクトで表現されるデータ構造であり、少なくとも「トークンID」と「所有者のアドレス」といったパラメータを持ち、トークンの移転が所有者の権限によってブロックチェーン上で管理されるデータを示す。すなわち、本実施形態のステートDBには、トークン毎に、スマートコントラクトのステート（例えば、所有者のアドレス等）の値が格納される。
　また、本実施形態のステートDBは、承認端末２のブロック生成部１５３により、トークン毎に、ステートの値が更新されたブロックのブロック番号である更新ブロック番号が更新後のステートの値と対応付けて設定される。ステートDBは、Key-Value Store(KVS)として機能し、トークンを一意に指定する識別情報（例えば、トークンID）が入力されると、当該トークンのステートの値および更新ブロック番号を出力する。
　なお、Ethereumでは、スマートコントラクトのバイトコードを、分散台帳１１（ステートDB）に登録すると、当該スマートコントラクトを示す識別情報が付与される。識別情報に対して、トランザクションを送信することができるため、スマートコントラクトの識別情報はアドレスとも呼ばれる。ユーザのアドレスへの送金との違いは、スマートコントラクトのアドレス宛てにトランザクションを送信すると、当該スマートコントラクトが実行されることである。
　トランザクション集合DBは、あるブロックの時点でのトランザクションの集合を示すDBである。トランザクションの集合は、あるブロックの時点での全てのトランザクションによって構成されるマークルツリーを意味する。
　次に、承認端末２が、ステートDBのステートの値を更新する際に、更新時点の更新ブロック番号を、当該ステートに付与する処理を説明する。
　図４は、更新ブロック番号をステートの値に付与する処理を説明するための模式図である。図示する例では、各端末の分散台帳１１には、＃26001番までのブロックが登録されているものとする。
　本実施形態の分散台帳１１には、前述のとおり、ブロックと、ステートDBとが対応付けて保持されている。図示する例では、#25768のブロックのステートDB５１と、#25770のブロックのステートDB５２と、#26000のステートDB５３と、#26001のステートDB５４とを示している。
　図示する各ステートDBは、トークン毎に、トークンIDと、所有者アドレスと、更新ブロック番号とを有する。本実施形態では、ステートのキーとしてトークンIDを用いるが、ステートのキーはトークンIDに限定されない。また、トークンは、代替不可能なトークン（Non-Fungible Token）であっても、代替可能なトークン（Fungible Token）であってもよい。
　所有者アドレスは、ステート（変数）である。所有者アドレスは、対応するブロックの時点における、トークンの所有者のアドレスが設定される。更新ブロック番号には、トークンの所有者が更新（変更）された際のブロック番号が設定される。
　例えば、#25768のステートDB５１を見ると、トークンID：0005については、所有者は利用者Ｃで、所有者が利用者Ｃに更新されたトランザクションを含む更新ブロック番号は#25007であることがわかる。また、トークンID：0006については、所有者は利用者Ｄで、所有者が利用者Ｄに更新されたトランザクションを含む更新ブロック番号は#24991であることがわかる。
　次に、ブロック#25769では、当該ブロックに含まれるトランザクションにより、トークンID：0005および0006の所有者アドレスは更新されないものとする。この場合、図示しないステートDBのトークンID：0005および0006の更新ブロック番号には、直前のブロック#25768の更新ブロック番号に設定されたブロック番号が引き続き設定されている。また、トークンID：0005、0006の所有者アドレスには、直前のブロックの所有者アドレスに設定されたアドレスが引き続き設定されている。
　そして、ブロック#25770に含まれるトランザクションにより、トークンID：0005および0006の所有者アドレスが更新される。この場合、承認端末２は、トークンID：0005および0006の所有者アドレスを更新するとともに、更新ブロック番号を更新する。具体的には、承認端末２は、当該ブロックのブロック番号（#25770）を、トークンID：0005および0006の更新ブロック番号に設定する。
　そして、ブロック#25771から＃25999では、各ブロックに含まれるトランザクションにより、トークンID：0005および0006の所有者アドレスは更新されないものとする。この場合、直前のブロックの更新ブロック番号に設定されたブロック番号が、引き続き設定されている。すなわち、ブロック#25771から＃25999のステートDBでは、トークンID：0005、0006については、#25770のステートDB５２と同じ所有者アドレスおよび更新ブロック番号が引き続き設定されている。
　そして、ブロック#26000に含まれるトランザクションにより、トークンID：0005の所有者アドレスが更新される。この場合、承認端末２は、トークンID：0005の所有者アドレスを更新するとともに、更新ブロック番号を更新する。具体的には、承認端末２は、当該ブロックのブロック番号（#26000）を、トークンID：0005更新ブロック番号に設定する。なお、トークンID：0006については、承認端末２は、直前のブロックと同じ所有者アドレスおよび更新ブロック番号を設定する。
　このように、本実施形態では、キー（トークンID）に対するステート（所有者アドレス）の値とともに、更新ブロック番号を設定する。これにより、本実施形態では、利用者端末１は、最新のステートDB５４を参照すると、最後に変更があった更新ブロック番号を取得することができる。例えば、トークンID：0006の場合は#25770を取得することができる。
　そして、利用者端末１は、更新ブロック番号から算出される検索ブロック番号を指定して、検索ブロック番号で指定された所有者アドレスおよび更新ブロック番号を取得する。例えば、検索ブロック番号は、更新ブロック番号から１減算したブロック番号とする。例えば、トークンID：0006の場合は更新ブロック番号#25770から１減算した検索ブロック番号＃25769を指定して当該ブロック番号に設定された所有者アドレス（利用者Ｄ）および更新ブロック番号（#24991）を取得する。このように、本実施形態では、ステートの値に変更があったブロックの付近のブロックのみを辿ることで、探索コストを大幅に低減し、容易にステートの値の変更履歴を取得することができる。
　図５は、本実施形態のブロック生成および履歴検索を示すシーケンス図である。
　図示する処理では、利用者Ａが利用者Ｂにトークンを移動（譲渡）し、利用者Ｂが利用者Ａから受け取ったトークンの履歴を探索する処理を示す。
　利用者Ａの利用者端末１Ａは、所定のトークンを利用者Ａから利用者Ｂに移動するためのトランザクションを生成し、を発行する（Ｓ１１）。具体的には、利用者端末１Ａはトランザクションをネットワーク４上にブロードキャストする。これにより、トランザクションは、ネットワーク４に接続された全ての端末に伝搬される。
　図６は、Ｓ１１のトランザクションの一例を示す図である。図示するトランザクションは、宛先と、支払額と、データと、電子署名とを有する。宛先には、スマートコントラクトのアドレスが設定される。支払額には、スマートコントラクトを実行するために支払われる金額（手数料）が設定される。
　データには、スマートコントラクト内の「指定されたアドレスへ所定のトークンの所有権を移動する」機能を提供する関数を実行することを指定するデータが設定される。なお、引数としてトークンのIDと利用者Ｂのアドレスを指定する。電子署名には、トランザクションの発行者である利用者Ａの秘密鍵で当該トランザクションが署名された署名値が設定される。
　そして、承認端末２（ブロック発行部１５）は、Ｓ１１で送信されたトランザクションを検証（マイニング）する（Ｓ１２）。そして、承認端末２は、当該トランザクションを、所定の時間内に発生した他のトランザクションとまとめて１つのブロックを生成する。当該ブロックは、ナンスのマイニングを経て自身の分散台帳１１のブロックチェーンに追加される（Ｓ１３）。承認端末２がブロックの生成に成功することにより、Ｓ１１で送信されたトランザクションが確定（承認）される。
　ここで、承認端末２は、Ｓ１１のトランザクションに基づいて、自身の分散台帳１１のデータ集合の各DBを更新し、更新後の各DBのハッシュ値を、生成するブロックのブロックヘッダに設定する。
　また、承認端末２は、データ集合のステートDBを更新する際に、Ｓ１１のトランザクションに従って、所有権を移動したトークンの所有者アドレスを、利用者Ａのアドレスから利用者Ｂのアドレスに更新・変更する。また、本実施形態では、承認端末２は、所有者アドレスを更新した当該ブロックのブロック番号を、ステートDBに記憶する。例えば、図４のステートDB５４に示すように、所有権を移動するトークンのトークンIDが0005で、生成するブロックが#26000の場合、承認端末２は、所有者アドレスに利用者Ｂのアドレスを設定し、更新ブロック番号に当該ブロックの番号#26000をステートDBに設定する。
　そして、承認端末２は、更新後のステートDBのハッシュ値を、生成するブロックのブロックヘッダに設定する。なお、Ｓ１３は、ネットワークに接続された全ての端末のうち、最も早くブロックの生成に成功した端末によって行われる処理である。
　そして、端末間のゆるやかな同期により、Ｓ１１で送信されたトランザクションを含むブロックが、ネットワーク４に接続された全ての端末の分散台帳１１に反映される（Ｓ１４、Ｓ１５）。すなわち、全ての端末のブロックチェーン制御部１２は、自身が保持する分散台帳１１に、Ｓ１１のトランザクションを含むブロックを追加する。また、全ての端末のブロックチェーン制御部１２は、承認端末２と同様に、ブロックに含まれるトランザクションに基づいて、自身の分散台帳１１のデータ集合のステートDBを更新する。
　次に、トークンの所有権となった利用者Ｂが、利用者Ａから譲渡されたトークンの過去の履歴を探索する場合、Ｓ１６以降の処理を行う。具体的には、利用者端末１Ｂは、最新のブロックにおける、前記トークンの所有者アドレス（ステートの値）を自身の分散台帳に問合せ（Ｓ１６）、分散台帳から最新のブロックの所有者アドレスと、更新ブロック番号とを取得する（Ｓ１７）。
　例えば、最新ブロックが図４に示す#26001で、問い合わせ対象のトークンIDが0005の場合、利用者端末１Ｂは、自身の分散台帳のステートDB５４を参照し、所有者として利用者Ｂのアドレスと、更新ブロック番号として#26000とを取得する。これにより、利用者Ｂは、現在のトークンの所有者が自分であり、また、所有者の更新が#26000のブロックで行われたことを確認することができる。
　そして、利用者Ｂは、トークンの過去の履歴を検索したい場合、Ｓ１８およびＳ１９の処理を繰り返し行う。すなわち、利用者端末１Ｂは、Ｓ１７で取得した更新ブロック番号に基づいて検索ブロック番号を算出する。ここでは、更新ブロック番号から「１」減算したブロック番号を検索ブロック番号とする。そして、利用者端末１Ｂは、検索ブロック番号を指定し、検索ブロック番号における、トークンの所有者アドレスを自身の分散台帳に問合せ（Ｓ１８）、分散台帳から指定したブロックにおける所有者アドレスと、更新ブロック番号とを取得する（Ｓ１９）。
　例えば、図４のステートDBにおいて、Ｓ１７取得した更新ブロック番号が#26000でトークンIDが0005の場合、利用者端末１Ｂは、#26000から「1」減算したブロック番号#259999を指定して、分散台帳に問い合わせる。#259999のステートDBは、図４に示していないが、トークンID：0005に対する更新は#25771から#259999までは行われていないため、トークンID：0005に関する#259999のステートは、#25770のステートDB５２と同じである。したがって、利用者端末１Ｂは、#259999の分散台帳のステートDBを参照し、所有者アドレスとして利用者Ａのアドレス、および、更新ブロック番号として#25770を取得する。これにより、利用者Ｂは、トークンID：0005の前の所有者が利用者Ａであり、また、利用者Ａへの所有者の変更が#25770のブロックで行われたことを確認することができる。
　そして、利用者端末１Ｂは、それ以前の過去の履歴を検索したい場合は、Ｓ１８およびＳ１９の処理を繰り返し行う。これにより、利用者Ｂは、トークンの過去の履歴を効率よく辿ることができる。
　以上説明した本実施形態では、利用者端末１と、承認端末２とを備えるブロックチェーンシステムであって、利用者端末１は、スマートコントラクトのステート（変数）の値を更新するトランザクションを発行するトランザクション発行部１３を備え、承認端末２は、前記トランザクションを含むブロックを生成するとともに前記ステートの値を更新し、前記ブロックと、前記ステートの値を更新した当該ブロックの更新ブロック番号とをブロックチェーンシステムの端末の分散台帳１１に反映させるブロック生成部１５３を備える。
　このように、本実施形態では、各端末の分散台帳１１のステートDBには、スマートコントラクトのステートの値が更新された時点で、更新のあったブロックの更新ブロック番号を、更新されたステートの値に付与する。これにより、利用者は、更新ブロック番号を辿ることで、過去の全てのブロックおよびトランザクションを参照することなく、分散台帳（ブロックチェーン）上で、データの履歴を容易に追跡することができる。すなわち、本実施形態では、スマートコントラクトのステートの値の過去の履歴および変遷を容易に取得することができる。
　また、本実施形態では、スマートコントラクトの利用者に対して、トレーサビリティを向上することができる。従来のステートDBでは、過去のどのブロックでステートの値が更新または変更されたかの情報は保持されていなく、ステートの値がどのブロックの時点で遷移したのかを利用者は知ることは容易ではない。従来では、変更のあったブロック番号を知るためには、全てのブロックまたはトランザクションを探索する必要があり、利用者にとって大きな負荷となっていた。これに対して、本実施形態では、ステートDBにステートの値の変化点として、ブロック生成時点（採掘時点）のブロック番号を追跡したいステートの値に付加することで、当該ステートのトレーサビリティを向上することができる。
　なお、上記説明した利用者端末１および承認端末２は、例えば、CPU（Central Processing Unit、プロセッサ）と、メモリと、ストレージ（HDD：Hard Disk Drive、SSD：Solid State Drive）と、通信装置と、入力装置と、出力装置とを備える汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、CPUがメモリ上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。例えば、利用者端末１および承認端末２の各機能は、利用者端末１用のプログラムの場合は利用者端末１のCPUが、承認端末２用のプログラムの場合は承認端末２のCPUが、それぞれ実行することにより実現される。
　また、利用者端末１用のプログラムおよび承認端末２用のプログラムは、HDD、SSD、USBメモリ、CD-ROM、DVD-ROM、MOなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。
　また、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
　例えば、本実施形態では、承認端末２は、更新ブロック番号として、ステートの値が更新されたブロックのブロック番号を更新ブロック番号としてステートDBに設定した。しかしながら、更新ブロック番号の代わりに、検索用ブロック番号をステートDBに設定することとしてもよい。すなわち、承認端末２は、更新ブロック番号の代わりに、更新ブロック番号から「１」減算した検索ブロック番号をステートDBに設定することとしてもよい。この場合、利用者端末１は、ステートの過去の履歴を取得する際（図５のＳ１８）に、更新ブロック番号から検索ブロック番号を算出することなく、分散台帳から取得した検索ブロック番号をそのまま用いて、過去の履歴を辿ることができる。
　また、本実施形態のステートDBは、図４に示すように１つのステート（所有者アドレス）を保持し、当該ステートに対応する１つの更新ブロック番号を保持することとした。しかしながら、ステートDBは複数のステートを保持することとしてもよい。この場合、複数のステートのそれぞれの追跡を行う場合、ステートDBは、各ステートごとに更新ブロック番号を備えるものとする。
　１　：利用者端末
　２　：承認端末
　１１：分散台帳
　１２：ブロックチェーン制御部
　１３：トランザクション発行部
　１４：履歴検索部
　１５：ブロック発行部
　１５１：コンセンサス実行部
　１５２：トランザクション検証部
　１５３：ブロック生成部
　４　：ブロックチェーンネットワーク
　　

Claims (8)

  1. 　利用者端末と、承認端末とを備えるブロックチェーンシステムであって、
    　前記利用者端末は、
    　　スマートコントラクトの変数の値を更新するトランザクションを発行するトランザクション発行部を備え、
    　前記承認端末は、
    　　前記トランザクションを含むブロックを生成するとともに前記変数の値を更新し、前記ブロックと、前記変数の値を更新した当該ブロックの更新ブロック番号とを前記ブロックチェーンシステムの端末の分散台帳に反映させるブロック生成部を備えること
    　を特徴とするブロックチェーンシステム。
  2. 　請求項１記載のブロックチェーンシステムであって、
    　前記分散台帳は、前記変数の値をトークン毎に格納するステートデータベースを備え、
    　前記ブロック生成部は、前記トークン毎に前記更新ブロック番号を前記ステートデータベースに設定すること
    　を特徴とするブロックチェーンシステム。
  3. 　請求項１または２記載のブロックチェーンシステムであって、
    　前記利用者端末は、
    　　自身の前記分散台帳から前記更新ブロック番号を取得し、前記更新ブロック番号から算出される検索ブロック番号を指定して、前記検索ブロック番号の時点のブロックにおける前記変数の値および更新ブロック番号を、自身の前記分散台帳から取得する履歴検索部を備えること
    　を特徴とするブロックチェーンシステム。
  4. 　請求項１または２記載のブロックチェーンシステムであって、
    　前記ブロック生成部は、前記更新ブロック番号の代わりに、前記更新ブロック番号から算出される検索ブロック番号を、前記ブロックチェーンシステムの端末の前記分散台帳に反映させること
    　を特徴とするブロックチェーンシステム。
  5. 　ブロックチェーンシステムにおいてトランザクションを承認する承認端末であって、
    　スマートコントラクトの変数の値を更新するトランザクションを受信する受信部と、
    　前記トランザクションを含むブロックを生成するとともに前記変数の値を更新し、前記ブロックと、前記変数の値を更新した当該ブロックの更新ブロック番号とを前記ブロックチェーンシステムの端末の分散台帳に反映させるブロック生成部と、を備えること
    　を特徴とする承認端末。
  6. 　ブロックチェーンシステムにおける利用者端末であって、
    　ブロックチェーンの分散台帳と、
    　スマートコントラクトの変数の値を更新するトランザクションを発行するトランザクション発行部と、
    　前記分散台帳から前記変数の値が更新されたブロックの更新ブロック番号を取得し、前記更新ブロック番号から算出される検索ブロック番号を指定して、前記検索ブロック番号の時点のブロックにおける前記スマートコントラクトの変数の値および更新ブロック番号を、前記分散台帳から取得する履歴検索部と、を備えること
    　を特徴とする利用者端末。
  7. 　ブロックチェーンの履歴を管理する履歴管理方法であって、
    　利用者端末は、
    　　スマートコントラクトの変数の値を更新するトランザクションを発行するトランザクション発行ステップを行い、
    　承認端末は、
    　　前記トランザクションを含むブロックを生成し、前記変数の値を更新する生成ステップと、
    　　前記ブロックと、前記変数の値を更新した当該ブロックの更新ブロック番号とを、ブロックチェーンネットワークに接続された端末の分散台帳に反映させる同期ステップとを行うこと
    　を特徴とする履歴管理方法。
  8. 　請求項５に記載の承認端末として、コンピュータを機能させることを特徴とする履歴管理プログラム。
PCT/JP2019/042658 2018-11-13 2019-10-30 ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム Ceased WO2020100602A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/293,583 US12124475B2 (en) 2018-11-13 2019-10-30 Blockchain system, approval terminal, user terminal, history management method, and history management program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018213190A JP7181455B2 (ja) 2018-11-13 2018-11-13 ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム
JP2018-213190 2018-11-13

Publications (1)

Publication Number Publication Date
WO2020100602A1 true WO2020100602A1 (ja) 2020-05-22

Family

ID=70731548

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/042658 Ceased WO2020100602A1 (ja) 2018-11-13 2019-10-30 ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム

Country Status (3)

Country Link
US (1) US12124475B2 (ja)
JP (1) JP7181455B2 (ja)
WO (1) WO2020100602A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
MX376445B (es) * 2018-11-30 2025-03-07 Advanced New Technologies Co Ltd Actualizaciones al contrato inteligente de cadena de bloques usando decision descentralizada.
WO2021132454A1 (ja) 2019-12-26 2021-07-01 シビラ株式会社 トランザクション委任方法、トランザクション委任システム、及びコンピュータプログラム
JP6797450B1 (ja) * 2020-06-04 2020-12-09 みんな電力株式会社 電力取引支援システム、電力取引支援方法及びプログラム
KR102561341B1 (ko) * 2021-11-12 2023-07-28 펜타시큐리티시스템 주식회사 엣지 클라우드 환경에서의 데이터 추적 장치 및 방법

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6362805B2 (ja) * 1983-10-28 1988-12-05

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3437002A4 (en) * 2016-03-31 2019-08-21 Clause, Inc. SYSTEM AND METHOD FOR THE PRODUCTION AND EXECUTION OF DATA-CONTROLLED LEGAL AGREEMENTS
KR101849917B1 (ko) * 2016-10-13 2018-05-31 주식회사 코인플러그 스마트 컨트랙트 기반의 인증서 서비스를 제공하는 방법 및 이를 이용한 서버
JP6931999B2 (ja) 2017-02-06 2021-09-08 株式会社日立製作所 信用度管理システムおよび信用度管理方法
JP6798604B2 (ja) * 2017-02-24 2020-12-09 日本電気株式会社 情報検証システム、情報検証装置、方法およびプログラム
US11888985B2 (en) * 2018-04-06 2024-01-30 Nippon Telegraph And Telephone Corporation Blockchain system, registration terminal, approval terminal, smart contract registration method, and smart contract registration program
US12136084B2 (en) * 2018-11-03 2024-11-05 International Business Machines Corporation Real-time monitoring of objects in blockchain networks
US11539527B2 (en) * 2019-05-29 2022-12-27 International Business Machines Corporation Peer node recovery via approximate hash verification

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6362805B2 (ja) * 1983-10-28 1988-12-05

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FENG, YAOKAI ET AL.: "Next-Generation Cryptocurrency Platform Ethereum and Its Evaluation, non-official translation (CSS 2015 Computer Security Symposium, 2015, 2015 proceedings and anti-malware research human resources development workshop, 2015 privacy workshop", 2015 IPSJ SYMPOSIUM SERIES, vol. 2015, 14 October 2015 (2015-10-14), pages 1151 - 1158 *
SATO, SEI, NEW IOT TECHNOLOGY, BLOCKCHAINS, OF COURSE, vol. 44, no. 8, 1 August 2018 (2018-08-01), pages 29 - 39 *

Also Published As

Publication number Publication date
US12124475B2 (en) 2024-10-22
JP2020080061A (ja) 2020-05-28
JP7181455B2 (ja) 2022-12-01
US20220004562A1 (en) 2022-01-06

Similar Documents

Publication Publication Date Title
JP7137077B2 (ja) ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム
JP7408619B2 (ja) ブロックチェーンネットワークにおいて大規模分散メモリプールを管理するためのコンピュータ実装されたシステム及び方法
US10986177B2 (en) Systems and methods of self-forking blockchain protocol
JP6939791B2 (ja) 掲示板情報管理システム
CA3055108C (en) System and method for parallel-processing blockchain transactions
CN112767158B (zh) 基于区块链的交易执行方法及装置、电子设备
US11303733B2 (en) Server apparatus, client apparatus, and data processing system
US20220108285A1 (en) Methods and Systems for Object Validated Blockchain Accounts
EP3438903B1 (en) Hierarchical network system, and node and program used in same
JP7157348B2 (ja) ブロックチェーンシステム、承認端末、スマートコントラクト登録方法、および、スマートコントラクト登録プログラム
WO2020100602A1 (ja) ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム
KR102139551B1 (ko) 유언장을 관리하는 서버 및 방법
JP7421443B2 (ja) データ移行方法、データ移行システム、およびノード
CN109493223A (zh) 一种记账方法及装置
CN110599331B (zh) 基于区块链的债务催收系统、方法、设备及存储介质
CN113326165B (zh) 基于区块链的数据处理方法、设备及计算机可读存储介质
JP2018101367A (ja) 情報処理システム、情報処理方法、プログラム及び情報処理装置
KR20220094899A (ko) 데이터 위변조 검증 방법 및 장치
KR102170031B1 (ko) 위치정보를 이용한 블록체인 거래인증방법, 기록매체 및 블록체인 시스템
KR20250044074A (ko) 토큰 증권에 대한 배당 처리 방법 및 시스템
WO2021005751A1 (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: 19885563

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19885563

Country of ref document: EP

Kind code of ref document: A1