JP7181455B2 - Blockchain system, approval terminal, user terminal, history management method, and history management program - Google Patents

Description

The present invention relates to technology for managing the history of a smart contract type blockchain.

A mechanism that can guarantee reliability without the need for centralized management is spreading, centering on the digital virtual currency bitcoin. In this mechanism, called blockchain, the reliability of exchanged information is guaranteed by the process of consensus building within the distributed network, and the soundness is ensured by preventing fraud such as falsification and double use throughout the system. drip.

In a blockchain, transaction information (transactions) between participants is organized in units called "blocks", and each block is linked together and managed in chronological order. New block approvals are formed by consensus algorithms in distributed networks such as Proof of Work. Approval of a new block indicates that the transactions recorded within the block have been agreed across the system.

A series of transaction information ledger managed using this blockchain is called a "distributed ledger", and each terminal participating in the network holds the same distributed ledger. In recent years, blockchain-based technology has also been developed that registers advanced script code on a distributed ledger and obtains consensus on the execution of the script code and its results. For example, the blockchain platform called Ethereum executes script code with transactions as input, stores the execution results in a tree-structured key-value store (called a state DB), and records the representative value of the store at that time in a block. have a distributed ledger that Script code that is registered on the blockchain in this way and that is registered and executed on each terminal is called a "smart contract."

In a smart contract type blockchain, each block is managed in association with the state DB of the smart contract at the time of the block (Non-Patent Document 1).

"JavaScript API/ethereum/wiki Wiki/GitHub", https://github.com/ethereum/wiki/wiki/JavaScript-API#contract-methods

Due to the data structure of the blockchain, it is easy to specify the block number and refer to the state at the time of that block. However, it is difficult to know how the value of the state of the block in question transitioned in which block in the past. This problem is particularly important from the viewpoint of ensuring the traceability of information.

For example, when performing advanced search/tracking such as tracking changes in values in a state, prepare an external database such as RDBMS, drop all the data extracted from the blockchain into the external database, and A method of building an index to search and track desired data is conceivable. However, 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 technology that enables easy tracing of data history on a blockchain.

To achieve the above object, one aspect of the present invention is a blockchain system comprising a user terminal and an approval terminal, wherein the user terminal issues a transaction to update the value of a smart contract variable. a transaction issuing unit, wherein the approval terminal generates a block containing the transaction and updates the value of the variable; It has a block generator that reflects it in the distributed ledger of the terminal of the system.

One aspect of the present invention is an approval terminal that approves a transaction in a blockchain system, comprising: a receiving unit that receives a transaction that updates a value of a variable of a smart contract; a block that includes the transaction; and a block generation unit that updates a value and reflects the block and the update block number of the block whose value of the variable is updated to a distributed ledger of the terminal of the blockchain system.

One aspect of the present invention is a user terminal in a blockchain system, comprising a blockchain distributed ledger, a transaction issuing unit that issues a transaction that updates the value of a smart contract variable, and Acquire the update block number of the block whose value has been updated, specify the search block number calculated from the update block number, and obtain the value of the smart contract variable and the update block number in the block at the time of the search block number from the distributed ledger.

One aspect of the present invention is a history management method for managing blockchain history, wherein a user terminal performs a transaction issuing step of issuing a transaction for updating the value of a variable of a smart contract, and an approval terminal performs the A generation step of generating a block containing a transaction and updating the value of the variable, and storing the block and the update block number of the block that updated the value of the variable in a distributed ledger of terminals connected to a blockchain network. and a synchronization step to reflect the

One aspect of the present invention is a smart contract registration program characterized by causing a computer to function as the approval terminal.

ADVANTAGE OF THE INVENTION According to this invention, the technique which makes it possible to trace the history of data easily on a block chain can be provided.

1 is a diagram showing the overall configuration of a blockchain system according to an embodiment of the present invention; FIG. It is a figure which shows the structure of a distributed ledger. 4 is a configuration diagram showing the configuration of a block issuing unit; FIG. FIG. 10 is an explanatory diagram for explaining a method of setting an update block number of a state DB; FIG. 10 is a sequence diagram showing block generation and history retrieval; FIG. 4 is a diagram showing an example of a transaction; FIG.

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, embodiments of the present invention will be described with reference to the drawings.

