WO2020213678A1 - 制御方法、サーバ、及び、データ構造 - Google Patents

制御方法、サーバ、及び、データ構造 Download PDF

Info

Publication number
WO2020213678A1
WO2020213678A1 PCT/JP2020/016705 JP2020016705W WO2020213678A1 WO 2020213678 A1 WO2020213678 A1 WO 2020213678A1 JP 2020016705 W JP2020016705 W JP 2020016705W WO 2020213678 A1 WO2020213678 A1 WO 2020213678A1
Authority
WO
WIPO (PCT)
Prior art keywords
contract
transaction data
smart contract
distributed ledger
server
Prior art date
Application number
PCT/JP2020/016705
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 CN202080027819.0A priority Critical patent/CN113785316A/zh
Priority to JP2021514213A priority patent/JPWO2020213678A1/ja
Publication of WO2020213678A1 publication Critical patent/WO2020213678A1/ja
Priority to US17/497,302 priority patent/US11809413B2/en
Priority to US18/377,085 priority patent/US20240037093A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • This disclosure relates to control methods, servers, and data structures.
  • Smart contract technology is known as a mechanism for programming contracts on the blockchain.
  • a smart contract can be executed by being included in a block such as a blockchain and recording the block in a distributed ledger. Therefore, by using a smart contract, it is possible to automatically execute contract actions such as confirmation or fulfillment of contract conditions if certain conditions are met, without tampering with the contract.
  • Patent Document 1 discloses a mechanism that enables operation management with uniform policies or timings between nodes even when there are a plurality of administrators in a distributed ledger system by using a smart contract.
  • This disclosure was made in view of the above circumstances, and provides a control method and the like that can further reduce the time cost and the energy cost by using the distributed ledger.
  • control method is a plurality of control methods that manage a terminal operated by a user and a distributed ledger, respectively, and manage a smart contract using the distributed ledger.
  • the first transaction data including the first electronic signature to be attached is received, the block containing the first transaction data is recorded in the distributed ledger, and the contents of the first contract and the contents of the first contract are described in the first smart contract.
  • the tentatively determined variables used to identify the second smart contract corresponding to the second contract which is a sub-contract with the first contract as the main contract and is to be newly concluded, and the above. It includes the conditions under which the second smart contract is created.
  • the time cost and the energy cost can be further reduced by using the distributed ledger.
  • FIG. 1 is a block diagram schematically showing a configuration of a control system according to an embodiment.
  • FIG. 2 is a block diagram schematically showing a server configuration according to the embodiment.
  • FIG. 3 is an explanatory diagram showing a data structure of the blockchain.
  • FIG. 4 is an explanatory diagram showing a data structure of transaction data.
  • FIG. 5 is a sequence diagram for explaining the process until the first smart contract in the embodiment is activated.
  • FIG. 6 is a diagram conceptually showing the contents of the first smart contract in the embodiment.
  • FIG. 7 is a sequence diagram for explaining the process until the second smart contract in the embodiment is activated.
  • FIG. 8 is a diagram conceptually showing the contents of the second smart contract in the embodiment.
  • FIG. 1 is a block diagram schematically showing a configuration of a control system according to an embodiment.
  • FIG. 2 is a block diagram schematically showing a server configuration according to the embodiment.
  • FIG. 3 is an explanatory diagram showing a data structure of the blockchain.
  • FIG. 9 is a sequence diagram for explaining the process until the third smart contract in the embodiment is activated.
  • FIG. 10 is a diagram conceptually showing the contents of the third smart contract in the embodiment.
  • FIG. 11A is a sequence diagram for explaining the process until the second smart contract is operated in the first modification of the embodiment.
  • FIG. 11B is a sequence diagram for explaining the process until the second smart contract is operated in the first modification of the embodiment.
  • FIG. 12A is a sequence diagram for explaining the process until the second smart contract operates in the second modification of the embodiment.
  • FIG. 12B is a sequence diagram for explaining the process until the second smart contract is operated in the second modification of the embodiment.
  • FIG. 13A is a sequence diagram for explaining the process until the second smart contract operates in the third modification of the embodiment.
  • FIG. 13B is a sequence diagram for explaining the process until the second smart contract operates in the third modification of the embodiment.
  • FIG. 14 is a sequence diagram for explaining the process until the third smart contract is operated in the modified example 4 of the embodiment.
  • the control method is in a system including a terminal operated by a user and a plurality of servers that each manage a distributed ledger and manage smart contracts using the distributed ledger. It is a control method executed by the first server among the plurality of servers, and corresponds to the first contract from the first terminal operated by the first user who is one of the contractors of the first contract.
  • a first smart contract which is a first smart contract in which the contract action of the first contract is executably programmed using the distributed ledger, and a first electronic signature associated with the first user.
  • the first transaction data including the first transaction data is received, the block containing the first transaction data is recorded in the distributed ledger, and the contents of the first contract and the first contract are the main contracts in the first smart contract.
  • a tentatively determined variable used to identify a second smart contract corresponding to a second contract that is a sub-contract and is to be newly concluded, and the second smart contract are created. Conditions and are included.
  • the first smart contract corresponding to the first contract that may be discussed separately in the future, and the second smart corresponding to the second contract that can be concluded by the separate consultation specified in the first contract include a variable as an alternative to the contract address of the contract.
  • a separate consultation that may occur in the future can be expressed in the first smart contract. Therefore, the use of smart contracts for contracts that may be discussed separately in the future is promoted, the merit of automating contract behavior, that is, fraud prevention, and the reduction of time cost and energy cost by not going through an intermediary. Can be planned.
  • the validity of the first transaction data is given together with a plurality of second servers other than the first server among the plurality of servers.
  • a first consensus algorithm is executed to agree on the above, and when the validity of the first transaction data is agreed by the first consensus algorithm, a block containing the first transaction data is recorded in the distributed ledger.
  • control method is the second smart contract corresponding to the second contract from the first terminal, and a program that enables execution of the contract action of the second contract by using the distributed ledger.
  • the second transaction data including the second smart contract and the second electronic signature associated with the first user is received, the block containing the second transaction data is recorded in the distributed ledger, and the above.
  • the second smart contract includes at least the contents of the second contract and the first contract address of the first smart contract as information indicating the link destination of the second smart contract.
  • control method when the control method receives the second transaction data, the control method further refers to the first contract address to specify the condition included in the first smart contract and receives the second transaction data. If the above conditions are satisfied, the second consensus algorithm is executed.
  • the second smart contract includes the variable in addition to the contents of the second contract and the first contract address.
  • the first smart contract refers to the first contract address included in the second transaction data. Is specified, and the contents of the first contract, the variables, and the conditions are acquired from the specified first smart contract, and the contents of the first contract, the conditions, and the variables are replaced.
  • a third smart contract including the second contract address of the second transaction data and corresponding to the first contract is created, and the created third smart contract is linked to the first server.
  • the third transaction data including the attached third electronic signature is generated, and the block including the third transaction data is recorded in the distributed ledger.
  • the validity of the third transaction data is agreed with a plurality of second servers other than the first server among the plurality of servers.
  • the third consensus algorithm for the purpose is executed and the validity of the third transaction data is agreed by the third consensus algorithm, the block containing the third transaction data is recorded in the distributed ledger.
  • control method further causes the working memory of the first server to hold information indicating that the latest smart contract for the first contract is the third smart contract.
  • the server is in a system including a terminal operated by a user and a plurality of servers that each manage a distributed ledger and manage a smart contract using the distributed ledger.
  • a server that is one of the plurality of servers, a processor, a memory that stores a program that causes the processor to execute a process, and a storage device that stores the distributed ledger in which a smart contract is stored.
  • the processor is a first smart contract corresponding to the first contract from a first terminal operated by a first user who is one of the contractors of the first contract, and the distributed ledger is displayed.
  • the processor receives first transaction data including a first smart contract programmed to execute the contract action of the first contract by using the first electronic signature associated with the first user.
  • the block containing the first transaction data is recorded in the distributed ledger, and the contents of the first contract and the second contract, which is a sub-contract with the first contract as the main contract, are included in the first smart contract. It includes a tentatively determined variable used to identify a second smart contract corresponding to the second contract that is to be newly concluded, and a condition for creating the second smart contract.
  • control system 1 of the present disclosure can include a mechanism in which the smart contract corresponding to the first contract stored in the distributed ledger can be dealt with even if a separate consultation specified in the first contract occurs in the future. As a result, it is possible to promote the use of smart contracts corresponding to the first contract, which may be discussed separately in the future.
  • FIG. 1 is a block diagram schematically showing the configuration of the control system 1 according to the present embodiment.
  • the control system 1 includes servers 10A, 10B and 10C, and terminals 40 and 41 operated by the user. These are communicably connected via network N.
  • the network N may be composed of any communication line or network, and includes, for example, the Internet, a carrier network of a mobile phone, and the like.
  • the servers 10A, 10B and 10C are also referred to as "server 10A and the like", and the terminals 40 and 41 are also referred to as "terminal 40 and the like".
  • FIG. 1 shows an example in which the control system 1 includes three servers and two terminals, but the present invention is not limited to this. That is, the control system 1 may include four or more servers, or may include three or more terminals.
  • Terminal 40 The terminals 40 and 41 operate independently and are operated by their respective users.
  • the terminal 40 is a terminal operated by the first user.
  • the terminal 40 is a first terminal operated by a first user who is one of the contractors of the first contract, which is a contract that may be discussed separately in the future.
  • the terminal 40 is, for example, a personal computer, a smartphone, a tablet, or the like.
  • the terminal 40 is a terminal capable of communicating with the server 10A or the like via the network N, and is a terminal used and operated by Mr. A, who is the first user.
  • the terminal 40 creates a smart contract according to the user's operation.
  • the terminal 40 When the terminal 40 creates a smart contract, it generates transaction data including the created smart contract and transmits the generated transaction data to the server 10A or the like.
  • the terminal 40 is a first smart contract corresponding to the first contract by the operation of Mr. A, who is the first user, and is programmed so that the contract action of the first contract can be executed by using the distributed ledger.
  • Create the first smart contract corresponds to the contents of the first contract and the second contract, which is a sub-contract with the first contract as the main contract and is scheduled to be newly concluded. It contains a tentatively determined variable used to identify the second smart contract to be created and the conditions under which the second smart contract is created.
  • the second contract is a sub-contract with the first contract as the main contract, which is concluded by conducting separate consultations specified in the first contract.
  • the terminal 40 receives the input of the electronic signature of Mr. A, who is the first user, and the instruction to generate the transaction data
  • the terminal 40 receives the electronic signature of Mr. A and the first transaction data including the created first smart contract.
  • the terminal 40 generates the first transaction data including the created first smart contract and the first electronic signature associated with the first user.
  • the terminal 40 transmits the generated first transaction data to the server 10A or the like.
  • the terminal 40 is a second smart contract corresponding to the second contract concluded separately by the operation of Mr. A, and the contract action of the second contract can be executed by using the distributed ledger.
  • the second smart contract created includes at least the contents of the second contract and the first contract address of the first smart contract as information indicating the link destination of the second smart contract.
  • the second smart contract may include the above variables in addition to the contents of the second contract and the first contract address.
  • the terminal 40 receives the input of the electronic signature of Mr. A, who is the first user, and the instruction to generate the transaction data
  • the terminal 40 receives the electronic signature of Mr. A and the second transaction data including the created second smart contract.
  • the terminal 40 generates the first transaction data including the created second smart contract and the second electronic signature associated with the first user.
  • the terminal 40 transmits the generated second transaction data to the server 10A or the like.
  • the first electronic signature and the second electronic signature may be the same or different as long as they are associated with the first user.
  • the terminal 41 is a terminal operated by a second user. In the present embodiment, it is one of the contractors of the first contract, and is a second terminal operated by a second user who separately discusses with the first user.
  • the terminal 41 is, for example, a personal computer, a smartphone, a tablet, or the like.
  • the terminal 41 is a terminal capable of communicating with the server 10A or the like via the network N, and is a terminal used and operated by Mr. B, who is a second user.
  • Each of the plurality of servers 10A, 10B, and 10C manages the distributed ledger and manages the smart contract by using the distributed ledger.
  • the servers 10A, 10B, and 10C are connected to each other so as to be able to communicate with each other via the network N, and operate independently. Since the servers 10A, 10B, and 10C have the same configuration, the server 10A will be described below as an example. In addition, another server (server 10B or 10C) may perform the above-mentioned processing.
  • FIG. 2 is a block diagram schematically showing the configuration of the server 10A in the present embodiment.
  • Server 10A is an example of the first server.
  • the server 10A includes a processing unit 11, a ledger management unit 12, a control unit 13, and a working memory 17.
  • These functional units included in the server 10A can be realized by, for example, a CPU (Central Processing Unit) executing a program using a memory.
  • a CPU Central Processing Unit
  • the processing unit 11 is a processing unit that manages various types of information using a distributed ledger.
  • the processing unit 11 provides the received or acquired transaction data to the ledger management unit 12 when the transaction data is received from the device in the control system 1 or when the transaction data generated by the control unit 13 is acquired. Store in the distributed ledger with.
  • This transaction data includes the first transaction data to the seventh transaction data, which will be described later.
  • the ledger management unit 12 is a processing unit that manages the distributed ledger. Specifically, when the ledger management unit 12 receives transaction data, it transfers the received transaction data to a plurality of other servers and stores the received transaction data in the distributed ledger.
  • the ledger management unit 12 stores the transaction data provided by the processing unit 11 in the distributed ledger. Transaction data from the past to the present is stored in the distributed ledger. In the distributed ledger, the above transaction data is managed so as not to be falsified based on the characteristic that it is difficult to falsify the information recorded in the distributed ledger.
  • the ledger management unit 12 has a storage unit 15 and a ledger storage unit 16.
  • the storage unit 15 is a processing unit that stores new transaction data to be stored in the distributed ledger in the ledger storage unit 16.
  • the storage unit 15 generates a block containing new transaction data, synchronizes the generated block with the server 10A and the like, and then stores the block in the ledger storage unit 16.
  • the storage unit 15 when the storage unit 15 receives the transaction data from the processing unit 11, it verifies the electronic signature included in the received transaction data and verifies the validity of the transaction data. Note that this verification may be skipped.
  • the storage unit 15 transfers the transaction data to the plurality of other servers 10B and 10C.
  • the storage unit 15 then, together with the plurality of other servers 10B and 10C, executes a consensus algorithm for agreeing on the validity of the transaction data.
  • the storage unit 15 records the block containing the transaction data in the distributed ledger.
  • the storage unit 15 When the storage unit 15 receives the second transaction data including the second smart contract corresponding to the second contract by the separate consultation from the processing unit 11, the storage unit 15 is the main contract of the second contract which is the sub-contract by the separate consultation. Identify the conditions contained in the first smart contract that corresponds to a first contract. In this case, the storage unit 15 performs a consensus algorithm when the verification of the electronic signature included in the received second transaction data and the verification of the validity of the second transaction data are successful, and when the conditions are satisfied. You may do it. If the verification of the second transaction data is skipped, the storage unit 15 may receive the second transaction data and execute the consensus algorithm when the condition is satisfied.
  • the storage unit 15 independently processes the block including the first smart contract corresponding to the first contract and the block including the second smart contract corresponding to the second contract, and distributes the ledger. Record in. Further, when the storage unit 15 receives the block including the third smart contract, which is a new smart contract corresponding to the first contract generated by the control unit 13, the storage unit 15 records the block including the third smart contract in the distributed ledger.
  • the ledger storage unit 16 is a storage device that stores the distributed ledger.
  • the ledger storage unit 16 is realized by an HDD (Hard Disk Drive), an SSD (Solid State Drive), or the like.
  • the distributed ledger stored in the ledger storage unit 16 contains one or more transaction data in a block and is electronically recorded, and is managed so as to be difficult to falsify by using characteristics such as a hash value. The details will be described later. Further, one or more smart contracts are stored in the distributed ledger stored in the ledger storage unit 16. For example, a program code called a contract code is stored in the distributed ledger, and a smart contract may be realized by executing this contract code. The contract code is the code executed to execute the contract action described in the smart contract.
  • the distributed ledger stored in the ledger storage unit 16 employs, for example, a blockchain method as a blockchain mounting platform that realizes distributed ledger management. Not limited to. Other methods such as IOTA or hash graphs may be employed.
  • PBFT Practical Byzantine Falternation
  • POS Proof Of Stake
  • the storage unit 15 first receives reports from each of the plurality of other servers 10B and 10C indicating whether or not the transaction verification is successful, and the number of such reports is a predetermined number. Judge whether or not it exceeds. Then, when the number of reports exceeds a predetermined number, the storage unit 15 may determine that the validity of the transaction data has been verified by the consensus algorithm.
  • distributed ledger technology such as Hyperledger fabric may be used.
  • the control unit 13 is a processing unit that controls various processes.
  • Part or all of the processing of the control unit 13 may be performed by executing the contract action described in the smart contract stored in the ledger storage unit 16.
  • the control unit 13 may realize the smart contract by executing the contract code stored in the ledger storage unit 16, that is, the contract action described in the smart contract may be executed as the above processing.
  • control unit 13 creates a new smart contract corresponding to the main contract, which reflects information on the smart contract corresponding to the sub-contract concluded by the separate consultation of the main contract.
  • the control unit 13 generates transaction data including the created new smart contract and transmits it to the processing unit 11.
  • the control unit 13 when the block including the second transaction data is recorded in the distributed ledger, the control unit 13 first refers to the first contract address included in the second transaction data and corresponds to the first contract. Identify the first smart contract to do. Next, the control unit 13 acquires the contents of the first contract, the variables, and the conditions from the specified first smart contract. Next, the control unit 13 is a new smart contract including the contents of the first contract, the conditions, and the second contract address of the second transaction data instead of the variables, and the third smart contract corresponding to the first contract. To create. Then, the control unit 13 generates a third transaction data including the created third smart contract and the third electronic signature associated with the server 10A, and transmits the third transaction data to the processing unit 11.
  • the working memory 17 is a memory that functions as an on-memory of the server 10A.
  • the working memory 17 reads the block recorded in the distributed ledger and holds the latest smart contract for the first contract.
  • the working memory 17 may hold information indicating the latest smart contract for the first contract. For example, when the third smart contract is the latest smart contract, the working memory 17 may hold information indicating that the latest smart contract for the first contract is the third smart contract.
  • FIG. 3 is an explanatory diagram showing the data structure of the blockchain.
  • a blockchain is a block that is a recording unit connected in a chain.
  • Each block has a plurality of transaction data and a hash value of the immediately preceding block.
  • the block B2 contains the hash value of the previous block B1.
  • the hash value calculated from the plurality of transaction data included in the block B2 and the hash value of the block B1 is included in the block B3 as the hash value of the block B2.
  • FIG. 4 is an explanatory diagram showing a data structure of transaction data.
  • the transaction data shown in FIG. 4 includes a transaction body P1 and a digital signature P2.
  • the transaction body P1 is a data body included in the transaction data.
  • the electronic signature P2 is generated by signing the hash value of the transaction body P1 with the signature key of the creator of the transaction data, and more specifically, encrypting it with the private key of the creator. is there.
  • the processing until the first smart contract, the second smart contract, and the third smart contract are operated will be described with reference to the sequence diagram.
  • the first smart contract will be referred to as the first smart contract X ver1
  • the second smart contract will be referred to as the second smart contract Y n
  • the third smart contract will be referred to as the third smart contract X ver2 .
  • FIG. 5 is a sequence diagram for explaining the process until the first smart contract X ver1 in the present embodiment is operated.
  • FIG. 6 is a diagram conceptually showing the contents of the first smart contract X ver1 in the present embodiment.
  • the terminal 40 sets the first smart contract X ver1 corresponding to the first contract by the operation of the first user, that is, Mr. A, who is one of the contractors of the first contract that may be discussed separately in the future.
  • the first smart contract X ver1 is a smart contract programmed so that the contract behavior of the first contract can be executed by using the distributed ledger.
  • the contents shown in FIG. 6 are input. That is, in the first smart contract X ver1 , the contents of the first contract, the destination of the separate discussion, and the conditions for creating the second smart contract are input. In the example shown in FIG.
  • variable xx a tentatively determined variable used for specifying the second smart contract corresponding to the second contract, such as “variable xx”, is shown as a separate destination for discussion.
  • the terminal 40 generates the first transaction data including the first smart contract X ver1 created in step S101 and the first electronic signature associated with the first user, Mr. A (S102).
  • the terminal 40 transmits the first transaction data generated in step S102 to, for example, the server 10A (S103).
  • the terminal 40 may transmit the first transaction data generated in step S102 to the server 10B or the server 10C.
  • the operation of the server 10A described below becomes the operation of the server 10B or the server 10C.
  • the server 10A verifies the first transaction data received from the terminal 40 (S104). More specifically, the server 10A verifies the first electronic signature included in the first transaction data received from the terminal 40 and verifies the validity of the first transaction data. Note that step S104 may be skipped.
  • step S104 if the verification of the first transaction data is not successful (N in S104), the server 10A notifies the terminal 40 of an error (S105) and ends this process.
  • step S104 when the verification of the first transaction data is successful (Y in S104), the server 10A transfers the first transaction data to the plurality of other servers 10B and 10C (S106). If step S104 is skipped, the server 10A may transfer the first transaction data received from the terminal 40 to the plurality of other servers 10B and 10C. Then, the servers 10B and 10C verify the first transaction data transferred and received, respectively.
  • the server 10A, the server 10B, and the server 10C execute the consensus algorithm (S107).
  • the consensus algorithm of step S107 corresponds to the first consensus algorithm for agreeing on the validity of the first transaction data.
  • the server 10A, the server 10B, and the server 10C execute a consensus algorithm and verify that the received first transaction data is legitimate transaction data (that is, legitimacy), they each include a block containing the first transaction data. Generate. Then, the servers 10A, 10B, and 10C record the block including the first transaction data in the distributed ledger.
  • the first smart contract X ver1 created by the terminal 40 in this way is recorded in the distributed ledger.
  • the first smart contract X ver1 becomes executable, that is, operates by being recorded in the distributed ledger (S108).
  • the first smart contract X ver1 recorded in the distributed ledger is when transaction data including the first contract address of the first smart contract X ver1 is received from another device or the like and recorded in the distributed ledger. It may be executed.
  • FIG. 7 is a sequence diagram for explaining the process until the second smart contract Y n in the present embodiment is activated.
  • FIG. 8 is a diagram conceptually showing the contents of the second smart contract Y n in the present embodiment.
  • the terminal 40 is a second smart contract for the second contract concluded by the separate consultation.
  • Check if Y n can be created (S202).
  • Terminal 40 determines that if the number of several or second smart contract Y n of the second contract is a secondary subscriber of the first contract is below a predetermined value, may create a second smart contract Y n .. This is to set a limit on the number of the second contract, which is a sub-contract (separate contract) of the first contract.
  • step S202 when it is confirmed that the terminal 40 can create the second smart contract Y n (Y in S202), the terminal 40 is operated by Mr. A, who is one of the contractors of the second contract concluded separately. 2 Create a second smart contract Y n corresponding to the contract (S203).
  • the second smart contract Y n is a smart contract programmed so that the contract behavior of the second contract can be executed by using the distributed ledger.
  • the content shown in FIG. 8 is input to the second smart contract Y n . That is, the content of the second contract and the link destination are input to the second smart contract Y n .
  • FIG. 8 the content shown in FIG. 8 is input to the second smart contract Y n . That is, the content of the second contract and the link destination are input to the second smart contract Y n .
  • the link destination is the first smart contract X ver1 .
  • the string Hazuki destination in order to indicate that the string Hazuki destination is the first smart contract X ver1, the string Hazuki destination, first contract addresses of the first smart contract X ver1 it is input.
  • the cord Hazuki destination in addition to the first contract addresses of the first smart contract X ver1, xx variable included in the first smart contract X ver1 may be input. It should be noted that the content input as the link destination does not matter as long as the variable xx included in the first smart contract X ver1 can be specified.
  • the terminal 40 generates the second transaction data including the second smart contract Y n created in step S203 and the second electronic signature associated with the first user, Mr. A (S204).
  • the terminal 40 transmits the second transaction data Y n generated in step S204 to, for example, the server 10A (S205).
  • the terminal 40 may transmit the second transaction data generated in step S204 to the server 10B or the server 10C.
  • the operation of the server 10A described below becomes the operation of the server 10B or the server 10C.
  • the server 10A verifies the second transaction data received from the terminal 40 (S206). More specifically, the server 10A verifies the second electronic signature included in the second transaction data received from the terminal 40 and verifies the validity of the second transaction data. Note that step S206 may be skipped.
  • step S206 if the verification of the second transaction data is not successful (N in S206), the server 10A notifies the terminal 40 of an error (S207) and ends this process.
  • step S206 when the verification of the second transaction data is successful (Y in S206), the server 10A transfers the second transaction data to the plurality of other servers 10B and 10C (S208). If step S206 is skipped, the server 10A may transfer the second transaction data received from the terminal 40 to the plurality of other servers 10B and 10C. Then, the servers 10B and 10C each verify the second transaction data transferred and received.
  • the server 10A, the server 10B, and the server 10C execute the consensus algorithm (S209).
  • the consensus algorithm of step S209 corresponds to the second consensus algorithm for agreeing on the validity of the second transaction data.
  • the server 10A, the server 10B, and the server 10C execute a consensus algorithm to verify that the received second transaction data is legitimate transaction data (that is, legitimacy), they each block a block containing the second transaction data. Generate. Then, the servers 10A, 10B, and 10C record the block including the second transaction data in the distributed ledger.
  • the second smart contract Y n created by the terminal 40 in this way is recorded in the distributed ledger.
  • the second smart contract Y n becomes feasible, that is, operates by being recorded in the distributed ledger (S210).
  • the second smart contract Y n recorded in the distributed ledger is when transaction data including the second contract address of the second smart contract Y n is received from another device or the like and recorded in the distributed ledger. It may be executed.
  • FIG. 9 is a sequence diagram for explaining the process until the third smart contract X ver2 in the present embodiment is operated.
  • FIG. 10 is a diagram conceptually showing the contents of the third smart contract X ver2 in the present embodiment.
  • the server 10A confirms whether or not the second smart contract Y n has been created (Y in S301), it confirms whether or not the second smart contract Y n is associated with another smart contract (S302). ..
  • the server 10A confirms the distributed ledger managed by itself, and confirms whether or not the second smart contract Y n is recorded.
  • the server 10A confirms the second smart contract Y n recorded in the distributed ledger, and confirms whether or not a portion indicating that it is linked to another smart contract is included.
  • step S302 when the server 10A confirms that the second smart contract Y n is associated with another smart contract (Y in S302), the server 10A identifies the smart contract associated with the second smart contract Y n. (S303).
  • the server 10A specifies the first contract address included in the second transaction data Y n by referring to the contents of the second smart contract Y n as shown in FIG.
  • the server 10A specifies the first smart contract X ver1 with reference to the specified first contract address.
  • step S302 when the server 10A confirms that the second smart contract Y n is not associated with another smart contract (N in S302), the server 10A ends this process.
  • the server 10A acquires the contents of the first contract and the like from the specified first smart contract X ver1 (S304).
  • the server 10A has the contents of the first contract, the tentatively determined variables used to specify the second smart contract Y n , and the second smart from the specified first smart contract X ver1. Gets the conditions under which the contract Y n is created.
  • the server 10A creates a third smart contract X ver2 corresponding to the first contract (S305).
  • the third smart contract X ver2 is a smart contract in which the contract actions between the second contract and the first contract, which are separately concluded in the consultation, are programmed by using the distributed ledger.
  • the second smart contract Y n corresponding to the second contract is expressed as a jump destination, and by jumping to the second smart contract Y n , the contract action of the second contract can be executed.
  • the content shown in FIG. 10 is input to the third smart contract X ver2 .
  • Jump is to indicate a second smart contract Y n, the jump, the second contract address of the second smart contract Y n are input. It should be noted that the mode of what is input to the destination of the discussion separately is not limited as long as it can be used to specify the second smart contract Y n .
  • the server 10A generates a third transaction data including the third smart contract X ver2 created in step S305 and the third electronic signature associated with the server 10A (S306).
  • the server 10A transfers the third transaction data generated in step S306 to the plurality of other servers 10B and 10C (S307). Then, the servers 10B and 10C each verify the transferred and received third transaction data.
  • the server 10A, the server 10B, and the server 10C execute the consensus algorithm (S308).
  • the consensus algorithm of step S308 corresponds to the third consensus algorithm for agreeing on the validity of the third transaction data.
  • the server 10A, the server 10B, and the server 10C execute a consensus algorithm and verify that the received third transaction data is legitimate transaction data (that is, legitimacy), they each block a block containing the third transaction data. Generate. Then, the servers 10A, 10B, and 10C record the block including the third transaction data in the distributed ledger.
  • the server 10A jumps to the second smart contract corresponding to the second contract, which is a sub-contract with the first contract as the main contract concluded separately for the first smart contract X ver1 .
  • the third smart contract X ver2 becomes executable, that is, operates by being recorded in the distributed ledger (S309).
  • the contract action between the first contract and the second contract concluded in a separate consultation becomes feasible.
  • a separate consultation may be concluded with the first smart contract corresponding to the first contract that may occur in the future by the separate consultation specified in the first contract. Include a variable as an alternative to the contract address of the second smart contract that corresponds to the second contract.
  • the first smart contract is created, the second smart contract is not created and the contract address is not determined, so a variable as an alternative is included.
  • a separate consultation that may occur in the future can be expressed in the first smart contract.
  • the control method, etc. of the present disclosure is a new third smart contract corresponding to the first contract that reflects the jump destination to the second smart contract corresponding to the second contract concluded separately by consultation with the first smart contract. Create in and record in the distributed ledger.
  • the time cost and the energy cost can be further reduced by using the distributed ledger.
  • condition for creating the second smart contract has been described as the case where the second contract is concluded as a sub-contract with the first contract as the main contract by separate consultation. Not limited to.
  • the condition may further include obtaining the consent of a user who operates a terminal 41 other than the terminal 40 that created the second smart contract.
  • the conditions may further include obtaining the agreement of the user who operates the terminal 40 that created the second smart contract and the agreement of the user who operates the terminal 41.
  • the server 10A may create a third smart contract that reflects the jump destinations to a plurality of second smart contracts separately concluded in the first smart contract and record it in the distributed ledger.
  • Modification example 1 In the first modification, as a condition for creating the second smart contract, in addition to the case where the second contract is concluded by separate consultation, the agreement of the user who operates the terminal 41 other than the terminal 40 that created the second smart contract. The case including taking is described.
  • FIG. 11A and 11B are sequence diagrams for explaining the process until the second smart contract Y n is operated in the first modification of the present embodiment.
  • the first smart contract will be referred to as the first smart contract X ver1
  • the second smart contract will be referred to as the second smart contract Y n .
  • the contents of the second smart contract Y n in this modification are as described with reference to FIG.
  • sequence diagram shown in FIG. 11A As compared with the sequence diagram shown in FIG. 7, the subject for confirming whether or not the second smart contract Y n may be created is changed to the server 10A, and the terminal 41 It differs in that it takes a request for confirmation of agreement with.
  • the sequence diagram shown in FIG. 11B is different from the sequence diagram shown in FIG. 7 in that transaction data showing the agreement confirmation result of Mr. B is further recorded in the distributed ledger.
  • FIG. 11A first, as in FIG. 7, it is assumed that the terminal 40 is input by the operation of Mr. A that there has been a separate consultation prescribed in the first contract (Y in S301).
  • the terminal 40 creates a second smart contract Y n corresponding to the second contract by the operation of Mr. A, who is one of the contractors of the second contract concluded by the separate consultation (S304).
  • the server 10A determines in step S302 whether or not the second smart contract Y n for the second contract that can be concluded separately by consultation may be created.
  • the second smart contract Y n created by the terminal 40 in step S304 is the nth second smart contract, and n is not more than a predetermined value.
  • step S302 the server 10A determines that the second smart contract Y n may be created (Y in S302), and transmits a notification indicating that the creation is OK to the terminal 40 (S303). .. If steps S302 and S303 are performed before step S304, they may be performed before step S301 or may be performed between step S301 and step S304.
  • the terminal 40 generates the second transaction data including the second smart contract Y n created in step S304 and the second electronic signature associated with the first user, Mr. A (S305).
  • the terminal 40 transmits the second transaction data generated in step S305 to, for example, the server 10A (S306).
  • the terminal 40 may transmit the second transaction data generated in step S305 to the server 10B or the server 10C.
  • the operation of the server 10A described below becomes the operation of the server 10B or the server 10C.
  • the server 10A verifies the second transaction data received from the terminal 40 (S307). Since steps S307 and S308 are the same processes as steps S206 and S207 of FIG. 7, specific description thereof will be omitted.
  • step S307 when the verification of the second transaction data is successful (Y in S307), the server 10A refers to its own distribution ledger and specifies the condition for creating the second smart contract Y n (S309). .. More specifically, the server 10A refers to the first smart contract X ver1 recorded in its own distributed ledger, and conditions for creating the second smart contract Y n included in the first smart contract X ver1. To identify. In this modification, in addition to the case where the second contract is concluded by separate consultation, the conditions require the consent of the user who operates the terminal 41 other than the terminal 40 that created the second smart contract Y n. include.
  • the server 10A transmits an agreement confirmation request for the created second smart contract Y n to the terminal 41 according to the conditions specified in step S309 (S310).
  • the agreement confirmation result for the created second smart contract Y n is input to the terminal 41 by the operation of Mr. B, who is a party to the second contract concluded separately. Then, the terminal 41 generates the fourth transaction data including the agreement confirmation result and the electronic signature associated with Mr. B (S311).
  • the terminal 41 transmits the fourth transaction data generated in step S311 to, for example, the server 10A (S312).
  • the terminal 41 may transmit the fourth transaction data generated in step S311 to the server 10B or the server 10C.
  • the operation of the server 10A described below becomes the operation of the server 10B or the server 10C.
  • the server 10A refers to the agreement confirmation result of Mr. B included in the fourth transaction data received from the terminal 41, and confirms whether or not Mr. B has agreed (S313).
  • step S313 when the server 10A confirms that Mr. B has not agreed (N in S313), the server 10A returns to S302. That is, in this case, since the server 10A does not record the fourth transaction data and the second transaction data in the distributed ledger, this process is terminated or the second smart contract Y n is generated again.
  • step S313 when the server 10A confirms that Mr. B has agreed (Y in S313), the server 10A transfers the second transaction data to the plurality of other servers 10B and 10C (S314). Since steps S314 to S316 are the same as steps S208 to S210 described with reference to FIG. 7, the description thereof will be omitted.
  • step S317 the server 10A verifies the fourth transaction data received from the terminal 41. More specifically, the server 10A verifies the electronic signature included in the fourth transaction data received from the terminal 41 and verifies the validity of the fourth transaction data. Note that step S317 may be skipped.
  • step S317 when the verification of the fourth transaction data is not successful (N in S317), the server 10A notifies the terminal 41 of an error (S318) and ends this process.
  • step S317 when the verification of the fourth transaction data is successful (Y in S317), the server 10A transfers the fourth transaction data to the plurality of other servers 10B and 10C (S319). If step S317 is skipped, the server 10A may transfer the fourth transaction data received from the terminal 41 to the plurality of other servers 10B and 10C. Then, the servers 10B and 10C each verify the transferred and received fourth transaction data.
  • the server 10A, the server 10B, and the server 10C execute a consensus algorithm for agreeing on the validity of the fourth transaction data (S320).
  • the server 10A, the server 10B, and the server 10C execute a consensus algorithm and verify that the received fourth transaction data is legitimate transaction data (that is, legitimacy), they each block a block containing the fourth transaction data. Generate.
  • the servers 10A, 10B, and 10C record the block including the second transaction data in the distributed ledger.
  • the second smart contract Y n created by the terminal 40 and the agreement confirmation result of Mr. B transmitted by the terminal 41 are recorded in the distributed ledger.
  • Modification 2 As a condition for creating the second smart contract, in addition to the case where the second contract is concluded by separate consultation, the agreement of the user who operates the terminal 40 that created the second smart contract and the terminal 41 are obtained. A case will be described in which the agreement of the operating user is also included.
  • FIG. 12A and 12B are sequence diagrams for explaining the process until the second smart contract Y n is operated in the second modification of the present embodiment.
  • the first smart contract will be referred to as the first smart contract X ver1
  • the second smart contract will be referred to as the second smart contract Y n .
  • the contents of the second smart contract Y n in this modification are as described with reference to FIG.
  • sequence diagram shown in FIG. 12A As compared with the sequence diagram shown in FIG. 11A, the subject for confirming whether or not the second smart contract Y n may be created is changed from the server 10A to the terminal 40. The difference is that the agreement is confirmed for the terminal 40 in addition to the terminal 41. Further, the sequence diagram shown in FIG. 12B is different from the sequence diagram shown in FIG. 11B in that transaction data showing the agreement confirmation result of Mr. A is also recorded in the distributed ledger.
  • step S400 the terminal 40 determines whether or not a second smart contract for a second contract that can be concluded separately by consultation may be created (S400).
  • the second smart contract Y n created next by the terminal 40 is the nth second smart contract created, and n is assumed to be equal to or less than a predetermined value. Therefore, the terminal 40 determines in step S400 that the second smart contract Y n may be created (creation is OK in S400).
  • step S400 may be performed after step S401 as long as it is performed before step S402.
  • the terminal 40 generates the second transaction data (S403) and transmits it to the server 10A (S404). Since steps S402 to S406 are the same as steps S304 to S308 described with reference to FIG. 11A, the description thereof will be omitted.
  • step S405 when the verification of the second transaction data is successful (Y in S405), the server 10A refers to its own distribution ledger and specifies the condition for creating the second smart contract Y n (S407). .. More specifically, the server 10A refers to the first smart contract X ver1 recorded in its own distributed ledger, and conditions for creating the second smart contract Y n included in the first smart contract X ver1. To identify. In this modification, the conditions include the agreement of the user who operates the terminal 40 that created the second smart contract Y n , and the terminals other than the terminal 40, in addition to the case where the second contract is concluded by separate consultation. It includes obtaining the consent of the user who operates 41.
  • the server 10A transmits an agreement confirmation request for the created second smart contract Y n to the terminal 40 and the terminal 41 according to the conditions specified in step S407 (S408).
  • the terminal 40 is input with the agreement result regarding the second smart contract Y n created by the operation of Mr. A, who is a party to the second contract concluded separately.
  • the agreement result indicating that Mr. A agrees is input (Y in S409)
  • the terminal 40 generates the fifth transaction data including the agreement result and the electronic signature associated with Mr. A (S410). ).
  • the agreement result indicating that the agreement is not agreed is input by Mr. A (N in S409)
  • the terminal 40 returns to the first step, that is, step S400.
  • the terminal 40 transmits the fifth transaction data generated in step S410 to, for example, the server 10A (S411).
  • the terminal 40 may transmit the fifth transaction data generated in step S410 to the server 10B or the server 10C.
  • the operation of the server 10A described below becomes the operation of the server 10B or the server 10C.
  • the terminal 41 is input with the agreement result regarding the second smart contract Y n created by the operation of Mr. B, who is a party to the second contract concluded separately.
  • the agreement result indicating that Mr. B agrees is input (Y in S412)
  • the terminal 41 generates the sixth transaction data including the agreement result and the electronic signature associated with Mr. B (S413). ).
  • Mr. B inputs an agreement result indicating that he / she does not agree (N in S413)
  • the terminal 41 returns to the first step, that is, step S400.
  • the terminal 41 transmits the sixth transaction data generated in step S413 to, for example, the server 10A (S414).
  • the terminal 41 may transmit the sixth transaction data generated in step S413 to the server 10B or the server 10C.
  • the operation of the server 10A described below becomes the operation of the server 10B or the server 10C.
  • Either step S409 or S412 may be processed first.
  • the server 10A refers to the agreement results of Mr. A and Mr. B included in the fifth and sixth transaction data received from the terminal 40 and the terminal 41, and satisfies the conditions, that is, Mr. A and Mr. B have agreed. It is confirmed whether or not (S415).
  • step S415 when it is confirmed that Mr. A and Mr. B have agreed and satisfy the conditions (Y in S415), the server 10A verifies the fifth and sixth transaction data received from the terminals 40 and 41. (S416). More specifically, the server 10A verifies the electronic signature included in the fifth and sixth transaction data received from the terminals 40 and 41, and verifies the validity of the fifth and sixth transaction data. Note that step S416 may be skipped.
  • step S415 when it is confirmed that Mr. A or Mr. B has not agreed and does not satisfy the conditions (N in S415), the server 10A returns to the first step, that is, step S400. In this case, since the server 10A does not record the second transaction data, the fifth transaction data, and the sixth transaction data in the distributed ledger, this process is terminated or the second smart contract Y n is generated again.
  • step S416 if the verification of the fifth or sixth transaction data is not successful (N in S416), the server 10A notifies the terminal 40 and the terminal 41 of an error (S417), and ends this process.
  • step S416 when the verification of the fifth and sixth transaction data is successful (Y in S416), the server 10A transfers the second, fifth, and sixth transaction data to the plurality of other servers 10B and 10C. (S418).
  • the server 10A, the server 10B, and the server 10C execute the consensus algorithm (S419).
  • a consensus algorithm for agreeing on the validity of the second transaction data and a consensus algorithm for agreeing on the validity of the fifth and sixth transaction data are executed. These may be executed as independent consensus algorithms or as a single consensus algorithm.
  • the second smart contract Y n created by the terminal 40 in this way and the agreement results of Mr. A and Mr. B transmitted by the terminal 40 and the terminal 41 are recorded in the distributed ledger.
  • the second smart contract Y n becomes feasible, that is, operates by being recorded in the distributed ledger (S420).
  • Modification 3 As a condition for creating the second smart contract, in addition to the case where the second contract is concluded by separate consultation, the agreement of the user who operates the terminal 41 other than the terminal 40 that created the second smart contract. The case where taking only is included is described.
  • FIG. 13A and 13B are sequence diagrams for explaining the process until the second smart contract Y n is operated in the third modification of the present embodiment.
  • the first smart contract will be referred to as the first smart contract X ver1
  • the second smart contract will be referred to as the second smart contract Y n .
  • the contents of the second smart contract Y n in this modification are as described with reference to FIG.
  • FIGS. 13A and 13B are compared with the sequence diagrams shown in FIGS. 11A and 11B, and only when the agreement confirmation request is made to the terminal 41 and Mr. B who operates the terminal 41 agrees, thereafter. It differs in that the processing is in progress.
  • steps S501 to S507 shown in FIG. 13A are the same processes as steps S301 to S307 shown in FIG. 11A, description thereof will be omitted.
  • step S507 when the verification of the second transaction data is successful (Y in S507), the server 10A refers to its own distribution ledger and specifies the condition for creating the second smart contract Y n (S509). .. More specifically, the server 10A refers to the first smart contract X ver1 recorded in its own distributed ledger, and conditions for creating the second smart contract Y n included in the first smart contract X ver1. To identify.
  • the condition includes, in addition to the case where the second contract is concluded by separate consultation, only the consent of the user who operates the terminal 41 other than the terminal 40 that created the second smart contract is obtained. It has been.
  • the server 10A transmits an agreement confirmation request for the created second smart contract Y n to the terminal 41 according to the conditions specified in step S509 (S510).
  • the terminal 41 confirms that the agreement result indicating that Mr. B agrees has been input (Y in S511), and the seventh transaction including the agreement result and the electronic signature associated with Mr. B. Generate data (S512).
  • the terminal 41 transmits the seventh transaction data generated in step S512 to, for example, the server 10A (S513).
  • the terminal 41 may transmit the seventh transaction data generated in step S512 to the server 10B or the server 10C.
  • the operation of the server 10A described below becomes the operation of the server 10B or the server 10C.
  • step S515 may be skipped.
  • step S515 if the verification of the seventh transaction data is not successful (N in S515), the server 10A notifies the terminal 41 of an error (S516), and ends this process.
  • step S515 when the verification of the seventh transaction data is successful (Y in S515), the server 10A transfers the second transaction data to the plurality of other servers 10B and 10C (S517). If step S515 is skipped, the server 10A may transfer the second transaction data received from the terminal 40 and the seventh transaction data received from the terminal 41 to the plurality of other servers 10B and 10C. .. Then, the servers 10B and 10C independently perform the verification of the fourth transaction data transferred and received and the verification of the seventh transaction data, respectively.
  • the server 10A, the server 10B, and the server 10C execute a consensus algorithm for agreeing on the validity of the second transaction data (S518).
  • the second smart contract Y n is operated by being recorded in the distributed ledger (S519). Since the processes of steps S518 and 519 are the same as the processes of steps S315 and S316 shown in FIG. 11A, the description thereof will be omitted.
  • the server 10A transfers the 7th transaction data to a plurality of other servers 10B and 10C (S520).
  • step S521 Since the process of step S521 is the same as that of step S318 shown in FIG. 11A, a specific description thereof will be omitted.
  • the second smart contract Y n created by the terminal 40 in this way and the seventh transaction data including the agreement result of Mr. B transmitted by the terminal 41 are recorded in the distributed ledger.
  • the terminal 40 creates the third smart contract by the operation of Mr. A
  • the second smart contract will be referred to as the second smart contract Y n
  • the third smart contract will be referred to as the third smart contract X ver2 .
  • FIG. 14 is a sequence diagram for explaining the process until the third smart contract X ver2 is operated in the modified example 4 of the present embodiment.
  • the sequence diagram shown in FIG. 14 is different from the sequence diagram shown in FIG. 9 in that the main body for creating the third smart contract X ver2 is changed to the terminal 40.
  • the terminal 40 creates a third smart contract X ver2 corresponding to the first contract by the operation of Mr. A (S601).
  • Mr. A is a party to the first contract and a party to the second contract concluded by a separate consultation stipulated in the first contract. Therefore, Mr. A can easily acquire the first contract address included in the second transaction data Y n created by himself. Furthermore, A's from the first smart contract X ver1, the content of the first contract, and if determined variables used to identify a second smart contract Y n, the second smart contract Y n created Conditions and conditions can be easily obtained. In other words, when Mr.
  • the third smart contract X ver2 includes the contents of the first contract, the second smart contract Y n , which is the destination of the separate contract, and the second smart contract Y n. The conditions to be created are entered.
  • the terminal 40 generates a third transaction data including the third smart contract X ver2 created in step S601 and the first electronic signature associated with the first user, Mr. A (S602).
  • the terminal 40 transmits the third transaction data generated in step S602 to, for example, the server 10A (S603).
  • the terminal 40 may transmit the third transaction data generated in step S602 to the server 10B or the server 10C.
  • the operation of the server 10A described below becomes the operation of the server 10B or the server 10C.
  • the server 10A verifies the third transaction data received from the terminal 40 (S604). More specifically, the server 10A verifies the first electronic signature included in the third transaction data received from the terminal 40 and verifies the validity of the third transaction data. Note that step S604 may be skipped.
  • step S604 when the verification of the third transaction data is not successful (N in S604), the server 10A notifies the terminal 40 of an error (S605) and ends this process.
  • step S604 when the verification of the third transaction data is successful (Y in S604), the server 10A transfers the first transaction data to the plurality of other servers 10B and 10C (S606).
  • step S606 that is, the processes of steps S606 to S608 are the same as the processes of steps S307 to S309 shown in FIG. 9, the description thereof will be omitted.
  • the terminal 40 may create a third smart contract X ver2 corresponding to the first contract.
  • the present disclosure also includes a data structure used for a block recorded as a blockchain in the control system 1 of the above embodiment.
  • the data structure of the present disclosure is a system including a terminal operated by a user and a plurality of servers that each manage a distributed ledger and manage smart contracts using the distributed ledger. It is a data structure used for the block recorded in the distributed ledger in the above, and the data structure is obtained by receiving from a first terminal operated by a first user who is one of the contractors of the first contract. It is the first smart contract corresponding to the first contract, and is associated with the first smart contract, which is programmed so that the contract behavior of the first contract can be executed using the distributed ledger, and the first user.
  • the first smart contract includes the first transaction data including the first electronic signature, and the first smart contract includes the contents of the first contract and a second contract which is a sub-contract with the first contract as the main contract. It includes a tentatively determined variable used to identify a second smart contract corresponding to the second contract to be newly concluded, and a condition for creating the second smart contract.
  • multisig may be used for consensus building for recording transaction data including the first to third smart contracts in the distributed ledger.
  • multisig is an abbreviation for multisignature and refers to a technology that requires a plurality of private keys to sign transaction data.
  • the second smart contract corresponding to the second contract concluded by the separate consultation is linked to the first contract which is one main contract. Not exclusively.
  • the second smart contract may be linked to a plurality of first contracts.
  • Each device in the above embodiment is specifically a computer system composed of a microprocessor, a ROM, a RAM, a hard disk unit, a display unit, a keyboard, a mouse, and the like.
  • a computer program is recorded in the RAM or the hard disk unit.
  • the microprocessor operates according to the computer program, each device achieves its function.
  • a computer program is configured by combining a plurality of instruction codes indicating commands to a computer in order to achieve a predetermined function.
  • Each device may be composed of a part or all of the constituent elements of one system LSI (Large Scale Integration: large-scale integrated circuit).
  • a system LSI is an ultra-multifunctional LSI manufactured by integrating a plurality of components on a single chip, and specifically, is a computer system including a microprocessor, ROM, RAM, and the like. ..
  • a computer program is recorded in the RAM. When the microprocessor operates according to the computer program, the system LSI achieves its function.
  • each part of the component components constituting each of the above devices may be individually integrated into one chip, or may be integrated into one chip so as to include a part or all of them.
  • system LSI Although it is referred to as a system LSI here, it may be referred to as an IC, an LSI, a super LSI, or an ultra LSI due to the difference in the degree of integration. Further, the method of making an integrated circuit is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor. An FPGA (Field Programmable Gate Array) that can be programmed after the LSI is manufactured, or a reconfigurable processor that can reconfigure the connection and settings of the circuit cells inside the LSI may be used.
  • FPGA Field Programmable Gate Array
  • each of the above devices may be composed of an IC card or a single module that can be attached to and detached from each device.
  • the IC card or the module is a computer system composed of a microprocessor, a ROM, a RAM, and the like.
  • the IC card or the module may include the above-mentioned super multifunctional LSI.
  • the microprocessor operates according to a computer program, the IC card or the module achieves its function. This IC card or this module may have tamper resistance.
  • the present disclosure may be the method shown above. Further, it may be a computer program that realizes these methods by a computer, or it may be a digital signal composed of the computer program.
  • the present disclosure discloses a recording medium in which the computer program or the digital signal can be read by a computer, for example, a flexible disc, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, or a BD (Blu-ray). (Registered trademark) Disc), may be recorded in a semiconductor memory or the like. Further, it may be the digital signal recorded on these recording media.
  • a computer for example, a flexible disc, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, or a BD (Blu-ray). (Registered trademark) Disc), may be recorded in a semiconductor memory or the like. Further, it may be the digital signal recorded on these recording media.
  • BD Blu-ray
  • the computer program or the digital signal may be transmitted via a telecommunication line, a wireless or wired communication line, a network typified by the Internet, data broadcasting, or the like.
  • the present disclosure is a computer system including a microprocessor and a memory, in which the memory records the computer program, and the microprocessor may operate according to the computer program.
  • control methods, servers, and data structures for example, control methods, servers, and smart contracts that record and use smart contracts corresponding to contracts that may occur in the future in a separate ledger. It can be used for data structures, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Data Mining & Analysis (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Tourism & Hospitality (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本開示の制御方法は、第１契約の締結者の１人である第１ユーザにより操作された端末（４０）から、第１契約に対応する第１スマートコントラクトと、第１ユーザに紐づけられる第１電子署名とを含む第１トランザクションデータを受信し（Ｓ１０３）、他の複数のサーバとともに、コンセンサスアルゴリズムを実行して（Ｓ１０７）、第１トランザクションデータを含むブロックを分散台帳に記録する。第１スマートコントラクトには、第１契約の内容と、第１契約を主契約とした副契約である第２契約であって新たに締結される予定の第２契約に対応する第２スマートコントラクトを特定するために用いられる仮に決められた変数と、第２スマートコントラクトが作成される条件とが含まれている。

Description

制御方法、サーバ、及び、データ構造
　本開示は、制御方法、サーバ、及び、データ構造に関する。
　ブロックチェーン上で契約をプログラム化する仕組みとして、スマートコントラクト技術が知られている。スマートコントラクトは、ブロックチェーン等のブロックに含まれて当該ブロックが分散台帳に記録されることで実行可能になる。このため、スマートコントラクトを用いることで、所定の条件を満たせば契約の条件確認または履行までといった契約行動を、契約を改ざんされずに、自動的に実行させることができる。
　例えば特許文献１には、スマートコントラクトを用いることで、分散台帳システムにおいて管理者が複数存在する状況下でも、ノード間でポリシーまたはタイミングを揃えた運用管理を可能とする仕組みについて開示されている。
国際公開第２０１９／０２１７９２号
　しかしながら、ある契約に対応するスマートコントラクトが稼働された後、当該契約に規定する別途協議が発生して新たな条項が締結されても、当該スマートコントラクトは確定している。つまり、当該スマートコントラクトに新たな条項の契約行動に関する記述を追加することができない。このため、別途協議が将来発生する可能性のある契約に対応するスマートコントラクトの利用が抑制され、契約行動の自動化によるメリットすなわち不正防止、並びに、仲介者を介さないことによる時間コスト及びエネルギーコスト削減を図るのが難しくなる可能性がある。
　本開示は、上述の事情を鑑みてなされたもので、分散台帳を用いて、時間コストとエネルギーコストとをより低減することができる制御方法などを提供する。
　上記目的を達成するために、本開示の一形態に係る制御方法は、ユーザにより操作される端末と、それぞれ、分散台帳を管理し、かつ、前記分散台帳を利用してスマートコントラクトを管理する複数のサーバとを備えるシステムにおける、前記複数のサーバのうちの第１サーバによって実行される制御方法であって、第１契約の締結者の１人である第１ユーザにより操作された第１端末から、前記第１契約に対応する第１スマートコントラクトであって、前記分散台帳を利用して前記第１契約の契約行動が実行可能にプログラム化された第１スマートコントラクトと、前記第１ユーザに紐づけられる第１電子署名とを含む第１トランザクションデータを受信し、前記第１トランザクションデータを含むブロックを前記分散台帳に記録し、前記第１スマートコントラクトには、前記第１契約の内容と、前記第１契約を主契約とした副契約である第２契約であって新たに締結される予定の第２契約に対応する第２スマートコントラクトを特定するために用いられる仮に決められた変数と、前記第２スマートコントラクトが作成される条件とが含まれている。
　なお、これらの全般的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータで読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　本開示の制御方法等によれば、分散台帳を用いて、時間コストとエネルギーコストとをより低減することができる。
図１は、実施の形態における制御システムの構成を模式的に示すブロック図である。 図２は、実施の形態におけるサーバの構成を模式的に示すブロック図である。 図３は、ブロックチェーンのデータ構造を示す説明図である。 図４は、トランザクションデータのデータ構造を示す説明図である。 図５は、実施の形態における第１スマートコントラクトが稼働するまでの処理を説明するためのシーケンス図である。 図６は、実施の形態における第１スマートコントラクトの内容を概念的に示す図である。 図７は、実施の形態における第２スマートコントラクトが稼働するまでの処理を説明するためのシーケンス図である。 図８は、実施の形態における第２スマートコントラクトの内容を概念的に示す図である。 図９は、実施の形態における第３スマートコントラクトが稼働するまでの処理を説明するためのシーケンス図である。 図１０は、実施の形態における第３スマートコントラクトの内容を概念的に示す図である。 図１１Ａは、実施の形態の変形例１における第２スマートコントラクトが稼働するまでの処理を説明するためのシーケンス図である。 図１１Ｂは、実施の形態の変形例１における第２スマートコントラクトが稼働するまでの処理を説明するためのシーケンス図である。 図１２Ａは、実施の形態の変形例２における第２スマートコントラクトが稼働するまでの処理を説明するためのシーケンス図である。 図１２Ｂは、実施の形態の変形例２における第２スマートコントラクトが稼働するまでの処理を説明するためのシーケンス図である。 図１３Ａは、実施の形態の変形例３における第２スマートコントラクトが稼働するまでの処理を説明するためのシーケンス図である。 図１３Ｂは、実施の形態の変形例３における第２スマートコントラクトが稼働するまでの処理を説明するためのシーケンス図である。 図１４は、実施の形態の変形例４における第３スマートコントラクトが稼働するまでの処理を説明するためのシーケンス図である。
　本開示の一形態に係る制御方法は、ユーザにより操作される端末と、それぞれ、分散台帳を管理し、かつ、前記分散台帳を利用してスマートコントラクトを管理する複数のサーバとを備えるシステムにおける、前記複数のサーバのうちの第１サーバによって実行される制御方法であって、第１契約の締結者の１人である第１ユーザにより操作された第１端末から、前記第１契約に対応する第１スマートコントラクトであって、前記分散台帳を利用して前記第１契約の契約行動が実行可能にプログラム化された第１スマートコントラクトと、前記第１ユーザに紐づけられる第１電子署名とを含む第１トランザクションデータを受信し、前記第１トランザクションデータを含むブロックを前記分散台帳に記録し、前記第１スマートコントラクトには、前記第１契約の内容と、前記第１契約を主契約とした副契約である第２契約であって新たに締結される予定の第２契約に対応する第２スマートコントラクトを特定するために用いられる仮に決められた変数と、前記第２スマートコントラクトが作成される条件とが含まれている。
　これによれば、分散台帳を用いて、時間コストとエネルギーコストとをより低減することができる制御方法などを実現することができる。
　より具体的には、別途協議が将来発生する可能性のある第１契約に対応する第１スマートコントラクトに、第１契約に規定される別途協議により締結され得る第２契約に対応する第２スマートコントラクトのコントラクトアドレスの代替としての変数を含める。このようにして、将来発生する可能性のある別途協議を第１スマートコントラクトで表現できる。よって、別途協議が将来発生する可能性のある契約に対応するスマートコントラクトの利用が促進され、契約行動の自動化によるメリットすなわち不正防止、並びに、仲介者を介さないことによる時間コスト及びエネルギーコストの削減を図ることができる。
　ここで、例えば、前記第１トランザクションデータを含むブロックを前記分散台帳に記録する際、前記複数のサーバのうちの前記第１サーバを除く複数の第２サーバとともに、前記第１トランザクションデータの正当性について合意するための第１コンセンサスアルゴリズムを実行し、前記第１コンセンサスアルゴリズムによって前記第１トランザクションデータの正当性について合意された場合、前記第１トランザクションデータを含むブロックを前記分散台帳に記録する。
　また、例えば、前記制御方法は、前記第１端末から、前記第２契約に対応する前記第２スマートコントラクトであって、前記分散台帳を利用して前記第２契約の契約行動が実行可能にプログラム化された前記第２スマートコントラクトと、前記第１ユーザに紐づけられる第２電子署名とを含む第２トランザクションデータを受信し、前記第２トランザクションデータを含むブロックを前記分散台帳に記録し、前記第２スマートコントラクトには、前記第２契約の内容と、前記第２スマートコントラクトの紐づき先を示す情報としての前記第１スマートコントラクトの第１コントラクトアドレスとが少なくとも含まれている。
　また、例えば、前記第２トランザクションデータを含むブロックを前記分散台帳に記録する際、前記複数のサーバのうちの前記第１サーバを除く複数の第２サーバとともに、前記第２トランザクションデータの正当性について合意するための第２コンセンサスアルゴリズムを実行し、前記第２コンセンサスアルゴリズムによって前記第２トランザクションデータの正当性について合意された場合、前記第２トランザクションデータを含むブロックを前記分散台帳に記録する。
　また、例えば、前記制御方法は、さらに、前記第２トランザクションデータを受信した場合、前記第１コントラクトアドレスを参照して前記第１スマートコントラクトに含まれる前記条件を特定し、第２トランザクションデータを受信した場合で、さらに、前記条件を満たすとき、前記第２コンセンサスアルゴリズムを実行する。
　また、例えば、前記第２スマートコントラクトには、前記第２契約の内容と、前記第１コントラクトアドレスとに加えて、前記変数が含まれている。
　また、前記制御方法は、さらに、前記第２トランザクションデータを含むブロックが前記分散台帳に記録された場合、前記第２トランザクションデータに含まれる前記第１コントラクトアドレスを参照して、前記第１スマートコントラクトを特定し、特定した前記第１スマートコントラクトから、前記第１契約の内容と、前記変数と、前記条件とを取得して、前記第１契約の内容と、前記条件と、前記変数に代えて前記第２トランザクションデータの第２コントラクトアドレスとを含む第３スマートコントラクトであって前記第１契約に対応する第３スマートコントラクトを作成し、作成した前記第３スマートコントラクトと、前記第１サーバに紐づけられる第３電子署名とを含む第３トランザクションデータを生成し、前記第３トランザクションデータを含むブロックを前記分散台帳に記録する。
　また、前記第３トランザクションデータを含むブロックを前記分散台帳に記録する際、前記複数のサーバのうちの前記第１サーバを除く複数の第２サーバとともに、前記第３トランザクションデータの正当性について合意するための第３コンセンサスアルゴリズムを実行し、前記第３コンセンサスアルゴリズムによって前記第３トランザクションデータの正当性について合意された場合、前記第３トランザクションデータを含むブロックを前記分散台帳に記録する。
　また、前記制御方法は、さらに、前記第１サーバのワーキングメモリに、前記第１契約に対する最新のスマートコントラクトが前記第３スマートコントラクトである旨を示す情報を保持させる。
　また、本開示の一形態に係るサーバは、ユーザにより操作される端末と、それぞれ、分散台帳を管理し、かつ、前記分散台帳を利用してスマートコントラクトを管理する複数のサーバとを備えるシステムにおける、前記複数のサーバのうちの一つのサーバであって、プロセッサと、前記プロセッサに処理を実行させるプログラムが記憶されたメモリと、スマートコントラクトが格納された前記分散台帳が記憶されている記憶装置と、を備え、前記プロセッサは、第１契約の締結者の１人である第１ユーザにより操作された第１端末から、前記第１契約に対応する第１スマートコントラクトであって、前記分散台帳を利用して前記第１契約の契約行動が実行可能にプログラム化された第１スマートコントラクトと、前記第１ユーザに紐づけられる第１電子署名とを含む第１トランザクションデータを受信し、前記プロセッサは、前記第１トランザクションデータを含むブロックを前記分散台帳に記録し、前記第１スマートコントラクトには、前記第１契約の内容と、前記第１契約を主契約とした副契約である第２契約であって新たに締結される予定の第２契約に対応する第２スマートコントラクトを特定するために用いられる仮に決められた変数と、前記第２スマートコントラクトが作成される条件とが含まれている。
　以下、図面を参照しながら、実施の形態について説明する。なお、以下で説明する実施の形態は、いずれも本開示の好ましい一具体例を示す。つまり、以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置及び接続形態、ステップ、ステップの順序などは、一例であり、本開示を限定する主旨ではない。本開示は、請求の範囲の記載に基づいて特定される。したがって、以下の実施の形態における構成要素のうち、本開示の最上位概念を示す独立請求項に記載されていない構成要素は、本開示の課題を達成するために必ずしも必要ではないが、より好ましい形態を構成する構成要素として説明される。
　（実施の形態）
　以下では、図面を参照しながら、実施の形態における制御システム１について説明する。
　［制御システム１の構成］
　本開示の制御システム１は、分散台帳に格納される第１契約に対応するスマートコントラクトに、当該第１契約に規定される別途協議が将来発生しても対応できる仕組みを含めることができる。これにより、別途協議が将来発生する可能性のある第１契約に対応するスマートコントラクトの利用を促進させることができる。
　図１は、本実施の形態における制御システム１の構成を模式的に示すブロック図である。
　制御システム１は、図１に示されるように、サーバ１０Ａ、１０Ｂ及び１０Ｃと、ユーザにより操作される端末４０及び４１とを備える。これらはネットワークＮを介して通信可能に接続されている。ネットワークＮは、どのような通信回線またはネットワークから構成されてもよく、例えば、インターネット、携帯電話のキャリアネットワークなどを含む。サーバ１０Ａ、１０Ｂ及び１０Ｃを「サーバ１０Ａ等」ともいい、端末４０及び４１を「端末４０等」ともいう。なお、図１では、制御システム１が、３つサーバと２つの端末とを備える場合の例が示されているが、これに限らない。すなわち、制御システム１は、４つ以上のサーバを備えてもよいし、３つ以上の端末を備えていてもよい。
　［端末４０等］
　端末４０及び４１はそれぞれ独立に動作し、それぞれのユーザにより操作される。
　端末４０は、第１ユーザにより操作される端末である。本実施の形態では、端末４０は、別途協議が将来発生する可能性のある契約である第１契約の締結者の１人である第１ユーザにより操作される第１端末である。端末４０は、例えばパーソナルコンピュータ、スマートフォン、タブレットなどである。図１に示す例では、端末４０は、サーバ１０Ａ等とネットワークＮを介して通信可能な端末であって、第１ユーザであるＡさんが使用して操作する端末である。
　また、端末４０は、ユーザの操作に従って、スマートコントラクトを作成する。端末４０は、スマートコントラクトを作成すると、作成したスマートコントラクトを含めたトランザクションデータを生成して、生成したトランザクションデータをサーバ１０Ａ等に送信する。
　例えば、端末４０は、第１ユーザであるＡさんの操作により、第１契約に対応する第１スマートコントラクトであって、分散台帳を利用することで第１契約の契約行動が実行可能にプログラム化された第１スマートコントラクトを作成する。ここで、作成される第１スマートコントラクトには、第１契約の内容と、第１契約を主契約とした副契約である第２契約であって新たに締結される予定の第２契約に対応する第２スマートコントラクトを特定するために用いられる仮に決められた変数と、第２スマートコントラクトが作成される条件とが含まれている。ここで、第２契約は、第１契約に定められる別途協議を行うことで締結された第１契約を主契約とした副契約である。
　さらに、端末４０は、第１ユーザであるＡさんの電子署名の入力と、トランザクションデータを生成する旨の指示を受け付けると、Ａさんの電子署名と作成した第１スマートコントラクトを含む第１トランザクションデータを生成する。換言すると、端末４０は、作成した第１スマートコントラクトと、第１ユーザに紐づけられる第１電子署名とを含む第１トランザクションデータを生成する。そして、端末４０は、生成した第１トランザクションデータをサーバ１０Ａ等に送信する。
　また、例えば、端末４０は、Ａさんの操作により、別途協議により締結された第２契約に対応する第２スマートコントラクトであって、分散台帳を利用して第２契約の契約行動が実行可能にプログラム化された第２スマートコントラクトを作成する。ここで、作成される第２スマートコントラクトには、第２契約の内容と、第２スマートコントラクトの紐づき先を示す情報としての第１スマートコントラクトの第１コントラクトアドレスとが少なくとも含まれている。なお、第２スマートコントラクトには、第２契約の内容と、第１コントラクトアドレスとに加えて、上記の変数が含まれていてもよい。
　さらに、端末４０は、第１ユーザであるＡさんの電子署名の入力と、トランザクションデータを生成する旨の指示を受け付けると、Ａさんの電子署名と作成した第２スマートコントラクトを含む第２トランザクションデータを生成する。換言すると、端末４０は、作成した第２スマートコントラクトと、第１ユーザに紐づけられる第２電子署名とを含む第１トランザクションデータを生成する。そして、端末４０は、生成した第２トランザクションデータをサーバ１０Ａ等に送信する。なお、第１電子署名と第２電子署名は、第１ユーザに紐づけられていれば、同一でも異なっていてもよい。
　端末４１は、第２ユーザにより操作される端末である。本実施の形態では、第１契約の締結者の１人であり、第１ユーザと別途協議を行う第２ユーザにより操作される第２端末である。端末４１は、例えばパーソナルコンピュータ、スマートフォン、タブレットなどである。図１に示す例では、端末４１は、サーバ１０Ａ等とネットワークＮを介して通信可能な端末であって、第２ユーザであるＢさんが使用して操作する端末である。
　［サーバ１０Ａ等］
　複数のサーバ１０Ａ、１０Ｂ及び１０Ｃはそれぞれ、分散台帳を管理し、かつ、分散台帳を利用してスマートコントラクトを管理する。
　サーバ１０Ａ、１０Ｂ、１０Ｃはそれぞれ、ネットワークＮを介して通信可能に接続され、独立に動作する。サーバ１０Ａ、１０Ｂ、１０Ｃは、同様の構成であるため、以下では、サーバ１０Ａを例に挙げて説明する。なお、他のサーバ（サーバ１０Ｂまたは１０Ｃ）が上記の処理を行ってもよい。
　図２は、本実施の形態におけるサーバ１０Ａの構成を模式的に示すブロック図である。
　サーバ１０Ａは、第１サーバの一例である。本実施の形態では、サーバ１０Ａは、図２に示すように、処理部１１と、台帳管理部１２と、制御部１３と、ワーキングメモリ１７とを備える。サーバ１０Ａが備えるこれらの機能部は、例えばＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）がメモリを用いてプログラムを実行することで実現され得る。
　＜処理部１１＞
　処理部１１は、分散台帳によって各種情報の管理を行う処理部である。処理部１１は、制御システム１内の装置からトランザクションデータを受信した場合、または、制御部１３が生成したトランザクションデータを取得した場合に、受信または取得したトランザクションデータを台帳管理部１２に提供することで分散台帳に格納する。このトランザクションデータには、後述する第１トランザクションデータ～第７トランザクションデータが含まれる。
　＜台帳管理部１２＞
　台帳管理部１２は、分散台帳を管理している処理部である。具体的には、台帳管理部１２は、トランザクションデータを受信した場合、受信したトランザクションデータを他の複数のサーバに転送し、かつ、受信したトランザクションデータを分散台帳に格納する。
　このように、台帳管理部１２は、処理部１１から提供されたトランザクションデータを分散台帳に格納する。分散台帳には、過去から現在までのトランザクションデータが格納される。分散台帳では、分散台帳に記録された情報の改ざんが困難であるという特性に基づいて、上記のトランザクションデータが改ざんされないように管理されている。
　台帳管理部１２は、図２に示すように、格納部１５と、台帳記憶部１６とを有する。
　格納部１５は、分散台帳に格納すべき新しいトランザクションデータを台帳記憶部１６に格納する処理部である。格納部１５は、新しいトランザクションデータを含むブロックを生成し、生成したブロックをサーバ１０Ａ等の間で同期をとった上で、上記ブロックを台帳記憶部１６に格納する。
　より具体的には、格納部１５は、処理部１１からトランザクションデータを受信すると、受信したトランザクションデータに含まれる電子署名の検証と、トランザクションデータの正当性の検証とを行う。なお、この検証はスキップされてもよい。格納部１５は、電子署名の検証及びトランザクションデータの正当性の検証が成功した場合、トランザクションデータを複数の他のサーバ１０Ｂ及び１０Ｃに転送する。次いで、格納部１５は、複数の他のサーバ１０Ｂ及び１０Ｃとともに、当該トランザクションデータの正当性について合意するためのコンセンサスアルゴリズムを実行する。格納部１５は、コンセンサスアルゴリズムによって当該トランザクションデータの正当性について合意された場合、当該トランザクションデータを含むブロックを分散台帳に記録する。
　なお、格納部１５は、処理部１１から、別途協議による第２契約に対応する第２スマートコントラクトを含む第２トランザクションデータを受信した場合、別途協議による副契約である第２契約の主契約である第１契約に対応する第１スマートコントラクトに含まれる条件を特定する。この場合、格納部１５は、受信した第２トランザクションデータに含まれる電子署名の検証と、第２トランザクションデータの正当性の検証が成功した場合で、さらに、当該条件を満たすときに、コンセンサスアルゴリズムを実行するとしてもよい。なお、第２トランザクションデータの検証がスキップされる場合には、格納部１５は、第２トランザクションデータを受信して、当該条件を満たすときに、コンセンサスアルゴリズムを実行するとしてもよい。
　本実施の形態では、格納部１５は、第１契約に対応する第１スマートコントラクトを含むブロックと、第２契約に対応する第２スマートコントラクトを含むブロックとを、独立に処理して、分散台帳に記録する。また、格納部１５は、制御部１３が生成した第１契約に対応する新たなスマートコントラクトである第３スマートコントラクトを含むブロックを受信すると、第３スマートコントラクトを含むブロックを分散台帳に記録する。
　台帳記憶部１６は、分散台帳を記憶している記憶装置である。台帳記憶部１６は、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）またはＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）などにより実現される。
　台帳記憶部１６に格納されている分散台帳は、１以上のトランザクションデータがブロックに含まれて電子的に記録され、ハッシュ値などの特性を用いて改ざんが困難であるように管理されている。この詳細は、後述する。また、台帳記憶部１６に格納されている分散台帳には、１以上のスマートコントラクトが記憶されている。当該分散台帳には、例えばコントラクトコードと呼ばれるプログラムコードが記憶されており、このコントラクトコードが実行されることで、スマートコントラクトが実現されるとしてもよい。コントラクトコードは、スマートコントラクトに記述された契約行動を実行するために実行されるコードである。
　なお、本実施の形態では、台帳記憶部１６に格納されている分散台帳には、分散型の台帳管理を実現するブロックチェーン実装基盤として例えばブロックチェーン方式が採用されているとして説明するが、これに限らない。ＩＯＴＡまたはハッシュグラフなどの他の方式が採用されていてもよい。
　また、新しいトランザクションデータが分散台帳に、格納される際にコンセンサスアルゴリズムが実行されるとして以下も説明するが、実行されなくてもよい。
　新しいトランザクションデータが分散台帳に、格納される際に実行されるコンセンサスアルゴリズムには、ＰＢＦＴ（Ｐｒａｃｔｉｃａｌ　Ｂｙｚａｎｔｉｎｅ　Ｆａｕｌｔ　Ｔｏｌｅｒａｎｃｅ）が用いられてもよいし、その他の公知のコンセンサスアルゴリズムが用いられてもよい。公知のコンセンサスアルゴリズムとしては、例えばＰＯＷ（Ｐｒｏｏｆ　Ｏｆ　Ｗｏｒｋ）またはＰＯＳ（Ｐｒｏｏｆ　Ｏｆ　Ｓｔａｋｅ）などがある。コンセンサスアルゴリズムにＰＢＦＴが用いられる場合、まず、格納部１５は、複数の他のサーバ１０Ｂ及び１０Ｃのそれぞれからトランザクションの検証が成功したか否かを示す報告を受け取り、当該報告の数が所定の数を超えたか否かを判定する。そして、格納部１５は、当該報告の数が所定の数を超えたとき、コンセンサスアルゴリズムによってトランザクションデータの正当性が検証された場合であると判定すればよい。
　新しいトランザクションデータが分散台帳に、格納される際にコンセンサスアルゴリズムが実行されない場合には、Ｈｙｐｅｒｌｅｄｇｅｒ　ｆａｂｒｉｃなどの分散台帳技術を用いればよい。
　＜制御部１３＞
　制御部１３は、各種の処理を制御する処理部である。
　制御部１３の処理の一部または全部は、台帳記憶部１６に記憶されたスマートコントラクトに記述された契約行動を実行することでなされてもよい。なお、制御部１３は、台帳記憶部１６に記憶されたコントラクトコードを実行することでスマートコントラクトを実現すなわちスマートコントラクトに記述された契約行動を、上記の処理として実行してもよい。
　また、制御部１３は、主契約の別途協議により締結された副契約に対応するスマートコントラクトに関する情報が反映された、主契約に対応する新たなスマートコントラクトを作成する。制御部１３は、作成した新たなスマートコントラクトを含めたトランザクションデータを生成して、処理部１１に送信する。
　本実施の形態では、制御部１３は、第２トランザクションデータを含むブロックが分散台帳に記録された場合、まず、第２トランザクションデータに含まれる第１コントラクトアドレスを参照して、第１契約に対応する第１スマートコントラクトを特定する。次いで、制御部１３は、特定した第１スマートコントラクトから、第１契約の内容と、変数と、条件とを取得する。次いで、制御部１３は、第１契約の内容と、条件と、変数に代えて第２トランザクションデータの第２コントラクトアドレスとを含む新たなスマートコントラクトであって第１契約に対応する第３スマートコントラクトを作成する。そして、制御部１３は、作成した第３スマートコントラクトと、サーバ１０Ａに紐づけられる第３電子署名とを含む第３トランザクションデータを生成して、処理部１１に送信する。
　＜ワーキングメモリ１７＞
　ワーキングメモリ１７は、サーバ１０Ａのオンメモリとして機能するメモリである。ワーキングメモリ１７は、分散台帳に記録されたブロックを読み出して、第１契約に対する最新のスマートコントラクトを保持する。なお、ワーキングメモリ１７は、第１契約に対する最新のスマートコントラクトを指し示す情報を保持してもよい。例えば、第３スマートコントラクトが最新のスマートコントラクトである場合、ワーキングメモリ１７は、第１契約に対する最新のスマートコントラクトが第３スマートコントラクトである旨を示す情報を保持してもよい。
　［データ構造］
　ブロックチェーンのデータ構造と、トランザクションデータのデータ構造とについて説明する。
　図３は、ブロックチェーンのデータ構造を示す説明図である。
　ブロックチェーンは、その記録単位であるブロックがチェーン（鎖）状に接続されたものである。それぞれのブロックは、複数のトランザクションデータと、直前のブロックのハッシュ値とを有している。具体的には、ブロックＢ２には、その前のブロックＢ１のハッシュ値が含まれている。そして、ブロックＢ２に含まれる複数のトランザクションデータと、ブロックＢ１のハッシュ値とから演算されたハッシュ値が、ブロックＢ２のハッシュ値として、ブロックＢ３に含められる。このように、前のブロックの内容をハッシュ値として含めながら、ブロックをチェーン状に接続することで、記録されたトランザクションデータの改ざんを有効に防止する。
　仮に過去のトランザクションデータが変更されると、ブロックのハッシュ値が変更前と異なる値になり、改ざんしたブロックを正しいものとみせかけるには、それ以降のブロックすべてを作り直さなければならず、この作業は現実的には非常に困難である。この性質を使用して、ブロックチェーンに改ざん困難性が担保されている。
　図４は、トランザクションデータのデータ構造を示す説明図である。
　図４に示されるトランザクションデータは、トランザクション本体Ｐ１と、電子署名Ｐ２とを含む。トランザクション本体Ｐ１は、当該トランザクションデータに含まれるデータ本体である。電子署名Ｐ２は、トランザクション本体Ｐ１のハッシュ値に対して、当該トランザクションデータの作成者の署名鍵で署名する、より具体的には、作成者の秘密鍵で暗号化することで生成されたものである。
　トランザクションデータは、電子署名Ｐ２を有するので、改ざんが実質的に不可能である。これにより、トランザクション本体の改ざんが防止される。
　［動作］
　続いて、以上のように構成された制御システム１において、第１スマートコントラクト、第２スマートコントラクト及び第３スマートコントラクトが稼働するまでの処理についてシーケンス図を用いて説明する。以下では、第１スマートコントラクトを第１スマートコントラクトXver1と表記し、第２スマートコントラクトを第２スマートコントラクトYnと表記し、第３スマートコントラクトを第３スマートコントラクトXver2と表記する。
　［第１スマートコントラクトXver1が稼働するまでの処理］
　図５は、本実施の形態における第１スマートコントラクトXver1が稼働するまでの処理を説明するためのシーケンス図である。図６は、本実施の形態における第１スマートコントラクトXver1の内容を概念的に示す図である。
　まず、端末４０は、別途協議が将来発生する可能性のある第１契約の締結者の１人である第１ユーザすなわちＡさんの操作により、第１契約に対応する第１スマートコントラクトXver1を作成する（Ｓ１０１）。ここで、第１スマートコントラクトXver1は、分散台帳を利用することで第１契約の契約行動が実行可能にプログラム化されたスマートコントラクトである。第１スマートコントラクトXver1は、例えば図６に示す内容が入力される。すなわち、第１スマートコントラクトXver1には、第１契約の内容と、別途協議の飛び先と、第２スマートコントラクトが作成される条件とが入力されている。図６に示す例では、別途協議の飛び先として、例えば「変数ｘｘ」など、第２契約に対応する第２スマートコントラクトを特定するために用いられる仮に決められた変数が示されている。なお、変数ｘｘは、仮に決められた変数でなくてもよく、仮に決められた特定アドレスでも仮に決められた値でもよい。すなわち、将来作成される第２スマートコントラクトを特定するために用いることができれば、その態様は問われない。なお、「飛び先Xver1=」の「Xver1=」は、第１スマートコントラクトからの飛び先を示すために付されている。
　次に、端末４０は、ステップＳ１０１で作成した第１スマートコントラクトXver1と、第１ユーザであるＡさんに紐づけられる第１電子署名とを含む第１トランザクションデータを生成する（Ｓ１０２）。
　次に、端末４０は、ステップＳ１０２で生成した第１トランザクションデータを、例えばサーバ１０Ａに送信する（Ｓ１０３）。なお、端末４０は、ステップＳ１０２で生成した第１トランザクションデータを、サーバ１０Ｂまたはサーバ１０Ｃに送信してもよい。この場合、以下で説明するサーバ１０Ａの動作がサーバ１０Ｂまたはサーバ１０Ｃの動作となる。
　次に、サーバ１０Ａは、端末４０から受信した第１トランザクションデータの検証を行う（Ｓ１０４）。より具体的には、サーバ１０Ａは、端末４０から受信した第１トランザクションデータに含まれる第１電子署名の検証と、第１トランザクションデータの正当性の検証とを行う。なお、ステップＳ１０４はスキップしてもよい。
　ステップＳ１０４において、サーバ１０Ａは、第１トランザクションデータの検証が成功しなかった場合（Ｓ１０４でＮ）、端末４０にエラー通知を行い（Ｓ１０５）、本処理を終了する。
　一方、ステップＳ１０４において、サーバ１０Ａは、第１トランザクションデータの検証が成功した場合（Ｓ１０４でＹ）、複数の他のサーバ１０Ｂ、１０Ｃに第１トランザクションデータを転送する（Ｓ１０６）。なお、ステップＳ１０４がスキップされた場合には、サーバ１０Ａは、端末４０から受信した第１トランザクションデータを複数の他のサーバ１０Ｂ、１０Ｃに転送すればよい。すると、サーバ１０Ｂ、１０Ｃではそれぞれ、転送されて受信した第１トランザクションデータの検証を行う。
　次に、サーバ１０Ａとサーバ１０Ｂとサーバ１０Ｃとは、コンセンサスアルゴリズムを実行する（Ｓ１０７）。ここで、ステップＳ１０７のコンセンサスアルゴリズムは、第１トランザクションデータの正当性について合意するための第１コンセンサスアルゴリズムに該当する。サーバ１０Ａとサーバ１０Ｂとサーバ１０Ｃとは、コンセンサスアルゴリズムを実行して、受信した第１トランザクションデータが正当なトランザクションデータであること（つまり正当性）を検証すると、それぞれ第１トランザクションデータを含むブロックを生成する。そして、サーバ１０Ａ、１０Ｂ、１０Ｃは、第１トランザクションデータを含むブロックを分散台帳に記録する。
　このようにして端末４０が作成した第１スマートコントラクトXver1が分散台帳に記録される。
　そして、第１スマートコントラクトXver1は、分散台帳に記録されることで、実行可能になるすなわち稼働する（Ｓ１０８）。なお、分散台帳に記録された第１スマートコントラクトXver1は、他の機器等から、当該第１スマートコントラクトXver1の第１コントラクトアドレスを含むトランザクションデータが受信され、分散台帳に記録された場合に実行されるとしてもよい。
　［第２スマートコントラクトYnが稼働するまでの処理］
　次に、第１契約の締結後に、第１契約に規定される別途協議により第１契約を主契約とした副契約である第２契約が締結された場合に、締結された第２契約に対応する第２スマートコントラクトYnが作成されて稼働するまでの処理について説明する。本実施の形態では、端末４０のユーザであるＡさんと、端末４１のユーザであるＢさんとで別途協議が行われて第２契約が締結されたとする。
　図７は、本実施の形態における第２スマートコントラクトYnが稼働するまでの処理を説明するためのシーケンス図である。図８は、本実施の形態における第２スマートコントラクトYnの内容を概念的に示す図である。
　まず、端末４０は、Ａさんの操作により、第１契約に規定される別途協議があったことが入力されると（Ｓ２０１でＹ）、別途協議により締結された第２契約に対する第２スマートコントラクトYnを作成できるかを確認する（Ｓ２０２）。端末４０は、第１契約の副契約である第２契約の数すなわち第２スマートコントラクトYnの数が所定値以下である場合に、第２スマートコントラクトYnを作成してもよいと判定する。これは第１契約の副契約（別途契約）である第２契約の数に制限を設けるためである。
　ステップＳ２０２において、端末４０は、第２スマートコントラクトYnを作成できることを確認した場合（Ｓ２０２でＹ）、別途協議により締結した第２契約の締結者の１人であるＡさんの操作により、第２契約に対応する第２スマートコントラクトYnを作成する（Ｓ２０３）。ここで、第２スマートコントラクトYnは、分散台帳を利用することで第２契約の契約行動が実行可能にプログラム化されたスマートコントラクトである。第２スマートコントラクトYnは、例えば図８に示す内容が入力される。すなわち、第２スマートコントラクトYnには、第２契約の内容と、紐づき先とが入力されている。図８に示す例では、例えば「＝Xver1」で示されるように、紐づき先が第１スマートコントラクトXver1であることが示されている。本実施の形態では、紐づき先が第１スマートコントラクトXver1であることを示すために、紐づき先に、第１スマートコントラクトXver1の第１コントラクトアドレスが入力される。また、紐づき先には、第１スマートコントラクトXver1の第１コントラクトアドレスに加えて、第１スマートコントラクトXver1に含まれる変数ｘｘが入力されてもよい。なお、紐づき先として入力される内容は、第１スマートコントラクトXver1に含まれる変数ｘｘが特定できれば、その態様は問われない。
　次に、端末４０は、ステップＳ２０３で作成した第２スマートコントラクトYnと、第１ユーザであるＡさんに紐づけられる第２電子署名とを含む第２トランザクションデータを生成する（Ｓ２０４）。
　次に、端末４０は、ステップＳ２０４で生成した第２トランザクションデータYnを、例えばサーバ１０Ａに送信する（Ｓ２０５）。なお、端末４０は、ステップＳ２０４で生成した第２トランザクションデータを、サーバ１０Ｂまたはサーバ１０Ｃに送信してもよい。この場合、以下で説明するサーバ１０Ａの動作がサーバ１０Ｂまたはサーバ１０Ｃの動作となる。
　次に、サーバ１０Ａは、端末４０から受信した第２トランザクションデータの検証を行う（Ｓ２０６）。より具体的には、サーバ１０Ａは、端末４０から受信した第２トランザクションデータに含まれる第２電子署名の検証と、第２トランザクションデータの正当性の検証とを行う。なお、ステップＳ２０６はスキップしてもよい。
　ステップＳ２０６において、サーバ１０Ａは、第２トランザクションデータの検証が成功しなかった場合（Ｓ２０６でＮ）、端末４０にエラー通知を行い（Ｓ２０７）、本処理を終了する。
　一方、ステップＳ２０６において、サーバ１０Ａは、第２トランザクションデータの検証が成功した場合（Ｓ２０６でＹ）、複数の他のサーバ１０Ｂ、１０Ｃに第２トランザクションデータを転送する（Ｓ２０８）。なお、ステップＳ２０６がスキップされた場合には、サーバ１０Ａは、端末４０から受信した第２トランザクションデータを複数の他のサーバ１０Ｂ、１０Ｃに転送すればよい。すると、サーバ１０Ｂ、１０Ｃではそれぞれ、転送されて受信した第２トランザクションデータの検証を行う。
　次に、サーバ１０Ａとサーバ１０Ｂとサーバ１０Ｃとは、コンセンサスアルゴリズムを実行する（Ｓ２０９）。ここで、ステップＳ２０９のコンセンサスアルゴリズムは、第２トランザクションデータの正当性について合意するための第２コンセンサスアルゴリズムに該当する。サーバ１０Ａとサーバ１０Ｂとサーバ１０Ｃとは、コンセンサスアルゴリズムを実行して、受信した第２トランザクションデータが正当なトランザクションデータであること（つまり正当性）を検証すると、それぞれ第２トランザクションデータを含むブロックを生成する。そして、サーバ１０Ａ、１０Ｂ、１０Ｃは、第２トランザクションデータを含むブロックを分散台帳に記録する。
　このようにして端末４０が作成した第２スマートコントラクトYnが分散台帳に記録される。
　そして、第２スマートコントラクトYnは、分散台帳に記録されることで、実行可能になるすなわち稼働する（Ｓ２１０）。なお、分散台帳に記録された第２スマートコントラクトYnは、他の機器等から、当該第２スマートコントラクトYnの第２コントラクトアドレスを含むトランザクションデータが受信され、分散台帳に記録された場合に実行されるとしてもよい。
　［第３スマートコントラクトXver2が稼働するまでの処理］
　次に、第２スマートコントラクトYnの稼働後に、第３スマートコントラクトXver2が作成されて稼働するまでの処理について説明する。本実施の形態では、サーバ１０Ａが第３スマートコントラクトXver2を作成する場合について説明するが、別のサーバ１０Ｂ及び１０Ｃが作成しても同様の説明となる。
　図９は、本実施の形態における第３スマートコントラクトXver2が稼働するまでの処理を説明するためのシーケンス図である。図１０は、本実施の形態における第３スマートコントラクトXver2の内容を概念的に示す図である。
　まず、サーバ１０Ａは、第２スマートコントラクトYnが作成されたか否かを確認すると（Ｓ３０１でＹ）、第２スマートコントラクトYnが他のスマートコントラクトと紐づいているかどうかを確認する（Ｓ３０２）。本実施の形態では、まず、サーバ１０Ａは、自身が管理する分散台帳を確認し、第２スマートコントラクトYnが記録されているかどうかを確認する。次いで、サーバ１０Ａは、分散台帳に記録されている第２スマートコントラクトYnを確認し、他のスマートコントラクトと紐づいていることを示す箇所が含まれているかを確認する。
　ステップＳ３０２において、サーバ１０Ａは、第２スマートコントラクトYnが他のスマートコントラクトと紐づいていることを確認すると（Ｓ３０２でＹ）、第２スマートコントラクトYnに紐づいているスマートコントラクトを特定する（Ｓ３０３）。本実施の形態では、まず、サーバ１０Ａは、図８に示すような第２スマートコントラクトYnの内容を参照して、第２トランザクションデータYnに含まれる第１コントラクトアドレスを特定する。次いで、サーバ１０Ａは、特定した第１コントラクトアドレスを参照して、第１スマートコントラクトXver1を特定する。なお、ステップＳ３０２において、サーバ１０Ａは、第２スマートコントラクトYnが他のスマートコントラクトと紐づいていないことを確認すると（Ｓ３０２でＮ）、本処理を終了する。
　次に、サーバ１０Ａは、特定した第１スマートコントラクトXver1から、第１契約の内容等を取得する（Ｓ３０４）。本実施の形態では、サーバ１０Ａは、特定した第１スマートコントラクトXver1から、第１契約の内容と、第２スマートコントラクトYnを特定するために用いられる仮に決められた変数と、第２スマートコントラクトYnが作成される条件とを取得する。
　次に、サーバ１０Ａは、第１契約に対応する第３スマートコントラクトXver2を作成する（Ｓ３０５）。ここで、第３スマートコントラクトXver2は、分散台帳を利用することで別途協議において締結した第２契約と第１契約との契約行動が実行可能にプログラム化されたスマートコントラクトである。第３スマートコントラクトXver2では、第２契約に対応する第２スマートコントラクトYnは飛び先として表現され、第２スマートコントラクトYnに飛ぶことで第２契約の契約行動が実行可能になる。本実施の形態では、第３スマートコントラクトXver2は、例えば図１０に示す内容が入力される。すなわち、第３スマートコントラクトXver2には、第１契約の内容と、別途契約の飛び先と第２スマートコントラクトYnが作成される条件とが入力されている。図１０に示す例では、別途協議の飛び先として、例えば「Xver2＝Yn」で示されるように、飛び先が第２契約に対応する第２スマートコントラクトYnであることが示されている。飛び先が第２スマートコントラクトYnであることを示すために、飛び先には、第２スマートコントラクトYnの第２コントラクトアドレスが入力される。なお、別途協議の飛び先に入力されるものは、第２スマートコントラクトYnを特定するために用いることができれば、その態様は問われない。
　次に、サーバ１０Ａは、ステップＳ３０５で作成した第３スマートコントラクトXver2と、サーバ１０Ａに紐づけられる第３電子署名とを含む第３トランザクションデータを生成する（Ｓ３０６）。
　次に、サーバ１０Ａは、ステップＳ３０６で生成した第３トランザクションデータを、複数の他のサーバ１０Ｂ、１０Ｃに転送する（Ｓ３０７）。すると、サーバ１０Ｂ、１０Ｃではそれぞれ、転送されて受信した第３トランザクションデータの検証を行う。
　次に、サーバ１０Ａとサーバ１０Ｂとサーバ１０Ｃとは、コンセンサスアルゴリズムを実行する（Ｓ３０８）。ここで、ステップＳ３０８のコンセンサスアルゴリズムは、第３トランザクションデータの正当性について合意するための第３コンセンサスアルゴリズムに該当する。サーバ１０Ａとサーバ１０Ｂとサーバ１０Ｃとは、コンセンサスアルゴリズムを実行して、受信した第３トランザクションデータが正当なトランザクションデータであること（つまり正当性）を検証すると、それぞれ第３トランザクションデータを含むブロックを生成する。そして、サーバ１０Ａ、１０Ｂ、１０Ｃは、第３トランザクションデータを含むブロックを分散台帳に記録する。
　このようにして、サーバ１０Ａは、第１スマートコントラクトXver1に対して別途協議により締結した第１契約を主契約とした副契約である第２契約に対応する第２スマートコントラクトへの飛び先を反映した第３スマートコントラクトXver2を作成して分散台帳に記録する。
　そして、第３スマートコントラクトXver2は、分散台帳に記録されることで、実行可能になるすなわち稼働する（Ｓ３０９）。これにより、第１契約と別途協議において締結した第２契約との契約行動が実行可能になる。
　［効果等］
　以上のように、本開示の制御方法等によれば、別途協議が将来発生する可能性のある第１契約に対応する第１スマートコントラクトに、第１契約に規定される別途協議により締結され得る第２契約に対応する第２スマートコントラクトのコントラクトアドレスの代替としての変数を含める。第１スマートコントラクトの作成時には、第２スマートコントラクトは作成されておらず、コントラクトアドレスも決まっていないことから、代替としての変数を含めている。これにより、将来発生する可能性のある別途協議を第１スマートコントラクトで表現できる。
　そして、第１契約に別途協議が実際に発生し、当該別途協議により締結された第１契約を主契約とした副契約である第２契約に対応する第２スマートコントラクトが作成され、稼働したとする。この場合、本開示の制御方法等は、第１スマートコントラクトに別途協議により締結した第２契約に対応する第２スマートコントラクトへの飛び先を反映した第１契約に対応する第３スマートコントラクトを新たに作成して分散台帳に記録する。
　このようにして、将来発生する可能性のある別途協議を第１スマートコントラクトで表現できるので、別途協議が将来発生する可能性のある契約に対応するスマートコントラクトの利用が促進される。この結果、契約行動の自動化によるメリットすなわち不正防止、並びに、仲介者を介さないことによる時間コスト及びエネルギーコスト削減を図ることができる。
　つまり、本開示の制御方法等によれば、分散台帳を用いて、時間コストとエネルギーコストとをより低減することができる。
　なお、上記の実施の形態では、第２スマートコントラクトが作成される条件は、別途協議により第１契約を主契約とした副契約として第２契約が締結された場合として説明していたが、これに限らない。当該条件に、さらに、第２スマートコントラクトを作成した端末４０以外の端末４１を操作するユーザの合意を取ることを含めてもよい。また、当該条件に、さらに、第２スマートコントラクトを作成した端末４０を操作するユーザの合意及び端末４１を操作するユーザの合意を取ることを含めてもよい。
　また、上記の実施の形態では、第１契約に規定される別途協議により締結される第１契約を主契約とした副契約としての第２契約の数が、１つである場合について説明していたが、これに限らない。第１契約に規定される別途協議により締結される第２契約の数は、複数であってもよく、別途協議により締結される第２契約の数に制限を設ければよい。この場合、サーバ１０Ａは、第１スマートコントラクトに別途協議により締結した複数の第２スマートコントラクトへの飛び先を反映した第３スマートコントラクトを作成して分散台帳に記録すればよい。
　（変形例１）
　変形例１では、第２スマートコントラクトが作成される条件として、別途協議により第２契約が締結された場合に加えて、第２スマートコントラクトを作成した端末４０以外の端末４１を操作するユーザの合意を取ることを含む場合について説明する。
　図１１Ａ及び図１１Ｂは、本実施の形態の変形例１における第２スマートコントラクトYnが稼働するまでの処理を説明するためのシーケンス図である。以下でも、第１スマートコントラクトを第１スマートコントラクトXver1と表記し、第２スマートコントラクトを第２スマートコントラクトYnと表記する。なお、本変形例における第２スマートコントラクトYnの内容は、図８を用いて説明した通りである。
　図１１Ａに示すシーケンス図は、図７に示すシーケンス図と比較して、第２スマートコントラクトYnを作成してもよいかどうかを確認する主体がサーバ１０Ａに変更されている点と、端末４１に対して合意確認依頼を取っている点とで異なる。図１１Ｂに示すシーケンス図は、図７に示すシーケンス図と比較して、さらに、Ｂさんの合意確認結果を示すトランザクションデータを分散台帳に記録する点で異なる。
　図１１Ａにおいて、まず、端末４０は、図７と同様、Ａさんの操作により、第１契約に規定される別途協議があったことが入力される（Ｓ３０１でＹ）とする。この場合、端末４０は、別途協議により締結した第２契約の締結者の１人であるＡさんの操作により、第２契約に対応する第２スマートコントラクトYnを作成する（Ｓ３０４）。ここで、サーバ１０Ａは、ステップＳ３０２において、別途協議により締結され得る第２契約に対する第２スマートコントラクトYnが作成されてもよいかを判定している。本変形例では、端末４０が、ステップＳ３０４で作成する第２スマートコントラクトYnは、ｎ番目に作成される第２スマートコントラクトであり、ｎが所定値以下であるとしている。このため、サーバ１０Ａは、ステップＳ３０２において、第２スマートコントラクトYnを作成してもよいと判定し（Ｓ３０２でＹ）、作成ＯＫの旨を示す通知を端末４０に送信している（Ｓ３０３）。なお、ステップＳ３０２及びＳ３０３は、ステップＳ３０４の前に行われていれば、ステップＳ３０１の前に行われていても、ステップＳ３０１とステップＳ３０４との間に行われていてもよい。
　次に、端末４０は、ステップＳ３０４で作成した第２スマートコントラクトYnと、第１ユーザであるＡさんに紐づけられる第２電子署名とを含む第２トランザクションデータを生成する（Ｓ３０５）。
　次に、端末４０は、ステップＳ３０５で生成した第２トランザクションデータを、例えばサーバ１０Ａに送信する（Ｓ３０６）。なお、端末４０は、ステップＳ３０５で生成した第２トランザクションデータを、サーバ１０Ｂまたはサーバ１０Ｃに送信してもよい。この場合、以下で説明するサーバ１０Ａの動作がサーバ１０Ｂまたはサーバ１０Ｃの動作となる。
　次に、サーバ１０Ａは、端末４０から受信した第２トランザクションデータの検証を行う（Ｓ３０７）。ステップＳ３０７及びＳ３０８については図７のステップＳ２０６及びＳ２０７と同様の処理であるため具体的な説明は省略する。
　ステップＳ３０７において、サーバ１０Ａは、第２トランザクションデータの検証が成功した場合（Ｓ３０７でＹ）、自身の分散台帳を参照して、第２スマートコントラクトYnが作成される条件を特定する（Ｓ３０９）。より具体的には、サーバ１０Ａは、自身の分散台帳に記録される第１スマートコントラクトXver1を参照して、第１スマートコントラクトXver1に含まれる、第２スマートコントラクトYnが作成される条件を特定する。本変形例では、当該条件には、別途協議により第２契約が締結された場合に加えて、第２スマートコントラクトYnを作成した端末４０以外の端末４１を操作するユーザの合意を取ることが含まれている。
　次に、サーバ１０Ａは、ステップＳ３０９において特定した条件に従って、端末４１に、作成された第２スマートコントラクトYnについての合意確認依頼を送信する（Ｓ３１０）。
　次に、別途協議により締結された第２契約の当事者であるＢさんの操作により、端末４１に、作成された第２スマートコントラクトYnについての合意確認結果が入力される。すると、端末４１は、当該合意確認結果と、Ｂさんに紐づけられる電子署名とを含む第４トランザクションデータを生成する（Ｓ３１１）。
　次に、端末４１は、ステップＳ３１１で生成した第４トランザクションデータを、例えばサーバ１０Ａに送信する（Ｓ３１２）。なお、端末４１は、ステップＳ３１１で生成した第４トランザクションデータを、サーバ１０Ｂまたはサーバ１０Ｃに送信してもよい。この場合、以下で説明するサーバ１０Ａの動作がサーバ１０Ｂまたはサーバ１０Ｃの動作となる。
　次に、サーバ１０Ａは、端末４１から受信した第４トランザクションデータに含まれるＢさんの合意確認結果を参照し、Ｂさんが合意したか否かを確認する（Ｓ３１３）。
　ステップＳ３１３において、サーバ１０Ａは、Ｂさんが合意しなかったことを確認すると（Ｓ３１３でＮ）、Ｓ３０２に戻る。つまり、この場合には、サーバ１０Ａは、第４トランザクションデータ及び第２トランザクションデータを分散台帳に記録しないので、本処理を終了または第２スマートコントラクトYnを再度生成することになる。
　一方、ステップＳ３１３において、サーバ１０Ａは、Ｂさんが合意したことを確認すると（Ｓ３１３でＹ）、複数の他のサーバ１０Ｂ、１０Ｃに第２トランザクションデータを転送する（Ｓ３１４）。なお、ステップＳ３１４～Ｓ３１６は、図７で説明したステップＳ２０８～Ｓ２１０と同様のため、説明を省略する。
　ステップＳ３１７において、サーバ１０Ａは、端末４１から受信した第４トランザクションデータの検証を行う。より具体的には、サーバ１０Ａは、端末４１から受信した第４トランザクションデータに含まれる電子署名の検証と、第４トランザクションデータの正当性の検証とを行う。なお、ステップＳ３１７はスキップしてもよい。
　ステップＳ３１７において、サーバ１０Ａは、第４トランザクションデータの検証が成功しなかった場合（Ｓ３１７でＮ）、端末４１にエラー通知を行い（Ｓ３１８）、本処理を終了する。
　一方、ステップＳ３１７において、サーバ１０Ａは、第４トランザクションデータの検証が成功した場合（Ｓ３１７でＹ）、複数の他のサーバ１０Ｂ、１０Ｃに第４トランザクションデータを転送する（Ｓ３１９）。なお、ステップＳ３１７がスキップされた場合には、サーバ１０Ａは、端末４１から受信した第４トランザクションデータを複数の他のサーバ１０Ｂ、１０Ｃに転送すればよい。すると、サーバ１０Ｂ、１０Ｃではそれぞれ、転送されて受信した第４トランザクションデータの検証を行う。
　次に、サーバ１０Ａとサーバ１０Ｂとサーバ１０Ｃとは、第４トランザクションデータの正当性について合意するためのコンセンサスアルゴリズムを実行する（Ｓ３２０）。サーバ１０Ａとサーバ１０Ｂとサーバ１０Ｃとは、コンセンサスアルゴリズムを実行して、受信した第４トランザクションデータが正当なトランザクションデータであること（つまり正当性）を検証すると、それぞれ第４トランザクションデータを含むブロックを生成する。そして、サーバ１０Ａ、１０Ｂ、１０Ｃは、第２トランザクションデータを含むブロックを分散台帳に記録する。
　このようにして端末４０が作成した第２スマートコントラクトYnと端末４１により送信されたＢさんの合意確認結果とが分散台帳に記録される。
　（変形例２）
　変形例２では、第２スマートコントラクトが作成される条件として、別途協議により第２契約が締結された場合に加えて、第２スマートコントラクトを作成した端末４０を操作するユーザの合意及び端末４１を操作するユーザの合意を取ることも含まれる場合について説明する。
　図１２Ａ及び図１２Ｂは、本実施の形態の変形例２における第２スマートコントラクトYnが稼働するまでの処理を説明するためのシーケンス図である。以下でも、第１スマートコントラクトを第１スマートコントラクトXver1と表記し、第２スマートコントラクトを第２スマートコントラクトYnと表記する。なお、本変形例における第２スマートコントラクトYnの内容は、図８を用いて説明した通りである。
　図１２Ａに示すシーケンス図は、図１１Ａに示すシーケンス図と比較して、第２スマートコントラクトYnを作成してもよいかどうかを確認する主体がサーバ１０Ａから端末４０に変更されている点と、端末４１に加えて端末４０に対しても合意確認を取っている点とで異なる。また、図１２Ｂに示すシーケンス図は、図１１Ｂに示すシーケンス図と比較して、さらに、Ａさんの合意確認結果を示すトランザクションデータも分散台帳に記録する点で異なる。
　図１２Ａにおいて、まず、端末４０は、ステップＳ４００において、別途協議により締結され得る第２契約に対する第２スマートコントラクトを作成してもよいかどうかを判定している（Ｓ４００）。本変形例では、端末４０が、次に作成する第２スマートコントラクトYnは、ｎ番目に作成される第２スマートコントラクトであり、ｎが所定値以下であるとしている。このため、端末４０は、ステップＳ４００において、第２スマートコントラクトYnを作成してもよいと判定する（Ｓ４００で作成ＯＫ）。
　次に、端末４０は、Ａさんの操作により、第１契約に規定される別途協議があったことが入力されると（Ｓ４０１でＹ）、端末４０は、Ａさんの操作により、第２契約に対応する第２スマートコントラクトYnを作成する（Ｓ４０２）。なお、ステップＳ４００は、ステップＳ４０２の前に行われていれば、ステップＳ４０１の後に行われていてもよい。
　次に、端末４０は、第２トランザクションデータを生成し（Ｓ４０３）、サーバ１０Ａに送信する（Ｓ４０４）。なお、ステップＳ４０２～Ｓ４０６は、図１１Ａで説明したステップＳ３０４～Ｓ３０８と同様のため、説明を省略する。
　ステップＳ４０５において、サーバ１０Ａは、第２トランザクションデータの検証が成功した場合（Ｓ４０５でＹ）、自身の分散台帳を参照して、第２スマートコントラクトYnが作成される条件を特定する（Ｓ４０７）。より具体的には、サーバ１０Ａは、自身の分散台帳に記録される第１スマートコントラクトXver1を参照して、第１スマートコントラクトXver1に含まれる、第２スマートコントラクトYnが作成される条件を特定する。本変形例では、当該条件には、別途協議により第２契約が締結された場合に加えて、第２スマートコントラクトYnを作成した端末４０を操作するユーザの合意と、当該端末４０以外の端末４１を操作するユーザの合意を取ることが含まれている。
　次に、サーバ１０Ａは、ステップＳ４０７において特定した条件に従って、端末４０及び端末４１に、作成された第２スマートコントラクトYnについての合意確認依頼を送信する（Ｓ４０８）。
　次に、端末４０は、別途協議により締結された第２契約の当事者であるＡさんの操作により、作成された第２スマートコントラクトYnについての合意結果が入力される。端末４０は、Ａさんにより合意することを示す合意結果が入力された場合（Ｓ４０９でＹ）、当該合意結果と、Ａさんに紐づけられる電子署名とを含む第５トランザクションデータを生成する（Ｓ４１０）。なお、端末４０は、Ａさんにより合意しないことを示す合意結果が入力された場合（Ｓ４０９でＮ）、最初すなわちステップＳ４００に戻る。
　次に、端末４０は、ステップＳ４１０で生成した第５トランザクションデータを、例えばサーバ１０Ａに送信する（Ｓ４１１）。なお、端末４０は、ステップＳ４１０で生成した第５トランザクションデータを、サーバ１０Ｂまたはサーバ１０Ｃに送信してもよい。この場合、以下で説明するサーバ１０Ａの動作がサーバ１０Ｂまたはサーバ１０Ｃの動作となる。
　また、端末４１は、別途協議により締結された第２契約の当事者であるＢさんの操作により、作成された第２スマートコントラクトYnについての合意結果が入力される。端末４１は、Ｂさんにより合意することを示す合意結果が入力された場合（Ｓ４１２でＹ）、当該合意結果と、Ｂさんに紐づけられる電子署名とを含む第６トランザクションデータを生成する（Ｓ４１３）。なお、端末４１は、Ｂさんにより合意しないことを示す合意結果が入力された場合（Ｓ４１３でＮ）、最初すなわちステップＳ４００に戻る。
　次に、端末４１は、ステップＳ４１３で生成した第６トランザクションデータを、例えばサーバ１０Ａに送信する（Ｓ４１４）。なお、端末４１は、ステップＳ４１３で生成した第６トランザクションデータを、サーバ１０Ｂまたはサーバ１０Ｃに送信してもよい。この場合、以下で説明するサーバ１０Ａの動作がサーバ１０Ｂまたはサーバ１０Ｃの動作となる。なお、ステップＳ４０９とＳ４１２とはどちらが先に処理されてもよい。
　次に、サーバ１０Ａは、端末４０及び端末４１から受信した第５及び第６トランザクションデータに含まれるＡさん及びＢさんの合意結果を参照し、条件を満たす、すなわちＡさん及びＢさんが合意したか否かを確認する（Ｓ４１５）。
　ステップＳ４１５において、サーバ１０Ａは、Ａさん及びＢさんが合意しており条件を満たしていることを確認した場合（Ｓ４１５でＹ）、端末４０、４１から受信した第５、第６トランザクションデータの検証を行う（Ｓ４１６）。より具体的には、サーバ１０Ａは、端末４０、４１から受信した第５、第６トランザクションデータに含まれる電子署名の検証と、第５、第６トランザクションデータの正当性の検証とを行う。なお、ステップＳ４１６はスキップしてもよい。
　一方、ステップＳ４１５において、サーバ１０Ａは、ＡさんまたはＢさんが合意しておらず条件を満たしていないことを確認した場合（Ｓ４１５でＮ）、最初すなわちステップＳ４００に戻る。この場合には、サーバ１０Ａは、第２トランザクションデータ、第５トランザクションデータ及び第６トランザクションデータを分散台帳に記録しないので、本処理を終了または第２スマートコントラクトYnを再度生成することになる。
　ステップＳ４１６において、サーバ１０Ａは、第５または第６トランザクションデータの検証が成功しなかった場合（Ｓ４１６でＮ）、端末４０、端末４１にエラー通知を行い（Ｓ４１７）、本処理を終了する。
　一方、ステップＳ４１６において、サーバ１０Ａは、第５及び第６トランザクションデータの検証が成功した場合（Ｓ４１６でＹ）、複数の他のサーバ１０Ｂ、１０Ｃに第２、第５及び第６トランザクションデータを転送する（Ｓ４１８）。
　次に、サーバ１０Ａとサーバ１０Ｂとサーバ１０Ｃとは、コンセンサスアルゴリズムを実行する（Ｓ４１９）。ここで、ステップＳ４１９のコンセンサスアルゴリズムは、第２トランザクションデータの正当性について合意するためのコンセンサスアルゴリズムと、第５及び第６トランザクションデータの正当性について合意するためのコンセンサスアルゴリズムとが実行される。これらは独立したコンセンサスアルゴリズム実行されてもよいし、一つのコンセンサスアルゴリズムとして実行されてもよい。
　このようにして端末４０が作成した第２スマートコントラクトYnと、端末４０及び端末４１により送信されたＡさん及びＢさんの合意結果とが分散台帳に記録される。
　そして、第２スマートコントラクトYnは、分散台帳に記録されることで、実行可能になるすなわち稼働する（Ｓ４２０）。
　（変形例３）
　変形例３では、第２スマートコントラクトが作成される条件として、別途協議により第２契約が締結された場合に加えて、第２スマートコントラクトを作成した端末４０以外の端末４１を操作するユーザの合意のみを取ることが含まれる場合について説明する。
　図１３Ａ及び図１３Ｂは、本実施の形態の変形例３における第２スマートコントラクトYnが稼働するまでの処理を説明するためのシーケンス図である。以下でも、第１スマートコントラクトを第１スマートコントラクトXver1と表記し、第２スマートコントラクトを第２スマートコントラクトYnと表記する。なお、本変形例における第２スマートコントラクトYnの内容は、図８を用いて説明した通りである。
　図１３Ａ及び図１３Ｂに示すシーケンス図は、図１１Ａ及び図１１Ｂに示すシーケンス図と比較して、端末４１に対して合意確認依頼をし、端末４１を操作するＢさんが合意した場合のみその後の処理を進めている点で異なる。
　図１３Ａに示すステップＳ５０１～Ｓ５０７は、図１１Ａに示すステップＳ３０１～Ｓ３０７と同様の処理となるため説明を省略する。
　ステップＳ５０７において、サーバ１０Ａは、第２トランザクションデータの検証が成功した場合（Ｓ５０７でＹ）、自身の分散台帳を参照して、第２スマートコントラクトYnが作成される条件を特定する（Ｓ５０９）。より具体的には、サーバ１０Ａは、自身の分散台帳に記録される第１スマートコントラクトXver1を参照して、第１スマートコントラクトXver1に含まれる、第２スマートコントラクトYnが作成される条件を特定する。本変形例では、当該条件には、別途協議により第２契約が締結された場合に加えて、第２スマートコントラクトを作成した端末４０以外の端末４１を操作するユーザの合意のみを取ることが含まれている。
　次に、サーバ１０Ａは、ステップＳ５０９において特定した条件に従って、端末４１に、作成された第２スマートコントラクトYnについての合意確認依頼を送信する（Ｓ５１０）。
　次に、Ｂさんの操作により、作成された第２スマートコントラクトYnについての合意結果が端末４１に入力されたとする。この場合、端末４１は、Ｂさんにより合意することを示す合意結果が入力されたことを確認し（Ｓ５１１でＹ）、当該合意結果と、Ｂさんに紐づけられる電子署名とを含む第７トランザクションデータを生成する（Ｓ５１２）。
　次に、端末４１は、ステップＳ５１２で生成した第７トランザクションデータを、例えばサーバ１０Ａに送信する（Ｓ５１３）。なお、端末４１は、ステップＳ５１２で生成した第７トランザクションデータを、サーバ１０Ｂまたはサーバ１０Ｃに送信してもよい。この場合、以下で説明するサーバ１０Ａの動作がサーバ１０Ｂまたはサーバ１０Ｃの動作となる。
　次に、サーバ１０Ａは、端末４１から第７トランザクションデータを受信すると（Ｓ５１４でＹ）、端末４１から受信した第７トランザクションデータの検証を行う（Ｓ５１５）。より具体的には、サーバ１０Ａは、端末４１から第７トランザクションデータを受信すると、受信した第７トランザクションデータに含まれる電子署名の検証と、第７トランザクションデータの正当性の検証とを行う。なお、ステップＳ５１５はスキップしてもよい。
　ステップＳ５１５において、サーバ１０Ａは、第７トランザクションデータの検証が成功しなかった場合（Ｓ５１５でＮ）、端末４１にエラー通知を行い（Ｓ５１６）、本処理を終了する。
　一方、ステップＳ５１５において、サーバ１０Ａは、第７トランザクションデータの検証が成功した場合（Ｓ５１５でＹ）、複数の他のサーバ１０Ｂ、１０Ｃに第２トランザクションデータを転送する（Ｓ５１７）。なお、ステップＳ５１５がスキップされた場合には、サーバ１０Ａは、端末４０から受信した第２トランザクションデータと端末４１から受信した第７トランザクションデータとを複数の他のサーバ１０Ｂ、１０Ｃに転送すればよい。すると、サーバ１０Ｂ、１０Ｃではそれぞれ、転送されて受信した第４トランザクションデータの検証と第７トランザクションデータの検証とを独立に行う。
　次に、サーバ１０Ａとサーバ１０Ｂとサーバ１０Ｃとは、第２トランザクションデータの正当性について合意するためのコンセンサスアルゴリズムを実行し（Ｓ５１８）。分散台帳に記録されることで第２スマートコントラクトYnを稼働させる（Ｓ５１９）。なお、ステップＳ５１８及び５１９の処理は、図１１Ａに示すステップＳ３１５及びＳ３１６と同様の処理となるため説明を省略する。
　また、サーバ１０Ａは、第７トランザクションデータの検証が成功した場合（Ｓ５１５でＹ）、複数の他のサーバ１０Ｂ、１０Ｃに第７トランザクションデータを転送する（Ｓ５２０）。
　次に、サーバ１０Ａとサーバ１０Ｂとサーバ１０Ｃとは、第７トランザクションデータの正当性について合意するためのコンセンサスアルゴリズムを実行する（Ｓ５２１）。なお、ステップＳ５２１の処理は、図１１Ａに示すステップＳ３１８と同様であるため具体的な説明は省略する。
　このようにして端末４０が作成した第２スマートコントラクトYnと、端末４１により送信されたＢさんの合意結果を含む第７トランザクションデータとが分散台帳に記録される。
　（変形例４）
　上記の実施の形態では、第３スマートコントラクトは、サーバ１０Ａにより作成されるとして説明したが、これに限らない。Ａさんにより操作された端末４０が作成してもよい。
　変形例４では、Ａさんの操作により端末４０が第３スマートコントラクトを作成する場合について説明する。以下では、第２スマートコントラクトを第２スマートコントラクトYnと表記し、第３スマートコントラクトを第３スマートコントラクトXver2と表記する。
　図１４は、本実施の形態の変形例４における第３スマートコントラクトXver2が稼働するまでの処理を説明するためのシーケンス図である。
　図１４に示すシーケンス図は、図９に示すシーケンス図と比較して、第３スマートコントラクトXver2を作成する主体が端末４０に変更されている点が異なる。
　すなわち、まず、端末４０は、Ａさんの操作により、第１契約に対応する第３スマートコントラクトXver2を作成する（Ｓ６０１）。ここで、Ａさんは、第１契約の当事者であり、第１契約に規定される別途協議により締結された第２契約の当事者である。このため、Ａさんは、自ら作成した第２トランザクションデータYnに含まれる第１コントラクトアドレスを容易に取得できる。また、Ａさんは、第１スマートコントラクトXver1から、第１契約の内容と、第２スマートコントラクトYnを特定するために用いられる仮に決められた変数と、第２スマートコントラクトYnが作成される条件とを容易に取得できる。つまり、Ａさんは、第２スマートコントラクトYnを作成し、分散台帳に記録されたことを確認すると、Ａさんの操作により、端末４０に、第３スマートコントラクトXver2を容易に作成させることができる。なお、第３スマートコントラクトXver2には、図１０を用いて説明したように、第１契約の内容と、別途契約の飛び先である第２スマートコントラクトYnと、第２スマートコントラクトYnが作成される条件とが入力されている。
　次に、端末４０は、ステップＳ６０１で作成した第３スマートコントラクトXver2と、第１ユーザであるＡさんに紐づけられる第１電子署名とを含む第３トランザクションデータを生成する（Ｓ６０２）。
　次に、端末４０は、ステップＳ６０２で生成した第３トランザクションデータを、例えばサーバ１０Ａに送信する（Ｓ６０３）。なお、端末４０は、ステップＳ６０２で生成した第３トランザクションデータを、サーバ１０Ｂまたはサーバ１０Ｃに送信してもよい。この場合、以下で説明するサーバ１０Ａの動作がサーバ１０Ｂまたはサーバ１０Ｃの動作となる。
　次に、サーバ１０Ａは、端末４０から受信した第３トランザクションデータの検証を行う（Ｓ６０４）。より具体的には、サーバ１０Ａは、端末４０から受信した第３トランザクションデータに含まれる第１電子署名の検証と、第３トランザクションデータの正当性の検証とを行う。なお、ステップＳ６０４はスキップしてもよい。
　ステップＳ６０４において、サーバ１０Ａは、第３トランザクションデータの検証が成功しなかった場合（Ｓ６０４でＮ）、端末４０にエラー通知を行い（Ｓ６０５）、本処理を終了する。
　一方、ステップＳ６０４において、サーバ１０Ａは、第３トランザクションデータの検証が成功した場合（Ｓ６０４でＹ）、複数の他のサーバ１０Ｂ、１０Ｃに第１トランザクションデータを転送する（Ｓ６０６）。
　なお、ステップＳ６０６以降の処理すなわちステップＳ６０６～Ｓ６０８の処理は、図９に示すステップＳ３０７～Ｓ３０９の処理と同様のため、説明を省略する。
　このようにして端末４０により、第１契約に対応する第３スマートコントラクトXver2が作成されてもよい。
　［その他の実施の形態等］
　以上のように、本開示について上記の実施の形態に基づいて説明してきたが、本開示は、上記の実施の形態に限定されないのはもちろんである。以下のような場合も本開示に含まれる。
　（１）例えば本開示には、上記実施の形態の制御システム１においてブロックチェーンとして記録されるブロックに用いられるデータ構造も含まれる。より具体的には、本開示のデータ構造は、ユーザにより操作される端末と、それぞれ、分散台帳を管理し、かつ、前記分散台帳を利用してスマートコントラクトを管理する複数のサーバとを備えるシステムにおいて前記分散台帳に記録されるブロックに用いられるデータ構造であって、前記データ構造は、第１契約の締結者の１人である第１ユーザにより操作された第１端末から受信して得た第１契約に対応する第１スマートコントラクトであって、前記分散台帳を利用して前記第１契約の契約行動が実行可能にプログラム化された第１スマートコントラクトと、前記第１ユーザに紐づけられる第１電子署名とを含む第１のトランザクションデータを含み、前記第１スマートコントラクトには、前記第１契約の内容と、前記第１契約を主契約とした副契約である第２契約であって新たに締結される予定の第２契約に対応する第２スマートコントラクトを特定するために用いられる仮に決められた変数と、前記第２スマートコントラクトが作成される条件とが含まれている。
　（２）なお、上記実施の形態では、別途協議により締結された第２契約に対応する第２スマートコントラクトを分散台帳に記録する際に、第２スマートコントラクトについて合意が取れているのかを確認する場合の例を挙げているが、本開示は、この例に限らない。サーバ１０Ａまたは端末４０が第３スマートコントラクトを作成する際に第２スマートコントラクトについての合意が取れているのかを確認してもよいし、第３スマートコントラクトが稼働する際に第２スマートコントラクトについての合意が取れているのかを確認してもよい。
　（３）また、本開示では、第１～第３スマートコントラクトを含むトランザクションデータを分散台帳に記録するための合意形成に、マルチシグを使ってもよい。ここで、マルチシグとは、マルチシグネチャーの略称でトランザクションデータの署名に複数の秘密鍵を必要とする技術をいう。
　（４）また、上記実施の形態では、別途協議により締結された第２契約に対応する第２スマートコントラクトは、一つの主契約である第１契約に紐づいているとして説明したが、これに限らない。本開示では、第２スマートコントラクトは、複数の第１契約に紐づいていてもよい。
　（５）上記の実施の形態における各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。前記ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
　（６）上記の実施の形態における各装置は、構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ　Ｓｃａｌｅ　Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
　また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部またはすべてを含むように１チップ化されてもよい。
　また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
　さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　（７）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
　（８）本開示は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。
　また、本開示は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕ－ｒａｙ（登録商標）　Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。
　また、本開示は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
　また、本開示は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。
　また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
　（９）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。
　本開示は、制御方法、サーバ、及び、データ構造に利用でき、例えば別途協議が将来発生する可能性のある契約に対応するスマートコントラクトを分散台帳に記録して利用する制御方法、サーバ、及び、データ構造などに利用可能である。
　１　　制御システム
　１０Ａ、１０Ｂ、１０Ｃ　　サーバ
　１１　　処理部
　１２　　台帳管理部
　１３　　制御部
　１５　　格納部
　１６　　台帳記憶部
　１７　　ワーキングメモリ
　４０、４１　　端末
　Ｂ１、Ｂ２、Ｂ３　　ブロック
　Ｎ　　ネットワーク

Claims (11)

  1. 　ユーザにより操作される端末と、それぞれ、分散台帳を管理し、かつ、前記分散台帳を利用してスマートコントラクトを管理する複数のサーバとを備えるシステムにおける、前記複数のサーバのうちの第１サーバによって実行される制御方法であって、
    　第１契約の締結者の１人である第１ユーザにより操作された第１端末から、前記第１契約に対応する第１スマートコントラクトであって、前記分散台帳を利用して前記第１契約の契約行動が実行可能にプログラム化された第１スマートコントラクトと、前記第１ユーザに紐づけられる第１電子署名とを含む第１トランザクションデータを受信し、
    　前記第１トランザクションデータを含むブロックを前記分散台帳に記録し、
    　前記第１スマートコントラクトには、前記第１契約の内容と、前記第１契約を主契約とした副契約である第２契約であって新たに締結される予定の第２契約に対応する第２スマートコントラクトを特定するために用いられる仮に決められた変数と、前記第２スマートコントラクトが作成される条件とが含まれている、
    　制御方法。
  2. 　前記第１トランザクションデータを含むブロックを前記分散台帳に記録する際、
    　前記複数のサーバのうちの前記第１サーバを除く複数の第２サーバとともに、前記第１トランザクションデータの正当性について合意するための第１コンセンサスアルゴリズムを実行し、
    　前記第１コンセンサスアルゴリズムによって前記第１トランザクションデータの正当性について合意された場合、前記第１トランザクションデータを含むブロックを前記分散台帳に記録する、
    　請求項１に記載の制御方法。
  3. 　前記制御方法は、
    　前記第１端末から、前記第２契約に対応する前記第２スマートコントラクトであって、前記分散台帳を利用して前記第２契約の契約行動が実行可能にプログラム化された前記第２スマートコントラクトと、前記第１ユーザに紐づけられる第２電子署名とを含む第２トランザクションデータを受信し、
    　前記第２トランザクションデータを含むブロックを前記分散台帳に記録し、
    　前記第２スマートコントラクトには、前記第２契約の内容と、前記第２スマートコントラクトの紐づき先を示す情報としての前記第１スマートコントラクトの第１コントラクトアドレスとが少なくとも含まれている、
    　請求項１または２に記載の制御方法。
  4. 　前記第２トランザクションデータを含むブロックを前記分散台帳に記録する際、
    　前記複数のサーバのうちの前記第１サーバを除く複数の第２サーバとともに、前記第２トランザクションデータの正当性について合意するための第２コンセンサスアルゴリズムを実行し、
    　前記第２コンセンサスアルゴリズムによって前記第２トランザクションデータの正当性について合意された場合、前記第２トランザクションデータを含むブロックを前記分散台帳に記録する、
    　請求項３に記載の制御方法。
  5. 　前記制御方法は、さらに、
    　前記第２トランザクションデータを受信した場合、前記第１コントラクトアドレスを参照して前記第１スマートコントラクトに含まれる前記条件を特定し、
    　第２トランザクションデータを受信した場合で、さらに、前記条件を満たすとき、前記第２コンセンサスアルゴリズムを実行する、
    　請求項４に記載の制御方法。
  6. 　前記第２スマートコントラクトには、前記第２契約の内容と、前記第１コントラクトアドレスとに加えて、前記変数が含まれている、
    　請求項３～５のいずれか１項に記載の制御方法。
  7. 　前記制御方法は、さらに、
    　前記第２トランザクションデータを含むブロックが前記分散台帳に記録された場合、前記第２トランザクションデータに含まれる前記第１コントラクトアドレスを参照して、前記第１スマートコントラクトを特定し、
    　特定した前記第１スマートコントラクトから、前記第１契約の内容と、前記変数と、前記条件とを取得して、前記第１契約の内容と、前記条件と、前記変数に代えて前記第２トランザクションデータの第２コントラクトアドレスとを含む第３スマートコントラクトであって前記第１契約に対応する第３スマートコントラクトを作成し、
    　作成した前記第３スマートコントラクトと、前記第１サーバに紐づけられる第３電子署名とを含む第３トランザクションデータを生成し、
    　前記第３トランザクションデータを含むブロックを前記分散台帳に記録する、
    　請求項３～６のいずれか１項に記載の制御方法。
  8. 　前記第３トランザクションデータを含むブロックを前記分散台帳に記録する際、
    　前記複数のサーバのうちの前記第１サーバを除く複数の第２サーバとともに、前記第３トランザクションデータの正当性について合意するための第３コンセンサスアルゴリズムを実行し、
    　前記第３コンセンサスアルゴリズムによって前記第３トランザクションデータの正当性について合意された場合、前記第３トランザクションデータを含むブロックを前記分散台帳に記録する、
    　請求項７に記載の制御方法。
  9. 　前記制御方法は、さらに、
    　前記第１サーバのワーキングメモリに、前記第１契約に対する最新のスマートコントラクトが前記第３スマートコントラクトである旨を示す情報を保持させる、
    　請求項７または８に記載の制御方法。
  10. 　ユーザにより操作される端末と、それぞれ、分散台帳を管理し、かつ、前記分散台帳を利用してスマートコントラクトを管理する複数のサーバとを備えるシステムにおける、前記複数のサーバのうちの一つのサーバであって、
    　プロセッサと、
    　前記プロセッサに処理を実行させるプログラムが記憶されたメモリと、
    　スマートコントラクトが格納された前記分散台帳が記憶されている記憶装置と、を備え、
    　前記プロセッサは、第１契約の締結者の１人である第１ユーザにより操作された第１端末から、前記第１契約に対応する第１スマートコントラクトであって、前記分散台帳を利用して前記第１契約の契約行動が実行可能にプログラム化された第１スマートコントラクトと、前記第１ユーザに紐づけられる第１電子署名とを含む第１トランザクションデータを受信し、
    　前記プロセッサは、前記第１トランザクションデータを含むブロックを前記分散台帳に記録し、
    　前記第１スマートコントラクトには、前記第１契約の内容と、前記第１契約を主契約とした副契約である第２契約であって新たに締結される予定の第２契約に対応する第２スマートコントラクトを特定するために用いられる仮に決められた変数と、前記第２スマートコントラクトが作成される条件とが含まれている、
    　サーバ。
  11. 　ユーザにより操作される端末と、それぞれ、分散台帳を管理し、かつ、前記分散台帳を利用してスマートコントラクトを管理する複数のサーバとを備えるシステムにおいて前記分散台帳に記録されるブロックに用いられるデータ構造であって、
    　前記データ構造は、
    　第１契約の締結者の１人である第１ユーザにより操作された第１端末から受信して得た第１契約に対応する第１スマートコントラクトであって、前記分散台帳を利用して前記第１契約の契約行動が実行可能にプログラム化された第１スマートコントラクトと、前記第１ユーザに紐づけられる第１電子署名とを含む第１のトランザクションデータを含み、
    　前記第１スマートコントラクトには、前記第１契約の内容と、前記第１契約を主契約とした副契約である第２契約であって新たに締結される予定の第２契約に対応する第２スマートコントラクトを特定するために用いられる仮に決められた変数と、前記第２スマートコントラクトが作成される条件とが含まれている、
    　データ構造。
     
PCT/JP2020/016705 2019-04-16 2020-04-16 制御方法、サーバ、及び、データ構造 WO2020213678A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202080027819.0A CN113785316A (zh) 2019-04-16 2020-04-16 控制方法、服务器及数据结构
JP2021514213A JPWO2020213678A1 (ja) 2019-04-16 2020-04-16
US17/497,302 US11809413B2 (en) 2019-04-16 2021-10-08 Control method, server, and data structure
US18/377,085 US20240037093A1 (en) 2019-04-16 2023-10-05 Control method, server, and data structure

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201962834728P 2019-04-16 2019-04-16
US62/834,728 2019-04-16

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/497,302 Continuation US11809413B2 (en) 2019-04-16 2021-10-08 Control method, server, and data structure

Publications (1)

Publication Number Publication Date
WO2020213678A1 true WO2020213678A1 (ja) 2020-10-22

Family

ID=72837261

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/016705 WO2020213678A1 (ja) 2019-04-16 2020-04-16 制御方法、サーバ、及び、データ構造

Country Status (4)

Country Link
US (2) US11809413B2 (ja)
JP (1) JPWO2020213678A1 (ja)
CN (1) CN113785316A (ja)
WO (1) WO2020213678A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022163457A1 (ja) * 2021-01-28 2022-08-04 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、サーバ、及びプログラム
WO2022224907A1 (ja) * 2021-04-22 2022-10-27 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、端末、及び、プログラム
DE102022129148A1 (de) 2021-11-17 2023-05-17 Honda Motor Co., Ltd. Vertragsverwaltungssystem und verfahren zur vertragsverwaltung

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02158B2 (ja) * 1982-01-13 1990-01-05 Taisei Corp
JP2019506074A (ja) * 2016-02-23 2019-02-28 エヌチェーン ホールディングス リミテッドＮｃｈａｉｎ Ｈｏｌｄｉｎｇｓ Ｌｉｍｉｔｅｄ ブロックチェーンを使用してピアツーピア分散型台帳におけるエンティティを効率的な移転のための方法およびシステム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6900266B2 (ja) 2017-07-26 2021-07-07 株式会社日立製作所 運用管理方法、運用管理システム、および、運用管理プログラム
JP6500158B1 (ja) * 2018-11-28 2019-04-10 太郎 西村 プログラム及び生成装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02158B2 (ja) * 1982-01-13 1990-01-05 Taisei Corp
JP2019506074A (ja) * 2016-02-23 2019-02-28 エヌチェーン ホールディングス リミテッドＮｃｈａｉｎ Ｈｏｌｄｉｎｇｓ Ｌｉｍｉｔｅｄ ブロックチェーンを使用してピアツーピア分散型台帳におけるエンティティを効率的な移転のための方法およびシステム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022163457A1 (ja) * 2021-01-28 2022-08-04 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、サーバ、及びプログラム
WO2022224907A1 (ja) * 2021-04-22 2022-10-27 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、端末、及び、プログラム
DE102022129148A1 (de) 2021-11-17 2023-05-17 Honda Motor Co., Ltd. Vertragsverwaltungssystem und verfahren zur vertragsverwaltung

Also Published As

Publication number Publication date
US11809413B2 (en) 2023-11-07
JPWO2020213678A1 (ja) 2020-10-22
US20240037093A1 (en) 2024-02-01
CN113785316A (zh) 2021-12-10
US20220027357A1 (en) 2022-01-27

Similar Documents

Publication Publication Date Title
Vazirani et al. Implementing blockchains for efficient health care: systematic review
CN110442652B (zh) 一种基于区块链的跨链数据处理方法及装置
WO2020213678A1 (ja) 制御方法、サーバ、及び、データ構造
Niranjanamurthy et al. Analysis of Blockchain technology: pros, cons and SWOT
CN114519180B (zh) 用于实施分布式账本制造历史的方法及系统
CN111164586B (zh) 用于更新区块链中的数据的系统和方法
AU2020414467B2 (en) Partially-ordered blockchain
CN110944046B (zh) 一种共识机制的控制方法及相关设备
Alshaikhli et al. Evolution of Internet of Things from blockchain to IOTA: A survey
CN112835612A (zh) 一种基于区块链的电子文档版本管理方法及装置
US11341267B1 (en) Death certificate information processing techniques
CN110245514B (zh) 一种基于区块链的分布式计算方法及系统
CN110866289A (zh) 基于区块链的数据处理方法、装置、服务器及存储介质
CA3116549A1 (en) Methods and systems for providing a customized network
CN110941672B (zh) 户籍管理方法、装置、设备以及存储介质
CN110599384A (zh) 组织关系的转移方法、装置、设备及存储介质
WO2023249696A1 (en) Computing technologies for enabling blockchain-based digital tokens with asset-specific attributes
JPWO2020085267A1 (ja) 制御方法、ファンド管理システム、プログラム、及び、データ構造
EP3945704B1 (en) A method and a system for securing data, especially data of biotechnological laboratories
CN115048677A (zh) 保单信息数据管理方法及相关设备
CN112150299B (zh) 年金数据处理方法、装置、介质及电子设备
Mubaslat Demonstrating the Functionality and Efficacy of Blockchain-based System in Healthcare Using Simulation Tools
CN111859041A (zh) 数据报送方法及装置
Kumar et al. Blockchain technology and applications
CN113379577A (zh) 一种事务审核方法、装置及设备

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021514213

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20791841

Country of ref document: EP

Kind code of ref document: A1