Blockchain system, block chain system update method and program

Abstract

A blockchain system according to an embodiment comprises a plurality of peers. Each peer is provided with a control unit and an execution unit. The control unit reads an effective version from a recording unit, and launches the smart contract execution software for the effective version. Upon receiving a first transaction request including data to be subjected to smart contract processing, the execution unit processes the data to be subjected to smart contract processing by executing the smart contract execution software for the effective version, and records, in the blockchain, a first transaction record including the result of processing the data to be subjected to smart contract processing.

Description

[Technical Field]

[0001] An embodiment of the present invention relates to a blockchain system, a blockchain system update method, and a program. [Background technology]

[0002] In a blockchain, a block hash is generated by incorporating the hash value of the previous block. This creates a data structure in which hash calculations are linked in a chain, making the entire chain tamper-resistant. In addition, by recording the same blockchain content on multiple peers, tamper resistance is further increased, while also increasing availability. Smart contracts are automatically executed on peers in response to transaction requests, and the execution results are also recorded on the blockchain. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Special Publication No. 2020-507140 Summary of the Invention [Problem to be solved by the invention]

[0004] However, with conventional technology, there was a risk that different versions of the software executing smart contracts would occur, leading to blockchain inconsistencies between peers. [Means for solving the problem]

[0005] The blockchain system of the embodiment is a blockchain system composed of multiple peers. Each peer includes a control unit and an execution unit. The control unit reads the effective version from the recording unit and launches the smart contract execution software of the effective version. When the execution unit receives a first transaction request including smart contract processing target data, it executes the effective version of the smart contract execution software to process the smart contract processing target data and records a first transaction record in the blockchain that includes the processing result of the smart contract processing target data. [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 is a diagram illustrating an example of a smart contract according to the first embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example of a data structure of the blockchain according to the first embodiment. [Figure 3] FIG. 3 is a diagram illustrating an example of a method for multiple execution of smart contracts according to the first embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of the device configuration of the blockchain system according to the first embodiment. [Figure 5] FIG. 5 is a diagram illustrating an example of a case where an inconsistency occurs in the blockchain between peers. [Figure 6] FIG. 6 is a diagram for explaining an outline of the blockchain system update method of the first embodiment. [Figure 7] FIG. 7 is a diagram illustrating an example of the functional configuration of a peer according to the first embodiment. [Figure 8] FIG. 8 is a flowchart showing an example of the operation of the peer according to the first embodiment. [Figure 9] FIG. 9 is a flowchart illustrating an example of the operation of the execution unit according to the first embodiment. [Figure 10] FIG. 10 is a flowchart illustrating an example of the operation of the execution unit according to the second embodiment. [Figure 11]FIG. 11 is a diagram illustrating an example of the hardware configuration of a peer according to the first and second embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0007] Hereinafter, embodiments of a blockchain system, a blockchain system update method, and a program will be described in detail with reference to the accompanying drawings.

[0008] (First embodiment) First, the smart contract of the embodiment will be described.

[0009] 1 is a diagram illustrating an example of a smart contract according to an embodiment. A smart contract is a program executed on multiple peers 20 (peers 20-1 to 20-3 in the example of FIG. 1) in response to a transaction request sent from a client device 10.

[0010] The peers 20 are server devices that store the blockchain. The same blockchain content is recorded on all peers 20. The blockchain is a ledger that contains transaction records.

[0011] In the example of FIG. 1, the transaction request is a packet including a contract ID, arguments, and a signature. The contract ID is identification information that identifies the smart contract being invoked. The arguments are parameters passed to the smart contract. The parameters include, for example, data to be processed by the smart contract. The signature is an electronic signature generated from the private key (wallet) of the client device 10, the contract ID, and the arguments.

[0012] The smart contract is executed in multiplex on all peers 20 that responded to the transaction request. In other words, the same calculation is performed on all peers 20, and the calculation results are the same.

[0013] Blockchain has a data structure in which hash calculations are linked in a chain, with each block generating a block hash that incorporates the hash value of the previous block. This makes the entire chain tamper-resistant, preventing legitimate transaction records from being rewritten later.

