JP2020038482A - Program verification program, program verification method and program verification device - Google Patents

Abstract

To accelerate the verification of a non-deterministic operation in a program.SOLUTION: A storage unit 11 stores a source code 13 for allowing the substitution of a plurality of values for the same variable. A processing unit 12 converts the source code 13 into a source code 14 of a static single substitution format for limiting the substitution of a value for each variable to one time. The processing unit 12 retrieves a command 15 showing writing in a database from the source code 14, detects a variable with a writing value stored in the command 15, and retrieves a command 16 showing the substitution of a value for the detected variable from the source code 14. The processing unit 12 determines whether the writing in the database is an argument of the source code 13 or a non-deterministic operation dependent on an execution state other than data of the database on the basis of an acquisition method of a value to be substituted for the variable detected in the command 16.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a program verification program, a program verification method, and a program verification device.

  There is a distributed database system in which a plurality of databases storing data of the same content are arranged on a network. For example, there is a block chain system in which a database called a block chain indicating a history of a transaction (transaction) is constructed, and a plurality of server devices hold the same content of the block chain to ensure the validity of the transaction. Updating a database in a distributed database system is performed by arranging the same program in a plurality of server devices and providing the same input to the programs of the plurality of server devices, thereby updating the plurality of databases in parallel. There is.

  Note that a static analysis method has been proposed in which a control flow and a data flow are statically analyzed with respect to an intermediate code generated from the source code when compiling the source code. The proposed static analysis method converts an intermediate code into a static single assignment (SSA) format for static analysis. In addition, a program verification device that generates a verification formula from a source code and verifies a program operation using a model verification tool has been proposed. The proposed program verification device converts the source code into the SSA format, and determines a processing part to be verified based on the original source code and the SSA format source code.

JP-A-9-282173 JP 2012-238235 A

  A program arranged in a plurality of server devices of a distributed database system is required to have determinism that values written to the database are the same for the same database contents and the same input. If a program includes non-deterministic operations, the identity of a plurality of databases may be lost, and the purpose of a distributed database system such as ensuring the validity of a transaction may not be achieved.

  The non-deterministic operation of the program occurs when a value to be written to the database depends on a predetermined type of operation such as obtaining a random number or obtaining a time stamp. Therefore, when developing a program to be allocated to a plurality of server devices, it is conceivable to verify the program in order to discover a problem that writing to the database is an indeterminate operation. However, conventional static analysis of source code, such as searching for an abstract syntax tree (AST) or symbolic execution, inefficiently traces instructions related to writing to a database and increases verification time. There's a problem.

  In one aspect, an object of the present invention is to provide a program verification program, a program verification method, and a program verification device that can speed up verification of a non-deterministic operation.

  In one aspect, a program verification program for causing a computer to execute the following processing is provided. The first source code that allows multiple values to be assigned to the same variable is converted to a static single assignment type second source code that limits the assignment of a value to each variable to one. From the second source code, a first instruction indicating writing to the database is searched, a variable storing a value to be written in the first instruction is detected, and the second source code is searched for the detected variable. Search for a second instruction that indicates a value assignment. Based on the acquisition method of the value substituted for the detected variable in the second instruction, whether writing to the database is a non-deterministic operation that depends on the execution status other than the argument of the first source code and the data of the database. Determine whether or not. In one aspect, a program verification method executed by a computer is provided. In one aspect, a program verification device having a storage unit and a processing unit is provided.

  In one aspect, non-deterministic operation verification can be speeded up.

FIG. 2 is a diagram illustrating an example of a program verification device according to the first embodiment. FIG. 14 is a diagram illustrating an example of an information processing system according to a second embodiment. FIG. 3 is a block diagram illustrating an example of hardware of a development device. FIG. 3 is a diagram illustrating an example of a data structure of a block chain. It is a figure showing an example of non-deterministic operation of a smart contract. It is a figure showing the example of a smart contract. FIG. 5 is a diagram illustrating a first example of an abstract syntax tree. FIG. 11 is a diagram illustrating a second example of an abstract syntax tree. It is a figure showing an example of symbolic execution. FIG. 3 is a diagram illustrating an example of an SSA source code. It is a block diagram showing an example of a function of a development device. FIG. 4 is a diagram illustrating an example of a table held by a development device. 9 is a flowchart illustrating an example of a procedure of program verification. It is a figure showing other examples of a smart contract and SSA source code.

Hereinafter, the present embodiment will be described with reference to the drawings.
[First Embodiment]
A first embodiment will be described.

