Information processing method, device, and program

Abstract

This information processing method comprises: (S2) acquiring a smart contract; (S3) analyzing the smart contract to identify one or more subcontracts constituting the smart contract; (S4, S5) identifying, for each of the one or more subcontracts, a version of a compiler that compiled the subcontract, and blockchain identification information that identifies a blockchain in which the subcontract is stored; (S6) generating a first list including, for each of the one or more subcontracts, subcontract identification information that identifies the subcontract, the compiler version identified for the subcontract, and the blockchain identification information identified for the subcontract; and (S8) transmitting, in order to store the first list in the blockchain, the first list to a blockchain system (300) managing the blockchain.

Description

Information processing method, device, and program

[0001] The present disclosure relates to an information processing method, an apparatus, and a program.

[0002] In recent years, with the advancement of blockchain technology, smart contracts have been utilized in various fields. Smart contracts enable the automatic execution of contracts and transactions using program code placed on the blockchain, and have the advantage of realizing trustless processing without the need for a central administrator.

[0003] Patent Document 1 proposes a technology that combines encryption technology and access control to ensure the security and privacy of smart contracts.

[0004] JP 2023-168952 A

[0005] The present disclosure provides an information processing method and the like that makes it easier to manage and track smart contract configurations and improve traceability and maintainability.

[0006] An information processing method according to one aspect of the present disclosure is an information processing method executed by at least a first device, which acquires a smart contract, analyzes the smart contract to identify one or more subcontracts that make up the smart contract, identifies, for each of the one or more subcontracts, the version of the compiler that compiled the subcontract and blockchain identification information that identifies the blockchain in which the subcontract is stored, generates a first list that includes, for each of the one or more subcontracts, the subcontract identification information that identifies the subcontract, the compiler version identified for the subcontract, and the blockchain identification information identified for the subcontract, and transmits the first list to a blockchain system that manages the blockchain to store it in the blockchain.

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

[0008] According to the information processing method and the like disclosed herein, it becomes easier to manage and track the configuration of smart contracts, thereby improving traceability and maintainability.

[0009] FIG. 1 is a schematic diagram showing the configuration of a system according to an embodiment. FIG. 2 is a diagram showing an example of the configuration of a user terminal according to an embodiment. FIG. 3 is a diagram showing an example of the configuration of a management device according to an embodiment. FIG. 4 is a diagram showing an example of the configuration of a node according to an embodiment. FIG. 5 is a diagram showing an example of the configuration of a server according to an embodiment. FIG. 6 is a sequence diagram showing an example of the operation of a system according to an embodiment. FIG. 7 is a diagram showing an example of a first list of one or more subcontracts constituting a smart contract according to an embodiment. FIG. 8 is a sequence diagram showing an example of an operation in which vulnerability testing and deployment control of a smart contract are performed in a system according to an embodiment. FIG. 9 is a diagram showing an example of a second list of one or more other smart contracts that use a smart contract according to an embodiment. FIG. 10 is a sequence diagram showing an example of an operation in which vulnerability testing of a smart contract is performed in a system according to an embodiment. FIG. 11 is a sequence diagram showing an example of processing when a vulnerability is discovered according to an embodiment. FIG. 12 is an explanatory diagram showing the data structure of a blockchain. FIG. 13 is an explanatory diagram showing the data structure of transaction data. FIG. 14 is an explanatory diagram showing transaction data related to the execution of a smart contract. FIG. 15 is an explanatory diagram showing processing related to the execution of a smart contract. FIG. 16 is an explanatory diagram showing the structure of an NFT and metadata.

[0010] (Findings that formed the basis of this disclosure) In recent years, there has been an increase in the number of cases in which services and systems are built by combining multiple smart contracts in blockchain systems, and if a vulnerability exists in one smart contract or compiler, it is more likely to have a wider impact than expected. Under these circumstances, there is a need for a mechanism to systematically visualize, manage, and track the dependencies of subcontracts that make up a smart contract, the compiler used, and the deployment status on the blockchain.

[0011] However, currently, users or developers are forced to individually manage the dependencies of subcontracts that make up a smart contract, the compiler used, and the deployment status on the blockchain, and sufficient measures are not in place.To discover risks such as vulnerabilities or license violations in smart contracts and take measures against them, cross-system management is required.

[0012] Based on this background, the present disclosure provides an information processing method and the like that makes it easier to manage and track the configuration of smart contracts, thereby improving traceability and maintainability.

[0013] An information processing method according to a first aspect of the present disclosure is an information processing method executed by at least a first device, which acquires a smart contract, analyzes the smart contract to identify one or more subcontracts that make up the smart contract, identifies, for each of the one or more subcontracts, the version of the compiler that compiled the subcontract and blockchain identification information that identifies the blockchain in which the subcontract is stored, generates a first list that includes, for each of the one or more subcontracts, the subcontract identification information that identifies the subcontract, the compiler version identified for the subcontract, and the blockchain identification information identified for the subcontract, and transmits the first list to a blockchain system that manages the blockchain to store it in the blockchain.

[0014] This makes it possible to obtain the identification information, compiler version, and blockchain identification information of each subcontract that makes up a smart contract and record them on the blockchain, making it easier to manage and track the configuration of smart contracts and improving traceability and maintainability.

[0015] An information processing method according to a second aspect of the present disclosure is the information processing method according to the first aspect, in which the identification includes identifying the one or more subcontracts by comparing a contract code included in the smart contract with a public code that is publicly available.

[0016] This allows the origin and similarity of subcontracts to be identified by comparing the contract code contained in the smart contract with the public code.

[0017] An information processing method according to a third aspect of the present disclosure is the information processing method according to the second aspect, wherein the identification includes identifying, as the one or more subcontracts, from among one or more codes included in the contract code, codes that match the public code at a match rate equal to or higher than a predetermined percentage, and the first list further includes, for each of the one or more subcontracts, the match rate between the subcontract code and the public code.

[0018] This allows for the identification of subcontracts using the code match rate, making it possible to properly detect the use of partial matches or similar code. This makes it possible to detect not only exact matches but also modified code, enabling more comprehensive management of smart contracts.

[0019] An information processing method according to a fourth aspect of the present disclosure is the information processing method according to the second or third aspect, wherein the public code is stored in a storage device for publishing the public code or in a blockchain that stores other smart contracts.

[0020] This allows the public code to be easily compared with the contract code since it is stored in a storage device or on the blockchain, improving the efficiency of determining the authenticity of one or more subcontracts and the efficiency of identifying the match rate of one or more subcontracts.

[0021] An information processing method according to a fifth aspect of the present disclosure is an information processing method according to any one of the first to fourth aspects, wherein the transmission includes transmitting transaction data including the first list to the blockchain system, and the blockchain system stores the transaction data and executes a detection smart contract that detects smart contracts that satisfy specified conditions, and by executing the detection smart contract, determines whether the smart contract satisfies the specified conditions based on the first list, and performs processing according to the determination result.

[0022] This makes it possible to automatically detect smart contracts that meet specified conditions based on transaction data including the first list, thereby enabling, for example, quick identification of risky contracts and efficient processing based on the identification results.

[0023] An information processing method according to a sixth aspect of the present disclosure is an information processing method according to the fifth aspect, wherein, in the processing according to the determination result, if the smart contract satisfies the specified conditions, conformance information indicating that the smart contract satisfies the specified conditions is sent to the first device, and if the smart contract does not satisfy the specified conditions, non-conformance information indicating that the smart contract does not satisfy the specified conditions is sent to the first device.

[0024] This allows conformance information or non-conformance information to be automatically sent to the first device depending on the result of the determination of the predetermined conditions, and the user of the first device can understand in real time whether the smart contract satisfies the predetermined conditions, which allows the user to decide whether to operate the smart contract or to quickly take measures against the smart contract.

[0025] An information processing method according to a seventh aspect of the present disclosure is an information processing method according to the fifth aspect, wherein the transaction data transmitted in the transmission further includes the smart contract, and in the processing according to the determination result, if the smart contract satisfies the specified conditions, the smart contract is not stored in the blockchain, and if the smart contract does not satisfy the specified conditions, the smart contract is stored in the blockchain.

[0026] This allows the storage of smart contracts on the blockchain to be controlled based on the judgment results, thereby preventing the distribution or operation of non-compliant smart contracts.

[0027] An information processing method according to an eighth aspect of the present disclosure is an information processing method according to the sixth or seventh aspect, wherein the specified condition is that the smart contract is free of vulnerabilities.