[0014] Figure 2 is a diagram for explaining an example of the data structure of the blockchain of the first embodiment. The blockchain has a structure in which blocks containing at least one transaction record 53 are linked together. The example in Figure 2 shows an example of a structure in which the n-1th (n is an integer of 2 or more) block n-1, the nth block n, and the n+1th block n+1 are linked together.

[0015] Block n includes data including at least a block hash 51n-1, a block number 52, and a transaction record 53, and a block hash 51n generated from the data. The block hash 51n-1 is the block hash of the block n-1 immediately before block n. The block number 52 is a number that identifies block n.

[0016] The transaction record 53 is record data including a transaction request 54 and the execution result 55 of a smart contract executed in response to the transaction request.

[0017] Each block may further include any other data. For example, transaction record 53 may further include information on the time when the transaction was processed and the time required to process the transaction.

[0018] FIG. 3 is a diagram illustrating an example of a method for multiple execution of a smart contract according to the first embodiment. In the example of FIG. 3, TX requests A and B indicate two different transaction requests. The content of the blockchain is the same for all peers 20. The consistency of the blockchain is maintained by a consensus algorithm. Any consensus algorithm may be used. The consensus algorithm guarantees the order in which transaction requests are processed (TX request A → TX request B in the example of FIG. 3), thereby maintaining the consistency of the blockchain.

[0019] [Example of equipment configuration] 4 is a diagram illustrating an example of the device configuration of the blockchain system 100 of the first embodiment. The blockchain system 100 of the first embodiment includes client devices 10-1 to 10-2, peers 20-1 to 20-3, and a control device 30.

[0020] The client devices 10-1 to 10-2, the peers 20-1 to 20-3, and the control device 30 are connected via a network 200. The communication method of the network 200 may be a wired method or a wireless method. Furthermore, the network 200 may be configured by combining a wired method and a wireless method.

[0021] The number of client devices 10-1 to 10-2 and peers 20-1 to 20-3 may be any. Hereinafter, when there is no need to distinguish between the client devices 10-1 to 10-2, they will simply be referred to as client devices 10. Similarly, when there is no need to distinguish between the peers 20-1 to 20-3, they will simply be referred to as peers 20.

[0022] The client device 10 transmits to the peer 20 a transaction request (first transaction request) including smart contract processing target data.

[0023] The peer 20 is an information processing device that executes processing in response to a transaction request. For example, the peer 20 executes smart contract execution software in response to a transaction request from the client device 10. The smart contract execution software is a program for executing a smart contract.

[0024] The control device 30 is a device that controls the blockchain system 100. For example, the control device 30 transmits a transaction request (second transaction request) including an instruction to change the effective version of the smart contract execution software to the peer 20 in response to an operation by an administrator of the blockchain system 100. The instruction to change the effective version includes, for example, an instruction to upgrade or downgrade the smart contract execution software.

[0025] In the blockchain system 100, all peers 20 process the same transaction requests and generate the same blocks. If the versions of smart contract execution software running on the peers 20 are different, there is a risk of blockchain inconsistency occurring between the peers 20.

[0026] FIG. 5 is a diagram illustrating an example of a case where a blockchain inconsistency occurs between peers 20. In the example of FIG. 5, txA to txC indicate transaction requests including data to be processed by a smart contract. The example of FIG. 5 shows a case where the smart contract execution software of only one peer, 20-1, is upgraded first before processing txB. In this case, block n+2 generated by peer 20-1 does not match block n+2 generated by peers 20-2 and 20-3, resulting in an inconsistency between the peers 20.

[0027] If block n+2 no longer matches, then blocks n+3 and beyond will also no longer match, because each block n contains the block hash 51n-1 of the previous block n-1 (see Figure 2).

[0028] When upgrading the smart contract execution software, if only one peer 20 is upgraded, there is a problem in that it is indistinguishable from a case where that peer 20 has been tampered with. Conversely, if only one peer 20 is not upgraded, there is a similar problem in that it is indistinguishable from a case where that peer 20 has been tampered with.