FIG. 1 is a diagram illustrating an example of a program verification device according to the first embodiment.
The program verification device 10 according to the first embodiment verifies a developed program. The program to be verified may be a program used in a distributed database system that updates a plurality of databases storing data of the same content in parallel. For example, a program to be verified is executed in parallel by a plurality of server devices that manage a block chain. The program verification device 10 may be called an information processing device or a computer. The program verification device 10 may be a client device or a server device.

  The program verification device 10 has a storage unit 11 and a processing unit 12. The storage unit 11 may be a volatile semiconductor memory such as a random access memory (RAM) or a nonvolatile storage such as a hard disk drive (HDD) or a flash memory. The processing unit 12 is a processor such as a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), and a DSP (Digital Signal Processor). However, the processing unit 12 may include a special-purpose electronic circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array). A set of multiple processors may be referred to as a “multiprocessor” or simply “processor”.

  The storage unit 11 stores the source code 13 (first source code) to be verified. The source code 13 is described in a programming language that is a high-level language. The source code 13 allows multiple values to be assigned to the same variable. The storage unit 11 stores a source code 14 (second source code) converted from the source code 13 as described later. The source code 14 is described in a programming language that is a high-level language like the source code 13. The source code 14 is in a static single assignment format (SSA format), and limits the assignment of a value to each variable to one time.

  When verifying the source code 13, the processing unit 12 first converts the source code 13 into a source code 14. In the conversion to the SSA format, the processing unit 12 detects the second assignment of the value to the same variable from the source code 13. Then, the processing unit 12 defines a new variable that is not used in the source code 13, changes the substitution destination of the value to the new variable, and replaces the subsequent reference of the variable with the reference of the new variable. I do. As a result, it is possible to limit the substitution of a value to each variable at most once.

  For example, the source code 13 includes an instruction to assign the value of the argument to the variable value, an instruction to assign a value obtained by adding a random number to the value of the variable value to the variable value, and an instruction to write the value of the variable value to the database. On the other hand, the source code 14 issues an instruction to assign the value of the argument to the variable value0, an instruction to assign the value obtained by adding a random number to the value of the variable value0 to the variable value1, and an instruction to write the value of the variable value1 to the database. Including.

  Next, the processing unit 12 searches the source code 14 for an instruction 15 (first instruction) indicating writing to the database. The processing unit 12 detects a variable in which the value to be written in the instruction 15 is stored. The variable in which the value to be written is stored is, for example, an operand described on the right side of the instruction 15. The processing unit 12 searches the source code 14 for an instruction 16 (second instruction) indicating the assignment of a value to the detected variable. The detected variable is described, for example, on the left side of the instruction 16. The processing unit 12 searches for the instruction 16 by scanning the instruction of the source code 14 from the instruction 15 toward the beginning of the source code 14, for example.

  For example, the processing unit 12 detects PutState (“key”, value 1) as the instruction 15 from the source code 14. This instruction writes the value of the variable value1 to the database as a value corresponding to "key". Then, the processing unit 12 scans the source code 14 retroactively from the instruction 15, and calculates value1 = value0 + rand. Int32 () is detected as the instruction 16. This instruction substitutes a value obtained by adding a random number to the value of the variable value0 to value1.

  The processing unit 12 specifies an acquisition method of a value to be substituted for the detected variable in the instruction 16, and determines whether writing to the database is a non-deterministic operation based on the identified acquisition method. The method of acquiring the value to be assigned to the variable can be specified from the right side of the instruction 16, for example. The non-deterministic operation is an operation in which the value to be written can change depending on the execution status other than the argument of the source code 13 and the data stored in the database.

  Causes of non-deterministic operation include, for example, that the value to be written depends on a random number or a time stamp (current time). Also, the cause of the non-deterministic operation includes, for example, that the value to be written depends on a global variable shared by a plurality of threads. The cause of the non-deterministic operation is, for example, that the value to be written depends on a value obtained by calling an API (Application Programming Interface) external to the server device that executes the processing specified in the source code 13. Is included. The cause of the non-deterministic operation includes, for example, that the value to be written depends on a data structure such as a Map object, which holds a plurality of data elements and the order between the data elements is not guaranteed.

  For example, the processing unit 12 determines that value1 = value0 + rand. When Int32 () is detected as the instruction 16, it is detected that the use of a random number is included in the method of acquiring the value substituted for the variable value1. Then, the processing unit 12 determines that the value assigned to the variable value1 in the instruction 16 is nondeterministic, and as a result, the value written to the database by the instruction 15 is nondeterministic.

  The processing unit 12 outputs a determination result as to whether writing to the database is a non-deterministic operation. For example, the processing unit 12 displays the determination result on a display of the program verification device 10. However, the processing unit 12 may record the determination result in a storage device of the program verification device 10 or may output the determination result to an output device other than the display. Further, the processing unit 12 may transmit the determination result to another information processing device. The determination result may include information for identifying the instruction 15 indicating writing to the database, or may include information for identifying the instruction 16 indicating substitution of a value to be written. If the right side of the instruction 16 includes a random number, for example, the processing unit 12 displays a warning on the display indicating that writing to the database defined by the source code 13 is a non-deterministic operation.

  According to the program verification device 10 of the first embodiment, the source code 13 is converted into the SSA format source code 14. Then, using the source code 14, an instruction related to a variable holding a value to be written to the database is searched to determine whether writing to the database is a non-deterministic operation. This makes it possible to detect a problem that the value written to the database changes during the development of the source code 13 depending on the execution status other than the argument and the data of the database. Therefore, when the processing specified in the source code 13 is executed in parallel by a plurality of computers, it is possible to suppress loss of consistency between databases due to a defect in the source code 13.

  Further, by using the source code 14 in the SSA format, it is easy to search for an instruction related to a value to be written to the database, and the speed of verification of nondeterministic operation can be increased. In the source code 14, the assignment to the variable holding the value to be written to the database is performed only once, and instructions are arranged in the order of data flow in the same function. Therefore, for example, by scanning the instructions in reverse order from the instruction 15 indicating writing to the database, the instruction 16 indicating assignment of a value to a variable can be searched at high speed. Further, compared to the method using the abstract syntax tree corresponding to the source code 13, the abstract syntax tree does not need to be repeatedly scanned to track the instruction related to the variable, and the search is speeded up. Also, compared to the method using symbolic execution, complicated path extraction does not need to be performed, and the search is speeded up.