[0028] This makes it possible to automatically detect whether or not a smart contract has vulnerabilities and prevent vulnerable smart contracts from being stored in the blockchain, thereby preventing the distribution or operation of vulnerable smart contracts.

[0029] An information processing method according to a ninth aspect of the present disclosure is an information processing method according to the sixth or seventh aspect, wherein the specified condition is that permission to use the smart contract has been obtained.

[0030] This makes it possible to automatically detect whether or not a smart contract has permission to use it and prevent unauthorized smart contracts (for example, unauthorized or in violation of a license) from being stored on the blockchain. This makes it possible to prevent unauthorized smart contracts from being distributed or operated.

[0031] An information processing method according to a tenth aspect of the present disclosure is an information processing method according to any one of the fifth to ninth aspects, wherein the blockchain system further obtains a second list of one or more other smart contracts that include a contract code included in the smart contract, obtains conformance information indicating that the smart contract satisfies the specified conditions, and adds the smart contract and the one or more other smart contracts to a third list, which is a list of conforming smart contracts that satisfy the specified conditions, based on the second list and the conformance information.

[0032] This allows the relationships between smart contracts and other related smart contracts to be listed and managed, making it possible to comprehensively grasp the scope of influence of smart contracts that meet certain conditions, and therefore to efficiently implement measures against smart contracts that meet certain conditions and related smart contracts.

[0033] An information processing method according to an eleventh aspect of the present disclosure is the information processing method according to the tenth aspect, wherein the second list further includes, for each of the one or more other smart contracts, contract identification information that identifies the other smart contract, a compiler version corresponding to the other smart contract, and blockchain identification information corresponding to the other smart contract.

[0034] This allows the second list to include and manage the identification information, compiler version, and blockchain identification information of other smart contracts, making it easier to manage dependencies between the smart contract and one or more other smart contracts.

[0035] An information processing method according to a twelfth aspect of the present disclosure is an information processing method according to the tenth or eleventh aspect, wherein the blockchain system further executes measures for the smart contract and the one or more other smart contracts to satisfy the specified conditions.

[0036] This allows measures to be implemented collectively for the smart contract being inspected and one or more other smart contracts if they satisfy certain conditions, thereby enabling measures to be implemented efficiently for smart contracts that satisfy certain conditions and for smart contracts related to them.

[0037] An information processing method according to a thirteenth aspect of the present disclosure is an information processing method according to the twelfth aspect, wherein the countermeasure includes a process of providing a reward to a user who discovers the smart contract that satisfies the specified conditions.

[0038] This allows third parties to be encouraged to discover smart contracts that meet certain conditions.

[0039] An information processing method according to a fourteenth aspect of the present disclosure is an information processing method according to the twelfth aspect, wherein the measures include a process for determining a period during which the smart contract and the one or more other smart contracts can be used.

[0040] This allows the period during which a smart contract that meets certain conditions and one or more other smart contracts can be used to be set, making it possible to set a grace period before operation is suspended and preventing excessive restrictions on the use of these smart contracts.

[0041] An information processing method according to a fifteenth aspect of the present disclosure is an information processing method according to the fourteenth aspect, in which the available period is determined by voting by multiple users who manage the blockchain system.

[0042] This allows multiple users to decide the available period through voting, thereby enabling fair operational decisions that reflect diverse interests regarding smart contracts that meet specified conditions and one or more other smart contracts.

[0043] An information processing method according to a sixteenth aspect of the present disclosure is the information processing method according to the fourteenth or fifteenth aspect, wherein the countermeasure includes a process of providing a reward to a user who makes an improvement so that the specified condition is not satisfied within the available period.

[0044] This makes it possible to automatically provide a reward to a user who makes improvements so that the predetermined condition is not satisfied within the available period, thereby promoting the prompt implementation of measures.

[0045] An information processing method according to a seventeenth aspect of the present disclosure is an information processing method according to any one of the fourteenth to sixteenth aspects, wherein the countermeasure includes a process of setting the smart contract and the one or more other smart contracts to be unavailable if the smart contract cannot be improved so as not to satisfy the specified condition within the available period.

[0046] This makes it possible to make a smart contract and one or more other smart contracts unavailable even after the period of availability has elapsed, if the smart contract and one or more other smart contracts still satisfy certain conditions, thereby reducing the security risk of the entire blockchain system.

[0047] An apparatus according to an eighteenth aspect of the present disclosure includes a processor and a memory, wherein the processor uses the memory to acquire a smart contract and analyze the smart contract to identify one or more subcontracts that constitute the smart contract, to identify, for each of the one or more subcontracts, the version of the compiler that compiled the subcontract and blockchain identification information that identifies the blockchain in which the subcontract is stored, to generate a first list that includes, for each of the one or more subcontracts, the subcontract identification information that identifies the subcontract, the compiler version identified for the subcontract, and the blockchain identification information identified for the subcontract, and to transmit the first list to a blockchain system that manages the blockchain to store it in the blockchain.

[0048] This makes it possible to obtain the identification information, compiler version, and blockchain identification information of each subcontract that makes up a smart contract and record them on the blockchain, making it easier to manage and track the configuration of smart contracts and improving traceability and maintainability.

[0049] A program according to a nineteenth aspect of the present disclosure is a program for causing a computer to execute the information processing method according to any one of the first to seventeenth aspects.

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

[0051] Hereinafter, embodiments will be described with reference to the drawings. Note that each of the embodiments described below represents a specific example of the present disclosure. In other words, the numerical values, shapes, materials, components, component arrangements and connection forms, steps, and step orders shown in the following embodiments are merely examples and are not intended to limit the present disclosure. Furthermore, among the components according to the following embodiments, components not recited in the independent claims representing the highest concepts are not necessarily required to achieve the objectives of the present disclosure, but are described as components constituting a more preferred embodiment.

[0052] (Embodiment) In this embodiment, an information processing method for extracting configuration information such as subcontracts that constitute a smart contract and systematically recording and managing the information on a blockchain will be described.

[0053] [System Configuration] FIG. 1 is a schematic diagram showing the configuration of a system according to an embodiment.

[0054] 1, the system 1 includes a user terminal 100 owned by a user, a management device 200, a blockchain system 300, and a network 600. In addition to the above configuration, the system 1 may further include a server 400.

[0055] The user terminal 100 is a terminal (e.g., a personal computer) operated by a user, and is a device that can perform operations related to blockchain and processes for storing transaction data in the blockchain system 300.

[0056] The management device 200 is a device (e.g., a personal computer or a server) that generates and updates information for managing smart contracts. For example, the management device 200 generates a first list that is a list of one or more subcontracts that make up the smart contract, or a second list that is a list of one or more other smart contracts that use the smart contract.

[0057] The blockchain system 300 is a distributed ledger system including nodes 300a, 300b, and 300c that are connected to each other so that they can communicate with each other. The blockchain system 300 manages a blockchain that is made up of blocks containing arbitrary data. The arbitrary data may be, for example, data related to virtual currencies (e.g., transaction data for crypto assets such as Bitcoin and Ethereum, wallet balance data, etc.), non-fungible tokens (NFTs), user identification information, or transaction data related to other smart contracts.

[0058] The server 400 is a storage device that stores public code (source code), which is code that has been made public. The server 400 provides an external source code management service, such as GitHub. The server 400 stores source code related to smart contracts and publishes or provides this source code to the outside.

[0059] The user terminal 100, management device 200, blockchain system 300, and server 400 may all be connected to one another via a network 600, all may be directly connected to enable communication, or some may be connected via the network 600 and other parts may be directly connected to enable communication. The network 600 may be, for example, the Internet or a mobile phone carrier network, but may be composed of any communication line or network.

[0060] FIG. 2 is a diagram illustrating an example of a configuration of a user terminal according to an embodiment.

[0061] The user terminal 100 includes a communication unit 101 , an input receiving unit 102 , a display unit 103 , a control unit 104 , and a storage unit 105 .

[0062] The communication unit 101 is an interface for communicating with the blockchain system 300 or the server 400 via the network 600. The communication unit 101 may, for example, transmit a smart contract to the management device 200 for analysis. The communication unit 101 may also have a function for transmitting transaction data for storing and deploying the smart contract in the blockchain system 300. The communication unit 101 may also have a function for transmitting transaction data for storing other data in the blockchain system 300.

[0063] In this way, the communication unit 101 communicates with the blockchain system 300 and the server 400 via the network 600. This communication may be performed using TLS (Transport Layer Security), and an encryption key for TLS communication may be held in the communication unit 101. The communication unit 101 is realized by a communication IF (Interface).

