Program, information processing method and information processing unit

Abstract

To provide a program etc., capable of displaying a list of a plurality of functions in a smart contract.SOLUTION: A program according to one aspect causes a computer to execute processing to acquire code information related to a code of a smart contract, and list and display requests of a plurality of functions in the smart contract and data formats of responses corresponding to the requests. Consequently, the plurality of functions in the smart contract can be listed and displayed.SELECTED DRAWING: Figure 1

Description

[Technical Field]

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

[0002] In recent years, there has been active development of technologies related to smart contracts in blockchain networks. For example, Patent Document 1 discloses a computer-implemented method for supporting smart contracts in a blockchain network. [Prior art documents] [Patent documents]

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

[0004] However, the invention of Patent Document 1 has a problem in that it is not possible to display a list of multiple functions in a smart contract.

[0005] One aspect is to provide a program or the like that can display a list of multiple functions in a smart contract. [Means for solving the problem]

[0006] A program according to one aspect acquires code information relating to the code of a smart contract, and causes a computer to execute a process of displaying a list of requests for multiple functions in the smart contract and the data formats of the responses corresponding to the requests, based on the acquired code information. [Effects of the Invention]

[0007] In one aspect, it allows listing multiple functions in a smart contract. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is an explanatory diagram showing an overview of a smart contract management system. [Figure 2] FIG. 2 is a block diagram illustrating an example of the configuration of a server. [Figure 3] 10A and 10B are explanatory diagrams showing examples of record layouts of a network management DB and a code information DB. [Figure 4] FIG. 2 is a block diagram illustrating an example of the configuration of a terminal. [Figure 5] FIG. 1 is an explanatory diagram illustrating the operation of a smart contract management system. [Figure 6] FIG. 10 is an explanatory diagram illustrating an example of a blockchain selection acceptance screen. [Figure 7] FIG. 10 is an explanatory diagram showing an example of a list display screen that displays a list of data formats of requests and responses. [Figure 8] FIG. 10 is an explanatory diagram showing an example of a display screen of a transaction corresponding to a request for a reading function. [Figure 9] FIG. 10 is an explanatory diagram showing an example of a display screen of a transaction corresponding to a request for a write function. [Figure 10] FIG. 10 is an explanatory diagram illustrating an example of a display screen of a transaction corresponding to a function request in an event. [Figure 11] 10 is a flowchart showing the processing steps for displaying a list of multiple functions in a smart contract. [Figure 12] 10 is a flowchart showing a processing procedure for displaying a transaction corresponding to a function request. [Figure 13] FIG. 10 is a block diagram showing an example of the configuration of a server in the second embodiment. [Figure 14] FIG. 10 is an explanatory diagram showing an example of the record layout of a monitor management DB and a remittance log DB. [Figure 15]FIG. 10 is an explanatory diagram illustrating a process of storing a request and a response. [Figure 16] FIG. 10 is an explanatory diagram showing an example of a monitor list display screen. [Figure 17] FIG. 10 is an explanatory diagram illustrating an example of a response display screen corresponding to a function request. [Figure 18] 10 is a flowchart showing a processing procedure for storing a request and a response. [Figure 19] 10 is a flowchart showing a processing procedure when outputting a response according to a smart contract. [Figure 20] FIG. 11 is a block diagram showing an example of the configuration of a server in the third embodiment. [Figure 21] FIG. 10 is an explanatory diagram showing an example of the record layout of a wallet DB and a balance log DB. DETAILED DESCRIPTION OF THE INVENTION

[0009] The present invention will be described in detail below with reference to the drawings showing embodiments thereof.

[0010] (Embodiment 1) Embodiment 1 relates to a form in which a list of multiple functions in a smart contract is displayed based on code information related to the code of the smart contract.

[0011] 1 is an explanatory diagram showing an overview of a smart contract management system. The system of this embodiment includes an information processing device 1, an information processing terminal 2, and multiple blockchain networks 3, and each device transmits and receives information via a network N such as the Internet.

[0012] The information processing device 1 is an information processing device that processes, stores, and transmits / receives various types of information. The information processing device 1 is, for example, a server device or a personal computer. In the present embodiment, the information processing device 1 will be hereinafter referred to as a server 1 for the sake of simplicity.

[0013] The information processing terminal 2 is a terminal device that receives and displays multiple functions in a smart contract. The information processing terminal 2 is an information processing device such as a personal computer terminal, a tablet, a smartphone, a mobile phone, or a wearable device such as a smart watch. For simplicity, the information processing terminal 2 will be referred to as terminal 2 below.

[0014] The blockchain network 3 is a distributed ledger technology or a distributed network. The blockchain network 3 is composed of multiple nodes 31 that execute consensus processing. Note that while FIG. 1 shows an example in which the blockchain network 3 is composed of five nodes 31, it may be composed of an appropriate number of nodes depending on the consensus algorithm or the number of network participants.

[0015] Each node 31 holds a copy of the blockchain data through the execution of the consensus process. The blockchain network 3 generates units of data called blocks at regular intervals and stores data by linking them together like a chain.

[0016] The blockchain network 3 is managed autonomously using a peer-to-peer network and a distributed timestamp server. Because it is stored in a chain, once data in a block is stored, it is difficult to retroactively change that data. The blockchain network 3 may be public, private, or consortium type. The unit of data may be individual transactions rather than blocks. Furthermore, data may be stored in a format other than a chain, such as a directed acyclic graph. For simplicity, the blockchain network 3 will be referred to as blockchain 3 below.

[0017] The code of a smart contract deployed to the blockchain 3 is written in bytecode format. However, because the contract code written in bytecode format is difficult to read, it is difficult to track the state of the smart contract or check its history. In this embodiment, a smart contract management system is provided that can visualize the code of a smart contract, thereby solving the above-mentioned problem.

[0018] The server 1 according to this embodiment acquires code information related to the code of a smart contract. The server 1 transmits the acquired code information to the terminal 2. Based on the code information transmitted from the server 1, the terminal 2 displays a list of requests for multiple functions in the smart contract and the data formats of the responses corresponding to the requests.

[0019] 2 is a block diagram showing an example of the configuration of the server 1. The server 1 includes a control unit 11, a storage unit 12, a communication unit 13, a reading unit 14, and a large-capacity storage unit 15. Each component is connected by a bus B.

[0020] The control unit 11 includes an arithmetic processing device such as a CPU (Central Processing Unit), an MPU (Micro-Processing Unit), a GPU (Graphics Processing Unit), an FPGA (Field Programmable Gate Array), a DSP (Digital Signal Processor), or a quantum processor. The control unit 11 reads and executes a control program 1P (program product) stored in the storage unit 12, thereby performing various information processing, control processing, and the like related to the server 1.

