JP2021064891A - Consortium block chain system, computer, and transaction approval method - Google Patents

Abstract

To provide a consortium block chain system using an encryption method that does not require pairing calculation.SOLUTION: A consortium block chain system includes: a first computer that holds transaction data and a generation key for generating a zero knowledge certification value; and a second computer that holds a verification key for verifying the zero knowledge certification value. The first computer uses the generation key to generate a zero knowledge certification value based on the transaction data and transmits the generated zero knowledge certification value to the second computer. The second computer uses the verification key to verify the zero knowledge certification value transmitted from the first computer.SELECTED DRAWING: Figure 1

Description

The present invention relates to a consortium blockchain system, a computer, and a transaction approval method.

In recent years, not only transactions of goods in real money and currencies, but also commercial transactions using electronic money and virtual currencies have been carried out. There is a technology that uses a virtual currency called Bitcoin to perform settlement transactions at a low fee that does not require a centralized institution such as a bank. In Bitcoin, transaction information (hereinafter, also referred to as transaction) is confirmed on the P2P (Peer to Peer) network by a node called a miner, which determines the validity, and then calculates a specific hash value called proof of work. Is being done. Confirmed transactions are combined into one block and recorded in a distributed ledger called a blockchain.

Since all the nodes on the P2P network can refer to the Bitcoin transaction and the distributed ledger, all the nodes can refer to which node the Bitcoin was remitted from which node. Therefore, if the user's bitcoin address is known, a third party can easily view the transaction information between the users.

To deal with such a problem, Non-Patent Document 1 discloses a method of using a coin for anonymous remittance called Zerocash (or Zcash) on the Bitcoin protocol.

In the Zcash method, the sender, recipient, and amount portion of the transaction data are concealed, and the concealed transaction in which the zero-knowledge proof value of the transaction is attached to the concealed data is broadcast to the P2P network. ..

Since the sender, recipient, and amount portion are kept secret on the distributed ledger, the contents of the transaction will not be leaked to a third party on the network. The reason for adding the zero-knowledge proof value to the transaction is to prove the validity of the part hidden by an unspecified number of miners.

For example, in the Bitcoin / Zcash transaction described in Non-Patent Document 1, the UTXO (Unsent Transaction Output) method is used. Here, in the UTXO method, it is necessary that the total value of input and the total value of output of each transaction match (including the fee).

When the input / output value is concealed, the miner cannot confirm that it is concealed. Therefore, in the Zcash method, the zero-knowledge proof value indicating that the total value of input and the total value of output match. Has been generated. At this time, the Pinoccio method described in Non-Patent Document 2 is used as a zero-knowledge proof method.

Eli Ben-Sasson et al., "Zerocas: Decentralized Anonymous Payments from Bitcoin." (2014) Bryan Parno et al., "Pinocchio: Nearly Practical Verifiable Computation." (2013) L. Ducas and D. Homomorphic Encryption, “FHEW: Bootstrapping Homomorphic Encryption in Less Than a Second.” (2015)

In the Zcash method of Non-Patent Document 1 and the Pinoccio method of Non-Patent Document 2 which is the base thereof, the Pairing encryption method is adopted as the encryption algorithm.

The Pairing cryptosystem is new as a public key cryptosystem, and its secure parameters such as key length have not been clarified as compared with the commonly used elliptic cryptosystem. Therefore, in order to operate the Pairing encryption safely, it is necessary to make the key length or the like longer than necessary.

Further, when the zero-knowledge proof value is verified, a pailing operation unique to the Pairing cipher is required, and the amount of calculation required for this operation is large. Moreover, since the security of the Pairing cryptosystem depends on the difficulty of the discrete logarithm problem, the Pairing cryptosystem is not resistant to attacks using a quantum computer.

In order to solve the above problems, one aspect of the present invention adopts the following configuration. The consortium type blockchain system has a first computer that holds transaction data and a generation key for generating a zero-knowledge proof value, and a second computer that holds a verification key for verifying the zero-knowledge proof value. The first computer uses the generated key to generate a zero-knowledge proof value based on the transaction data, and transmits the generated zero-knowledge proof value to the second computer, and the second computer. The computer verifies the zero-knowledge proof value transmitted from the first computer using the verification key, receives the transaction data, and the transaction indicated by the transaction data based on the verification result of the zero-knowledge proof value. Approve or reject.

