JP2023014548A - Information processing device, information processing method, and program - Google Patents

Abstract

To conveniently manage a smart contract.SOLUTION: An information processing device comprises a giving unit and a determination unit. The giving unit gives a type based on a homotopy-type theory to a smart contract recorded in a block chain network and another smart contract. When conversion from the smart contract to the other smart contract meets prescribed rules based on the homotopy-type theory, the determination unit determines that both the other smart contract and the smart contract have identity.SELECTED DRAWING: Figure 1

Description

The present invention relates to an information processing device, an information processing method, and a program.

Techniques for managing updates of smart contracts executed in blockchain networks are known. For example, Patent Document 1 discloses a technique for updating a smart contract and recording a change in a block in a blockchain network when it is determined that the conditions for updating the smart contract are satisfied. there is

Japanese Patent Publication No. 2020-501402

However, in the conventional technology, when a smart contract is updated, the smart contract is managed as a different smart contract. was treated as a different smart contract in some cases. As a result, smart contracts may not be conveniently managed.

The present invention has been made in consideration of such circumstances, and one of the objects thereof is to provide an information processing device, an information processing method, and a program capable of conveniently managing smart contracts. .

An information processing apparatus according to an aspect of the present invention includes: an assigning unit that assigns a type based on homotopy type theory to a smart contract recorded in a blockchain network and another smart contract; a determination unit that determines that the another smart contract is identical to the smart contract when conversion to the smart contract satisfies a predetermined rule based on the homotopy type theory.

According to one aspect of the present invention, smart contracts can be conveniently managed.

1 is a diagram showing an example of a system 1 that is a usage environment of an information processing device 100; FIG. 3 is a diagram showing an example of the configuration of blockchain data 12 stored in a node 10; FIG. 3 is a diagram showing an example of pseudo code of smart contract SC_a recorded in blockchain data 12. FIG. 3 is a diagram showing an example of pseudo code of smart contract SC_b recorded in blockchain data 12. FIG. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a diagram for explaining an outline of a homotopy-type theory; FIG. 4 is a conceptual diagram for explaining a path p from smart contract SC_a to smart contract SC_b; 3 is a diagram showing an example of pseudo code of smart contract SC_c recorded in blockchain data 12. FIG. FIG. 10 is a conceptual diagram for explaining synthesis q0p of path p from smart contract SC_a to smart contract SC_b and path q from smart contract SC_b to smart contract SC_c; 3 is a diagram showing an example of pseudo code of smart contract SC_d recorded in blockchain data 12. FIG. FIG. 4 is a conceptual diagram for explaining the convertibility from smart contract SC_c to smart contract SC_d; 3 is a diagram showing an example of a smart contract management table 132 stored in a storage unit 130; FIG.

Hereinafter, embodiments of an information processing apparatus, an information processing method, and a program according to the present invention will be described with reference to the drawings. FIG. 1 is a diagram showing an example of a system 1 that is an environment in which an information processing apparatus 100 is used. As shown in FIG. 1 , the system 1 includes multiple nodes 10 and an information processing device 100 .

The node 10 is a computer device that connects to the blockchain network NW, which is a peer-to-peer network, and communicates with other nodes 10 and the like via the blockchain network NW. Each node 10 stores blockchain data 12 and executes a smart contract SC, which is program code recorded in the blockchain data 12 . By executing the smart contract SC, for example, it is possible to automate the processing of business logic agreed between participants in advance, such as data reading/writing and remittance under predetermined conditions. The node 10 may be a full node that holds all information in the blockchain network NW, or a light node that holds information such as a hash value for certifying each piece of data.

The information processing device 100 acquires blockchain data 12 from one or more nodes 10 and manages information related to smart contracts SC recorded in the blockchain data 12 . The information processing device 100 also functions as the node 10, and may manage information regarding the smart contract SC recorded in the blockchain data 12 stored by the information processing device 100 itself.

The information processing apparatus 100 includes a granting unit 110, a determining unit 120, and a storage unit 130 in order to realize the functions described above. The granting unit 110 and the determining unit 120 are implemented by, for example, a hardware processor such as a CPU executing a program (software). The granting unit 110 and the determining unit 120 may be realized by hardware (including circuitry) such as LSI, ASIC, FPGA, GPU, etc., or may be realized by cooperation of software and hardware. The storage unit 130 is implemented by, for example, a ROM, flash memory, SD card, RAM, HDD, register, and the like. Details of the functions of the provision unit 110 and the determination unit 120 and details of the information stored in the storage unit 130 will be described later.

