CONTROL METHOD, ANALYSIS APPARATUS, AND PROGRAM

Abstract

A method for controlling an analysis device, the method involving: analyzing the binary code of each of a plurality of smart contracts stored in a first distributed ledger (S1); acquiring, using the result of analysis, a plurality of commonalized information pieces in which information provided by each of the plurality of smart contracts is expressed in a common format (S2); and performing a control to generate transaction data that includes the acquired plurality of commonalized information pieces and store the generated transaction data in a second distributed ledger (S3).

Description

[Technical field]

[0001] The present invention relates to a control method, an analysis device, and a program. [Background technology]

[0002] There is a technology that uses a distributed ledger to manage contract-related information. Information stored in the distributed ledger is managed in such a way that it is virtually impossible to rewrite it.

[0003] In a system using a distributed ledger, a technique for aligning operation policies or operation timing has been disclosed (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0004] [Patent Document 1] International Publication No. 2019 / 021792 Summary of the Invention [Problem to be solved by the invention]

[0005] The present invention provides a control method for suppressing an increase in power consumption of a computer system that manages contracts. [Means for solving the problem]

[0006] A control method according to one embodiment of the present invention is a control method that analyzes the binary code of each of a plurality of smart contracts stored in a first distributed ledger, uses the results of the analysis to obtain a plurality of common pieces of information that express information provided by each of the plurality of smart contracts in a common format, generates transaction data including the obtained plurality of common pieces of information, and controls the storage of the generated transaction data in a second distributed ledger.

[0007] These comprehensive or specific aspects may be realized as a system, an apparatus, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, or may be realized as any combination of a system, an apparatus, an integrated circuit, a computer program, and a recording medium. Effect of the Invention

[0008] The control method of the present invention can suppress an increase in power consumption of a computer system that manages contracts. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is an explanatory diagram that illustrates a contract according to an embodiment. [Diagram 2] FIG. 2 is an explanatory diagram illustrating a first example of a contract code according to the embodiment. [Diagram 3] FIG. 3 is an explanatory diagram illustrating a second example of a contract code according to the embodiment. [Figure 4] FIG. 4 is a block diagram showing a schematic configuration of a contract management system according to an embodiment. [Diagram 5] FIG. 5 is a block diagram illustrating a functional configuration of the ledger server according to the embodiment. [Figure 6] FIG. 6 is a block diagram showing a functional configuration of the analysis device according to the embodiment. [Figure 7] FIG. 7 is a block diagram illustrating a functional configuration of the ledger server according to the embodiment. [Figure 8] FIG. 8 is an explanatory diagram illustrating an example of a function table according to the embodiment. [Figure 9] FIG. 9 is an explanatory diagram showing an example of a template of a common code in the embodiment. [Figure 10] FIG. 10 is an explanatory diagram illustrating an example of a language table according to the embodiment. [Figure 11] FIG. 11 is an explanatory diagram illustrating an example of a conversion table according to the embodiment. [Figure 12] FIG. 12 is an explanatory diagram illustrating an example of common information according to the embodiment. [Figure 13] FIG. 13 is an explanatory diagram showing a first example of a common code in the embodiment. [Figure 14] FIG. 14 is an explanatory diagram showing a second example of the common code in the embodiment. [Figure 15] FIG. 15 is an explanatory diagram illustrating an example of an address list according to the embodiment. [Figure 16] FIG. 16 is an explanatory diagram showing an example of an image for search in the embodiment. [Figure 17] FIG. 17 is an explanatory diagram showing a first example of an image for displaying search results in the embodiment. [Figure 18] FIG. 18 is an explanatory diagram showing a second example of an image for displaying search results in the embodiment. [Figure 19] FIG. 19 is a flow chart showing the process of the analysis device in the embodiment. [Figure 20] FIG. 20 is a flowchart showing a first example of detailed processing by the analysis device in the embodiment. [Figure 21] FIG. 21 is a flowchart showing a second example of detailed processing by the analysis device in the embodiment. [Figure 22] FIG. 22 is a flowchart showing a third example of detailed processing by the analysis device in the embodiment. [Diagram 23] FIG. 23 is a sequence diagram showing a first example of the processing of the contract management system in the embodiment. [Figure 24] FIG. 24 is a sequence diagram showing a second example of the processing of the contract management system in the embodiment. [Diagram 25] FIG. 25 is an explanatory diagram showing the data structure of a blockchain. [Figure 26] FIG. 26 is an explanatory diagram showing the data structure of the transaction data. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] (Findings on which the present invention is based) The present inventor has found that the following problems arise with the contract-related technology described in the "Background Art" section.

[0011] There is a technology that uses a distributed ledger to manage information related to a contract. Information stored in the distributed ledger is managed so that it is virtually impossible to rewrite. There is also a technology that uses a distributed ledger to execute contract-related processes and manage contracts. Such a technology can be realized, for example, by a smart contract.

[0012] Incidentally, it is conceivable that there are a plurality of contracts that can be concluded in order to achieve the user's objective, and the user may select a contract to conclude from among these contracts.

[0013] For example, there may be a plurality of sellers of an item that a user wishes to purchase. In this case, the user concludes a sales contract with one of the plurality of sellers in order to achieve the purpose of purchasing the item. In other words, the user selects a sales contract to conclude from among the plurality of sales contracts.

[0014] It is also anticipated that contracts will be concluded through smart contract processing using distributed ledger technology.

[0015] 1 is an explanatory diagram showing a typical contract according to the present embodiment. The contract is, for example, a sales contract.

[0016] The user shown in Figure 1 is choosing to enter into a sales contract with either Company A or Company B. The sales contract with Company A and the sales contract with Company B are each realized by contract conclusion processing using a smart contract.

[0017] In a sales contract for goods, generally, the items related to the contract (e.g., the price of the goods, delivery date, quality, shipping fee or handling fee, etc.) may differ from seller to seller. The user compares and considers these items related to the contract, determines the seller that is most convenient for the user, and concludes a sales contract. For example, regarding the price of the goods, a seller that sells the goods at a price within the range that the user considers appropriate is a seller that is most convenient for the user. Also, among multiple sellers, a seller that sells the goods at the lowest price may be the most convenient seller for the user.

[0018] However, the algorithms inside the multiple smart contracts and the contract codes related to the multiple smart contracts are generally different from each other. The algorithms inside the multiple smart contracts are arbitrarily designed, so even if they provide the same function, they may differ from one another. In addition, the contract codes of the multiple smart contracts may be written in different programming languages, and the names of the functions that describe the sales contracts may be different.