According to one aspect of the present invention, it is possible to realize a consortium blockchain system using an encryption method that does not require a Pairing operation.

Issues, configurations and effects other than those described above will be clarified by the description of the following embodiments.

It is a block diagram which shows an example of the structure of the blockchain system in Example 1. FIG. It is a block diagram which shows an example of the hardware configuration of the computer which comprises the user terminal, the system management terminal, and the transaction approval terminal in Example 1. FIG. It is a sequence diagram which shows an example of the setup process of the blockchain system in Example 1, and the zero-knowledge proof value generation / verification process following the setup process. This is an example of the data format of the zero-knowledge proof data in the first embodiment.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In the present embodiment, in principle, the same components are designated by the same reference numerals, and the repeated description will be omitted. It should be noted that the present embodiment is merely an example for realizing the present invention and does not limit the technical scope of the present invention.

In this embodiment, a consortium-type blockchain in which only a limited number of nodes verify and approve transactions will be described. For example, by using some of the system parameters (called CRS) used in the Zcash method only by a limited number of nodes that perform verification, a consortium-type blockchain system using an encryption method that does not use the Pairing operation can be created. It can be realized.

FIG. 1 is a block diagram showing an example of the configuration of a blockchain system. The blockchain system includes a user terminal 100, a system management terminal 200, and a transaction approval terminal 300, and these terminals are connected to each other by a network 400 such as the Internet.

The blockchain system of this embodiment is a consortium blockchain in which only the transaction approval terminal 300 has the approval authority.

The user terminal 100 includes a transaction generation unit 101 that generates a transaction, a zero-knowledge proof value generation unit 102 that generates a zero-knowledge proof value, and a communication unit 103 that controls communication with other terminals. Further, the user terminal 100 has a zero-knowledge proof value generation key storage unit 104 in which a zero-knowledge proof value generation key for generating a zero-knowledge proof value is stored.

The system management terminal 200 includes a zero-knowledge proof value generation key / verification key generation unit 201 and a communication unit 202. The zero-knowledge proof value generation key / verification key generation unit 201 sets a pair of a zero-knowledge proof value generation key for generating a zero-knowledge proof value and a zero-knowledge proof verification key for verifying the zero-knowledge proof value. Generate. The communication unit 202 controls communication with other terminals. Further, the system management terminal 200 has a key storage unit 203 in which a pair of a zero-knowledge proof value generation key and a zero-knowledge proof verification key generated by the zero-knowledge proof value generation key / verification key generation unit 201 is stored. ..

The zero-knowledge proof value generation key / verification key generation key 201 generated by the zero-knowledge proof value generation key 201 is open to all blockchain network participants including the user terminal 100, and the zero-knowledge proof value verification key is the transaction approval terminal 300. Distributed only to.

The transaction approval terminal 300 includes a verification unit 301 and a communication unit 302. The verification unit 301 verifies the transaction and the zero-knowledge proof value generated by the user terminal 100. The communication unit 302 controls communication with other terminals. Further, the transaction approval terminal 300 has a zero-knowledge proof value verification key storage unit 303 and a distributed ledger 304.

The zero-knowledge proof value verification key storage unit 303 stores the zero-knowledge proof value verification key. If there is no problem in the verification result (that is, if the verification result is [true]), the verification unit 301 writes the transaction and the zero-knowledge proof value in the distribution ledger 304, and if there is a problem in the verification result (that is, if there is a problem in the verification result). If the verification result is [false]), the verification result is transmitted to the user terminal 100 without writing the transaction and the zero-knowledge proof value in the distribution ledger 304.

That is, as described above, the transaction approval terminal 300 is a limited terminal having approval authority, that is, a node that manages the distributed ledger 304 in the so-called consortium blockchain system.

Further, the transaction approval terminal 300 has a strong authority because it has a zero-knowledge proof value verification key. Therefore, it is desirable that the transaction approval terminal 300 be installed in a trusted institution (ie, used by a trusted approver). If the transaction approval terminal 300 is used by a malicious approver, there is a risk that a legitimate transaction may not be approved or an illegal transaction may be approved.

FIG. 2 is a block diagram showing an example of the hardware configuration of the user terminal 100, the system management terminal 200, and the transaction approval terminal 300, and the hardware constituting each of them.