[0021] It should be noted that the control program 1P can be deployed to run on a single computer, or on multiple computers located at one site, or distributed across multiple sites and interconnected by a communications network.

[0022] 2, the control unit 11 is described as a single processor, but it may be a multi-processor. The control unit 11 may execute various information processes or control processes by the same processor within the server 1, or may execute various processes by different processors within the server 1.

[0023] The storage unit 12 includes memory elements such as RAM (Random Access Memory) and ROM (Read Only Memory), and stores the control program 1P or data required for the control unit 11 to execute processing. The storage unit 12 also temporarily stores data required for the control unit 11 to execute arithmetic processing. The communication unit 13 is a communication module for performing communication-related processing, and transmits and receives information to and from the terminal 2, etc. via the network N.

[0024] The reading unit 14 reads a portable storage medium 1a including a CD (Compact Disc)-ROM or a DVD (Digital Versatile Disc)-ROM. The control unit 11 may read the control program 1P from the portable storage medium 1a via the reading unit 14 and store it in the mass storage unit 15. Alternatively, the control unit 11 may download the control program 1P from another computer via a network N or the like and store it in the mass storage unit 15. Furthermore, the control unit 11 may read the control program 1P from the semiconductor memory 1b.

[0025] The mass storage unit 15 includes a recording medium such as an HDD (Hard disk drive) or an SSD (Solid State Drive). The mass storage unit 15 includes a network management database (DB) 151 and a code information DB 152. The network management DB 151 stores management information for multiple blockchains 3. The code information DB 152 stores code information related to the code of smart contracts.

[0026] In this embodiment, the storage unit 12 and the large-capacity storage unit 15 may be configured as an integrated storage device. Furthermore, the large-capacity storage unit 15 may be configured by a plurality of storage devices. Furthermore, the large-capacity storage unit 15 may be an external storage device connected to the server 1.

[0027] The server 1 may execute various information processing and control processing on a single computer, or may execute the processing in a distributed manner on multiple computers. The server 1 may also be realized by multiple virtual machines provided in a single server, or may be realized by using a cloud server.

[0028] FIG. 3 is an explanatory diagram showing an example of the record layout of the network management DB 151 and the code information DB 152. As shown in FIG. The network management DB 151 includes a network ID column, a network name column, a contract name column, an address column, a function number column, a monitor number column, and a developer wallet number column. The network ID column stores the network ID of the blockchain 3 that is uniquely specified to identify each blockchain 3. The network name column stores the name of the blockchain 3.

[0029] The contract name string stores the name of the smart contract deployed on the blockchain 3. A smart contract is a program that runs at a specific address on the blockchain 3 and is composed of data and functions that can be executed when a transaction is received. A smart contract is a self-executing contract, and the code for the smart contract resides on the blockchain 3 and is automatically executed when a transaction is sent.

[0030] The Address column stores the contract address (contract account) of the smart contract. The smart contract address serves as a unique identifier for the smart contract and is used by users to interact with the smart contract. It is generated when the smart contract is deployed.

[0031] The function sequence stores the number of functions. Functions will be described later. The monitor sequence stores the number of monitors. A monitor is a monitoring device that registers smart contracts to be monitored. By periodically sending specific requests to smart contracts registered in a monitor, it is possible to receive and store responses from the smart contracts, or send alert notifications based on the responses. Monitors will be described later in embodiment 2. The developer wallet sequence stores the number of developer wallets that have the authority to deploy smart contracts.

[0032] The code information DB152 includes a network ID column, a contract name column, a category column, a request column, a function name column, a data format column, and a description column. The network ID column stores a network ID that identifies the blockchain 3. The contract name column stores the name of the smart contract deployed to the blockchain 3. The category column stores categories classified by function type. The categories include read functions, write functions, and events.

[0033] The read function is used to obtain the state of data recorded in blockchain 3. The read function can obtain information without issuing a transaction, so it is used for operations that do not change the state of blockchain 3.

[0034] The read function includes, for example, name, symbol, or maxSupply. name is a function that gets the name of the token. symbol is a function that gets the symbol of the token. Symbols are important data types that have uniqueness and immutability, and are used to safely identify the properties of objects. maxSupply is a function that gets the maximum amount that a token can issue.

[0035] Write functions are used to change (update) the state on the blockchain 3. Write functions are used to issue transactions and update or create new data, for example, transferring funds, updating data, or creating new contracts. Write functions include, for example, airdrop, ALmint, or approve. Airdrop is a function that sends tokens en masse to a list of wallet addresses. ALmint is a function that issues tokens. Approve is a function that approves tokens.

[0036] Events are used to record important actions or state changes, allowing for tracking important actions on the blockchain and enabling collaboration with external applications. For example, when the Approve function is called, a smart contract will emit an Approve event.

[0037] The request column stores function requests. Requests include read (View), write (Write), and event (Event), etc. The function name column stores the name of the function. The data format column stores the type of response data corresponding to the function request. The response data is the data returned when the function is executed. The description column stores a description of the read function, write function, or event.

[0038] The storage format of each DB described above is an example, and other storage formats may be used as long as the relationships between the data are maintained.

[0039] 4 is a block diagram showing an example of the configuration of the terminal 2. The terminal 2 includes a control unit 21, a storage unit 22, a communication unit 23, an input unit 24, and a display unit 25. Each component is connected by a bus B.

[0040] The control unit 21 includes a processing unit such as a CPU or an MPU, and performs various information processing and control processing related to the terminal 2 by reading and executing a control program 2P (program product) stored in the storage unit 22.

[0041] 4, the control unit 21 is described as a single processor, but it may be a multi-processor. The control unit 21 may execute various information processing or control processes by the same processor within the terminal 2, or may execute various information processing or control processes by different processors within the terminal 2.

[0042] The storage unit 22 includes memory elements such as RAM and ROM, and stores the control program 2P or data required for the control unit 21 to execute processing. The storage unit 22 also temporarily stores data required for the control unit 21 to execute arithmetic processing.

[0043] The communication unit 23 is a communication module for performing communication-related processing, and transmits and receives information to and from the server 1, etc. via the network N. The input unit 24 may be a keyboard, a mouse, or a touch panel integrated with the display unit 25. The display unit 25 is a liquid crystal display, an organic EL (electroluminescence) display, or the like, and displays various information according to instructions from the control unit 21.

[0044] Figure 5 is an explanatory diagram illustrating the operation of a smart contract management system. A server 1 deploys smart contract code to multiple different blockchains 3. Blockchains 3 include, for example, Numbai, Sepolia, Bitcoin (registered trademark), or Ethereum (registered trademark). When a smart contract is deployed, an ABI (Application Binary Interface) is automatically registered (generated).

[0045] The ABI (blueprint data) of a deployed smart contract is the interface for communication between the smart contract and external applications, etc. The ABI is an interface that compiles information necessary for calling smart contract functions, retrieving variables, or monitoring events.