[0029] Furthermore, even if all peers 20 were to simultaneously upgrade, it is not guaranteed that each peer 20 would be processing the same block at that time, and so there was still a risk of inconsistencies occurring between the peers 20.

[0030] Therefore, in the blockchain system 100 of the first embodiment, when an upgrade is made effective, the control device 30 issues a special transaction request indicating the version has been made effective. Then, in response to the transaction request, the peer 20 records the version's effectiveness in the blockchain, and operates with the updated version from the block following the one recorded.

[0031] The method for recording the version's effectiveness in a block uses the same mechanism as that for processing normal transaction requests. This maintains the consistency of the transaction order between peers 20, so the record of the version's effectiveness is recorded in the same block at all peers 20. Therefore, if the version starts to be effective from the next block, the consistency of the version can be maintained.

[0032] Even if two or more transaction requests are included in the same block, the order in which the transaction requests are executed does not change among peers 20 due to the above-mentioned consensus algorithm. Therefore, if multiple transaction requests including information indicating the version is valid are included in the same block, the valid version of the transaction request that was processed last may be made valid, for example.

[0033] It should be noted that at the same time, the blocks being processed by each peer 20 may differ significantly (for example, processing by only one peer 20 may be significantly delayed), but the blockchain system 100 of the first embodiment does not pose any problems even in this case.

[0034] For example, if a peer 20 is added later, the peer 20 will process transaction requests in order from the initial block. The execution of processing by this peer 20 will be consistent with other peers 20 because the version of the smart contract execution software will be changed in accordance with the transaction request that includes information indicating the version coming into effect.

[0035] Fig. 6 is a diagram for explaining an overview of the blockchain system update method of the first embodiment. In the example of Fig. 6, txA to txC indicate transaction requests including smart contract processing target data. Version upgrade TX indicates a special transaction request indicating the effectuation of a version.

[0036] In the example of Figure 6, the upgraded smart contract execution software is installed in each peer 20 at any timing before each peer 20 receives the upgrade TX. In the blockchain system 100 of the first embodiment, the installation of the smart contract execution software and the activation of the version are managed separately. In other words, the upgraded smart contract execution software is not activated when it is installed in each peer 20.

[0037] In the example of Figure 6, when each peer 20 receives the version upgrade TX, it records the effectuation of the version in block n+2. Then, each peer 20 processes transaction requests from block n+3 onwards using the upgraded smart contract execution software. This makes it possible to manage the version of the smart contract execution software using the blockchain mechanism, thereby solving the problem shown in Figure 5 above.

[0038] [Example of functional configuration] 7 is a diagram showing an example of the functional configuration of the peer 20 according to the first embodiment. The peer 20 according to the first embodiment includes a recording unit 21, a control unit 22, and an execution unit .

[0039] First, an overview of each functional block will be described.

[0040] The recording unit 21 stores the effective version and the blockchain. The effective version indicates the version of the smart contract execution software that is currently enabled and executed by the execution unit 23. The blockchain is a ledger of transaction records recorded by the execution unit 23 in response to transaction requests.

[0041] The control unit 22 controls the execution unit 23. The control unit 22 starts up smart contract execution software to be executed by the execution unit 23, for example.

[0042] The execution unit 23 executes smart contract execution software in response to a transaction request, thereby recording the transaction record in the blockchain.

[0043] Next, the processing flow of each functional block will be described.

[0044] First, the control unit 22 reads out the effective version from the recording unit 21 (step S1). In the example of Fig. 7, it is assumed that the effective version read out by the process of step S1 is 2.

[0045] Next, the control unit 22 starts the effective version of the smart contract execution software read out by the processing of step S1 (step S2).

[0046] Next, the execution unit 23 executes the effective version of the smart contract execution software in response to the input of the transaction request (step S3).

[0047] If the transaction request input in step S3 is a transaction request (first transaction record) that includes data to be processed by a smart contract, the execution unit 23 records a transaction record (first transaction record) that includes the processing result of the data to be processed by a smart contract in the blockchain (step S4).