[0064] The input accepting unit 102 is an interface for accepting inputs from a user, such as the issuance of transaction data, the registration of a smart contract, and a request for analyzing a smart contract. The input accepting unit 102 may also accept inputs for generating a first list, which is a list of one or more subcontracts that constitute a smart contract. That is, the input accepting unit 102 may accept input of information to be included in the first list. The input accepting unit 102 may also accept inputs for generating a second list, which is a list of one or more other smart contracts that use the smart contract. That is, the input accepting unit 102 may accept input of information to be included in the second list. The accepted inputs may be transmitted to the control unit 104 and may also be reflected on the display unit 103.

[0065] The display unit 103 displays an input UI (User Interface) for receiving input by the input receiving unit 102. The display unit 103 also displays the input received by the input receiving unit 102 in the input UI. The display unit 103 has a function of displaying information received from the management device 200, the blockchain system 300, and the server 400, processing results, etc. The display unit 103 is realized by a display.

[0066] The control unit 104 may generate transaction data based on the input received by the input receiving unit 102, and transmit the generated transaction data to the blockchain system 300 via the communication unit 101. Furthermore, the control unit 104 may generate a smart contract analysis request, a first list, or a second list based on the input. The control unit 104 is realized by a processor.

[0067] The memory unit 105 stores information received by the communication unit 101, input accepted by the input accepting unit 102, transaction data generated by the control unit 104, etc. The memory unit 105 may also store data other than the above-mentioned information. The memory unit 105 is realized by a storage.

[0068] The user terminal 100 realizes various processes using blockchain by having the processor (control unit 104) execute a predetermined program using the memory (storage unit 105).

[0069] FIG. 3 is a diagram illustrating an example of a configuration of a management device according to an embodiment.

[0070] The management device 200 includes a communication unit 201 , an input receiving unit 202 , a display unit 203 , a control unit 204 , and a storage unit 205 .

[0071] The communication unit 201 is an interface for communicating with the blockchain system 300 via the network 600. The communication unit 201 may have, for example, a function to receive (acquire) a smart contract from the user terminal 100. The communication unit 201 may also have, for example, a function to execute information exchange between the blockchain system 300 or the server 400 to identify public code that is at least partially similar to or identical to the contract code included in the smart contract. The communication unit 201 may also have, for example, a function to transmit transaction data to the blockchain system 300.

[0072] In this way, the communication unit 201 communicates with the blockchain system 300 or the server 400 via the network 600. This communication may be performed using TLS (Transport Layer Security), and an encryption key for TLS communication may be held in the communication unit 201. The communication unit 201 is realized by a communication IF.

[0073] The input reception unit 202 is an interface for receiving inputs made by an administrator. The received inputs are sent to the control unit 204 and may also be reflected on the display unit 203. The input reception unit 202 is realized by an input device such as a keyboard, a mouse, or a touch panel. Note that the management device 200 does not necessarily have to include the input reception unit 202.

[0074] The display unit 203 displays an input UI (User Interface) for receiving input by the input receiving unit 202. The display unit 203 also displays the input received by the input receiving unit 202 in the input UI. The display unit 203 has a function of displaying information received from the blockchain system 300 or the server 400, processing results, etc. The display unit 203 is realized by, for example, a display. Note that the management device 200 does not necessarily have to include the display unit 203.

[0075] The control unit 204 may analyze the contract code included in the acquired smart contract. As a result, the control unit 204 may identify one or more subcontracts that constitute the smart contract. In this analysis, the control unit 204 refers to public code that is publicly available on the blockchain system 300 and the server 400 by communication between the blockchain system 300 and the server 400 via the communication unit 201. In other words, the public code is stored on the server 400 for sharing source code, or on the blockchain of the blockchain system 300 that stores other smart contracts. The control unit 204 may then compare the contract code included in the smart contract with the public code to identify one or more subcontracts that constitute the smart contract.

[0076] As a result, the control unit 204 identifies, for each of one or more subcontracts, the version of the compiler that compiled the subcontract and the blockchain identification information that identifies the blockchain that the subcontract is stored in. The blockchain identification information may be any information that can uniquely identify a blockchain, and may be the ID of the blockchain or information indicating the type of blockchain.

[0077] Then, the control unit 204 generates a first list including, for each of one or more subcontracts, subcontract identification information that identifies the subcontract, the compiler version specified for the subcontract, and the blockchain identification information specified for the subcontract. Details of the first list will be described later using FIG. 7.

[0078] In identifying one or more subcontracts, the control unit 204 may identify, as one or more subcontracts, code that matches the published source code at a match rate of at least a predetermined percentage, from among one or more codes included in the contract code of the smart contract. In this case, the first list may further include, for each of the one or more subcontracts, the match rate between the code of the subcontract and the source code.

[0079] The control unit 204 transmits the first list to the blockchain system 300 that manages the blockchain, for storage in the blockchain, using the communication unit 201. The control unit 204 is realized by a processor.

[0080] The storage unit 205 stores information received by the communication unit 201, input accepted by the input accepting unit 202, information generated by the control unit 204, etc. The storage unit 205 may store data other than the above-mentioned information. The storage unit 205 is realized by, for example, a storage.

[0081] The management device 200 realizes various processes for managing smart contracts by having the processor (control unit 204) execute a predetermined program using the memory (storage unit 205).

[0082] FIG. 4 is a diagram illustrating an example of a configuration of a node according to an embodiment.

[0083] 4, each of the nodes 300a to 300c includes a communication unit 301, a control unit 302, a recording unit 303, a transaction data verification unit 304, and a distributed ledger 305. The nodes 300a to 300c manage the blockchain.

[0084] The communication unit 301 transmits information to the user terminal 100, the management device 200, and other nodes among the nodes 300a to 300c via the network 600, and receives information from the user terminal 100, the management device 200, and other nodes among the nodes 300a to 300c.

[0085] Specifically, the communication unit 301 receives transaction data to be stored in the blockchain system 300 from the user terminal 100 or the management device 200. This transaction data may include a smart contract to be deployed to the blockchain system 300, or may include a smart contract that is to be determined by the blockchain system 300 as to whether or not it satisfies predetermined conditions. In the latter case, the smart contract need only be the subject of determination as to whether or not it satisfies predetermined conditions, and need not be deployed to the blockchain system 300. The communication unit 301 may also have a function to transmit, for example, to the user terminal 100, the determination result as to whether or not the acquired smart contract satisfies predetermined conditions. The communication unit 301 may also have a function to exchange information with the management device 200 to identify public code that is at least partially similar to or identical to the contract code included in the smart contract.

[0086] The other nodes are nodes 300a to 300c that are different from the node that includes the communication unit 301. The communication unit 301 also transmits and receives transaction data to and from the other nodes 300a to 300c for the purposes of the consensus algorithm.

[0087] In this way, the communication unit 301 communicates with the user terminal 100, the management device 200, and other nodes via the network 600. Note that this communication may be performed using TLS (Transport Layer Security), and the encryption key for TLS communication may be held by the communication unit 301.

[0088] The control unit 302 executes a consensus algorithm on the transaction data received by the communication unit 301. As a result, the control unit 302 stores the transaction data in the distributed ledger 305. The control unit 302 stores information included in the transaction data in the blockchain, for example, by linking a block including the transaction data to the blockchain of the distributed ledger 305.

[0089] Furthermore, if the information received by the communication unit 301 is a request to issue an NFT, the control unit 302 may issue an NFT and record the issued NFT in the distributed ledger 305. This may result in a block containing the NFT being added to the blockchain. For example, in the case of an NFT corresponding to content, upon receiving a request to issue an NFT, the communication unit 301 generates an NFT corresponding to the content based on the address (URL) included in the issuance request and stores the NFT in the blockchain. The NFT is recorded in the blockchain ledger by a smart contract as a set of data linking the address included in the issuance request, an NFT ID generated by the smart contract, and an initially set owner. The data recorded in the NFT may also include other information.

[0090] When the communication unit 301 receives transaction data, the transaction data verification unit 304 verifies the validity of the transaction data. For example, the transaction data verification unit 304 verifies whether the transaction data received by the communication unit 301 is accompanied by a digital signature generated using a correct method. If the validity is verified, the communication unit 301 transmits a copy of the transaction data to multiple other nodes 300a-300c, thereby causing the verified authenticated transaction data to be recorded in the recording units 303 of the other nodes 300a-300c. This allows only transaction data whose validity has been verified to be transmitted to other servers, thereby suppressing increases in computer power consumption. Note that this verification may be skipped.