[0019] In this case, when a user selects a contract to be concluded from among multiple contracts, it may be difficult to compare the multiple contract codes, and it may be difficult to determine which smart contract to select. If it is difficult for a user to determine which smart contract to select, it may take a long time for the user to make a decision, or the user may end up being unable to make a decision after comparing and considering the contracts and abandoning the task. In such a case, the power consumption of the computer system that realizes the distributed ledger and the computer used by the user may increase, resulting in unnecessary power consumption.

[0020] The present invention provides a control method for suppressing an increase in power consumption of a computer system that manages contracts.

[0021] A control method according to one embodiment of the present invention is a control method that analyzes the binary code of each of a plurality of smart contracts stored in a first distributed ledger, uses the results of the analysis to obtain a plurality of common pieces of information that express information provided by each of the plurality of smart contracts in a common format, generates transaction data including the obtained plurality of common pieces of information, and controls the storage of the generated transaction data in a second distributed ledger.

[0022] According to the above aspect, even if the algorithms inside the multiple smart contracts are different, or the programming languages ​​in which the contract codes of the multiple smart contracts are written are different, the common information obtained by analyzing these is stored in the distributed ledger. The common information is information that indicates the information provided by the smart contract in a common format. If a user browses the common information for each of the multiple smart contracts, the user can easily compare and consider the contents of the contracts, and can easily select the contract to be concluded, i.e., the smart contract. This makes it possible to suppress an increase in power consumption of a computer system that realizes a distributed ledger, and also to suppress the occurrence of unnecessary power consumption. In this way, the above control method can suppress an increase in power consumption of a computer system that manages contracts.

[0023] In addition, the analysis may involve executing functions possessed by each of the multiple smart contracts, and in obtaining the multiple pieces of common information, information provided by the executed functions may be obtained as the multiple pieces of common information.

[0024] According to the above aspect, functions that provide information and that belong to multiple smart contracts are actually executed, and common information is generated using the information obtained by the execution. This makes it easier to generate common information. This makes it easier to suppress an increase in power consumption of a computer system that manages contracts.

[0025] In addition, the analysis may include extracting functions from among the functions of the plurality of smart contracts, the functions having names that are predetermined as names of functions that are relatively likely to provide the information, and executing the extracted functions.

[0026] According to the above aspect, a function that is relatively likely to provide information is extracted from functions of multiple smart contracts, and common information is generated using information obtained by executing the extracted function. Since a function that is relatively likely to provide information is used, the common information is generated more efficiently. This makes it possible to more efficiently suppress an increase in power consumption of a computer system that manages contracts.

[0027] In addition, the analysis may involve obtaining multiple source codes by disassembling binary code of the multiple smart contracts, and the acquisition of the multiple pieces of common information may involve obtaining multiple common codes that express the obtained multiple source codes in a common format as the multiple pieces of common information.

[0028] According to the above aspect, a common code, which is common information, is obtained by using source code obtained by disassembling binary codes of multiple smart contracts. This makes it possible to obtain common information by using binary code that can be easily obtained from a distributed ledger, in other words, without needing the original source code of the smart contract or executing the function of the smart contract. This makes it easier to suppress an increase in power consumption of a computer system that manages contracts.

[0029] In addition, in acquiring the plurality of pieces of common information, the plurality of acquired source codes may be converted according to a predetermined code conversion rule to acquire the plurality of common codes.

[0030] According to the above aspect, the common code is obtained by code conversion from the source code obtained from the binary code obtained from the distributed ledger, so that the common code can be obtained more easily. Therefore, it is possible to more easily suppress the increase in power consumption of the computer system that manages the contract.

[0031] In addition, when generating the transaction data, the transaction data may be generated including the multiple pieces of common information in a format in which an identifier of each of the multiple smart contracts is associated with common information for that smart contract among the multiple pieces of common information.

[0032] According to the above aspect, the shared information of each of a plurality of smart contracts is included in the transaction data and stored in the distributed ledger. This allows the shared information to be managed in a viewable state and in a manner that is substantially unalterable. This makes it possible to appropriately manage the shared information while suppressing an increase in power consumption of the computer system that manages the contracts.

[0033] In addition, when generating the transaction data, transaction data including the multiple common information may be generated for each of the multiple smart contracts in a format in which an identifier of the smart contract is associated with a common code for the smart contract among the multiple common codes.

[0034] According to the above aspect, the shared code of each of a plurality of smart contracts is included in the transaction data and stored in the distributed ledger. This allows the shared code to be managed in a viewable state and substantially unalterable. In addition, smart contracts related to the shared code can be executed on the server that manages the distributed ledger. This makes it possible to appropriately manage the shared information while suppressing an increase in power consumption of the computer system that manages the contracts.

[0035] The control method may further include controlling so that the transaction data stored in the second distributed ledger is read and common information for each of the multiple smart contracts is displayed.

[0036] According to the above aspect, the contents of the transaction data including the shared information stored in the distributed ledger are displayed. This allows the user to view the shared information for each of multiple smart contracts by displaying it on the device, making it easy to compare and consider the contents of the contracts, which can contribute to shortening the time required for using the computer system. This can further reduce the increase in power consumption of the computer system that manages the contracts.

[0037] In addition, each of the multiple smart contracts corresponds to a contract conclusion process, and the control method may further control so that, for each of the multiple smart contracts, a button for executing the contract conclusion process corresponding to that smart contract is further displayed.

[0038] According to the above aspect, a user who has viewed the common information and compared the contents of the contracts can operate the device to execute the contract conclusion process. A user who has determined an appropriate contract can execute the conclusion process of the appropriate contract on the device, which can contribute to shortening the use of the computer system. Therefore, it is possible to further suppress the increase in power consumption of the computer system that manages the contracts.

[0039] In addition, the control method may further control such that, when operation information indicating that an operation has been performed on the button is obtained, the contract conclusion process corresponding to the smart contract associated with the button is executed.

[0040] According to the above aspect, the contract conclusion process is actually executed based on the user's operation to execute the contract conclusion process. This allows the process from the user's operation to the contract conclusion process to be performed automatically, in other words, without human intervention, so that the contract conclusion process can be completed in a shorter time while preventing information tampering. This makes it possible to further suppress an increase in power consumption of the computer system that manages the contracts.

[0041] In addition, an analysis device according to one embodiment of the present invention is an analysis device including an analysis unit that analyzes the binary code of each of a plurality of smart contracts stored in a first distributed ledger, a commonization unit that uses the results of the analysis to acquire a plurality of common information pieces that express information provided by each of the plurality of smart contracts in a common format, and an output unit that generates transaction data including the acquired plurality of common information pieces and controls the storage of the generated transaction data in a second distributed ledger.

[0042] The above aspect provides the same effects as the above control method.

[0043] A program according to one aspect of the present invention is a program for causing a computer to execute the above-described control method.

[0044] The above aspect provides the same effects as the above control method.

