Information processing method, information processing device, and program

Abstract

This information processing method is executed in an information processing system including a device for transferring data from a first distributed ledger system to a second distributed ledger system different from the first distributed ledger system. The information processing method includes: acquiring a code included in a smart contract executed when transferring the data from the first distributed ledger system to the second distributed ledger system (S20); detecting vulnerability of the smart contract on the basis of whether or not the code includes a code for executing predetermined processing (S30); and outputting a detection result for the vulnerability of the smart contract (S40).

Description

Information processing method, information processing device, and program

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

[0002] Cross-chain technology has been known as a technology that enables data exchange between multiple blockchain systems. For example, Patent Literature 1 discloses a device that acts as a bridge connecting multiple blockchains and realizes communication between the multiple blockchains using the Cross Blockchain Communication Protocol (CBCP).

[0003] Special table 2019-536380 publication

[0004] Incidentally, even if no vulnerabilities are found in smart contracts executed in a blockchain system when they are executed within a single blockchain system, vulnerabilities may be found when they are executed via a device that acts as a bridge connecting multiple blockchain systems. Patent Document 1 does not disclose any technology for detecting such vulnerabilities.

[0005] Therefore, the present disclosure provides an information processing method, an information processing device, and a program that can detect vulnerabilities in smart contracts executed via a bridge device.

[0006] An information processing method according to one aspect of the present disclosure is an information processing method executed in an information processing system including a device that transfers data from a first distributed ledger system to a second distributed ledger system different from the first distributed ledger system, the information processing method obtaining code included in a smart contract that is executed when the device transfers data from the first distributed ledger system to the second distributed ledger system, detecting vulnerabilities in the smart contract based on whether the code includes code that executes a predetermined process, and outputting the detection result of the vulnerability of the smart contract.

[0007] An information processing device according to one aspect of the present disclosure is an information processing device in an information processing system that includes a device that transfers data from a first distributed ledger system to a second distributed ledger system that is different from the first distributed ledger system, and includes: an acquisition unit that acquires code included in a smart contract that is executed when transferring data from the first distributed ledger system to the second distributed ledger system; a detection unit that detects vulnerabilities in the smart contract based on whether the code includes code that executes a predetermined process; and an output unit that outputs the detection result of the vulnerability of the smart contract.

[0008] A program according to one aspect of the present disclosure is a program for causing a computer to execute the above-described information processing method.

[0009] According to one aspect of the present disclosure, it is possible to realize an information processing method, etc., that can detect vulnerabilities in smart contracts executed via a bridge device.

[0010] FIG. 1 is a diagram showing the configuration of an information processing system according to an embodiment. FIG. 2 is a block diagram showing the functional configuration of a ledger server according to an embodiment. FIG. 3A is a block diagram showing the functional configuration of a server according to an embodiment. FIG. 3B is a block diagram showing the functional configuration of an information processing device according to an embodiment. FIG. 4 is a flowchart showing the operation of the information processing device according to an embodiment. FIG. 5 is a diagram showing information regarding attacks that can be detected by the information processing device according to the embodiment. FIG. 6 is a flowchart showing the detailed operation of step S30 shown in FIG. 4. FIG. 7A is a diagram showing a first example of code of a smart contract having a vulnerability. FIG. 7B is a diagram showing the code of the smart contract in which the vulnerability shown in FIG. 7A has been resolved, expressed as an XML syntax tree. FIG. 8A is a diagram showing a second example of code of a smart contract having a vulnerability. FIG. 8B is a diagram showing an example of code of the smart contract in which the vulnerability shown in FIG. 8A has been resolved. FIG. 9A is a diagram showing a third example of code of a smart contract having a vulnerability. FIG. 9B is a diagram showing an example of code of the smart contract in which the vulnerability shown in FIG. 9A has been resolved. FIG. 10A is a diagram showing a fourth example of code of a smart contract having a vulnerability. FIG. 10B is a diagram showing an example of smart contract code in which the vulnerability shown in FIG. 10A has been resolved. FIG. 11 is a diagram showing an example of smart contract code that executes processing related to payments. FIG. 12A is a diagram showing a fifth example of smart contract code having a vulnerability. FIG. 12B is a diagram showing an example of smart contract code in which the vulnerability shown in FIG. 12A has been resolved. FIG. 13 is an explanatory diagram showing the data structure of a blockchain, which is an example of a distributed ledger. FIG. 14 is an explanatory diagram showing the data structure of transaction data. FIG. 15 is an explanatory diagram showing transaction data related to the execution of a smart contract. FIG. 16 is a flowchart showing processing related to the execution of a smart contract. FIG. 17 is an explanatory diagram showing the structures of an NFT and metadata.

[0011] (Background to the present embodiment) First, an example of cross-chain technology will be described. Here, we will illustrate the processing of a sender blockchain system that sends data such as tokens, a receiver blockchain system that receives data such as tokens, and a server that acts as a bridge that transfers data from the sender blockchain system to the receiver blockchain system. Here, we will assume that the sender blockchain system is the Bitcoin network and the receiver blockchain system is the Ethereum network. In this case, smart contracts deployed in each of the multiple blockchain systems and a server that acts as a bridge connecting the multiple blockchain systems execute predetermined processing, allowing data to be transferred from one blockchain system to another.

[0012] Specifically, when the sending blockchain system receives transaction data containing a Bitcoin transfer command from an external terminal, it sends the transaction data to a bridge server. The bridge server executes a smart contract deployed on the sending blockchain system to lock (also known as event lock) Bitcoin equal to the transfer amount in the sender's wallet and deposit (also known as event deposit or deposit) the Bitcoin equal to the transfer amount into a wallet for temporary management. The bridge server then executes a smart contract deployed on the receiving blockchain system to issue new Ethereum equal to the locked Bitcoin. In other words, by executing smart contracts deployed on the sending and receiving blockchain systems, the bridge server can send data such as digital assets from the sending blockchain system to the receiving blockchain system.

[0013] As mentioned above, a server connecting multiple blockchain systems (hereinafter referred to as a bridge server) executes a predetermined process, enabling data to be sent and received between multiple different blockchain systems. However, it is known that there are vulnerabilities that can cause abnormal behavior in smart contracts when data is transmitted via the bridge server. Note that a smart contract executed via a bridge server may mean that the bridge server executes a smart contract deployed in the sending and receiving blockchain systems.

[0014] A known method for detecting vulnerabilities in smart contracts that are executed via a bridge server involves pattern matching between transaction events occurring in a sending blockchain system and a receiving blockchain system. One example is a technology that detects vulnerabilities in smart contracts by determining an anomaly when an event deposit process is not executed after an event lock process is executed. However, this technology cannot detect vulnerabilities that are likely to arise from attacks other than event-related attacks. Non-event-related attacks may refer to attacks against the vulnerable code (also known as source code) contained in the smart contract. Furthermore, because this technology monitors events of smart contracts deployed to the blockchain, it cannot detect vulnerabilities in smart contracts before they are deployed to the blockchain.

[0015] Therefore, the inventors of the present application have conducted extensive research into information processing methods and the like that can detect vulnerabilities in smart contracts whose processing is executed via a bridge server, and have devised the information processing methods and the like described below.

[0016] An information processing method according to a first aspect of the present disclosure is an information processing method executed in an information processing system including a device that transfers data from a first distributed ledger system to a second distributed ledger system different from the first distributed ledger system, the information processing method obtaining code included in a smart contract that is executed when the device transfers data from the first distributed ledger system to the second distributed ledger system, detecting vulnerabilities in the smart contract based on whether the code includes code that executes a predetermined process, and outputting the detection result of the vulnerability of the smart contract.

[0017] This allows for the detection of vulnerabilities in smart contracts using the code of the smart contract, making it possible to detect vulnerabilities to attacks other than those related to events when the smart contract is executed via a bridge server. Furthermore, since the code of the smart contract is used, there is no need to check events, making it possible to detect vulnerabilities in the smart contract even before the smart contract is deployed.

[0018] An information processing method according to a second aspect of the present disclosure is the information processing method according to the first aspect, wherein the predetermined processing includes a first processing of confirming the authority of an executor who made a change request when changing the owner of the smart contract, and a vulnerability of the smart contract may be detected if the code does not include code for executing the first processing.

[0019] This makes it possible to detect vulnerabilities to attacks that execute fraudulent processing by fraudulently changing the owner of a smart contract.

[0020] An information processing method according to a third aspect of the present disclosure is the information processing method according to the first or second aspect, wherein the detection of vulnerabilities based on whether or not the code that executes the specified processing is present may be performed by converting the structure of the acquired code into a syntax tree, which is a hierarchically expressed tree structure, and using the converted syntax tree.