[0048] If the transaction request input in step S3 is a transaction request (second transaction record) including information indicating the version's effectiveness (an instruction to change the effective version), the execution unit 23 records the transaction record (second transaction record) including information indicating the version's effectiveness in the blockchain (step S4), and records (updates) the effective version in the recording unit 21 based on the change instruction (step S5).

[0049] As shown in Figure 7, the execution unit 23 has installed not only the latest version of the smart contract execution software (version 3 in the example of Figure 7), but also earlier versions (versions 1 and 2 in the example of Figure 7).

[0050] In the example of Figure 7, the latest version of the smart contract execution software is already installed, but an upgrade to the latest version has not yet been put into effect. Version 1 of the smart contract execution software is also installed. This means that by accepting a transaction request that includes an instruction to downgrade the effective version, version 1 of the smart contract execution software can be run on the execution unit 23.

[0051] The smart contract execution software may be firmware built into the peer 20.

[0052] 8 is a flowchart showing an example of the operation of the peer 20 according to the first embodiment. First, the control unit 22 reads out the effective version from the recording unit 21 and stores it in V (step S11). Here, V is a variable that stores the effective version and is used for control by the control unit 22.

[0053] Next, the control unit 22 determines whether or not there is smart contract execution software corresponding to V (step S12). That is, the control unit 22 determines whether or not the smart contract execution software of the version indicated by V has already been installed in the peer 20.

[0054] If there is smart contract execution software corresponding to V (step S12, Yes), the control unit 22 starts the smart contract execution software corresponding to V (step S13).

[0055] If there is no smart contract execution software corresponding to V (step S12, No), the control unit 22 stops the operation of the peer 20.

[0056] Fig. 9 is a flowchart showing an example of the operation of the execution unit 23 according to the first embodiment. The process of step S13 in Fig. 8 causes the execution unit 23 to start operating the smart contract execution software, and the process of the flowchart shown in Fig. 9 starts.

[0057] First, the execution unit 23 receives an input of a transaction request (step S21). Next, the execution unit 23 refers to the transaction request received in step S21 and determines whether a change in the effective version has been requested (step S22).

[0058] If a change in the effective version is not requested (step S22, No), the execution unit 23 executes the smart contract corresponding to the contract ID included in the transaction request and stores the result in the blockchain (step S23). In step S23, the smart contract corresponding to the contract ID included in the transaction request is the smart contract that processes the smart contract processing target data.

[0059] If a change in the effective version is requested (step S22, Yes), the execution unit 23 executes the smart contract corresponding to the contract ID included in the transaction request, stores the result in the blockchain, and simultaneously stores (updates) the requested effective version in the recording unit 21 (step S24). In step S24, the smart contract corresponding to the contract ID included in the transaction request is the smart contract that processes an instruction to change the version of the smart contract execution software.

[0060] In step S24, the process of storing (updating) the effective version in the recording unit 21 and the process of recording the transaction record including the version change instruction in the blockchain are executed atomically. That is, if an error occurs in either process for some reason, the execution unit 23 marks both processes as errors.

[0061] After the processing of step S24, the execution unit 23 stops the smart contract execution software, and the processing proceeds to step S11 in FIG. 8 (restarting the smart contract execution software).

[0062] For example, if a certain number (e.g., 51% or more) of peers 20 constituting a permissioned blockchain are operational, the entire system can continue processing. Therefore, the upgraded (or downgraded) smart contract execution software may be put into effect before it is installed on all peers 20.

[0063] Specifically, the control device 30 receives, for example, a notification of completion of installation of the smart contract execution software of the version specified in the change instruction from the peers 20. Then, if the number of peers 20 on which the installation has been completed is equal to or greater than a threshold value (first threshold value), the control device 30 transmits a transaction request including the change instruction for the version to the multiple peers 20.

[0064] In this case, the peers 20 that do not have the upgraded smart contract execution software installed will be unable to process the next block after the new version is released, causing the smart contract execution software to stop. However, if the new smart contract execution software is later installed on the peers 20, processing can be resumed.