FIG. 2 is a diagram showing an example of the configuration of blockchain data 12 stored in the node 10. As shown in FIG. As shown in FIG. 2, the blockchain data 12 is composed of a plurality of blocks, and each block BL includes, for example, a previous block hash value HV1, a transaction history hash value HV2, other headers OH, a nonce value NV, and a smart Includes contract SC and transaction history TD.

The previous block hash value HV1 indicates a hash value calculated by the previous block BL(N−1) of a certain block BL(N). A transaction history hash value HV2 indicates a hash value calculated according to a predetermined rule based on the transaction history TD, and is, for example, a mark root value. Other header OH indicates meta information of the block BL, and includes information such as time stamp, for example. The nonce value indicates a number generated by mining by a miner when the node 10 generates a block, and is, for example, a 32-bit number. The smart contract SC indicates program code recorded in the blockchain data 12 as described above. The transaction history TD indicates cryptocurrency remittance information from one node 10 to another node 10 .

When each node 10 newly generates the next block BL(N+1) of a certain block BL(N), each node 10 generates a previous block hash value HV1, a transaction history hash value HV2, and other headers OH in the block BL(N). , based on the nonce value, the hash value of the block BL(N) is calculated. It is stored as the previous block hash value HV1 in BL(N+1). If the calculated hash value does not satisfy a predetermined condition (for example, the value of the upper 16 digits is all zero), each node 10 receives the next nonce value from the miner and re-does the hash value of block BL(N). Receipt of the nonce value and recalculation of the hash value are repeated until the calculated and recalculated hash value satisfies a predetermined condition. As a result, a block BL(N+1) next to a certain block BL(N) is generated. In addition to the previous block hash value HV1, the transaction history hash value HV2, the other header OH, and the nonce value, the smart contract SC may be used as input to calculate the hash value of the block BL(N). .

FIG. 3 is a diagram showing an example of pseudocode of the smart contract SC_a recorded in the blockchain data 12. As shown in FIG. The smart contract SC_a shown in FIG. 3 acquires the current month and day, and when the acquired current month and day match October 1, the process of transferring the amount equivalent to the amount from the sender to the receiver. is shown.

FIG. 4 is a diagram showing an example of pseudo code of the smart contract SC_b recorded in the blockchain data 12. As shown in FIG. The smart contract SC_b shown in FIG. 4 acquires the current month and day, and when the acquired current month and day match October 1st, the process of transferring the amount equivalent to the amount from the sender to the receiver. , which is the same as the processing performed by the smart contract SC_a.

Comparing smart contract SC_a and smart contract SC_b, in smart contract SC_a, datetime. While the storage variable of the object acquired by the now method is time, smart contract SC_b stores datetime. The storage variable of the object acquired by the now method is t. That is, smart contract SC_a matches smart contract SC_b by modifying the storage variable time described in the program code of smart contract SC_a to storage variable t.

Since the program code of the smart contract SC_a and the program code of the smart contract SC_b are different in this way, the smart contract SC_a and the smart contract SC_b may be treated as different things in the conventional technology. However, smart contract SC_a and smart contract SC_b can also be interpreted as having the same in that the amount equivalent to the amount is transferred from the sender to the receiver on October 1st. That is, in managing a plurality of smart contracts SC, it is necessary to define what it means for the plurality of smart contracts SC to have the same identity.

To solve the above problems, the present invention applies homotopy-type theory. Homotopy type theory is a theory that integrates homotopy theory, which belongs to the field of topology, and type theory, which belongs to the field of foundations of mathematics, from a more general point of view, and deals with the extended concept of identity. . Here, "applying the homotopy type theory" means, for example, creating and executing an arbitrary program code based on the homotopy type theory. It doesn't have to mean creating a function or the like.

FIG. 5 is a diagram for explaining the outline of the homotopy-type theory. In FIG. 5, a, b, and c indicate points in space, p indicates a path from point a to point b, and q indicates a path from point b to point c. In the homotopy-type theory, when there is a path connecting two points in space, it is interpreted that the two points have the same identity, and p:a= _Ab holds. where A denotes the type that points a and b have, and p:a= _A b means that points a and b have identity with respect to type A. That is, it is equivalent that there exists a path from point a to point b if points a and b have the same type. A road has the following properties.