[0021] This allows for the use of syntax trees, thereby reducing the time required to detect vulnerabilities in smart contracts.

[0022] Furthermore, for example, the information processing method according to the fourth aspect is the information processing method according to the first or second aspect, and the detection of vulnerability based on whether or not the code that executes the specified processing is present may be performed by converting the acquired code into an expression using a mathematical formula, and using the converted mathematical formula.

[0023] This allows for the use of type calculations, making it possible to accurately detect vulnerabilities in smart contracts.

[0024] 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 predetermined processing includes a second processing of determining whether or not proof is recorded in the first distributed ledger system or the second distributed ledger system when executing a proof verification function in a consensus algorithm, and a vulnerability of the smart contract may be detected if it is determined that the code does not include code for executing the second processing.

[0025] This makes it possible to detect vulnerability to attacks that execute fraudulent processing by reusing past proofs.

[0026] An information processing method according to a sixth aspect of the present disclosure is an information processing method according to any one of the first to fifth aspects, wherein the smart contract has a function of performing a remittance process, the data is a token, the predetermined process includes a third process of verifying the authority of an executor who has requested the remittance of the token, and if the code does not include code for executing the third process, a vulnerability of the smart contract may be detected.

[0027] This makes it possible to detect vulnerabilities to attacks that perform fraudulent transactions, such as fraudulent money transfers.

[0028] An information processing method according to a seventh aspect of the present disclosure is an information processing method according to any one of the first to sixth aspects, wherein the predetermined process includes a fourth process of checking whether the type of a variable of a return value of signature verification in the second distributed ledger system matches the type of a variable indicating the result of signature verification in the first distributed ledger system, and a vulnerability of the smart contract may be detected if the code does not include code for executing the fourth process.

[0029] This makes it possible to detect vulnerabilities that are likely to occur due to attacks that execute unauthorized processing by using different variable types.

[0030] An information processing method according to an eighth aspect of the present disclosure is an information processing method according to any one of the first to seventh aspects, wherein the smart contract has a function of performing a remittance process, and the predetermined process includes a fifth process of confirming whether the total amount of the amount received by the remittance destination from the remitter, the remaining amount remaining in the remitter after the remittance, and the usage fee for executing the smart contract matches the remaining amount of the remitter before the remitter performs the remittance process, and if the code does not include code for executing the fifth process, a vulnerability in the smart contract may be detected.

[0031] This makes it possible to detect vulnerabilities that are likely to arise from attacks that cause malfunctions by transferring tokens between multiple blockchain systems.

[0032] An information processing method according to a ninth aspect of the present disclosure is an information processing method according to any one of the first to eighth aspects, wherein the predetermined processing includes a sixth processing step of checking whether at least one of a variable and an address used in the smart contract has been initialized, and if the code does not include code for executing the sixth processing step, a vulnerability of the smart contract may be detected.

[0033] This makes it possible to detect vulnerabilities that are likely to arise from attacks that change the token market price by repeatedly transferring and withdrawing funds.

[0034] An information processing method according to a tenth aspect of the present disclosure is an information processing method according to any one of the first to ninth aspects, wherein the detection result may include information indicating that a vulnerability has been detected in the smart contract.

[0035] This allows the user to be notified by an alert that a vulnerability has been detected.

[0036] An information processing method according to an eleventh aspect of the present disclosure is an information processing method according to any one of the first to tenth aspects, wherein the detection result includes code in the smart contract in which a vulnerability has been detected, and the code in which the vulnerability has been detected may be presented to a user.

[0037] This allows the code in which a vulnerability has been detected to be presented to the user, thereby assisting the user in identifying smart contracts that have vulnerabilities.

[0038] Furthermore, an information processing device according to a twelfth aspect of the present disclosure is an information processing device in an information processing system including a device that transfers data from a first distributed ledger system to a second distributed ledger system different from the first distributed ledger system, and includes an acquisition unit that acquires code included in a smart contract that is executed when transferring data from the first distributed ledger system to the second distributed ledger system, a detection unit that detects vulnerabilities in the smart contract based on whether the code includes code that executes a predetermined process, and an output unit that outputs the detection result of the vulnerability of the smart contract.

[0039] This provides the same effect as the above-described information processing method.

[0040] A program according to a thirteenth 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 eleventh aspects.

[0041] This provides the same effect as the above-described information processing method.

[0042] These general or specific aspects may be realized as a system, a method, an integrated circuit, a computer program, or a non-transitory recording medium such as a computer-readable CD-ROM, or as any combination of the system, method, integrated circuit, computer program, or recording medium. The program may be pre-stored in the recording medium, or may be supplied to the recording medium via a wide area communication network including the Internet.

[0043] Hereinafter, the embodiments will be specifically described with reference to the drawings.

[0044] The embodiments described below are all comprehensive or specific examples. The numerical values, components, component placement and connection configurations, steps, and step order shown in the following embodiments are merely examples and are not intended to limit the present disclosure. Furthermore, among the components in the following embodiments, components not described in independent claims are described as optional components.

[0045] Furthermore, each figure is a schematic diagram and is not necessarily an exact illustration. Therefore, for example, the scales and the like do not necessarily match in each figure. Furthermore, in each figure, substantially identical configurations are assigned the same reference numerals, and duplicate explanations are omitted or simplified. Furthermore, for convenience, English notations are provided in some of the drawings for reference. English notations may not necessarily match Japanese notations in the specification. Furthermore, English notations may also be used in the specification.

[0046] Furthermore, in this specification, numerical values ​​and numerical ranges are not expressions that express only the strict meaning, but are expressions that mean that they also include a substantially equivalent range, for example, a difference of about several percent (or about 10%).

[0047] Furthermore, in this specification, ordinal numbers such as "first" and "second" do not refer to the number or order of components unless otherwise specified, but are used for the purpose of avoiding confusion and distinguishing between components of the same type.

[0048] (Embodiment) Hereinafter, an information processing device and the like according to the present embodiment will be described with reference to FIGS.

[0049] [1. Configuration of Information Processing System] First, the configuration of an information processing system according to this embodiment will be described with reference to Figures 1 to 3B. Figure 1 is a diagram showing the configuration of an information processing system 10 according to this embodiment. Note that Figure 1 shows an exemplary functional configuration of the information processing system 10, and the functional configuration of the information processing system 10 is not limited to that shown in Figure 1.

[0050] 1 , information processing system 10 comprises a first distributed ledger system 100, a second distributed ledger system 200, a server 300 with bridge functionality, and an information processing device 400. Each of first distributed ledger system 100 and second distributed ledger system 200 is communicatively connected to server 300, and is configured to be able to exchange assets or information via server 300. Furthermore, information processing device 400 is communicatively connected to each of first distributed ledger system 100, second distributed ledger system 200, and server 300.

[0051] The first distributed ledger system 100 is a ledger system that includes ledger servers 100a, 100b, and 100c (also referred to as ledger servers 100a, etc.) as a group of servers that hold a first distributed ledger (for example, the distributed ledger 114a shown in FIG. 2). When at least one of the ledger servers 100a, etc. receives transaction data, the transaction data is transferred to all ledger servers 100a, etc. other than the at least one server, and stored in the first distributed ledger held by each of them.

[0052] In this way, ledger server 100a is the server that holds and manages the first distributed ledger, and updates the distributed ledger while synchronizing it with other ledger servers (specifically, ledger servers 100b and 100c).

[0053] Ledger servers 100b and 100c are servers that hold and manage the first distributed ledger, similar to ledger server 100a, and operate independently of ledger server 100a.

[0054] The second distributed ledger system 200 is a ledger system that includes ledger servers 200a, 200b, and 200c (also referred to as ledger servers 200a, etc.) as a group of servers that hold the second distributed ledger. The second distributed ledger is a distributed ledger that is different from the first distributed ledger, and the data recorded in the first distributed ledger and the second distributed ledger are different. When at least one of the ledger servers 200a, etc. receives transaction data, the transaction data is forwarded to all ledger servers 200a, etc. other than the at least one server, and stored in the second distributed ledger held by each of them.

[0055] In this way, ledger server 200a is a server that holds and manages the second distributed ledger, and updates the distributed ledger while synchronizing it with other ledger servers (specifically, ledger servers 200b and 200c).

[0056] Ledger servers 200b and 200c are servers that hold and manage a second distributed ledger, similar to ledger server 200a, and operate independently of ledger server 200a.

[0057] A distributed ledger system is a processing system that uses a distributed ledger to store various types of data. A variety of data can be stored in the distributed ledger of the ledger system. The distributed ledger of the ledger system stores transaction data history for executing processes such as remittance processing. The distributed ledger may also store the creation history of NFTs, which are associated one-to-one with objects in the real world, and the transfer history of the NFTs. The NFTs are NFTs that trace the creation or transfer of objects in the real world on the distributed ledger.