The computer 500 has, for example, a CPU 501, an auxiliary storage device 502, a memory 503, an input / output interface 505, and a communication device 506, which are connected via an internal signal line 504.

The CPU 501 includes a processor and executes a program stored in the memory 503. The memory 503 includes a ROM which is a non-volatile storage element and a RAM which is a volatile storage element. The ROM stores an invariant program (for example, BIOS) and the like. The RAM is a high-speed and volatile storage element such as a DRAM (Dynamic Random Access Memory), and temporarily stores a program executed by the CPU 501 and data used when the program is executed.

The auxiliary storage device 502 is, for example, a large-capacity and non-volatile storage device such as a magnetic storage device (HDD) or a flash memory (SSD), and stores a program executed by the CPU 501 and data used when executing the program. .. That is, the program is read from the auxiliary storage device 502, loaded into the memory 503, and executed by the CPU 501.

The input / output interface 505 is an interface to which a dormitory device such as a keyboard and a mouse is connected to receive input from a user, and an output device such as a display device or a printer is connected so that the user can visually recognize the execution result of the program. Includes an interface that outputs in format. The computer 500 may include an input device and an output device.

Further, for example, the zero-knowledge proof value generation key storage unit 104 of the user terminal 100 is realized by a part of the storage area of the auxiliary storage device 502 of the computer 500 constituting the user terminal 100. Similarly, the storage unit of the other terminal is also realized by a part of the storage area of the auxiliary storage device 502 of the computer 500 that constitutes the other terminal.

The communication device 506 is a network interface device that controls communication with other devices according to a predetermined protocol. Further, the communication device 506 includes, for example, a serial interface such as USB.

The program executed by the CPU 501 is provided to the user terminal 100 via a removable medium (CD-ROM, flash memory, etc.) or a network 400, and is stored in a non-volatile auxiliary storage device 502 which is a non-temporary storage medium. Therefore, the computer 500 may have an interface for reading data from removable media.

For example, the CPU 501 of the computer 500 constituting the user terminal 100 functions as the transaction generation unit 101 by operating according to the transaction generation program loaded in the memory 503 of the computer 500, and is loaded into the memory 503. By operating according to the zero-knowledge proof value generation program, it functions as the zero-knowledge proof value generation unit 102. The same applies to the relationship between the program and the other functional unit of the user terminal 100 and the relationship between the functional unit and the program of the other terminal.

Note that some or all of the functions of the terminal included in the blockchain system may be realized by hardware such as ASIC (Application Specific Integrated Circuit) or FPGA (Field-Programmable Gate Array).

In the present embodiment, the information used by each terminal included in the blockchain system may be represented by any data structure regardless of the data structure. For example, a properly selected data structure from a table, list, database or queue can store the information.

The user terminal 100 is a computer system configured on one computer physically or on a plurality of computers logically or physically configured, and operates in separate threads on the same computer. It may operate on a virtual computer built on a plurality of physical computer resources. The same applies to other terminals.

FIG. 3 is a sequence diagram showing an example of the setup process of the blockchain system of this embodiment and the zero-knowledge proof value generation / verification process following the setup process.
First, the setup process will be described. The zero-knowledge proof value generation key / verification key generation unit 201 of the system management terminal 200 generates a zero-knowledge proof value generation key and a zero-knowledge proof value verification key (S210).

The algorithm used to generate the zero knowledge proof value generation key and the zero knowledge proof value verification key is, for example, zero knowledge from a set of public key cryptographic statements encrypted with a public key described in Non-Patent Document 2. A CRS (Comon Reference Strings) generation algorithm (an example of an asymmetric additive quasi-isomorphic cryptosystem) in which a certification value generation key is generated is used. Further, for example, a private key for a set of public key cryptosystems in this CRS generation algorithm is generated as a zero-knowledge proof value verification key.

Next, the communication unit 202 of the system management terminal 200 transmits the zero-knowledge proof value generation key generated in step S210 to the user terminal 100 (S211), and transmits the zero-knowledge proof value verification key to the transaction approval terminal 300 (S212). ).

The zero-knowledge proof value generation key received by the user terminal 100 is stored in the zero-knowledge proof value generation key storage unit 104, and the zero-knowledge proof value verification key received by the transaction approval terminal 300 is the zero-knowledge proof value verification key storage unit. It is stored in 303, and the setup process ends.