[0091] The transaction data verifier 304 also executes a consensus algorithm together with multiple other nodes 300a to 300c to reach an agreement on the validity of the transaction data.

[0092] The consensus algorithm used here may be Practical Byzantine Fault Tolerance (PBFT), or another known consensus algorithm. Examples of known consensus algorithms include Proof of Work (PoW) and Proof of Stake (PoS). When PBFT is used as the consensus algorithm, the transaction data verifier 304 receives reports from each of the multiple nodes 300a to 300c indicating whether the transaction data verification was successful or not, and determines whether the number of reports exceeds a predetermined number (a threshold for the number of reports). When the number of reports exceeds the predetermined number, the transaction data verifier 304 determines that the validity of the transaction data has been verified by the consensus algorithm.

[0093] If the transaction data verification unit 304 confirms the legitimacy of the transaction data, it records the transaction data in the recording unit 303. If the legitimacy of the transaction data cannot be verified, the transaction data verification unit 304 discards the transaction data. This prevents transaction data whose legitimacy cannot be verified from being recorded in the recording unit 303, thereby reducing the required amount of computer resources. The transaction data verification unit 304 may generate a block including transaction data whose legitimacy has been confirmed, and store the generated block in the distributed ledger 305.

[0094] In this embodiment, the transaction data verification unit 304 verifies the validity of the transaction data received by the communication unit 301 .

[0095] The recording unit 303 records the transaction data by storing the transaction data whose validity has been verified by the transaction data verification unit 304 in the distributed ledger 305. This makes it possible to prevent tampering with the transaction data.

[0096] The recording unit 303 may be configured inside the distributed ledger 305.

[0097] The distributed ledger 305 stores transaction data. The distributed ledger 305 sequentially acquires and stores transaction data, and therefore stores one or more pieces of transaction data. The distributed ledger 305 is realized by storage.

[0098] Note that, when the information received by the communication unit 301 is a request to issue an NFT, the control unit 302 may issue the NFT and record the issued NFT in the distributed ledger 305. As a result, a block including the NFT may be added to the blockchain.

[0099] FIG. 5 is a diagram illustrating an example of a configuration of a server according to the embodiment.

[0100] The server 400 includes a communication unit 401 , a control unit 404 , and a storage unit 405 .

[0101] The communication unit 401 is an interface for communicating with the management device 200 via the network 600. The communication unit 401 may have a function for exchanging information with the management device 200 to identify public code that is at least partially similar to or identical to the contract code included in the smart contract, for example.

[0102] In this way, the communication unit 401 communicates with the management device 200 via the network 600. This communication may be performed using TLS (Transport Layer Security), and an encryption key for TLS communication may be held in the communication unit 401. The communication unit 401 is realized by a communication IF (Interface).

[0103] The control unit 404 may execute at least a part of a process for identifying public code that is at least partially similar to or matches the contract code included in the smart contract. The control unit 404 is realized by a processor.

[0104] The storage unit 405 stores information received by the communication unit 401, information generated by the control unit 404, etc. The storage unit 405 may store data other than the above-mentioned information. The storage unit 405 is realized by, for example, a storage.

[0105] The server 400 realizes various processes by causing a processor (control unit 404) to execute predetermined programs using a memory (storage unit 405).

[0106] [System Operation] Next, the operation of the system 1 configured as above will be described.

[0107] 6 is a sequence diagram showing an example of the operation of the system according to the embodiment. In the diagram, transaction data may be represented as Tx data, and a smart contract may be represented as SC.

[0108] The user terminal 100 receives input from a user and generates a new smart contract (SC) in accordance with the input (S1).

[0109] The user terminal 100 transmits the generated smart contract to the management device 200 (S2). As a result, the management device 200 receives the smart contract from the user terminal 100.

[0110] Upon receiving the smart contract, the management device 200 analyzes the received smart contract (S3). Specifically, after receiving the smart contract, the management device 200 performs a static code analysis process to analyze the syntactic structure or dependencies of the contract code. This static code analysis includes identifying libraries imported or referenced in the contract code, calculating the match rate between the contract code and public code (e.g., stored on GitHub, a blockchain, etc.), obtaining addresses (URLs, etc.) of matching smart contracts, and extracting dependencies. This allows the management device 200 to comprehensively understand the structural features and dependencies of the smart contract, as well as its correspondence with related existing code.

[0111] In the analysis, steps S4 and S5 are performed.

[0112] The management device 200 compares the contract code included in the smart contract with the public code stored in the server 400 to identify one or more subcontracts that are similar to or match the public code stored in the server 400 (S4). Specifically, if the contract code included in the smart contract is source code, the management device 200 may compare the source codes without converting them, since the public code stored in the server 400 is source code. Furthermore, if the contract code included in the smart contract is bytecode, the management device 200 may convert the public code stored in the server 400 into bytecode by compiling it, and then compare the bytecodes. Furthermore, if the contract code included in the smart contract is bytecode, the management device 200 may convert it into source code by compiling it with the contract code, and then compare the source codes.

[0113] When identifying one or more subcontracts, the management device 200 may acquire, for each of the one or more subcontracts, the version of the compiler that compiled the subcontract, the identification information of the subcontract, and the match rate with the public code. Note that the identification information of the subcontract may be the ID of the subcontract, or may be the address (URL) on the server 400 of the public code that is similar to or matches the subcontract.

[0114] The management device 200 compares the contract code included in the smart contract with the public code stored in the blockchain system 300 to identify one or more subcontracts that are similar to or match the public code stored in the blockchain system 300 (S5). Specifically, if the contract code included in the smart contract is source code, the management device 200 may convert the contract code included in the smart contract into bytecode by compiling it, and compare the bytecodes, since the public code stored in the blockchain system 300 is bytecode. Also, if the contract code included in the smart contract is source code, the management device 200 may decompile the public code into bytecode, and compare the bytecodes, since the public code stored in the blockchain system 300 is bytecode. Also, if the contract code included in the smart contract is bytecode, the management device 200 may compare the bytecodes without converting them.

[0115] When identifying one or more subcontracts, the management device 200 may acquire, for each of the one or more subcontracts, the version of the compiler that compiled the subcontract, the identification information of the subcontract, the blockchain identification information of the blockchain in which the subcontract is stored, and the match rate with the public code. Note that the identification information of the subcontract may be the ID of the subcontract or the contract address of the subcontract.

[0116] The management device 200 generates a first list (S6) that includes, for each of one or more subcontracts, subcontract identification information that identifies the subcontract, the compiler version specified for the subcontract, and the blockchain identification information specified for the subcontract. The first list is, for example, a normal SCBOM (Smart Contract Bill of Materials) and includes information about each of the one or more subcontracts that make up the smart contract. In other words, the first list is information that indicates what contract code a given smart contract has. In other words, one first list is generated corresponding to one smart contract.

[0117] Here, a specific example of the first list will be described with reference to FIG.

[0118] FIG. 7 is a diagram showing an example of a first list of one or more subcontracts that constitute a smart contract according to an embodiment.

[0119] The first list is a list of attribute information for each subcontract that makes up the smart contract. The first list is used, for example, to identify and manage each subcontract, determine its authenticity, or analyze its dependency relationships.

[0120] The columns in Figure 7 are, in order, SC ID, contract address, URL, dependency, compiler version, blockchain identification information, and match rate. SC ID is a unique number (or character string) assigned to each subcontract for management purposes. Contract address is information indicating the storage location in the blockchain to which the subcontract is deployed. URL indicates an external reference to the public code or related information of the subcontract, and includes, for example, a URL such as GitHub.

[0121] Dependencies indicate the dependency relationships (e.g., inheritance relationships, extension relationships) of each subcontract with respect to the main contract indicated by ID1. For example, "w / #1" means dependency on the main contract indicated by ID1, specifically meaning that the subcontract indicated by ID2 has the function of calling the main contract indicated by ID1. In other words, the subcontract indicated by ID2 is a contract that calls the contract indicated by ID1 or its database. "Extend #2" means an extension of the subcontract indicated by ID2, specifically meaning that the subcontract indicated by ID3 includes at least some of the code of the subcontract indicated by ID2. In other words, the subcontract indicated by ID3 is a contract that includes some or all of the code indicated by ID2 and adds or restricts the functions of ID2.