[0058] The distributed ledger system can also execute smart contract-based transactions using the distributed ledger, and can generate NFTs and transfer NFTs using smart contract-based transactions.

[0059] The first distributed ledger system 100 and the second distributed ledger system 200 are different blockchain networks, i.e., systems that use different blockchain protocols, such as the Ethereum network on one side and the Bitcoin network on the other. Data such as digital assets can be transferred from one of the first distributed ledger system 100 and the second distributed ledger system 200 to the other via a server 300 that has bridge functionality.

[0060] Hereinafter, the storage devices 101a, 101b, and 101c will also be referred to as storage devices 101a, etc. (storage devices 101a to 101c), and the storage devices 201a, 201b, and 201c will also be referred to as storage devices 201a, etc. (storage devices 201a to 201c).

[0061] The ledger server 100a, etc. is connected to the storage device 101a, etc. The ledger server 100a, etc. may be connected to the storage device 101a, etc. via a communication network (not shown), or may include the storage device 101a, etc. internally. The storage device 101a, etc. has a distributed ledger in which transaction data and blocks of the blockchain are electronically recorded.

[0062] The ledger server 200a etc. is connected to the storage device 201a etc. The ledger server 200a etc. may be connected to the storage device 201a etc. via a communication network (not shown), or may include the storage device 201a etc. internally. The storage device 201a etc. has a distributed ledger in which transaction data and blocks of the blockchain are electronically recorded.

[0063] Each distributed ledger system manages the distributed ledger using a blockchain. Note that the number of ledger servers that make up a distributed ledger system is not limited to three.

[0064] Each component of the information processing system 10 will be described below with further reference to FIGS. 2 to 3B. FIG. 2 is a block diagram showing the functional configuration of the ledger server 100a according to this embodiment. Since the configurations of the ledger servers 100b, 100c, and 200a to 200c are similar to that of the ledger server 100a, the following description will use the ledger server 100a as an example. Note that FIG. 2 shows an exemplary functional configuration of the ledger server 100a, and the functional configuration of the ledger server 100a is not limited to that shown in FIG. 2.

[0065] 2, the ledger server 100a includes a communication unit 111, a ledger management unit 112, an execution unit 113, and a storage unit 114. At least some of the functional units included in the ledger server 100a are realized by a processor (e.g., a CPU) included in the ledger server 100a executing a program using a memory.

[0066] The communication unit 111 is a communication interface communicatively connected to a communication network. The communication unit 111 is used when the functional unit of the ledger server 100a communicates with other devices. For example, the communication unit 111 is used when the functional unit of the ledger server 100a communicates with either the ledger server 100b or 100c. The communication unit 111 may be configured to include, for example, a communication circuit (or a communication module).

[0067] The ledger management unit 112 processes the distributed ledger 114a and transaction data. Specifically, when the ledger management unit 112 receives transaction data from the ledger servers 100b and 100c, it verifies the digital signature included in the received transaction data and controls the storage of successfully verified transaction data in the distributed ledger 114a held by the storage unit 114. When storing transaction data in the distributed ledger 114a, the ledger management unit 112 generates a block including the transaction data to be stored, and can control the storage of the generated block in the distributed ledger 114a when an agreement is reached with the ledger management units of the other ledger servers, the ledger servers 100b and 100c.

[0068] The execution unit 113 can execute information processing by executing smart contracts deployed in the distributed ledger 114a. When the execution unit 113 does not execute smart contracts, it executes information processing according to normal program code.

[0069] The storage unit 114 is a storage device that stores information. The storage unit 114 stores a distributed ledger 114a. The storage unit 114 is realized by a non-volatile storage device (such as a solid state drive (SSD) or a hard disk drive (HDD)).

[0070] The distributed ledger 114a stores data having a structure in which blocks, each containing one or more transaction data, are linked in a chain. The one or more transaction data stored in the distributed ledger 114a include transaction data including the contract code of a smart contract, transaction data including instructions to execute the smart contract, or transaction data including other information. When transaction data including the contract code of a smart contract is recorded in the distributed ledger, the smart contract is deployed. When transaction data including instructions to execute the smart contract is recorded in the distributed ledger, the smart contract is executed. In this embodiment, the distributed ledger 114a is a blockchain.

[0071] Referring again to FIG. 1 , server 300 is an information processing device connected between the first distributed ledger system 100 and the second distributed ledger system 200 and functions as a bridge in cross-chain technology. Server 300 is, for example, a device that transfers data from the first distributed ledger system 100 to a second distributed ledger system 200 that is different from the first distributed ledger system 100. Server 300 performs information processing to enable crypto assets (also called tokens) such as virtual currencies to be used in two or more blockchain systems. Note that server 300 is an information processing device that is not included in any of the blockchain systems.

[0072] Below, we will describe an example of transferring tokens from the first distributed ledger system 100 (also called the sender blockchain system) to the second distributed ledger system 200 (also called the destination blockchain system) via server 300.

[0073] Fig. 3A is a block diagram showing the functional configuration of server 300 according to this embodiment. Note that Fig. 3A shows an exemplary functional configuration of server 300, and the functional configuration of server 300 is not limited to that shown in Fig. 3A.

[0074] 3A, the server 300 includes a communication unit 311 and an execution unit 312. At least some of the functional units included in the server 300 are realized by a processor (e.g., a CPU) included in the server 300 executing a program using a memory.

[0075] When the communication unit 311 acquires transaction data including a token remittance command from the first distributed ledger system 100 to the second distributed ledger system 200, the execution unit 312 executes a remittance process on the first distributed ledger system 100 side and a deposit process on the second distributed ledger system 200. Specifically, when the communication unit 311 acquires transaction data including a token remittance command from the first distributed ledger system 100, the execution unit 312 executes a smart contract (also referred to as a first smart contract) deployed on the first distributed ledger to lock tokens equivalent to the remittance amount in the sender's wallet and deposit the tokens equivalent to the remittance amount into a wallet for temporary management (also referred to as a deposit process). Next, the execution unit 312 executes a smart contract (also referred to as a second smart contract) deployed on the recipient's blockchain system to issue tokens in the second distributed ledger system 200 in an amount equal to the remittance amount. In other words, since the server 300 has the authority to execute the code (also called functions) used in the smart contract in each blockchain system, it can be said that the remittance process and the deposit process are executed on each blockchain system. Although the code in a series of programs in a smart contract is executed in order from top to bottom, the execution unit 312 may execute processing from code in the middle of the series of programs, or may execute processing of only part of the code.

[0076] The server 300 may also have a function for generating transaction data. The server 300 may generate transaction data that includes at least one of the following information: an instruction to execute an operation on a smart contract deployed in the first distributed ledger system 100 or the second distributed ledger system 200; an identifier of the smart contract; an identifier of the first distributed ledger system 100 or the second distributed ledger system 200; and an identifier of the server that owns the first distributed ledger system 100 or the second distributed ledger system 200.

[0077] The information processing device 400 detects vulnerabilities in smart contracts used in the information processing system 10, which includes a first distributed ledger system 100 and a second distributed ledger system 200 connected via a server 300.

[0078] 3B is a block diagram showing the functional configuration of the information processing device 400 according to this embodiment. Note that FIG. 3B shows an exemplary functional configuration of the information processing device 400, and the functional configuration of the information processing device 400 is not limited to that shown in FIG. 3B. Furthermore, the information processing device 400 is an information processing device that is not included in a blockchain system. Furthermore, the information processing device 400 is an information processing device different from the server 300.

[0079] 3B , the information processing device 400 includes an acquisition unit 411, a detection unit 412, a storage unit 413, and an output unit 414. At least some of the functional units included in the information processing device 400 are realized by a processor (e.g., a CPU) included in the information processing device 400 executing a program using a memory.

[0080] The acquisition unit 411 is a communication interface communicatively connected to a communication network. The acquisition unit 411 may be a communication interface for a wired communication standard (e.g., Ethernet (registered trademark) or the like), or may be a communication interface for a wireless communication standard (e.g., Wi-Fi (registered trademark) or the like, or a mobile communication system (3G, 4G, 5G, or the like)). The acquisition unit 411 is used when a functional unit included in the information processing device 400 acquires information from another device. For example, the acquisition unit 411 is used when a functional unit included in the information processing device 400 acquires information from either the ledger server of either the first distributed ledger system 100 or the second distributed ledger system 200, the server 300, or the like. The acquisition unit 411 may be configured to include, for example, a communication circuit (or a communication module).