[0065] As described above, in the blockchain system 100 of the first embodiment, the control unit 22 reads the effective version from the recording unit 21 and starts the smart contract execution software of that effective version. When the execution unit 23 receives a first transaction request including smart contract processing target data, it processes the smart contract processing target data by executing the effective version of the smart contract execution software. Then, the execution unit 23 records a first transaction record including the processing result of the smart contract processing target data in the blockchain.

[0066] According to the blockchain system 100 of the first embodiment, it is possible to prevent the versions of smart contract execution software from becoming different, thereby preventing inconsistencies in the blockchain between the peers 20.

[0067] For example, as shown in FIG. 6 above, by updating the version of the smart contract execution software of each peer 20, for example, it is possible to distinguish version upgrades of the smart contract execution software from tampering.

[0068] Furthermore, for example, the smart contract execution software itself can be installed separately. Specifically, it becomes possible to update the versions of the smart contract execution software of multiple peers 20 included in the blockchain system 100 by rolling updates. This makes it possible to update the version of the smart contract execution software without stopping the entire blockchain system 100, for example.

[0069] Also, for example, the administrator of the blockchain system 100 can flexibly decide when the version upgrade or version downgrade takes effect.

[0070] (Modification of the first embodiment) Next, a modified example of the first embodiment will be described. In the description of the modified example, the same explanation as in the first embodiment will be omitted, and only differences from the first embodiment will be described. In the first embodiment, for example, if a non-existent version number is mistakenly specified and the smart contract is put into effect, the smart contract execution software will stop on all peers 20.

[0071] Therefore, in the modified example, the control unit 22 records the completion of installation in the blockchain when it completes the installation of the smart contract execution software on each peer 20. When processing a transaction request for version issuance, the execution unit 23 refers to the record in the processing of the smart contract and confirms that the installation of the software on all (or a sufficient number of) the peers 20 has been completed.

[0072] If it cannot be confirmed that the installation has been completed, the execution unit 23 processes the transaction request for version activation as an error, and does not activate the version specified in the transaction request.

[0073] Specifically, in a modified example, after the installation of the smart contract execution software is completed, the control unit 22 transmits a transaction request having as arguments installation status information including identification information for identifying the peers 20 on which the smart contract execution software is installed and the version of the installed smart contract execution software. As a result, the installation status information is recorded in the blockchain. When the execution unit 23 receives a transaction request (second transaction request) including an instruction to change the effective version, the execution unit 23 identifies the number of peers 20 on which the installation has been completed from the installation status information recorded in the blockchain. Then, if the number of peers 20 on which the installation has been completed is equal to or greater than a threshold (second threshold), the execution unit 23 processes the second transaction request. If the number of peers 20 on which the installation has been completed is less than the second threshold, the execution unit 23 does not process the second transaction request.

[0074] (Second embodiment) Next, a second embodiment will be described. In the description of the second embodiment, the same explanation as in the first embodiment will be omitted, and only the differences from the first embodiment will be described. In the second embodiment, an embodiment will be described in which a version can be made effective from a block with a block number N (N is any integer equal to or greater than 1).

[0075] In the second embodiment, the argument included in the transaction request for version effectuation further includes the start block number N of the version effectuation.

[0076] Furthermore, the recording unit 21 records not only the current effective version but also the next effective version and the start block number N. The start block number N indicates the block number of the block at which processing starts in the next effective version.

[0077] The flowchart showing an example of the operation of the peer 20 in the second embodiment is the same as that in the first embodiment (see FIG. 8), and therefore a description thereof will be omitted.

[0078] Fig. 10 is a flowchart showing an example of the operation of the execution unit 23 according to the second embodiment. The process of step S13 in Fig. 8 causes the execution unit 23 to start operating the smart contract execution software, and the process of the flowchart shown in Fig. 10 starts.

[0079] First, the execution unit 23 reads the start block number from the recording unit 21 and determines whether the block number being processed is equal to or greater than the start block number (step S31).