[0045] These comprehensive or specific aspects may be realized as a system, an apparatus, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, or may be realized as any combination of a system, an apparatus, an integrated circuit, a computer program, or a recording medium.

[0046] Hereinafter, the embodiment will be specifically described with reference to the drawings.

[0047] The embodiments described below are all comprehensive or specific examples. The numerical values, shapes, materials, components, component arrangement and connection forms, steps, and order of steps shown in the following embodiments are merely examples and are not intended to limit the present invention. Furthermore, among the components in the following embodiments, components that are not described in an independent claim showing a top concept are described as optional components.

[0048] (Embodiment) In this embodiment, a contract management system and a control method thereof that suppress an increase in power consumption of a computer system that manages contracts will be described.

[0049] In this embodiment, as shown in FIG. 1, a case will be described as an example in which a user selects and concludes a contract from among a plurality of contracts (for example, a sales contract with Company A and a sales contract with Company B). Here, a case will be described as an example in which the party with whom the user is attempting to conclude a contract is one of two sellers, Company A and Company B. However, there may be more sellers. There may be more sellers with whom the user is attempting to conclude a contract. The seller may not be a company but an individual.

[0050] In addition, the above multiple contracts are assumed to be executed by processes executed by smart contracts. The contract code of the smart contract describing the processes related to the contract with company A and the contract code of the smart contract describing the processes related to the contract with company B are assumed to be written in different programming languages.

[0051] 2 and 3 are explanatory diagrams showing examples of contract codes in this embodiment.

[0052] The contract code shown in Figure 2 is an example of contract code that describes the process related to the contract with Company A, and is written in the Solidity language. Figure 2 includes a function that sets a value to a variable (setValue function) and a function that reads and outputs the value of the variable (getValue function).

[0053] The contract code shown in Figure 3 is an example of contract code that describes the process related to the contract with Company B, and is written in Go language. Figure 3 includes a function that sets a value to a variable (setValue function) and a function that reads and outputs the value of the variable (getValue function).

[0054] As shown in Figures 2 and 3, the contract code describing the process related to the contract with Company A and the contract code describing the process related to the contract with Company B have different descriptions of the setValue function and the getValue function. In addition, the methods of describing the functions, that is, the wording added before the function name, the presence or absence of a symbol at the end of the sentence, the presence or absence of parentheses, etc., are different. Therefore, even if a user obtains the above two contract codes, they cannot simply compare them, making it difficult to select the contract to be concluded.

[0055] FIG. 4 is a block diagram showing a schematic configuration of the contract management system 1 according to the present embodiment.

[0056] 4, the contract management system 1 includes an analysis device 10 and ledger networks 20, 30, and 40. The analysis device 10 and the ledger networks 20, 30, and 40 are directly or indirectly connected to a network N and can communicate with each other via the network N. In addition, a terminal 50 is connected to the contract management system 1 via the network N.

[0057] Network N may be composed of any communication line or network, and may include, for example, the Internet, a mobile phone carrier network, an Internet provider's access network, or a public access network.

[0058] The analysis device 10 is a device that analyzes multiple smart contracts and outputs common information related to the multiple smart contracts. The multiple smart contracts that are the targets of analysis by the analysis device 10 are a smart contract that processes a contract with company A and a smart contract that processes a contract with company B.

[0059] The ledger network 20 is a P2P network that stores and manages a distributed ledger. The distributed ledger managed by the ledger network 20 stores a smart contract that processes the contract with Company A.

[0060] The ledger network 20 includes ledger servers 20A, 20B, and 20C (also referred to as ledger servers 20A, etc.) as nodes of a P2P network. The ledger servers 20A, etc. will be described in detail later. Note that the number of ledger servers included in the ledger network 20 is not limited to three and may be more than three.

[0061] The ledger network 30 is a P2P network that stores and manages a distributed ledger. The distributed ledger managed by the ledger network 30 stores a smart contract that processes the contract with Company B.

[0062] The ledger network 30 includes ledger servers 30A, 30B, and 30C (also referred to as ledger servers 30A, etc.) as nodes of a P2P network. Ledger servers 30A, etc. will be described in detail later. Note that the number of ledger servers included in the ledger network 30 is not limited to three and may be more than three.

[0063] The ledger network 40 is a P2P network that stores and manages a distributed ledger. The distributed ledger managed by the ledger network 40 stores the shared information output by the analysis device 10.

[0064] The ledger network 40 includes ledger servers 40A, 40B, and 40C (also referred to as ledger server 40A, etc.) as nodes of a P2P network. Ledger servers 40A, etc. will be described in detail later. Note that the number of ledger servers included in the ledger network 40 is not limited to three, and may be more than three.

[0065] The terminal 50 is a terminal device that presents the common information output by the analysis device 10 and accepts an operation by a user related to the selection of a contract. The user can use the terminal 50 to view information on the contracts with both company A and company B. The user can select a seller to conclude a contract with based on the information presented by the terminal 50.

[0066] 5 is a block diagram showing a functional configuration of the ledger server 20A in this embodiment. In the following, the ledger server 20A will be used as a representative of the ledger servers 20A, etc. The ledger servers 20B and 20C also have the same functions as the ledger server 20A.

[0067] As shown in FIG. 5, the ledger server 20A includes a processing unit 21, a ledger storage unit 22, and an execution unit .

[0068] The processing unit 21 is a functional unit that executes processing related to transaction data. The processing unit 21 can be realized by a processor (for example, a central processing unit (CPU)) included in the ledger server 20A executing a program using a memory.

[0069] The processing unit 21 executes a process of acquiring transaction data and storing the acquired transaction data in the distributed ledger.

[0070] When storing new transaction data in the distributed ledger, the processing unit 21 stores the new transaction data in the ledger storage unit 22 in a manner according to the type of distributed ledger. Furthermore, the processing unit 21 transmits and receives communication data to and from the ledger storage units 22 of other ledger servers among the ledger servers 20A, etc., and stores the above transaction data in the ledger storage units 22 of the other ledger servers as well. For example, when the distributed ledger is a blockchain, the processing unit 21 generates a block including new transaction data, and stores the generated block in the ledger storage unit 22 after reaching a consensus among the ledger servers 20A, etc. using a consensus algorithm.

[0071] The transaction data that the processing unit 21 stores in the distributed ledger includes a contract code of a smart contract that processes related to the contract with Company A (also referred to as the “contract code corresponding to the contract with Company A”).

[0072] The ledger storage unit 22 is a storage unit that stores the distributed ledger. The distributed ledger stored in the ledger storage unit 22 stores one or more transaction data, and is managed so that tampering is difficult using characteristics such as hash values ​​(described later). The ledger storage unit 22 stores the transaction data provided by the processing unit 21, including the contract code corresponding to the contract with company A, in the distributed ledger.