[0081] The detection unit 412 executes information processing to detect vulnerabilities in smart contracts. The detection unit 412 detects vulnerabilities in smart contracts by performing pattern matching related to the code of the smart contracts.

[0082] The storage unit 413 is a storage device that stores various information for detecting vulnerabilities in smart contracts. The storage unit 413 is realized by a non-volatile storage device (SSD or HDD) or the like.

[0083] The output unit 414 is a communication interface communicatively connected to a communication network. The output unit 414 may be a communication interface for a wired communication standard (e.g., Ethernet (registered trademark) or the like), or may be a communication interface for a wireless communication standard (e.g., Wi-Fi (registered trademark) or the like, or a mobile communication system (3G, 4G, 5G, etc.)). The output unit 414 is used when a functional unit of the information processing device 400 outputs information to another device. For example, the output unit 414 is used when a functional unit of the information processing device 400 outputs information to either the ledger server of either the first distributed ledger system 100 or the second distributed ledger system 200, the server 300, etc. The output unit 414 may be configured to include, for example, a communication circuit (or a communication module).

[0084] 2. Operation of Information Processing System Next, the operation of the information processing system 10 configured as described above will be described with reference to Fig. 4 to Fig. 12B. Fig. 4 is a flowchart showing the operation (information processing method) of the information processing device according to this embodiment.

[0085] 4, the output unit 414 of the information processing device 400 requests the code of a smart contract deployed in at least one of the first distributed ledger system 100 and the second distributed ledger system 200 (S10), and the acquisition unit 411 acquires the code of the smart contract deployed in at least one of the distributed ledger systems (S20). The acquired smart contract code is the code for which vulnerabilities are to be detected. The acquisition unit 411 may acquire the code from the device that generated the smart contract, or may acquire the code from the distributed ledger system.

[0086] The timing of acquiring a smart contract is not particularly limited; it may be acquired before the smart contract is deployed to the distributed ledger system, or before the deployed smart contract is executed (i.e., before the transaction for executing the smart contract is recorded on the blockchain).

[0087] The acquired smart contract code may be stored in the storage unit 413.

[0088] Next, the detection unit 412 detects vulnerabilities using the acquired code of the smart contract (S30). The detection unit 412 may detect vulnerabilities in the smart contract based on whether or not the smart contract has code that executes a predetermined process.

[0089] Next, the output unit 414 outputs the detection result of the vulnerability of the smart contract (S40). The output unit 414 may output the detection result to the device that generated the smart contract, or may output the detection result to the distributed ledger system in which the smart contract is deployed, thereby recording the detection result.

[0090] The detection result includes information indicating that a vulnerability has been detected, and may also include alert information. The detection result may also include the code of the smart contract in which the vulnerability has been detected. The output unit 414 may present the code in which the vulnerability has been detected to the device that generated the smart contract via an information terminal or the like. The code in which the vulnerability has been detected may include only the code in which the vulnerability has been detected out of the entire code of the smart contract, or it may be the entire code of the smart contract. Information indicating which of the determinations in steps S31 to S36 above resulted in a "No" result (i.e., the content of the determination that a vulnerability exists) may also be presented.

[0091] The processing of step S30 will now be further described with reference to FIGS. 5 to 12B. First, the details of vulnerabilities to be detected by the information processing device 400 will be described with reference to FIG. 5. FIG. 5 shows a list of attacks (e.g., fraudulent processing) that may be performed when a smart contract has a vulnerability. The "Attack Surface" column in FIG. 5 shows the general name of the attack, and the "Example" column shows the attack method.

[0092] As shown in Figure 5, "rugpull" refers to an attack to fraudulently obtain crypto assets, and an example of the attack method is "bridge running away." Although details will be omitted below, an example of an attack method used in "vulnerable contracts," which use vulnerabilities in smart contracts as a springboard, is "reentrancy," which re-enters the remittance process within the overall process, and an example of an attack method used in "problematic mint," which generates crypto assets without proper authorization, is "invalid mint permission," which abuses generation authority. Furthermore, an example of an attack method used in "Fake burn," which fakes the consumption of crypto assets, is "invalid burn approval," which grants inconsistent crypto asset consumption authority, and an example of an attack method used in "Incorrect release," which proceeds with processing with inconsistent calculation results, is "invalid verification," which indicates a verification failure. Furthermore, an example of an attack method used in "Replayed withdrawal," which re-executes a withdrawal, is "problematic proof," which does not complete the proof process, and an example of an attack method used in "Inconsistent transfer," which fails to transfer crypto assets, is "incorrect transfer amount," which causes the remittance amount and remaining balance to become inconsistent.

[0093] The relationship between "Attack Surface" and "Example" shown in FIG. 5 is merely an example, and is not limited to this.

[0094] Fig. 6 is a flowchart showing the detailed operation (information processing method) of step S30 shown in Fig. 4. Steps S31 to S34 show the process of determining whether or not the smart contract is vulnerable to a permission-related attack that executes processing beyond the authority of the executor, and steps S35 and S36 show the process of determining whether or not the smart contract is vulnerable to a logic error-related attack that executes without properly processing variables.

[0095] As shown in FIG. 6 , the detection unit 412 detects vulnerabilities in a smart contract by performing six determinations in steps S31 to S36. While FIG. 6 illustrates an example in which six determinations in steps S31 to S36 are performed, this is not limiting; at least one of the six determinations may be performed. Furthermore, while this is an example in which a No determination is made in any of steps S31 to S36, this is not limiting; even if a No determination is made in any of steps S31 to S36, other determinations may be performed. Furthermore, the timing at which the determinations in steps S31 to S36 are performed may be different from each other, or each may be performed independently (or in parallel). Furthermore, the order of the determinations in steps S31 to S36 is not particularly limited, and may be reversed.

[0096] The detection unit 412 acquires the code of the smart contract and determines whether or not a process for verifying the authority of the executor who executes the smart contract has been performed before changing the owner of the smart contract to another entity (S31). The owner of the smart contract may be the device or user that created the smart contract. Changing the owner of the smart contract may mean transferring management of the smart contract. The entity may mean the device or the user.

[0097] Typically, when a smart contract is executed in a blockchain system, all code included in the smart contract, i.e., all functions, are reliably executed, resulting in low vulnerability. On the other hand, when a smart contract is executed via a bridge server, the bridge server (here, server 300) may execute only some of the functions included in the smart contract. This may result in vulnerability because some functions, including those for verifying authority, may be skipped, allowing the smart contract to be executed without authorization. The process for verifying the authority of the executor, which is performed before changing the owner, is an example of a predetermined process (first process).

[0098] The determination in step S31 may be performed when the information processing system 10 acquires transaction data including an instruction to change the owner of the smart contract, or may be performed before the change of owner is executed.

[0099] Figure 7A is a diagram showing a first example of code for a smart contract having a vulnerability. The smart contract shown in Figure 7A is a contract for executing a process to change the owner of the smart contract. Note that the smart contract shown in Figure 7A can provide various functions by adding arbitrary functions to the smart contract.

[0100] The code shown on line 6 of Figure 7A indicates that manager has the authority to change the owner of contract A. manager refers to the original administrator of the smart contract. The code shown on line 9 of Figure 7A indicates that the "ChangeOwner" function changes the owner of contract A (i.e., the owner of the smart contract) to the input variable account (i.e., the address of the entity that executes the owner change).

[0101] Furthermore, as shown in the code from line 14 onwards in Figure 7A, contract B references the processing of contract A. Therefore, when the owner is changed in contract A, the new owner can also execute the processing of contract B. As shown in line 15 of Figure 7A, contract B can overwrite the function specified by funcSig in the contract specified by callee with "funcSig = onlyManager" and overwrite parameters with "parameters = manager". This is because a bridge server in a cross-chain system can reference and execute only part of the processing of a smart contract, rather than referencing and executing the entire smart contract. In other words, in the smart contract shown in Figure 7A, there is a risk that the owner may be changed ignoring the constraint on line 6.

[0102] In this way, if the owner variable is changed, unless contract A contains code that verifies whether the entity attempting to make the change has the authority to make the change, the unauthorized change to owner cannot be detected and the process will be executed as normal. In this way, even when events are proceeding normally, smart contracts may have vulnerabilities.

[0103] The detection unit 412 detects smart contracts with the above-described vulnerabilities using a method that uses an Extensible Markup Language (XML) syntax tree or a method that uses type calculation. A syntax tree is a tree structure that hierarchically represents the structure of code. The determination of whether or not the acquired smart contract code contains the code that executes the first process is performed by converting the acquired smart contract code into an XML syntax tree and using the converted XML syntax tree. Alternatively, the smart contract code may be converted into a mathematical expression and the converted mathematical expression may be used to determine whether or not the smart contract contains the code that executes the first process. Since the process of converting code into an XML syntax tree is performed in a short time, vulnerability detection can be performed in a short time. Furthermore, when type calculation is used, possible states of the code can be expressed mathematically, allowing vulnerabilities to be detected with high accuracy through the calculation results.

