Verification system and verification method for Byzantine fault detection

Abstract

The invention provides a verification system and a verification method for Byzantine fault detection, and the verification system carries out the verification of a transaction after the transaction is executed in a first computer system. In particular, a verification system stores transaction management data for each transaction executing in a first computer system into a second computer system. When executing the transaction in response to the transaction request, the first computer system returns a result containing an attestation regarding execution of the transaction. For each transaction, the transaction management data includes data that the transaction request has, and includes data derived from a result of the transaction and data that has an attestation of the transaction. The verification system determines, from the second computer system, transaction management data that verifies the object transaction, and verifies based on the determined transaction management data.

Description

Technical Field

[0001] The present invention generally relates to verification of Byzantine fault detection. Background Art

[0002] In recent years, inspection fraud and data tampering, particularly in the manufacturing industry, have become increasingly prevalent, both domestically and internationally, and have become a social problem. Furthermore, cyberattacks against businesses and government agencies are also on the rise. To combat these malicious attacks, Byzantine Fault Tolerance (BFT) and Byzantine Fault Detection (BFD) technologies have been extensively researched.

[0003] Byzantine fault tolerance techniques are also used in database systems, enabling transaction processing while maintaining indivisibility, consistency, and independence. Using these techniques to mitigate Byzantine faults requires multiple database replicas. Assuming the number of faulty replicas allowed is f, at least 3f + 1 replicas are required. Malicious attacks typically affect replicas within the same administrative domain, so these multiple replicas must operate in different administrative domains. Therefore, to mitigate Byzantine faults, database systems typically operated by a single organization must be run by at least four organizations with different administrative authorities, placing a significant management burden. Here, an "administrative domain" refers to the collection of nodes and networks operating under a single organization and administrative authority.

[0004] Byzantine fault detection technology is one method for mitigating this burden while countering malicious attacks. Since these detection technologies are designed solely for Byzantine fault detection, they cannot continue to function like shielding technologies. However, for a faulty replica number f, as long as there are f+1 replicas, they can be utilized. In other words, Byzantine faults can be detected in at least two management domains. For example, Patent Document 1 discloses a technique known as Byzantine fault detection technology, which uses two database replicas in two components called the Ledger and Auditor to synchronously detect Byzantine faults. Prior art literature Patent Literature

[0005] Patent Document 1: Japanese Patent No. 7152828 Summary of the Invention Technical problem to be solved by the invention

[0006] However, if synchronous consensus processing (agreement formation) between the first computer system (eg, Ledger) and the verification system (eg, Auditor) is required in transaction execution, the latency is large and the transaction throughput is reduced. Technical means to solve the problem

[0007] After a transaction is executed in the first computer system, the verification system performs verification regarding the transaction.

[0008] Specifically, the verification system stores transaction management data for each transaction executed in the first computer system in a second computer system. When a transaction is executed in response to a transaction request, the first computer system returns a transaction result that includes proof of the execution of the transaction. For each transaction, the transaction management data includes the data contained in the transaction request and data derived from the transaction result and containing proof of the transaction. In response to the verification request, the verification system determines the transaction management data for the verification target transaction from the second computer system and performs verification based on the determined transaction management data. Effects of the Invention

[0009] Improve latency and increase transaction throughput. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 A configuration example of the entire system including the validator system according to the second embodiment is shown. Figure 2 An example of the structure of the Validator database is shown. Figure 3 An example of the structure of a Ledger database is shown. Figure 4 This shows an example of the structure of the transaction log table of the Validator database. Figure 5 This shows an example of the structure of the record table of the Validator database. Figure 6 This shows an example of the structure of the time management table of the Validator database. Figure 7 This shows an example of the structure of the transaction log table of the Ledger database. Figure 8 This shows an example of the structure of a record table in a Ledger database. Figure 9 An example of the process flow involving the Validator program in the process flow regarding transaction execution is shown. Figure 10 An example of a process flow involving a ledger server in a process flow related to transaction execution is shown. Figure 11 An example of the processing flow of the verification process is shown. Figure 12 An example of the processing flow of the status derivation process is shown. Figure 13An example of the processing flow of the graph generation process is shown. Figure 14 An example of the processing flow of the conflict confirmation process is shown. Figure 15 An example of the processing flow of the visibility confirmation process is shown. Figure 16 An example of the processing flow of the visible time update process is shown. Figure 17 An example of the visible end time of version "0" and the visible start time of version "1" is shown. Figure 18 An example of updating the visible end time of version "0" is shown. Figure 19 An example of updating the visible start time of version "1" is shown. Figure 20 Shows a structural example of a computer system. Figure 21 A configuration example of the entire system including the validator system according to the third embodiment is shown. Figure 22 A configuration example of the entire system including the validator system according to the first embodiment is shown. Figure 23 Algorithm 1 (processing flow of the log phase) is shown. Figure 24 Algorithm 2 (processing flow of the verification phase) is shown. DETAILED DESCRIPTION

[0011] In the following description, an "interface device" includes one or more interfaces. The one or more interfaces can be one or more communication interface devices of the same type (e.g., one or more NICs (Network Interface Cards)) or two or more communication interface devices of different types (e.g., a NIC and an HBA (Host Bus Adapter)).

[0012] In addition, in the following description, a "storage device" includes one or more memories. With respect to the storage device, at least one memory may be a volatile memory. The storage device is primarily used when the processor performs processing. In addition to the memory, the storage device may also include one or more non-volatile storage devices (e.g., HDD (Hard Disk Drive) or SSD (Solid State Drive)).

[0013] In the following description, "processor" includes more than one processor. The at least one processor is typically a microprocessor such as a CPU (Central Processing Unit). Each of the more than one processors can be single-core or multi-core. The processor can also include hardware circuitry that performs some or all of the processing.

[0014] In addition, in the following description, "program" is sometimes used as the subject to describe the processing, but the program is executed by a processor, thereby appropriately using a storage device (such as a memory) and / or an interface device (such as a communication port) to perform the prescribed processing, and thus the subject of the processing can also be set to the processor. The processing described with the program as the subject can also be the processing performed by a processor or a device having its processor. In addition, the processor can also include a hardware circuit (such as an FPGA (Field-Programmable Gate Array, Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit, Application Specific Integrated Circuit)) that performs a part of the processing or all of the processing. The program can also be installed from a program source to a device such as a computer. The program source can be, for example, a program distribution server or a computer-readable recording medium (such as a non-volatile recording medium). In addition, in the following description, two or more programs can be implemented as one program, or one program can be implemented as two or more programs.

[0015] In addition, in the following description, sometimes "program" is used as the subject to describe the process, but the program is executed by a processor, thereby appropriately using a storage device and / or an interface device, etc. to perform the prescribed process, and thus the subject of the process can also be set to the processor (or a device such as a controller with the processor). The program can also be installed to a device such as a computer from a program source. The program source can be, for example, a program distribution server or a computer-readable (e.g., non-volatile) recording medium. In addition, in the following description, two or more programs can be implemented as one program, or one program can be implemented as two or more programs. In addition, the function implemented by executing "xxx program" can be referred to as "xxx unit".

[0016] In the following description, when describing elements of the same type without distinguishing them from each other, common reference numerals are used in the reference numerals, and when distinguishing elements of the same type, the reference numerals are used.

[0017] In the following description, "record" and "entry" refer to a logical block of electronic data (eg, an object) viewed from a program such as an application.

[0018] In the following embodiments, a "Byzantine fault" may be any fault and may include a malicious internal attack such as tampering. [First embodiment]

[0019] First, Byzantine fault tolerance technology and Byzantine fault detection technology are explained.

[0020] Byzantine fault tolerance technology has been widely studied in the context of state machine replication (SMR) to shield against arbitrary failures, such as malicious attacks that tamper with data. In this specification, Byzantine fault tolerance technology based on SMR is categorized as BFT·SMR. To tolerate faulty replicas, BFT·SMR replicates client requests across multiple replicas. Assuming the number of faulty replicas allowed is f, at least 3f+1 replicas are required. In BFT·SMR, client requests are typically executed sequentially to achieve the same state across replicas.

[0021] Research is also underway to expand BFT·SMR for database systems. In this specification, these are categorized as BFT·DB. Byzantium is a BFT·DB that applies Byzantine fault tolerance technology to databases, enabling multiple transactions to be ACID and executed in parallel. Because Byzantium uses PBFT for replication, 3f+1 replicas are required. Basil broadcasts each transaction to multiple replicas, allowing independent decisions and votes on whether to commit or abort. The clients then collect their votes and make a final decision based on a quorum. Basil requires 5f+1 replicas to limit exchanges with replicas to a single round-trip communication consisting of sending, executing, and receiving the results of a transaction.

[0022] Byzantine fault detection technology handles Byzantine faults in a different way than BFT·SMR and BFT·DB. When detecting f faulty replicas, Byzantine fault detection (BFD) only requires f+1 replicas, but it cannot continue to operate like shielding technology. PeerReview, a pioneer in BFD research, verifies that the states between replicas are the same by generating a fully ordered execution log connected by a hash chain on the primary node and re-executing it sequentially on secondary nodes called witnesses. Due to its similar characteristics to SMR, PeerReview is classified as BFD·SMR. Although PeerReview can also be applied to database systems, the problem is that the sequential re-execution of the log on the secondary nodes hinders the parallel execution of transactions.