[Second embodiment]
Next, a second embodiment will be described.
FIG. 2 is a diagram illustrating an example of the information processing system according to the second embodiment.

  The information processing system according to the second embodiment is a distributed database system that manages a block chain using a plurality of server devices. The block chain is a database showing the history of a series of transactions, and is a list in which blocks corresponding to those transactions are linked. A plurality of server devices hold the same contents of the block chain and mutually confirm each other, so that the legitimacy of the transaction can be secured.

  The information processing system according to the second embodiment includes a development device 100 and server devices 200, 200-1, 200-2, 200-3, and 200-4. The development device 100 and the server devices 200, 200-1, 200-2, 200-3, and 200-4 are connected to the network 30. The network 30 is a wide area network such as the Internet.

  The development device 100 is an information processing device used for developing a smart contract that is a program executed by the server devices 200, 200-1, 200-2, 200-3, and 200-4. The smart contract adds a new block to the end of the blockchain when a new transaction occurs. The development device 100 distributes the same smart contract to the server devices 200, 200-1, 200-2, 200-3, and 200-4. The development device 100 may be a client device or a server device.

  Each of the server devices 200, 200-1, 200-2, 200-3, and 200-4 is an information processing device that holds block chains having the same contents. The same smart contract is arranged in each of the server devices 200, 200-1, 200-2, 200-3, and 200-4. The server devices 200, 200-1, 200-2, 200-3, and 200-4 receive the input information indicating the newly generated transaction, and execute the smart contract using the received input information to execute the smart contract in parallel. Update the blockchain.

  The server device 200 holds the blockchain 210 and executes the smart contract to update the blockchain 210. The server device 200-1 holds the block chain 210-1 and executes the smart contract to update the block chain 210-1. The server device 200-2 holds the block chain 210-2, executes the smart contract, and updates the block chain 210-2. The server device 200-3 holds the block chain 210-3, executes the smart contract, and updates the block chain 210-3. The server device 200-4 holds the blockchain 210-4, executes the smart contract, and updates the blockchain 210-4.

FIG. 3 is a block diagram illustrating an example of hardware of the development device.
The development device 100 includes a CPU 101, a RAM 102, an HDD 103, an image signal processing unit 104, an input signal processing unit 105, a medium reader 106, and a communication interface 107 connected to a bus. The development device 100 corresponds to the program verification device 10 according to the first embodiment. The CPU 101 corresponds to the processing unit 12 according to the first embodiment. The RAM 102 or the HDD 103 corresponds to the storage unit 11 according to the first embodiment. The server devices 200, 200-1, 200-2, 200-3, and 200-4 have similar hardware.

  The CPU 101 is a processor that executes instructions of a program. The CPU 101 loads at least a part of the programs and data stored in the HDD 103 into the RAM 102 and executes the programs. Note that the CPU 101 may include a plurality of processor cores, and the development device 100 may include a plurality of processors. A set of multiple processors may be referred to as a “multiprocessor” or simply “processor”.

  The RAM 102 is a volatile semiconductor memory that temporarily stores programs executed by the CPU 101 and data used by the CPU 101 for calculations. The development device 100 may include a type of memory other than the RAM, or may include a plurality of memories.

  The HDD 103 is a non-volatile storage that stores an OS (Operating System), software programs such as middleware and application software, and data. Note that the development device 100 may include another type of storage such as a flash memory or an SSD (Solid State Drive), or may include a plurality of storages.

  The image signal processing unit 104 outputs an image to a display 111 connected to the development device 100 according to a command from the CPU 101. As the display 111, an arbitrary type of display such as a CRT (Cathode Ray Tube) display, a liquid crystal display (LCD: Liquid Crystal Display), and an organic EL (OEL: Organic Electro-Luminescence) display can be used.

  The input signal processing unit 105 receives an input signal from the input device 112 connected to the development device 100. As the input device 112, any type of input device such as a mouse, a touch panel, a touch pad, and a keyboard can be used. Further, a plurality of types of input devices may be connected to the development device 100.

  The medium reader 106 is a reading device that reads programs and data recorded on the recording medium 113. As the recording medium 113, for example, a magnetic disk such as a flexible disk (FD: Flexible Disk) or an HDD, an optical disk such as a CD (Compact Disc) or a DVD (Digital Versatile Disc), a magneto-optical disk (MO: Magneto-Optical disk), A semiconductor memory or the like can be used. The medium reader 106 stores programs and data read from the recording medium 113 in the RAM 102 or the HDD 103, for example.

  The communication interface 107 is an interface that is connected to the network 30 and communicates with information processing devices such as the server devices 200 and 200-1 to 200-4 via the network 30. The communication interface 107 is a wired communication interface connected to a wired communication device such as a switch or a router. However, a wireless communication interface connected to a wireless communication device such as a base station or an access point may be used.

FIG. 4 is a diagram illustrating an example of a data structure of a block chain.
Each of the server devices 200, 200-1, 200-2, 200-3, and 200-4 holds a block chain having a data structure as shown in FIG. The block chain includes a plurality of blocks such as blocks 40, 40-1, and 40-2. One block indicates one transaction. The block 40-1 is a block preceding the block 40. Block 40-2 is a block subsequent to block 40. Each block can hold data in a key-value format, which is a set of a key and a value, for example. Block 40 includes hash value 41, transaction data 42, public key 43, and signature 44. Other blocks such as the blocks 40-1 and 40-2 have the same data structure as the block 40.

  The hash value 41 is a hash value calculated by inputting the entirety of the preceding block 40-1 to a predetermined hash function. The hash value 41 associates the block 40 with the preceding block 40-1. In addition, the block 40-2 is associated with the preceding block 40 by the hash value included in the block 40-2. The transaction data 42 indicates the content of the transaction such as the transaction amount.

  The public key 43 is the public key of the business partner. It is expected that the trading partner of the transaction indicated by the block 40 will be the subject of the transaction indicated by the subsequent block 40-2. Therefore, the signature included in the subsequent block 40-2 can be verified using the public key 43. The signature 44 is a digital signature generated using a private key of a business entity (transaction source). The business entity of the transaction indicated by block 40 is expected to be the trading partner of the transaction indicated by block 40-1 at the preceding stage. Therefore, the signature 44 of the block 40 can be verified using the public key of the preceding block 40-1.