[0104] Figure 7B is a diagram showing the code of the smart contract in which the vulnerability shown in Figure 7A has been resolved, expressed as an XML syntax tree. Note that any known method, such as using a parser (syntax analyzer), may be used to convert the code into an XML syntax tree.

[0105] In the XML syntax tree shown in Figure 7B, ifCondition indicates a conditional expression, indicating that only an entity that satisfies the condition linked to ifCondition can execute the process linked to changeowner. The condition linked to ifCondition refers to msg.sender (the address of the executor executing the process to change the owner of the smart contract) and manager (the owner of the smart contract) shown in Figure 7B. The process linked to changeowner refers to manager and account (the address of the executor executing the process to change the owner). In other words, the owner of the smart contract can be changed to the address of the executor executing the change process only when msg.sender and the address of the owner specified in manager match. On the other hand, the code shown in Figure 7A does not include processing related to the condition linked to ifCondition.

[0106] Therefore, the detection unit 412 may convert the code of the smart contract into an XML syntax tree, determine whether ifCondition is included in the code (i.e., whether the execution of changeOwner is restricted to entities that satisfy the conditions indicated in ifCondition), and determine that the smart contract has a vulnerability if it is not included, and determine that the smart contract does not have a vulnerability if it is included.

[0107] Note that the syntax tree is not limited to being an XML syntax tree, and may be any syntax tree that indicates the grammatical structure of the code of the smart contract.

[0108] In addition, the detection unit 412 may express the code of the smart contract using type calculation (i.e., convert the code into an expression using a mathematical formula), determine whether the converted formula contains the type shown in Equation 1 below, and determine that the smart contract has a vulnerability if it does not, and determine that the smart contract does not have a vulnerability if it does.

[0109]

[0110] Ht corresponds to one variable included in the code. The detection unit 412 detects vulnerability by determining whether the explicit variable range of Ht includes only manager.

[0111] Equation 1 can be calculated as follows: Equation 2 is an equation representing a state machine.

[0112]

[0113] Furthermore, when the input variable is v and the output variable is h, the calculation result of the input variable v and the output variable h is E(v, h), the set of input variables is V, the set of output variables is H, an arbitrary program unit is P, and the formulation of the arbitrary program unit P is [P].

[0114] In this case, the abstract concept of the if statement of the program and its type calculation can be defined as in the following formulas 3 to 5, respectively.

[0115] Abstraction: if E(ν, h) then P ｔ　 else P ｆ ...(Formula 3)

[0116]

[0117]

[0118] The above-mentioned formula 3 is an expression of an if statement, and its type calculation expression is given in formulas 4 and 5. The if statement branches processing depending on whether or not the condition is satisfied, and the case where the condition is satisfied corresponds to the term in formula 6 below in formula 4, and the case where the condition is not satisfied corresponds to the term in formula 7 below in formula 4.

[0119]

[0120]

[0121] Furthermore, the output is Equation 5. As described in Equation 1, when the range of the variable Ht includes only manager, it is determined that the process leading to changeowner is executed in Equation 6. When manager is not included, that is, when the process leading to changeowner is executed in Equation 7, it is determined that the smart contract has a vulnerability.

[0122] Referring back to FIG. 6 , if the detection unit 412 determines that a process for verifying the authority of the executor executing the smart contract has been performed before the owner of the smart contract is changed to another entity (Yes in S31), it then determines whether or not the proof has been recorded in the first distributed ledger or the second distributed ledger when executing the proof verification function in the consensus algorithm (S32). Proof is data that proves that the process has been executed correctly, and the proof verification function is a function that verifies the validity of the data. Typically, when a smart contract is executed, a process that automatically verifies the transaction history recorded in the blockchain system is executed, resulting in low vulnerability. However, when a smart contract is executed via a bridge server connecting multiple blockchain systems, it is possible that the bridge server may verify the transaction history in one blockchain system but not the transaction history in the other blockchain system. This may result in vulnerabilities such as duplicate transfers. The transaction history is information related to the transactions executed by the blockchain system and is recorded in the blockchain. Taking remittance processing as an example, the history of remittance processing is recorded in the blockchain as processing history. Note that there are blockchain systems in which processing history is recorded in the blockchain, and there are also blockchain systems in which processing history is not recorded in the blockchain.

[0123] Specific examples of the above-mentioned vulnerabilities are as follows. Consider an example in which a token remittance process is executed from the first distributed ledger system 100 to the second distributed ledger system 200 via the server 300 in the information processing system 10. Information related to the remittance process is recorded as a processing history in the first and second distributed ledgers. Typically, when a smart contract is executed in a blockchain system, a process is executed to check the processing history recorded in the distributed ledger where the smart contract is deployed. However, smart contracts are not designed to check the processing history recorded in the distributed ledger where the smart contract is not deployed (i.e., the remittance destination distributed ledger). This could lead to fraudulent attempts to receive duplicate copies of previously remitted funds.

[0124] For example, if specifications are in place to verify the processing history (here, the history of remittance processing) recorded in the first distributed ledger of the first distributed ledger system 100, which is the blockchain system of the remitter, and the processing history (here, the history of deposit processing) recorded in the second distributed ledger of the second distributed ledger system 200, which is the blockchain system of the remitter, then if the two do not match, it can be detected that the second distributed ledger system 200 or the server 300 is performing fraudulent processing. On the other hand, if the process of verifying whether the processing histories recorded in the first distributed ledger system 100 and the second distributed ledger system 200 match is not executed, there is a risk that a remittance process (e.g., a duplicate remittance) will be executed in response to the remittance command.

[0125] Therefore, it is possible to prevent fraudulent transactions such as duplicate remittances by executing a process to verify whether the processing histories recorded in the first distributed ledger system 100 and the second distributed ledger system 200 match. For example, by determining whether the remittance processing history recorded in the first distributed ledger system 100 matches the deposit processing history recorded in the second distributed ledger system 200, and prohibiting the remittance processing if it is determined that they do not match, it is possible to prevent fraudulent transactions such as duplicate remittances.

[0126] In other words, the detection unit 412 determines whether the smart contract contains code that determines whether the processing history recorded in the first distributed ledger system 100 (e.g., the history of remittance processing) is consistent with the processing history recorded in the second distributed ledger system 200 (e.g., the history of deposit processing), and if it does not contain such code, it determines that the smart contract has a vulnerability, and if it does contain such code, it determines that the smart contract does not have a vulnerability.

[0127] As such, it is desirable that the smart contract include code for determining the proof recorded in the first distributed ledger or the second distributed ledger when executing the proof verification function. The process of checking whether the smart contract includes code for determining whether the proof is stored in the first distributed ledger or the second distributed ledger is an example of the predetermined process (second process).

[0128] 8A is a diagram showing a second example of code for a smart contract having a vulnerability. The smart contract shown in FIG. 8A is a contract for executing a remittance process after verifying proof. In FIG. 8A, the code does not include a function for determining whether or not there is proof recorded before executing the proof verification function.

[0129] In the example of Figure 8A, the proof variable data is verified by the function isValid, and if it is valid, the token is transferred. Here, if the function isValid does not execute a process to check the history, etc., of data, there is a risk that the proof recorded in the first distributed ledger system 100 or the second distributed ledger system 200 will be reused. In Figure 8A, since the function isValid does not execute a process to check the history, etc., of data, if it has been successfully verified in the past, it will be successfully verified again. This could result in, for example, past proof (i.e., past data) being reused when burning a token.

[0130] FIG. 8B is a diagram showing an example of smart contract code in which the vulnerability shown in FIG. 8A has been resolved.

[0131] In the code shown in FIG. 8B , verification is performed to determine whether the proof to be verified (i.e., the data to be verified) is included in a set of proofs used in the past (i.e., data used in the past). This makes it possible to detect whether the proof to be verified is included in the set of proofs used in the past, that is, whether a proof used in the past is being used again. This prevents proofs from being reused. When a remittance process is executed, the history of the remittance process is written to the distributed ledger 114a. In other words, a set of data can be obtained by checking the distributed ledger 114a. Note that the past may refer to a period prior to the timing at which the verification function is executed.