[0023] Patent Document 1 discloses a technique that uses two database replicas, each comprised of a Ledger and an Auditor, to synchronously detect Byzantine faults. Synchronization, as used herein, means that any inconsistencies between the two replicas are detected immediately during transaction execution. In contrast, the Validator of this embodiment (hereinafter referred to as "Validator" in the description of this embodiment) forgoes the tradeoff of synchronous Byzantine fault detection based on the interaction between the Ledger and Auditor, performing asynchronous Byzantine fault detection instead, thereby improving transaction throughput and latency performance.

[0024] The process of synchronous Byzantine fault detection is described as follows. 1) Auditor sorts the transaction requests from the client based on whether there are conflicts (sorting phase). 2) Ledger executes and commits transactions in the specified order (commit phase). 3) Auditor verifies the transaction execution results and execution order of Ledger (verification phase).

[0025] This three-phase protocol allows for immediate detection of Byzantine faults, such as transactions that violate strict serialization or data tampering, at any replica. However, during transaction execution, the ledger and auditor must simultaneously perform consensus (agreement formation) in both the sorting and verification phases, leading to significant latency.

[0026] The validator assumes that nodes with Byzantine faults can exhibit arbitrary behavior and that Byzantine faults can propagate between nodes in the same domain (if the domains are different, Byzantine faults will not propagate and there will be no collusion). Furthermore, the required number of replicas (the number of domains) is two, but more than two is possible.

[0027] The safety and liveness standards guaranteed by the Validator are described below. Safety means that the database system can guarantee strict serialization and provide the following system characteristics based on the number of faulty replicas. 1) When there are no faulty replicas: When both replicas are not faulty, the validator guarantees safety and liveness. 2) When only one replica is faulty: Validators guarantee safety when any replica fails. This means that normal clients can asynchronously detect Byzantine faults in the database system. For example, if the database system executes transactions in a schedule that violates strict serialization, normal clients can retroactively detect the failure. 3) When there are two faulty replicas: Validators do not guarantee safety or liveness when two replicas fail. However, as long as the management domains do not collude with each other, the probability of two replicas being illicitly identical is extremely low, so in most cases, a normal client can detect the failure (e.g., inconsistency in state such as tampering).

[0028] Figure 22 A configuration example of the entire system including the validator system according to the first embodiment is shown.

[0029] The Validator system consists of two components: the Validator and the Ledger. The Validator consists of a Validator client and a Validator database. Besides serving as a client for accessing the Ledger server, the Validator client also provides functions for asynchronous Byzantine fault detection, such as saving transaction request content and execution results to the Validator database. The Ledger executes and commits transactions based on client requests.

[0030] Validators and ledgers manage their own database replicas in separate administrative domains. Each replica stores not only the data read and written by transactions but also a deterministic program that defines the read and write logic. The client specifies the program's identifier and necessary parameters and requests the ledger to execute a transaction. Each replica can consist of a single node or multiple nodes for improved performance and crash resistance.

[0031] The basic concept of the asynchronous Byzantine fault detection protocol in the validator is that the validator subsequently verifies the correctness of transactions submitted by the ledger, rather than predetermining the order of transactions to ensure strict serialization, as in conventional synchronous protocols. To facilitate this post-hoc verification, the proposed protocol consists of a logging phase and a verification phase. In the logging phase, the validator client records the request content (such as the program identifier and parameters) and time before sending a transaction request to the ledger. Furthermore, when receiving the transaction execution result from the ledger, the content and time are recorded. In the verification phase, the validator client re-executes the transaction based on the transaction request content recorded in the logging phase, verifying that the execution result is the same as when the ledger submitted it. Furthermore, concurrent and conflicting transactions are identified based on the execution time and read / write objects, and the MVSG (Multi-Version Serialization Graph) is used to verify that the execution is strictly serializable. MVSG is a directed graph that not only includes the Reads-From relationships between transactions but also extends the edges related to the version order. By confirming that there are no cycles in the graph, it is determined whether the given schedule is serializable. Unlike serialization verification in a black box environment, serialization verification can be performed in polynomial time due to the premise of obtaining the version order. Specifically, let V be the number of nodes (here, the number of transactions) and E be the number of edges extended based on the conflict relationship, then serializability can be verified in O(V+E). The following is a detailed description of each stage.

[0032] Figure 23 Algorithm 1 (processing flow of the log phase) is shown.

[0033] In the logging phase, the client first records the transaction request received from the application in the Validator database along with the time it was received (the start time) (lines 1-2). The transaction request consists of <n, f, a, s>, where n is the unique transaction ID (e.g., a UUID) used to identify the request, f is the identifier of the program (the execution logic of the transaction), a is a parameter of the program, and s is the key shared by the Validator client and the Ledger, as well as the message authentication code generated from n, f, and a.

[0034] Next, the client sends a request to the Ledger and executes the transaction (line 4). Transaction processing in the Ledger is the same as the commit phase of the previous protocol, so detailed descriptions are omitted. However, the Ledger atomically reads and writes database records according to the content described in the program, and records the status of each transaction ID (committed or aborted). In addition, the Ledger generates the execution results of the program to the client, and generates input and output information during the transaction execution, called proofs, for each record read and written, and responds. The proof consists of <k, v, n, d, s>, where k is the primary key of the record, v is the version number of the record, n is the transaction ID, d is the set of the primary key and version number of the record used as input for the transaction, and s is the message authentication code generated by k, v, n, and d.

[0035] After receiving the execution result and proof from the Ledger, the client records them along with the time (end time) of receipt (lines 5-6). More specifically, the Read-Write set for the transaction is generated from the proof, associated with the transaction request recorded at the beginning, and saved. Here, the Read-Write set refers to the set of primary keys and version numbers of the records read and written by the transaction, not the record values ​​themselves. The Read-Write set can be generated from the proof's k, v, and d.

[0036] Figure 24 Algorithm 2 (processing flow of the verification phase) is shown.

[0037] Verification is performed on a per-record basis, either per version or per transaction. When performing verification on a per-record basis, the primary key and version number are specified, a certificate is obtained, and verification is performed after identifying the transaction that wrote that version (lines 2-3). When performing verification on a per-transaction basis, since the transaction ID is known in advance, verification is performed from line 3 onwards.

[0038] In the verification process of the verification phase, two checks are performed: input and output verification to verify whether the input and output of the transaction are correct (lines 3-6) and serializability verification to verify whether the transaction and the set of concurrent and conflicting transactions are executed according to the correct schedule (lines 7-9).

[0039] In the input and output verification, for all record versions written by the transaction, the proof of each record stored in the Validator database is obtained and its input and output are verified (lines 5-6). The main verification process is performed by the deriveStates() function. First, the set of input records used when outputting the record is obtained (lines 11-14). The primary key and version number of the input record are obtained from each proof. In addition, using the transaction ID also obtained from the proof, the program executed according to the transaction request and its parameters are obtained, and the program is executed again (lines 15-17). The state obtained after the second execution, that is, if the output record is inconsistent with the Ledger side, a verification error is issued, and if it is consistent, they are written to the Validator database (lines 18-21).

[0040] The main processing of serializability verification is the MVSG generation process performed by the createMVSG() function (lines 22-36) and the process of confirming whether there is a loop in the generated MVSG (lines 8-9). The MVSG retrieves the target transaction and concurrent candidate transactions (line 31), and when their candidate transactions have a conflicting relationship, it is generated by adding edges from the target transaction to the candidate transaction (lines 32-35). Concurrent candidate transactions are retrieved based on the start and end times associated with each transaction request and recorded in the log phase. In addition, whether there is a conflicting relationship is determined based on the records read and written by the transaction and its version using the Read-Write set of the same record (line 34). Even if there is a direct concurrent and non-conflicting relationship with the verification object transaction set as the starting point, since transactions in a transfer relationship may violate serializability, concurrent and conflicting transactions are recursively confirmed and appended to the graph (line 36).

[0041] Generating an MVSG as described above verifies that transaction execution on the ledger side is serializable by checking for loops. However, linearizability violations such as time travel anomalies cannot be detected. Therefore, as exemplified in the literature, improper transactions can occur, such as submitting transactions on a schedule that does not violate serializability while improperly referencing older versions. The time when each version can be read (called visible time) is determined based on the start and end times of transactions recorded on the client side. Strict serialization can be guaranteed by confirming whether the transaction reading a certain version is consistent with the visible time of that version.

[0042] Due to various reasons, such as client or ledger failures or network outages, even if a transaction request is sent, if no response is received, the logging phase may not complete normally. Here, we briefly explain the failure recovery process for such transactions.

[0043] During the fault recovery process, first, the uncertain transactions whose end times are not stamped are identified. For each uncertain transaction, the status of the transaction is queried from the Ledger. The query result, if the commit or abort is confirmed, uses the current time stamp to mark the end time. If the commit is complete, the Read-Write collection is also obtained and saved in association with the record of the transaction request. If the query result shows an unclear status, the transaction may be in progress, so the determination is postponed. If the retry is still unclear after a certain period of time, the end time is stamped in the same way as when the abort is completed. If the transaction processing in the Ledger (either commit or abort) is retried with the timeout, the Validator side will not make an error. Even if the Ledger improperly postpones the commit beyond the timeout, the inconsistency can be detected from the records left on the Validator side.

[0044] In the asynchronous Byzantine fault detection protocol, ledger transaction processing is identical to the commit phase of conventional protocols, allowing for direct repurposing of conventional ledger implementations. Therefore, transactions in the validator system are executed using a one-shot model of deterministic programs called contracts. The ledger database is abstracted as a multi-dimensional key-value mapping, and can be read and written in accordance with ACID through contracts.