FIG. 1 is a diagram showing the overall configuration of the blockchain system of this embodiment. The blockchain of this embodiment is a smart contract type blockchain, and uses Ethereum, which is one of the blockchain base technologies. Ethereum is an application development platform for using blockchain as a distributed ledger that records state transitions. However, the present invention is not limited to Ethereum, and may be used for blockchains other than Ethereum.

The blockchain system shown in FIG. 1 has a user terminal 1 and an approval terminal 2 . These terminals 1 and 2 are connected to a block chain network 4 (hereinafter referred to as "network"), which is a P2P network, in an autonomous distributed manner. A plurality of terminals are connected to the network 4 in addition to the terminals 1 and 2 shown in the figure. For example, multiple user terminals 1 and multiple approval terminals 2 may be connected. A 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 blockchain and smart contracts. 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 state of the blockchain in near-real time by loosely synchronizing with all the terminals connected to the network 4 via the blockchain control unit 12 . A blockchain and a set of data managed by the blockchain are stored in the distributed ledger 11 of the present embodiment.

The blockchain control unit 12 cooperates with terminals connected to the network 4 in an autonomous decentralized manner to maintain the blockchain system. The blockchain control unit 12 accesses the distributed ledger 11 and reads or updates the blockchain and data set of the distributed ledger 11 .

A transaction issuing unit 13 issues a transaction to the network 4 . In this embodiment, the transaction issuing unit 13 issues a transaction for updating the state (variable) value of the smart contract.

The history search unit 14 acquires the update block number of the block whose smart contract state value has been updated from its own distributed ledger 11, designates the search block number calculated from the update block number, and retrieves the search block number. Get the value of the state of the smart contract at the current block and the update block number from the distributed ledger 11 . 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, for example, a transaction verifier called a miner, collects transactions sent to the network 4, verifies their validity, and generates blocks 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 transactions issued on the network 4 and tries to generate blocks according to a consensus algorithm for block generation such as Proof of Work.

FIG. 2 is a configuration diagram showing the configuration of the block issuing unit 15 provided in the approval terminal 2. As shown in FIG. The illustrated block issuing unit 15 includes a consensus executing unit 151 , a transaction verifying unit 152 , and a block generating unit 153 .

The consensus execution unit 151 performs calculations necessary for consensus (agreement) such as hash calculation. In addition to Proof of Work used in Bitcoin, the consensus algorithm uses other consensus algorithms for block generation, such as Proof of Stake, which uses the amount of owned coins as a resource, and PBFT, which is a consensus algorithm for Byzantine failures. can be

Upon receiving a transaction from the network 4, the transaction verification unit 152 verifies the transaction such as the legitimacy of the electronic signature of the received transaction.

The block generation unit 153 generates one block by collecting transactions issued on the network 4 within a predetermined period of time. That is, when the transaction verification unit 152 succeeds in verification, 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 this 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 value of the state (variable) of the smart contract. The updated block number of the block is reflected in the distributed ledger of the terminal of the blockchain system.

Specifically, the block generation unit 153 updates the state DB, which is one of the data sets of its own distributed ledger 11, based on the transaction that updates the state value of the smart contract, and updates the state DB after the update. Set the hash value in the block header of the block to be generated. That is, the block generation unit 153 sets the value of the state updated according to the transaction and the update block number of the updated block in the state DB.

FIG. 3 shows the configuration of the distributed ledger 11 of each terminal. The distributed ledger 11 of this embodiment comprises a block chain composed of a plurality of blocks 111 and a data set 112 managed corresponding to each block.

A 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 in the block header 113 . In the illustrated example, the block header 113 is set with a summary value of the data set 112 (state DB hash value, transaction set hash value, etc.) as a snapshot of the data set 112 at a certain point in time. For example, if the data set is stored in a tree structure such as a Merkle tree, the summary value is set to the root hash of the Merkle tree. The transaction list 114 is a list of transactions included in the block 111 concerned.

Data set 112 is not limited in its use and purpose. The illustrated distributed ledger 11 includes a state DB and a transaction set DB as data sets 112 .