[0132] The detection unit 412 determines whether or not code for checking past proofs is included when executing a proof verification function, and determines that the smart contract has a vulnerability if the code does not include the code, and determines that the smart contract does not have a vulnerability if the code includes the code. It can also be said that the detection unit 412 detects a vulnerability in the smart contract if the code does not include a process for checking past proofs when executing a proof verification function.

[0133] Referring back to FIG. 6 , next, when the detection unit 412 determines that the first distributed ledger has confirmed whether proof is recorded in the second distributed ledger when executing the proof verification function (Yes in S32), it determines whether authorization verification processing is performed before remittance (S33). Typically, when a smart contract is executed, the authorization verification processing is reliably performed, resulting in low vulnerability. However, in the case of a smart contract executed via a bridge server that can execute only some functions, vulnerability may arise due to the execution of only certain functions. Therefore, it is desirable for the smart contract to include code for performing authorization verification processing before a process such as remittance. The process of performing authorization verification before a process such as remittance is an example of a predetermined process (third process). The third process includes a process of verifying the authority of the executor who requested the token remittance. A token is an example of data.

[0134] Figure 9A shows a third example of vulnerable smart contract code. The smart contract shown in Figure 9A is a contract for executing a remittance process from an account specified in "from" to an account specified in "to." Figure 9A shows the code for the case where authorization verification is not performed before the remittance.

[0135] The token is implemented with the approval function of ERC20 (a standard for tokens that operate on Ethereum). In this case, if the authority to execute DApps (Decentralized Applications; in this embodiment, this means smart contracts) is inappropriate when a process such as remittance is executed between multiple different blockchain systems, problems may arise, such as the remittance function "transfer" being able to be executed without authorization, or the design being such that the remittance source entity (originally the entity specified by "address from") has already approved (i.e., approved the withdrawal of tokens). In this way, by using the approve function, the sending entity is authorized to withdraw a certain amount of tokens specified in advance. Therefore, if the authority of the smart contract is inappropriate (for example, if the sending entity is different from the entity indicated by the account attempting to execute the transfer process), anyone will be able to execute the function for transferring tokens, which could lead to the execution of fraudulent processes such as duplicate transfers.

[0136] The approve function allows a specific account (e.g., an account corresponding to the sender) to freely transfer its own tokens by specifying a certain amount in advance, and DApps is a general term for applications that run on a distributed ledger system.

[0137] For example, when a remittance process is executed, the remittance source entity must be the account holder of the account that is executing the remittance process. The account holder may be the manager of the smart contract or the account owner.

[0138] FIG. 9B is a diagram showing an example of smart contract code in which the vulnerability shown in FIG. 9A has been resolved.

[0139] In Figure 9B, the code has been modified so that the remittance is performed if the remittance is being executed by the owner, and the remittance process is not executed if the remittance is being executed by someone other than the owner (see lines 10 to 13, for example).

[0140] The detection unit 412 determines whether or not the smart contract contains code for determining whether an entity authorized to remit (e.g., the owner) is attempting to execute a remittance process, and determines that the smart contract has a vulnerability if the code does not contain the code, and determines that the smart contract does not have a vulnerability if the code contains the code. It can also be said that the detection unit 412 detects a vulnerability in the smart contract if the code does not contain processing for determining whether an entity authorized to remit is attempting to execute a remittance process.

[0141] Referring back to FIG. 6 , if the detection unit 412 determines that authorization verification processing is performed before remittance (Yes in S33), it next determines whether the type of the variable of the return value of the signature verification in the remittance blockchain system matches the type of the variable indicating the signature verification result in the remittance blockchain system (S34). Typically, blockchain systems are pre-configured to use specific variable types, so there is no need to determine the variable type when obtaining the signature verification result, resulting in low vulnerability. However, when processing is performed via a bridge server, vulnerabilities may arise due to differences in the signature verification type between the remittance blockchain system and the remittance blockchain system. For example, if the signature verification type of the remittance blockchain system differs from that of the remittance blockchain system, the remittance process may be performed without issue in the remittance blockchain system, but the deposit process may not be performed in the remittance blockchain system. Therefore, it is desirable for smart contracts to include code for verifying that the signature verification type of the remittance blockchain system matches that of the remittance blockchain system.

[0142] In step S34, the detection unit 412 determines whether the smart contract includes a process for determining whether the signature verification type of the remittance destination blockchain system matches the signature verification type of the remittance source blockchain system. The signature verification type refers to the type of the signature verification variable. An example of the variable type is Boolean, and an example of the return value is a Boolean variable when the variable type is Boolean, but the variable type and return value are not limited to this. The detection unit 412 acquires the type of the variable of the return value of the signature verification in the remittance destination blockchain system via the server 300, and determines whether the smart contract includes code for executing a process for determining whether the type of the variable acquired via the server 300 matches the type of the variable indicating the result of signature verification in the remittance source blockchain system. The process of confirming whether the type of the variable indicating the result of signature verification in the remittance source blockchain system matches the type of the variable of the return value of signature verification in the remittance destination blockchain system is an example of a predetermined process (fourth process).

[0143] Figure 10A shows a fourth example of vulnerable smart contract code. The smart contract shown in Figure 10A is a contract for executing a process to generate tokens equivalent to the amount specified in amount. Figure 10A can also be seen as code that could be used in a case where an attack is carried out because the signature verification of the signature included in the transaction is not properly processed when recording transaction data in the distributed ledger of the remittance destination.

[0144] The code shown in lines 3 to 5 of Figure 10A allows tokens to be generated even if the signature is invalid, and therefore the verify_signatures function does not properly verify the signature. This bypasses the authorization process and may allow an attacker to easily generate tokens.

[0145] FIG. 10B is a diagram showing an example of smart contract code in which the vulnerability shown in FIG. 10A has been resolved.

[0146] The code shown in FIG. 10B implements the logic for signature verification and token minting.

[0147] The detection unit 412 determines whether or not the smart contract contains code that determines whether the type of the variable of the return value of the signature verification in the blockchain system of the remittance destination matches the type of the variable indicating the result of the signature verification in the blockchain system of the remittance source, and determines that the smart contract has a vulnerability if the code does not contain such code, and determines that the smart contract does not have a vulnerability if the code contains such code.In other words, the detection unit 412 detects a vulnerability in the smart contract if the code does not contain processing for determining whether the variable types of the signature verification result match.

[0148] Referring again to Figure 6, next, if the detection unit 412 determines that it has confirmed whether the type of the variable of the return value of the signature verification of the blockchain system of the remitter matches the type of the variable indicating the signature verification result of the blockchain system of the remitter (Yes in S34), it determines whether it has confirmed whether the total amount of the amount received by the remitter from the remitter, the remaining amount remaining in the remitter after the remittance, and the usage fee for executing the smart contract matches the remaining amount of the remitter before the remitter performed the remittance process (S35).

[0149] A smart contract executed on a single blockchain transfers tokens from a sender's wallet to a recipient's wallet, both of which are part of the same blockchain system, uniquely determining the token payment amount and reducing vulnerability. However, when tokens are transferred between multiple blockchain systems, the amount of tokens in circulation changes, and the token market price may be intentionally altered accordingly, potentially creating vulnerabilities. Therefore, it is desirable for the smart contract to include code for verifying whether the total amount, including the amount received by the recipient from the sender, the amount received by the recipient from the sender, the remaining balance on the sender after the transfer, and the usage fee for executing the smart contract, matches the remaining balance on the sender before the sender performs the transfer process. This verification process is an example of a predetermined process (process number 5).

[0150] Note that a change in the token market price may mean that repeated transfers and withdrawals of tokens between the sender's blockchain system and the recipient's blockchain system cause a relative change in the circulation volume of two different types of tokens, resulting in a change in the exchange rate between the two types of tokens. For example, assume that the sender's blockchain system is the Bitcoin network, the recipient's blockchain system is the Ethereum network, and the recipient wishes to receive 10 ETCs from the sender. Also, assume that the exchange rate between Bitcoin and Ethereum at the time the sender processes the transfer is 1 BTC (BTC is the currency unit of Bitcoin) = 1 ETC (ETC is the currency unit of Ethereum), and that the sender holds 100 BTC. In this case, when the sender performs a remittance process to send 10 BTC to the recipient, the total amount (100 BTC) of the amount received by the recipient (10 ETC, i.e., 10 BTC) and the balance remaining in the sender after the remittance (90 BTC) matches the balance (100 BTC) of the sender before the sender performed the remittance process, so no problem occurs. However, if a malicious attacker sends a large amount of Ethereum from the recipient's blockchain system to another blockchain system during the remittance process, the amount of Ethereum in circulation will increase significantly, causing a sudden change in the exchange rate between Bitcoin and Ethereum (for example, 1 BTC = 2 ETC). As a result, the total amount (95 BTC) of the amount received by the recipient (10 ETC, or 5 BTC) and the balance remaining in the sender after the transfer (90 BTC) does not match the balance in the sender before the transfer process (100 BTC). In other words, an attacker could steal 5 BTC (or 10 ETC) by intentionally changing the exchange rate.