[Reflex law]
For any point a in space there is a path p from point a itself. That is, p:a= _Aa holds. The path p at this time is also written as id, and is sometimes called an identity map.

[Law of symmetry]
If there exists a path p from point a to point b in space, there also exists a path q from point b to point a. That is, when p:a= _Ab holds, there exists a path q such that q:b= _Aa holds. The road q at this time is, for example, a road that follows the road p from the point a to the point b in the opposite direction, and ! It is written as p. ! Sometimes p is called an inverse mapping.

[Transitive law]
If there exists a path p from point a to point b in space and a path q from point b to point c, then there also exists a path r from point a to point c. That is, if p:a= _Ab and q:b= _Ac , there exists a path r such that r:a= _Ac . The road r at this time is, for example, a road connecting the road p from the point a to the point b and the road q from the point b to the point c, and is written as q0p. q0p may be referred to as a synthetic map.

The assigning unit 110 assigns a type based on the homotopy type theory described above to the smart contract SC recorded in the blockchain data 12 to define the identity of the smart contract SC. More specifically, in this embodiment, the assigning unit 110 assigns the same type to a plurality of smart contracts SC having the same execution content.

If there is a path from one smart contract SC to another smart contract SC, that is, if two smart contract SCs have the same execution content, the determination unit 120 determines that these smart contract SCs are identical. do. The determining unit 120 associates the smart contracts SC determined to have the same type with the same type and stores them in the smart contract management table 132 stored in the storage unit 130 . Details of the smart contract management table 132 will be described later.

FIG. 6 is a conceptual diagram for explaining the path p from smart contract SC_a to smart contract SC_b. As described above, the smart contract SC_b is program code obtained by converting the variable time of the smart contract SC_a into the variable t. At this time, there is no change in the execution content of transferring the amount equivalent to the amount from the sender to the receiver on October 1st. Therefore, the assigning unit 110 assigns the same type A to the smart contract SC_a and the smart contract SC_b, and the determining unit 120 determines that the smart contract SC_a and the smart contract SC_b are identical.

FIG. 7 is a diagram showing an example of pseudo code of the smart contract SC_c recorded in the blockchain data 12. As shown in FIG. The smart contract SC_c shown in FIG. 7 is program code obtained by converting the variable month of the smart contract SC_b into the variable mon. At this time, as in the case of conversion from smart contract SC_a to smart contract SC_b, there is no change in the execution content of transferring the amount equivalent to the amount from the sender to the receiver on October 1st. Therefore, the assigning unit 110 assigns type A to the smart contract SC_c, and the determining unit 120 determines that the smart contract SC_a, the smart contract SC_b, and the smart contract SC_c are identical.

FIG. 8 is a conceptual diagram for explaining synthesis q0p of path p from smart contract SC_a to smart contract SC_b and path q from smart contract SC_b to smart contract SC_c. The smart contract SC_c is program code obtained by converting the variable time of the smart contract SC_a into the variable t (path p) and then converting the variable month into the variable mon (path q). That is, from smart contract SC_a to smart contract SC_c, a combination q0p of way p and way q is applied, and q0p: smart contract SC_a= _A smart contract SC_c is established.

FIG. 9 is a diagram showing an example of pseudo code of smart contract SC_d recorded in blockchain data 12. As shown in FIG. The smart contract SC_d shown in FIG. 9 acquires the current month and day, and when the acquired current month and day match November 1st, the process of transferring the amount equivalent to the amount from the sender to the receiver. is shown. At this time, the content of execution is changed to remit an amount equivalent to the amount from the sender to the receiver on October 1st. Therefore, the granting unit 110 grants the smart contract SC_d a type B different from the smart contracts SC_a, the smart contracts SC_b, and the smart contracts SC_c. It is determined that the contract SC_b and the smart contract SC_c are not identical.

FIG. 10 is a conceptual diagram for explaining the convertibility from smart contract SC_c to smart contract SC_d. As shown in FIG. 10, the smart contract SC_c is obtained by converting the variable time of the smart contract SC_a into the variable t (path p), and then converting the variable month into the variable mon (path p), Since there is no change in the execution details of the smart contract, type A is assigned by the assigning unit 110 .

On the other hand, since smart contract SC_d has execution content different from smart contract SC_a, smart contract SC_b, and smart contract SC_c, there is no way from smart contract SC_c to smart contract SC_d. Therefore, the granting unit 110 grants the smart contract SC_d a type B different from the type A, and the determination unit 120 determines that the smart contract SC_d is identical to the smart contract SC_a, the smart contract SC_b, and the smart contract SC_c. Determine not to have.