[0045] Ledger abstracts the data access layer, allowing it to implement its functions independently of underlying database systems. A highly scalable distributed transaction manager can be used as the transaction manager for this abstracted data access layer. This allows ACID transactions to be implemented on a wide variety of databases, including SQL, which lack ACID transaction capabilities. By utilizing this transaction manager, the Ledger database can be used with both ACID and non-ACID databases, depending on performance, cost, and scalability requirements.

[0046] The Validator implements the logging and verification phases described above. It can be implemented as a library for accessing the Ledger. Applications can use the Validator client SDK to register authentication keys, register contracts, and execute them. Furthermore, access to the Validator database can be abstracted similarly to the Ledger, allowing the use of the aforementioned transaction manager to select a variety of databases as a lower-level database.

[0047] One of the important pieces of information used in the proposed protocol to verify serializability asynchronously is the start and end times of transactions obtained during the logging phase. The validator uses Lamport's logical clock (an example of a logical clock) as the start and end times.

[0048] In this embodiment, the reasons for not using TrueTime or Timestamp Oracle as the start and end times are as follows. First, physical times like TrueTime are not used because not all systems can utilize such precise time management services. Although it is possible to consider using a general-purpose NTP server to provide TrueTime, its operation is not necessarily easy. In addition, a centralized Timestamp Oracle server has the problem of easily becoming a single point of failure. Even if multiple servers are running, it is not easy to ensure monotonic increase of time while maintaining performance scalability. In view of this, the client uses Lamport's logical clock to stamp the time in a distributed and scalable manner.

[0049] In the Validator, multiple clients (e.g., multiple threads) issue transaction requests. Furthermore, the number of clients can fluctuate depending on performance requirements and other factors. Therefore, it's unrealistic to implement a method where clients send and receive clocks, as in Lamprot's logical clock algorithm. To address this, the Validator replaces this sending and receiving process with read and write operations on a clock table in a shared Validator database.

[0050] Specifically, the clock table contains multiple counter records equivalent to local counters used by each client. The number of counters required will be explained later. At the start and end of a transaction, the client scans the clock table and uses the maximum value of the counter plus 1 as the logical clock at that point in time. Furthermore, the clock table records are updated with the new logical clock value.

[0051] Furthermore, to ensure consistent identification of concurrent transactions, scanning and updating each client's clock table does not need to be performed as a transaction; scanning an old clock is sufficient. This is because if two transactions are actually concurrent, the start (or end) clock update of one transaction will inevitably be observed by the end (or start) scan of the other transaction, resulting in overlapping start and end times. Since the actual start time of a transaction T_i occurs after the clock update of T_i, and the scan of the end of a different transaction T_j occurs after the commit of T_j, if T_i and T_j are concurrent, the scan of T_j will inevitably observe the clock update of T_i. By obtaining the old clock, transactions that are not actually concurrent can sometimes be given the appearance of being concurrent, but this does not affect the results of the serializability check.

[0052] Since scanning and updating of the logical clock is a relatively heavy process accompanied by access to the database, the number of counter records in the clock table or its update frequency is an important tuning parameter.

[0053] The number of counter records in the clock table can be reduced by sharing them among several client threads. This reduces the number of records scanned, but performance may be degraded due to logical clock update conflicts.

[0054] Furthermore, when acquiring the time, only the value recorded in the counter can be scanned, omitting periodic updates. This scenario increases the number of transactions that appear to be concurrent. This has two drawbacks. First, the number of candidate transactions increases slightly when extracting concurrent transactions during the serializability check. However, if there are no conflicts, the graph itself does not increase in size. Second, the visible time of the version that the validator can subsequently verify increases, increasing the likelihood that the ledger will be able to illegally read an older version without being discovered. However, since the validator's time management and the ledger's transaction management are independent and handled in different management domains, it is difficult for the ledger to abuse the operation of the logical clock and commit fraud at the right opportunity.

[0055] In the first embodiment, we outline a validator system capable of asynchronous Byzantine fault detection. Rather than performing consensus processing synchronously during transaction execution to detect failures, the validator system detects asynchronous Byzantine faults by performing verification processing after transaction execution. Compared to traditional systems, the validator system improves transaction throughput and latency.

[0056] The following contents are derived from the description of the first embodiment: The following description includes supplementary descriptions of the first embodiment and descriptions of modified examples.

[0057] The client program that relays transaction requests from an application program to a database server program includes a recording module, an input / output verification module, and a serializability verification module. The recording module records transaction information. Transaction information consists of the transaction request identifier, processing details, parameters, the result of the database server program processing the transaction request, output records, identifiers and version numbers of the input / output records, and the start and end times of the transaction request. The input / output verification module receives a verification request containing the transaction request identifier and re-executes the transaction based on the processing details, parameters, and input records of the transaction request recorded by the recording module. It then verifies that the result and output records of the transaction executed in the database server program are identical. The serializability verification module lists transactions executed concurrently with the transaction based on the start and end times of the transaction request, generates a serialization graph representing conflict relationships between the transactions based on the identifiers and version numbers of the input / output records of the listed transactions, and verifies that the listed transactions are serializable based on the serialization graph.

[0058] In addition, the serializability verification module can calculate the readable time of the record based on the version number and start and end time of the transaction input and output records, and can verify whether there is any contradiction between the parallel executed transactions and the real-time sequence based on the readable time.

[0059] Furthermore, when there is no entity of the record set as input, the input / output verification module identifies a transaction for outputting the record and recursively executes the transaction again.

[0060] The start and end times can be logical clocks shared by multiple client programs.

[0061] The recording module can increase or decrease the frequency of obtaining and updating the logical clock based on the transaction request load.

[0062] The client program may include a fault recovery module that searches for and obtains transactions that have no record at the end time, queries the database server program for the status of their transactions, and obtains and / or records deficiency information. [Second embodiment]

[0063] The second embodiment will be described. The description of the second embodiment also includes any description of similarities and differences with the first embodiment. Although the first embodiment describes the problem-solving of the three-phase protocol, the validator system involved in the first embodiment and the validator systems involved in any of the second and third embodiments can be applied to systems that use protocols other than the three-phase protocol.

[0064] Figure 1 A configuration example of the entire system including the validator system according to the second embodiment is shown.

[0065] There are one or more clients 100 , validator database system 170 , and ledger system 180 . Part of each client 100 and validator database system 170 constitute validator system 150 .

[0066] Each client 100 communicates with the validator database system 170 and the ledger system 180, respectively. This communication is typically performed via a communication network (not shown). The communication network used to communicate between each client 100 and the validator database system 170 and the communication network used to communicate between each client 100 and the ledger system 180 can be physically or logically separated.

[0067] The client 100 executes a plurality of programs. Examples of the executed programs include the application program 101 and the validator program 160 .

[0068] Application 101 is a computer program for applications such as account management and online shopping. Transaction requests are issued from application 101 to Ledger system 180 via client function 161, and Ledger server 181 of Ledger system 180 executes transactions in response to the transaction requests.

[0069] Validator program 160 is part of Validator system 150. Validator program 160 includes client functionality 161, transaction logging functionality 162, and transaction verification functionality 163. Client functionality 161 is used to communicate with Ledger system 180. Transaction logging functionality 162 and transaction verification functionality 163 are used to communicate with Validator database system 170. Transaction logging functionality 162 records transaction logs and proofs in Validator database 172. Transaction verification functionality 163 verifies that transactions are correctly executed in Ledger system 180.

[0070] The validator database system 170 includes a validator server 171 and a validator database 172. The validator server 171 inputs and outputs transaction logs and certificates to the validator database 172. The validator server 171 may exist in each client 100 or may be shared by multiple clients 100. The validator database 172 contains data such as transaction logs and certificates. Specifically, for example, Figure 2 As described above, the validator database 172 includes a transaction log table 201V, a record table 202V, and a time management table 203 .

[0071] The Ledger system 180 includes a Ledger server 181 and a Ledger database 182. The Ledger server 181 inputs and outputs data to the Ledger database 182 in response to a transaction request from the client 100. The Ledger database 182 has data input and output in response to a transaction request from the client 100. Specifically, for example, Figure 3 As shown, the Ledger database 182 includes a transaction log table 201L and a record table 202L.

[0072] The management domain 50 includes, for example, a management domain 50A having the client 100, a management domain 50B having the validator database system 170, and a management domain 50C having the ledger system 180. The management domain 50C having the ledger system 180 preferably does not include the elements of the validator system 150. The elements of the validator system 150 in the client 100 may be included in the management domain 50B having the validator database system 170 instead of the management domain 50A. One management domain 50A may include all the clients 100, or a plurality of management domains 50A may be prepared, each of which includes one or more clients 100. The management domain 50B corresponds to Figure 22 In the example of the Validator management domain, the management domain 50C corresponds to Figure 22 The Ledger management domain in the example.

[0073] The client 100, the validator database system 170, and the ledger system 180 can each be a physical computer system (one or more physical computers), or a logical computer system based on a physical computer system (such as a virtual machine or cloud computing service). The validator server 171 and the ledger server 181 can each implement their functions by executing a program, or can be a physical or logical computer system. Figure 20 That is, the computer system 2000 includes an interface device 2001, a permanent storage device 2002, a memory 2003, and a processor 2004 connected thereto.

[0074] Ledger server 181 manages one or more contracts (e.g., one or more contracts in management domain 50C) and executes designated contracts. A "contract" refers to the processing logic (e.g., a computer program) that may be executed during the transaction execution process. Ledger server 181 may maintain a contract management table containing information related to each of the one or more contracts. Additionally, Ledger server 181 may maintain an authentication management table necessary for client 100 or other authentication.