Next, problems in the development of a smart contract will be described.
FIG. 5 is a diagram illustrating an example of a non-deterministic operation of the smart contract.
The server devices 200, 200-1, 200-2, 200-3, and 200-4 receive the same input information, execute the same smart contract, and execute the block chains 210, 210-1, and 210-2 in parallel. , 210-3, 210-4. The contents of the updated block chains 210, 210-1, 210-2, 210-3, 210-4 are required to be the same. Therefore, the smart contract ensures that the value to be written to the blockchain is uniquely determined from the input information and the contents of the blockchain before update, and is not determined depending on other external states. Is required.

  If the value to be written to the blockchain depends only on the input information and the contents of the blockchain before updating, it can be said that the writing is deterministic. On the other hand, if the value to be written to the block chain depends on an external state other than the input information and the contents of the block chain before updating, it can be said that the writing is non-deterministic. Dependencies on external states include the use of random numbers, the use of timestamps, calling external APIs, referencing global variables, and iteratively referencing Map objects.

  If a random number is used, the value written to the blockchain will change randomly. When a time stamp is used, the value written to the blockchain changes depending on the time at which the smart contract is executed. When an external API is called, it is not guaranteed that information received from outside the server device by calling the external API is unchanged, and the value to be written in the block chain changes depending on the server device.

  When referring to a global variable, the value of the global variable referred to by a certain thread may be rewritten by another thread, and the value to be written to the block chain changes depending on the execution timing of a plurality of threads on the same server device. The Map object is a data structure capable of storing a plurality of data elements (sometimes called entries or records), and the storage order of the plurality of data elements is not guaranteed. Therefore, when a plurality of data elements stored in the Map object are sequentially referred to using a repetitive structure such as a for statement, the reference order of the plurality of data elements changes depending on the server device, and the value written in the block chain changes. .

  For example, it is assumed that the smart contract 51 that writes a time stamp (current time) in the block chain is arranged in the server devices 200, 200-1, 200-2, 200-3, and 200-4. Then, the values written in the block chains 210, 210-1, 210-2, 210-3, and 210-4 are not necessarily the same. For example, the time “10:20:06 430Z” is written in the block chain 210. The time “10:20:06 450Z” is written in the block chain 210-1. The time “10:20:06 450Z” is written in the block chain 210-2. The time “10:20:06 400Z” is written in the block chain 210-3. Time “10:20:06 419Z” is written in the block chain 210-4.

  If a smart contract in which writing to the blockchain becomes a non-deterministic operation is arranged in the server device 200, 200-1, 200-2, 200-3, 200-4, a problem occurs in the information processing system. Therefore, the development device 100 verifies that the developed smart contract does not include a non-deterministic operation.

FIG. 6 is a diagram illustrating an example of a smart contract.
The development device 100 stores the developed smart contract. The smart contracts 52 and 53 are examples of a smart contract to be verified.

  The smart contract 52 includes a function Init. The function Init receives four arguments args [0] to args [3] when called. The function Init assigns the character string of the argument args [0] to the variable A, assigns an integer random number to the variable Aval, assigns the character string of the argument args [2] to the variable B, and assigns the argument args [3] to the variable B. The integer represented by the character string is assigned to a variable Bval. The random number is a function rand. It is obtained by calling Int32.

  If the character string of the argument args [3] cannot be converted to an integer, the function Init outputs an error message. The function Init uses the character string of the variable A as a key and writes a character string representing an integer of the variable Aval as a value into the block chain. Writing to the block chain is performed by calling the function PutState. If an error occurs at this time, the function Init outputs an error message. The function Init uses the character string of the variable B as a key and writes a character string representing an integer of the variable Bval as a value into the block chain. If an error occurs at this time, the function Init outputs an error message.

  The smart contract 53 defines a character string type variable A, an integer type variable Aval, and an integer type variable X. The smart contract 53 assigns the character string “key” to the variable A, assigns the integer “1” to the variable Aval, and assigns an integer random number to the variable X. The smart contract 53 adds the value of the variable X to the value of the variable Aval, and substitutes the addition result for the variable Aval. Then, the smart contract 53 uses the character string of the variable A as a key and writes a character string representing an integer of the variable Aval as a value into the block chain.

  As a method of verifying the nondeterministic operation of the smart contract, a method using an abstract syntax tree or a method using symbolic execution can be considered. In the following, a method using an abstract syntax tree and a method using symbolic execution will be described.

FIG. 7 is a diagram illustrating a first example of an abstract syntax tree.
The abstract syntax tree 61 is an abstract syntax tree generated from the smart contract 52. The abstract syntax tree 61 is tree structure data representing the syntax of the smart contract 52 that is the source code. The abstract syntax tree 61 includes a node indicating a variable declaration (variable declaration) and a node indicating assignment of a value to a variable (assignment operation). Further, the abstract syntax tree 61 has, as child nodes of the node indicating the assignment operation, a node indicating the assignment destination variable (the variable on the left side), a node indicating the operator, and a variable storing the assignment value (the variable on the right side). , A node indicating a call of a function for calculating an assignment value (function call), and the like. Further, the abstract syntax tree 61 includes a node indicating a variable as an argument of a function as a child node of a node indicating a function call.

  When verifying whether writing to the block chain is non-deterministic using the abstract syntax tree 61, the following verification method can be considered. First, the abstract syntax tree 61 is sequentially scanned from the root node by a breadth-first search or a depth-first search, and a node of a function call indicating writing to a block chain is searched. When the node of the function call is detected, the variable that stores the value to be written to the block chain is specified based on the child node.

  Then, the abstract syntax tree 61 is again scanned in order from the root node to search for a node indicating an assignment operation for assigning a value to the variable. If a variable exists on the right side of the detected assignment operation, the abstract syntax tree 61 is again scanned in order from the root node to search for a node indicating an assignment operation for assigning a value to the variable. By repeating this, the process of calculating the value to be written to the block chain is tracked. In the process of calculating the value to be written, if an operation that causes nondeterminism is performed, such as calling a function for obtaining a random number or calling a function for obtaining a time stamp, it is determined that writing is a nondeterministic operation. .

  For example, in the example of FIG. 7, first, a node indicating a call to the function PutState is detected, and a node indicating a variable A and a node indicating a variable Aval are detected as nodes indicating arguments of the function PutState. Then, the abstract syntax tree 61 is again scanned in order from the root node, and a node indicating an assignment operation for assigning the value of the argument args [0] to the variable A, and the function rand. A node indicating an assignment operation for assigning the return value of Int32 is detected. The function rand. Since Int32 is a function for obtaining a random number, the value to be written depends on the random number, and it is determined that writing to the block chain is non-deterministic.

  However, the abstract syntax tree 61 does not express the order relation among a plurality of operations. Further, the value substitution for the same variable may be performed a plurality of times, and a plurality of nodes indicating the substitution operation for the same variable may exist in the abstract syntax tree 61. For this reason, there is a possibility that nodes related to variables storing values to be written in the block chain are dispersed in various places in the abstract syntax tree 61, and the scanning of the abstract syntax tree 61 is repeated many times.

  Therefore, the number of nodes in the abstract syntax tree 61 increases as the size of the smart contract 52 increases, and the execution time of program verification increases. For example, an abstract syntax tree including about 600 nodes may be generated from about 160 lines of source code. Also, an abstract syntax tree including about 7500 nodes may be generated from about 1700 lines of source code. As a result, program verification may be inefficient.