[0151] FIG. 11 shows an example of smart contract code that executes a remittance process, in this case, a remedied vulnerability. Because a usage fee is required to execute a smart contract, the payment amount, calculated by adding the usage fee to the remittance amount from the sender, should be greater than the deposit amount. However, if the payment amount matches the deposit amount, this means that the remittance process was not performed properly, and tokens may be stolen. The deposit amount refers to the amount of tokens equivalent to the remittance amount that is deposited from the sender's wallet to a wallet for temporary token management during the remittance process. The deposit amount is determined before the deposit process is executed in the recipient's blockchain system, so whether the remittance amount is greater than the deposit amount is determined before the deposit process is executed.

[0152] In Figure 11, as shown in the sixth line, a determination is made as to whether the payment amount (the part to the left of the inequality sign) is greater than the deposit amount (the part to the right of the inequality sign), and the remittance process is carried out only if the payment amount is greater than the deposit amount, so that the remittance process can be carried out appropriately.

[0153] The code with the sixth line deleted is vulnerable.

[0154] The detection unit 412 determines whether or not the smart contract contains code for determining whether the remitter's payment amount is greater than the deposit amount, and determines that the smart contract has a vulnerability if the code does not contain such code, and determines that the smart contract does not have a vulnerability if the code contains such code. In other words, the detection unit 412 detects a vulnerability in the smart contract if the code does not contain processing for determining whether the user's payment amount is greater than the deposit amount.

[0155] Referring back to FIG. 6 , next, if the detection unit 412 determines that the total amount of the amount received by the remitter from the remitter, the remaining balance remaining in the remitter after the remitter's remittance, and the usage fee for executing the smart contract matches the remaining balance of the remitter before the remitter performed the remittance process (Yes in S35), the detection unit 412 determines whether the smart contract includes a process for checking whether variables and addresses used in the smart contract have been initialized (S36). The variables may be any variables used during the execution of the smart contract, and may be addresses assigned to transactions such as remittances, or variables obtained by some kind of verification result (e.g., Boolean variables). Furthermore, if transaction data including a token remittance command has been acquired, the address may be an address indicating the user who sent the transaction data, or an address for the token remittance command.

[0156] For example, if a smart contract does not include code for initializing variables and addresses, the variables and addresses may not be initialized. Even if an abnormal process occurs due to uninitialized variables and addresses, a single blockchain system may not cause serious damage because it simultaneously performs processes related to authority verification, making it possible to detect an unauthorized executor attempting to execute the abnormal process. However, when a smart contract is executed via a bridge server, uninitialized variables and addresses may result in vulnerabilities. Therefore, it is desirable for a smart contract to include code for verifying whether variables and addresses are initialized. The process of verifying whether variables and addresses are initialized is an example of a predetermined process (sixth process).

[0157] FIG. 12A is a diagram showing a fifth example of code for a smart contract having a vulnerability.

[0158] In Figure 12A, the code on line 11 has an incorrect address set for the owner address (i.e., the address of the entity that wants to execute the remittance). Specifically, the owner address is "0x," and since no owner address is specified, it is a variable that indicates that the owner does not exist. Note that "0x" is an address that is set regardless of the owner address.

[0159] Also, the code in line 13 is such that the variable indicating whether transfer is possible is always true.

[0160] If such addresses and variables are not initialized after the execution of a smart contract, there is a risk that when the smart contract is executed again, the uninitialized variables and addresses will be referenced, resulting in an unauthorized process (such as a duplicate transfer). Note that initialization refers to the process of setting addresses and variables to preset values, and for example, if the preset value for the address of the owner of the smart contract is the address of the owner of the smart contract, then after the smart contract is executed, the owner's address may be set to the address of the owner of the smart contract, but this is not limiting.

[0161] FIG. 12B is a diagram illustrating an example of smart contract code in which the vulnerability illustrated in FIG. 12A has been resolved.

[0162] As shown in lines 16, 17, 20, and 21 of FIG. 12B, code is included that determines whether or not to allow a transfer depending on whether or not a Boolean variable has been initialized.

[0163] The detection unit 412 determines whether the code for determining whether variables and addresses are initialized is included, and determines that the smart contract has a vulnerability if the code does not include the code, and determines that the smart contract does not have a vulnerability if the code includes the code. It can also be said that the detection unit 412 detects a vulnerability in a smart contract if the code does not include processing for determining whether variables and addresses are initialized. Note that the detection unit 412 may also determine whether at least one of the variables and addresses is initialized.

[0164] 6 again, when the detection unit 412 determines that the smart contract includes a process for checking whether the variables and addresses used in the smart contract have been initialized (Yes in S36), it determines that the smart contract has no vulnerability (S37). Furthermore, when the detection unit 412 determines that a process for checking the authority of the executor who executes the smart contract has not been performed before changing the owner of the smart contract to another entity (No in S31), when the detection unit 412 determines that a check has not been made to see whether the proof is recorded in the first distributed ledger or the second distributed ledger when executing the proof verification function (No in S32), when the detection unit 412 determines that a process for checking the authority has not been performed before remittance (No in S33), or when the type of the variable of the return value of the signature verification in the blockchain system of the remittance destination matches the type of the variable indicating the signature verification result in the blockchain system of the remittance source. If it is determined that the recipient has not confirmed whether the remittance destination has received the remittance from the remitter (No in S34), if it is determined that the total amount of the amount received by the remitter from the remitter, the remaining balance remaining in the remitter after the remittance, and the usage fee for executing the smart contract does not match the remaining balance in the remitter before the remitter performed the remittance process (No in S35), or if it is determined that the smart contract does not include a process for checking whether the variables and addresses used in the smart contract have been initialized (No in S36), then it is determined that the smart contract has a vulnerability (S38). In other words, if the smart contract does not include code for executing any of the first to sixth processes, a vulnerability in the smart contract is detected.

[0165] In this way, since the smart contract code is used to detect vulnerabilities, it is possible to detect vulnerabilities in the smart contract without relying on the occurrence of an event and even if the smart contract is not deployed to the distributed ledger system. Furthermore, as shown in the above determinations, the detection unit 412 can also be said to detect vulnerabilities in the smart contract by performing pattern matching (e.g., pattern matching of logical meaning) on ​​the processing content of the smart contract code.

[0166] Note that the information processing device 400 executes the process shown in Figure 6 for smart contracts in both the first distributed ledger system 100 and the second distributed ledger system 200 (e.g., both the sender and receiver in a remittance transaction), but it may also execute the process shown in Figure 6 for, for example, one of the first distributed ledger system 100 and the second distributed ledger system 200. Furthermore, the information processing device 400 executes the process shown in Figure 6 individually for each smart contract.

[0167] Next, we will explain the data structure of a distributed ledger, the execution of smart contracts, and the data structure of NFTs with reference to Figures 13 to 17.

[0168] FIG. 13 is an explanatory diagram showing the data structure of a blockchain, which is an example of a distributed ledger.

[0169] A blockchain is a chain of blocks, which are units of record. Each block contains multiple transaction data and the hash value of the previous block.

[0170] FIG. 13 shows blocks B1, B2, and B3 included in the blockchain.

[0171] For example, block B2 contains the hash value of the previous block B1, which is calculated by performing a hash algorithm on the contents of block B1.

[0172] Furthermore, block B3 includes, as the hash value of block B2, a hash value calculated from multiple transaction data included in block B2 and the hash value of block B1.

[0173] In this way, a blockchain is structured so that blocks containing the contents of the previous block as a hash value are connected in a chain, which effectively prevents tampering with the recorded transaction data.

[0174] If past transaction data is changed (in other words, tampered with), the hash value of the block containing that transaction data will be different from the value before the change. In that case, to make the block containing the changed transaction data appear correct, all blocks after that block in the distributed ledger stored on multiple servers would have to be recreated, which is extremely difficult in reality. This feature makes it virtually impossible to tamper with transaction data contained in the blockchain.

[0175] When a node stores transaction data in a blockchain, it generates a block containing the transaction data to be stored and attempts to reach consensus on the generated block by executing processing based on a consensus algorithm with other nodes. Then, when consensus is reached, the node controls the storage of the block in the blockchain. This allows multiple nodes operating in an autonomous and decentralized manner to connect legitimate blocks to the blockchain. As a consensus algorithm, PBFT (Practical Byzantine Fault Tolerance), PoW (Proof of Work), PoS (Proof of Stake), or the like may be used. When Hyperledger Fabric is used as an example of a distributed ledger technology, a consensus algorithm does not need to be executed.