[0075] Validator server 171 also manages one or more contracts identical to the one or more contracts executable by ledger server 181 (e.g., one or more contracts in management domain 50B). Validator server 171 can execute the same contracts as those executed by ledger server 181, and therefore, can verify them. Validator server 171 may include a contract management table containing information related to each of the one or more contracts. Additionally, validator server 171 may include an authentication management table necessary for authentication by client 100 or other parties.

[0076] The following describes the validator database 172 and the ledger database 182. In the following description, an "entry" refers to a table row, and a "record" refers to data that is input or output to the ledger database 182 during transaction execution. Specifically, a record is data representing the state of an object (e.g., an element specified by a request from the application 101, such as an account), such as a key-value pair.

[0077] Figure 4 An example of the structure of the transaction log table 201V of the validator database 172 is shown.

[0078] The transaction log table 201V records the transaction log. In order to re-execute the transaction during verification, the recorded transaction log is used for verification.

[0079] The transaction log table 201V has an entry for each transaction, and each entry includes data such as TxID 401V, PID 402V, parameter set 403V, ​​signature 404V, start time 405V, end time 406V, RW set 407V, execution result 408V, and status 409V.

[0080] TxID 401V represents the transaction ID (e.g., a UUID). CID 402V represents the contract ID. Parameter group 403V represents one or more parameters of the contract. Signature 404V represents a signature (e.g., a signature generated using the TxID, CID, and parameter group) used to indicate that the transaction request has not been tampered with.

[0081] The start time 405V indicates the start time of the transaction. The end time 406V indicates the end time of the transaction. The "time" can be expressed in units such as year, month, day, hour, minute, and second, but as in the first embodiment, it is obtained from the time management table 203 as a logical clock.

[0082] The RW set 407V is a set of records read and written during the execution of a transaction. Specifically, it includes the record ID and version combination of the records read, and the record ID and version combination of the records written during the execution of the transaction. For example, in the entry TxID401V "1", "Read: x0" means that the record with record ID "x" and version "0" is read, and "Write: x1" means that the record with record ID "x" and version "1" is written. In addition, the record ID is equivalent to the ID of the object. Multiple records with the same record ID may exist in the ledger database 182. The record ID and version combination uniquely represents the record in the record table 202L of the ledger database 182.

[0083] Execution result 408V indicates that during transaction execution, client 100 (client function 161) received a value of a specified type from ledger system 180 as part of the transaction result. This "value of a specified type" may include, for example, the state of an object (e.g., an account) after transaction execution (e.g., the latest balance), as shown in the figure, and may also include a record ID and version combination.

[0084] Status 409V indicates the status of a transaction. The "state of a transaction" may be, for example, the start and end of a transaction related to transaction execution, or the start and end of verification related to transaction verification. For example, the transaction verification function 163 determines which transaction has completed verification and which transaction is to start verification from the column of status 409V, and can perform verification using the RW set 407V and execution result 408V of the determined transaction.

[0085] When the client function 161 receives a request from the application 101 and starts transaction execution, data 401V to 405V are recorded by the transaction log function 162. When the client function 161 receives a transaction result during the transaction execution, data 406V to 407V are recorded by the transaction log function 162.

[0086] Figure 5 An example of the structure of the record table 202V of the validator database 172 is shown.

[0087] The record table 202V is a table equivalent to a copy of the record table 202L of the ledger database 182. The record table 202V has entries for each record ID and version combination. The entry has data such as record ID 501V, version 502V, input 503V, output 504V, TxID 505V, hash value 506V, signature 507V, visible start time 508V, and visible end time 509V. Figure 5 "Following Records" in the .

[0088] The record ID 501V indicates the record ID (an example of a key) of the record of interest. The version 502V of the record of interest indicates the version.

[0089] Input 503V indicates the record ID and version of the record read in order to write the record of interest during transaction execution.

[0090] Output 504V is the output data (an example of a value) written during transaction execution for the record of interest. For example, it includes the record ID and version of the record of interest, and the status of the object corresponding to the record ID (for example, the balance of an account). Output 504V is blank before verification and is written during verification.

[0091] TxID 505V indicates the ID of the transaction that wrote the record of interest. The record read to write the record of interest and the transaction that wrote the record of interest can be identified from the combination of TxID 505V and input 503V. TxID 505V and input 503V are referenced during verification.

[0092] Hash value 506V is a hash value of the outputs (specifically, data 501V-505V) included in the transaction result of the transaction written to the record of interest. Signature 507V is a signature indicating that hash value 506V has not been tampered with. If the response from ledger system 180 has been authenticated, signature 507V does not need to be stored. Furthermore, if the certificate from ledger system 180 includes output 504L instead of hash value, hash value 506V may not be present.

[0093] Visible start time 508V indicates the start time of the visible time of the record of interest. Visible end time 509V indicates the end time of the visible time of the record of interest. Here, the "visible time" of a record refers to the time period during which the record can be logically read into the ledger database 182 within the ledger system 180 (the continuous time period from the visible start time to the visible end time). The technical meaning of "visible start time" and "visible end time" will be explained in detail later.

[0094] Figure 6 A structural example of the time management table 203 of the validator database 172 is shown.

[0095] The time management table 203 corresponds to the clock table in the first embodiment. The time management table 203 has entries for a plurality of (or one) counter IDs. Each entry has data such as an ID 601 and a counter 602.

[0096] ID 601 indicates a counter ID. Counter 602 indicates a counter value as a time (for example, an integer).

[0097] Each of a plurality of (or one) counter IDs is statically or dynamically assigned to any client 100. For example, a counter ID may be prepared for each client 100, and a counter ID may be assigned to the client 100 based on a rule regarding the counter ID assigned to the client 100. The counter ID is assigned to each client 100.

[0098] For example, the transaction log function 162 scans the time management table 203, determines the maximum value of the counter value, and records the counter value (maximum value + 1) in the counter 602 corresponding to the counter ID assigned to the client 100 having the transaction log function 162. Thus, the time as the counter value is updated.

[0099] The times (counter values) determined from the time management table 203 are used for the start and end times of transactions, in addition to the visible start and end times. The continuous period from the start to the end of a transaction is referred to as "transaction time." Multiple transactions whose transaction times overlap at least partially are considered concurrent transactions. Verification checks whether concurrent and conflicting transactions can be executed serially.

[0100] Figure 7 An example of the structure of the transaction log table 201L of the Ledger database 182 is shown.

[0101] The transaction log table 201L records the accepted transaction requests and the transaction log as a status log. The transaction log table 201L may have a different structure from the transaction log table 201V of the validator database 172.

[0102] The transaction log table 201L has an entry for each transaction. Each entry has data such as a TxID 401L, a status 409L, an RW set 407L, and an execution result 408L.

[0103] TxID 401L indicates the ID of the transaction. Status 409L indicates the status of the transaction, for example, whether it is committed or aborted.

[0104] The RW set 407L and the execution result 408L are equivalent to the transaction log recorded in the transaction log table 201L. For example, when the transaction log function 162 is unable to record the transaction log to the validator database system 170 due to a power outage, the ledger system 180 obtains the transaction log through the client function 161. The RW set 407L is a set of records read and written during the execution of the transaction. Specifically, it includes a set of record IDs and versions of records read and a set of record IDs and versions of records written during the execution of the transaction. The execution result 408L represents a value of a specified type included in the transaction result received by the client 100 from the ledger system 180 during the transaction execution. The "specified value" can include, for example, the state of an object (e.g., an account) after the transaction execution (e.g., the latest balance) as shown in the figure, and can also include a set of record IDs and versions.

[0105] Figure 8 The following shows an example of the structure of the record table 202L of the Ledger database 182.

[0106] The record table 202L is a table that inputs and outputs data (e.g., so-called user data) in response to a request sent from the application 101 via the client function 161. The record table 202L has a record for each set of a record ID and a version. A record has data such as a record ID 501L, a version 502L, an input 503L, and an output 504L. Figure 8 "Following Records" in the .

[0107] The record ID 501L indicates the record ID (an example of a key) of the record of interest. The version 502L of the record of interest indicates the version.

[0108] Input 503L represents the record ID and version of the record read during transaction execution to write the record of interest. Output 504L represents output data (an example of a value) written during transaction execution regarding the record of interest, for example, a set of the record ID and version of the record of interest, and the state of the object corresponding to the record ID (e.g., the balance of an account).

[0109] Below, refer to Figures 9 to 16 An example of processing performed in the second embodiment will be described. Figure 9 as well as Figure 10 Corresponding to the log phase, Figures 11 to 16 Corresponding to the verification phase. The verification phase is asynchronous with the logging phase.

[0110] Figure 9 as well as Figure 10 An example of the processing flow for transaction execution is shown. Specifically, Figure 9An example of the process flow involving the Validator program 160 in the process flow regarding transaction execution is shown. Figure 10 An example of a process flow involving the Ledger server 181 in the process flow regarding transaction execution is shown.

[0111] This processing flow starts when the client function 161 of the validator program 160 receives a request from the application 101. In the request from the application 101, the ID of the contract to be executed is associated with one or more parameters used in executing the contract.

[0112] like Figure 9 As shown, the client function 161 generates a transaction request (S901) associated with a contract ID and one or more parameters from the application 101 and decryptable by the ledger system 180. In addition to the CID (contract ID) and parameter set (one or more parameters), the generated transaction request also associates a TxID (transaction ID) and a signature (e.g., TxID, CID, and a signature generated using the parameter set).

[0113] The transaction log function 162 obtains the current time (for example, the value of the largest counter 602 in the time management table 203 plus 1) as the start time from the time management table 203, and writes the current time as the counter 602 corresponding to the clock ID 601 assigned to the client 100 containing the function 162 (S902).