[0073] The distributed ledger stores transaction data from the past to the present. Based on the characteristic that information recorded in the distributed ledger is difficult to tamper with, the transaction data is managed to prevent tampering.

[0074] The distributed ledger is, for example, a blockchain, and this case will be described as an example, but other types of distributed ledgers (for example, IOTA or hash graph) can also be adopted. The distributed ledger may or may not execute a consensus algorithm (for example, Practical Byzantine Fault Tolerance (PBFT), Proof of Work (PoW), or Proof of Stake (PoS)) when storing new data. Hyperledger fabric is an example of a distributed ledger technology that does not execute a consensus algorithm.

[0075] The execution unit 23 is a functional unit that executes processing by referring to transaction data stored in the distributed ledger stored in the ledger storage unit 22. The execution unit 23 can be realized by a processor (e.g., a CPU) included in the ledger server 20A executing a program using a memory. The execution unit 23 executes processing by a smart contract in accordance with a contract code included in the transaction data stored in the distributed ledger.

[0076] Specifically, when transaction data including an instruction to execute a smart contract corresponding to the contract with Company A is stored in the distributed ledger, the execution unit 23 executes processing related to the contract using the smart contract in accordance with the instruction.

[0077] Each of the ledger servers 30A, etc. has the same functions as the ledger server 20A. However, in the ledger servers 30A, etc., the transaction data stored in the distributed ledger by the processing unit 21 includes a contract code of a smart contract that processes the contract with Company B (also referred to as a "contract code corresponding to the contract with Company B").

[0078] FIG. 6 is a block diagram showing the functional configuration of the analysis device 10 according to the present embodiment.

[0079] 6, the analysis device 10 includes an analysis unit 11, a common unit 12, and an output unit 13. The analysis device 10 may further include a server function unit 15.

[0080] Each functional unit of the analysis device 10 is realized by a processor (eg, a CPU) included in the analysis device 10 executing a program using a memory.

[0081] The analysis unit 11 is a functional unit that analyzes the binary code of each of a plurality of smart contracts stored in a distributed ledger (corresponding to a first distributed ledger). The plurality of smart contracts include smart contracts stored in the ledger storage unit 22 of the ledger server 20A, which is an example of the first distributed ledger, and smart contracts stored in the ledger storage unit 22 of the ledger server 30A, which is an example of the first distributed ledger. The analysis of the binary code can be performed by executing a function of each smart contract, or by using source code obtained by disassembling the binary code. Details will be described later.

[0082] The commonization unit 12 is a functional unit that acquires a plurality of common information pieces that express information provided by each of a plurality of smart contracts in a common format using the results of the analysis by the analysis unit 11. The plurality of common information pieces are information pieces that indicate information provided by a plurality of smart contracts in a predetermined common format, and may be, for example, a format that indicates the information as a list (also called a list format) or a format that indicates the information as a contract code including the information (also called a code format). The information provided by the smart contract is information that the execution unit 23 outputs by executing processing by the smart contract. Details will be described later.

[0083] The output unit 13 is a functional unit that outputs the multiple pieces of common information acquired by the sharing unit 12. Specifically, the output unit 13 generates transaction data including the multiple pieces of common information acquired by the sharing unit 12, and transmits the generated transaction data to a distributed ledger (also called a second distributed ledger) held by the ledger server 40A, etc. By transmitting the transaction data in this manner, the output unit 13 controls the storage of the transaction data in the distributed ledger.

[0084] The server function unit 15 is a function unit having the function of a ledger server. The server function unit 15 has the function of ledger server 20A etc., 30A etc., 40A etc. When the server function unit 15 has the function of ledger server 20A, the analysis device 10 can participate in the ledger network 20 and become one node of the P2P network which is the ledger network 20. The same applies to the ledger servers 30A etc. and 40A etc. The server function unit 15 may have the function of multiple ledger servers at the same time. Also, the server function unit 15 is not a required component.

[0085] More specifically, the analysis unit 11 and the common unit 12 can operate as follows.

[0086] As an example of analysis, the analysis unit 11 may execute a function possessed by each of a plurality of smart contracts. In this case, the commonization unit 12 acquires information provided by the executed functions as a plurality of common information. Here, the analysis unit 11 may extract a function having a name that is predetermined as a name of a function that is relatively likely to provide information from among the functions possessed by the plurality of smart contracts, and execute the extracted function. The above function is also called a providing function.

[0087] To execute the provisioning function, it is necessary to generate transaction data including an instruction to execute the provisioning function, and to transmit the generated transaction data to the distributed ledger in which the smart contract is stored for storage.

[0088] Furthermore, as an example of analysis, the analysis unit 11 may obtain multiple source codes by disassembling binary codes of multiple smart contracts. In this case, the commonization unit 12 obtains multiple common codes that express the obtained multiple source codes in a common format as multiple pieces of common information. Here, the commonization unit 12 may obtain the multiple common codes by converting the multiple source codes obtained by the analysis unit 11 according to a predetermined conversion rule.

[0089] More specifically, the output unit 13 can operate as follows.

[0090] As an example of generating transaction data, the output unit 13 may generate transaction data including multiple pieces of common information in a format in which, for each of multiple smart contracts, an identifier of the smart contract is associated with common information for the smart contract among the multiple pieces of common information.

[0091] In addition, as an example of generating transaction data, the output unit 13 may generate transaction data including multiple common information for each of multiple smart contracts in a format in which an identifier of the smart contract is associated with a common code for the smart contract among the multiple common codes.

[0092] Furthermore, the output unit 13 can control the display of various information on the terminal 50 by providing the terminal 50 with display control information generated by the ledger server 40A.

[0093] For example, the output unit 13 can perform control so that transaction data stored in a distributed ledger held by the ledger server 40A is read out and common information for each of the multiple smart contracts is displayed on the terminal 50. In other words, the ledger server 40A (display control unit 44) reads out the transaction data stored in the ledger storage unit 42 and transmits display control information for displaying common information for each of the multiple smart contracts to the terminal 50. The terminal 50 receives the display control information and displays the common information based on the received control information.

[0094] Furthermore, the output unit 13 can perform control so that, for each of the multiple smart contracts, a button for executing a process for concluding a contract corresponding to the smart contract (also referred to as a contract concluding process) is further displayed on the terminal 50. In other words, the ledger server 40A (display control unit 44) transmits display control information for displaying the above button to the terminal 50. The terminal 50 receives the display control information and displays the above button based on the received display control information. At this time, it is assumed that each of the multiple smart contracts corresponds to the contract concluding process.

[0095] In addition, when the terminal 50 acquires operation information indicating that an operation has been performed on the above button, the output unit 13 can control the execution of a contract conclusion process corresponding to the smart contract associated with the above button.