[0046] Registering an ABI allows you to extract logic from smart contract code. Logic describes how a program operates. Smart contract logic can include conditional branching (If / Else), variable or state management, transaction processing, event firing, or error handling.

[0047] Management information for each blockchain 3 to which the blockchain is deployed is stored in the network management DB 151 of the server 1. The management information includes a network ID, a network name, a contract name, a contract address, the number of functions, the number of monitors, or the number of developer wallets.

[0048] The server 1 also stores code information about the code of the smart contract deployed to each blockchain 3 in the code information DB 152. The code information includes a category (read function, write function, or event), a function request, a function name, a data format of a response corresponding to the request, or a function description.

[0049] The terminal 2 acquires code information related to the code of the smart contract deployed in each blockchain 3 from the code information DB 152 of the server 1. Based on the acquired code information, the terminal 2 displays a list display screen (FIG. 7) for displaying a list of requests for multiple functions in the smart contract and the data formats of the responses corresponding to the requests.

[0050] When the terminal 2 receives a request to call a transaction for a specific function request on the list display screen, it obtains a transaction (response) corresponding to the request for the function from the corresponding blockchain 3.

[0051] Specifically, the terminal 2 acquires the contract address of the smart contract from the network management DB 151 of the server 1 based on the network ID and the name of the smart contract. The terminal 2 sends request information to the corresponding blockchain 3. The request information includes the network ID, contract address, request (View, Write, or Event), or function name, etc.

[0052] Based on the request information sent from terminal 2, blockchain 3 obtains the transaction corresponding to the read function request from the ABI generated when the smart contract code is deployed. Blockchain 3 sends the obtained transaction to terminal 2. Terminal 2 receives the transaction sent from blockchain 3 and displays it on the screen. Details of the transaction will be described later with reference to Figures 8 to 10.

[0053] 6 is an explanatory diagram showing an example of a selection acceptance screen of the blockchain 3. The screen includes a management information display field 11a and a network selection button 11b.

[0054] The management information display field 11a is a display field that displays management information of the blockchain 3. The management information includes the network name of the blockchain 3, the name of the smart contract deployed to the blockchain 3, the number of functions, the number of monitors, or the number of developer wallets, etc. The network selection button 11b is a button that accepts the selection of the blockchain 3.

[0055] Based on the network ID, the server 1 acquires management information (network name, smart contract name, number of functions, number of monitors, number of developer wallets, etc.) for multiple blockchains 3 from the network management DB 151. The server 1 transmits the acquired management information for multiple blockchains 3 to the terminal 2.

[0056] The terminal 2 receives the management information sent from the server 1 and displays the received management information in the management information display field 11a. As shown in the figure, the management information display field 11a displays the network name of each blockchain 3, the name of the smart contract, the number of functions, the number of monitors, and the number of developer wallets.

[0057] When the terminal 2 receives a touch (click) operation on the network selection button 11b, it acquires the network ID and the name of the smart contract of the selected blockchain 3. The terminal 2 passes the acquired network ID and the name of the smart contract to the list display screen (Fig. 7) and transitions to the list display screen.

[0058] 7 is an explanatory diagram showing an example of a list display screen that displays a list of data formats of requests and responses. The list display screen includes a read function display field 12a, a write function display field 12b, and an event display field 12c. The read function display field 12a is a display field that displays read functions including name, symbol, maxSupply, etc. The write function display field 12b is a display field that displays write functions including airdrop, ALmint, approve, etc. The event display field 12c is a display field that displays an event issued by a smart contract when a function is called.

[0059] Furthermore, the read function display field 12a, the write function display field 12b, and the event display field 12c each include a function name display field 12d, a data format display field 12e, a description display field 12f, and an edit button 12g. The function name display field 12d is a display field that displays a function request. The data format display field 12e is a display field that displays the data format of a response corresponding to a function request. The description display field 12f is a display field that displays a description of the function. The edit button 12g is a button for accepting editing of the description.

[0060] The read function display field 12a includes a read request button (View) 12h, the write function display field 12b includes a write request button (Write) 12i, and the event display field 12c includes an event request button (Event) 12j.

[0061] The read request button 12h is a button for accepting a request to call a transaction corresponding to a request for a read function. The write request button 12i is a button for accepting a request to call a transaction corresponding to a request for a write function. The event request button 12j is a button for accepting a request to call a transaction corresponding to a request for a function in an event.

[0062] The server 1 acquires code information related to the code of the smart contract based on the network ID and the name of the smart contract passed from the selection reception screen (Fig. 6) of the blockchain 3. Specifically, the server 1 acquires from the code information DB 152, for each category (read function, write function, or event), the requests of the corresponding multiple functions, the function names, the data format of the response corresponding to the request, or a function description, etc., based on the network ID and the name of the smart contract.

[0063] In this embodiment, an example of smart contract code will be described, but the present invention is not limited to this and may be compiled data of a smart contract.

[0064] Server 1 transmits the acquired code information to Terminal 2. Terminal 2 receives the code information transmitted from Server 1. Based on the received code information, Terminal 2 displays a list of requests for multiple functions in the smart contract, function names, response data formats corresponding to the requests, or function descriptions.

[0065] Specifically, the terminal 2 displays the code information for each category transmitted from the server 1 in the reading function display field 12a, the writing function display field 12b, and the event display field 12c.

[0066] As shown in the figure, the reading function display field 12a displays a reading function request including name, symbol, maxSupply, etc., the function name, the data format of the response corresponding to the request (e.g., string or uint256), a description (e.g., "Name of this NFT"), and an edit button 12g.

[0067] In addition, the write function display field 12b displays write function requests including airdrop, ALmint, and approve, the function name, the data format of the response corresponding to the request (e.g., Boolean), a description (e.g., "mint & transfer NFTs"), and an edit button 12g.

[0068] In addition, when a function including Approve, ApproveForAll, Transfer, etc. is called, the event display column 12c displays the function request in the event issued by the smart contract, the function name, the data format of the response corresponding to the request (e.g., (address, address, uint256)), a description (e.g., "Events emitted when approve function succeeds"), and an edit button 12g.

[0069] When the terminal 2 receives a touch (click) operation on the edit button 12g, it accepts editing of the explanation for the corresponding function. The terminal 2 transmits the edited explanation to the server 1, associating it with the network ID, smart contract name, and function name. The server 1 receives the network ID, smart contract name, function name, and edited explanation transmitted from the terminal 2. The server 1 updates (stores) the edited explanation in the code information DB 152, associating it with the received network ID, smart contract name, and function name.

[0070] When the terminal 2 receives a touch operation on the read request button 12h corresponding to the read function, the terminal 2 transitions to a display screen (FIG. 8) of a transaction corresponding to the request for the read function.