[0114] The transaction log function 162 writes the transaction log to the transaction log table 201V of the validator database 172 (S903). The transaction log written in S903 includes data 401V to 405V, namely, the TxID, CID, parameter group, and signature data associated with the transaction request generated in S901, as well as the start time data obtained in S902.

[0115] The client function 161 sends the transaction request generated in S901 to the Ledger system 180 ( S904 ).

[0116] like Figure 10 As shown, the Ledger server 181 of the Ledger system 180 receives the transaction request sent in S904 from the client function 161 ( S1001 ).

[0117] The Ledger server 181 responds to the transaction request and determines the contract corresponding to the specified CID in the transaction request from one or more contracts owned by the Ledger system 180 (one or more contracts in the management domain 50C), and executes the determined contract (S1002). In S1002, records are read and written to the record table 202L of the Ledger database 182. For example, in S1002, when reading the record {x0} with status "4" (record ID "x" and version "0") and writing the record {x1} with status "5", the record written to the record table 202L is Figure 8 The second record in .

[0118] The Ledger server 181 executes commit or abort as a result of the transaction included in S1002 ( S1003 ).

[0119] The Ledger server 181 generates a certificate of execution of the transaction (S1004). The certificate includes the record ID and version of the record written, the input (the record ID and version of the record read for recording the write), the TxID of the transaction, the hash value of the record written, and the signature of the hash value. That is, the certificate includes the data written to the record table 202V of the Validator database 172 as data 501V~503V and 505V~507V. The TxID may not be present. The hash value in the certificate is an example of an outline of the output 504L, and the hash value in the certificate and its signature are equivalent to the summary of the output 504L. Instead of the hash value and its signature, the certificate may include the output 504L.

[0120] Ledger server 181 generates a transaction result as a response to the transaction request received in S904, and sends the transaction result to Validator program 160 (S1005). The transaction result includes the certificate generated in S1004 and the result of executing the contract in S1002, namely, execution result 408L. The certificate includes data indicating what transaction was executed in Ledger system 180 (e.g., the hash value of input 503L and output 504L and its signature (or output 504L)).

[0121] like Figure 9 As shown, the client function 161 of the validator program 160 receives the transaction result sent in S1005 ( S905 ).

[0122] The transaction log function 162 acquires the current time as the end time from the time management table 203 and writes the current time as the counter 602 corresponding to the clock ID 601 assigned to the client 100 including the function 162 ( S906 ).

[0123] The transaction log function 162 writes the transaction log to the transaction log table 201V of the validator database 172 and writes the proof in the transaction result received in S905 to the record table 202V of the validator database 172 (S907). The transaction log written in S907 is data 406V to 408V, that is, data indicating the end time obtained in S906, the RW set determined from the transaction result, and the execution result (the written record has a value as the status). The proof written in S907 is data 501V to 503V and 505V to 507V.

[0124] Figure 11 An example of the processing flow of the verification process is shown.

[0125] This processing flow begins when the transaction verification function 163 receives a verification request associated with a record ID and version (a request to verify whether the record determined by the record ID and version is correct). The verification request can be issued from the application 101, or from a physical or virtual management computer (e.g., a computer in the management domain 50A) not shown in the figure, or from another verification request source. The processing flow can be started by inputting an unverified target transaction ID determined by the transaction verification function 163 based on the transaction status 409V. In this case, processing can be started from S1102.

[0126] The transaction verification function 163 determines the entry associated with the verification request, which has a record ID 501V and a version 502V that are consistent with the record ID and version, from the record table 202V of the Validator database 172, and obtains proof from the determined entry (i.e., data 501V to 503V and 505V to 507V in the entry) (S1101).

[0127] The transaction verification function 163 acquires the transaction log that is an entry having the TxID 401V that matches the TxID in the certificate acquired in S1101 from the transaction log table 201V of the validator database 172 ( S1102 ).

[0128] The transaction verification function 163 determines whether there is an unprocessed write record among the write records indicated by the RW set 407V of the transaction log acquired in S1102 (S1103). An "unprocessed write record" is a write record that has not been processed in S1104 and S1105.

[0129] When the judgment result of S1103 is true (S1103: Yes), the transaction verification function 163 selects an unprocessed write record and obtains a certificate of the write record from the record table 202V (S1104). Specifically, the certificate (data 501V~503V and 505V~507V) is obtained from the entry having the record ID 501V and version 502V that are consistent with the record ID and version of the write record. The transaction verification function 163 performs state export processing (S1105). In S1105, the transaction verification function 163 uses the certificate obtained in S1104 to execute the transaction again, and determines whether the same record as the unprocessed write record is obtained as a result of the re-execution. The state export processing corresponds to the processing using the deriveStates() function in the first embodiment. For details of the state export processing, refer to Figure 12 This will be explained later.

[0130] If the result of the determination in S1103 is false (S1103: No), the transaction verification function 163 performs a graph generation process (S1106). In the graph generation process, a graph is generated. The generated graph is a directed graph, where nodes are transactions, and edges and their directions correspond to the read and write of records between transactions. For details of the graph generation process, refer to Figure 13 This will be explained later.

[0131] The transaction verification function 163 determines whether there is a loop in the graph (S1107). If the result of S1107 is true (S1107: Yes), the transaction verification function 163 sends an error to the verification request source (the source of the verification request) (S1108). The presence of a loop in the graph means that the transaction is not executed serially.

[0132] Figure 12 An example of the processing flow of the status derivation process is shown.

[0133] The transaction verification function 163 determines whether there is an unprocessed read record among the read records indicated by the input 503V of the certificate acquired in S1104 (S1201). An "unprocessed read record" is a read record that has not been processed in S1202.

[0134] If the result of S1201 is true (S1201: Yes), the transaction verification function 163 selects an unprocessed read record, obtains the entry corresponding to the unprocessed read record from the record table 202V (S1201), and adds the contents of the entry (e.g., at least data 501V to 507V) to the input list (S1203). The data added to the input list may be only data 501V, 502V, and 504V, or may include data other than these data. If the record obtained in S1202 is an unprocessed write record (S1103: Yes), the state derivation process is recursively executed (S1105).

[0135] When the judgment result of S1201 is false (S1201: No), the transaction verification function 163 executes the transaction again using the input list (S1204), and determines whether the hash value of the write record obtained as a result of the re-execution is consistent with the hash value 506V in the certificate obtained in S1104 (S1205).

[0136] If the result of determination in S1205 is true ( S1205 : Yes), the transaction verification function 163 writes data including the status obtained as a result of the re-execution as the output 504V of the certificate acquired in S1104 ( S1206 ).

[0137] If the result of S1205 is false (S1205: No), the transaction verification function 163 sends an error to the verification request source (the source of the verification request) (S1207). This is because there is a possibility of tampering (for example, tampering with the contract or record table 202L of the ledger system 180). Furthermore, if S1207 is executed, the verification process itself may also be terminated in addition to the state derivation process.

[0138] Figure 13 An example of the processing flow of the graph generation process is shown.

[0139] The transaction verification function 163 initializes the graph and the ToDo list (S1301). The "graph" generated in this graph generation process is a graph with the TxID of the transaction log obtained in S1102 as the base point. Graph initialization prepares a blank graph with neither nodes nor edges. The "ToDo list" is a list of the TxIDs of the transactions to be verified. The ToDo list is used to verify the presence of concurrent transactions. Initialization of the ToDo list lists only the base TxID.

[0140] The transaction verification function 163 determines whether the ToDo list is empty (S1302). Since there is a base point TxID immediately after S1301, the determination result of S1302 is false.

[0141] If the result of determination in S1302 is false (S1302: No), the transaction verification function 163 acquires the TxID (for example, the TxID in the top row) from the ToDo list (S1303). The acquired TxID is deleted from the ToDo list.

[0142] The transaction verification function 163 determines whether the TxID acquired in S1303 exists in the ToDo list (S1304). The TxID acquired in S1303 immediately after S1301 is the base point TxID. Since the map is blank, the determination result of S1304 is false.

[0143] When the judgment result of S1304 is false (S1304: No), the transaction verification function 163 performs a visible confirmation process. The visible confirmation process is equivalent to checking the presence or absence of Strict serializability. The visible confirmation process can be performed as a process other than the graph generation process, but it is efficient to perform it in the graph generation process. This is because the read record group necessary for visible confirmation is obtained in the transaction log acquisition (S1102 or S1401). That is, the transaction log obtained in S1102 or S1401 can be cached so that it can be efficiently referenced later. For details of the visible confirmation process, refer to Figure 15 This will be explained later.

[0144] The transaction verification function 163 adds the node corresponding to the TxID acquired in S1303 to the graph ( S1306 ).

[0145] The transaction verification function 163 performs conflict confirmation processing (S1307). The TxID listed as the verification object in the conflict confirmation processing is appended to the ToDo list. For example, assume that Tx1 is a transaction that is concurrent with Tx2 and has an action conflict. Tx1 conflicts with Tx2, so the node corresponding to TxID2 will be included in the graph. On the other hand, for Tx2, there may be more than just Tx1 that is conflicting and concurrent. Therefore, since the existence of transactions that are conflicting and concurrent with Tx2 will be checked later, TxID2 is appended to the To list, and then S1304: No is obtained for TxID2, and conflict confirmation processing is performed. For details of the conflict confirmation processing, refer to Figure 14 This will be explained later. Furthermore, while the TxIDs listed during conflict resolution are added to the ToDo list, the nodes corresponding to those TxIDs are not immediately added to the graph. Therefore, there may be TxIDs that exist in the ToDo list but not in the graph. Concurrent transactions can occur over time, as such transactions can be identified. Furthermore, as shown below, edges are added in S1307, but these edges are only added to the nodes added in S1306.