Next, the zero-knowledge proof value generation / verification process during the operation of the consortium blockchain will be described. The transaction generation unit 101 of the user terminal 100 generates a transaction to be transmitted to the blockchain (S110).

The zero-knowledge proof value generation unit 102 of the user terminal 100 uses the zero-knowledge proof value generation key stored in the zero-knowledge proof value generation key storage unit 104 for the transaction generated in step S111 (for example, zero). (By encrypting with the knowledge proof value generation key), the zero knowledge proof value is generated, and the zero knowledge proof data including the generated zero knowledge proof value is generated (S111). The communication unit 103 of the user terminal 100 transmits the generated zero-knowledge proof data to the transaction approval terminal 300 (S112).

The zero-knowledge proof generation algorithm used by the zero-knowledge proof value generation unit 102 of the user terminal 100 is, for example, the zero-knowledge proof generation algorithm described in Non-Patent Document 2. In this case, it consists of a linear sum of the ciphertext data subsets (including not only the true subset but also the ciphertext data set itself) in the zero-knowledge proof generation key, which is a set of ciphertexts of a specific public key cryptosystem. The set of ciphertexts is an example of zero-knowledge proof values.

FIG. 4 is an example of a data format of zero-knowledge proof data. The zero-knowledge proof data 600 includes a zero-knowledge proof value unit 601 and a statement unit 602 that holds a statement. The zero-knowledge proof value unit 601 holds a zero-knowledge proof value. The statement unit 602 holds a statement which is auxiliary information necessary for the zero-knowledge proof value verification process described later. When the zero-knowledge proof generation algorithm described in Non-Patent Document 2 is used, the zero-knowledge proof value unit 601 includes a plurality of specific public key cryptosystems.

Further, in this case, the statement (auxiliary information) input to the statement unit 602 includes, for example, a part or all of the transaction data, version information, protocol name, and the like. If auxiliary information is not required for the zero-knowledge proof value verification process, the statement unit 602 may be blank.

Even when auxiliary information is required for the zero-knowledge proof value verification process, the zero-knowledge proof data 600 may hold only the zero-knowledge proof value. In this case, the user terminal 100 may, for example, hold the zero-knowledge proof value. , Another method or auxiliary information such as transaction data is transmitted to the transaction approval terminal 300 via the network 400.

Returning to the description of FIG. Following step S112, the verification unit 301 of the transaction approval terminal 300 that has received the zero-knowledge proof value follows a specific algorithm using the zero-knowledge proof verification key stored in the zero-knowledge proof value verification key storage unit 303. Verification of the zero-knowledge proof value is executed (S310).

When the verification unit 301 determines that the verification result is [true], the verification unit 301 determines that the received transaction is a legitimate transaction and writes it in the distributed ledger 304. On the other hand, when the verification unit 301 determines that the verification result is [false], the verification unit 301 determines that the received transaction is an invalid transaction and discards it. The verification unit 301 may transmit the verification result to the user terminal 100 via the communication unit 302.

For example, when the zero knowledge proof value is a set of ciphertexts of a specific public key cryptosystem and the zero knowledge proof verification key is a secret key for decrypting these ciphertexts, the verification unit 301 In the zero knowledge proof verification process of step S310, a set of public key ciphertexts is decrypted with the private key, and the decrypted plain text set is in the verification process of Non-Patent Document 2. [True] is output when all the relational expressions of the following equations are satisfied, and [false] is output when not.

Specifically, for example, a set of ciphertexts of the LWE encryption method (an example of an asymmetric additive homomorphic encryption method) having additive homomorphism described in Non-Patent Document 3 is set as a zero-knowledge proof value generation key, and they are used. The private key of may be used as a zero-knowledge proof value test. By using the LWE cipher described in Non-Patent Document 3, it is possible to have resistance to attacks by quantum computers, and by extension, the convenience and security of users who use the blockchain are improved. Further, more generally, a set of ciphertexts of public key cryptography having additive homomorphism may be used as a zero-knowledge proof generation key, and their private keys may be used as a zero-knowledge proof verification key.