[0080] If the block number being processed is equal to or greater than the start block number (step S31, Yes), the execution unit 23 stops the smart contract execution software (step S37), and the process proceeds to step S11 in Fig. 8 (restarting the smart contract execution software). However, step S11 in the second embodiment differs from the first embodiment in that the next effective version that is made effective from the start block number is stored in the variable V.

[0081] Next, the execution unit 23 receives an input of a transaction request (step S32). Next, the execution unit 23 refers to the transaction request received in step S32 and determines whether a change in the effective version has been requested (step S33).

[0082] If a change in the effective version is not requested (step S33, No), the execution unit 23 executes the smart contract corresponding to the contract ID included in the transaction request and stores the result in the blockchain (step S34). In step S33, the smart contract corresponding to the contract ID included in the transaction request is a smart contract that processes normal smart contract processing target data. Next, the execution unit 23 adds 1 to the block number being processed (step S35), and the process returns to step S31.

[0083] If a change in the effective version is requested (step S33, Yes), the execution unit 23 executes the smart contract corresponding to the contract ID included in the transaction request, stores the result in the blockchain, and simultaneously stores the requested effective version and the starting block number in the recording unit 21 (step S36). In step S36, the smart contract corresponding to the contract ID included in the transaction request is the smart contract that processes an instruction to change the version of the smart contract execution software. The starting block number is the block number currently being processed + N. Next, the execution unit 23 adds 1 to the block number being processed (step S35), and the process returns to step S31.

[0084] As described above, in the second embodiment, when the execution unit 23 receives a second transaction request including the next effective version and a starting block number indicating the block number of the block where processing will start in the next effective version, the execution unit 23 stores the next effective version in the recording unit 21. At the same time, the execution unit 23 records a second transaction record including the next effective version and the starting block number in the blockchain. When the execution unit 23 receives a first transaction request, if the block number of the block where the first transaction record is recorded is equal to or greater than the starting block number, the execution unit 23 stops the smart contract execution software. Then, when the smart contract execution software stops, the control unit 22 reads the next effective version from the recording unit 21 and starts the smart contract execution software of the next effective version.

[0085] Finally, an example of the hardware configuration of the peer 20 in the first and second embodiments will be described.

[0086] [Example of hardware configuration] 11 is a diagram showing an example of the hardware configuration of the peer 20 according to the first and second embodiments. The peer 20 according to the first and second embodiments includes a processor 201, a main storage device 202, an auxiliary storage device 203, a display device 204, an input device 205, and a communication device 206. The processor 201, the main storage device 202, the auxiliary storage device 203, the display device 204, the input device 205, and the communication device 206 are connected via a bus 210.

[0087] The peer 20 of the first and second embodiments may not be provided with some of the above components. For example, if the peer 20 can use the input function and display function of an external device, the peer 20 may not be provided with the display device 204 and the input device 205.

[0088] The processor 201 executes a program read from the auxiliary storage device 203 to the main storage device 202. The main storage device 202 is a memory such as a ROM and a RAM. The auxiliary storage device 203 is a hard disk drive (HDD), a memory card, or the like.

[0089] The display device 204 is, for example, a liquid crystal display. The input device 205 is an interface for operating the peer 20. The display device 204 and the input device 205 may be realized by a touch panel or the like having a display function and an input function. The communication device 206 is an interface for communicating with other devices.

[0090] The programs executed by Pier 20 are provided as computer program products recorded on computer-readable storage media such as CD-ROMs, memory cards, CD-Rs, and DVDs in the form of installable or executable files.

[0091] The program executed by the peer 20 may be stored on a computer connected to a network such as the Internet and provided by being downloaded via the network. Alternatively, the program executed by the peer 20 may be provided via a network such as the Internet without being downloaded.

[0092] The program of the peer 20 may be provided in advance by being stored in a ROM or the like.

[0093] The program executed by the peer 20 has a modular structure including functions that can be realized by the program among the functional configurations shown in Fig. 7. As for each function, the processor 201 reads the program from a storage medium and executes it, and the above-mentioned functional blocks are loaded onto the main memory device 202, in terms of actual hardware. In other words, the above-mentioned functional blocks are generated on the main memory device 202.