[0096] 7 is a block diagram showing a functional configuration of ledger server 40A in this embodiment. In the following, description will be given using ledger server 40A as a representative of ledger server 40A etc. Ledger servers 40B and 40C also have the same functions as ledger server 40A.

[0097] As shown in FIG. 7, the ledger server 40A includes a processing unit 41, a ledger storage unit 42, an execution unit 43, and a display control unit 44.

[0098] The processing unit 41 is a functional unit that executes processing related to transaction data, and is similar to the processing unit 21 of the ledger server 20A etc. The processing unit 41 can be realized by a processor (e.g., a CPU) included in the ledger server 40A executing a program using a memory.

[0099] The processing unit 41 executes a process of acquiring transaction data and storing the acquired transaction data in the distributed ledger. When storing new transaction data in the distributed ledger, the processing unit 41 stores the new transaction data in the ledger storage unit 42 in a method according to the type of the distributed ledger. The processing unit 41 also transmits and receives communication data to and from ledger storage units 42 provided in other ledger servers among the ledger servers 20A, etc., and causes the above transaction data to be stored in the ledger storage units 42 provided in the other ledger servers as well.

[0100] The transaction data that the processing unit 41 stores in the distributed ledger includes common information expressed in a list format or code format.

[0101] The ledger storage unit 42 is a storage unit that stores the distributed ledger, and is similar to the ledger storage unit 22 of the ledger server 20A, etc. The distributed ledger stored in the ledger storage unit 42 stores transaction data including common information expressed in a list format or code format.

[0102] The execution unit 43 is a functional unit that executes processing by referring to transaction data stored in the distributed ledger stored in the ledger storage unit 42, and is similar to the execution unit 23 of the ledger server 20A, etc. The execution unit 43 can be realized by a processor (e.g., a CPU) included in the ledger server 40A executing a program using a memory. Here, the execution unit 43 executes processing according to the code of a smart contract included in the transaction data stored in the distributed ledger.

[0103] Specifically, when transaction data including an instruction to execute a process related to a contract with company A is stored in the distributed ledger, the execution unit 43 executes the process related to the contract according to the instruction. Also, when transaction data including an instruction to execute a process related to a contract with company B is stored in the distributed ledger, the execution unit 43 executes the process related to the contract according to the instruction.

[0104] The display control unit 44 is a functional unit that performs control for displaying the common information. When the display control unit 44 receives request information for displaying the common information from the terminal 50, the display control unit 44 transmits control information for displaying the common information to the terminal 50 in response to the received request information. The control information includes, for example, information in which an image for displaying the common information is described in HTML (HyperText Markup Language). When the terminal 50 receives the control information, the terminal 50 displays an image configured by the received control information on a display screen of the terminal 50. Note that the display control unit 44 may transmit, in advance, to the terminal 50 display control information for displaying an image for receiving input of search conditions from the user.

[0105] The following describes the information used to analyze smart contracts and generate shared information.

[0106] FIG. 8 is an explanatory diagram showing an example of a function table in this embodiment.

[0107] The function table shown in FIG. 8 is referred to when the analysis unit 11 executes the provided functions of the smart contract.

[0108] The function table indicates, for each piece of information provided by the smart contract, the name of the providing function that outputs that information.

[0109] For example, getValue, getPrice, getReward, and getFee are shown as names of functions that provide a price, and getTime and getDate are shown as names of functions that provide a delivery date.

[0110] The name of the provided function shown in the function table may be linked to the smart contract as the name of the function that provides the information. In this case, the analysis unit 11 executes the provided function of the smart contract using the name of the provided function shown in the function table.

[0111] The names of the provided functions shown in the function table may be names that are generally determined in advance as names of functions that are relatively likely to provide the information. In this case, the analysis unit 11 extracts functions that have the names of the provided functions as part or whole from among the functions published as the functions of the smart contract, and treats the extracted functions as provided functions to execute the provided functions of the smart contract.

[0112] FIG. 9 is an explanatory diagram showing an example of a template of a common code in this embodiment.

[0113] The template of the common code shown in FIG. 9 is used when the common unit 12 generates a common code.

[0114] The template of the common code shown in FIG. 9 is a template that can generate a contract code written in a specific programming language by filling in the blanks.

[0115] Specifically, in Fig. 9, the character string indicating the name of the smart contract is expressed as "Contract%%%", which includes a blank "%%%". Also, the variable name is expressed as a blank "$$$".

[0116] The commonization unit 12 replaces the blank "%%%" with an identifier that can uniquely identify the common code. For example, in a contract code corresponding to the result of analyzing the contract code of the contract conclusion process with company A, the blank "%%%" may be set to "A1." Similarly, in a contract code corresponding to the result of analyzing the contract code of the contract conclusion process with company B, the blank "%%%" may be set to "B1."

[0117] The common unit 12 replaces the blanks “$$$” with the price information obtained as a result of the analysis by the analysis unit 11.

[0118] In this manner, the common unit 12 generates a common code.

[0119] FIG. 10 is an explanatory diagram showing an example of a language table in the present embodiment.

[0120] The language table shown in FIG. 10 is referred to when the common unit 12 disassembles the binary code of the smart contract.

[0121] The language table lists, for each ledger network, the programming language of the contract code used in that ledger network.

[0122] For example, it is shown that the programming language of the contract code used in the ledger network 20 is the Solidity language. Also, it is shown that the programming language of the contract code used in the ledger network 30 is the Go language.

[0123] The standardization unit 12 refers to the language table to determine the programming language of the contract code, and executes disassembly in a method according to the programming language.

[0124] FIG. 11 is an explanatory diagram showing an example of a conversion table in the present embodiment.

[0125] The conversion table shown in FIG. 11 is used when the commonization unit 12 converts the source code obtained by the disassembly of the binary code by the analysis unit 11 into a common code.

[0126] FIG. 11 shows the correspondence between the Solidity language code and the Go language code.

[0127] For example, "Contract ###{}" in Solidity maps to "package ###" in Go, where "###" is a metacharacter that represents any string.

[0128] The commonization unit 12 can convert between the Solidity language and the Go language by using this correspondence relationship. That is, when the language of the common code is the Solidity language, the commonization unit 12 can obtain the common code by converting the contract code written in the Go language into the Solidity language.

[0129] FIG. 12 is an explanatory diagram showing an example of common information in the present embodiment.

[0130] The shared information shown in FIG. 12 indicates shared information in a list format acquired by the sharing unit 12.

[0131] The shared information lists, for each seller, the price as a parameter related to the contract with that seller, and the address of the smart contract corresponding to the contract with that seller.

[0132] Specifically, Figure 12 shows that Company A and Company B are sellers, and that the amounts to be paid to the other party under the contracts with Company A and Company B are 100 yen and 110 yen, respectively. Also, the addresses of the smart contracts corresponding to each contract are shown.