[0122] The compiler version is the version number of the compiler used to compile the subcontract. The blockchain identification information is the identification information of the blockchain in which the subcontract is stored, such as Ethereum or Polygon. The match rate is an indicator of the match rate or clone relationship between the subcontract code and the public code, and is expressed as a perfect match (clone) or a certain percentage (e.g., 80% or 90%).

[0123] The user terminal 100 or the management device 200 can systematically grasp the overall structure or origin and dependencies of smart contracts by managing the first list on the blockchain system 300. Furthermore, the user terminal 100 or the management device 200 can use the information recorded in the first list to perform vulnerability testing of subcontracts, license management, tracking of inheritance relationships, or operational control.

[0124] In this way, the first list is an information structure that is central to the traceability and security management of smart contracts in the system 1 of this embodiment.

[0125] Returning to the description of FIG.

[0126] The management device 200 generates first transaction data including the first list based on the first list (S7). The first transaction data has a data structure for recording the subcontract identification information and related information included in the first list in the blockchain system 300.

[0127] The management device 200 transmits the generated first transaction data to the blockchain system 300 (S8). As a result, the blockchain system 300 receives the first transaction data from the management device 200.

[0128] The blockchain system 300 executes a consensus algorithm on the received first transaction data, thereby storing the first transaction data in the blockchain (S9). This process allows information about the components of the smart contract to be managed in an immutable, transparent, and decentralized manner, facilitating subsequent verification and management of the smart contract.

[0129] FIG. 8 is a sequence diagram showing an example of an operation in which vulnerability testing and deployment control of a smart contract are performed in a system according to an embodiment.

[0130] The user terminal 100 receives input from the user and generates a new smart contract (SC) in accordance with the input (S11).

[0131] Next, the user terminal 100 generates second transaction data (second Tx data) corresponding to the generated smart contract (S12).

[0132] The second transaction data may include a first list (normal SCBOM) related to the smart contract to be deployed. In other words, if the first list (normal SCBOM) related to the smart contract is stored in advance on the blockchain, the second transaction data does not need to include the first list. The second transaction data may include the smart contract.

[0133] After that, the user terminal 100 transmits the second transaction data to the blockchain system 300 (S13). As a result, the blockchain system 300 receives the second transaction data from the user terminal 100.

[0134] When the blockchain system 300 receives the second transaction data, it checks whether the smart contract included in the second transaction data has any vulnerabilities (S14). That is, the blockchain system 300 determines whether the smart contract includes any code with vulnerabilities. This vulnerability check is performed using a detection smart contract, which is a smart contract for vulnerability check implemented on the blockchain. The blockchain system 300 executes the detection smart contract to perform the processes of steps S14 and S15.

[0135] Specifically, in step S14, the blockchain system 300 checks whether the smart contract itself contains a known vulnerability, or whether the compiler related to the smart contract contains a known vulnerability, and compares it with the second list (inverse-SCBOM) or the third list (vulnerable SC list) recorded in the blockchain to check whether the SC ID included in the first list (normal SCBOM) matches the SC ID included in the third list, or whether there is a relationship with the smart contract listed in the second list.

[0136] Here, a specific example of the second list will be described with reference to FIG.

[0137] FIG. 9 illustrates an example of a second list of one or more other smart contracts that utilize a smart contract according to an embodiment.

[0138] Unlike the first list, the second list is information indicating what other smart contracts the contract code of a certain smart contract is used in. In other words, if there is a problem with a certain smart contract, the second list for that smart contract will indicate a list of other smart contracts that also have the problem.

[0139] The second list has the same structure as the first list and lists the attribute information of each other smart contract that uses the smart contract. The second list is used, for example, to identify and manage each other smart contract, determine its authenticity, or analyze its dependency relationships.

[0140] The columns in Figure 9 are, in order, SC ID, contract address, URL, dependency, compiler version, blockchain identification information, and match rate. SC ID is a unique number (or string) assigned to each other smart contract for management purposes. Contract address is information indicating the storage location of each other smart contract in the blockchain to which it is deployed. URL indicates an external reference to the public code or related information of each other smart contract, and includes, for example, a URL such as GitHub.

[0141] Dependency indicates a dependency (e.g., inheritance relationship, extension relationship) between the smart contract indicated by ID11 and another smart contract or another smart contract. For example, "w / #11" means a dependency with the smart contract indicated by ID11, specifically, that the other smart contract indicated by ID12 has the function of calling the smart contract indicated by ID11. In other words, the other smart contract indicated by ID12 is a contract that calls the smart contract indicated by ID11 or its database. "extend #12" means an extension of the contract indicated by ID12, specifically, that the other smart contract indicated by ID13 includes at least some of the code of the other smart contract indicated by ID12. In other words, the other smart contract indicated by ID13 is a contract that includes some or all of the code indicated by ID12 and adds or restricts the functionality of ID12.

[0142] The compiler version is the version number of the compiler used to compile the other smart contract. The blockchain identification information is the identification information of the blockchain on which the other smart contract is stored, such as Ethereum or Polygon. The match rate is an indicator of the degree of match or clone relationship between the code of each other smart contract and the public code, and is expressed as a perfect match or a certain percentage (e.g., 80% or 90%).

[0143] By managing the second list on the blockchain system 300, the user terminal 100 or the management device 200 can systematically grasp the usage relationships or origins and dependencies of smart contracts. Furthermore, the user terminal 100 or the management device 200 can use the information listed in the second list to perform vulnerability testing, license management, inheritance relationship tracking, or operational control of smart contracts or other contracts.

[0144] Returning to the description of FIG.

[0145] If the inspection results in the blockchain system 300 determining that the transmitted smart contract contains vulnerable code (Yes in S14), the blockchain system 300 terminates the process (rejects registration), and may discard the smart contract.

[0146] On the other hand, if no vulnerability is detected in the smart contract (No in S14), the blockchain system 300 stores the second transaction data in the blockchain by executing a consensus algorithm on the second transaction data (S15).

[0147] This series of processes can prevent the deployment or operation of vulnerable smart contracts, ensuring security.

[0148] Therefore, smart contracts created by users are recorded on the blockchain and deployed with safety guaranteed.

[0149] In step S14, the blockchain system 300 executes the detection smart contract to determine whether the smart contract included in the second transaction data (i.e., the smart contract to be inspected) has a vulnerability, but this is not limiting and the blockchain system 300 may also determine whether permission to use the smart contract has been obtained. In other words, in step S14, it is sufficient to determine whether the smart contract to be inspected satisfies a predetermined condition.

[0150] For example, the blockchain system 300 may terminate processing if the smart contract to be inspected satisfies a predetermined condition (Yes in S14), and may execute step S15 if the smart contract to be inspected does not satisfy the predetermined condition (No in S14). In this way, the predetermined condition may be that the smart contract to be inspected does not have a vulnerability, or that permission to use the smart contract to be inspected has been obtained.

[0151] 10 is a sequence diagram showing an example of an operation in which a vulnerability test for a smart contract is performed in a system according to an embodiment. Fig. 10 differs from Fig. 8 in that the smart contract is not deployed, and the test result is notified to the user.

[0152] The user terminal 100 executes the same processes as steps S11 to S13.

[0153] Then, the blockchain system 300 executes the same processing as step S14.

[0154] If, as a result of the inspection, the blockchain system 300 determines that the transmitted smart contract contains code that has a vulnerability (Yes in S14), it transmits compliance information indicating that the smart contract has a vulnerability (i.e., that it meets the conditions for having a vulnerability) to the user terminal 100 (S16).

[0155] On the other hand, if no vulnerability is detected in the smart contract (No in S14), the blockchain system 300 sends non-compliance information indicating that the smart contract does not have a vulnerability (i.e., indicating that the condition for having a vulnerability is not met) to the user terminal 100 (S17).

[0156] If the smart contract does not satisfy the predetermined conditions as a result of determining whether the smart contract satisfies the conditions, the smart contract may be given authentication using an NFT. This authentication may be, for example, time-limited, with a predetermined expiration date, or open-ended, with no specific expiration date. This authentication demonstrates that the smart contract is currently free of vulnerabilities and can function as proof information that contributes to ensuring reliability and security. The NFT that serves as authentication information may also include the date of issuance of the authentication, the expiration date (or validity period) of the authentication, the entity that conducted the inspection, or its identification information, etc.

[0157] FIG. 11 is a sequence diagram illustrating an example of processing when a vulnerability is discovered according to the embodiment.