[0146] When the TxID is acquired from the ToDo list in S1303 and a series of processes are completed, the process returns to S1302. If the result of the determination in S1302 is true (S1302: Yes), the graph is completed, and thus the graph generation process is terminated.

[0147] Figure 14 An example of the processing flow of the conflict confirmation process is shown.

[0148] The transaction verification function 163 acquires the transaction log (entry) having the TxID acquired in S1303 from the transaction log table 201V of the Validator database 172 ( S1401 ).

[0149] The transaction verification function 163 identifies one or more concurrent transactions, or concurrent transaction groups (S1402). A "concurrent transaction" herein refers to a transaction whose transaction time (the time period from the start time to the end time) indicated by the transaction log obtained in S1401 overlaps with the start time or the end time. Concurrent transaction groups can be identified from the transaction log table 201V.

[0150] The transaction verification function 163 determines whether there are any unprocessed concurrent transactions (S1403). "Unprocessed concurrent transactions" refer to concurrent transactions in the concurrent transaction group determined in S1402 that have not been processed after S1404. If there are no unprocessed concurrent transactions, or if no concurrent transactions were determined in S1402, the result of S1403 is false.

[0151] If the result of S1403 is true (S1403: Yes), the transaction verification function 163 selects an unprocessed concurrent transaction and obtains a transaction log having a TxID that matches the TxID of the concurrent transaction, i.e., a concurrent transaction log, from the transaction log table 201V (S1404). Alternatively, the transaction logs of all concurrent transactions in S1402 may be obtained, in which case S1404 may not be performed.

[0152] The transaction verification function 163 determines whether the concurrent transaction conflicts with the transaction of the TxID obtained in S1303 (hereinafter referred to as the acquisition transaction) (S1405). Specifically, the RW set 407V of the acquisition transaction is compared with the RW set 407V of the concurrent transaction. In the case where the record ID of the write record of the transaction of one of the acquisition transaction and the concurrent transaction is the record ID of the read record of the other transaction, or in the case where the record IDs of the write records of the acquisition transaction and the concurrent transaction are the same, a conflict determination result is obtained. In addition, in the case where the record IDs of the write records of the acquisition transaction and the concurrent transaction are the same and the versions are also the same, an error is sent, and the conflict confirmation process or verification process can be terminated.

[0153] If the result of determination in S1405 is false (S1405: No), S1406 and S1407 are skipped and the process returns to S1403. This is because it is obvious that the acquisition transaction and the concurrent transaction can be executed serially if there is no conflict.

[0154] If the result of S1405 is true (S1405: Yes), the transaction verification function 163 adds an edge to the graph with the TxID of the acquisition transaction as the starting point or the end point (S1406). For example, if the acquisition transaction reads and writes a record of a concurrent transaction, an edge is added with the node of the acquisition transaction as the end point. If the concurrent transaction reads a record written by the acquisition transaction, an edge is added with the node of the acquisition transaction as the starting point. If the acquisition transaction also writes a record with the same record ID as the concurrent transaction, an edge is added with the direction based on which version is the previous one.

[0155] The transaction verification function 163 adds the TxID of the concurrent transaction to the ToDo list (S1407). As mentioned above, this is because the concurrent transaction occurs in a progressive manner. At this stage, the node of the concurrent transaction is not added to the graph.

[0156] Figure 15 An example of the processing flow of the visibility confirmation process is shown.

[0157] The transaction verification function 163 determines a read record group (S1501). A "read record group" is one or more read records, each of which is determined from the RW set 407V in the transaction log having the same TxID 401V as the TxID obtained in S1303. Figures 15 to 19 In the description, the TxID obtained in S1303 is called the "focus TxID", and the transaction corresponding to the focus TxID is called the "focus transaction".

[0158] The transaction verification function 163 determines whether there is an unprocessed read record in the read record group specified in S1501 (S1502). "Unprocessed read record" refers to a read record that has not been processed in S1503.

[0159] If the result of S1502 is true (S1502: Yes), the transaction validation function 163 selects an unprocessed read record and retrieves the entry corresponding to the read record from the record table 202V of the validator database 172 (S1503). The visible start time 508V and visible end time 509V in the entry are initialized. Initialization is performed only when the visible start time 508V and visible end time 509V of the entry are empty (e.g., NULL). The initialized visible start time 508V is the same as the start time 405V of the transaction that wrote the record corresponding to the entry. The initialized visible end time 509V is the same as the end time 406V of the transaction that wrote the record if there is a next version of the record corresponding to the entry, or the maximum integer value of the time in the processing system if there is no next version. The purpose of initialization is to set the most conservative visible time that the record can be read. Based on the time of the transaction associated with the record, the presence of strict serialization can be verified while gradually reducing the visible time as appropriate.

[0160] The transaction verification function 163 determines whether the start time 405V of the TxID of interest is less than or equal to the visible end time 509V of the selected read record (i.e., whether the start time 405V is the same as or earlier than the visible end time 509V) (S1504). Furthermore, the transaction verification function 163 determines whether the end time 406V of the TxID of interest is greater than or equal to the visible start time 508V of the selected read record (i.e., whether the end time 406V is the same as or later than the visible start time 508V) (S1505). Either S1504 or S1505 may be performed first.

[0161] S1504 and S1505 are used to determine whether the version of the read record is correct, that is, whether it is a version of the record that can be read in the execution of the transaction of interest. In the case where there is no overlap between the transaction time of the transaction of interest and the visible time of the read record, that is, when the judgment result of S1504 is false (S1504: No), or when the judgment result of S1505 is false (S1505: No), it means that a record of a version that has not been read in the transaction of interest has been read. Therefore, the transaction verification function 163 sends an error (S1507) to the verification request source. In addition, when S1507 is performed, in addition to the visible confirmation process, the verification process itself can also be terminated.

[0162] When the judgment result of S1504 is true (S1504: Yes), and when the judgment result of S1505 is true (S1505: Yes), in order to make the visible time a more appropriate visible time, the transaction verification function 163 performs visible time update processing (S1506).

[0163] Figure 16 An example of the processing flow of the visible time update process is shown.

[0164] exist Figure 16 In the description of , the version of the read record corresponding to the entry obtained in S1503 can be referred to as the "focused version," the version before the focused version can be referred to as the "previous version," and the version after the focused version can be referred to as the "next version." The record IDs of the focused version, previous version, and next version records are the same.

[0165] The transaction verification function 163 refers to the record table 202V and determines whether it is the previous version of the version of interest (S1601). If the result of S1601 is true (S1601: Yes), the transaction verification function 163 determines whether the visible end time 509V of the previous version is greater than the (future) end time 406V of the transaction of interest (S1602). If the result of S1602 is true (S1602: Yes), the transaction verification function 163 updates the visible end time 509V of the previous version to the end time 406V of the transaction of interest (S1603). In other words, the visible end time 509V of the previous version becomes further in the past, and the visible period of the previous version becomes shorter.

[0166] After S1603, if the result of S1601 is false (S1601: No) or if the result of S1602 is false (S1602: No), the transaction verification function 163 refers to the record table 202V and determines whether it is the next version of the version of interest (S1604). If the result of S1604 is true (S1604: Yes), the transaction verification function 163 determines whether the visible start time 508V of the next version is less than (in the past) the start time 405V of the transaction of interest (S1605). If the result of S1605 is true (S1605: Yes), the transaction verification function 163 updates the visible start time 508V of the next version to the start time 405V of the transaction of interest (S1606). In other words, the visible start time 508V of the next version becomes further in the future, and the visible period of the next version becomes shorter.

[0167] Reference Figures 17 to 19 , an example of visible time update processing is explained.

[0168] like Figure 17 As shown, assume that there are Tx1 to Tx3 (transactions 1 to 3). The actual transaction order is Tx1 → Tx2 → Tx3. Therefore, if record {x1} (record with record ID "x" and version "1") has already been written and committed during the execution of Tx1, the record {x1} read during the execution of Tx2 is correct, but the record {x0} read during the execution of Tx3 is incorrect. In this case, the contract in the ledger system 180 may have been tampered with.

[0169] However, in the verification of serializability (excluding the graph generation process for visibility confirmation), it was found that the order Tx3 → Tx1 → Tx2 satisfies serializability. In other words, strict serializability cannot be guaranteed.

[0170] In view of this, this embodiment introduces a visibility verification process as a strict serialization check. Specifically, because the actual behavior of the ledger system 180 cannot be accurately known from outside the ledger system 180, the validator program 160 determines the visibility time of each record version based on the time observed by the validator system 150, and updates the visibility time appropriately to improve the accuracy of the visibility time.

[0171] Take the record with ID "x" as an example. According to the actual behavior of Ledger system 180, the latest time allowed for reading record {x0} is before the commit time of Tx1, and the earliest time allowed for reading record {x1} is the commit time of Tx1. However, as mentioned above, the actual behavior of Ledger system 180 is unavailable from outside of Ledger system 180. Therefore, the following times are used for versions "0" and "1." The visible end time 509V of version "0" is the time when the Validator program 160 receives the transaction result of Tx1, that is, the end time 406V of Tx1. This end time 406V is the latest time that version "0" can exist, among the times known from outside the Ledger system 180. Assuming that version "1" is written and committed immediately after Tx1 starts, the visible start time 508V of version "1" is the start time 405V of Tx1.

[0172] Furthermore, the visible end time 509V thus determined is updated, for example, in the following manner.