[0133] The common code will be described with reference to Fig. 13 and Fig. 14. Here, a case where a code written in the Solidity language is adopted will be described as an example of the common code. The common code shown here is a common code generated by the commonization unit 12 so as to output information acquired by using a provided function, or a common code generated by converting a source code obtained by disassembly.

[0134] FIG. 13 is an explanatory diagram showing a first example of a common code in this embodiment.

[0135] The common code C3 shown in FIG. 13 is a common code for processing related to the contract with Company A.

[0136] The common code C3 is a common code representation of the contract code C1 of the process related to the contract with Company A shown in FIG.

[0137] The common code C3 differs from the contract code C1 for the process related to the contract with Company A shown in Figure 2 in that the name of the contract is "ContractA1." In other respects, it is the same as the contract code C1 for the process related to the contract with Company A shown in Figure 2.

[0138] Since the contract code C1 is written in the Solidity language, the common code C3, which is also written in the Solidity language, is the same as the contract code C1.

[0139] FIG. 14 is an explanatory diagram showing a second example of the common code in this embodiment.

[0140] The common code C4 shown in FIG.

[0141] The common code C4 is a common code representation of the contract code C2 of the process related to the contract with Company B shown in FIG.

[0142] The common code C4 describes substantially the same algorithm as the contract code C2, but is different from the contract code C2. Since the contract code C2 is written in the Go language, the common code C4 written in the Solidity language is different from the contract code C2.

[0143] FIG. 15 is an explanatory diagram showing an example of an address list in this embodiment.

[0144] The address list shown in Fig. 15 is a list showing addresses of smart contracts corresponding to common codes. When the common code is generated by the commonization unit 12 and stored in the distributed ledger, the address list shows addresses of smart contracts corresponding to the common code. The address list is included in the transaction data stored in the ledger storage unit 42.

[0145] Figure 15 shows the address of the smart contract corresponding to the common code indicating the contract with Company A and Company B.

[0146] When the execution unit 43 receives transaction data including an instruction to execute a smart contract for processing related to the contract from the terminal 50, it searches the address list for the contracting seller based on the received transaction data. Then, it transfers the contract transaction data to the address of the seller obtained by the search.

[0147] FIG. 16 is an explanatory diagram showing an image 51 which is an example of an image for search in this embodiment.

[0148] The image 51 is an image that is generated and displayed by the terminal 50 based on the display control information generated by the display control unit 44. The image 51 is an image that accepts conditions regarding matters related to the contract, in other words, conditions for searching for an appropriate seller.

[0149] The image 51 includes a field 52 for receiving input of the terms of the contract, specifically, the name, price, and delivery date of the item, from the user. The user can input the terms of the contract in the field 52.

[0150] The image 51 also includes a button 53 for executing a search based on the conditions entered by the user and obtaining the results. When the button 53 is operated, the terminal 50 generates request data including the information entered in the field 52 at the time of the operation as a search condition, and transmits the request data to the ledger server 40A. When the ledger server 40A receives the request data, it executes a search process on the transaction data stored in the distributed ledger based on the search conditions indicated in the received request data, and obtains sellers who satisfy the search conditions and information indicating the conditions of the sale. The ledger server 40A transmits display control information for displaying the sellers and the conditions of the sale to the terminal 50.

[0151] FIG. 17 is an explanatory diagram showing an image 61 which is a first example of an image for displaying search results in this embodiment.

[0152] Image 61 is an example of an image displayed by terminal 50 when search button 53 is operated on image 51 shown in FIG. 16, that is, image 51 in a state where "ABC" has been input as the name.

[0153] An image 61 displays information showing the results of a search for an item named "ABC" as common information.

[0154] In the image 61, a field 62 showing the seller and a field 63 showing the price are shown. In addition, for each seller, a button 64 for concluding a contract with the seller is displayed.

[0155] It is assumed that the user visually checks the image 61, decides whether to conclude a sales contract for the purchase of the goods with company A or company B (i.e., whether to purchase the goods from company A or company B), and operates the contract button 64 associated with the determined seller. When the contract button 64 is operated, the terminal 50 generates transaction data including an instruction to execute a smart contract related to the contract with the seller corresponding to the operated button 64, and transmits the transaction data to the ledger server 40A.

[0156] The search results may be displayed using a common code as common information.

[0157] FIG. 18 is an explanatory diagram showing an image 71 which is a first example of an image for displaying search results in this embodiment.

[0158] An image 71 displays information indicating the result of a search for an item as a common code.

[0159] In the image 71, a field 72 showing the seller and a field 73 showing the common code are shown. In addition, for each seller, a button 74 for concluding a contract with the seller is displayed.

[0160] It is assumed that the user visually checks image 71 to confirm the common code, decides whether to conclude a sales contract for the purchase of the goods with company A or company B, and operates contract button 74 associated with the determined seller. The processing when contract button 74 is operated is the same as that described in FIG.

[0161] The processing of the analysis device 10 configured as above will now be described.

[0162] FIG. 19 is a flow diagram showing the processing of the analysis device 10 in this embodiment.

[0163] As shown in FIG. 19, in step S1, the analysis unit 11 analyzes the binary code of each of the multiple smart contracts stored in the distributed ledger.

[0164] In step S2, the common unit 12 uses the results of the analysis in step S1 to obtain a plurality of common pieces of information in which the information provided by each of the plurality of smart contracts is expressed in a common format.

[0165] In step S3, the output unit 13 generates transaction data including the multiple pieces of common information acquired in step S2, and controls to store the generated transaction data in a distributed ledger (corresponding to a second distributed ledger). The distributed ledger in which the transaction data is stored may be, for example, the distributed ledger of the ledger server 40A, or it may be the distributed ledger of the ledger servers 20A and 30A.

[0166] Through the series of processes shown in FIG. 19, the analysis device 10 suppresses an increase in power consumption of the computer system that manages the contract.

[0167] The process shown in FIG. 19 will be described in more detail below.

[0168] FIG. 20 is a flow diagram showing a first example of detailed processing by the analysis device 10 in this embodiment.

[0169] As shown in FIG. 20, in step S11, the analysis unit 11 acquires a provided function included in the smart contract.

[0170] In step S12, the analysis unit 11 generates transaction data including an instruction to execute the provision function acquired in step S11, and transmits the generated transaction data to the ledger server in which the smart contract is stored (i.e., the ledger servers 20A and 30A). The ledger server that receives the transaction data stores the received transaction data in the distributed ledger and executes the provision function. The ledger server transmits information indicating the execution result of the provision function (also simply referred to as the execution result) to the analysis device 10.

[0171] In step S13, the analysis unit 11 acquires the execution result transmitted by the ledger server in step S12.