[0158] The user terminal 100 discovers a smart contract (SC) having a vulnerability in the blockchain system 300 (S21). This discovery of the vulnerability is realized by the user analyzing the source code themselves or by receiving information provided by a third party. In other words, the user terminal 100 discovers a smart contract having a vulnerability by accepting the analysis results of the source code from the user or by receiving information provided by a third party.

[0159] The user terminal 100 generates a second list (inverse-SCBOM) including information on the vulnerable smart contract and other smart contracts that use that smart contract (S22). This second list includes the address, identification information, dependency relationships, compiler version, blockchain identification information, match rate, etc. of the vulnerable smart contract. Note that the vulnerable smart contract may be a smart contract for which permission for use has not been obtained, and may be indicated by a combination of the smart contract and compliance information indicating that the smart contract complies with predetermined conditions.

[0160] The user terminal 100 generates third transaction data including the second list based on the second list (S23). The third transaction data has a data structure for recording identification information and related information of the vulnerable smart contract.

[0161] The user terminal 100 transmits the generated third transaction data to the blockchain system 300 (S24). As a result, the blockchain system 300 receives the third transaction data from the user terminal 100. In other words, the blockchain system 300 acquires the second list.

[0162] The blockchain system 300 executes a consensus algorithm on the received third transaction data, thereby storing the third transaction data in the blockchain (S25).

[0163] Next, based on the third transaction data, the blockchain system 300 adds the vulnerable smart contract and other smart contracts based on the second list that use the vulnerable smart contract to the third list (S26).

[0164] The blockchain system 300 simultaneously implements countermeasures to address vulnerabilities for all smart contracts included in the second list (S27).

[0165] Specific examples of countermeasures implemented in step S27 include the following: Countermeasures include, for example, rewarding a user or third party who discovers a vulnerable smart contract for their discovery. The amount of this reward may be increased or decreased depending on the number of uses of the smart contract, i.e., the total amount of gas sent to the smart contract.

[0166] The countermeasures may also include a process for determining a usable period for the smart contract having the vulnerability and other smart contracts using the same. The usable period may be determined by voting by multiple users. Furthermore, if a usable period is set, a process may be executed to provide a reward to the user who fixed the vulnerability within that period. This reward may also be determined to vary depending on the number of uses of the smart contract (past gas amount), etc.

[0167] Furthermore, if the vulnerability is not fixed within the usable period, the smart contract or other smart contracts that use it may be set to unavailable on the blockchain. For example, the setting to be unavailable may involve blocking access to the smart contract or executing a destruction process.

[0168] In addition, when addressing vulnerabilities, appropriate modifications can be made by referring to the compiler version or blockchain identification information listed in the first list (normal SCBOM).

[0169] In this way, by using the series of processes shown in Figure 11, if the user terminal 100 or a third party discovers a smart contract with a vulnerability, the vulnerability information and its scope of impact can be recorded on the blockchain system 300, and measures can be efficiently implemented against multiple related smart contracts.

[0170] [Effects, etc.] The information processing method according to this embodiment is executed by at least the management device 200 (first device). The management device 200 acquires a smart contract (S2). The management device 200 analyzes the smart contract (S3). As a result, the management device 200 identifies one or more subcontracts constituting the smart contract, and for each of the one or more subcontracts, identifies the version of the compiler that compiled the subcontract and blockchain identification information that identifies the blockchain in which the subcontract is stored (S4, S5). The management device 200 generates a first list that includes, for each of the one or more subcontracts, the subcontract identification information that identifies the subcontract, the compiler version identified for the subcontract, and the blockchain identification information identified for the subcontract (S6). The management device 200 transmits the first list to the blockchain system 300 that manages the blockchain for storage in the blockchain (S8).

[0171] This makes it possible to obtain the identification information, compiler version, and blockchain identification information of each subcontract that makes up a smart contract and record them on the blockchain, making it easier to manage and track the configuration of smart contracts and improving traceability and maintainability.

[0172] In the information processing method according to this embodiment, the identification step involves comparing the contract code included in the smart contract with public code, which is publicly available code, to identify one or more subcontracts.

[0173] This allows the origin and similarity of subcontracts to be identified by comparing the contract code contained in the smart contract with the public code.

[0174] In the information processing method according to the present embodiment, the identification step involves identifying, as one or more subcontracts, codes that match the public code at a match rate equal to or greater than a predetermined rate from among one or more codes included in the contract code. The first list further includes, for each of the subcontracts, the match rate between the subcontract code and the public code.

[0175] This allows for the identification of subcontracts using the code match rate, making it possible to properly detect the use of partial matches or similar code. This makes it possible to detect not only exact matches but also modified code, enabling more comprehensive management of smart contracts.

[0176] In the information processing method according to this embodiment, the public code is stored in a server 400 (storage device) for publishing the public code, or in a blockchain that stores other smart contracts.

[0177] This allows the public code to be easily compared with the contract code since it is stored on the server 400 or on the blockchain, improving the efficiency of determining the authenticity of one or more subcontracts and the efficiency of identifying the match rate of one or more subcontracts.

[0178] In the information processing method according to this embodiment, in the transmission step, transaction data including the first list is transmitted to the blockchain system 300. The blockchain system 300 stores the transaction data and executes a detection smart contract that detects smart contracts that satisfy predetermined conditions. By executing the detection smart contract, the blockchain system 300 determines whether the smart contract has a vulnerability (whether the predetermined conditions are satisfied) based on the first list (S14), and executes processing according to the determination result.

[0179] This makes it possible to automatically detect smart contracts that meet specified conditions based on transaction data including the first list, thereby enabling, for example, quick identification of risky contracts and efficient processing based on the identification results.

[0180] In the information processing method according to the present embodiment, in the process according to the determination result, if the smart contract satisfies the predetermined condition (Yes in S14), conformance information indicating that the smart contract satisfies the predetermined condition is transmitted to the user terminal 100 (first device) (S16). In addition, in the process according to the determination result, if the smart contract does not satisfy the predetermined condition (No in S14), non-conformance information indicating that the smart contract does not satisfy the predetermined condition is transmitted to the user terminal 100 (S17).

[0181] This allows conformance information or non-conformance information to be automatically sent to the user terminal 100 according to the result of the determination of the predetermined conditions, and the user of the user terminal 100 can understand in real time whether the smart contract satisfies the predetermined conditions. This allows the user to decide whether to operate the smart contract or not, or to quickly implement measures against the smart contract.

[0182] In the information processing method according to this embodiment, the transaction data transmitted in the transmission of the transaction data including the first list further includes a smart contract. In the processing according to the determination result, if the smart contract satisfies a predetermined condition (Yes in S14), the smart contract is not stored in the blockchain and the processing ends. In the processing according to the determination result, if the smart contract does not satisfy the predetermined condition (No in S14), the smart contract is stored in the blockchain (S15).

[0183] This allows the storage of smart contracts on the blockchain to be controlled based on the judgment results, thereby preventing the distribution or operation of non-compliant smart contracts.

[0184] In the information processing method according to this embodiment, the predetermined condition is that the smart contract does not have any vulnerabilities.

[0185] This makes it possible to automatically detect whether or not a smart contract has vulnerabilities and prevent vulnerable smart contracts from being stored in the blockchain, thereby preventing the distribution or operation of vulnerable smart contracts.

[0186] In the information processing method according to this embodiment, the predetermined condition is that permission to use the smart contract has been obtained.

[0187] This makes it possible to automatically detect whether or not a smart contract has permission to use it and prevent unauthorized smart contracts (for example, unauthorized or in violation of a license) from being stored on the blockchain. This makes it possible to prevent unauthorized smart contracts from being distributed or operated.

[0188] In the information processing method according to this embodiment, the blockchain system 300 further acquires a second list of one or more other smart contracts that include the contract code included in the smart contract. The blockchain system 300 acquires non-compliance information indicating that the smart contract satisfies a predetermined condition. Based on the second list and the non-compliance information, the blockchain system 300 adds the smart contract and one or more other smart contracts based on the second list to a third list, which is a list of conforming smart contracts that satisfy the predetermined condition (S26).

[0189] This allows the relationships between smart contracts and other related smart contracts to be listed and managed, making it possible to comprehensively grasp the scope of influence of smart contracts that meet certain conditions, and therefore to efficiently implement measures against smart contracts that meet certain conditions and related smart contracts.

[0190] In the information processing method according to this embodiment, the second list further includes, for each of one or more other smart contracts, contract identification information that identifies the other smart contract, a compiler version corresponding to the other smart contract, and blockchain identification information corresponding to the other smart contract.