FIG. 11 is a diagram showing an example of the smart contract management table 132 stored in the storage unit 130. As shown in FIG. As shown in FIG. 11, in the smart contract management table 132, smart contract IDs are associated with smart contract change information and information such as types.

A smart contract ID is an identifier for identifying an individual smart contract SC. The smart contract ID is given to the smart contract SC when the smart contract SC is generated, and is updated each time the program code of the smart contract SC is changed. The smart contract change information is change information from the smart contract SC corresponding to the previous smart contract ID to the current smart contract ID. The type is a type based on topology type theory given by the giving unit 110 .

As shown in FIG. 11, when individual smart contracts SC are managed based on strict consistency of program code, in the prior art, multiple smart contracts SC with the same execution content are identified as different smart contracts SC. there was a case. On the other hand, according to the present embodiment, smart contracts can be conveniently managed by assigning the same type based on the homotopy type theory to a plurality of smart contracts SC having the same execution content.

In the above-described embodiment, the assigning unit 110 assigns the same type to the smart contracts SC based on the criterion of whether or not the execution contents of the smart contracts SC are the same. However, the invention is not limited to such embodiments.

As an example, the assigning unit 110 assigns the same type to these smart contract SCs when the conversion from one smart contract SC to another smart contract SC is a conversion of a single character. Alternatively, if the transformation from one smart contract SC to another smart contract SC was a transformation of a single word, these smart contract SCs may be given the same type, or the smart contract SC If the transformation from an SC to another smart contract SC was the transformation of a single sentence, these smart contract SCs may be given the same type.

Also, as an example, the granting unit 110 ensures that conversion from a smart contract SC to another smart contract SC does not change the basic contract part (for example, the remittance module of the smart contract SC) or the contract part uniquely defined by the user. In some cases, these smart contracts SC may be given the same type.

In addition, as an example, if the conversion from one smart contract SC to another smart contract SC involves typographical errors, omissions, format changes, or addition or deletion of spaces or tabs, the granting unit 110 converts these smart contract SCs may be given the same type. Furthermore, the above-described rules that serve as criteria for assigning the same type may be combined with each other.

According to the present embodiment described above, the information processing device assigns a type based on the homotopy type theory to the smart contract, and if there is a path to another smart contract, the other smart contract The identity of smart contracts is determined by assigning the same type. This allows smart contracts to be managed conveniently.

As described above, the mode for carrying out the present invention has been described using the embodiments, but the present invention is not limited to such embodiments at all, and various modifications and replacements can be made without departing from the scope of the present invention. can be added.

1 System 10 Node 12 Blockchain Data 100 Information Processing Device 110 Granting Unit 120 Determination Unit 130 Storage Unit NW Blockchain Network BL Block HV1 Previous Block Hash Value HV2 Transaction History Hash Value OH Other Header NV Nonce Value SC Smart Contract TD Transaction History

Claims (7)

a granting unit that grants a type based on homotopy type theory to a smart contract recorded in a blockchain network and another smart contract;
a determination unit that determines that the smart contract and the smart contract are identical when the conversion from the smart contract to the smart contract satisfies a predetermined rule based on the homotopy type theory; comprising
Information processing equipment. the predetermined rule is that the conversion of the smart contract to the other smart contract does not change the execution of the smart contract;
The information processing device according to claim 1 . the predetermined rule is that the transformation from the smart contract to the another smart contract transforms the characters of the smart contract;
The information processing apparatus according to claim 1 or 2. the predetermined rule is that the conversion from the smart contract to the another smart contract converts words of the smart contract;
The information processing apparatus according to any one of claims 1 to 3. the predetermined rule is that the transformation from the smart contract to the another smart contract transforms text of the smart contract;
The information processing apparatus according to any one of claims 1 to 4. the computer
Giving a type based on homotopy type theory to a smart contract recorded in a blockchain network and another smart contract,
If the conversion from the smart contract to the another smart contract satisfies a predetermined rule based on the homotopy-type theory, the smart contract and the smart contract are determined to have identity;
Information processing methods. to the computer,
Giving a smart contract recorded in a blockchain network and another smart contract a type based on homotopy type theory,
If the conversion from the smart contract to the another smart contract satisfies a predetermined rule based on the homotopy type theory, the other smart contract and the smart contract are determined to have identity;
program.

Images