[0071] When the terminal 2 receives a touch operation on the write request button 12i corresponding to the write function, the terminal 2 transitions to a display screen (FIG. 9) of a transaction corresponding to the request for the write function.

[0072] When the terminal 2 receives a touch operation on the event request button 12j corresponding to an event, the terminal 2 transitions to a display screen (FIG. 10) of a transaction corresponding to a request for a function in the event.

[0073] Figure 8 is an explanatory diagram showing an example of a display screen for a transaction corresponding to a request for the reading function. Note that the same reference numerals are used to designate the same content as in Figure 7, and the description thereof will be omitted. This screen includes a parameter setting field 13a, a transaction display field 13b, and a transaction acquisition (Try Now) button 13c.

[0074] The parameter setting field 13a is a setting field that accepts the setting of function parameters. If there are no parameters for the function, the parameter setting field 13a may be left blank. The transaction display field 13b is a display field that displays a transaction corresponding to a function request. The transaction acquisition button 13c is a button for acquiring a transaction corresponding to a function request.

[0075] When the terminal 2 receives a touch operation on the transaction acquisition button 13c corresponding to the target reading function (for example, "maxSupply"), it acquires a transaction corresponding to the request for the reading function from the corresponding blockchain 3.

[0076] Specifically, based on the network ID and the name of the smart contract, the terminal 2 obtains the contract address of the smart contract from the network management DB 151 of the server 1. The terminal 2 transmits the network ID, the contract address, and the function name of the reading function to the corresponding blockchain 3.

[0077] The blockchain 3 obtains the transaction corresponding to the read function request from the ABI generated when the smart contract code is deployed, based on the network ID, contract address, and function name sent from the terminal 2. For example, the obtained transaction is "3000."

[0078] The blockchain 3 transmits the acquired transaction to the terminal 2. The terminal 2 receives the transaction transmitted from the blockchain 3. The terminal 2 displays the received transaction in the transaction display field 13b.

[0079] Figure 9 is an explanatory diagram showing an example of a display screen for a transaction corresponding to a request for the write function. Note that the same reference numerals are used to designate the same content as in Figure 8, and the description thereof will be omitted. The parameter setting field 13a on this screen includes a setting field for parameters provided according to the function.

[0080] As an example, the parameters for the write function "approve" include a first parameter (to) and a second parameter (tokenId). The first parameter is a parameter for specifying the address to receive the token, and its data format is "address." The second parameter is the identifier (token ID) of the token to be transferred, and its data format is "unit256."

[0081] Although FIG. 9 illustrates an example of the write function "approve," the same can be applied to other write functions.

[0082] As shown in the figure, the parameter setting field 13a includes a first parameter setting field 13d, a second parameter setting field 13e, a parameter array setting field 13f, and an add button 13g. The first parameter setting field 13d is a setting field that accepts the setting of the first parameter (to) of the "approve" function. The second parameter setting field 13e is a setting field that accepts the setting of the second parameter (tokenId) of the "approve" function.

[0083] The parameter array setting field 13f is a setting field that accepts the setting of parameters (for example, first and second parameters) in an array (list) format. The add button 13g is a button that adds a parameter of the function to the parameter array.

[0084] When the terminal 2 receives a setting operation for the first parameter setting field 13d, it acquires the set first parameter (for example, "to"). When the terminal 2 receives a setting operation for the second parameter setting field 13e, it acquires the set second parameter (for example, "tokenId").

[0085] Alternatively, when the terminal 2 receives a setting operation for the parameter array setting field 13f, it acquires the parameter settings in an array format. When the terminal 2 receives a touch operation for the add button 13g, it adds a parameter setting field including the first parameter and the second parameter to the parameter array setting field 13f.

[0086] When the terminal 2 receives a touch operation of the transaction acquisition (Try Now) button 13c, Wallet Connect is launched. Wallet Connect is a protocol (communication protocol) for connecting a wallet app on a virtual currency (crypto asset) terminal device (e.g., a smartphone) with DApps (decentralized applications). Terminal 2 acquires the transaction corresponding to the write function request via Wallet Connect.

[0087] Specifically, based on the network ID and the name of the smart contract, the terminal 2 obtains the contract address of the smart contract from the network management DB 151 of the server 1. The terminal 2 transmits the network ID, the contract address, the function name of the write function, and the set single or multiple parameters to the corresponding blockchain 3.

[0088] The blockchain 3 obtains a transaction corresponding to the write function request from the ABI generated when the smart contract code is deployed, based on the network ID, contract address, function name, and parameters sent from the terminal 2. For example, the obtained transaction is "Succeeded True."

[0089] The blockchain 3 transmits the acquired transaction to the terminal 2. The terminal 2 receives the transaction transmitted from the blockchain 3. The terminal 2 displays the received transaction in the transaction display field 13b.

[0090] Fig. 10 is an explanatory diagram showing an example of a display screen of a transaction corresponding to a function request in an event. Note that the same reference numerals are used to denote the same contents as in Fig. 8, and the description thereof will be omitted. When the terminal 2 receives a touch operation on the event request button 12j, it acquires a transaction corresponding to a function (e.g., "ApproveForAll") in the corresponding event.

[0091] Specifically, based on the network ID and the name of the smart contract, the terminal 2 obtains the contract address of the smart contract from the network management DB 151 of the server 1. The terminal 2 transmits the network ID, the contract address, and the function name of the function in the event to the corresponding blockchain 3.

[0092] The blockchain 3 obtains a transaction corresponding to the function request in the event from the ABI generated when the smart contract code is deployed, based on the network ID, contract address, and function name sent from the terminal 2. For example, the obtained transaction is " { “blockHash”:number, “blockTime”:number, “txHash”:string, "data":{ “from”:address, “to”:address, "approved":bool } } "

[0093] The blockchain 3 transmits the acquired transaction to the terminal 2. The terminal 2 receives the transaction transmitted from the blockchain 3. The terminal 2 displays the received transaction in the transaction display field 13b.

[0094] 11 is a flowchart showing the processing steps for displaying a list of multiple functions in a smart contract. The control unit 11 of the server 1 acquires network management information for multiple blockchains 3 from the network management DB 151 in the mass storage unit 15 based on the network ID (step S101). The network management information includes the network name, smart contract name, contract address, number of functions, number of monitors, or number of developer wallets, etc.

[0095] The control unit 11 transmits the acquired management information of the multiple blockchains 3 to the terminal 2 via the communication unit 13 (step S102). The control unit 21 of the terminal 2 receives the network management information of the multiple blockchains 3 transmitted from the server 1 via the communication unit 23 (step S201). The control unit 21 displays the received management information of the multiple blockchains 3 on the display unit 25 (step S202).