[0172] In step S14, the common unit 12 holds the execution result acquired in step S13 as common information.

[0173] In step S15, the output unit 13 generates transaction data including the multiple pieces of common information acquired in step S2, and stores the generated transaction data in the distributed ledger (corresponding to the second distributed ledger) of the ledger server 40A.

[0174] 19. Steps S11 to S13 correspond to step S1 in FIG. 19, step S14 corresponds to step S2 in FIG. 19, and step S15 corresponds to step S3 in FIG.

[0175] Through the series of processes shown in FIG. 20, the analysis device 10 suppresses an increase in power consumption of the computer system that manages the contract.

[0176] FIG. 21 is a flow diagram showing a second example of detailed processing by the analysis device 10 in this embodiment.

[0177] Steps S11 to S13 and S15 shown in FIG. 21 are the same as the steps of the same names shown in FIG.

[0178] In step S21, the sharing unit 12 generates a sharing code, which is a contract code for outputting the execution result acquired in step S13.

[0179] In step S22, the sharing unit 12 holds the shared code acquired in step S21 as shared information.

[0180] It should be noted that steps S21 and S22 correspond to step S2 in FIG.

[0181] Through the series of processes shown in FIG. 21, the analysis device 10 suppresses an increase in power consumption of the computer system that manages the contract.

[0182] FIG. 22 is a flow diagram showing a third example of detailed processing by the analysis device 10 in this embodiment.

[0183] In step S31, the analysis unit 11 acquires the binary code of the smart contract.

[0184] In step S32, the analysis unit 11 disassembles the binary code acquired in step S31 to acquire source code.

[0185] In step S33, the commonization unit 12 converts the source code acquired in step S32 into a common code.

[0186] In step S34, the sharing unit 12 holds the shared code acquired in step S33 as shared information.

[0187] In step S35, the output unit 13 generates transaction data including the multiple pieces of common information acquired in step S34, and stores the generated transaction data in the distributed ledger (corresponding to the second distributed ledger) of the ledger server 40A.

[0188] 19. Steps S31 and S32 correspond to step S1 in FIG. 19, steps S33 and S34 correspond to step S2 in FIG. 19, and step S35 corresponds to step S3 in FIG.

[0189] Through the series of processes shown in FIG. 22, the analysis device 10 suppresses an increase in power consumption of the computer system that manages the contract.

[0190] Next, the processing of the contract management system 1 including the analysis device 10 will be described.

[0191] Fig. 23 is a sequence diagram showing a first example of processing of the contract management system 1 in this embodiment. The sequence diagram shown in Fig. 23 shows processing when the ledger server 40A stores common information in a code format (i.e., a common code) in the distributed ledger.

[0192] The processing steps already described are denoted by the same reference numerals, and detailed description thereof will be omitted.

[0193] In steps S1 to S3, the analysis device 10 performs control to analyze the binary code, obtain the common information, and store the transaction data in the distributed ledger of the ledger server 40A. The control to store the transaction data in the distributed ledger of the ledger server 40A includes transmitting the transaction data to the ledger server 40A.

[0194] In step S101, the ledger server 40A receives the transaction data sent in step S3 and stores it in the distributed ledger.

[0195] It is assumed that the terminal 50 then transmits a request to acquire the common information to the ledger server 40A. At this time, the ledger server 40A may transmit display control information for displaying information for searching for sellers to the terminal 50 in advance, and the terminal 50 may display the information for searching for sellers based on the display control information. In this case, the transmission of the request by the terminal 50 may be performed based on the user visually checking the displayed information and inputting it to the terminal 50.

[0196] In step S102, upon receiving the request from the terminal 50, the ledger server 40A generates display control information and transmits the generated display control information to the terminal 50.

[0197] In step S103, the terminal 50 receives the display control information transmitted in step S102, and displays the common information based on the received display control information. The terminal 50 also accepts an operation on the displayed common information. The operation on the displayed common information is, for example, an operation on a contract button associated with a contract shown in the displayed common information.

[0198] In step S104, based on the operation received in step S103, the terminal 50 transmits to the ledger server 40A contract transaction data for executing a contract conclusion process for concluding a contract related to the operation.

[0199] In step S105, the ledger server 40A receives the contract transaction data sent in step S104, and stores the received contract transaction data in the distributed ledger.

[0200] In step S106, the ledger server 40A executes the contract conclusion process based on the contract transaction data stored in the distributed ledger in step S105.

[0201] Fig. 24 is a sequence diagram showing a first example of processing of the contract management system 1 in this embodiment. The sequence diagram shown in Fig. 24 shows processing when the ledger servers 20A and 30A store the shared information in list format in the distributed ledger.

[0202] In Fig. 24, the processes enclosed by dashed lines are different from those in Fig. 23. The following mainly describes the processes that are different from those in Fig. 23. Note that the same reference numerals are used for the process steps that have already been described, and detailed descriptions thereof will be omitted.

[0203] In steps S1 to S3, the analysis device 10 performs control to analyze the binary code, obtain the common information, and store the transaction data in the distributed ledgers of the ledger servers 20A and 30A. The control to store the transaction data in the distributed ledgers of the ledger servers 20A and 30A includes transmitting the transaction data to the ledger servers 20A and 30A.

[0204] In step S200A, the ledger server 20A receives the transaction data sent in step S3 and stores it in the distributed ledger.

[0205] In step S200B, the ledger server 20B receives the transaction data sent in step S3 and stores it in the distributed ledger.

[0206] In step S201, the output unit 13 of the analysis device 10 controls to store transaction data for executing an additional function (also referred to as additional transaction data) in the distributed ledger of the ledger server 40A. The control to store the additional transaction data in the distributed ledger of the ledger server 40A includes transmitting the additional transaction data to the ledger server 40A. The additional transaction data includes an instruction to add the addresses of the smart contracts stored in each of the ledger servers 20A and 30A to the address lists.

[0207] In step S202, the ledger server 40A receives the additional transaction data sent in step S201 and stores it in the distributed ledger.

[0208] In step S203, the ledger server 40A adds the addresses of the smart contracts stored in each of the ledger servers 20A and 30A to the address list based on the storage of the additional transaction data in the distributed ledger in step S202.

[0209] In step S211, the ledger server 40A receives the contract transaction data sent in step S104. The ledger server 40A refers to the address list to search for a ledger server that stores a smart contract related to the contract conclusion process with the contracting seller. If the contracting seller is B, the above search results in the address of the smart contract in the ledger server 30A. The ledger server 40A transfers the received contract transaction data to the address obtained by the search.

[0210] In step S212, the ledger server 30A receives the contract transaction data sent in step S211, and stores the received contract transaction data in the distributed ledger.