FIG. 8 is a diagram illustrating a second example of the abstract syntax tree.
The abstract syntax tree 62 is an abstract syntax tree generated from the smart contract 53. When verifying whether writing to the block chain is non-deterministic using the abstract syntax tree 62, a verification method similar to that of the above-described abstract syntax tree 61 is performed.

  For example, in the example of FIG. 8, a node indicating a call to the function PutState is detected, and a node indicating the variable A and a node indicating the variable Aval are detected as nodes indicating the arguments of the function PutState. Then, the abstract syntax tree 62 is scanned again in order from the root node, and a node indicating an assignment operation for assigning the character string “key” to the variable A is detected. Further, a node indicating an assignment operation of adding the value of the variable X to the value of the variable Aval and assigning the result to the variable Aval is detected. There is no cause of nondeterminism in these assignment operations themselves.

  On the other hand, the value before the variable Aval and the value of the variable X are used in the substitution operation of the variable Aval. Therefore, the abstract syntax tree 62 is scanned again in order from the root node, and a node indicating an assignment operation for assigning an integer “1” to a variable Aval and a function rand. A node indicating an assignment operation for assigning the return value of Int32 is detected. The function rand. Since Int32 is a function for obtaining a random number, the value to be written depends on the random number, and it is determined that writing to the block chain is non-deterministic. As described above, the scanning of the abstract syntax tree 62 is repeated many times, and the verification of the nondeterministic operation becomes inefficient.

FIG. 9 is a diagram illustrating an example of symbolic execution.
Symbolic execution is a static analysis method that analyzes a source code and detects a plurality of different execution paths. In symbolic execution, an abstract symbol is substituted for a variable instead of a specific value, and the source code is virtually executed, and the operation result is represented by an expression using the symbol. The execution path is detected by tracing a change in the value of a variable represented by an expression using a symbol.

  The symbolic execution flow 63 represents processing steps of the symbolic execution of the smart contract 52. In the process p1, the symbol a0 is assigned to the variable A, the symbol aval0 is assigned to the variable Aval, the symbol b0 is assigned to the variable B, the symbol bval0 is assigned to the variable Bval, and the symbol e0 is assigned to the variable err. The process p2 determines whether the value of the variable err is not nil (empty character), that is, whether the symbol e0 is not nil. The execution path branches to processing p3 and processing p4 according to the comparison between the symbol e0 and nil. When the symbol e0 is nil (when the condition “e0! = Nil” is false), the process p3 is executed. In the process p3, the symbol a0 is used as a key, and a character string representing the symbol aval0 is written into the block chain as a value. When the symbol e0 is not nil (when the condition “e0! = Nil” is true), the process p4 is executed. The process p4 outputs an error.

  The path table 64 is a table indicating execution paths detected by symbolic execution. The path table 64 includes items of a path ID, a path condition, and a path. The path ID is an identifier for identifying the detected execution path. The path condition is a condition to be satisfied by the symbol in order to select the execution path, that is, a condition of a value to be assigned to a variable. A path is a series of processing steps that the execution path passes.

  Two execution paths are detected from the symbolic execution flow 63. One execution path is an execution path selected when the symbol e0 is nil, and passes through the processes p1, p2, and p3. The other execution path is an execution path selected when the symbol e0 is not nil, and passes through the processes p1, p2, and p4.

  When using symbolic execution to verify whether writing to the block chain is non-deterministic, first determine the path conditions for each execution path by symbolic execution, and then enter multiple input values that match the path conditions for each execution path. Prepare as test data. Then, a plurality of input values are given to the smart contract 52, the execution result is observed, and it is determined whether an unintended change in the execution result has occurred. If there is an unintended change in the execution result, it is estimated that the smart contract 52 includes a non-deterministic operation. For example, if an input value given in the hope that a certain execution path is selected gives an unintended output when another execution path is selected, it is determined that there is nondeterminism that was not analyzed by symbolic execution Is done.

  However, as the size of the smart contract 52 increases, the number of conditional branches in the symbolic execution flow 63 increases, so that the number of execution paths to be detected increases and the execution time of program verification increases. In symbolic execution, a constraint solver that performs mathematical processing such as an SMT (Satisfiability Modulo Theories) solver is used to calculate path conditions for each execution path. However, for example, when information for determining a path condition is insufficient in the smart contract 52, a path condition for each execution path cannot be calculated by a constraint solver. In that case, test data cannot be efficiently generated.

  Therefore, the development device 100 according to the second embodiment converts the smart contracts 52 and 53 into a static single assignment (SSA) format, and performs non-deterministic operation of the smart contracts 52 and 53 by static analysis of the SSA source code. Verify