[0173] For example, Figure 18As shown, the visible end time 509V of version "0" is updated. That is, the focus TxID is set to "2." The end time 406V of Tx2 is before the visible end time 509V of version "0," the previous version of record {x1} read during the execution of Tx2 (S1602: Yes). Therefore, the visible end time 509V of version "0" is updated to the end time 406V of Tx2.

[0174] In addition, for example, Figure 19 As shown, the visible start time 508V of version "1" is updated. That is, the focus TxID is set to "3". The start time 405V of Tx3 is the time before the visible start time 508V (S1605: Yes) of the next version of the record {x0} read in the execution of Tx3, that is, the version "1". Therefore, the visible start time 508V of version "1" is updated to the start time 405V of Tx3. In addition, if the visible start time 508V of version "1" is updated in this way, when the focus TxID is "2", an error (S1507) is sent as a result of the serializability check (S1504 and S1505). Since the visible start time 508V of version "1" is in the future than the start time 405V of Tx2, the visible time of version "1" will not overlap with the transaction time of Tx2, so this is because the judgment result of S1504 is false. That is, the order opposite to the actual execution order (Tx3→Tx1→Tx2) is detected as inconsistent, so strict serialization is guaranteed. [Third embodiment]

[0175] The third embodiment will be described. Here, the differences from the second embodiment will be mainly described, and the description of the common points with the second embodiment will be omitted or simplified.

[0176] Figure 21 A configuration example of the entire system including the validator system according to the third embodiment is shown.

[0177] According to the third embodiment, the transaction log function 162 and the transaction verification function 163 are located in the validator server 171 of the validator database system 170, instead of the validator program 160 of the client 100. As in the second embodiment, either the transaction log function 162 or the transaction verification function 163 can be located in the validator program 160. Furthermore, the validator server 171 can be located in each client 100. Multiple validator servers 171 and validator databases 172 can therefore share the time management table 203.

[0178] Several embodiments have been described above, but these are examples for illustrating the present invention and are not intended to limit the scope of the present invention to these embodiments. The present invention can also be implemented in various other ways. For example, at least a portion of the first embodiment can be applied to the second or third embodiment, and at least a portion of the second or third embodiment can also be applied to the first embodiment. In addition, the transaction verification function 163 accepts whether the user (for example, a user belonging to the management domain 50A or 50B) needs to ensure strict serialization, and according to the user's choice, it can decide whether to execute or not execute the visible confirmation processing.

[0179] The above description can be summarized as follows: The following summary may include supplementary descriptions and descriptions of modified examples.

[0180] A verification system (e.g., Validator system 150) is constructed. The verification system includes a storage unit (e.g., a recording module or transaction log function 162) and a verification unit (e.g., an input / output verification module, a serializable verification module, or a transaction verification function 163). Functions such as the storage unit and the verification unit are implemented by a computer executing a computer program. In addition, the "computer" is a computer outside the first computer system (e.g., Ledger system 180). By executing the computer program on such a computer, the computer is constructed as a verification system outside the first computer system. The management domain of the first computer system is different from the management domain of the verification system. The first computer system may be a first database system.

[0181] After a transaction is executed in a first computer system (e.g., Ledger system 180), the verification system performs verification on the transaction. Specifically, the storage unit of the verification system stores the transaction management data of each transaction executed in the first computer system in a second computer system (e.g., Validator database system 170). The second computer system can be a second database system. When a transaction is executed in response to a transaction request, the first computer system returns a transaction result that includes proof of execution of the transaction. For each transaction, the transaction management data includes the data contained in the transaction request for the transaction, and also includes data obtained from the transaction result of the transaction and data that provides proof of the transaction. In response to the verification request, the verification system determines the transaction management data of the verification target transaction from the second computer system and performs verification based on the determined transaction management data. This improves latency and increases transaction throughput. In addition, the execution of transactions in the first computer system can be verified by a verification system outside the first computer system.

[0182] The storage unit stores transaction management data for each transaction executed in the first computer system in the second computer system. The first computer system manages a target set (e.g., record table 202L). A target set is a target set (e.g., record set) for each object (e.g., bank account). A target set is one or more targets (e.g., one or more records), where a target is data representing the state of an object (e.g., a record). When a transaction is executed in response to a transaction request, i.e., a request to read and / or write a target representing the state of an object, the first computer system returns data regarding the result of the transaction, i.e., a transaction result. For each transaction, a proof includes the primary key (e.g., record ID) and version of the read target read during the transaction, the primary key and version of the write target written during the transaction, and the state represented by the write target, or a summary thereof. The proof may include a parameter set (one or more parameters) given to a deterministic function or the ID of the executed deterministic function. For each transaction, the transaction management data includes the data included in the transaction request for the transaction, as well as data obtained from the transaction result of the transaction and including the proof of the transaction. The transaction management data for each transaction may be, for example, all or part of the entry in the transaction log table 201V corresponding to the transaction. In addition, for each record read and / or written during the execution of the transaction, it may include all or part of the entry in the record table 202V corresponding to the record.

[0183] A transaction request is sent from one or more clients to the first computer system, and at least one of the one or more clients may be equipped with at least one of a storage unit and a verification unit.

[0184] The storage unit and the verification unit may be provided in the second computer system. A combination of the storage unit and the verification unit may also be provided in the second computer system for each client.

[0185] Verification that can be performed by the verification unit includes input / output verification (e.g., state export processing (S1105)). The verification unit performs input / output verification, for example, in response to a verification request. In the input / output verification, the verification unit determines the transaction management data of the verification target transaction from the second computer system. The "verification target transaction" can be a transaction specified by the verification request or a transaction that writes to a target specified by the verification request. For each write target determined from the transaction management data, the verification unit can re-execute the transaction. Specifically, it can perform the following (1) and (2). (1) All read targets to be read for writing to the write target are specified from the transaction management data. (2) By using the determined read-in target, executing the same deterministic function (e.g., contract) as that used for executing the transaction in the first computer system, thereby determining whether the output state or its summary (e.g., hash value) is consistent with the state or its summary determined from the transaction management data.

[0186] Additionally, verification performed by the verification unit includes serialization verification (e.g., graph generation processing (S1106) and determination (S1107)). Multiple transaction requests issued from one or more clients are sent to the first computer system in an unordered manner (e.g., without the ordering phase of the three-phase protocol described above), and the first computer system executes the multiple transactions concurrently. Input and output verification can be performed using proofs from the first computer system, but serializability is not guaranteed.

[0187] In view of this, the storage unit obtains the start and end times of each transaction. Since the verification system is located outside the first computer system, the transaction start time is the time when the transaction request is sent from the client to the first computer system, and the transaction end time is the time when the client receives the transaction result. For each transaction, the transaction management data may include data indicating the start and end times of the transaction. For each transaction, the transaction time is the time from the start time to the end time of the transaction.

[0188] For example, if the write targets of the verification target transactions are consistent during input / output verification, serialization verification can be performed. During serialization verification, the verification unit can perform the following (1) and (2) for each of one or more target transactions containing the verification target transaction. The first target transaction in the one or more target transactions can be a transaction that is concurrent with and conflicts with the second target transaction in the one or more target transactions. For example, each target transaction can be the transaction corresponding to the TxID obtained in S1303. (1) Determine all transactions whose transaction time and at least a portion of the transaction time of the target transaction are repeated and concurrent. (2) Based on the primary keys of the read records and write records determined from the transaction management data of the determined concurrent transaction and the primary keys of the read records and write records determined from the transaction management data of the target transaction, determine the transactions that are concurrent and conflicting with the target transaction in the determined concurrent transactions.

[0189] The verification unit may verify whether the plurality of transactions forming a conflicting relationship determined for each of the one or more target transactions are serializable.

[0190] Specifically, for example, the verification unit can construct a directed graph representing multiple transactions in a conflicting relationship. In this directed graph, each node corresponds to a transaction, and each directed edge can be a directed edge based on the read and write records between transactions. If a cycle exists in this directed graph, the verification unit will issue an error. If there is no cycle, serializability is guaranteed.

[0191] In addition, as verification that can be performed by the verification unit, strict serialization verification (such as visible confirmation processing (S1305)) is included. For example, if the user specifies a strict serialization guarantee (i.e., when strict serialization verification is selected as an option), strict serialization verification can be performed. For each target written to the first computer system, the storage unit can store data indicating the time when the target can be read, that is, the visible start time and the visible end time of the visible time, in the second computer system. The verification unit can perform strict serialization verification for each of one or more transactions containing the verification object. For example, in the serialization verification, strict serialization verification can be performed for each of one or more object transactions. In addition, for example, in the input and output verification, if consistency is obtained for each write target of the verification object transaction, strict serialization verification can be performed for each of one or more object transactions. For each of one or more object transactions, in the strict serialization verification, the verification unit can send an error for at least one of the more than one read targets in the execution of the object transaction if any of the following (a) and (b) is not satisfied. (a) The start time of the target transaction is the same as or before the visible end time of the read target. (b) The end time of the target transaction is the same as or later than the visible start time of the read target.

[0192] For each target, the latest visible end time can be the maximum visible end time if there is no target for the next version of the target, i.e., the next version target. If there is a next version target, it can be the end time of the transaction that wrote the target. For each target, the earliest visible start time is the start time of the transaction that wrote the target.

