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

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

Info

Publication number
WO2020203349A1
WO2020203349A1 PCT/JP2020/012289 JP2020012289W WO2020203349A1 WO 2020203349 A1 WO2020203349 A1 WO 2020203349A1 JP 2020012289 W JP2020012289 W JP 2020012289W WO 2020203349 A1 WO2020203349 A1 WO 2020203349A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
block
state
update
transaction
Prior art date
Application number
PCT/JP2020/012289
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 US17/600,874 priority Critical patent/US20220156733A1/en
Publication of WO2020203349A1 publication Critical patent/WO2020203349A1/ja

Links

Images

Classifications

    • 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/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • 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/23—Updating
    • G06F16/2358—Change logging, detection, and notification
    • 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/3825—Use of electronic 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/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/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

Definitions

  • the present invention relates to a technique for managing the history of a smart contract type blockchain.
  • a mechanism that can guarantee reliability without the need for centralized management is becoming widespread, centered on the digital virtual currency Bitcoin.
  • this mechanism called blockchain, the reliability of the information exchanged is guaranteed by the process of consensus building in the distributed network, and the soundness is maintained by preventing fraud such as falsification and double use throughout the system. Dripping.
  • transaction information between participants is organized in units called “blocks”, and each block is managed in chronological order as a string of beads.
  • Approval of new blocks is formed by consensus algorithms in distributed networks such as Proof of Work. Approval of the new block indicates that the transactions recorded inside the block have been agreed across the system.
  • a series of transaction information books managed using this blockchain is called a “distributed ledger", and each terminal participating in the network holds the same distributed ledger.
  • blockchain basic technology has also been developed in which advanced script code is registered in a distributed ledger and agreement is obtained regarding the execution of the script code and the result.
  • the blockchain infrastructure called Ethereum executes script code by inputting a transaction, stores the execution result in a key-value type store (called a state DB) with a tree structure, and records the representative value of the store at that time in the block.
  • a state DB key-value type store
  • the script code registered on the blockchain and registered and executed on each terminal in this way is called a "smart contract”.
  • the smart contract type blockchain is managed by associating each block with the state DB of the smart contract at the time of the block (Non-Patent Document 1).
  • Non-Patent Document 2 a technology for enhancing the traceability of the supply chain by using smart contracts using Ethereum, which is one of the blockchain platforms, is also being researched.
  • Non-Patent Document 2 For example, in tracking products in the supply chain, as shown in Non-Patent Document 2, it is possible to refer to the latest state at that time, but in order to refer to the past state, the block number is used as a key. You need to search for brute force.
  • Non-Patent Document 2 does not consider cases of more complicated supply chains. For example, the case where another product is completed by combining materials (combination) and the case where another content is produced from one digital content (division) are not considered. For such complex use cases, searching becomes more difficult, even with an external database.
  • the present invention has been made in view of the above problems, and an object of the present invention is to provide a technique capable of easily tracking a history of data on a blockchain.
  • one aspect of the present invention is a blockchain system including a user terminal and an approval terminal, and the distributed ledger of the blockchain system stores the state of a smart contract for each token.
  • the user terminal has a state database
  • the user terminal includes a transaction issuing unit for issuing a transaction for updating a token
  • the approval terminal has an updating unit for updating the token in the state database and a block containing the transaction.
  • a block generation unit that generates the block and reflects the updated state database in the distributed ledger
  • the update unit adds the update block of the block that updated the token to the token of the state database. Tracking data including a number and token information of the token is set.
  • One aspect of the present invention is an approval terminal that approves a transaction in a blockchain system, a distributed ledger having a state database that stores the state of a smart contract for each token, and a receiving unit that receives a transaction that updates a token.
  • the update unit includes an update unit that updates the token of the state database, and a block generation unit that generates a block including the transaction and reflects the block and the updated state database in the distributed ledger. Sets tracking data including the update block number of the block that updated the token and the token information of the token in the token of the state database.
  • One aspect of the present invention is a user terminal in a blockchain system, a distributed ledger having a state database that stores the state of a smart contract for each token, and an update block number of a block whose token has been updated from the state database.
  • a history search unit that acquires tracking data including the above, specifies a search block number calculated from the update block number, and acquires the state and tracking data of the token in the block at the time of the search block number from the state database. And, the tracking data includes the update block number and token information of the token.
  • One aspect of the present invention is a history management method for managing the history of the blockchain, in which the distributed ledger of the blockchain has a state database that stores the state of the smart contract for each token, and the user terminal has a state database.
  • a transaction issuance step for issuing a transaction for updating a token is performed, and the approval terminal generates an update step for updating the token in the state database and a block containing the transaction, and uses the block and the updated state database.
  • the block generation step to be reflected in the distributed ledger is performed, and the update step adds tracking data including the update block number of the block that updated the token and the token information of the token to the token of the state database.
  • One aspect of the present invention is a history management program characterized in that a computer functions as the approval terminal.
  • FIG. 1 is a diagram showing an overall configuration of the blockchain system of the present embodiment.
  • the blockchain of this embodiment is a smart contract type blockchain and uses Ethereum, which is one of the blockchain basic technologies. Ethereum is an application development platform for using the blockchain as a distributed ledger for recording state transitions.
  • the present invention is not limited to Ethereum, and may be used for blockchains 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 decentralizedly connected to the blockchain 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 blockchain control unit 12, and a transaction issuing unit 13, which will be described later, and mutually verifies the 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 a blockchain and a smart contract.
  • the user terminal 1 includes a distributed ledger 11, a blockchain control unit 12, a transaction issuing unit 13, and a history search unit 14.
  • the distributed ledger 11 stores the latest blockchain in a form close to real time by gently synchronizing with all terminals connected to the network 4 via the blockchain control unit 12.
  • the distributed ledger 11 of the present embodiment stores a blockchain and a data set managed by the blockchain.
  • the blockchain control unit 12 maintains the blockchain system in an autonomous and decentralized cooperation with the terminals connected to the network 4.
  • the blockchain control unit 12 accesses the distributed ledger 11 and reads or updates the blockchain 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 token.
  • the transaction issuing unit 13 issues a transaction for updating the value of the token state, a transaction for combining a plurality of tokens, a transaction for dividing the token, and the like.
  • the history search unit 14 acquires tracking data including the update block number of the block whose token has been updated from the state DB of its own distribution ledger 11, specifies the search block number calculated from the update block number, and specifies the search block. Get the token state and tracking data in the block at the time of the number from the state DB.
  • the history search unit 14 accesses the distributed ledger 11 via the blockchain control unit 12.
  • the approval terminal 2 is a terminal used by a transaction verifier called a minor, for example, and collects transactions transmitted to the network 4, confirms their validity, and then generates a block through approval work.
  • the approval terminal 2 includes a distributed ledger 11, a blockchain control unit 12, a transaction issuing unit 13, and a block issuing unit 15.
  • the distributed ledger 11, blockchain control unit 12, and transaction issuing unit 13 of the approval terminal 2 are the same as the distributed ledger 11, blockchain control unit 12, and 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 generating a block such as Proof of Work.
  • a consensus algorithm an algorithm for generating a block such as Proof of Work.
  • FIG. 2 is a configuration diagram showing the configuration of the block issuing unit 15 included in the approval terminal 2.
  • the illustrated block issuing unit 15 includes a consensus execution unit 151, a transaction verification unit 152, a block generation unit 153, and an update unit 154.
  • the consensus execution unit 151 performs calculations necessary for consensus (agreement) such as hash calculation.
  • consensus uses other consensus algorithms for block generation, such as Proof of Stake, which uses the amount of coins in possession as a resource, and PBFT, which is a consensus algorithm for Byzantine failures. You may.
  • the transaction verification unit 152 When the transaction verification unit 152 receives a transaction from the network 4, it verifies the transaction such as the validity of the electronic signature of the received transaction.
  • the block generation unit 153 collectively generates one block by collecting transactions issued on the network 4 within a predetermined time. That is, when the block generation unit 153 succeeds in the verification by the transaction verification unit 152, the block generation unit 153 generates a block including the transaction, and reflects the generated block in the distributed ledger 11 of all the terminals connected to the network 4.
  • the block generation unit 153 of the present embodiment generates a block including a transaction for updating the token, and reflects the block and the state DB updated by the update unit 154 in the distributed ledger 11. Further, the block generation unit 153 sets the hash value of the updated state DB in the block header of the block to be generated.
  • the update unit 154 updates the state DB, which is one of the data sets of its own distribution ledger 11, based on the transaction for updating the token.
  • the update unit 154 sets the token of the state DB with tracking data including the update block number of the block that updated the token and the token information of the token.
  • the token information of the present embodiment includes the token ID and the address of the token smart contract.
  • the update unit 154 sets the block number of the block that generated the combined token, the token ID of the plurality of tokens of the combined source, and the address of the smart contract as tracking data in the combined token that combines the plurality of tokens. .. In addition, the update unit 154 sets the block number of the block that generated the split token, the token ID of the token of the split source, and the address of the smart contract in the split token as tracking data.
  • the update unit 154 sets a consumption flag indicating that the tokens of the combination source of the state DB or the tokens of the division source have been consumed.
  • FIG. 3 shows the configuration of the distributed ledger 11 of each terminal.
  • the distributed ledger 11 of the present embodiment includes a blockchain 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.
  • the block header 113 is set with a summary value of the data set 112 (hash value of the state DB, hash value of the transaction set, etc.) as a snapshot of the data set 112 at a certain point in time.
  • the data set is stored in a tree structure such as a Merkle tree
  • the root hash of the Merkle tree is set as a 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 is not limited.
  • the distributed ledger 11 shown in the figure includes a state DB and a transaction set DB as the data set 112.
  • the state DB is a DB for managing the value or state of the state of the smart contract at the time of a certain block.
  • the bytecode of the smart contract is stored in the state DB.
  • information is recorded in the state DB in units of data called tokens.
  • the token is a data structure represented by a smart contract, and indicates data managed on the blockchain. That is, the state DB of the present embodiment stores the state of the smart contract for each token.
  • tracking data including the update block number of the block in which the token is updated is set for each token by the update unit 154 of the approval terminal 2.
  • the state DB functions as a key-value store (KVS), and when identification information (for example, token ID) that uniquely specifies a token is input, the state value and tracking data of the token are output.
  • KVS key-value store
  • identification information indicating the smart contract is given. Since transactions can be sent to the identification information, the identification information of the smart contract is also called an address. The difference from sending money to a user's address is that when a transaction is sent to the address of the smart contract, the smart contract is executed.
  • the transaction set DB is a DB that shows a set of transactions at the time of a certain block.
  • a set of transactions means a Merkle tree composed of all transactions at the time of a block.
  • FIG. 4 is an example of a transition diagram showing the transition of tokens in this embodiment.
  • the token of this embodiment is a token that can not only update the state but also divide the token and combine the tokens.
  • Token division is to divide one token into multiple tokens. To divide the token, the token of the division source is divided to generate multiple new tokens, and the token of the division source is consumed, or a part of the token of the division source is cut out into a new token and the division source is divided. Tokens may only be partially consumed and survive. Token combination is to combine multiple tokens into one token.
  • DAG Directed acyclic graph
  • the tracking data of each token is represented by Si (update block number, token ID, contract address).
  • Si update block number, token ID, contract address
  • the update block number is "1699”
  • the token ID is "5"
  • the contract address is "0xA6214 ".
  • the token of S4 is a token divided from the token of S2.
  • the S6 token is a token that is a combination of the S5 token and the S3 token.
  • token updates include not only state updates, but also binding and splitting with other tokens. Therefore, the tracking data of the present embodiment includes the update block number of the block at the time of updating the token, the token ID, and the address of the smart contract (hereinafter, “contract address”).
  • token update three cases of state update, token combination, and token division will be explained below.
  • FIG. 5 is a schematic diagram for explaining a process of assigning tracking data to a token (or state) when updating a token state (state, variable). In the illustrated example, updating the state of a wood token will be described in the process of making furniture from wood.
  • FIG. 5 shows the state tables 51A and 51B of the token management contract held in the state DB.
  • a token management contract is a smart contract that manages timber tokens.
  • the state table 51A is a state table of the block (# 24768).
  • the state table 51B is a state table of the block (# 25007).
  • the state tables 51A and 51B have a token ID, state data, a consumption flag, and tracking data 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 a non-substitutable token (Non-FungibleToken) or a substitutable token (FungibleToken).
  • the state data is data indicating the state, and in the illustrated example, the owner address and the number of lots are included.
  • the owner address is set to the address of the token owner at the time of the corresponding block. In the number of lots, the unit of manufacturing or ordering the object (here, wood) indicated by the token is set.
  • the Consumed flag is a flag indicating whether or not the token has been consumed. If the tokens are combined or split, the original token will be consumed and the consumption flag will be True (consumed). If the token is not combined and split, the token is not consumed and the consumption flag is False.
  • Tracking data is data for tracking the history of tokens (tracking data).
  • the tracking data of this embodiment includes an update block number, a token ID, and a contract address.
  • the block number for which the state data has been updated is set in the update block number.
  • the block number of the updated block is set in the update block number.
  • the state data of token ID: 1005 is tracked with the owner "0x13ae ", the number of lots "5", and the consumption flag "False” (unconsumed).
  • the data has an update block number of "23027", a token ID of "1005", and a contract address of "0xA6214 ".
  • the state data of token ID: 1005 shall not be updated by the transactions included in these blocks.
  • the approval terminal 2 continues to set the state data, consumption flag, and tracking data of the state table of the immediately preceding block to the token ID: 1005 in each state table of blocks # 24769 to # 25006 (not shown). That is, the data of the token ID: 1005 in each state table of the blocks # 24769 to # 25006 is the same as the data of the token ID: 1005 of the state table 51A of the block # 24768.
  • the state data (owner address, number of lots) of token ID: 1005 is updated by the transaction included in block # 25007.
  • the approval terminal 2 updates the state data of the token ID: 1005 and also updates the tracking data. Specifically, the approval terminal 2 sets the block number (# 25007) of the block as the update block number. Further, the approval terminal 2 sets the updated token ID (1005) and the updated token contract address (0xA6214 ...) In the tracking data.
  • tracking data is set together with the state (state data) for the key (token ID).
  • the user terminal 1 can acquire tracking data indicating the block in which the latest update has occurred by referring to the state table of the latest block # 25009. For example, in the case of token ID: 1005, # 25007 can be obtained as the update block number.
  • the user terminal 1 specifies the search block number calculated from the update block number, and acquires the update block number of the state data and the tracking data specified by the search block number.
  • the search block number is a block number obtained by subtracting 1 from the update block number.
  • token ID: 1005 the search block number # 25006 obtained by subtracting 1 from the update block number # 25007 is specified, and the update block number (# 23027) of the state data and tracking data set in the block number is acquired.
  • the search cost can be significantly reduced and the change history of the state value can be easily obtained by tracing only the blocks in the vicinity of the block in which the state value has been changed. ..
  • FIG. 6 is a schematic diagram for explaining a process of assigning tracking data to tokens (or states) when a plurality of tokens are combined.
  • a combination of a wood token and an adhesive token to generate a furniture token will be described.
  • the points different from the above-mentioned "1. State update" will be mainly described.
  • the state DB manages the token state for each smart contract.
  • 6 and 7 show the wood token management contract state tables 61A and 61B, the adhesive token management contract state tables 62A and 62B, and the furniture token management contract state tables 63.
  • State tables 61A and 61B are state tables of block # 25768.
  • the state tables 61B, 62B, and 63 are state tables of block # 25999.
  • the state table has a token ID, state data, consumption flags, and tracking data for each token.
  • the state data of token ID: 1005 is tracked with the owner "0x92be ", the number of lots "10", and the consumption flag "False” (unconsumed).
  • the data has an update block number of "25007”, a token ID of "1005", and a contract address of "0xA6214 ".
  • the state data of token ID: 0177 is that the owner is "0x12ac ", the lot number is “100”, the consumption flag is "False” (unconsumed), and the tracking data.
  • the update block number is "10283”, the token ID is "0177”, and the contract address is "0xBE823 ".
  • the data of token ID: 0177 in each state table of blocks # 25769 to # 25998 is the same as the data of token ID: 0177 of state table 61B of block # 25768.
  • the token of the state table 61A (ID: 1005) and the token of the state table 62A (ID: 0177) are combined to generate the furniture token.
  • the approval terminal 2 generates data of a new furniture token that combines the wood token and the adhesive token, and sets the data in the adhesive state table 63 of the block # 25999. Specifically, the approval terminal 2 sets a predetermined ID: 0016 for the token ID of the furniture token, sets a value specified in the transaction for the state data, and sets the consumption flag to "False" (unconsumed). ) Is set, and two pieces of information, a wood token (ID: 1005) and an adhesive token (ID: 0177), are set in the tracking data.
  • the approval terminal 2 has the update block number (# 25999) of the block that generated the furniture token, the token ID (1005) of the wood token, and the contract address of the wood token (0xA6214. ⁇ ⁇ ) And set.
  • the approval terminal 2 has the update block number (# 25999) of the block that generated the furniture token, the token ID (0177) of the adhesive token, and the contract address (0xBE823) of the adhesive token. ⁇ ⁇ ) And is set.
  • the approval terminal 2 updates the state tables 61B and 62B of the token of the binding source of block # 25999. As shown in FIG. 7, the approval terminal 2 updates the consumption flag of the binding source wood token (ID: 1005) of the state table 61B from “False” (unconsumed) to “True” (consumed). Similarly, the approval terminal 2 updates the consumption flag of the adhesive token (ID: 0177) of the binding source of the state table 62B from “False” to “True”. When the tokens are combined, the tokens from which they are combined are consumed, and the consumption flag becomes "True”. The combined token (furniture token) belongs to a smart contract different from the token of the combined source and has a different token ID.
  • the approval terminal 2 sets the token information of the consumption destination (combination destination) in the consumption flag.
  • the token information includes a contract address and a token ID.
  • the approval terminal 2 may update the update block number of the tracking data to the consumed (combined) block number.
  • the consumption flag is updated for the update block number of the tracking data of the binding source wood token (ID: 1005) of the state table 61B and the binding source adhesive token (ID: 0177) of the state table 62B.
  • the block number (# 25999) is set.
  • FIG. 8 is a schematic diagram for explaining a process of assigning tracking data to a state value in token division.
  • a part of the performance right is cut out from the copyright of the content and the copyright is divided will be described.
  • the points different from the above-mentioned "1. Token update” and "2. Token combination” will be mainly described.
  • the state DB corresponding to each block has the state tables 81A and 81B of the token management contract that manages the "copyright" token and the state table 82 of the token management contract that manages the "play right” token. Shown.
  • the state table 81A is a state table of block # 25768.
  • State tables 81B and 82 are state tables of block # 25999.
  • the state table has a token ID, state data, consumption flags, and tracking data for each token.
  • the state data of token ID: 40 in the state table 81A shall not be updated by the transactions included in these blocks.
  • the approval terminal 2 continues to set the token ID: 40 of the state table of the immediately preceding block to the token ID: 40 of each state table of blocks # 25769 to # 25998 (not shown). That is, the data of token ID: 40 in each state table of blocks # 25769 to # 25998 is the same as the data of token ID: 40 in the state table 81A of block # 25768.
  • the approval terminal 2 sets a predetermined ID: 99 for the token ID of the performance right token, sets the value specified in the transaction for the state data, and sets the consumption flag to "False” (not yet). (Consumption) is set, and the information of the copyright token (ID: 40) of the division source is set in the tracking data.
  • the approval terminal 2 has the update block number (# 25999) of the block that generated the performance right token, the token ID (40) of the copyright token, and the contract address (0xB7342 ...) of the copyright token. Is set as tracking data.
  • the approval terminal 2 updates the consumption flag of the copyright token (ID: 40) of the division source of the state table 81B to "True (partially consumed)". Further, when the consumption flag is updated to "True (partially consumed)", the approval terminal 2 sets the token information of the consumption destination (division destination) in the consumption flag and associates it with the consumption destination.
  • the token information includes a contract address and a token ID.
  • FIG. 9 is a sequence diagram showing block generation and history search of the present embodiment.
  • the illustrated process shows a process in which user A issues a transaction for updating tokens (including joining and splitting), and user B searches for the history of tokens updated by user A.
  • User terminal 1A of user A generates, for example, a transaction for moving a predetermined token from user A to user B, and issues (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. 10 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.
  • a smart contract address (contract address) is set as the destination.
  • the amount to be paid (commission) for executing the smart contract is set in the payment amount.
  • data that specifies to execute a function that provides a function of "transferring ownership of a predetermined token to a specified address" in a smart contract is set in the data.
  • a signature value in which the transaction is signed 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 to generate one block. The block is added to the blockchain of its own distributed ledger 11 through nonce mining (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 distribution 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 updates the designated token according to the transaction of S11. That is, the approval terminal 2 changes the state data of the token, combines the tokens, or divides the tokens. Further, in the present embodiment, the approval terminal 2 stores tracking data including the block number, token ID, and contract address of the block whose token has been updated in the state DB.
  • the approval terminal 2 sets the hash value of the updated state DB 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 blockchain control unit 12 of all terminals adds a block including the transaction of S11 to the distributed ledger 11 held by itself. Further, the blockchain control unit 12 of all terminals updates the state DB of the data set of its own distribution ledger 11 based on the transaction included in the block, similarly to the approval terminal 2.
  • the processing after S16 is performed. Specifically, the user terminal 1B queries its own distributed ledger for the state data of the token in the latest block (S16), and acquires the state data of the latest block and tracking data from the distributed ledger. (S17).
  • the user terminal 1B refers to the state DB51B of its own distributed ledger, and sets the state data and the update block number # 25007. Get tracking data and include. As a result, the user B can confirm the value of the current token state and that the token has been updated in the block of # 25007.
  • the user B when the user B wants to search the past history of the token, the user B repeats the processes from S18 to S20. That is, the user terminal 1B acquires the search block number and the contract address and token ID of the token to be searched from the tracking data of S17 (S18).
  • the user terminal 1B calculates the search block number based on the acquired update block number.
  • the block number obtained by subtracting "1" from the update block number is used as the search block number.
  • the user terminal 1B specifies the search block number, the contract address, and the token ID, queries the data of the specified token in the search block number to its own distribution ledger (S19), and specifies in the specified block.
  • the state data of the token and the tracking data are acquired from the distributed ledger (S20).
  • the user terminal 1B specifies the search block number # 25006 obtained by subtracting "1" from # 25007. Contact the distributed ledger.
  • the state DB of # 25006 is not shown in Fig. 5, but since the update for token ID: 1005 has not been performed from # 24769 to # 25006, the state of # 25006 for token ID: 1005 is the state of # 24768. Same as DB51A. Therefore, the user terminal 1B refers to the state DB of # 25006, and acquires the state data and the tracking data including the update block number # 23027.
  • the tracking data of this embodiment includes not only the update block number but also the token ID and the contract address. Therefore, in the present embodiment, even when the tokens are combined or divided and the tokens to be searched for are changed to different token IDs of different smart contracts, the token history can be efficiently tracked.
  • the user terminal 1 has acquired the consumption flag of the token (ID: 10.05) of the wood state table 61B shown in FIG. 7, the combined token to which the token is combined is set in the consumption flag.
  • the contract address (0x2A119 ...) and the token ID (0015)
  • the data of the specified token of the latest block is queried to its own distribution ledger, and the state of the token of the latest block from the distribution ledger. Get the data and the tracking data. This allows the user to get the current state of the desired token.
  • the user terminal 1B tracks the state data from the furniture state table of the latest block of its own distribution ledger (same as the state table 63 of # 25999). Get the data.
  • the user can confirm the current state data (owner, number of lots) of the combined token (ID: 0016) to which the timber token (ID: 1005) is combined.
  • the user wants to search the past history of the combined token (ID: 0016) the past history can be acquired by performing the processes S16 to S20 shown in FIG.
  • the process in which the user searches for the current state of the split token (consumer token), which is the split destination of a certain token, using the consumption flag is the same as the process of the combined token.
  • the blockchain system includes the user terminal 1 and the approval terminal 2, and the distributed ledger 11 of the blockchain system has a state DB that stores the state of the smart contract for each token.
  • the user terminal 1 includes a transaction issuing unit 13 that issues a transaction that updates the token
  • the approval terminal 2 generates an updating unit 154 that updates the token of the state DB and a block including the transaction, and the block is concerned.
  • a block generation unit 153 that reflects the updated state DB in the distributed ledger 11, and the update unit 154 adds the update block number of the block that updated the token, the token ID, and the token to the token of the state DB.
  • the tracking data including the update block number, token ID, and contract address of the updated block is stored in the state DB of the distributed ledger 11 of each terminal. Grant to the updated token.
  • the user can easily track the token history on the distributed ledger (blockchain) by tracing the update block number without referring to all the past blocks and transactions. That is, in the present embodiment, the past history and transition of the state of the smart contract can be easily and quickly acquired without holding the external database or the index DB.
  • the tracking data of the present embodiment includes the update block number of the block that updated the token, the ID of the token, and the address of the smart contract of the token.
  • the history of the token can be easily tracked not only for "update” of the token state but also for "combination” and "split" with other tokens. That is, not only the history of tokens with the same token ID in the same smart contract can be tracked, but also tokens of another smart contract and another token ID can be linked, and the history can be tracked. Therefore, in the present embodiment, the history of tokens can be tracked and the tracking path can be expressed even when a complicated token update such as joining or splitting is performed.
  • the approval terminal 2 sets the consumption flag and the token information of the consumption destination in the token. Therefore, in the present embodiment, it is possible to acquire the state of the token to which the token consumed by the combination or division is consumed.
  • traceability can be improved for users of smart contracts.
  • the conventional state DB information on which block in the past the state value was updated or changed is not retained, and it is not easy for the user to know at which block the state value has transitioned.
  • the trace data including the block number at the time of block generation (mining time) is added to the value of the state to be traced as the change point of the state value in the state DB. Traceability can be improved.
  • the user terminal 1 and the approved terminal 2 described above include, 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 executing a predetermined program loaded on the memory by the CPU.
  • each function of the user terminal 1 and the approval terminal 2 has 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. It is realized by executing.
  • the program for the user terminal 1 and the program for the approved terminal 2 can be stored in a computer-readable recording medium such as an HDD, SSD, USB memory, CD-ROM, DVD-ROM, or MO, or the network can be stored. It can also be delivered via.
  • a computer-readable recording medium such as an HDD, SSD, USB memory, CD-ROM, DVD-ROM, or MO, or the network can be stored. It can also be delivered via.
  • 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 does not calculate the search block number from the update block number when acquiring the past history of the state (S18 in FIG. 9), and uses the search block number acquired from the distributed ledger as it is. You can trace the past history.
  • state DB (state table) of the present embodiment is provided with the consumption flag
  • state DB (state table) does not have to be provided with the consumption flag.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

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

Description

ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム
　本発明は、スマートコントラクト型のブロックチェーンの履歴を管理する技術に関する。
　中央集権的な管理を必要とせずに、信頼性を担保可能な仕組みがデジタル仮想通貨ビットコインを中心に普及しつつある。ブロックチェーンと呼ばれるこの仕組みにおいては、やり取りされる情報の信頼性が分散ネットワーク内の合意形成のプロセスによって担保され、かつ、改ざんや二重使用などの不正を系全体で防ぐことで健全性が保たれる。
　ブロックチェーンでは、参加者間の取引情報（トランザクション）が「ブロック」という単位でまとめられ、各ブロックは数珠つなぎとなって時系列順に管理される。新たなブロックの承認は、Proof of Workなどの分散ネットワークにおける合意アルゴリズムによって形成される。新たなブロックの承認は、ブロック内部に記録された取引が系全体で合意されたことを示す。
　このブロックチェーンを用いて管理される一連の取引情報の帳簿を「分散台帳」と呼び、ネットワークに参加する各端末は同一の分散台帳を保持している。近年では、分散台帳に高度なスクリプトコードを登録し、スクリプトコードの実行とその結果についても合意を得るブロックチェーン基盤技術も開発されている。例えばEthereumと呼ばれるブロックチェーン基盤は、トランザクションを入力としてスクリプトコードを実行し、その実行結果をツリー構造のキーバリュー型ストア（ステートDBと呼ぶ）に格納し、その時のストアの代表値もブロックに記録する分散台帳を持つ。このようにブロックチェーン上に登録され、各端末に登録および実行されるスクリプトコードは「スマートコントラクト」と呼ばれている。
　スマートコントラクト型のブロックチェーンは、各ブロックと、そのブロック時点でスマートコントラクトのステートDBとが対応づけて管理されている（非特許文献１）。
　また、ブロックチェーン基盤の１つであるEthereumを用いて、サプライチェーンのトレーサビリティを、スマートコントラクトを利用して強化する技術も研究されている（非特許文献２）。
「JavaScript API・ethereum/wiki　Wiki・GitHub」、https://github.com/ethereum/wiki/wiki/JavaScript-API#contract-methods KENTAROH TOYODA、「A Novel Blockchain-Based Product Ownership Management System (POMS) for Anti-Counterfeits in the Post Supply Chain」、IEEE Access
　ブロックチェーンのデータ構造上、ブロック番号を指定し、そのブロック時点のステートを参照することは容易である。しかしながら、当該ブロックのステートの値が、過去のどのブロックでどのように遷移したのかを知ることは困難である。特に、情報のトレーサビリティを確保するという観点において、この問題は重要である。
　例えば、サプライチェーンの商品の追跡においては、非特許文献２に示すように、その時点で最新のステートを参照することは可能であるが、過去のステートを参照するためにはブロック番号をキーとして総当りに探索する必要がある。
　ステートのある値の変化を追跡する等の高度な探索・追跡を行う場合、RDBMS等の外部データベースを用意して、ブロックチェーンから抽出した全てのデータを外部データベースに落とし込み、外部データベース上でインデックスを構築し所望のデータを探索・追跡する方法が考えられる。しかしながら、外部データベースを用いた探索システムを構築および維持することは、一般ユーザにとって高いコストを要することになる。
　また、非特許文献２では、より複雑なサプライチェーンのケースについて考慮されていない。例えば、材料同士を組み合わせて別の製品が完成するケース（結合）、あるデジタルコンテンツから別のコンテンツが生まれるケース（分割）などは、考慮されていない。このような複雑なユースケースの場合、外部データベースを利用したとしても、探索はより困難となる。
　本発明は、上記課題を鑑みてなされたものであり、本発明の目的は、ブロックチェーン上で、データの履歴を容易に追跡することを可能とする技術を提供することにある。
　上記目的を達成するため、本発明の一態様は、利用者端末と、承認端末とを備えるブロックチェーンシステムであって、前記ブロックチェーンシステムの分散台帳は、スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有し、前記利用者端末は、トークンを更新するトランザクションを発行するトランザクション発行部、を備え、前記承認端末は、前記ステートデータベースの前記トークンを更新する更新部と、前記トランザクションを含むブロックを生成し、当該ブロックおよび更新後の前記ステートデータベースを前記分散台帳に反映させるブロック生成部と、を備え、前記更新部は、前記ステートデータベースの前記トークンに、前記トークンを更新したブロックの更新ブロック番号と、前記トークンのトークン情報とを含む追跡データを設定する。
　本発明の一態様は、ブロックチェーンシステムにおいてトランザクションを承認する承認端末であって、スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有する分散台帳と、トークンを更新するトランザクションを受信する受信部と、前記ステートデータベースの前記トークンを更新する更新部と、前記トランザクションを含むブロックを生成し、当該ブロックおよび更新後の前記ステートデータベースを前記分散台帳に反映させるブロック生成部と、を備え、前記更新部は、前記ステートデータベースの前記トークンに、前記トークンを更新したブロックの更新ブロック番号と、前記トークンのトークン情報とを含む追跡データを設定する。
　本発明の一態様は、ブロックチェーンシステムにおける利用者端末であって、スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有する分散台帳と、前記ステートデータベースからトークンが更新されたブロックの更新ブロック番号を含む追跡データを取得し、前記更新ブロック番号から算出される検索ブロック番号を指定して、前記検索ブロック番号の時点のブロックにおける前記トークンのステートおよび追跡データを前記ステートデータベースから取得する履歴検索部と、を備え、前記追跡データは、前記更新ブロック番号と、前記トークンのトークン情報とを含む。
　本発明の一態様は、ブロックチェーンの履歴を管理する履歴管理方法であって、前記ブロックチェーンの分散台帳は、スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有し、利用者端末は、トークンを更新するトランザクションを発行するトランザクション発行ステップを行い、承認端末は、前記ステートデータベースの前記トークンを更新する更新ステップと、前記トランザクションを含むブロックを生成し、当該ブロックおよび更新後の前記ステートデータベースを前記分散台帳に反映させるブロック生成ステップと、を行い、前記更新ステップは、前記ステートデータベースの前記トークンに、前記トークンを更新したブロックの更新ブロック番号と、前記トークンのトークン情報とを含む追跡データを設定する。
　本発明の一態様は、上記承認端末として、コンピュータを機能させることを特徴とする履歴管理プログラムである。
　本発明によれば、ブロックチェーン上で、データの履歴を容易に追跡することを可能とする技術を提供することができる。
本発明の実施形態に係るブロックチェーンシステムの全体構成を示す図である。 ブロック発行部の構成を示す構成図である。 分散台帳の構成を示す図である。 トークンの遷移を示す遷移図の例である。 ステートの更新時の追跡データの設定を説明するための模式図である。 トークンの結合時の追跡データの設定を説明するための模式図である。 トークンの結合時のステートテーブルの一例を示す図である。 トークンの分割時の追跡データの設定を説明するための模式図である。 ブロック生成および履歴検索を示すシーケンス図である。 トランザクションの一例を示す図である。
　以下、本発明の実施の形態について、図面を参照して説明する。
　（ブロックチェーンシステムの構成）
　図１は、本実施形態のブロックチェーンシステムの全体構成を示す図である。本実施形態のブロックチェーンは、スマートコントラクト型ブロックチェーンであって、ブロックチェーン基盤技術の１つであるEthereumを用いる。Ethereumは、ブロックチェーンを、状態遷移を記録する分散台帳として用いるためのアプリケーション開発プラットフォームである。ただし、本発明は、Ethereumに限定されるものではなく、Ethereum以外のブロックチェーンに用いてもよい。
　図１に示すブロックチェーンシステムは、利用者端末１と、承認端末２とを備える。これらの端末１、２は、P2Pネットワークであるブロックチェーンネットワーク４（以下、「ネットワーク」という）に自律分散的に接続される。なお、ネットワーク４には、図示する端末１、２の他にも、複数の端末が接続される。例えば、複数の利用者端末１、および、複数の承認端末２が接続されていてもよい。ネットワーク４に接続される端末は、後述する分散台帳１１、ブロックチェーン制御部１２およびトランザクション発行部１３を備え、分散台帳１１に記録されたデータおよびトランザクションを相互に検証し、系を維持している。
　利用者端末１は、ブロックチェーンおよびスマートコントラクトを利用する利用者が使用する端末（ノード）である。利用者端末１は、分散台帳１１と、ブロックチェーン制御部１２と、トランザクション発行部１３と、履歴検索部１４とを備える。
　分散台帳１１には、ブロックチェーン制御部１２を介して、ネットワーク４に接続された全ての端末と緩やかに同期することによって、リアルタイムに近い形で最新状態のブロックチェーンが記憶されている。本実施形態の分散台帳１１には、ブロックチェーンと、ブロックチェーンで管理されるデータ集合とが記憶されている。
　ブロックチェーン制御部１２は、ネットワーク４に接続された端末と自律分散的に協調してブロックチェーンの系を維持する。ブロックチェーン制御部１２は、分散台帳１１にアクセスし、分散台帳１１のブロックチェーンおよびデータ集合を読み出し、または、更新する。
　トランザクション発行部１３は、トランザクションをネットワーク４に発行する。本実施形態では、トランザクション発行部１３は、トークンを更新するトランザクションを発行する。具体的には、トランザクション発行部１３は、トークンのステートの値を更新するトランザクション、複数のトークンを結合するトランザクション、トークンを分割するトランザクションなどを発行する。
　履歴検索部１４は、自身の分散台帳１１のステートDBからトークンが更新されたブロックの更新ブロック番号を含む追跡データを取得し、更新ブロック番号から算出される検索ブロック番号を指定して、検索ブロック番号の時点のブロックにおけるトークンのステートおよび追跡データをステートDBから取得する。履歴検索部１４は、ブロックチェーン制御部１２を介して、分散台帳１１にアクセスする。
　承認端末２は、例えばマイナーと呼ばれるトランザクションの検証者が使用する端末であって、ネットワーク４に送信されたトランザクションを収集し、正当性を確認後に、承認作業を通じてブロックを生成する。承認端末２は、分散台帳１１と、ブロックチェーン制御部１２と、トランザクション発行部１３と、ブロック発行部１５とを備える。承認端末２の分散台帳１１、ブロックチェーン制御部１２およびトランザクション発行部１３は、利用者端末１の分散台帳１１、ブロックチェーン制御部１２およびトランザクション発行部１３と同様である。
　ブロック発行部１５は、ネットワーク４上に発行されたトランザクションを検証し、Proof of Workなどのブロック生成のためのコンセンサスアルゴリズム（合意アルゴリズム）に従い、ブロックの生成を試みる。
　図２は、承認端末２が備えるブロック発行部１５の構成を示す構成図である。図示するブロック発行部１５は、コンセンサス実行部１５１と、トランザクション検証部１５２と、ブロック生成部１５３と、更新部１５４とを備える。
　コンセンサス実行部１５１は、ハッシュ演算などコンセンサス（合意）に必要な計算を実施する。コンセンサスアルゴリズムは、ビットコインで用いられているProof of Work以外にも、所持コイン量をリソースとしたProof of Stake、ビザンチン故障における合意アルゴリズムであるPBFTなど、その他のブロック生成のためのコンセンサスアルゴリズムを用いても良い。
　トランザクション検証部１５２は、ネットワーク４よりトランザクションを受け取ると、受け取ったトランザクションの電子署名の正当性などのトランザクションの検証を行う。　
　ブロック生成部１５３は、所定の時間内にネットワーク４上で発行されたトランザクションをまとめて１つのブロックを生成する。すなわち、ブロック生成部１５３は、トランザクション検証部１５２による検証に成功した場合、当該トランザクションを含むブロックを生成し、ネットワーク４に接続される全ての端末の分散台帳１１に生成したブロックを反映させる。
　本実施形態のブロック生成部１５３は、トークンを更新するトランザクションを含むブロックを生成し、当該ブロックおよび更新部１５４により更新されたステートDBを分散台帳１１に反映させる。また、ブロック生成部１５３は、更新後のステートDBのハッシュ値を、生成するブロックのブロックヘッダに設定する。
　更新部１５４は、トークンを更新するトランザクションに基づいて、自身の分散台帳１１のデータ集合の１つであるステートDBを更新する。本実施形態では、更新部１５４は、ステートDBのトークンに、当該トークンを更新したブロックの更新ブロック番号と、当該トークンのトークン情報とを含む追跡データを設定する。本実施形態のトークン情報には、トークンのＩＤと、トークンのスマートコントラクトのアドレスとを含む。
　また、更新部１５４は、複数のトークンを結合した結合トークンに、結合トークンを生成したブロックのブロック番号と、結合元の複数のトークンのトークンＩＤおよびスマートコントラクトのアドレスとを、追跡データとして設定する。また、更新部１５４は、分割された分割トークンに、分割トークンを生成したブロックのブロック番号と、分割元のトークンのトークンＩＤおよびスマートコントラクトのアドレスとを、追跡データとして設定する。
　また更新部１５４は、ステートDBの結合元の複数の前記トークン、または、分割元のトークンに消費済であることを示す消費フラグを設定する。
　図３は、各端末の分散台帳１１の構成を示す。本実施形態の分散台帳１１は、複数のブロック１１１から構成されるブロックチェーンと、各ブロックに対応して管理されるデータ集合１１２とを備える。
　ブロック１１１は、ブロックヘッダ１１３、トランザクションリスト１１４などを有する。ブロックヘッダ１１３には、当該ブロックの時点の分散台帳１１全体の要約が設定される。図示する例では、ブロックヘッダ１１３には、データ集合１１２のある時点のスナップショットとして、データ集合１１２の要約値（ステートDBのハッシュ値、トランザクション集合のハッシュ値など）が設定される。例えば、データ集合がマークルツリーなどのツリー構造で格納されている場合、要約値として、マークルツリーのルートハッシュが設定される。トランザクションリスト１１４は、当該ブロック１１１に含まれるトランザクションのリストである。 
　データ集合１１２は、その用途および目的は限定されない。図示する分散台帳１１では、データ集合１１２として、ステートDBと、トランザクション集合DBとを備える。
　ステートDBは、あるブロックの時点でのスマートコントラクトのステートの値または状態を管理するためのDBである。また、ステートDBには、スマートコントラクトのバイトコードが格納される。本実施形態では、トークンというデータ単位でステートDBに情報が記録されている。ここでトークンとはスマートコントラクトで表現されるデータ構造であり、ブロックチェーン上で管理されるデータを示す。すなわち、本実施形態のステートDBは、スマートコントラクトのステートをトークン毎に記憶する。
　また、本実施形態のステートDBは、承認端末２の更新部１５４により、トークン毎に、トークンが更新されたブロックの更新ブロック番号を含む追跡データが設定される。ステートDBは、Key-Value Store(KVS)として機能し、トークンを一意に指定する識別情報（例えば、トークンID）が入力されると、当該トークンのステートの値および追跡データを出力する。
　なお、Ethereumでは、スマートコントラクトのバイトコードを、分散台帳１１（ステートDB）に登録すると、当該スマートコントラクトを示す識別情報が付与される。識別情報に対して、トランザクションを送信することができるため、スマートコントラクトの識別情報はアドレスとも呼ばれる。ユーザのアドレスへの送金との違いは、スマートコントラクトのアドレス宛てにトランザクションを送信すると、当該スマートコントラクトが実行されることである。
　トランザクション集合DBは、あるブロックの時点でのトランザクションの集合を示すDBである。トランザクションの集合は、あるブロックの時点での全てのトランザクションによって構成されるマークルツリーを意味する。
　（トークンのステートの遷移）
　図４は、本実施形態におけるトークンの遷移を示す遷移図の例である。
　本実施形態のトークンは、ステートの更新だけでなく、トークンの分割およびトークンの結合が可能なトークンである。トークンの分割は、１つのトークンを複数のトークンに分割することである。トークンの分割には、分割元のトークンを分割して新たな複数のトークンを生成し、分割元のトークンは消費される場合と、分割元のトークンの一部を新たなトークンに切り出し、分割元のトークンは一部のみ消費されて存続する場合とがある。トークンの結合は、複数のトークンを１つのトークンに結合することである。
　したがって、本実施形態のトークンの遷移は、図示するようにDAG（Directed acyclic graph：有向非巡回グラフ）を用いて、表現することができる。DAGは、グラフ理論における閉路のない有向グラフである。
　図示する例では、各トークンの追跡データを、Si（更新ブロック番号、トークンID、コントラクトアドレス）で表している。追跡データについては、後述する。i=1,…,Nは、異なる一意のステートの追跡データであることを示す添字である。例えば、S2のトークンでは、更新ブロック番号は「1699」、トークンIDは「5」、コントラクトアドレスは「0xA6214...」であることを示している。また、S4のトークンは、S2のトークンから分割されトークンである。S6のトークンは、S5のトークンとS3のトークンとが結合したトークンである。
　（追跡データの設定）
　次に、承認端末２が、ステートDBのトークンを更新する際に、当該トークンの履歴を追跡するための追跡データをステートDBに設定する処理を説明する。本実施形態では、トークンの更新には、ステートの更新だけでなく、他のトークンとの結合および分割も含まれる。そのため、本実施形態の追跡データは、トークンを更新した更新時点のブロックの更新ブロック番号と、トークンIDと、スマートコントラクトのアドレス（以下、「コントラクトアドレス」）とを含む。
　これにより、１つのスマートコントラクト内の同じIDのトークンの履歴を追跡できるだけでなく、関連する他のスマートコントラクトの他のIDのトークンもついても紐付けが可能となり、複数のスマートコントラクト間のトークンの履歴を追跡することができる。
　以下に、トークンの更新について、ステートの更新、トークンの結合、トークンの分割の３つのケースについて説明する。
　１．ステートの更新
　図５は、トークンのステート（状態、変数）を更新する場合において、追跡データをトークン（または、ステート）に付与する処理を説明するための模式図である。図示する例では、木材から家具を製作する過程で、木材のトークンのステートの更新について説明する。
　分散台帳１１には、前述のとおり、ブロックと、ステートDBとが対応付けて保持されている。ステートDBは、スマートコントラクト毎に、トークンのステートを管理する。図５は、ステートDBに保持されるトークン管理コントラクトのステートテーブル５１Ａ、５１Ｂを示す。トークン管理コントラクトは、木材のトークンを管理するスマートコントラクトである。ステートテーブル５１Ａは、ブロック（#24768）のステートテーブルである。ステートテーブル５１Ｂは、ブロック（#25007）のステートテーブルである。
　ステートテーブル５１Ａ、５１Ｂは、トークン毎に、トークンIDと、ステートデータと、消費フラグと、追跡データとを有する。本実施形態では、ステートのキーとしてトークンIDを用いるが、ステートのキーはトークンIDに限定されない。また、トークンは、代替不可能なトークン（Non-Fungible Token）であっても、代替可能なトークン（Fungible Token）であってもよい。
　ステートデータは、ステートを示すデータであって、図示する例では所有者アドレスと、ロット数とが含まれる。所有者アドレスには、対応するブロックの時点における、トークンの所有者のアドレスが設定される。ロット数には、トークンが示す対象（ここでは木材）の製造または発注の単位が設定される。
　消費（Consumed）フラグは、トークンが消費されたか否かを示すフラグである。トークンが結合または分割される場合には、元のトークンは消費され、消費フラグがTrue（消費済み）となる。トークンが結合および分割されていない場合には、トークンは消費されていなく、消費フラグはFalse（未消費）である。
　追跡データは、トークンの履歴を追跡するためのデータ（追跡用データ）である。本実施形態の追跡データには、更新ブロック番号、トークンID、コントラクトアドレスが含まれる。更新ブロック番号には、ステートデータを更新したブロック番号が設定される。ここでは、ステートデータの少なくとも１つが更新された場合、更新ブロック番号には更新したブロックのブロック番号が設定される。
　ブロック#24768のステートテーブル５１では、トークンID：1005のステートデータは、所有者は「0x13ae・・・」で、ロット数は「5」で、消費フラグは「False」（未消費）で、追跡データは、更新ブロック番号が「23027」で、トークンIDが「1005」で、コントラクトアドレスが「0xA6214・・・」である。
　ブロック#24769～#25006では、これらのブロックに含まれるトランザクションにより、トークンID：1005のステートデータは更新されないものとする。この場合、承認端末２は、図示しないブロック#24769～#25006の各ステートテーブルにおけるトークンID：1005に、直前のブロックのステートテーブルのステートデータ、消費フラグおよび追跡データを引き続き設定する。すなわち、ブロック#24769～#25006の各ステートテーブルにおけるトークンID：1005のデータは、ブロック#24768のステートテーブル５１Ａ のトークンID：1005のデータと同じである。
　そして、ブロック#25007に含まれるトランザクションにより、トークンID：1005のステートデータ（所有者アドレス、ロット数）が更新される。この場合、承認端末２は、トークンID：1005のステートデータを更新するとともに、追跡データを更新する。具体的には、承認端末２は、当該ブロックのブロック番号（#25007）を、更新ブロック番号に設定する。また、承認端末２は、更新されたトークンのID（1005）、更新されたトークンのコントラクトアドレス（0xA6214…）を、追跡データに設定する。
　このように、本実施形態では、キー（トークンID）に対するステート（ステートデータ）とともに、追跡データを設定する。これにより、本実施形態では、利用者端末１は、最新のブロック#25009のステートテーブルを参照すると、直近で更新が発生したブロックを示す追跡データを取得することができる。例えば、トークンID：1005の場合は、更新ブロック番号として#25007を取得することができる。
　そして、利用者端末１は、更新ブロック番号から算出される検索ブロック番号を指定して、検索ブロック番号で指定されたステートデータおよび追跡データの更新ブロック番号を取得する。例えば、検索ブロック番号は、更新ブロック番号から１減算したブロック番号とする。トークンID：1005の場合、更新ブロック番号#25007から１減算した検索ブロック番号＃25006を指定して当該ブロック番号に設定されたステートデータおよび追跡データの更新ブロック番号（#23027）を取得する。このように、本実施形態では、ステートの値に変更があったブロックの付近のブロックのみを辿ることで、探索コストを大幅に低減し、容易にステートの値の変更履歴を取得することができる。
　２．トークンの結合
　図６は、複数のトークンを結合する場合において、追跡データをトークン（または、ステート）に付与する処理を説明するための模式図である。図示する例では、木材から家具を製作する過程で、木材トークンと接着剤トークンとを結合して、家具トークンを生成する結合について説明する。ここでは、前述した「１．ステートの更新」と異なる点を中心に説明する。
　ステートDBは、スマートコントラクト毎に、トークンのステートを管理する。図６および図７では、木材のトークン管理コントラクトのステートテーブル６１Ａ、６１Ｂと、接着剤のトークン管理コントラクトのステートテーブル６２Ａ、６２Ｂと、家具のトークン管理コントラクトのステートテーブル６３と、を示している。
　ステートテーブル６１Ａ、６１Ｂは、ブロック#25768のステートテーブルである。ステートテーブル６１Ｂ、６２Ｂ、６３は、ブロック#25999のステートテーブルである。ステートテーブルは、前述のとおり、トークン毎に、トークンIDと、ステートデータと、消費フラグと、追跡データとを有する。
　例えば、木材のステートテーブル６１Ａでは、トークンID：1005のステートデータは、所有者は「0x92be・・・」で、ロット数は「10」で、消費フラグは「False」（未消費）で、追跡データは、更新ブロック番号が「25007」で、トークンIDが「1005」で、コントラクトアドレスが「0xA6214・・・」である。
　接着剤のステートテーブル６２Ａでは、トークンID：0177のステートデータは、所有者は「0x12ac・・・」で、ロット数は「100」で、消費フラグは「False」（未消費）で、追跡データは、更新ブロック番号が「10283」で、トークンIDが「0177」で、コントラクトアドレスが「0xBE823・・・」である。
　ブロック#25769～#25998では、これらのブロックに含まれるトランザクションにより、ステートテーブル６１ＡのトークンID：1005のステートデータ、および、ステートテーブル６２ＢのトークンID：0177のステートデータは、更新されないものとする。この場合、承認端末２は、図示しないブロック#25769～#25998の各ステートテーブルのトークンID：1005に、直前のブロックのステートテーブルのトークンID：1005のデータを引き続き設定する。すなわち、ブロック#25769～#25998の各ステートテーブルにおけるトークンID：1005のデータは、ブロック#25768のステートテーブル６１Ａ のトークンID：1005のデータと同じである。
　接着剤のステートテーブルについても同様に、ブロック#25769～#25998の各ステートテーブルにおけるトークンID：0177のデータは、ブロック#25768のステートテーブル６１Ｂ のトークンID：0177のデータと同じである。
　そして、ブロック#25999に含まれるトランザクションにより、ステートテーブル６１Ａのトークン（ID：1005）と、ステートテーブル６２Ａのトークン（ID：0177）とが結合され、家具トークンが生成される。
　この場合、承認端末２は、木材トークンおよび接着剤トークンを結合した新たな家具トークンのデータを生成し、ブロック#25999の接着剤のステートテーブル６３に設定する。具体的には、承認端末２は、家具トークンのトークンIDには所定のID：0016を設定し、ステートデータにはトランザクションで指定された値を設定し、消費フラグには「False」（未消費）を設定し、追跡データには結合される木材トークン（ID：1005）および接着剤トークン（ID：0177）の２つの情報を設定する。
　ここでは、木材トークンの追跡データとして、承認端末２は、家具トークンを生成した当該ブロックの更新ブロック番号（#25999）と、木材トークンのトークンID（1005）と、木材トークンのコントラクトアドレス（0xA6214・・・）とを設定する。接着剤トークンの追跡データとして、承認端末２は、家具トークンを生成した当該ブロックの更新ブロック番号（#25999）と、接着剤トークンのトークンID（0177）と、接着剤トークンのコントラクトアドレス（0xBE823・・・）とを設定する。
　また、承認端末２は、ブロック#25999の結合元のトークンのステートテーブル６１Ｂ、６２Ｂを更新する。図７に示すように、承認端末２は、ステートテーブル６１Ｂの結合元の木材トークン（ID：1005）の消費フラグを「False」（未消費）から「True」（消費済み）に更新する。同様に、承認端末２は、ステートテーブル６２Ｂの結合元の接着剤トークン（ID：0177）の消費フラグを「False」から「True」に更新する。トークンが結合されることにより、結合元のトークンは消費され、消費フラグが「True」となる。結合トークン（家具トークン）は、結合元のトークンとは異なるスマートコントラクトに属し、異なるトークンIDを持つ。
　また、承認端末２は、消費フラグを「True」に更新した場合、消費先（結合先）のトークン情報を消費フラグに設定する。本実施形態では、トークン情報は、コントラクトアドレスと、トークンIDとを含む。
　また、承認端末２は、消費フラグを「True」に更新した場合、追跡データの更新ブロック番号を、消費（結合）されたブロック番号に更新してもよい。図７では、ステートテーブル６１Ｂの結合元の木材トークン（ID：1005）、および、ステートテーブル６２Ｂの結合元の接着剤トークン（ID：0177）の追跡データの更新ブロック番号には、消費フラグを更新したブロック番号（#25999）が設定されている。これにより、利用者は、消費フラグが「True」に更新されたブロックを、容易に知ることができる。
　なお、消費フラグが「True」に更新されたトークンは、これ以降のブロックで、更新、結合および分割が行われず、したがって、当該トークの情報はこれ以降更新されない。
　３．トークンの分割
　図８は、トークンの分割において、追跡データをステートの値に付与する処理を説明するための模式図である。図示する例では、コンテンツの著作権から、一部の演奏権を切り出し、著作権を分割するケースについて説明する。ここでは、前述した「１．トークンの更新」および「２．トークンの結合」と異なる点を中心に説明する。
　図示する例では、各ブロックに対応するステートDBは、「著作権」トークンを管理するトークン管理コントラクトのステートテーブル８１Ａ、８１Ｂと、「演奏権」トークンを管理するトークン管理コントラクトのステートテーブル８２とを示している。
　ステートテーブル８１Ａは、ブロック#25768のステートテーブルである。ステートテーブル８１Ｂ、８２は、ブロック#25999のステートテーブルである。ステートテーブルは、前述のとおり、トークン毎に、トークンIDと、ステートデータと、消費フラグと、追跡データとを有する。
　ブロック#25769～#25998では、これらのブロックに含まれるトランザクションにより、ステートテーブル８１ＡのトークンID：40のステートデータは、更新されないものとする。この場合、承認端末２は、図示しないブロック#25769～#25998の各ステートテーブルのトークンID：40に、直前のブロックのステートテーブルのトークンID：40のデータを引き続き設定する。すなわち、ブロック#25769～#25998の各ステートテーブルにおけるトークンID：40のデータは、ブロック#25768のステートテーブル８１Ａ のトークンID：40のデータと同じである。
　そして、ブロック#25999に含まれるトランザクションにより、著作権トークン（ID：40）から、著作権の一部の演奏権が切り出され、演奏権トークンとして分割される。この場合、承認端末２は、分割による新たな演奏権トークンを生成し、ブロック#25999の演奏権のステートテーブル８２に設定する。
　具体的には、承認端末２は、演奏権トークンのトークンIDには所定のID：99を設定し、ステートデータにはトランザクションで指定された値を設定し、消費フラグには「False」（未消費）を設定し、追跡データには分割元の著作権トークン（ID：40）の情報を設定する。ここでは、承認端末２は、演奏権トークンを生成した当該ブロックの更新ブロック番号（#25999）と、著作権トークンのトークンID（40）と、著作権トークンのコントラクトアドレス（0xB7342・・・）とを、追跡データとして設定する。
　また、承認端末２は、ステートテーブル８１Ｂの分割元の著作権トークン（ID：40）の消費フラグを、「True(一部消費)」に更新する。また、承認端末２は、消費フラグを「True（一部消費）」に更新した場合、消費先（分割先）のトークン情報を消費フラグに設定し、消費先と関連付ける。本実施形態では、トークン情報は、コントラクトアドレスと、トークンIDとを含む。
　（ブロックの生成およびトークンの履歴検索）
　図９は、本実施形態のブロック生成および履歴検索を示すシーケンス図である。
　図示する処理では、利用者Ａがトークンを更新（結合および分割を含む）するトランザクションを発行し、利用者Ｂが利用者Ａにより更新されたトークンの履歴を探索する処理を示す。
　利用者Ａの利用者端末１Ａは、例えば、所定のトークンを利用者Ａから利用者Ｂに移動するためのトランザクションを生成し、を発行する（Ｓ１１）。具体的には、利用者端末１Ａはトランザクションをネットワーク４上にブロードキャストする。これにより、トランザクションは、ネットワーク４に接続された全ての端末に伝搬される。
　図１０は、Ｓ１１のトランザクションの一例を示す図である。図示するトランザクションは、宛先と、支払額と、データと、電子署名とを有する。宛先には、スマートコントラクトのアドレス（コントラクトアドレス）が設定される。支払額には、スマートコントラクトを実行するために支払われる金額（手数料）が設定される。
　データには、例えば、スマートコントラクト内の「指定されたアドレスへ所定のトークンの所有権を移動する」機能を提供する関数を実行することを指定するデータが設定される。なお、引数としてトークンのIDと、移動先の利用者のアドレス等を指定する。電子署名には、トランザクションの発行者である利用者Ａの秘密鍵で当該トランザクションが署名された署名値が設定される。
　そして、承認端末２（ブロック発行部１５）は、Ｓ１１で送信されたトランザクションを検証（マイニング）する（Ｓ１２）。そして、承認端末２は、当該トランザクションを、所定の時間内に発生した他のトランザクションとまとめて１つのブロックを生成する。当該ブロックは、ナンスのマイニングを経て自身の分散台帳１１のブロックチェーンに追加される（Ｓ１３）。承認端末２がブロックの生成に成功することにより、Ｓ１１で送信されたトランザクションが確定（承認）される。
　ここで、承認端末２は、Ｓ１１のトランザクションに基づいて、自身の分散台帳１１のデータ集合の各DBを更新し、更新後の各DBのハッシュ値を、生成するブロックのブロックヘッダに設定する。
　また、承認端末２は、データ集合のステートDBを更新する際に、Ｓ１１のトランザクションに従って、指定されたトークンを更新する。すなわち、承認端末２は、トークンのステートデータを変更、トークンを結合、または、トークンを分割する。また、本実施形態では、承認端末２は、トークンを更新した当該ブロックのブロック番号、トークンID、コントラクトアドレスを含む追跡データを、ステートDBに記憶する。
　そして、承認端末２は、更新後のステートDBのハッシュ値を、生成するブロックのブロックヘッダに設定する。なお、Ｓ１３は、ネットワークに接続された全ての端末のうち、最も早くブロックの生成に成功した端末によって行われる処理である。
　そして、端末間のゆるやかな同期により、Ｓ１１で送信されたトランザクションを含むブロックが、ネットワーク４に接続された全ての端末の分散台帳１１に反映される（Ｓ１４、Ｓ１５）。すなわち、全ての端末のブロックチェーン制御部１２は、自身が保持する分散台帳１１に、Ｓ１１のトランザクションを含むブロックを追加する。また、全ての端末のブロックチェーン制御部１２は、承認端末２と同様に、ブロックに含まれるトランザクションに基づいて、自身の分散台帳１１のデータ集合のステートDBを更新する。
　次に、利用者Ｂが、利用者Ａが更新したトークンの過去の履歴を探索する場合、Ｓ１６以降の処理を行う。具体的には、利用者端末１Ｂは、最新のブロックにおける、前記トークンのステートデータを、自身の分散台帳に問合せ（Ｓ１６）、分散台帳から最新のブロックのステートデータと、追跡データとを取得する（Ｓ１７）。
　例えば、最新ブロックが図５に示す#25009で、問い合わせ対象のトークンIDが1005の場合、利用者端末１Ｂは、自身の分散台帳のステートDB５１Ｂを参照し、ステートデータと、更新ブロック番号#25007を含む追跡データとを取得する。これにより、利用者Ｂは、現在のトークンのステートの値と、また、当該トークンの更新が#25007のブロックで行われたことを確認することができる。
　そして、利用者Ｂは、当該トークンの過去の履歴を検索したい場合、Ｓ１８からＳ２０の処理を繰り返し行う。すなわち、利用者端末１Ｂは、Ｓ１７の追跡データから検索ブロック番号と、検索したいトークンのコントラクトアドレスおよびトークンIDとを取得する（Ｓ１８）。
　具体的には、利用者端末１Ｂは、取得した更新ブロック番号に基づいて検索ブロック番号を算出する。ここでは、更新ブロック番号から「１」減算したブロック番号を検索ブロック番号とする。そして、利用者端末１Ｂは、検索ブロック番号と、コントラクトアドレスと、トークンIDとを指定し、検索ブロック番号における、指定したトークンのデータを自身の分散台帳に問合せ（Ｓ１９）、指定したブロックにおける指定したトークンのステートデータと、追跡データとを分散台帳から取得する（Ｓ２０）。
　例えば、図５のステートDBにおいて、Ｓ１７取得した更新ブロック番号が#25007でトークンIDが1005の場合、利用者端末１Ｂは、#25007から「1」減算した検索ブロック番号#25006を指定して、分散台帳に問い合わせる。#25006のステートDBは、図５に示していないが、トークンID：1005に対する更新は#24769から#25006までは行われていないため、トークンID：1005に関する#25006のステートは、#24768のステートDB５１Ａと同じである。したがって、利用者端末１Ｂは、#25006のステートDBを参照し、ステートデータ、および、更新ブロック番号#23027を含む追跡データを取得する。
　そして、利用者端末１Ｂは、それ以前の過去の履歴を検索したい場合は、Ｓ１８からＳ２０の処理を繰り返し行う。これにより、利用者Ｂは、トークンの過去の履歴を効率よく辿ることができる。
　また、本実施形態の追跡データには、更新ブロック番号だけでなく、トークンIDおよびコントラクトアドレスも含まれる。これにより、本実施形態では、トークンが結合または分割されて、検索したいトークンが異なるスマートコントラクトの異なるトークンIDに変更された場合であっても、トークンの履歴を効率よく追跡することができる。
　次に、追跡データの消費フラグを用いたトークンの検索について説明する。
　ここでは、利用者が、あるトークンの結合先である結合トークン（消費先のトークン）の現在のステートを、消費フラグを用いて探索する処理を説明する。
　例えば、利用者端末１は、図７に示す木材のステートテーブル６１Ｂのトークン（ID:1005）の消費フラグを取得している場合、当該トークンの結合先である結合トークンを、消費フラグに設定されたコントラクトアドレス（0x2A119・・・）と、トークンID（0015）とを指定して、最新のブロックの指定したトークンのデータを自身の分散台帳に問合せ、分散台帳から最新のブロックの当該トークンのステートデータと、追跡データとを取得する。これにより、利用者は、所望のトークンの現在のステートを取得することができる。
　例えば、最新ブロックが図６に示す#26001の場合、利用者端末１Ｂは、自身の分散台帳の最新のブロックの家具のステートテーブル（#25999のステートテーブル６３と同じ）から、ステートデータと、追跡データとを取得する。これにより、利用者は、木材のトークン（ID:1005）の結合先である結合トークン（ID：0016）の現在のステートデータ（所有者、ロット数）を確認することができる。また、利用者が結合トークン（ID：0016）の過去の履歴を検索したい場合は、図９に示すＳ１６からＳ２０の処理を行うことで過去の履歴を取得することができる。
　利用者が、あるトークンの分割先である分割トークン（消費先のトークン）の現在のステートを、消費フラグを用いて探索する処理についても、結合トークンの処理と同様である。
　以上説明した本実施形態では、利用者端末１と、承認端末２とを備えるブロックチェーンシステムであって、ブロックチェーンシステムの分散台帳１１は、スマートコントラクトのステートをトークン毎に記憶するステートDBを有し、利用者端末１は、トークンを更新するトランザクションを発行するトランザクション発行部１３を備え、承認端末２は、ステートDBのトークンを更新する更新部１５４と、トランザクションを含むブロックを生成し、当該ブロックおよび更新後のステートDBを分散台帳１１に反映させるブロック生成部１５３とを備え、更新部１５４は、ステートDBのトークンに、トークンを更新したブロックの更新ブロック番号と、トークンのＩＤと、トークンのコントラクトアドレスとを含む追跡データを設定する。
　このように、本実施形態では、各端末の分散台帳１１のステートDBには、トークンが更新された時点で、更新のあったブロックの更新ブロック番号、トークンIDおよびコントラクトアドレスを含む追跡データを、更新されたトークンに付与する。これにより、利用者は、更新ブロック番号を辿ることで、過去の全てのブロックおよびトランザクションを参照することなく、分散台帳（ブロックチェーン）上で、トークンの履歴を容易に追跡することができる。すなわち、本実施形態では、スマートコントラクトのステートの過去の履歴および変遷を、外部データベースやインデックスDBを保持することなく、容易および高速に取得することができる。
　また、本実施形態の追跡データは、トークンを更新したブロックの更新ブロック番号と、トークンのＩＤと、トークンのスマートコントラクトのアドレスとを含む。これにより、本実施形態では、トークンのステートの「更新」だけでなく、他のトークンとの「結合」および「分割」についても、トークンの履歴を容易に追跡することができる。すなわち、同じスマートコントラクト内の同じトークンIDのトークンの履歴を追跡するだけでなく、別のスマートコントラクトおよび別のトークンIDのトークンについても紐付けが可能となり、履歴を追跡することができる。したがって、本実施形態では、結合または分割などの複雑なトークンの更新が行われている場合であっても、トークンの履歴を追跡でき、追跡経路を表現することができる。
　また、本実施形態では、承認端末２は、トークンに消費フラグおよび消費先のトークンの情報を設定する。これにより、本実施形態では、結合または分割により消費されたトークンの消費先のトークンのステートを取得することができる。
　また、本実施形態では、スマートコントラクトの利用者に対して、トレーサビリティを向上することができる。従来のステート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（ステートテーブル）は、消費フラグを備えなくてもよい。
　１　：利用者端末
　２　：承認端末
　１１：分散台帳
　１２：ブロックチェーン制御部
　１３：トランザクション発行部
　１４：履歴検索部
　１５：ブロック発行部
　１５１：コンセンサス実行部
　１５２：トランザクション検証部
　１５３：ブロック生成部
　１５４：更新部
　４　：ブロックチェーンネットワーク

Claims (8)

  1. 　利用者端末と、承認端末とを備えるブロックチェーンシステムであって、
    　前記ブロックチェーンシステムの分散台帳は、スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有し、
    　前記利用者端末は、
    　　トークンを更新するトランザクションを発行するトランザクション発行部、を備え、
    　前記承認端末は、
    　　前記ステートデータベースの前記トークンを更新する更新部と、
    　　前記トランザクションを含むブロックを生成し、当該ブロックおよび更新後の前記ステートデータベースを前記分散台帳に反映させるブロック生成部と、を備え、
    　　前記更新部は、前記ステートデータベースの前記トークンに、前記トークンを更新したブロックの更新ブロック番号と、前記トークンのトークン情報とを含む追跡データを設定すること
    　を特徴とするブロックチェーンシステム。
  2. 　請求項１記載のブロックチェーンシステムであって、
    　前記トランザクション発行部は、複数のトークンを結合するトランザクションを発行し、
    　前記更新部は、複数の前記トークンを結合した結合トークンに、前記結合トークンを生成したブロックのブロック番号と、結合元の複数の前記トークンのトークンＩＤおよびスマートコントラクトのアドレスとを、前記追跡データとして設定すること
    　を特徴とするブロックチェーンシステム。
  3. 　請求項２記載のブロックチェーンシステムであって、
    　前記更新部は、前記ステートデータベースの結合元の複数の前記トークンに、消費済であることを示すフラグを設定すること
    　を特徴とするブロックチェーンシステム。
  4. 　請求項１記載のブロックチェーンシステムであって、
    　前記トランザクション発行部は、トークンを分割するトランザクションを発行し、
    　前記更新部は、前記トークンから分割された分割トークンに、前記分割トークンを生成したブロックのブロック番号と、分割元の前記トークンのトークンＩＤおよびスマートコントラクトのアドレスとを、前記追跡データとして設定すること
    　を特徴とするブロックチェーンシステム。
  5. 　ブロックチェーンシステムにおいてトランザクションを承認する承認端末であって、
    　スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有する分散台帳と、
    　トークンを更新するトランザクションを受信する受信部と、
    　前記ステートデータベースの前記トークンを更新する更新部と、
    　前記トランザクションを含むブロックを生成し、当該ブロックおよび更新後の前記ステートデータベースを前記分散台帳に反映させるブロック生成部と、を備え、
    　前記更新部は、前記ステートデータベースの前記トークンに、前記トークンを更新したブロックの更新ブロック番号と、前記トークンのトークン情報とを含む追跡データを設定すること
    　を特徴とする承認端末。
  6. 　ブロックチェーンシステムにおける利用者端末であって、
    　スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有する分散台帳と、
    　前記ステートデータベースからトークンが更新されたブロックの更新ブロック番号を含む追跡データを取得し、前記更新ブロック番号から算出される検索ブロック番号を指定して、前記検索ブロック番号の時点のブロックにおける前記トークンのステートおよび追跡データを前記ステートデータベースから取得する履歴検索部と、を備え、
    　前記追跡データは、前記更新ブロック番号と、前記トークンのトークン情報とを含むこと
    　を特徴とする利用者端末。
  7. 　ブロックチェーンの履歴を管理する履歴管理方法であって、
    　前記ブロックチェーンの分散台帳は、スマートコントラクトのステートをトークン毎に記憶するステートデータベースを有し、
    　利用者端末は、
    　　トークンを更新するトランザクションを発行するトランザクション発行ステップを行い、
    　承認端末は、
    　　前記ステートデータベースの前記トークンを更新する更新ステップと、
    　　前記トランザクションを含むブロックを生成し、当該ブロックおよび更新後の前記ステートデータベースを前記分散台帳に反映させるブロック生成ステップと、を行い、
    　　前記更新ステップは、前記ステートデータベースの前記トークンに、前記トークンを更新したブロックの更新ブロック番号と、前記トークンのトークン情報とを含む追跡データを設定すること
    　を特徴とする履歴管理方法。
  8. 　請求項５に記載の承認端末として、コンピュータを機能させることを特徴とする履歴管理プログラム。
PCT/JP2020/012289 2019-04-02 2020-03-19 ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム WO2020203349A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/600,874 US20220156733A1 (en) 2019-04-02 2020-03-19 Blockchain system, approval terminal, user terminal, history management method, and history management program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2019-070600 2019-04-02
JP2019070600A JP7137077B2 (ja) 2019-04-02 2019-04-02 ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム

Publications (1)

Publication Number Publication Date
WO2020203349A1 true WO2020203349A1 (ja) 2020-10-08

Family

ID=72667675

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/012289 WO2020203349A1 (ja) 2019-04-02 2020-03-19 ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム

Country Status (3)

Country Link
US (1) US20220156733A1 (ja)
JP (1) JP7137077B2 (ja)
WO (1) WO2020203349A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112950180A (zh) * 2021-02-24 2021-06-11 中国工商银行股份有限公司 一种基于联盟链的通证方法、系统、电子设备及存储介质

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200372493A1 (en) * 2019-05-21 2020-11-26 Obook Inc. Item Management Method, Blockchain Analysis Method and Computer System Using the Same
JP7055234B1 (ja) 2021-09-29 2022-04-15 東電設計株式会社 情報処理装置、プログラム、三次元データ管理システムおよび三次元データ管理方法
JP7366981B2 (ja) * 2021-11-17 2023-10-23 本田技研工業株式会社 契約管理システムおよび契約管理方法
WO2023090233A1 (ja) * 2021-11-18 2023-05-25 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 管理方法、装置、及び、プログラム
JP7195673B1 (ja) 2022-02-23 2022-12-26 充宏 前田 情報処理システム、情報処理方法及びプログラム
CN118871910A (zh) * 2022-03-29 2024-10-29 三菱电机株式会社 数据验证装置、客户端应用、区块链系统、数据验证方法以及数据验证程序
WO2024214581A1 (ja) * 2023-04-10 2024-10-17 パナソニックＩｐマネジメント株式会社 情報処理方法、情報処理装置、および、プログラム

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018112827A (ja) * 2017-01-10 2018-07-19 日本電信電話株式会社 情報処理システム
JP2018128723A (ja) * 2017-02-06 2018-08-16 株式会社日立製作所 信用度管理システムおよび信用度管理方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018175504A1 (en) * 2017-03-20 2018-09-27 Wasserman Steven Victor Blockchain digital currency: systems and methods for use in enterprise blockchain banking
JP6900266B2 (ja) * 2017-07-26 2021-07-07 株式会社日立製作所 運用管理方法、運用管理システム、および、運用管理プログラム
TWI659373B (zh) * 2018-02-14 2019-05-11 財團法人工業技術研究院 區塊鏈系統及應用其的方法
US11676122B2 (en) * 2018-06-29 2023-06-13 Itron, Inc. Operating smart sensors using distributed ledgers
US20200034457A1 (en) * 2018-07-24 2020-01-30 Ernst & Young U.S.LLP System and methods for organizing and inter-relating hierarchical data files using a distributed database
US10880074B2 (en) * 2018-10-15 2020-12-29 Adobe Inc. Smart contract platform for generating and customizing smart contracts
US11093479B2 (en) * 2018-11-06 2021-08-17 Workday, Inc. Ledger data generation and storage for trusted recall of professional profiles
US11455380B2 (en) * 2018-11-20 2022-09-27 International Business Machines Corporation Chain-of-custody of digital content in a database system
US20200210978A1 (en) * 2018-12-31 2020-07-02 Suzanne Brown Blockchain-Based Value Platform

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018112827A (ja) * 2017-01-10 2018-07-19 日本電信電話株式会社 情報処理システム
JP2018128723A (ja) * 2017-02-06 2018-08-16 株式会社日立製作所 信用度管理システムおよび信用度管理方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112950180A (zh) * 2021-02-24 2021-06-11 中国工商银行股份有限公司 一种基于联盟链的通证方法、系统、电子设备及存储介质

Also Published As

Publication number Publication date
JP7137077B2 (ja) 2022-09-14
JP2020170296A (ja) 2020-10-15
US20220156733A1 (en) 2022-05-19

Similar Documents

Publication Publication Date Title
WO2020203349A1 (ja) ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム
US11973869B2 (en) Maintaining blocks of a blockchain in a partitioned blockchain network
CN108389129B (zh) 基于区块链的交易执行方法及装置、电子设备
Buterin A next-generation smart contract and decentralized application platform
WO2021244208A1 (zh) 区块链的提案消息处理方法、装置、设备以及存储介质
JP7157348B2 (ja) ブロックチェーンシステム、承認端末、スマートコントラクト登録方法、および、スマートコントラクト登録プログラム
US11748724B2 (en) Systems and methods for operating a bridge server to support multiple shards of a blockchain
US20210367797A1 (en) Systems and methods for an online media marketplace
JP7181455B2 (ja) ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム
CN112200571B (zh) 基于区块链的资源发放方法、装置及电子设备
Wang et al. ReviewChain: Smart contract based review system with multi-blockchain gateway
US20200084041A1 (en) Automated Blockchain Protocol Update
CN109726249B (zh) 一种去中心化芯片研发交易数据存储方法及系统
US20230120476A1 (en) Methods and systems for creation and distribution of non-fungible tokens
CN112200567A (zh) 基于区块链的资源管理方法、装置及电子设备
CN111488396A (zh) 业务数据区块链的数据同步方法及装置
CN110597922A (zh) 数据处理方法、装置、终端及存储介质
CN112200572A (zh) 基于区块链的资源发放方法、装置及电子设备
CN112200570A (zh) 基于区块链的资源发放方法、装置及电子设备
CN111488356A (zh) 业务数据区块链的数据存储方法及其装置
KR20200107113A (ko) 블록체인을 활용한 신뢰도 기반 전력 거래 방법 및 시스템
CN111488613A (zh) 业务数据区块链的数据高效查询方法及装置
KR101447850B1 (ko) 실시간 대전 게임을 위한 게임 제공 방법 및 그 시스템
Tsampas Survey on decentralized applications
Evermann et al. Workflow Management on BFT Blockchains

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: 20783500

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: 20783500

Country of ref document: EP

Kind code of ref document: A1