FIG. 10 is a diagram illustrating an example of the SSA source code.
The development device 100 converts the smart contract 52 into an SSA source code 71 and stores it, and converts the smart contract 53 into an SSA source code 72 and stores it. The SSA source codes 71 and 72 are semantically equivalent to the smart contracts 52 and 53. However, unlike the smart contracts 52 and 53, the SSA source codes 71 and 72 have a restriction that the assignment operation for one variable is performed only once. The conversion from the smart contracts 52, 53 to the SSA source codes 71, 72 can be performed as follows.

  The development device 100 scans a certain smart contract from the beginning to the end, and detects a second assignment operation for the same variable. When the second assignment operation is detected, the development device 100 defines a new variable that is not used in the smart contract and rewrites the assignment destination of the second assignment operation with the new variable. Then, the development device 100 rewrites the reference of the variable in the subsequent processing to the reference of the new variable. For the third and subsequent assignment operations, a new variable is defined each time, and reference to the subsequent variables is rewritten. As a result, the assignment of a value to one variable can be limited to one without changing the meaning of the program.

  The SSA source code 71 includes a function Init as in the smart contract 52. The SSA source code 71 assigns a character string array including four character strings as arguments to a variable t1, assigns the first character string of the variable t1 to a variable t2, and assigns an integer random number to a variable t3. . Thereafter, the SSA source code 71 calls the function PutState with the variables t2 and t3 as arguments, and substitutes the return value of the function PutState into the variable t45.

  The SSA source code 72 defines a character string type variable A as the variable t0, defines an integer type variable Aval as the variable t1, and defines an integer type variable X as the variable t2. The SSA source code 72 substitutes the character string “key” for a newly defined variable t3 corresponding to the variable t0. Further, the SSA source code 72 substitutes an integer “1” for a newly defined variable t4 corresponding to the variable t1. In addition, the SSA source code 72 substitutes an integer random number for a newly defined variable t5 corresponding to the variable t2. The SSA source code 72 calculates the sum of the value of the variable t4 and the value of the variable t5, and substitutes it for a new variable t6. Then, the SSA source code 72 calls the function PutState with the variables t3 and t6 as arguments, and substitutes the return value of the function PutState into a new variable t7.

  By using such SSA source codes 71 and 72, the development device 100 can efficiently verify the non-deterministic operation of the smart contracts 52 and 53. The development device 100 scans a certain SSA source code from the beginning to the end, and searches for a write operation indicating writing to the block chain. Upon detecting the write operation, the development device 100 specifies the variable used as the argument of the write operation, scans the SSA source code in the reverse direction, and performs an assignment operation indicating the assignment of the value to the specified variable. Search for.

  When detecting the assignment operation, the development device 100 checks whether a nondeterministic operation causing nondeterminism, such as calling a function for obtaining a random number, exists on the right side of the assignment operation. If there is another variable for which there is no non-deterministic operation on the right side of the assignment operation, the development device 100 scans the SSA source code further in the reverse direction to indicate the assignment of a value to the other variable. Search for. By recursively searching for a variable assignment operation, it is possible to search for a non-deterministic operation that affects a variable that stores a value to be written to the block chain.

  For example, for the SSA source code 71, the development device 100 detects the call of the function PutState and specifies the variables t2 and t3, which are the arguments. The development device 100 scans the SSA source code 71 from the calling position of the function PutState toward the top, and detects an assignment operation of the variable t3. On the right side of the assignment operation of the variable t3, the function rand. Since Int32 has been called, the development device 100 determines that the value of the variable t3 written in the block chain depends on the random number and is nondeterministic.

  Further, with respect to the SSA source code 72, the development device 100 detects the call of the function PutState and specifies the variables t3 and t6, which are the arguments. The development device 100 scans the SSA source code 72 from the calling position of the function PutState toward the beginning, and detects an assignment operation of the variable t6. Since the right side of the assignment operation of the variable t6 does not include the nondeterministic operation but includes the variables t4 and t5, the development device 100 adds the variables t4 and t5 to the search target. The development device 100 scans the SSA source code 72 further toward the top, and detects an assignment operation of the variable t5. On the right side of the assignment operation of the variable t5, the function rand. Since Int32 has been called, the development device 100 determines that the value of the variable t6 written in the block chain depends on the random number and is nondeterministic.

  Thus, the SSA source codes 71 and 72 describe various operations in the same function in the order of data flow. Further, the SSA source codes 71 and 72 limit the assignment operation to one variable to one time, and thereafter allow only reference to the variable. Therefore, the development device 100 can determine the non-determinism by scanning the SSA source codes 71 and 72 only once in reverse order from the position of the write operation of the block chain.

Next, functions and processing procedures of the development device 100 will be described.
FIG. 11 is a block diagram illustrating an example of functions of the development device.
The development device 100 includes a source code storage unit 121, an SSA source code storage unit 122, a control information storage unit 123, an SSA conversion unit 124, a non-deterministic detection unit 125, and a result display unit 126. The source code storage unit 121, the SSA source code storage unit 122, and the control information storage unit 123 can be implemented using the storage area of the RAM 102 or the HDD 103. The SSA conversion unit 124, the non-determinism detection unit 125, and the result display unit 126 can be implemented using a program executed by the CPU 101.

  The source code storage unit 121 stores a smart contract to be verified, such as the smart contracts 52 and 53. The SSA source code storage unit 122 stores the SSA format source code converted from the smart contract to be verified, such as the SSA source codes 71 and 72. The control information storage unit 123 stores control information that is referred to when verifying a non-deterministic operation of the smart contract. The control information includes a program description indicating a blockchain write operation and a program description indicating a nondeterministic operation that causes nondeterminism. These program descriptions are defined in advance for each programming language.

  The SSA conversion unit 124 reads the smart contract to be verified from the source code storage unit 121, converts the smart contract into an SSA source code, and stores the SSA source code in the SSA source code storage unit 122. The non-deterministic detection unit 125 reads the SSA source code from the SSA source code storage unit 122, refers to the control information stored in the control information storage unit 123, and performs a non-deterministic operation that affects the value written to the block chain. Search from source code. The result display unit 126 displays the detection result of the non-deterministic operation on the display 111. The detection result includes a message indicating whether writing to the block chain is non-deterministic. If the writing to the blockchain is non-deterministic, the detection result may include the identification information of the non-deterministic operation in question.