[0193] For each of one or more target transactions, and for each of one or more read targets during the execution of the target transaction, if either of (a) and (b) is satisfied for the read target, the verification unit may perform the following (1) and (2). That is, the verification unit may update the visible time of the read target to a more accurate time. (1) If there is a target of a previous version of the version of the read target, that is, a previous version target, and the visible end time of the previous version target is after the end time of the target transaction, the visible end time of the previous version target is updated to the end time of the target transaction. (2) If there is a target of the next version after the version of the read target, i.e., a next version target, and the visible start time of the next version target is before the start time of the object transaction, the visible start time of the next version target is updated to the start time of the object transaction.

[0194] For each transaction, the storage unit may determine the start time and end time of the transaction based on a logical clock shared by multiple storage units including the storage unit.

[0195] The storage unit can determine that the data having the transaction result is not included in the transaction management data. In addition to the target set, for each executed transaction, the first computer system can also manage data including the primary key and version of the read target read in the execution of the transaction, the primary key and version of the write target written in the execution of the transaction, and the state represented by the write target, i.e., a log. The interface unit of the first computer system (e.g., the client function 161) sends a query for the determined transaction to the first computer system, and receives a log as a response to the query. The storage unit can include the data in the log in the transaction management data of the transaction. For example, when the storage unit is unable to record a part of the transaction management data to the second computer system due to a power outage, the interface unit obtains the log from the second computer system, and the storage unit can store the part of the transaction management data that cannot be recorded to the second computer system based on the log. Description of Reference Numerals

[0196] 160: Validator program, 161: Client function, 162: Transaction log function, 163: Transaction verification function, 150: Validator system, 180: Ledger system.

Claims

1. A computer program, characterized in that The computer program stores transaction management data for each transaction executed in the first computer system in the second computer system, The first computer system manages a target group set, the target group set being a target group for each object, a target group being one or more targets, a target being data representing a state of an object, The first computer system, when executing a transaction in response to a transaction request for reading and / or writing a target representing a state of an object, returns data regarding a result of the transaction, namely, a transaction result, the transaction result including proof of execution of the transaction. For each transaction, the proof includes the primary key and version of the read target read during the execution of the transaction, the primary key and version of the write target written during the execution of the transaction, and the state represented by the write target or a summary thereof, For each transaction, the transaction management data includes data of the transaction request of the transaction and data of the proof of the transaction obtained from the transaction result of the transaction. causing a computer other than the first computer system to execute: In response to a verification request, performing input-output verification, In the input-output verification, determining transaction management data of the verification target transaction from the second computer system, For each write target determined from the transaction management data, From the transaction management data, all read targets to be read for writing to the write target are determined, And by using the determined read-in target, executing the same deterministic function as the deterministic function used for executing the transaction in the first computer system, it is determined whether the output state or its summary is consistent with the state or its summary determined from the transaction management data.

2. The computer program according to claim 1, wherein causing the computer to execute: For each transaction, the time when the transaction request of the transaction is sent to the first computer system is obtained as the start time of the transaction, and the time when the transaction result of the transaction is received is obtained as the end time of the transaction. For each transaction, the transaction management data includes data indicating the start time and end time of the transaction. For each transaction, the transaction time is the time from the start time to the end time of the transaction. In the input / output verification, when consistency is obtained for each write destination of the verification target transaction, serialization verification is performed. In the serialization verification, For each of one or more target transactions including the verification target transaction, Determine the transaction time of the object transaction and all concurrent transactions that have at least a portion of the transaction time repeated, determining, based on the primary keys of the read and write records determined from the transaction management data of the identified concurrent transaction and the primary keys of the read and write records determined from the transaction management data of the target transaction, transactions that are concurrent with and conflict with the target transaction among the identified concurrent transactions; It is verified whether the multiple transactions forming a conflict relationship determined for each of the one or more object transactions are serializable.

3. The computer program according to claim 2, wherein A first object transaction among the one or more object transactions is a transaction that is concurrent with and conflicts with a second object transaction among the one or more object transactions.

4. The computer program according to claim 2, wherein forming a directed graph representing the plurality of transactions forming a conflict relationship, In this directed graph, each node corresponds to a transaction, and each directed edge is a directed edge based on the read and write records between transactions. If a cycle exists in the directed graph, an error is issued.

5. The computer program according to claim 2, wherein causing the computer to execute: For each object written to the first computer system, data indicating a visible start time and a visible end time, which represent a time when the object can be read, is stored in the second computer system. In the serialization verification, strict serialization verification is performed on each of the one or more object transactions. For each of the one or more object transactions, in the strict serialization verification, If neither of the following (a) and (b) is satisfied for at least one of the one or more read targets during the execution of the target transaction, an error is issued. (a) the start time of the target transaction is the same as or before the visible end time of the read target, (b) The end time of the target transaction is the same as or later than the visible start time of the read target.

6. The computer program according to claim 5, characterized in that For each goal, As the visible end time of the target, the latest time is the maximum value of the visible end time when there is no target of the next version of the target, that is, the next version target; if there is a next version target, it is the end time of the transaction that writes to the target. The earliest visible start time for the target is the start time of the transaction that wrote the target.

7. The computer program according to claim 5, wherein causing the computer to execute: For each of the one or more object transactions, For each of one or more read targets during the execution of the target transaction, if any one of (a) and (b) is satisfied for the read target, If there is a target of the previous version of the target, that is, the previous version target, and the visible end time of the previous version target is after the end time of the target transaction, the visible end time of the previous version target is updated to the end time of the target transaction. If there is a target of the next version of the version of the read target, that is, the next version target, and the visible start time of the next version target is before the start time of the object transaction, the visible start time of the next version target is updated to the start time of the object transaction.

8. The computer program according to claim 1, wherein causing the computer to execute: For each object written to the first computer system, data indicating a time when the object can be read, i.e., a visible start time and a visible end time are stored in the second computer system, Perform strict serialization verification on each of one or more transactions containing the verification object. For each of the one or more object transactions, in the strict serialization verification, If neither of the following (a) and (b) is satisfied for at least one of the one or more read targets during the execution of the target transaction, an error is issued. (a) the start time of the target transaction is the same as or before the visible end time of the read target, (b) The end time of the target transaction is the same as or later than the visible start time of the read target.

9. The computer program according to claim 1, wherein The computer program causes the computer to execute: For each transaction, the start time and the end time of the transaction are determined according to a logical clock shared by the plurality of computer programs including the computer program.

10. The computer program according to claim 1, wherein The computer program causes the computer to execute: determining a transaction having data of said transaction result not contained in said transaction management data, In addition to managing the target set, the first computer system manages a log for each executed transaction, wherein the log includes data including a primary key and version of a read target read during the execution of the transaction, a primary key and version of a write target written during the execution of the transaction, and a state represented by the write target. sending a query for the determined transaction to the first computer system, In response to the query, a log is received and the data contained in the log is included in the transaction management data of the transaction.

11. A verification method, characterized in that: storing transaction management data for each transaction executed in the first computer system in the second computer system, The first computer system manages a target group set, the target group set being a target group for each object, a target group being one or more targets, a target being data representing a state of an object, The first computer system, when executing a transaction in response to a transaction request for reading and / or writing a target representing a state of an object, returns data regarding a result of the transaction, namely, a transaction result, the transaction result including proof of execution of the transaction. For each transaction, the proof includes the primary key and version of the read target read during the execution of the transaction, the primary key and version of the write target written during the execution of the transaction, and the state represented by the write target or a summary thereof, For each transaction, the transaction management data includes data included in the transaction request of the transaction, and includes, as data obtained from the transaction result of the transaction, a primary key and version of a read target read during the execution of the transaction, a primary key and version of a write target written during the execution of the transaction, and a state represented by the write target or a summary thereof. Executed by a computer other than the first computer system: In response to a verification request, performing input-output verification, In the input-output verification, determining transaction management data of the verification target transaction from the second computer system, For each write target determined from the transaction management data, From the transaction management data, all read targets to be read for writing to the write target are determined, And by using the determined read-in target, executing the same deterministic function as the deterministic function used for executing the transaction in the first computer system, it is determined whether the output state or its summary is consistent with the state or its summary determined from the transaction management data.

12. A verification system, characterized in that: The verification system includes a storage unit and a verification unit. The storage unit stores transaction management data of each transaction executed in the first computer system in the second computer system, The first computer system manages a target group set, the target group set being a target group for each object, a target group being one or more targets, a target being data representing a state of an object, The first computer system, when executing a transaction in response to a transaction request for reading and / or writing a target representing a state of an object, returns data regarding a result of the transaction, namely, a transaction result, the transaction result including proof of execution of the transaction. For each transaction, the proof includes the primary key and version of the read target read during the execution of the transaction, the primary key and version of the write target written during the execution of the transaction, and the state represented by the write target or a summary thereof, For each transaction, the transaction management data includes data included in the transaction request of the transaction, and includes, as data obtained from the transaction result of the transaction, a primary key and version of a read target read during the execution of the transaction, a primary key and version of a write target written during the execution of the transaction, and a state represented by the write target or a summary thereof. The verification unit performs input and output verification in response to the verification request. In the input-output verification, the verification unit, determining transaction management data of the verification target transaction from the second computer system, For each write target determined from the transaction management data, From the transaction management data, all read targets to be read for writing to the write target are determined, And by using the determined read-in target, executing the same deterministic function as the deterministic function used for executing the transaction in the first computer system, it is determined whether the output state or its summary is consistent with the state or its summary determined from the transaction management data.

13. The verification system according to claim 12, characterized in that: Sending transaction requests from one or more clients to the first computer system respectively, At least one of the storage unit and the verification unit is provided in at least one of the one or more clients.

14. The verification system according to claim 12, wherein: Sending transaction requests from one or more clients to the first computer system respectively, The storage unit and the verification unit are provided in the second computer system.

Images