[0211] In step S213, the ledger server 30A executes a contract conclusion process by executing a smart contract related to the contract based on the contract transaction data stored in the distributed ledger in step S212.

[0212] (supplement) The blockchain in each of the above embodiments or modifications will now be described in a supplementary manner.

[0213] FIG. 25 is an explanatory diagram showing the data structure of a blockchain.

[0214] A blockchain is a set of blocks, which are units of recording, connected in a chain. Each block contains multiple transaction data and the hash value of the immediately preceding block. Specifically, block B2 contains the hash value of the previous block B1. A hash value calculated from the multiple transaction data contained in block B2 and the hash value of block B1 is included in block B3 as the hash value of block B2. In this way, by connecting blocks in a chain while including the contents of the previous block as a hash value, tampering with the recorded transaction data is effectively prevented.

[0215] If past transaction data is changed, the hash value of the block will be different from the value before the change, and in order to make the altered block appear correct, all blocks after it would have to be recreated, which is practically very difficult. This property is used to ensure that the blockchain is tamper-resistant.

[0216] FIG. 26 is an explanatory diagram showing the data structure of the transaction data.

[0217] 26 includes a transaction body P1 and a digital signature P2. The transaction body P1 is the data body included in the transaction data. The digital 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, more specifically, by encrypting it with the private key of the creator.

[0218] The transaction data has the digital signature P2, making it virtually impossible to tamper with. This prevents tampering with the transaction body.

[0219] In the above-described embodiments, each component may be configured with dedicated hardware, or may be realized by executing a software program suitable for each component. Each component may be realized by a program execution unit such as a CPU or processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory. Here, the software for realizing the content management system of the above-described embodiments is a program such as the following.

[0220] In other words, this program is a program that causes a computer to execute a control method in a contract management system having a plurality of devices each holding a distributed ledger, the control method being executed by one of the plurality of devices, the control method comprising: acquiring first transaction data including a first variable indicating first information regarding a first contract between a first user and a second user, and a second variable indicating second information different from the first information regarding the first contract, the second variable being set to a predetermined value indicating that the second information is undecided; storing the acquired first transaction data in the distributed ledger; executing a storage process of reading out the second variable included in the first transaction data stored in the distributed ledger and storing it in a rewritable memory unit of the one device; acquiring second transaction data including a third variable indicating third information regarding a second contract between the first user and a third user and a change instruction to change the second variable based on the third variable; storing the acquired second transaction data in the distributed ledger; and, after storing the second transaction data in the distributed ledger, executing a change process to change the second variable stored in the memory unit from the predetermined value in accordance with the change instruction.

[0221] Although the contract management system according to one or more aspects has been described based on the embodiment, the present invention is not limited to this embodiment. As long as it does not deviate from the spirit of the present invention, various modifications conceived by a person skilled in the art to this embodiment and forms constructed by combining components of different embodiments may also be included within the scope of one or more aspects. [Industrial Applicability]

[0222] The present invention can be used in a contract management system for managing contracts. [Explanation of symbols]

[0223] 1. Contract Management System 10 Analyzer 11 Analysis Department 12 Commonization section 13 Output section 15 Server Function Unit 20, 30, 40 Ledger Network 20A, 20B, 20C, 30A, 30B, 30C, 40A, 40B, 40C Ledger Server 21, 41 Processing section 22, 42 Ledger memory section 23, 43 Executive Department 44 Display control section 50 terminals 51, 61, 71 Images Columns 52, 62, 63, 72, and 73 53, 64, 74 buttons B0, B1, B2, B3 blocks C1, C2 contract code C3, C4 common code N Network P1 Transaction Body P2 electronic signature

Claims

1. A method for controlling a computer system, comprising: The computer system includes: Analyzing the binary code of each of the multiple smart contracts stored in the first distributed ledger; Using the results of the analysis, obtain a plurality of pieces of common information that express the information provided by each of the plurality of smart contracts in a common format; generating transaction data including the acquired plurality of pieces of common information, and controlling storage of the generated transaction data in a second distributed ledger; In the above analysis, disassembling the binary code of the smart contracts to obtain source code; In acquiring the plurality of pieces of common information, acquiring a plurality of common codes, which are obtained by expressing the acquired plurality of source codes in a common format, as the plurality of common information; In generating the transaction data, Generate transaction data including the plurality of pieces of common information in a format in which, for each of the plurality of smart contracts, an identifier of the smart contract is associated with a common code for the smart contract among the plurality of common codes. Control methods.

2. In the above analysis, Executing a function possessed by each of the plurality of smart contracts; In acquiring the plurality of pieces of common information, The information provided by the executed function is acquired as the plurality of pieces of common information. The control method according to claim 1 .

3. In the above analysis, Extracting a function having a name that is predetermined as a name of a function that is relatively likely to provide the information from among the functions of the plurality of smart contracts, and executing the extracted function. The control method according to claim 2 .

4. In acquiring the plurality of pieces of common information, The plurality of acquired source codes are converted according to a predetermined code conversion rule to obtain the plurality of common codes. The control method according to claim 1 .

5. In generating the transaction data, Generate the transaction data including the plurality of pieces of common information in a format in which, for each of the plurality of smart contracts, an identifier of the smart contract is associated with common information for the smart contract among the plurality of pieces of common information. The control method according to any one of claims 1 to 4.

6. The control method further comprises: The transaction data stored in the second distributed ledger is read; Controlling so that common information for each of the plurality of smart contracts is displayed. The control method according to claim 5.

7. Each of the plurality of smart contracts corresponds to a contract execution process; The control method further comprises: Control is performed so that, for each of the plurality of smart contracts, a button for executing a contract conclusion process corresponding to the smart contract is further displayed. The control method according to claim 6.

8. The control method further comprises: When operation information indicating that an operation has been performed on the button is acquired, control is performed so that the contract conclusion process corresponding to the smart contract associated with the button is executed. The control method according to claim 7.

9. an analysis unit that analyzes binary code of each of the plurality of smart contracts stored in the first distributed ledger; A commonization unit that uses a result of the analysis to acquire a plurality of common information pieces that express information provided by each of the plurality of smart contracts in a common format; an output unit that generates transaction data including the acquired plurality of pieces of common information and controls storage of the generated transaction data in a second distributed ledger; In the above analysis, disassembling the binary code of the smart contracts to obtain source code; In acquiring the plurality of pieces of common information, acquiring a plurality of common codes, which are obtained by expressing the acquired plurality of source codes in a common format, as the plurality of common information; In generating the transaction data, Generate transaction data including the plurality of pieces of common information in a format in which, for each of the plurality of smart contracts, an identifier of the smart contract is associated with a common code for the smart contract among the plurality of common codes. Analyzer.

10. A program for causing a computer to execute the control method according to any one of claims 1 to 8.

Images