A state DB is a DB for managing the values or states of smart contract states (variables) at the time of a certain block. Also, the state DB stores the bytecode of the smart contract. In this embodiment, information is recorded in the state DB in units of data called tokens. Here, a token is a data structure represented by a smart contract, which has at least parameters such as "token ID" and "owner's address", and data whose transfer of the token is managed on the blockchain by the authority of the owner. indicates That is, the state DB of the present embodiment stores the value of the smart contract state (for example, the owner's address, etc.) for each token.

In the state DB of this embodiment, the block generation unit 153 of the approval terminal 2 associates the updated block number, which is the block number of the block whose state value is updated, with the updated state value for each token. is set. 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, it outputs the state value and update block number of the token.

In Ethereum, when the bytecode of a smart contract is registered in the distributed ledger 11 (state DB), identification information indicating the smart contract is given. A smart contract's identity is also called an address, as transactions can be sent to it. The difference from sending money to a user's address is that sending a transaction to a smart contract's address will cause the smart contract to be executed.

A transaction set DB is a DB that indicates 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 certain block.

Next, a process will be described in which the approval terminal 2 assigns an update block number at the time of update to the state when updating the value of the state in the state DB.

FIG. 4 is a schematic diagram for explaining the process of assigning update block numbers to state values. In the illustrated example, it is assumed that blocks up to #26001 are registered in the distributed ledger 11 of each terminal.

As described above, the distributed ledger 11 of the present embodiment stores blocks and state DBs in association with each other. In the illustrated example, the state DB 51 of block #25768, the state DB 52 of block #25770, the state DB 53 of #26000, and the state DB 54 of #26001 are shown.

Each state DB shown has a token ID, an owner address, and an update block number for each token. In this embodiment, the token ID is used as the state key, but the state key is not limited to the token ID. Also, the token may be either a non-fungible token or a fungible token.

The owner address is a state (variable). The owner address is set to the address of the token owner 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).

For example, looking at the state DB 51 of #25768, for token ID: 0005, the owner is user C, and the update block number containing the transaction updated by user C is #25007. . For token ID: 0006, the owner is user D, and the updated block number including the transaction updated by user D is #24991.

Next, in block #25769, it is assumed that the owner addresses of token IDs: 0005 and 0006 are not updated by the transactions included in that block. In this case, the update block numbers of the token IDs 0005 and 0006 of the state DB (not shown) continue to be the block numbers set to the update block number of the previous block #25768. Also, the owner addresses of token IDs: 0005 and 0006 are still set to the addresses set as the owner addresses of the previous block.

Then, the transaction contained in block #25770 updates the owner addresses of token IDs: 0005 and 0006. In this case, the approval terminal 2 updates the owner addresses of the token IDs: 0005 and 0006 and updates the update block number. Specifically, the approval terminal 2 sets the block number (#25770) of the block to the updated block number of the token IDs: 0005 and 0006.

In blocks #25771 to #25999, the owner addresses of token IDs: 0005 and 0006 are not updated by the transactions included in each block. In this case, the block number set as the update block number of the previous block is still set. That is, in the state DB of blocks #25771 to #25999, the same owner address and update block number as in the state DB 52 of #25770 are set for token IDs: 0005 and 0006.

Then, the transaction included in block #26000 updates the owner address of token ID: 0005. In this case, the approval terminal 2 updates the owner address of 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 token ID: 0006, the approval terminal 2 sets the same owner address and update block number as the previous block.

Thus, in this embodiment, the update block number is set together with the state (owner address) value for the key (token ID). As a result, in this embodiment, the user terminal 1 can obtain the latest updated block number by referring to the latest state DB 54 . For example, for token ID: 0006, #25770 can be obtained.

Then, the user terminal 1 specifies a search block number calculated from the update block number, and acquires the owner address and update block number specified by the search block number. For example, the search block number is the block number obtained by subtracting 1 from the update block number. For example, in the case of token ID: 0006, specify the search block number #25769 that is obtained by subtracting 1 from the update block number #25770, and specify the owner address (user D) and update block number (#24991) set to that block number. to get As described above, in this embodiment, by tracing only the blocks near the block in which the state value has been changed, the search cost can be greatly reduced, and the change history of the state value can be easily obtained. .

FIG. 5 is a sequence diagram showing block generation and history retrieval according to this embodiment.

In the illustrated process, user A transfers (transfers) a token to user B, and user B searches the history of the token received from user A. FIG.

The user terminal 1A of the user A generates and issues a transaction for transferring a predetermined token from the user A to the user B (S11). Specifically, the user terminal 1A broadcasts the transaction over the network 4. FIG. The transaction is thereby 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 an electronic signature. The address of the smart contract is set as the destination. The payment amount is set to the amount (commission) to be paid for executing the smart contract.