[0096] The control unit 21 receives, via the input unit 24, a selection of a target blockchain 3 from multiple blockchains 3 and a smart contract deployed to the blockchain 3 (step S203). The control unit 21 transmits the network ID of the selected blockchain 3 and the name of the smart contract to the server 1 via the communication unit 23 (step S204).

[0097] The control unit 11 of the server 1 receives the network ID and the name of the smart contract transmitted from the terminal 2 via the communication unit 13 (step S103). Based on the received network ID and the name of the smart contract, the control unit 11 acquires code information related to the code of the smart contract from the code information DB 152 of the mass storage unit 15 (step S104).

[0098] Specifically, based on the network ID and the name of the smart contract, the control unit 11 acquires, by category, requests for a plurality of corresponding functions, function names, data formats of responses corresponding to the requests, or function descriptions, etc. from the code information DB 152. The control unit 11 transmits the acquired code information to the terminal 2 via the communication unit 13 (step S105).

[0099] The control unit 21 of the terminal 2 receives the code information transmitted from the server 1 via the communication unit 23 (step S205). Based on the received code information, the control unit 21 displays a list of requests for multiple functions in the smart contract, function names, data formats of responses corresponding to the requests, or explanations of the functions, sorted by function category, via the display unit 25 (step S206).

[0100] The control unit 21 receives an edited explanation of the function via the input unit 24 (step S207). The control unit 21 associates the edited explanation with the network ID, the name of the smart contract, and the function name, and transmits the received edited explanation to the server 1 via the communication unit 23 (step S208).

[0101] The control unit 11 of the server 1 receives the network ID, smart contract name, function name, and edited commentary sent from the terminal 2 via the communication unit 13 (step S106). The control unit 11 stores the edited commentary in the code information DB 152 in association with the received network ID, smart contract name, and function name (step S107). The control unit 11 then ends the process.

[0102] 12 is a flowchart showing the processing steps for displaying a transaction corresponding to a function request. The control unit 21 of the terminal 2 receives a call request for a transaction of the target function request via the input unit 24 (step S211). The control unit 21 determines whether the function corresponding to the received call request is a read function or a write function (step S212).

[0103] If the function is not either a read function or a write function (NO in step S212), the control unit 21 transmits request information to any of the nodes 31 in the corresponding blockchain 3 via the communication unit 23 (step S213). The request information includes the network ID, the contract address, and the function name of the function in the event. The node 31 in the blockchain 3 executes the processes of steps S311 to S313, which will be described later.

[0104] If the function is a read function or a write function (YES in step S212), control unit 21 determines whether or not parameter setting for the function is necessary (step S214). Specifically, if there are parameters for the function, control unit 21 determines that parameter setting for the function is necessary. Alternatively, if there are no parameters for the function, control unit 21 determines that parameter setting for the function is not necessary.

[0105] If control unit 21 determines that parameter setting for the function is not required (NO in step S214), the process proceeds to step S217, which will be described later. If control unit 21 determines that parameter setting for the function is required (YES in step S214), control unit 21 displays a setting field (parameter setting field 13a in FIG. 9) for accepting parameter setting on display unit 25 (step S215).

[0106] Control unit 21 receives parameter settings from input unit 24 via the setting field (step S216). Control unit 21 determines whether the function is a write function (step S217). If the function is not a write function (NO in step S217), control unit 21 proceeds to processing in step S219, which will be described later. If the function is a write function (YES in step S217), control unit 21 starts Wallet Connect (step S218).

[0107] The terminal 2 transmits the function request information to any of the nodes 31 in the corresponding blockchain 3 via the communication unit 23 (step S219). The request information includes a network ID, a contract address, a function name, or a single or multiple set parameters.

[0108] Node 31 of blockchain 3 receives function request information sent from server 1 (step S311). Based on the received request information, node 31 acquires a transaction corresponding to the function request from the ABI generated when the smart contract code is deployed (step S312). Node 31 transmits the acquired transaction to terminal 2 (step S313).

[0109] The control unit 21 of the terminal 2 receives the transaction transmitted from the blockchain 3 via the communication unit 23 (step S220). The control unit 21 displays the received transaction on the display unit 25 (step S221). The control unit 21 ends the process.

[0110] According to this embodiment, it is possible to track the state of a smart contract by displaying a list of requests for multiple functions in the smart contract and the data formats of the responses corresponding to the requests.

[0111] According to this embodiment, when a request to call a transaction of a request for a specific function is received, it is possible to display the transaction corresponding to the request for that function.

[0112] According to this embodiment, it is possible to centrally manage smart contracts deployed on multiple blockchains 3.

[0113] (Embodiment 2) The second embodiment relates to a form in which requests to a smart contract and responses from the smart contract are stored as log data. Note that a description of content that overlaps with the first embodiment will be omitted.

[0114] Fig. 13 is a block diagram showing an example of the configuration of the server 1 in embodiment 2. Note that the same reference numerals are used to denote the same components as those in Fig. 2, and the description thereof will be omitted. The mass storage unit 15 includes a monitor management DB 153 and a remittance log DB 154.

[0115] The monitor management DB 153 stores management information for smart contracts to be monitored. In this embodiment, the smart contracts to be monitored are registered in the monitor management DB 153. Furthermore, when a function is registered in the monitor management DB 153, by specifying the name of a log DB for storing requests and responses of the function, transactions can be tracked from the specified log DB.

[0116] For example, if the function "mint" is registered in the monitor management DB 153, the name of the log DB may be designated as "mint log DB." Alternatively, if the function "transfer" is registered in the monitor management DB 153, the name of the log DB may be designated as "remittance log DB."

[0117] In this embodiment, an example of the remittance log DB 154 will be described, but the present invention can be similarly applied to log DBs corresponding to other types of functions. The remittance log DB 154 stores requests for the transfer function of the smart contract and responses by the smart contract as log data.

[0118] FIG. 14 is an explanatory diagram showing an example of the record layout of the monitor management DB 153 and the remittance log DB 154. As shown in FIG. The monitor management DB 153 includes a monitoring ID column, a network ID column, a contract name column, a function name column, a parameter column, an alert condition column, and a log DB name column. The monitoring ID column stores a monitoring ID that uniquely identifies data to identify each monitoring target data. The network ID column stores a network ID that identifies the blockchain 3.

[0119] The contract name column stores the name of the smart contract deployed to the blockchain 3. The function name column stores the name of the function. The parameter column stores the parameters of the function. The alert condition column stores the alert condition for notifying the user of an alert. Alert conditions will be described later. The log DB name column stores the name of the log DB for storing the log data of the function.

[0120] The remittance log DB154 includes a log ID column, a block number column, a date and time column, a transaction hash (txHash) column, a source address (from) column, a destination address column (to) and a token ID (tokenId) column. The log ID column stores a log ID of the log data of the remittance that is uniquely specified to identify the log data of each remittance. The block number column stores the number of the block that contains the transaction.