[0191] This allows the second list to include and manage the identification information, compiler version, and blockchain identification information of other smart contracts, making it easier to manage dependencies between the smart contract and one or more other smart contracts.

[0192] In the information processing method according to this embodiment, the blockchain system 300 further executes measures for the smart contract and one or more other smart contracts to satisfy predetermined conditions (S27).

[0193] This allows measures to be implemented collectively for the smart contract being inspected and one or more other smart contracts if they satisfy certain conditions, thereby enabling measures to be implemented efficiently for smart contracts that satisfy certain conditions and for smart contracts related to them.

[0194] In the information processing method according to this embodiment, the countermeasures include a process of rewarding a user who discovers a smart contract that satisfies a predetermined condition.

[0195] This allows third parties to discover smart contracts that satisfy predetermined conditions. In the information processing method according to this embodiment, the countermeasures include a process for determining the usable period of the smart contract and one or more other smart contracts.

[0196] This allows the period during which a smart contract that meets certain conditions and one or more other smart contracts can be used to be set, making it possible to set a grace period before operation is suspended and preventing excessive restrictions on the use of these smart contracts.

[0197] In the information processing method according to this embodiment, the available period may be determined by voting by multiple users who manage the blockchain system.

[0198] This allows multiple users to decide the available period through voting, thereby enabling fair operational decisions that reflect diverse interests regarding smart contracts that meet specified conditions and one or more other smart contracts.

[0199] In the information processing method according to this embodiment, the countermeasure includes a process of giving a reward to a user who improves so that the predetermined condition is not satisfied within the available period.

[0200] This makes it possible to automatically provide a reward to a user who makes improvements so that the predetermined condition is not satisfied within the available period, thereby promoting the prompt implementation of measures.

[0201] In the information processing method according to this embodiment, the countermeasures include a process of setting the smart contract and one or more other smart contracts to be unavailable if the smart contract cannot be improved so that it does not satisfy the specified conditions within the available period.

[0202] This makes it possible to make a smart contract and one or more other smart contracts unavailable even after the period of availability has elapsed, if the smart contract and one or more other smart contracts still satisfy certain conditions, thereby reducing the security risk of the entire blockchain system.

[0203] (Modifications) The following configurations or operations can be adopted as further developments, applications, and modifications of the contents of this specification.

[0204] (1) In addition to the present embodiment, for example, protocols such as REST API, gRPC, or WebSocket may be used as a means of communication between the components. The server 400 may be configured to manage smart contract source code using not only an external source code management service but also a distributed storage system (e.g., IPFS). Furthermore, the nodes 300a to 300c may be configured to dynamically allow nodes to be added or removed, or may be equipped with a failover mechanism that automatically enables another node to take over processing in the event of a failure.

[0205] (2) In addition to this embodiment, for example, access authentication using an access control list (ACL), API key, OAuth, or the like may be added when communicating with each device. Also, an access audit log may be acquired in each part of the system to detect and track anomalies. Furthermore, descriptions regarding version management and update procedures for various software and smart contracts may be included. An operational flow may be established to detect and take measures against unauthorized operations from malicious user terminals or management devices.

[0206] (3) In addition to the present embodiment, the first list and the second list may be generated automatically not only when a smart contract is registered or updated, but also during periodic scanning or auditing. The list may be written in a standard format such as JSON, XML, or YAML. Contract identification information may be uniquely identified using a hash value or UUID. Furthermore, multiple methods may be selected to calculate the match rate, such as comparing source code syntax trees (ASTs) or comparing bytecodes.

[0207] (4) In addition to this embodiment, vulnerability information from CVE or OSS may be used as a reference database or standard for vulnerability assessment. Smart contract license information (GPL, MIT, etc.) may be inspected, and a warning, registration refusal, or block may be issued in the event of a violation. The detection smart contract for vulnerability testing may work with external security services or oracles to improve the accuracy of the assessment. The user may be notified of the inspection results and the scope of the impact using a UI display, webhook, email, or other methods.

[0208] (5) In addition to this embodiment, cross-chain support may be included, which links list management and inspection judgments between different blockchains. Multiple consensus algorithms may be dynamically selected or switched depending on the application or purpose. Furthermore, the scope of application may be expanded to include NFTs, tokens, and other applications other than smart contracts.

[0209] (6) In addition to this embodiment, it is also possible to configure the system so that user identity verification (KYC / AML, etc.) is performed when paying rewards, and important operational decisions are made by voting or majority vote among multiple users. Furthermore, it is also possible to configure the system to link with an oracle service to obtain external blockchain data. It is also possible to expand the lifecycle management function from smart contract creation to operation, termination, and archiving.

[0210] (Supplementary Note) The following provides a supplementary explanation of the distributed ledger in the above embodiment or modification. Here, a blockchain will be described as an example of a distributed ledger, but the same applies to other distributed ledgers.

[0211] FIG. 12 is an explanatory diagram illustrating the data structure of a blockchain.

[0212] A blockchain is a chain of blocks, which are the units of record. 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 then 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.

[0213] If past transaction data were to be changed, the hash value of the block would be different from before the change, and in order to make the altered block appear correct, all subsequent blocks would have to be recreated, which is extremely difficult in reality. This property is used to ensure that blockchains are tamper-resistant.

[0214] FIG. 13 is an explanatory diagram showing the data structure of transaction data.

[0215] The transaction data shown in Figure 13 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 a digital signature generated for the hash value of the transaction body P1 using the signature key of the creator of the transaction data. More specifically, it is generated by encrypting the hash value with the private key of the creator of the transaction data. Examples of digital signature methods include ECDSA (Elliptic Curve Digital Signature Algorithm), CRYSTALS-Dilithium, Falcon, and SPHINCS+.

[0216] The transaction data has digital signature P2, making it virtually impossible to tamper with. If the transaction data were to be tampered with, verification using digital signature P2 would fail, revealing that the transaction data had been tampered with. This prevents tampering with the transaction body P1.

[0217] 14 and 15 are explanatory diagrams showing transaction data related to the execution of a smart contract, and processing related to the execution of a smart contract, respectively.

[0218] A series of processes related to the execution of a smart contract using a distributed ledger will be described with reference to Figures 14 and 15.

[0219] In step SB1, the node stores transaction data B11, including contract code B12 that describes the processing of the smart contract, in the distributed ledger B10. For example, the node acquires transaction data B11 by receiving the transaction data B11 from an information processing device via communication or by the node itself generating the transaction data B11, and stores the acquired transaction data B11 in the distributed ledger B10. Step SB1 is performed before executing the smart contract.

[0220] In step SB2, the node stores transaction data B15, including instructions B16 for executing the smart contract, in the distributed ledger B10. For example, the node receives transaction data B15 from an information processing device via communication and stores the received transaction data B15 in the distributed ledger B10.

[0221] In step SB3, in response to the transaction data B15 including the instruction B16 being stored in the distributed ledger B10 in step SB2, the node reads the contract code B12 from the distributed ledger B10 and executes processing based on the contract code B12. The results of the processing may be included in the transaction data and stored in the distributed ledger B10.

[0222] FIG. 16 is an explanatory diagram showing the structure of an NFT and metadata. An NFT is a token stored in a distributed ledger and is a unique token (in other words, a non-fungible token). NFTs are standardized, for example, as ERC (Ethereum Request for Comments) 721, but are not limited to this. NFTs may conform to a different standard or may be non-standard (for example, proprietary to an organization). While ERC 721 is a standard for unique tokens, the NFTs described herein do not necessarily have to be unique tokens.

[0223] 16 shows transaction data B21 stored in the distributed ledger. The transaction data B21 stores an NFT. The NFT includes a token ID (i.e., identification information that can uniquely identify the NFT) and a metadata uniform resource identifier (URI).

[0224] The NFT has metadata. The metadata may be located in a location accessible via a network (e.g., storage device B22). A metadata URI indicating the location of the metadata may be calculated using the NFT's token ID and a predetermined base URI.

[0225] The information managed as an NFT may be included in the transaction data B21 or in the metadata. Including the information managed as an NFT in the metadata has the advantage of reducing the amount of information included in the transaction data B21 (in other words, the information included in the blockchain). In this case, it can be said that the metadata contains the actual information managed as an NFT. When an image is managed as an NFT, a URL indicating the image data of the image may be managed as an NFT.