As described above, the blockchain system of the present embodiment is a general additive homomorphic encryption without using the Paillier operation, which has a large amount of calculation and does not have resistance to attacks using a quantum computer. Transaction verification can be performed using ElGammal encryption, Paillier encryption, or the like (that is, encryption using only operations different from the Pairing operation). As a result, in the blockchain system of this embodiment, various parameter lengths can be shortened.

Even if a cryptographic method is used in which the zero-knowledge proof value generation key and the zero-knowledge proof value verification key are a set of ciphertexts of the Pairing cipher and a set of their private keys as described in Non-Patent Document 1, this implementation is performed. The example blockchain system is feasible.

Although the example in which the blockchain system includes one transaction approval terminal 300 has been described, the blockchain system has a plurality of transaction approval terminals 300 that can communicate with each other and can verify transactions and zero-knowledge proof values. May include.

In this case, the user terminal 100 transmits the zero-knowledge proof data 600 to the plurality of transaction approval terminals 300. Further, for example, the zero-knowledge proof data 600 may be transmitted to a limited (for example, one) transaction approval terminal 300, and the transaction approval terminal 300 may transmit the zero-knowledge proof data 600 to another transaction approval terminal 300. , The zero-knowledge proof data 600 may be disclosed or shared so that the other transaction approval terminal 300 can refer to it.

At this time, each transaction approval terminal 300 may perform the verification process by a different algorithm. At this time, the transaction approval terminals 300 may communicate with each other via the network 400, refer to each other's verification results, and agree on whether or not to write in the distributed ledger 304.

Specifically, for example, it is agreed to approve the target transaction when the verification result of the transaction approval terminal 300 of a predetermined ratio (for example, 80%) or more of the plurality of transaction approval terminals 300 is [true]. , Agree to reject the target transaction when the verification result of the transaction approval terminal 300 less than a predetermined ratio is [true].

Since the blockchain system includes a plurality of transaction approval terminals 300 in this way, strong transaction approval authority is distributed, so that some transaction approval terminals 300 are used by a malicious approver. However, a legitimate approval result can be obtained.

Further, in order to distribute the transaction approval authority, for example, instead of having a plurality of transaction approval terminals 300 in one company or one group company, it is possible to share a plurality of transaction approval terminals 300 with competitors having a restraining force. desirable.

The present invention is not limited to the above-described examples, and includes various modifications. For example, the above-described embodiment has been described in detail in order to explain the present invention in an easy-to-understand manner, and is not necessarily limited to the one including all the described configurations. It is also possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Further, it is possible to add / delete / replace a part of the configuration of each embodiment with another configuration.

Further, each of the above configurations, functions, processing units, processing means and the like may be realized by hardware by designing a part or all of them by, for example, an integrated circuit. Further, each of the above configurations, functions, and the like may be realized by software by the processor interpreting and executing a program that realizes each function. Information such as programs, tables, and files that realize each function can be stored in a memory, a hard disk, a recording device such as an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, or a DVD.

In addition, the control lines and information lines indicate those that are considered necessary for explanation, and do not necessarily indicate all the control lines and information lines in the product. In practice, it can be considered that almost all configurations are interconnected.

100 user terminal, 102 zero-knowledge proof value generator, 200 system management terminal, 202 zero-knowledge proof value generation key / verification key generator, 300 transaction approval terminal, 301 verification unit, 400 network, 500 computer, 501 CPU, 502 auxiliary Storage device, 503 memory, 506 communication device, 600 zero-knowledge proof data

Claims (15)