The data is populated with data that specifies executing a function that provides the ability to "move ownership of a given token to a specified address" within the smart contract. Note that the ID of the token and the address of user B are specified as arguments. A signature value obtained by signing the transaction with the secret key of user A who is the issuer of the transaction is set in the electronic signature.

Then, the approval terminal 2 (block issuing unit 15) verifies (mines) the transaction transmitted in S11 (S12). Then, the approval terminal 2 generates one block by combining the transaction with other transactions that occurred within a predetermined period of time. 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).

Here, the approval terminal 2 updates each DB in the data set of its own distributed ledger 11 based on the transaction of S11, and sets the hash value of each DB after updating to the block header of the generated block.

Also, when updating the state DB of the data set, the approval terminal 2 updates/changes the owner address of the token whose ownership has been transferred from the address of user A to the address of user B according to the transaction of S11. do. Also, in this 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 whose ownership is to be transferred is 0005 and the block to be generated is #26000, the approval terminal 2 sets the address of user B as the owner address. and set the block number #26000 as the update block number in the state DB.

Then, the approval terminal 2 sets the hash value of the updated state DB in the block header of the generated block. Note that S13 is a process performed by the terminal that has succeeded in generating the block earliest among all the terminals connected to the network.

Then, by loose synchronization between terminals, the block containing the transaction sent in S11 is reflected in the distributed ledger 11 of all terminals connected to the network 4 (S14, S15). That is, the blockchain control units 12 of all terminals add a block including the transaction of S11 to the distributed ledger 11 held by themselves. In addition, the blockchain control units 12 of all terminals update the state DB of the data set of their own distributed ledger 11 based on the transactions included in the blocks, like the approval terminal 2 .

Next, when User B, who has become the owner of the token, searches for the past history of the token transferred from User A, the process from S16 onwards is performed. Specifically, the user terminal 1B queries its own distributed ledger for the owner address (state value) of the token in the latest block (S16), and from the distributed ledger, the owner address of the latest block, An update block number is acquired (S17).

For example, when the latest block is #26001 shown in FIG. 4 and the token ID to be queried is 0005, 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 update block number. As a result, user B can confirm that he is the current token owner and that the owner has been updated in block #26000.

Then, when user B wants to search the past history of the token, user B repeats the processes of S18 and S19. That is, the user terminal 1B calculates the search block number based on the update block number obtained in S17. Here, the block number obtained by subtracting "1" from the update block number is used as the search block number. Then, the user terminal 1B designates the search block number, inquires of its own distributed ledger about the owner address of the token in the search block number (S18), the owner address in the block specified from the distributed ledger, and the update block number is acquired (S19).

For example, in the state DB of FIG. 4, if the update block number acquired in S17 is #26000 and the token ID is 0005, the user terminal 1B designates block number #259999 obtained by subtracting "1" from #26000, and distributes Query the ledger. Although the state DB of #259999 is not shown in Fig. 4, since no update for token ID: 0005 is performed from #25771 to #259999, the state of #259999 related to token ID: 0005 is the state of #25770 Same as DB52. Therefore, the user terminal 1B refers to the state DB of the distributed ledger #259999, and acquires the address of user A as the owner address and #25770 as the update block number. As a result, user B can confirm that the previous owner of token ID: 0005 was user A, and that the owner was changed to user A in block #25770. can.

Then, if the user terminal 1B wishes to search for the past history before that, the user terminal 1B repeats the processes of S18 and S19. Thereby, the user B can efficiently trace the past history of the token.

In the embodiment described above, the blockchain system includes the user terminal 1 and the approval terminal 2, and the user terminal 1 issues a transaction to update the value of the state (variable) of the smart contract. An issuing unit 13 is provided, and the approval terminal 2 generates a block containing the transaction, updates the state value, and sends the block and an update block number of the block whose state value has been updated to the blockchain system. A block generation unit 153 is provided for reflecting on the distributed ledger 11 of the terminal.

In this way, in this embodiment, when the state value of the smart contract is updated, the updated block number of the updated block is stored in the state DB of the distributed ledger 11 of each terminal. Give value. As a result, users can easily trace the history of data on the distributed ledger (blockchain) by tracing the update block number without referring to all past blocks and transactions. That is, in the present embodiment, it is possible to easily acquire the past history and transition of the value of the state of the smart contract.