[0121] The date and time column stores the date and time when the transaction occurred. The transaction hash column stores the transaction hash, which is a unique identifier generated each time a transaction is executed within the blockchain 3. The transaction hash is used to verify that the transaction is valid and immutable, and contains important information about the transaction, such as the wallet address, the amount sent, the date and time, or the current status.

[0122] The source address column stores the source address that sends the token. The destination address column stores the destination address that receives the token. The token ID column stores the token ID, which is a unique identifier of the token.

[0123] FIG. 15 is an explanatory diagram illustrating the process of storing requests and responses. First, the registration process of a smart contract to be monitored will be explained. Terminal 2 accepts registration information for each function of the smart contract to be monitored. The registration information includes the network ID, contract name, function name, parameters, alert conditions, or the name of the log DB, etc.

[0124] An alert condition is a condition set for outputting alert information to terminal 2 when a response from a smart contract meets a predetermined condition. For example, alert conditions for the "Transfer" function include the absence of a sender address (account), the sender's token balance being insufficient, or the destination address being invalid, and these are conditions for confirming the legitimacy of the transaction.

[0125] The terminal 2 transmits the received registration information to the server 1. The server 1 assigns a monitoring ID to each function of the registration information transmitted from the terminal 2. The server 1 stores the network ID, contract name, function name, parameters, alert conditions, and log DB name for each function as one record in the monitor management DB 153, in association with the assigned monitoring ID.

[0126] Next, we will explain the process of sending a request to a registered smart contract at a predetermined timing. Note that, although the following explains the example of the "transfer" function, it can be applied to other functions as well.

[0127] The server 1 acquires request information for the function "transfer" at a predetermined timing from the code information DB 152. The predetermined timing may be a specified time (e.g., 9:00, 12:00, 15:00, 18:00, and 21:00) at a predetermined cycle (e.g., five times a day). The request information includes a network ID, a function name, parameters, etc.

[0128] Based on the network ID, the server 1 transmits the acquired request information to one of the nodes 31 in the corresponding blockchain 3. The node 31 in the blockchain 3 receives the request information transmitted from the server 1. Based on the received request information, the node 31 obtains a response from the smart contract corresponding to the function request from the ABI generated when the smart contract code is deployed.

[0129] For example, the response to the request includes the block number, the date and time when the transaction occurred, the transaction hash, the source address, the destination address, or the token ID, etc. The node 31 transmits the response to the acquired request to the server 1.

[0130] The server 1 assigns a log ID to the response sent from the blockchain 3. The server 1 stores the acquired block number, transaction hash, sender address, destination address, and token ID as one record in the remittance log DB 154, in association with the assigned log ID and the date and time information when the transaction occurred.

[0131] The server 1 acquires the alert conditions corresponding to the function from the monitor management DB 153 based on the monitoring ID. The server 1 determines whether the response sent from the blockchain 3 satisfies the acquired alert conditions. If the response satisfies the alert conditions, the server 1 outputs (sends) alert information to the terminal 2 or an external chat platform, etc. The alert information includes, for example, an error number, a message indicating the error, or measures to take against the error.

[0132] Examples of chat platforms include Slack (registered trademark), Discord (registered trademark), PagerDuty (registered trademark), ChatWork (registered trademark), or Line (registered trademark). For example, if the response satisfies an alert condition that the sender's token balance is insufficient, the server 1 may output alert information to the terminal 2 or an external chat platform. Therefore, by notifying the user of the alert, the user can deal with the problem early and prevent potential problems.

[0133] The response can be output in a predetermined file format, such as an Excel file, a portable document format (PDF) file, or a comma separated value (CSV) file.

[0134] Specifically, the server 1 acquires the target date and time. The target date and time may be, for example, a date and time specified in units of a month, a week, or a day. The server 1 reads out the response by the smart contract corresponding to the acquired date and time from the remittance log DB 154. The server 1 outputs the read response in a predetermined file format (for example, a CSV file). The terminal 2 downloads the response file output from the server 1.

[0135] Fig. 16 is an explanatory diagram showing an example of a monitor list display screen. This screen includes a monitor list display field 14a and a log display button 14b. The monitor list display field 14a is a display field that displays a list of smart contracts to be monitored that are registered in the monitor management DB 153. The log display button 14b is a button for transitioning to a response display screen (Fig. 17) for responses by smart contracts.

[0136] The server 1 acquires management information of the smart contract to be monitored from the monitor management DB 153. The management information includes, for example, a network ID, a contract name, a function name, or a log DB name. The server 1 acquires the name of the network from the network management DB 151 based on the acquired network ID. The server 1 transmits the acquired network name, contract name, function name, and log DB name to the terminal 2.

[0137] The terminal 2 receives the network name, contract name, function name, and log DB name transmitted from the server 1. The terminal 2 displays the received network name, contract name, function name, and log DB name in the monitor list display field 14a.

[0138] When the terminal 2 receives a touch operation of the log display button 14b, it transfers the name of the corresponding log DB to the response display screen (FIG. 17) and transitions to the response display screen. For example, when the terminal 2 receives a touch operation of the log display button 14b corresponding to the function "Transfer", it transfers the name of the log DB "Transfer_logs (transmission log)" to the response display screen corresponding to the request for the function "Transfer", and transitions to the response display screen.

[0139] Fig. 17 is an explanatory diagram showing an example of a response display screen corresponding to a function request. Note that Fig. 17 illustrates an example of the function "Transfer." The screen includes a date and time selection field 15a, a file output button 15b, and a response list display field 15c.

[0140] The date and time selection field 15a is a selection field that accepts the selection of the target date and time. The file output button 15b is a button for outputting the response to a file. The response list display field 15c is a display field that displays a list of responses from smart contracts corresponding to the selected date.

[0141] When the terminal 2 receives a selection operation in the date and time selection field 15a, it acquires the selected date. For example, the terminal 2 receives the selection of a date and time in monthly units (e.g., February). The terminal 2 transmits the received date and time and the name of the log DB passed from the list display screen (FIG. 16) of the monitor to the server 1. The server 1 receives the date and time and the name of the log DB transmitted from the terminal 2.

[0142] Based on the name of the received log DB (for example, remittance log DB 154), the server 1 reads out the response from the smart contract corresponding to the received date and time from the corresponding DB. The server 1 transmits the read response from the smart contract to the terminal 2. The terminal 2 receives the response from the smart contract transmitted from the server 1. The terminal 2 displays the received response from the smart contract in the response list display field 15c.