[0094] Note that some or all of the functions in FIG. 7 may be realized by hardware such as an IC, rather than by software.

[0095] Furthermore, each function may be realized using a plurality of processors 201, and in this case, each processor 201 may realize one of the functions, or may realize two or more of the functions.

[0096] Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included within the scope and spirit of the invention, and are also included in the scope of the invention and its equivalents as defined in the claims.

Claims

1. A blockchain system consisting of multiple peers, The peer may: a control unit that reads an effective version indicating the version of the smart contract execution software from the recording unit and starts the effective version of the smart contract execution software; an execution unit that, upon receiving a first transaction request including smart contract processing target data, processes the smart contract processing target data by executing the effective version of the smart contract execution software and records a first transaction record including a processing result of the smart contract processing target data in a blockchain; A blockchain system that includes:

2. When the execution unit receives a second transaction request including an instruction to change the effective version, the execution unit updates the effective version in the record unit based on the instruction to change, records a second transaction record including the instruction to change the effective version in the blockchain, and stops the smart contract execution software; When the smart contract execution software is stopped, the control unit reads the updated effective version from the recording unit and starts the updated effective version of the smart contract execution software. The blockchain system according to claim 1 .

3. The execution unit simultaneously updates the effective version of the recording unit and records the second transaction record in the blockchain. The blockchain system according to claim 2.

4. a control device that receives from the peers a notification of completion of installation of the smart contract execution software of the version specified in the change instruction, and sends the second transaction request to the plurality of peers if the number of the peers that have completed installation is equal to or greater than a first threshold; The blockchain system according to claim 2 or 3.

5. The instruction to change the effective version includes an instruction to upgrade the smart contract execution software. The blockchain system according to any one of claims 2 to 4.

6. The instruction to change the effective version includes an instruction to downgrade the smart contract execution software. The blockchain system according to any one of claims 2 to 4.

7. After the installation of the smart contract execution software is completed, the control unit records installation status information in the blockchain, the installation status information including identification information for identifying the peer on which the smart contract execution software is installed and the version of the installed smart contract execution software; When the execution unit receives the second transaction request, it identifies the number of the peers for which installation has been completed from the installation status information recorded in the blockchain, and processes the second transaction request if the number of the peers for which installation has been completed is equal to or greater than a second threshold, and does not process the second transaction request if the number of the peers for which installation has been completed is less than the second threshold. The blockchain system according to any one of claims 2 to 6.

8. When the execution unit receives a second transaction request including a next effective version and a starting block number indicating the block number of a block at which processing in the next effective version will start, the execution unit stores the next effective version in the recording unit and records a second transaction record including the next effective version and the starting block number in the blockchain; When the execution unit receives the first transaction request, if the block number of the block in which the first transaction record is recorded is equal to or greater than a start block number, the execution unit stops the smart contract execution software; When the smart contract execution software is stopped, the control unit reads the next effective version from the recording unit and starts the smart contract execution software of the next effective version. The blockchain system according to claim 1 .

9. The smart contract execution software is firmware embedded in the peer. The blockchain system according to any one of claims 1 to 8.

10. A blockchain system update method for a blockchain system configured with multiple peers, comprising: The peer reads from the recorder an effective version indicating the version of the smart contract execution software, and launches the effective version of the smart contract execution software; When the peer receives a first transaction request including smart contract processing target data, the peer executes the effective version of the smart contract execution software to process the smart contract processing target data, and records a first transaction record in the blockchain that includes a processing result of the smart contract processing target data; A method for updating a blockchain system, including:

11. The multiple peers that make up a blockchain system are a control unit that reads an effective version indicating the version of the smart contract execution software from the recording unit and starts the effective version of the smart contract execution software; an execution unit that, upon receiving a first transaction request including smart contract processing target data, processes the smart contract processing target data by executing the effective version of the smart contract execution software and records a first transaction record including a processing result of the smart contract processing target data in a blockchain; A program to function as a

Images