Moreover, in this embodiment, traceability can be improved for smart contract users. In a 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 transitioned. Conventionally, in order to know the changed block number, it was necessary to search for all blocks or transactions, which was a heavy burden on the user. On the other hand, in this embodiment, as a change point of the state value in the state DB, the block number at the time of block creation (at the time of mining) is added to the value of the state to be tracked, thereby improving the traceability of the state. 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, A general-purpose computer system with an input device and an output device can be used. In this computer system, each function of each device is realized by the CPU executing a predetermined program loaded on the memory. For example, each function of the user terminal 1 and the approval terminal 2 is executed by the CPU of the user terminal 1 in the case of the program for the user terminal 1, and by the CPU of the approval terminal 2 in the case of the program for the approval terminal 2. It is realized by executing

In addition, the 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 HDD, SSD, USB memory, CD-ROM, DVD-ROM, MO, etc. It can also be delivered via

Moreover, the present invention is not limited to the above-described embodiments, and various modifications are possible within the scope of the gist of the present invention.

For example, in this embodiment, the approval terminal 2 sets the block number of the block whose state value has been updated in the state DB as the update block number. However, instead of the update block number, the search block number may be set in the state DB. That is, instead of the update block number, the approval terminal 2 may set the search block number obtained by subtracting "1" from the update block number in the state DB. In this case, when acquiring the past history of the state (S18 in FIG. 5), the user terminal 1 uses the search block number obtained from the distributed ledger as it is without calculating the search block number from the update block number. can trace past history.

Also, the state DB of this embodiment holds one state (owner address) as shown in FIG. 4, and holds one update block number corresponding to the state. However, the state DB may hold multiple states. In this case, when tracking each of a plurality of states, the state DB shall have an update block number for each state.

1: User terminal 2: Approval terminal 11: Distributed ledger 12: Blockchain control unit 13: Transaction issuing unit 14: History search unit 15: Block issuing unit 151: Consensus execution unit 152: Transaction verification unit 153: Block generation unit 4 : Blockchain network

Claims (9)

A blockchain system comprising a user terminal and an approval terminal,
The user terminal is
Equipped with a transaction issuing unit that issues a transaction that updates the value of the smart contract variable,
The approval terminal,
Block generation that generates a block containing the transaction, updates the value of the variable, and reflects the block and an update block number of the block in which the value of the variable is updated to a distributed ledger of a terminal of the blockchain system. A blockchain system characterized by comprising a part. The blockchain system according to claim 1,
The distributed ledger comprises a state database that stores the value of the variable for each token,
The block chain system, wherein the block generation unit sets the update block number in the state database for each token. The blockchain system according to claim 1 or 2,
The user terminal is
Obtain the update block number from the distributed ledger of its own, specify the search block number calculated from the update block number, and store the value of the variable and the update block number in the block at the time of the search block number. A blockchain system characterized by comprising a history search unit that acquires from the distributed ledger of . The blockchain system according to claim 1 or 2,
A blockchain system, wherein the block generation unit reflects a search block number calculated from the update block number in the distributed ledger of a terminal of the blockchain system, instead of the update block number. An approval terminal that approves transactions in a blockchain system,
a receiver that receives a transaction that updates the value of a smart contract variable;
Block generation that generates a block containing the transaction, updates the value of the variable, and reflects the block and an update block number of the block in which the value of the variable is updated to a distributed ledger of a terminal of the blockchain system. and an approval terminal. A user terminal in a blockchain system,
blockchain distributed ledger,
a transaction issuing unit that issues a transaction that updates the value of a smart contract variable;
Acquire the update block number of the block in which the value of the variable has been updated from the distributed ledger, specify the search block number calculated from the update block number, and execute the smart contract in the block at the time of the search block number. A user terminal, comprising: a history search unit that acquires a value of a variable and an update block number from the distributed ledger. A history management method for managing the history of a blockchain,
The user terminal
Perform a transaction issuance step to issue a transaction that updates the value of the smart contract variable,
Approved terminal
a generating step of generating a block containing the transaction and updating the value of the variable;
A history management method, characterized by performing a synchronization step of reflecting the block and the update block number of the block in which the value of the variable is updated in a distributed ledger of terminals connected to a blockchain network. 6. A history management program that causes a computer to function as the approval terminal according to claim 5. 7. A history management program that causes a computer to function as the user terminal according to claim 6.

Images