[0143] 18 is a flowchart showing the processing procedure for storing a request and a response. The control unit 11 of the server 1 acquires the registration information (network ID, contract name, function name, parameters, alert conditions, or log DB name, etc.) of the function accepted by the terminal 2 via the communication unit 13 (step S131).

[0144] The control unit 11 stores the acquired registration information in the monitor management DB 153 of the mass storage unit 15 (step S132). Specifically, the control unit 11 assigns a monitoring ID to the registration information. The control unit 11 stores the network ID, contract name, function name, parameters, alert conditions, and log DB name as one record in the monitor management DB 153, in association with the assigned monitoring ID.

[0145] It should be noted that once the above-described processing (steps S131 to S132) has been performed once, the processing can be omitted from the next time.

[0146] The control unit 11 determines whether or not a predetermined timing (for example, 12:00 every day) has arrived (step S133). If the predetermined timing has not arrived (NO in step S133), the control unit 11 waits. If the predetermined timing has arrived (YES in step S133), the control unit 11 acquires request information for the registered function from the code information DB 152 in the mass storage unit 15 (step S134). The request information includes a network ID, a function name, parameters, etc.

[0147] Based on the network ID, the control unit 11 transmits the acquired request information to any of the nodes 31 in the corresponding blockchain 3 via the communication unit 13 (step S135). The node 31 in the blockchain 3 receives the request information transmitted from the server 1 (step S331). Based on the received request information, the node 31 acquires a response from the smart contract corresponding to the function request from the ABI generated when the smart contract code is deployed (step S332).

[0148] The response from the smart contract may include the block number, the date and time the transaction occurred, the transaction hash, the source address, the destination address, or the token ID.

[0149] The node 31 transmits a response corresponding to the acquired request to the server 1 (step S333). The control unit 11 of the server 1 receives the response transmitted from the blockchain 3 via the communication unit 13 (step S136). The control unit 11 performs a conversion process on the return value of the request included in the received response (step S137).

[0150] For example, if the return value of the request included in the response (e.g., the remittance amount) is "377557249377700013333333333", the control unit 11 converts the return value of the request into token units. For example, the return value of the request after conversion is "377557249.377700013333333333 OSHI".

[0151] The control unit 11 stores the response including the converted return value in the remittance log DB 154 of the mass storage unit 15 in association with the date and time information (step S138). Specifically, the control unit 11 assigns a log ID to the response. The control unit 11 stores the acquired block number, the transaction hash including the converted return value, the sender address, the destination address, and the token ID in association with the assigned log ID and the date and time information when the transaction occurred in the remittance log DB 154 as one record.

[0152] The control unit 11 acquires the alert condition corresponding to the function from the monitor management DB 153 based on the monitoring ID (step S139). The control unit 11 determines whether the response sent from the blockchain 3 satisfies the acquired alert condition (step S140).

[0153] An example is a destination address. For example, if the destination address included in the response is valid, the control unit 11 determines that the alert condition is not met. Alternatively, if the destination address included in the response is invalid, the control unit 11 determines that the alert condition is met.

[0154] If the response does not satisfy the alert condition (NO in step S140), the control unit 11 ends the process. If the response satisfies the alert condition (YES in step S140), the control unit 11 outputs alert information including an error number, a message indicating the error, or a countermeasure for the error to the terminal 2 or an external chat platform or the like via the communication unit 13 (step S141). The control unit 11 ends the process.

[0155] 19 is a flowchart showing the processing steps when outputting a response by a smart contract. The control unit 21 of the terminal 2 receives a setting (selection) operation of a target date and time (for example, February) via the input unit 24 (step S251). The control unit 21 receives an output request including a screen output or a file output via the input unit 24 (step S252).

[0156] The control unit 21 transmits the network ID, the name of the smart contract, the function name, and the output request to the server 1 via the communication unit 23 in association with the received date and time (step S253). The control unit 11 of the server 1 receives the date and time, the network ID, the name of the smart contract, the function name, and the output request transmitted from the terminal 2 via the communication unit 13 (step S151).

[0157] Based on the received date and time, network ID, smart contract name, and function name, the control unit 11 identifies the name of the target log DB (e.g., remittance log DB) from the monitor management DB 153 (step S152). Based on the identified log DB name, the control unit 11 reads out the response by the smart contract corresponding to the received date and time from the corresponding DB (step S153).

[0158] The control unit 11 determines whether the received output request is for screen output (step S154). If the output request is not for screen output (NO in step S154), the control unit 11 generates a response file in a predetermined file format (for example, a CSV file) based on the read response (step S155). The control unit 11 transmits the generated response file to the terminal 2 via the communication unit 13 (step S156).

[0159] The control unit 21 of the terminal 2 receives the response file transmitted from the server 1 via the communication unit 23 (step S254). The control unit 21 downloads the received response file (step S255).

[0160] If the output request is for screen output (YES in step S154), the control unit 11 of the server 1 transmits a list of the read responses according to the smart contract to the terminal 2 via the communication unit 13 (step S157).

[0161] The control unit 21 of the terminal 2 receives the response based on the smart contract sent from the server 1 via the communication unit 23 (step S256). The control unit 21 displays a list of the received responses based on the smart contract via the display unit 25 (step S257). The control unit 21 ends the process.

[0162] According to this embodiment, it is possible to store requests to a smart contract and responses from the smart contract as log data.

[0163] According to this embodiment, if the response from the smart contract satisfies a predetermined condition, it is possible to output alert information.

[0164] According to this embodiment, by outputting alert information, it is possible to detect system abnormalities or fraudulent activities at an early stage and protect the assets or information of the user.

[0165] According to this embodiment, it is possible to output a response from a smart contract corresponding to a target date and time in a specified file format.

[0166] (Embodiment 3) The third embodiment relates to a form in which balances of multiple currencies in a smart contract are stored as log data. Note that a description of the contents that overlap with the first and second embodiments will be omitted.

[0167] Figure 20 is a block diagram showing an example of the configuration of the server 1 in embodiment 3. Note that the same reference numerals are used to denote the same parts as in Figure 13, and descriptions thereof will be omitted. The mass storage unit 15 includes a wallet DB 155 and a balance log DB 156. The wallet DB 155 stores the wallet address of the user who is the remittance destination. The balance log DB 156 stores log data including balances of multiple currencies in the smart contract.

[0168] FIG. 21 is an explanatory diagram showing an example of the record layout of the wallet DB 155 and the balance log DB 156. The wallet DB 155 includes a user column, a network ID column, and a wallet address column. The user column stores a user ID or a user name. The network ID column stores the network ID of the blockchain 3 used by the user. The wallet address column stores the user's wallet address.

[0169] The balance log DB 156 includes a log ID column, a date and time column, a user column, a network ID column, a wallet address column, a token column, and a balance column. The log ID column stores a log ID of the log data of the balance that is uniquely specified in order to identify the log data of each balance. The date and time column stores information on the date and time when the transaction occurred.