[0176] FIG. 14 is an explanatory diagram showing the data structure of transaction data.

[0177] 14 includes a transaction body BP1 and a digital signature BP2 (also simply referred to as a signature). The transaction body BP1 is the data body included in the transaction data. The digital signature BP2 is generated by encrypting the hash value of the transaction body BP1 with the signature key (in other words, the private key) of the creator of the transaction data.

[0178] A node that receives transaction data can verify that the transaction body BP1 is legitimate (in other words, that it has not been tampered with) using the digital signature BP2 included in the transaction data. This makes it virtually impossible to tamper with the data included in the transaction body BP1. Furthermore, by storing successfully verified transaction data in the blockchain, the legitimacy of the transaction data stored in the blockchain can be maintained.

[0179] As described above, transaction data included in the blockchain is stored in a chain using the hash values ​​of the transaction data and the hash values ​​of the blocks. This allows the transaction data included in the blockchain to be stored and maintained substantially without being tampered with. This is an advantage over a database or a distributed database that simply stores a collection of data.

[0180] Fig. 15 is an explanatory diagram showing transaction data related to the execution of a smart contract. Fig. 16 is a flow diagram showing processing (information processing method) related to the execution of a smart contract.

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

[0182] 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.

[0183] 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.

[0184] 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.

[0185] Through the above series of processes, when the 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.

[0186] FIG. 17 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.

[0187] 17 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).

[0188] 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.

[0189] 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.

[0190] (Other Embodiments) While the information processing method according to one or more aspects has been described above based on the embodiments, the present disclosure is not limited to these embodiments. As long as it does not deviate from the spirit of the present disclosure, various modifications conceivable by a person skilled in the art to the present embodiments and embodiments constructed by combining components of different embodiments may also be included in the present disclosure.

[0191] For example, although the above embodiment uses a blockchain, it is not necessary to use a blockchain. Also, instead of a blockchain, a distributed ledger technology such as a hash graph may be used.

[0192] Furthermore, 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 in the RAM or hard disk unit. Each device achieves its function when the microprocessor operates in accordance with the computer program. Here, a computer program is composed of a combination of multiple instruction codes that indicate instructions to a computer to achieve a predetermined function.

[0193] In addition, some or all of the constituent elements of each device in the above embodiments may be configured from a single 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. Furthermore, each component of each device may be individually integrated into a single chip, or some or all of the components may be integrated into a single chip. Here, the term system LSI is used, but it may also be called an IC, LSI, super LSI, or ultra LSI depending on the degree of integration.

[0194] The present disclosure may also be embodied as the methods described above. Furthermore, the present disclosure may also be embodied as a computer program that implements these methods on a computer, or as a digital signal comprising the computer program. For example, one aspect of the present disclosure may be a computer program that causes a computer to execute each of the characteristic steps included in the information processing method shown in any of Figures 4, 6, and 16.

[0195] 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, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray (registered trademark) Disc), semiconductor memory, or the like. It may also be a digital signal recorded on such a recording medium. The present disclosure may also be a computer program or a digital signal transmitted via a telecommunications line, a wireless or wired communication line, a network such as the Internet, data broadcasting, or the like.

[0196] The present disclosure may also be 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.

[0197] Furthermore, the program or digital signal may be recorded on a recording medium and transferred, or the program or digital signal may be transferred via a network or the like, so that the program or digital signal may be implemented by another independent computer system.

[0198] In the above embodiments, each component may be configured with dedicated hardware, or may be realized by executing a software program suitable for each component. Each component may be realized by a program execution unit such as a CPU or processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory.

[0199] The order in which the steps in the flowchart are executed is merely an example for specifically explaining the present disclosure, and other orders may be used. Some of the steps may be executed simultaneously (in parallel) with other steps, or some of the steps may not be executed.

[0200] The division of functional blocks in the block diagram is an example, and multiple functional blocks may be realized as a single functional block, one functional block may be divided into multiple blocks, or some functions may be moved to another functional block.Furthermore, the functions of multiple functional blocks having similar functions may be processed in parallel or in time-sharing by a single piece of hardware or software.

[0201] Furthermore, each of the information processing devices according to the above embodiments may be realized as a single device or may be realized by multiple devices. When an information processing device is realized by multiple devices, the components of the information processing device may be distributed among the multiple devices in any manner. When the information processing device is realized by multiple devices, the communication method between the multiple devices is not particularly limited, and may be wireless communication or wired communication. Furthermore, wireless communication and wired communication may be combined between the devices.

[0202] This disclosure is applicable to systems with multiple distributed ledgers.

[0203] 10 Information processing system 100 First distributed ledger system 100a, 100b, 100c, 200a, 200b, 200c Ledger server 101a, 101b, 101c, 201a, 201b, 201c, B22 Storage device 111, 311 Communication unit 112 Ledger management unit 113, 312 Execution unit 114, 413 Storage unit 114a, B10 Distributed ledger 200 Second distributed ledger system 300 Server (device) 400 Information processing device 411 Acquisition unit 412 Detection unit 414 Output unit B1, B2, B3 Block B11, B15, B21 Transaction data B12 Contract code B16 Instruction BP1 Transaction body BP2 Digital signature

Claims

1. An information processing method executed in an information processing system including a device that transfers data from a first distributed ledger system to a second distributed ledger system different from the first distributed ledger system, the information processing method comprising: obtaining code included in a smart contract that is executed when the device transfers data from the first distributed ledger system to the second distributed ledger system; detecting vulnerabilities in the smart contract based on whether the code includes code that executes a specified process; and outputting the detection result of the vulnerability in the smart contract.

2. The information processing method according to claim 1, wherein the predetermined processing includes a first processing step of confirming the authority of an executor who has requested a change when changing the owner of the smart contract, and a vulnerability in the smart contract is detected if the code does not include code for executing the first processing step.

3. The information processing method according to claim 2, wherein the detection of vulnerabilities based on whether or not the code that executes the specified process is performed by converting the structure of the acquired code into a syntax tree, which is a hierarchical tree structure, and using the converted syntax tree.

4. The information processing method according to claim 2, wherein the detection of vulnerabilities based on whether or not the code that executes the specified processing is performed by converting the acquired code into an expression using a mathematical formula and executing the converted mathematical formula.

5. The information processing method of claim 1, wherein the predetermined processing includes a second processing step of determining whether or not proof is recorded in the first distributed ledger system or the second distributed ledger system when executing a proof verification function in a consensus algorithm, and a vulnerability in the smart contract is detected if it is determined that the code does not include code for executing the second processing step.

6. The information processing method according to claim 1, wherein the smart contract has a function of performing a remittance process, the data is a token, the predetermined process includes a third process of verifying the authority of an executor who has requested the remittance of the token, and if the code does not include code for executing the third process, a vulnerability in the smart contract is detected.

7. The information processing method of claim 1, wherein the predetermined processing includes a fourth processing step of checking whether the type of a variable of the return value of the signature verification in the second distributed ledger system matches the type of a variable indicating the result of the signature verification in the first distributed ledger system, and a vulnerability in the smart contract is detected if the code does not include code for executing the fourth processing step.

8. The information processing method according to claim 1, wherein the smart contract has a function of performing a remittance process, and the predetermined process includes a fifth process of confirming whether the total amount of the amount received by the remittance destination from the remitter, the remaining amount remaining in the remitter after the remittance, and the usage fee for executing the smart contract matches the remaining amount in the remitter before the remitter performs the remittance process, and a vulnerability in the smart contract is detected if the code does not include code for executing the fifth process.

9. The information processing method according to claim 1, wherein the predetermined processing includes a sixth processing step of checking whether at least one of a variable and an address used in the smart contract has been initialized, and if the code does not include code for executing the sixth processing step, a vulnerability in the smart contract is detected.

10. An information processing method according to any one of claims 1 to 9, wherein the detection result includes information indicating that a vulnerability has been detected in the smart contract.

11. The information processing method according to any one of claims 1 to 9, wherein the detection result includes code in the smart contract in which a vulnerability has been detected, and the code in which a vulnerability has been detected is presented to a user.

12. An information processing device in an information processing system including a device for transferring data from a first distributed ledger system to a second distributed ledger system different from the first distributed ledger system, the information processing device comprising: an acquisition unit that acquires code included in a smart contract that is executed when transferring data from the first distributed ledger system to the second distributed ledger system; a detection unit that detects vulnerabilities in the smart contract based on whether the code includes code that executes a specified process; and an output unit that outputs the detection result of the vulnerability of the smart contract.

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

Images