A consortium blockchain system
A first computer that holds transaction data, a generation key for generating zero-knowledge proof values, and
Including a second computer holding a verification key for verifying the zero-knowledge proof value.
The first calculator is
Using the generated key, a zero-knowledge proof value based on the transaction data is generated.
The generated zero-knowledge proof value is transmitted to the second computer,
The second calculator
The zero-knowledge proof value transmitted from the first computer is verified by using the verification key.
Receive the transaction data and
A consortium blockchain system that approves or rejects the transaction indicated by the transaction data based on the verification result of the zero-knowledge proof value. The consortium blockchain system according to claim 1.
The consortium blockchain system, wherein the generated key and the verification key are keys generated by a cryptographic method in which only operations different from the Pairing operation are performed. The consortium blockchain system according to claim 2.
The generated key contains a set of ciphertexts of asymmetric additive homomorphic encryption.
The zero-knowledge proof value includes a linear sum of a subset of the ciphertext of the asymmetric additive homomorphic encryption.
The verification key is a consortium blockchain system that includes a set of private keys that decrypt the ciphertext of the asymmetric additive homomorphic encryption. The consortium blockchain system according to claim 3.
The ciphertext of the asymmetric additive homomorphic encryption includes the ciphertext of the LWE encryption method.
The set of private keys for decrypting the ciphertext of the asymmetric additive homomorphic encryption is a consortium blockchain system including the private key of the LWE encryption method. The consortium blockchain system according to claim 1.
Including a plurality of the second calculators
The zero-knowledge proof value and transaction data generated by the first computer are shared by the plurality of second computers.
Each of the plurality of second computers verifies the zero-knowledge proof value by using the verification key.
The plurality of second calculators
Sharing the verification results by each of the plurality of second calculators,
A consortium blockchain system that approves or rejects the transaction indicated by the transaction data based on the shared verification result. A computer that approves transactions in a consortium blockchain system.
Including processor and memory
The memory holds transaction data indicating the transaction, a zero-knowledge proof value generated by using the generation key, and a verification key for verifying the zero-knowledge proof value.
The processor
The zero-knowledge proof value is verified using the verification key, and the zero-knowledge proof value is verified.
A computer that approves or rejects the transaction indicated by the transaction data based on the verification result of the zero-knowledge proof value. The calculator according to claim 6.
The generated key and the verification key are keys generated by an encryption method in which only an operation different from the Pairing operation is performed, a calculator. The calculator according to claim 7.
The generated key contains a set of ciphertexts of asymmetric additive homomorphic encryption.
The zero-knowledge proof value includes a linear sum of a subset of the ciphertext of the asymmetric additive homomorphic encryption.
The verification key is a computer including a set of private keys for decrypting the ciphertext of the asymmetric additive homomorphic encryption. The calculator according to claim 8.
The ciphertext of the asymmetric additive homomorphic encryption includes the ciphertext of the LWE encryption method.
The set of secret keys for decrypting the ciphertext of the asymmetric additive homomorphic encryption is a computer including the secret key of the LWE encryption method. The calculator according to claim 6.
The zero-knowledge proof value and the transaction data are shared with other computers included in the consortium blockchain system, approving transactions in the consortium blockchain system, and having a verification key.
The other computer verifies the zero-knowledge proof value by using the verification key possessed by the other computer.
Share the verification results by yourself and the verification results by the other computers mentioned above,
A computer that approves or rejects the transaction indicated by the transaction data based on the shared verification result. A transaction approval method that approves transactions by a computer included in the consortium blockchain system.
The calculator includes a processor and memory.
The memory holds transaction data indicating the transaction, a zero-knowledge proof value generated by using the generation key, and a verification key for verifying the zero-knowledge proof value.
The transaction approval method is
The processor verifies the zero-knowledge proof value using the verification key.
A transaction approval method in which the processor approves or rejects the transaction indicated by the transaction data based on the verification result of the zero-knowledge proof value. The transaction approval method according to claim 11.
A transaction approval method, wherein the generated key and the verification key are keys generated by an encryption method in which only an operation different from the Pairing operation is performed. The transaction approval method according to claim 12.
The generated key contains a set of ciphertexts of asymmetric additive homomorphic encryption.
The zero-knowledge proof value includes a linear sum of a subset of the ciphertext of the asymmetric additive homomorphic encryption.
The verification key is a transaction approval method including a set of private keys for decrypting the ciphertext of the asymmetric additive homomorphic encryption. The transaction approval method according to claim 13.
The ciphertext of the asymmetric additive homomorphic encryption includes the ciphertext of the LWE encryption method.
The set of private keys for decrypting the ciphertext of the asymmetric additive homomorphic encryption is a transaction approval method including the private key of the LWE encryption method. The transaction approval method according to claim 11.
The transaction approval method is
The processor is included in the consortium blockchain system, approves a transaction in the consortium blockchain system, and shares the zero-knowledge proof value and the transaction data with another computer having a verification key.
The other computer verifies the zero-knowledge proof value by using the verification key possessed by the other computer.
The processor shares the verification result by itself and the verification result by the other computer,
A transaction approval method in which the processor approves or rejects the transaction indicated by the transaction data based on the shared verification result.

Images