FIG. 12 is a diagram illustrating an example of a table held by the development device.
The write operation table 131 is created in advance and stored in the control information storage unit 123. The write operation table 131 includes items of a programming language and an operation. A programming language is a high-level language used for describing a smart contract that is a source code. The operation of the write operation table 131 is a program description used for writing to a block chain in a specific programming language. For example, the name of a function used for a write operation and the number of arguments of the function are defined.

  For example, in a certain programming language (languageX), a program description called PutState (key, value) is used as a write operation. In another programming language (languageY), a program description called putState (key, value) is used as a write operation.

  The non-deterministic operation table 132 is created in advance and stored in the control information storage unit 123. The non-deterministic operation table 132 includes items of programming language, category, and operation. A programming language is a high-level language used for describing a smart contract that is a source code. A category is a type of nondeterministic operation that causes nondeterminism. As described above, the category includes a random number, a time stamp, an external API, a global variable, and a Map object. The operation of the non-deterministic operation table 132 is a program description used for the non-deterministic operation in a specific programming language. For example, the name of the function used for the non-deterministic operation and the number of arguments of the function are defined.

  For example, in some programming languages, the non-deterministic operation of obtaining random numbers is rand. Int32 () program description and rand. A program description called Float32 () is used. Also, in some programming languages, time.time. A program description called Now () is used.

  The detection result table 133 is generated by the non-deterministic detection unit 125 for verification of one smart contract. Information of the detection result table 133 may be stored in the RAM 102 or the HDD 103, or may be displayed on the display 111. The detection result table 133 includes items of position, non-deterministic operation, and category.

  The position is a position on the smart contract in which a non-deterministic operation affecting the value written to the block chain is described, and is specified by, for example, the line number of the smart contract. As the nondeterministic operation in the detection result table 133, a program description of the nondeterministic operation is registered. The category is a category defined in the non-deterministic operation table 132.

FIG. 13 is a flowchart illustrating an example of a procedure of program verification.
(S10) The SSA conversion unit 124 converts the smart contract that is the source code into the SSA format source code (SSA source code). In the conversion into the SSA source code, the SSA conversion unit 124 detects the second and subsequent substitution operations for the same variable, replaces the substitution destination variable with a new variable, and refers to the subsequent variables to the new variable. Replace with the reference.

  (S11) In the first reading of the SSA source code, the non-deterministic detection unit 125 reads the first line of the SSA source code. In the second and subsequent reading of the SSA source code, the non-deterministic detection unit 125 reads a line next to the previously read line from the SSA source code.

  (S12) The non-deterministic detection unit 125 determines whether the row read in step S11 includes any of the write operations defined in the write operation table 131. If a write operation is included, the process proceeds to step S14; otherwise, the process proceeds to step S13.

  (S13) The non-deterministic detection unit 125 determines whether the last line of the SSA source code has been read in step S11. When reading up to the last line of the SSA source code, the program verification ends, assuming that the smart contract to be verified does not include a block chain write operation. If the last line of the SSA source code has not been reached, the process proceeds to step S11.

  (S14) The non-deterministic detection unit 125 extracts a variable storing a value to be written to the block chain from the row read in step S11. The non-deterministic detection unit 125 registers the extracted variables as variables to be subsequently searched.

(S15) The non-deterministic detection unit 125 reads the previous line from the SSA source code.
(S16) The non-deterministic detection unit 125 determines whether the line read in step S15 is an assignment statement for assigning a value to any of the variables registered as a search target. If it is a substitution statement of a registered variable, the process proceeds to step S17; otherwise, the process proceeds to step S20.

  (S17) The non-deterministic detection unit 125 determines whether the row read in step S15 includes any non-deterministic operation defined in the non-deterministic operation table 132. If it includes a non-deterministic operation, the process proceeds to step S21. If it does not include a non-deterministic operation, the process proceeds to step S18.

  (S18) The non-deterministic detection unit 125 determines whether the line read in step S15 includes a variable indicating an assignment value, that is, whether the right side of the assignment statement includes another variable. If the variable includes the variable indicating the substitution value, the process proceeds to step S19; otherwise, the process proceeds to step S20.

(S19) The non-deterministic detection unit 125 extracts a variable indicating a substitution value from the line read in step S15. The non-deterministic detection unit 125 additionally registers the extracted variable as a search target variable.
(S20) The non-deterministic detection unit 125 determines whether the first line of the SSA source code has been read in step S15. When reading up to the first line of the SSA source code, the non-deterministic detection unit 125 determines that the write operation of the block chain is not a non-deterministic operation. Then, the program verification ends. At this time, the result display unit 126 may display on the display 111 a message indicating that a nondeterministic operation has not been detected. On the other hand, if the first line of the SSA source code has not been reached, the process proceeds to step S15.

  (S21) The non-deterministic detection unit 125 determines that the write operation of the block chain is a non-deterministic operation. The non-deterministic detection unit 125 determines the position, non-deterministic operation, and category of the line read in step S15, and generates the detection result table 133. Then, the program verification ends. At this time, the result display unit 126 may display a message to the effect that the non-deterministic operation has been detected on the display 111, and may display information of the detection result table 133 on the display 111 as the cause of the non-deterministic operation. .

  In the above, an example in which a value to be written to the block chain is calculated from a value obtained by a non-deterministic operation such as a random number or a time stamp as the non-deterministic operation has been described. On the other hand, by using the value obtained by the non-deterministic operation for flow control such as conditional branching, the method of writing to the block chain may be switched to a non-deterministic operation. The development device 100 can also detect a non-deterministic operation caused by such flow control.

  For example, in the flowchart of FIG. 13, the non-deterministic detection unit 125 reads the immediately preceding line from the SSA source code, and if the read line is not an assignment statement of a registered variable, the read line is replaced with the value of some variable. It is determined whether the conditional branch statement depends on it. If the conditional branch statement depends on the value of any variable, the non-deterministic detection unit 125 additionally registers a variable included in the conditional branch statement as a search target. Thus, it is possible to detect a non-deterministic operation in which whether or not a certain write operation is performed depends on a random number or a time stamp.