[0170] The user column stores the user ID or the user's name. The network ID column stores the network ID for identifying the blockchain 3. The wallet address column stores the user's wallet address. The token column stores the type of token (currency). Token types include, for example, MATIC token or ETH token. The balance column stores the amount of tokens held in the user's wallet address (token balance).

[0171] The server 1 registers registration information for a smart contract function ("getBalance") that tracks balance changes in the monitor management DB 153. The registration information includes the network ID, the name of the smart contract, the function name "getBalance", parameters, alert conditions, or the name of the log DB (for example, "balance_logs"), etc. The alert condition for the "getBalance" function may be set, for example, to the fact that the remittance destination (address) of the recipient is an unregistered remittance destination. Note that the registration process is the same as in embodiment 2, so a description thereof will be omitted.

[0172] The server 1 acquires request information for the function "getBalance" from the code information DB 152 at a predetermined timing. The predetermined timing may be a specified time (e.g., 9:00, 12:00, 15:00, 18:00, and 21:00) at a predetermined cycle (e.g., five times a day). The request information includes a network ID, a function name ("getBalance"), parameters, etc.

[0173] Based on the network ID, the server 1 sends the acquired request information to one of the nodes 31 in the corresponding blockchain 3. The node 31 in the blockchain 3 receives the request information sent from the server 1. Based on the received request information, the node 31 acquires a response corresponding to the request for the function ("getBalance") from the ABI generated when the smart contract code is deployed.

[0174] For example, the response corresponding to the request may include the date and time when the transaction occurred, the user's name, the network ID, the user's wallet address, the type of token, or the token balance, etc. The node 31 transmits the response corresponding to the acquired request to the server 1.

[0175] The server 1 assigns a log ID to the response sent from the blockchain 3. The server 1 stores the acquired user name, network ID, user wallet address, token type, and token balance as one record in the balance log DB 156, in association with the assigned log ID and the date and time information when the transaction occurred.

[0176] Based on the monitoring ID, the server 1 obtains the alert conditions corresponding to the function from the monitor management DB 153. The server 1 determines whether the remittance destination included in the response sent from the blockchain 3 is an unregistered remittance destination. For example, if the remittance destination included in the response does not exist in the wallet DB 155, the server 1 determines that the remittance destination is an unregistered remittance destination. Alternatively, if the remittance destination included in the response exists in the wallet DB 155, the server 1 determines that the remittance destination is not an unregistered remittance destination.

[0177] If the remittance destination is an unregistered remittance destination, the server 1 outputs alert information including an error number, a message indicating the error, or countermeasures for the error to the terminal 2 or an external chat platform (e.g., Slack, Discord, ChatWork, or PagerDuty).

[0178] The server 1 may output the response to the terminal 2 in a predetermined file format, or may output a list display screen for displaying a list of the responses to the terminal 2. The response output process is the same as in the second embodiment, and therefore a description thereof will be omitted.

[0179] The flowchart for the process of storing the balances of multiple currencies in a smart contract at a predetermined timing and the process of outputting alert information is the same as the flowchart shown in Figure 18, so the explanation will be omitted.

[0180] According to this embodiment, it is possible to store the balances of multiple currencies in a smart contract at a predetermined timing.

[0181] According to this embodiment, when a remittance is made to an unregistered remittance destination, alert information is output to the user, thereby making it possible to prevent fraudulent remittances.

[0182] The embodiments disclosed herein are illustrative in all respects and should not be considered limiting. The scope of the present invention is defined by the claims, not by the above meaning, and is intended to include all modifications within the meaning and scope of the claims.

[0183] The matters described in each embodiment can be combined with each other. Furthermore, the independent claims and dependent claims described in the claims can be combined with each other in any and all combinations, regardless of the reference format. Furthermore, the claims use a format in which a claim references two or more other claims (multiple claim format), but this is not limited to this. A multiple claim (multi-multi claim) that references at least one other multiple claim may also be used. [Explanation of symbols]

[0184] 1. Information processing device (server) 11 Control section 12 Storage section 13 Communications Department 14 Reading unit 15 Mass storage 151 Network Management DB 152 Code Information DB 153 Monitor Management DB 154 Remittance Log DB 155 Wallet DB 156 Balance Log DB 1a Portable storage media 1b semiconductor memory 1P control program 2. Information processing terminal (terminal) 21 Control section 22 Memory section 23 Communications Department 24 Input section 25 Display section 2P control program 3 Blockchain Network (Blockchain) 31 nodes

Claims

1. Obtain code information about the code of the smart contract, Based on the acquired code information, a list of requests for a plurality of functions in the smart contract and data formats of responses corresponding to the requests is displayed. A program that causes a computer to perform a process.

2. A list of requests for each function and the data format of the responses corresponding to the requests is displayed for each category classified by the type of function. The program according to claim 1.

3. Accept edits to the description of each feature request The program according to claim 1 or 2.

4. Deploying the smart contract to multiple different blockchain networks; Accepting a selection of a target blockchain network from the plurality of blockchain networks; Obtain code information regarding the code of the smart contract deployed to the accepted blockchain network. The program according to claim 1 or 2.

5. When a request to call a transaction of a specific function request is received, the transaction corresponding to the function request is displayed on a list display screen that displays a list of the function requests and data formats. The program according to claim 1 or 2.

6. Accepting parameter settings for the function; When the call request is accepted, a transaction corresponding to the request for the function according to the accepted parameter setting is displayed. The program according to claim 5.

7. Obtaining a request for the smart contract; Sending the acquired request to the smart contract at a predetermined timing, The response from the smart contract is stored in a storage unit in association with date and time information. The program according to claim 1 or 2.

8. If the response from the smart contract satisfies a predetermined condition, alert information is output. The program according to claim 7.

9. converting the return value of the request included in the response; A response including the converted return value is stored in the storage unit in association with the date and time information. The program according to claim 7.

10. Get the target date and time, Reads from the storage unit a response by a smart contract corresponding to the acquired date and time; Output the read response in a specified file format The program according to claim 7.

11. At a predetermined timing, the balances of the multiple currencies in the smart contract are stored in a storage unit. The program according to claim 1 or 2.

12. storing a remittance destination in the smart contract transaction in the storage unit; If the saved remittance destination is not registered, an alert message will be output. The program according to claim 11.

13. Obtain code information about the code of the smart contract, Based on the acquired code information, a list of requests for a plurality of functions in the smart contract and data formats of responses corresponding to the requests is displayed. Information processing methods.

14. An information processing device including a control unit, The control unit Obtain code information about the code of the smart contract, Based on the acquired code information, a list of requests for a plurality of functions in the smart contract and data formats of responses corresponding to the requests is displayed. Information processing device.

Images