[0226] Through the above series of processes, when the distributed ledger system receives transaction data B15 including instructions B16 for executing a smart contract, it automatically (i.e., without manual intervention) executes the processing in accordance with the instructions B16, enabling highly efficient (i.e., high speed or short processing time). Achieving highly efficient processing has the effect of reducing power consumption. Furthermore, since no manual intervention is required, it is possible to prevent human tampering with information, fraud, or human error. Furthermore, since the results of the processing thus executed are stored in the blockchain, it is virtually impossible to tamper with the results of the processing.

[0227] [Other Embodiments, etc.] As described above, the present disclosure has been described based on the above-mentioned embodiments, but it goes without saying that the present disclosure is not limited to the above-mentioned embodiments. The following cases are also included in the present disclosure.

[0228] (1) Each device in the above embodiments is specifically a computer system comprising a microprocessor, ROM, RAM, hard disk unit, display unit, keyboard, mouse, etc. A computer program is recorded on the RAM or hard disk unit. Each device achieves its function by the microprocessor operating in accordance with the computer program. Here, the computer program is composed of a combination of multiple instruction codes that indicate commands to a computer to achieve a predetermined function.

[0229] (2) In each of the above embodiments, some or all of the constituent elements may be configured from a single system LSI (Large Scale Integration). A system LSI is an ultra-multifunctional LSI manufactured by integrating multiple components on a single chip, and specifically, is a computer system configured to include a microprocessor, ROM, RAM, etc. A computer program is stored in the RAM. The system LSI achieves its functions when the microprocessor operates in accordance with the computer program.

[0230] Furthermore, each of the components constituting each of the above-described devices may be individually integrated into a single chip, or some or all of them may be integrated into a single chip.

[0231] Although the term "system LSI" is used here, it may also be called an IC, LSI, super LSI, or ultra LSI depending on the level of integration. Furthermore, the method of integration is not limited to LSI, and may be realized using a dedicated circuit or a general-purpose processor. It is also possible to use a field programmable gate array (FPGA), which can be programmed after LSI manufacturing, or a reconfigurable processor, which allows the connections and settings of circuit cells within the LSI to be reconfigured.

[0232] Furthermore, if an integrated circuit technology that can replace LSI emerges due to advances in semiconductor technology or other derivative technologies, it is natural that such technology may be used to integrate functional blocks. The application of biotechnology, etc. is also a possibility.

[0233] (3) Some or all of the components constituting each of the above devices may be configured as an IC card or a standalone module that can be attached to each device. The IC card or module may be a computer system configured with a microprocessor, ROM, RAM, etc. The IC card or module may include the above-mentioned ultra-multifunctional LSI. The IC card or module achieves its functions when the microprocessor operates in accordance with a computer program. The IC card or module may be tamper-resistant.

[0234] (4) The present disclosure may be embodied as the above-described methods, a computer program for implementing these methods on a computer, or a digital signal comprising the computer program.

[0235] The present disclosure may also be a computer program or a digital signal recorded on a computer-readable recording medium, such as a flexible disk, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, a BD (Blu-ray (registered trademark) Disc), a semiconductor memory, etc. Alternatively, the present disclosure may be a digital signal recorded on such a recording medium.

[0236] Furthermore, the present disclosure may also be applied to transmitting the computer program or the digital signal via a telecommunications line, a wireless or wired communication line, a network such as the Internet, data broadcasting, or the like.

[0237] The present disclosure may also be directed to a computer system having a microprocessor and a memory, the memory storing the computer program, and the microprocessor operating in accordance with the computer program.

[0238] The program or the digital signal may also be implemented by another independent computer system by recording it on the recording medium and transferring it, or by transferring the program or the digital signal via the network or the like.

[0239] (5) The above-described embodiments and modifications may be combined with each other.

[0240] The present disclosure is useful as an information processing method that makes it easy to manage and track the configuration of smart contracts and improves traceability and maintainability.

[0241] 1 System 100 User terminal 101, 201, 301, 401 Communication unit 102, 202 Input reception unit 103, 203 Display unit 104, 204, 302, 404 Control unit 105, 205, 405 Storage unit 200 Management device 300 Blockchain system 300a to 300c Node 303 Recording unit 304 Transaction data verification unit 305 Distributed ledger 400 Server 600 Network

Claims

1. An information processing method executed by at least a first device, comprising: acquiring a smart contract; analyzing the smart contract to identify one or more subcontracts that make up the smart contract; identifying, for each of the one or more subcontracts, the version of the compiler that compiled the subcontract and blockchain identification information that identifies the blockchain in which the subcontract is stored; generating a first list that includes, for each of the one or more subcontracts, the subcontract identification information that identifies the subcontract, the compiler version identified for the subcontract, and the blockchain identification information identified for the subcontract; and transmitting the first list to a blockchain system that manages the blockchain to store it in the blockchain.

2. The information processing method of claim 1, wherein the identification comprises comparing a contract code included in the smart contract with public code, which is publicly available code, to identify the one or more subcontracts.

3. The information processing method of claim 2, wherein the identification step identifies, as the one or more subcontracts, codes from among one or more codes included in the contract code that match the public code at a matching rate equal to or higher than a predetermined rate, and the first list further includes, for each of the one or more subcontracts, the matching rate between the subcontract code and the public code.

4. An information processing method according to claim 2 or 3, wherein the public code is stored in a storage device for publishing the public code or in a blockchain that stores other smart contracts.

5. An information processing method according to any one of claims 1 to 3, wherein the sending includes sending transaction data including the first list to the blockchain system, and the blockchain system executes a detection smart contract that detects smart contracts that satisfy specified conditions by storing the transaction data, and by executing the detection smart contract, determines whether the smart contract satisfies the specified conditions based on the first list, and executes processing according to the result of the determination.

6. The information processing method of claim 5, wherein the processing according to the determination result comprises, if the smart contract satisfies the specified conditions, transmitting conformance information indicating that the smart contract satisfies the specified conditions to the first device, and, if the smart contract does not satisfy the specified conditions, transmitting non-conformance information indicating that the smart contract does not satisfy the specified conditions to the first device.

7. The information processing method of claim 5, wherein the transaction data transmitted in the transmission further includes the smart contract, and in the processing according to the determination result, if the smart contract satisfies the specified conditions, the smart contract is not stored in the blockchain, and if the smart contract does not satisfy the specified conditions, the smart contract is stored in the blockchain.

8. The information processing method described in claim 6, wherein the predetermined condition is that the smart contract has no vulnerabilities.

9. The information processing method described in claim 6, wherein the predetermined condition is that permission to use the smart contract has been obtained.

10. The information processing method described in claim 5, wherein the blockchain system further: obtains a second list of one or more other smart contracts that include the contract code included in the smart contract; obtains conformance information indicating that the smart contract satisfies the specified conditions; and adds the smart contract and the one or more other smart contracts to a third list, which is a list of conforming smart contracts that satisfy the specified conditions, based on the second list and the conformance information.

11. The information processing method described in claim 10, wherein the second list further includes, for each of the one or more other smart contracts, contract identification information that identifies the other smart contract, a compiler version corresponding to the other smart contract, and blockchain identification information corresponding to the other smart contract.

12. The information processing method according to claim 10, wherein the blockchain system further executes measures for the smart contract and the one or more other smart contracts in response to the specified conditions being met.

13. The information processing method according to claim 12, wherein the countermeasure includes a process of providing a reward to a user who discovers the smart contract that satisfies the predetermined condition.

14. The information processing method of claim 12, wherein the measures include a process for determining an available period for the smart contract and the one or more other smart contracts.

15. The information processing method according to claim 14, wherein the available period is determined by voting of a plurality of users who manage the blockchain system.

16. The information processing method according to claim 14, wherein the countermeasure includes a process of providing a reward to a user who improves so that the predetermined condition is not satisfied within the available period.

17. An information processing method as described in claim 14, wherein the countermeasures include a process of setting the smart contract and the one or more other smart contracts to be unavailable if the smart contract is not improved so that the specified condition is not met within the available period.

18. A device comprising: a processor; and a memory, wherein the processor uses the memory to: acquire a smart contract; analyze the smart contract to identify one or more subcontracts that make up the smart contract; identify, for each of the one or more subcontracts, the version of the compiler that compiled the subcontract and blockchain identification information that identifies the blockchain in which the subcontract is stored; generate a first list for each of the one or more subcontracts, the first list including the subcontract identification information that identifies the subcontract, the compiler version identified for the subcontract, and the blockchain identification information identified for the subcontract; and transmit the first list to a blockchain system that manages the blockchain for storage in the blockchain.

19. A program for causing a computer to execute the information processing method according to any one of claims 1 to 3.

Images