FIG. 14 is a diagram showing another example of the smart contract and the SSA source code.
The smart contract 54 includes a function main. The function main assigns a random number of a floating-point real number to a variable A. The function main compares the value of the variable A with the real number “0.5”. When the value of the variable A is larger than 0.5, the function main calls the function PutState with the character string “Success” and the boolean value “True” as arguments. On the other hand, when the value of the variable A is 0.5 or less, the function main calls the function PutState with the character string “Success” and the Boolean value “False” as arguments. Whether the true / false value written to the block chain becomes “True” or “False” depends on a random number.

  The development device 100 converts the smart contract 54 into the SSA source code 73. The SSA source code 73 substitutes a random number of a floating-point real number into a variable t0, and substitutes a boolean value indicating whether or not the value of the variable t0 is greater than 0.5 into a variable t1. The SSA source code 73 jumps to the first address when the variable t1 indicates true, and jumps to the third address when the variable t1 indicates false. At the first address, the SSA source code 73 substitutes a predetermined character string for the variable t5, calls the function PutState with the variable t5 included in the argument, and substitutes the return value of the function PutState for the variable t6. At the third address, the SSA source code 73 substitutes a predetermined character string for the variable t10, calls the function PutState with the variable t10 as an argument, and substitutes the return value of the function PutState for the variable t11.

  Here, variables such as variables t5 and t10 used as arguments of the function PutState and the variable t1 used in the conditional branch statement do not have an assignment relationship on the SSA source code 73. However, the development device 100 can also detect the nondeterministic operation caused by the control flow from the SSA source code 73 by tracking the variable t1 used in the conditional branch statement.

  According to the information processing system of the second embodiment, the smart contract is converted into the SSA source code, a predetermined write operation is detected on the SSA source code, and the SSA source code is scanned in reverse order to affect the write value. Is detected.

  This makes it possible to detect a problem that the value to be written in the block chain changes depending on the input information and the external state other than the contents of the block chain before writing. Therefore, it is possible to prevent the blockchain from being lost in consistency among the plurality of server devices. In addition, by using the SSA source code, it is possible to quickly search for the assignment operation related to the value to be written to the block chain with a small number of scans, and to execute the non-deterministic operation verification of the smart contract in a short time. it can.

Reference Signs List 10 program verification device 11 storage unit 12 processing unit 13, 14 source code 15, 16 instruction

Claims (6)

On the computer,
Converting a first source code that allows multiple values to be assigned to the same variable into a second single source code in a static single assignment format that limits the assignment of a value to each variable to one time;
The second source code is searched for a first instruction indicating writing to a database, a variable storing a value to be written in the first instruction is detected, and the detection is performed from the second source code. Search for a second instruction indicating the assignment of a value to the assigned variable,
The non-determination that the writing to the database depends on the execution status other than the argument of the first source code and the data of the database based on a method of obtaining a value substituted for the detected variable in the second instruction. Judge whether it is a dynamic operation,
A program verification program that executes processing. In the search for the second instruction, an instruction included in the second source code is scanned from the first instruction toward the beginning of the second source code.
The program verification program according to claim 1. The computer further comprises:
In the second instruction, another variable referred to when assigning a value to the detected variable is detected, and the instruction is scanned from the second instruction toward the head of the second source code. Searching for a third instruction indicating the assignment of a value to the other detected variable,
Tracking a method of obtaining a value to be assigned to the detected variable based on the third instruction;
The program verification program according to claim 1, wherein the program is executed. In the determination of the non-deterministic operation, when the acquisition method of the value substituted for the detected variable includes at least one of acquisition of a random number, acquisition of a time stamp, and reference to a global variable, the writing to the database is performed by the Determine that the operation is non-deterministic;
The program verification program according to claim 1. Computer
Converting a first source code that allows multiple values to be assigned to the same variable into a static single assignment type second source code that limits the assignment of a value to each variable to one time;
The second source code is searched for a first instruction indicating writing to a database, a variable storing a value to be written in the first instruction is detected, and the detection is performed from the second source code. Search for a second instruction indicating the assignment of a value to the assigned variable,
The non-determination that the writing to the database depends on the execution status other than the argument of the first source code and the data of the database based on a method of obtaining a value substituted for the detected variable in the second instruction. Judge whether it is a dynamic operation,
Program verification method. A storage unit that stores a first source code that allows a plurality of values to be substituted for the same variable;
The first source code is converted to a second source code in a static single assignment format that limits assignment of a value to each variable to one time, and writing from the second source code to a database is performed. A second instruction that indicates a substitution of a value into the detected variable from the second source code by searching for a variable in which a value to be written in the first instruction is stored. Based on a method of acquiring a value to be substituted for the detected variable in the second instruction, the execution status of the writing to the database being other than the argument of the first source code and the data of the database. A processing unit that determines whether or not the non-deterministic operation depends on
A program verification device having:

Images