JP7583233B2 - Trading system, method for controlling a trading system, and program for controlling a trading system - Google Patents

Description

The present invention relates to a trading system related to distributed ledger technology such as blockchain, a control method for a trading system, and a control program for a trading system.

Virtual currencies realized using distributed ledger technologies such as blockchain have been used for some time.
There is also a demand to exchange these virtual currencies for legal tender such as the yen, and proposals have been made to exchange virtual currencies for legal tender at a fixed price (for example, Patent Document 1, etc.).

JP 2017-29706 A

However, in order to exchange "virtual currency," whose credit is guaranteed using distributed ledger technology such as blockchain, for legal tender such as the yen, a consensus must be reached among miners using a method such as POW (Proof of Work) on the blockchain, which takes approximately 10 minutes, for example. This creates the problem that it takes too long for the results of a transaction between virtual currency and legal tender to actually be reflected on the blockchain.
In addition, in order to exchange "virtual currency" managed by blockchain etc. for legal tender and reflect the transaction results on the blockchain etc., the agreement of miners is required, and there has also been the problem of rising transaction costs due to the skyrocketing fees of miners.

The present invention aims to provide a trading system, a control method for a trading system, and a control program for a trading system that can quickly and at low cost exchange virtual currency with legal tender, or exchange between legal tender currencies using virtual currency as an intermediary currency, while also ensuring security and efficiency.

The object of the present invention is to provide a trading system having a blockchain in which transaction records are maintained by a plurality of nodes and virtual currency is managed in a network constructed by these nodes, and a side chain which is a side chain of the blockchain, the system having a trading terminal for trading the virtual currency, a verification server for verifying transactions, and a transaction settlement server which is a third-party organization, the side chain being capable of managing the virtual currency managed by the blockchain and capable of conducting transactions including at least the exchange of the virtual currency with legal tender, the result information of transactions executed in the side chain being reflected in the blockchain, and the transaction information in the side chain being verified by an audit terminal and the verification server, This is achieved by a trading system characterized in that the audit terminal is a plurality of trading terminals selected from the trading terminals that are not actually functioning as parties to the virtual currency transaction, the plurality of trading terminals are involved in transactions in the side chain as parties multiple times, and when result information of multiple transactions is generated, a netting process is performed in which intermediate result information of the transactions is omitted and only the final result information of the transactions is stored, and based on the final result information of the netting process, transaction information which is a contract only between each of the trading terminals that are parties and the transaction settlement server is generated, and transactions are executed in the side chain based on the transaction information between the trading terminals and the transaction settlement server.

According to the above configuration, the side chain can manage virtual currencies managed by the blockchain, and is configured to enable transactions including at least the exchange of virtual currencies and legal tender, and the result information of transactions executed on the side chain is reflected in the main chain.
In a blockchain , it takes a long time, about 10 minutes per block, for a consensus to be reached among "miners" through POW (Proof of Work), but in the present invention, actual transactions (e.g., exchange of virtual currency and legal currency) are carried out on a side chain.
Because of this, with sidechains, there is no need to wait for consensus in POW, which shortens transaction times and enables faster transactions.
Additionally, the use of sidechains can also reduce costs, as consensus from “miners” like with blockchains is not required.
Furthermore, in a sidechain, transactions are monitored by multiple monitoring units (e.g., verification servers, audit terminals, etc.) that are different from the blockchain 's "miners," making it possible to ensure the security of transactions.
According to the above configuration, when a terminal is involved multiple times as a party in a transaction in a side chain, a netting process is performed on the transaction contents of the transaction information.
When the parties are involved in multiple transactions, in principle, the transaction contents must be executed each time. For example, if terminal A exchanges virtual currency with terminal B for 1 million yen, and then terminal B, which has obtained the virtual currency, exchanges the same virtual currency with terminal C for 1.1 million yen, the transaction contents are executed for each transaction. At this time, if terminal B does not have any funds, terminal B will borrow 1 million yen to obtain the virtual currency from terminal A, and then after exchanging the virtual currency with terminal C for 1.1 million yen, it will repay the 1 million yen. This makes it impossible to speed up transactions.
On the other hand, in the above example, if a "netting process" is performed on the transactions in which virtual currency is transferred from terminal A to terminal C, 1 million yen is transferred from terminal C to terminal A, and 100,000 yen is transferred from terminal C to terminal B, terminal B will not need to take the trouble of borrowing money in order to transact with terminal A, and the transaction can be completed quickly.
Furthermore, with this "netting process," if terminal C experiences a fund shortage of even 10,000 yen, there is a risk that all transactions at terminals A, B, and C will go into default.
Therefore, in the present invention, based on the result information of the netting process, the transaction information only between each terminal that is a party and a third party institution (e.g., a transaction settlement server, etc.) is generated for each terminal, and the transaction is executed in the side chain based on the transaction information with the third party institution.
That is, in the above example, transaction information between a third party such as a transaction settlement server and terminal A, terminal B, and terminal C is generated, for example.
Specifically, the system generates transaction information in which a third party institution pays 1 million yen to terminal A, transaction information in which the third party institution pays 100,000 yen to terminal B, and transaction information in which the third party institution delivers virtual currency to terminal C in exchange for 1.1 million yen.
In this way, by generating transaction information only between each of the parties, the terminals, and the third party institution for each terminal, even if terminal C has insufficient funds, for example, only the transaction between terminal C and the third party institution will be defaulted, and the other two transactions will be validly concluded.
Therefore, both safety and efficiency of transactions can be achieved.

Preferably, the transaction information between the terminals that are parties in the side chain of the transaction system includes a configuration in which the objects of the transaction to be exchanged are mutually conditioned, and if one of the terminals of the parties does not execute the transaction contents, the transaction contents of the other terminal are also not executed.

According to the above configuration, the transaction information between the terminals that are parties in the side chain includes a configuration in which the objects of the transaction to be exchanged (e.g., Bitcoin tokens, yen tokens, etc.) are mutually conditioned so that if one terminal of the parties does not execute the transaction contents, the transaction contents of the other terminal are not executed either, such as a delivery versus payment swap.
For this reason, even if the parties involved (terminals conducting transactions on the side chain) do not have a mutual trust relationship, they can safely conduct bilateral transactions without going through a third-party intermediary.

Preferably, the transaction information in the side chain of the trading system is subjected to a confidentiality process to keep its contents confidential.

According to the above configuration, the transaction information in the side chain is subjected to confidentiality processing, such as confidential transactions and confidential assets, to conceal its contents (e.g., transaction volume, type of token, etc.), so that the contents of transactions on the side chain are not leaked to the outside, etc., and the security of transactions is ensured.

Preferably, the virtual currency and the legal currency of the trading system are each converted into a side chain token usable on the side chain and traded on the side chain, the side chain token is configured to be authorized for issuance by the verification server , the side chain token is configured to be authorized for issuance by the verification server , and the verification server determines the validity of the exchange value of the subject of the transaction in the transaction information on the side chain .

According to the above configuration, virtual currencies and legal currencies are converted into side chain tokens (e.g., Bitcoin tokens, yen tokens, etc.) that can be used on the side chain and traded, and the issuance of side chain tokens is authorized by a monitoring unit (e.g., an audit terminal, a verification server, etc.).
Therefore, in a sidechain, transactions cannot be conducted without the permission of the monitoring department, ensuring the safety (security) of transactions.
Furthermore, according to the above configuration, the monitoring unit (e.g., a verification server, etc.) determines the validity of the exchange value of the transaction object of the transaction information in the side chain (e.g., the exchange value between a Bitcoin token and a yen token, etc.).
Therefore, for example, if the exchange value of Bitcoin tokens and yen tokens significantly differs from the current market price information, the transaction will be deemed inappropriate and will not be approved.
In this way, the present invention can prevent transactions with inappropriate content from being concluded in the side chain.

Preferably, the transaction settlement server of the transaction system locks the virtual currency on the blockchain so that it cannot be used, and the multiple audit terminals verify whether the virtual currency is locked, and if the audit terminal succeeds in the verification, unlocks or newly issues a side chain token equivalent to the virtual currency locked on the blockchain to the side chain .

The object, according to the present invention, is to provide a method for controlling a trading system having a blockchain in which transaction records are maintained by a plurality of nodes and virtual currency is managed in a network constructed by these nodes, and a side chain which is a side chain of the blockchain, and having a trading terminal for trading the virtual currency, a verification server for verifying transactions, and a transaction settlement server which is a third-party organization, wherein the side chain is configured to be able to manage the virtual currency managed by the blockchain and to enable transactions including at least the exchange of the virtual currency with legal tender, and information on the results of transactions executed in the side chain is reflected in the blockchain, and transaction information in the side chain is inspected by an audit terminal and the verification server. This is achieved by a control method for a trading system, characterized in that the audit terminal is selected from the trading terminals that are not actually functioning as a party to the virtual currency transaction, a plurality of the trading terminals are involved in transactions in the side chain multiple times as parties, and when result information of a plurality of the transactions is generated, a netting process is performed in which intermediate result information of the transactions is omitted and only final result information of the transactions is stored, and based on the final result information of the netting process, transaction information which is a contract only between each of the trading terminals that are parties and a transaction settlement server which is a third-party institution is generated, and transactions are executed in the side chain based on the transaction information between the trading terminals and the transaction settlement server.

The object of the present invention is to provide a trading system having a blockchain in which transaction records are maintained by a plurality of nodes and virtual currency is managed in a network constructed by these nodes, a side chain which is a side chain of the blockchain, a trading terminal for trading the virtual currency, a verification server for verifying transactions, and a transaction settlement server which is a third-party organization, the side chain being capable of managing the virtual currency managed by the blockchain and capable of trading at least including the exchange of the virtual currency with legal tender, and a function in which result information of transactions executed on the side chain is reflected in the blockchain, The information is achieved by a control program of the trading system for realizing the following functions: a function of verification by the audit terminal and the verification server; a function of performing a netting process in which, when a plurality of the trading terminals are involved in transactions in the side chain multiple times as parties and result information of a plurality of the transactions is generated, the intermediate result information of the transactions is omitted and only the final result information of the transactions is stored; and a function of generating transaction information which is a contract only between each of the trading terminals which are parties and a transaction settlement server which is a third party based on the final result information of the netting process, and a transaction is executed in the side chain based on the transaction information between the trading terminals and the transaction settlement server.

As described above, the present invention has the advantage of being able to provide a trading system, a control method for a trading system, and a control program for a trading system that can quickly and at low cost exchange virtual currency with legal tender, or exchange between legal tender using virtual currency as an intermediary currency, while also ensuring security and efficiency.

FIG. 1 is a schematic explanatory diagram showing a “Bitcoin (registered trademark) trading system 1” which is an embodiment of the “trading system” of the present invention. FIG. 2 is a schematic diagram of the Bitcoin "blockchain (main chain)" and its side chain, the "side chain," on a platform provided by the Internet network 2 in FIG. 1 . FIG. 2 is a schematic block diagram showing the main components of the “transaction settlement server 200” of FIG. 1. A schematic block diagram showing the main configuration of the "transaction settlement server side first various information storage unit 210" in Figure 3. A schematic block diagram showing the main configuration of the "transaction settlement server side second various information storage unit 220" in Figure 3. A schematic block diagram showing the main configuration of the "transaction settlement server side second various information storage unit 230" in Figure 3. FIG. 2 is a schematic block diagram showing the main configuration of the “validation server 100” in FIG. FIG. 8 is a schematic block diagram showing a main configuration of a “validation server side first various information storage unit 110” in FIG. 7. FIG. 8 is a schematic block diagram showing a main configuration of a “validation server side second various information storage unit 120” in FIG. 7. FIG. 2 is a schematic diagram showing the main configuration of the transaction terminals 10A, 10B, 10C, etc. shown in FIG. 2 is a schematic block diagram showing a "transaction terminal 10D (E, F, G)" of FIG. 1 that functions as an "audit terminal" in this embodiment, among the "transaction terminals" of FIG. 1. This is a schematic flowchart showing the steps that the "transaction settlement server 200" in Figure 1 performs, such as "matching processing" and "netting processing," when each of the transaction terminals 10A to 10C transmits information on a desire to trade "Bitcoin." This is another schematic flowchart showing the steps that the "transaction settlement server 200" in Figure 1 performs, such as "matching processing" and "netting processing," when each of the transaction terminals 10A to 10C transmits information on a desire to trade "Bitcoin." This is a schematic flowchart showing the process of executing individual contracts (transactions) between the confirmed "transaction settlement server 200" and each "transaction terminal 10A", etc., using the platform of this system 1. 13 is another schematic flowchart showing the process of executing individual contracts (transactions) between the confirmed "transaction settlement server 200" and each "transaction terminal 10A" etc., using the platform of the present system 1. 13 is another schematic flowchart showing the process of executing individual contracts (transactions) between the confirmed "transaction settlement server 200" and each "transaction terminal 10A" etc., using the platform of the present system 1. 13 is another schematic flowchart showing the process of executing individual contracts (transactions) between the confirmed "transaction settlement server 200" and each "transaction terminal 10A" etc., using the platform of the present system 1. 13 is another schematic flowchart showing the process of executing individual contracts (transactions) between the confirmed "transaction settlement server 200" and each "transaction terminal 10A" etc., using the platform of the present system 1. 13 is another schematic flowchart showing the process of executing individual contracts (transactions) between the confirmed "transaction settlement server 200" and each "transaction terminal 10A" etc., using the platform of the present system 1.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.
It should be noted that the embodiments described below are preferred specific examples of the present invention, and therefore various technically preferable limitations are imposed thereon. However, the scope of the present invention is not limited to these embodiments unless otherwise specified in the following description to the effect that the present invention is limited thereto.

FIG. 1 is a schematic diagram showing a "Bitcoin (registered trademark) trading system 1" which is an embodiment of the "trading system" of the present invention.
As shown in FIG. 1, the system 1 has trading terminals 10A to 10G owned by exchanges 10A to 10G, etc., for example, "Bitcoin," which is a virtual currency that is a trading object.
These trading terminals 10A and the like are located geographically apart from one another. For example, the trading terminal 10A is located in Tokyo, the trading terminal 10B in Osaka, and the trading terminal 10G in London.

These transaction terminals 10A and the like are configured to be able to communicate with each other via the Internet network 2 as shown in FIG.
As shown in FIG. 1, the Internet network 2 is also capable of communicating with a monitoring unit, for example, a "verification server 100," and a third party, for example, a "transaction settlement server 200."

As shown in FIG. 1, the transaction terminal A, etc., is configured to function as an "audit terminal 10A, etc.", which will be described later, in addition to functioning as a party to a "Bitcoin" transaction.

FIG. 2 is a schematic diagram of the Bitcoin “blockchain (main chain)” and its side chain, the “side chain,” in a platform provided by the Internet network 2 in FIG. 1 .
Currently, Bitcoin's trading price and circulation volume vary depending on the exchange, and there is no balance. There is also no common trading platform or common payment platform for Bitcoin transactions.
For this reason, the system 1 of this embodiment provides a common platform for Bitcoin transactions.

Additionally, the “blockchain (main chain)” in Figure 1 is a type of distributed ledger that manages the transaction history of Bitcoin, a virtual currency.
The blockchain network is formed by an unspecified number of nodes called miners, each of which verifies transactions, reaches a consensus on the verification results, and updates the transaction history on the blockchain.
In the present invention, the virtual currency is not limited to Bitcoin, but may be an altcoin such as Ethereum (registered trademark).

As shown in FIG. 2, in this embodiment, the main chain has a “side chain” which is a blockchain that serves as a side chain of the main chain.
This “side chain” is a network that operates on an “algorithm” different from that of the “main chain,” as described below. However, between the “main chain” and the “side chain,” a “two-way peg” is possible, as described below.
In other words, it is possible to exchange "Bitcoin" managed on the "main chain" with "side chain tokens" managed on the "side chain."

The algorithm for operating the side chain is not particularly limited, but the side chain according to the present embodiment operates on an algorithm called "Strong Federations."
Strong Federations involves multiple audit terminals distributed geographically and jurisdictionally across the network, which perform validation of transactions on the sidechain as well as validation of Bitcoin's two-way peg with the mainchain.

In this embodiment, the transaction terminal 10A or the like in FIG. 1 is configured to also function as an audit terminal.
This verification is performed using a k-of-n "multisignature scheme" algorithm (multiple private keys are required, of which a fixed number are required).
In the "main chain," consensus among "miners" is reached using "Proof of Work (Pow)," but in the "side chain," this is replaced with "multi-signature," which is designed to reduce time delays while maintaining the security of the main chain.

In addition, by using multi-signature technology, which is also implemented in the “main chain”, two-way pegging is possible without changing the specifications of the main chain.
In this embodiment, a platform is constructed on a "side chain" where the verifier's "verification server 100" and "transaction settlement server 200", in addition to the "audit terminal 10A, etc.", verify currency exchange transactions.

This platform is configured so that no transactions can be made without approval from the verification server. The verification server not only verifies the ID of the trader, but also checks the content of transactions from a legal perspective and does not approve transactions that violate laws and regulations.

The transaction terminal 10A, the verification server 100, and the transaction settlement server 200 in FIG. 1 each have a computer, including a CPU (Central Processing Unit), RAM (Random Access Memory), ROM (Read Only Memory), a hard disk, etc., and are connected via a bus.

FIG. 3 is a schematic block diagram showing the main components of the transaction settlement server 200 of FIG.
As shown in Figure 3, the transaction settlement server 200 has a transaction settlement server side control unit 201, which controls a "transaction settlement server side communication device 202" that communicates with other devices, a "transaction settlement server side display 203" that displays various information, and a "transaction settlement server side various information input device 204" that inputs various information.
In addition, the control unit 201 controls the ``transaction settlement server side first various information storage unit 210,'' ``transaction settlement server side second various information storage unit 220,'' and ``transaction settlement server side second various information storage unit 230'' in Figure 3.

Figures 4 to 6 are schematic block diagrams showing the main configurations of the ``transaction settlement server side first various information storage unit 210,'' ``transaction settlement server side second various information storage unit 220,'' and ``transaction settlement server side second various information storage unit 230'' in Figure 3, respectively.
These details will be discussed later.

FIG. 7 is a schematic block diagram showing the main configuration of the “validation server 100” in FIG.
As shown in FIG. 7, the validation server 100 has a validation server-side control unit 101, which controls a “validation server-side communication device 102” that communicates with other devices, a “validation server-side display 103” that displays various information, and a “validation server-side various information input device 104” that inputs various information.
7. The control unit 101 also controls the "validation server side first various information storage unit 110" and the "validation server side second various information storage unit 120" in FIG.

8 and 9 are schematic block diagrams showing main configurations of the "validation server side first various information storage unit 110" and the "validation server side second various information storage unit 120" in FIG. 7, respectively.
These details will be discussed later.

Fig. 10 is a schematic diagram showing the main configuration of the transaction terminals 10A, 10B, 10C, etc. in Fig. 1. In this embodiment, as described later, the transaction terminals 10A to 10C function as parties to a "Bitcoin" transaction, and the transaction terminals 10D to 10G in Fig. 1 function as "audit terminals."
For convenience of explanation, the present embodiment will be described using four inspection terminals, but the number of inspection terminals in the present invention is not limited to this, and an appropriate number of inspection terminals is required.
Furthermore, the greater the number of inspection terminals, the higher the security will be, and the fewer the number of inspection terminals, the faster the processing speed will be.
For this reason, the number of monitoring terminals is appropriately determined so as to strike a balance between the two.
The transaction terminals 10A, 10B, and 10C function as a "transaction terminal." However, since these have the same configuration, only the "transaction terminal 10C" will be described below.

FIG. 10 is a schematic block diagram showing the main configuration of the "transaction terminal 10C (A, B)" in FIG.
As shown in FIG. 10, the trading terminal 10C has a trading terminal side control unit 11C, which controls a "trading terminal side communication device 12C" that communicates with other devices, a "trading terminal side display 13C" that displays various information, and a "trading terminal side various information input device 14C" that inputs various information.
The control unit 11C also controls the "C transaction terminal side key information storage unit 15C" and the "transaction terminal side various information storage unit 16C" in FIG.
Of these, the "C transaction terminal side key information storage unit 15C" will be described later.

FIG. 11 is a schematic block diagram showing the "transaction terminal 10D (E, F, G)" of FIG. 1 that functions as an "audit terminal" in this embodiment, among the "transaction terminals" of FIG.
Hereinafter, the inspection terminals will be described as "inspection terminals 10D (E, F, G)."
The inspection terminals 10D to 10G function as an "inspection terminal", but since they have the same configuration, only the "inspection terminal 10D" will be described below.

As shown in FIG. 11, the inspection terminal 10D has an "inspection terminal side control unit 11D", which controls an "inspection terminal side communication device 12D" that communicates with other devices, an "inspection terminal side display 13D" that displays various information, and an "inspection terminal side various information input device 14D" that inputs various information.
The control unit 11D also controls the "inspection terminal side key information storage unit 15D" and the "inspection terminal verification unit 17D" in FIG.
The contents of the 'inspection terminal side key information storage unit 15D' and the 'inspection terminal verification unit 17D' will be described later.

12 to 19 are schematic flow charts showing an example of the main operations of the present system 1. FIG.
In this embodiment, the following describes an example in which "transaction terminal 10A,""transaction terminal B," and "transaction terminal C" in Figure 1 each wish to conduct a transaction related to "Bitcoin," and "transaction terminal 10D" to "transaction terminal 10G" in Figure 1 function as "audit terminals."

Figures 12 and 13 are schematic flow charts showing the process in which the "transaction settlement server 200" in Figure 1 performs "matching processing" and "netting processing" when each of the transaction terminals 10A to 10C transmits information on a desire to trade "Bitcoin."

A transaction terminal 10A or the like that wishes to use the present system 1 installs a program from the "payment server 200" in FIG.
Specifically, it is a program that functions as a tool for each trading terminal 10A etc. to execute trading matching, communication, transaction generation, etc.
As a result, the trading terminal 10A etc. uses the program to search for a counterparty for a Bitcoin transaction on the platform of this system 1, negotiate transaction information, such as the transaction details (transaction price, transaction amount, etc.), and if an agreement is reached with the counterparty, the trading terminal 10A etc. performs an exchange of Bitcoin using this system 1.

In addition, trading terminals 10A and the like that wish to use this system 1 take measures such as depositing a "collateral deposit" or the like with a "transaction settlement center" that manages the "transaction settlement server 200" in case a funds shortage or the like occurs in a transaction.
This enables the transaction terminal 10A and the like to utilize the present system 1 including the "transaction settlement server 200."

The following description will be given with reference to the flowcharts of FIG. 12 and FIG.
First, proceed to step (hereinafter referred to as "ST") 1 in FIG.
In ST1, specific condition information for the exchange of “Bitcoin” and “Yen” is transmitted from each transaction terminal 10A etc. to the “transaction settlement server 200”.

Next, the process proceeds to ST2. In ST2, the transaction settlement server 200 stores the condition information of each transaction terminal 10A, etc. in the condition information storage unit 211 of the transaction settlement server 200 in FIG.
For example, 1) the condition information of trading terminal A is that it wants to buy "1 Bitcoin" for "1 million yen" and wants to sell "1 Bitcoin" for "1.1 million yen."
Furthermore, 2) the condition information of "transaction terminal 10B" is that it wishes to purchase "2 Bitcoins" for "1.8 million yen" and that it wishes to sell "1 Bitcoin" for "1 million yen." Furthermore, 3) the condition information of "transaction terminal 10C" is that it has purchased "1 Bitcoin" for "1.1 million yen" and that it wishes to sell "2 Bitcoins" for "1.8 million yen."

Next, proceed to ST3. In ST3, the "matching processing unit (program) 212" in FIG. 4 of the "transaction settlement server 200" operates to search for a combination of "Bitcoin" desired to be executed within a specified time period (e.g., 9:00 to 11:00) and a transaction terminal 10A etc. that matches the exchange transaction conditions with a legal currency, e.g., "yen," and store the combination in the "matching result storage unit 213" in FIG. 4.

For example, trading terminal 10A sells "1 Bitcoin" to trading terminal B for "1.1 million yen," trading terminal 10A purchases "1 Bitcoin" from trading terminal 10C for "1 million yen," and trading terminal 10B purchases "2 Bitcoins" from trading terminal 10C for "1.8 million yen."
In this way, the "contract between trading terminal 10A and trading terminal B," the "contract between trading terminal 10B and trading terminal 10C," and the "contract between trading terminal 10C and trading terminal 10A" are selected as candidates and stored in the "matching result memory unit 213."

Next, proceed to ST4. In ST4, consent is sought and obtained from each contracting party, such as the trading terminal 10A, regarding the contract contents in the "matching result storage unit 213".

In this way, when each exchange A, etc. executes the contents of the contract for each contract, each exchange A, etc. needs to prepare "Bitcoin" or "Yen" that matches the contents of the contract for each contract.
For example, in the above example, the trading terminal 10A has a contract to provide "1.1 million yen" to 10C, but has a contract with trading terminal B to receive "1 million yen" from B.

In this case, if exchange A does not have 1.1 million yen but only 100,000 yen when it first executes a contract with exchange C, it will borrow the 1 million yen through a short-term loan, acquire the 1 million yen through a contract with exchange B, and then repay the 1 million yen.
This poses a problem in that it becomes difficult to carry out transactions quickly.

Therefore, in this embodiment, rather than executing each contract individually, a process called "netting" is carried out, which calculates the final amount of "Bitcoin" and "yen" acquired and provided by each exchange and omits each intermediate transaction, as follows:

In ST5, the "netting contract processing unit 214" in FIG. 4 operates, and instead of executing each of the three contracts for the trading terminals 10A, 10B, and 10C in the "matching result storage unit 213", the trading terminals 10A, 10B, and 10C and the "transaction settlement server 200" each enter into a contract to generate contract combination information that allows the trading terminals 10A, 10B, and 10C to acquire and/or provide the "Pitcoins" and/or "yen" that they ultimately acquire or provide, with a single contract.

Specifically, in the above example, between trading terminals 10A, 10B and 10C, ultimately, 1) trading terminal 10C provides "1 Bitcoin" to 10B, and 2) trading terminal 10B provides 1 million yen to trading terminal 10A and 700,000 yen to trading terminal C.
Then, the result information of this "netting agreement processing" is stored in the "netting agreement processing result information storage unit 221" of FIG.

However, in the contract contents in the "netting contract processing result information storage unit 221" in FIG. 5, if the exchange 10B of the trading terminal 10B cannot prepare 1,700,000 yen, for example, the entire contract will be defaulted and cannot be executed, which is a problem.
Therefore, in this embodiment, the "central counterparty agreement processing unit (program) 234" in Figure 6 of the "transaction settlement server 200" operates to change the contracting parties of the "netting agreement processing result information" stored in the "netting agreement processing result information storage unit 221" in Figure 5 to contracts with the "transaction settlement server 200", and store them in the "central counterparty agreement processing result information storage unit 222" in Figure 5.

Specifically, in the above example, there is a contract in which 1) the transaction settlement server 200 provides 100,000 yen to the transaction terminal 10A, 2) the transaction settlement server 200 provides 1 bitcoin to the transaction terminal 10B, and 3) the transaction settlement server 200 provides 1 bitcoin to the transaction terminal 10C, and the transaction terminal 10C provides 700,000 yen to the transaction settlement server 200.

In this way, by incorporating the "transaction settlement server 200" as a contracting entity, even if one of the contracting parties is unable to fulfill the terms of the contract, not all contracts will be defaulted; only the contract with the "transaction settlement server" where the default occurred will be defaulted, and contracts with other "transaction settlement servers 200" will be fulfilled.
Furthermore, since the contracts in the "Central Counterparty Contract Processing Result Information Storage Unit 222" are processed as netting contracts, there is no need for each party to prepare the full amount of legal tender (yen) required for performance under the contract before the above-mentioned netting at the time of performance, and therefore transactions can be carried out quickly.

In the present embodiment, an example has been described in which the "netting agreement processing unit 214" in FIG. 4 operates, and further the "central counterparty agreement processing unit 234" in FIG. 6 operates. However, these may be processed together without being separated.
Moreover, when a transaction is urgent, the processes shown in FIGS. 1 to 7 may be omitted.

Then, proceed to ST7. In ST7, the "transaction settlement server 200" checks the repayment capacity and collateral of the contracting counterparty, the trading terminal 10A, etc., and obtains the "consent" of the contracting counterparty, the trading terminal 10A, etc., for the "central counterparty contract."

As described above, the specific transaction (contract) to be executed is determined using the main chain and side chain in Figure 1.
Furthermore, as described above, by making a contract (transaction) between the "transaction settlement server 200" and each of the transaction terminals 10A, 10BC, and 10C, it is possible to guarantee a quick and safe transaction.

These transaction details include, for example, the virtual currency (Bitcoin) being traded, the type of legal tender (yen), the transaction price equivalent to the price of the virtual currency (Bitcoin) against the legal tender (yen), the currency trading volume (exchange volume), as well as the date and time of the transaction, the transaction terminal ID of the transaction, etc.

Figures 14 to 19 are schematic flowcharts showing the process of executing individual contracts (transactions) between the "transaction settlement server 200" and each "transaction terminal 10A" etc., which have been confirmed in the above-mentioned process, using the platform of this system 1.

When the transaction details are agreed upon, the transaction settlement server 200 and the transaction terminals 10A, 10B and 10C each carry out processing in accordance with the agreed upon transaction details.
Specifically, in the above example, the contracts are: 1) a contract in which the transaction settlement server 200 provides "100,000 yen" to the transaction terminal 10A, 2) a contract in which the transaction settlement server 200 provides "1 Bitcoin" to the transaction terminal 10B, and 3) a contract in which the transaction settlement server 200 provides "1 Bitcoin" to the transaction terminal 10C, and the transaction terminal 10C provides "700,000 yen" to the transaction settlement server 200.

The following will be explained in accordance with the flowcharts in Figures 14 to 19, but first, the contract process will be explained in which the "transaction settlement server 200" provides "1 Bitcoin" to the "transaction terminal 10C" and the "transaction terminal 10C" provides "700,000 yen" to the "transaction settlement server 200".

In ST11 of FIG. 14, the transaction settlement server 200 executes an operation to move the virtual currency it owns, for example, "1 Bitcoin", from the "main chain" to the "side chain".
That is, the transaction settlement server 200 performs the following operations to "lock (freeze)" a specific "1 Bitcoin" in the transaction settlement server 200 so that it cannot be used.

Specifically, the "locking multisig address generation unit (program) 223" in Figure 5 operates, and the transaction settlement server 200 uses the public keys of the "audit terminal side key information storage unit 15D" in Figure 11 of multiple audit terminals D, etc. (e.g., transaction terminals D, etc.) and the public key of the "transaction settlement server side key information storage unit 224" (Figure 5) of the transaction settlement server 200 to generate a "locking multisig address" for locking "1 Bitcoin" on the main chain, and stores it in the "locking multisig address storage unit".

Here, "multisig address" refers to a technology that requires multiple keys to sign a transaction.
At this time, the transaction settlement server 200 also uses the homomorphism of elliptic curves to generate a new public key from the public key of each inspection terminal, and generates a "multisig address" using the generated public key.

Next, proceed to ST12. In ST12, the "locking transaction generation unit (program) 231" (Figure 6) of the transaction settlement server 200 operates to generate a "locking transaction" in which "1 Bitcoin" is deposited into the "locking multisig address" of the "locking multisig address storage unit 225" in Figure 5, and stores this in the "locking transaction storage unit 232" in Figure 6.

Next, proceed to ST13. In ST13, the transaction settlement server 200 transmits the locking transaction in the "locking transaction storage unit 232" in Fig. 6 to the main chain network.
This will lock that one bitcoin into the main chain.

In addition, the "Bitcoin" on the main chain cannot be "unlocked" and becomes unusable unless the audit terminal 10D or the like inputs an electronic signature.

Next, proceed to ST14. In ST14, the "Bitcoin token request unit (program) 233" (Figure 6) of the transaction settlement server 200 operates, and the transaction settlement server 200 transmits to the "audit terminal 10D, etc." the "locking transaction" information of the "locking transaction memory unit 232" in Figure 6 and information such as the public key of the transaction settlement server 200 used when generating the "locking multisig address" of the "locking multisig address memory unit 225" in Figure 5, and requests the transmission of the transaction target, such as a "Bitcoin token," which is a side chain token, to the side chain address of the transaction settlement server 200.

Next, proceed to ST15. In ST15, the audit terminal 10D, etc. uses information such as the private key of the audit terminal 10D, etc. in the "audit terminal side key information storage unit 15D" in FIG. 11 and the public key in the "transaction settlement server side key information storage unit 224" in FIG. 5 to verify whether the "Bitcoin" is locked in the main chain.

Then, proceed to ST16. In ST16, in "Strong Federations," an algorithm used in side chains, it is determined whether an appropriate number of audit terminals 10D, etc., out of multiple audit terminals 10D, etc., have succeeded in verification.

Then, proceed to ST17. In ST17, if an appropriate number of audit terminals 10D, etc., have successfully verified, the "PEG-in" is approved, and a "1 Bitcoin token" equivalent to the "1 Bitcoin" locked in the main chain is unlocked or newly issued in the side chain, and the information is sent to the address of the transaction settlement server 200.

Next, proceed to ST18. In ST18, the "transaction settlement server 200" transmits information about the "UTXO" that holds the "1 Bitcoin token" acquired above to the "verification server 100," and registers it in the "transaction database 111" in Figure 8 in association with the corresponding "1 Bitcoin."

Therefore, if the "transaction settlement server 200" uses "1 Bitcoin token" registered in "UTXO" without the permission of the "verification server 100", the "verification server 100" will not approve the transaction when verifying the transaction and can invalidate the transaction.

Next, proceed to ST19. In ST19, the "transaction terminal 10C" transfers legal tender (700,000 yen) to the verifier managing the validation server 100 or to the yen token issuer by means of financial transfer or the like, and requests the validation server to issue a "side chain token," for example a "700,000 yen token," whose transaction history is managed in the side chain.

In this embodiment, the "verification server 100" is described as performing both transaction verification and yen token issuance, but in the present invention, the entity that issues the yen token may be different from the "verification server 200."

Next, proceed to ST20. In ST20, the "verification server side multisig address generation unit (program) 112" in FIG. 8 operates to generate a multisig address with the input of the electronic signatures of the trading terminal 10C and the validation server 200 as a release condition, using the public key of the trading terminal 10C in the "C trading terminal side key information storage unit 15D" in FIG. 10 and the public key of the validation server in the "verification server side key information storage unit 113" in FIG. 8, and store the multisig address in the "verification server side multisig address storage unit 114" in FIG. 8.

Next, proceed to ST21. In ST21, the "verification server side transaction generation unit (program) 115" in FIG. 8 operates to generate a transaction depositing the "700,000 yen token" to the multisig address in the "verification server side multisig address storage unit 114" in FIG. 8, and broadcast it to the side chain network.

As a result, on this platform, the "700,000 yen token" cannot be used without approval (signature) from the "verification server 100."

Then, proceed to ST22. In ST22, the "verification server 100" registers the "UTXO" information indicating that the "trading terminal 10C" holds the "700,000 yen token" in the "trading database 121" of Figure 9.

After this, the "transaction settlement server 200" will generate a transaction to exchange the acquired "1 Bitcoin token" for the "700,000 yen token" of the "transaction terminal 10C" and broadcast it to the side chain network.
However, in this case, if the "transaction settlement server 200" merely generates a transaction and sends a token to the transaction terminal C, there is a risk that the exchange will not be completed due to fraudulent activity by the "transaction terminal 10C".

In this embodiment, in preparation for such a situation, the transaction settlement server and transaction terminal C exchange tokens by "Delivery Versus Payment Swap" (where Bitcoin tokens and yen tokens are mutually conditioned so that if one is not performed, the other will not be performed either) (hereinafter referred to as "DVP swap").

"DVP swap" is a method that enables the exchange of virtual currencies such as Bitcoin for "yen tokens" in a private transaction without going through a third party (intermediary), while eliminating the need for mutual trust between the two parties.
Therefore, even if the parties involved in a transaction on a side chain do not have a mutual trust relationship, they can safely conduct bilateral transactions without going through a third-party intermediary.

The following describes the "DVP swap." In this embodiment, the "transaction settlement server 200" generates a "multisig address" using the public keys of the "transaction settlement server 200" and the "transaction terminal 10C," and uses the multisig address to generate a transaction depositing "1 Bitcoin token" and "700,000 yen token."

Then, the "transaction settlement server 200" and the "transaction terminal 10C" input (add) their respective electronic signatures to the transaction and broadcast it.
Specifically, the following applies:

In ST24, the "transaction settlement server 100" uses the public keys of the transaction settlement server 200 and the transaction terminal 10C in the "transaction settlement server side key information storage unit 224" in FIG. 5 and the "C transaction terminal side key information storage unit 13C" in FIG. 10 to set the input of the electronic signatures of the transaction settlement server 200 and the transaction terminal 10C as a release condition and store the output of "1 Bitcoin token" with the address of the "transaction terminal 10C" as the output destination as a transaction.

Next, proceed to ST25. In ST25, the "transaction settlement server 200" uses the public keys of the "transaction settlement server 200, transaction terminal 10C, and verification server 100" in the "transaction settlement server side key information storage unit 224" in FIG. 5, the "C transaction terminal side key information storage unit 13C" in FIG. 10, and the "verification server side key information storage unit 113" in FIG. 8 to set the input of the electronic signatures of the three parties as a release condition, and stores the output of the "700,000 yen token" in the transaction, with the output destination being the address of the "transaction settlement server 200" or the "multisig address" of the transaction settlement server 200 and the verification server 100.

When generating the above-mentioned transaction, the "transaction settlement server 200" generates an encrypted transaction so that it cannot be viewed by anyone other than the parties involved, in order to conceal the type and quantity of the "1 Bitcoin token" and "700,000 yen token" exchanged in the transaction, i.e., the transaction details, from third parties.

Specifically, the transaction settlement server 200 generates a transaction in which the transaction contents are encrypted using a concealment process such as a method called "Confidential Transaction" and "Confidential Assets."

This means that the transaction details on the sidechain will not be leaked, ensuring the safety of transactions.

Below, we will explain "confidential transactions" that encrypt the transaction amount.
Confidential transactions are a method of concealing the transaction volume of "Bitcoin tokens" and "Yen tokens" made public by the blockchain, and encrypt the transaction volume using homomorphic encryption.

In a confidential transaction, a “Pedersen Commitment” is used, and the transaction amount (a) is expressed as a commitment C(a) shown in the following formula (1).
Commitment C(a) = xG + aH (1)
x is a secret key (blinding factor) shared by the parties, and G and H are base points (discrete logarithm points) on the elliptic curve.

As shown in equation (1), in addition to the base point (G) for converting a private key into a public key in normal elliptic curve cryptography, a base point (H) for encrypting the transaction amount (a) is added to generate a commitment C(a).
In a confidential transaction, the quantity of each input and output stored in the transaction is represented by a commitment C(a), and the commitment C(a) is written in the script of each input and output instead of the quantity.

Commitment C(a) has additive properties, such that the sum of multiple commitments C(a) is equal to the commitment C(a) of the sum of the committed transaction amounts (a).
For example, the relationship C(1)+C(1)=C(2) holds.
Therefore, the transaction volume (a) can be verified by checking whether the sum of the commitments C(a) of each input minus the sum of the commitments C(a) of each output results in zero.
This allows a party who knows the private key (x) to know the transaction amount (a), while a third party cannot know the transaction amount (a).

In addition, confidential transactions use range proofs such as ring signatures to prove that the committed transaction amount (a) is greater than or equal to 0.

Next, we will explain “confidential assets,” which conceal the type (asset type) of “tokens” being traded in addition to the trading volume.
Confidential assets are an application of confidential transactions, which conceal not only the transaction volume but also the type (asset type) of “Bitcoin token” or “Yen token” being traded.

Confidential Assets will calculate commitments using different base points for each type of cryptocurrency, such as Bitcoin Token.
For example, assuming two types of “Bitcoin token” and “yen token” with transaction volumes (a) and (b), the commitment C(a) of the “Bitcoin token” etc. with transaction volume (a) is calculated using formula (1), and the commitment C(b) of the “Bitcoin token” etc. with transaction volume (b) is calculated using the following formula (2).

C(b)=xG+bI...(2)
"I" and "H" are similarly base points on the elliptic curve.
As can be seen by comparing equations (1) and (2), in confidential assets, different base points H and I are selected depending on the type of “Bitcoin Token” and the commitments C(a) and C(b) are calculated. b) is calculated.

Then, commitments C(a) and C(b) are described as the quantities of each input and output, and each commitment C(a) and C(b) is labeled with base points H and I according to the type, such as "Bitcoin token."

This ensures that the transaction volumes (a) and (b) are kept confidential.
However, if the base point H is a fixed value, the type of the token, such as a “Bitcoin token,” would be identified. Therefore, for confidential assets, the base point H is replaced with A as shown in the following equation (3).
A=H+rG...(3)
where r is a secret field value known only to the parties involved. When the base point H is replaced with A, formula (1) is expressed as the following formula (4).
C(a)=xG+aA=xG+a(H+rG)=(x+ra)G+aH...(4)
As can be seen by comparing equations (1) and (4), the private key x is replaced with (x, r).

A party who knows the random value r can know the type of “Bitcoin token” etc. from the base point A, while a third party cannot know the type of “Bitcoin token” etc.
In addition, in Confidential Assets, base point A is constructed using a ring signature to prevent the creation of currency.

Although the above describes a so-called "DVP swap" on a single chain, it is also possible to generate multiple transactions to perform currency exchange, such as a cross-chain "DVP swap" or "atomic swap."
In other words, the number of transactions generated by the "transaction settlement server 200" and the "transaction terminal 10C" is not limited to one.

In this way, the "transaction settlement server 200" and the "transaction terminal 10C" can generate a transaction that encrypts the transaction details, etc., for exchanging "1 Bitcoin token" and "700,000 yen token" without the need for a trust relationship due to the "DVP swap" as described above.

Then, proceed to ST26 in FIG. 17. In ST26, the "transaction settlement server 200" inputs the electronic signature of the "transaction settlement server 20" into the transaction using the private key of the "transaction settlement server 200" in the "transaction settlement server side key information storage unit 224" in FIG. 5, and transmits it to the "transaction terminal 10C."

Next, proceed to ST27. In ST27, the "trading terminal 10C" inputs an electronic signature to the received transaction using the private key of the "trading terminal 10C" in the "C-trading terminal side key information storage unit 15C".

At this time, if the "transaction terminal 10C" commits fraud and alters the output destination of the "700,000 yen token" that should be output to the "transaction settlement server 200," the "transaction settlement server 200" will fail to verify the electronic signature entered, and the transaction will be determined to be invalid.
In this manner, the above-described process allows a transaction to be carried out safely without the involvement of a third party and without the need for a trusting relationship with the other party.

Next, proceed to ST28. In ST28, the "transaction settlement server 200" and the "transaction terminal 10C" send the generated transaction to the "verification server 100" and request verification of the transaction. The "transaction settlement server 200" and the "transaction terminal 10C" also send the private key used to conceal the transaction so that the "verification server 100" can verify the transaction.

Then, proceed to ST29. In ST29, the "Decryption unit (program) 122" in FIG. 9 operates to decrypt information indicating transaction details such as the exchange amount (transaction amount) and type of "token" using the private keys transmitted from the "transaction settlement server 200" and the "transaction terminal 10C."

Then, the "approval unit (program) 123" in FIG. 9 operates to verify whether the decrypted transaction details are valid, and if so, approves the transaction, and if not, does not approve the transaction.

Specifically, for example, the "approval unit (program) 123" of the "verification server 100" calculates the transaction price (exchange rate) of the currency exchange transaction carried out between the "transaction settlement server 200" and the "transaction terminal 10C" from the quantity of "Bitcoin tokens" and the quantity of "yen tokens" exchanged in the above transaction.

Since the "Bitcoin Token" corresponds to virtual currency and the "Yen Token" corresponds to legal tender, the calculated price is equivalent to the buying and selling price of virtual currency against legal tender.
In addition, the validation server 200 obtains current market value information of virtual currency against legal currency from a predetermined external API (Application Programmable Interface).

Then, the “validation server 100” determines whether the difference between the transaction price calculated above and the transaction price (distribution route) of the generally circulating virtual currency is equal to or greater than a predetermined threshold.
If it is determined that the difference between the two is equal to or greater than a threshold, the “verification server 100” determines that the transaction is an inappropriate transaction and does not approve the transaction.

In financial transactions, various regulations, including laws, regulations, and self-regulations, are generally in place to crack down on inappropriate transactions.
On the other hand, the present system 1 is a decentralized trading system that uses blockchain, and there is no centralized administrator to manage transactions.
However, if transactions are left entirely to the users, there is a risk that inappropriate transactions may be conducted in light of general regulations on financial transactions.

For example, there is a risk that parties may collude and exchange small amounts of Japanese yen for large amounts of virtual currency (Bitcoin), leading to activities similar to money laundering.
Therefore, in this embodiment, the "verification server 100" verifies the transaction contents to prevent inappropriate transactions.

For example, the validation server may validate the exchange rate of the currency exchanged in the transaction as described above to determine whether the transaction is improper.
In addition, the "verification server 100" verifies information related to transactions, such as the ID of each trading terminal and UTXO, and determines whether the transaction is inappropriate.

In the above embodiment, verification is performed based on the currency exchange rate, the ID of the parties, UTXO, etc., but the present invention is not limited to this, and verification may be performed based on, for example, the currency trading volume, etc.

In other words, the "verification server 100" only needs to be able to determine whether the transaction content is a valid transaction, and there are no particular limitations on the conditions for this determination.

Next, in ST31 of FIG. 18, if the "approval unit (program) 123" of the "verification server 100" determines that the transaction is valid and the verification is successful, the "verification server 100" adds an electronic signature to the transaction using the private key of the "verification server 100" in the "verification server side key information storage unit 113" of FIG. 8, and broadcasts it to the side chain network.

Next, the process proceeds to ST32. In ST32, the transaction broadcast from the validation server 100 is validated by the audit terminal 10D or the like.
The "audit terminal 10D" etc. have their "audit terminal verification unit (program) 17D" shown in FIG. 11 operating, and verify the transaction using the "strong federation" algorithm adopted in the side chain rather than "Pow" which relies on the computing power of the terminal, and if they agree to adding the transaction to a block in the side chain, each audit terminal 10D etc. inputs the electronic signature of the "audit terminal 10D" etc. into the block.

The "audit terminal 10D" and the like verify transactions and form consensus using the "strong federation" algorithm adopted in side chains, rather than "Pow", which relies on the computing power of the terminal.
In the strong federation, processing is performed in a round robin manner, and among a plurality of audit terminals, one of the audit terminals such as the audit terminal 10D is selected in turn as the master to perform the verification.
The audit terminal 10D or the like that has become the master verifies the script of each transaction broadcast on the side chain network and generates candidates for blocks to be added to the side chain.
The master audit terminal 10D or the like transmits the generated block candidates to the other audit terminals.

Next, proceed to ST33. In ST33, "if electronic signatures are input from a predetermined number of audit terminals among the multiple audit terminals 10D, etc., the block is added to the side chain, and the transaction between the "transaction settlement server 200" and the "transaction terminal 10C" is successfully incorporated into the side chain."

Since the side chain adopts strong federation, it does not rely on the computing power of the “audit terminal 10D” etc., so the computational load is greatly reduced, the time required for consensus building is shortened, and transactions can be executed quickly.
On the other hand, by requiring the consent of a certain number of "audit terminals 10D", etc., the security (Byzantine resistance) guaranteed by the main chain can be maintained.

Next, proceed to ST34. In ST34, the "transaction settlement server 100" requests the "audit terminal 10D" etc. and/or the verification server 100 to release the "locking transaction" that has locked "1 Bitcoin" on the main chain.

Next, in ST35, the "trading terminal 10C" sends a peg-out request to the "audit terminal 10D" or the like to convert the "Bitcoin token" of the side chain into "Bitcoin" of the main chain, or embeds it in the side chain.

Next, proceed to ST36. In ST36, each "audit terminal 10D" etc. that received the "peg-out" request verifies the "UTXO" of the "verification server 100" on the side chain where the "trading terminal 10C" holds the "Bitcoin token".

Next, proceed to ST37. In ST37, if a predetermined number of audit terminals 10D, etc. have successfully verified and approved the peg-out, each "audit terminal 10D", etc., inputs an electronic signature into the locking transaction, and the "Bitcoin" is unlocked.

By unlocking the "1 Bitcoin," the "transaction terminal 10C" becomes able to send the "Bitcoin" to its own wallet address.
The “Bitcoin” that is unlocked is not necessarily the “Bitcoin” that was locked by the “transaction settlement server 200” in this transaction, but may be the “Bitcoin” that was locked in another transaction.

Note that the locking transaction in which the "transaction settlement server 200" locks "Bitcoin" at the time of peg-in does not necessarily match the locking transaction that the "transaction terminal 10C", the counterparty to the transaction, unlocks at the time of peg-out, and it may be that the locking transaction was generated by another "transaction terminal 10C" in a different transaction.

Then, proceed to ST38. In ST38, the "transaction settlement server 200" transmits a redemption request for the legal tender (700,000 yen) based on the "yen token" acquired through the above-mentioned transaction to the transmission server.

Then, proceed to ST39. In ST39, the "verification server 100" that has received the redemption request checks whether the "transaction settlement server 200" holds the "700,000 yen token," and then transfers the legal tender (700,000 yen) equivalent to the "yen token" held by the "transaction settlement server 200" to the account of the transaction settlement server by means of financial transfer or the like.

In this way, in this embodiment, the "transaction terminal 10C" performs a peg-out to move the "1 Bitcoin token" from the side chain to the main chain and obtains "1 Bitcoin," and the "transaction settlement server 200" requests redemption of legal tender (700,000 yen) based on the "yen token" and obtains the legal tender (700,000 yen) by means of a financial transfer or the like.
This completes the exchange of "1 Bitcoin" from the "transaction settlement server 200" and the legal tender (700,000 yen) from the "transaction terminal 10C."

In addition, in this embodiment, the side chain is configured to ensure the security of transactions because transactions are carried out using "tokens" managed by the audit terminal 10D, etc. or the verification server 100.

Next, another transaction, that is, a contract in which the "transaction settlement server 200" provides "100,000 yen" to the "transaction terminal 10A", is also executed using this system 1.
In this case, the process is executed through steps similar to those in which the "transaction terminal 10C" provides "700,000 yen" to the "transaction settlement server 200" described above.

In addition, another transaction, a contract to provide "1 Bitcoin" to "transaction terminal 10C", is also executed using this system 1.
In this case, the process is carried out through steps similar to those in which the transaction terminal 10C provides one bitcoin to the transaction settlement server 200.

As described above, by using this system 1, it is possible to exchange virtual currency (1 Bitcoin) and legal tender (700,000 yen) without so-called counterparty risk.
In addition, they can be exchanged through bilateral transactions without the involvement of a third party, and the parties involved can control the currency being bought and sold by themselves.
Furthermore, by combining the processes executed by the "validation server 100", it is possible to impose certain restrictions on currency exchange transactions.
In addition, there is an inconvenience in processing each individual contract for multiple consecutive contracts, but in this embodiment, this is solved by operating the "transaction settlement server 200" or the like.

The validation server 100 may be configured to not only validate transactions, but also to output transaction records performed by each transaction, that is, to output reports on currency exchange transactions performed on the platform.
In general financial transactions, transaction records must be submitted upon request from financial authorities.
In response to this, the verification server 100 decrypts the encrypted transaction details of each transaction using a private key for anonymity, and outputs the transaction record.
This ensures that transaction records on this platform are kept confidential from general users, while allowing them to be viewed if necessary.

In this embodiment, the exchange of virtual currency such as Bitcoin with the legal currency, the yen, has been described as an example, but in this embodiment, the legal currency is not limited to the yen, and may be the legal currency of another country, such as the US dollar or the Vietnamese dong.

In addition, in this embodiment, the exchange between virtual currency and legal currency has been described as an example, but it is also possible to use virtual currency as an intermediary currency, for example, to exchange yen and US dollars, yen and Vietnamese dong, etc.
In this case, by arranging a Japanese yen audit terminal, a US dollar audit terminal, a Vietnamese dong audit terminal, a Malaysian ringgit audit terminal, etc. in the system 1 of FIG. 1 of this embodiment, it becomes possible to exchange Japanese yen, US dollars, Vietnamese dong, and Malaysian ringgit for each other via virtual currencies such as Bitcoin.

In the above-described embodiment, an example has been given of the case where the invention is realized as a device, but the invention is not limited to this, and the invention may be distributed as a program that can be executed by a computer, stored on a storage medium such as a magnetic disk (floppy disk, hard disk, etc.), an optical disk (CD-ROM, DVD, etc.), a magneto-optical disk (MO), or a semiconductor memory.

The storage medium may be any storage medium that can store a program and is computer-readable. There are no particular limitations on the storage format of the storage medium.

In addition, an OS (operating system), database management software, network software, or other MW (middleware) running on a computer may execute some of the processes for implementing this embodiment based on instructions from a program installed on the computer from a storage medium.

Furthermore, the storage medium in the present invention is not limited to a medium independent of a computer, but also includes a storage medium that stores or temporarily stores a program downloaded from a LAN, the Internet, etc.

The computer of the present invention only needs to execute each process in this embodiment based on a program stored in a storage medium, and may be a device consisting of a single personal computer, etc., or a system in which multiple devices are connected to a network.

In addition, the computer in this invention is not limited to a personal computer, but also includes an arithmetic processing unit, a microcomputer, etc., included in information processing equipment, and is a general term for equipment or devices that can realize the functions of this invention by a program.

The above describes an embodiment of the present invention. However, the present invention is not limited to the above embodiment, and various modifications can be made without departing from the scope of the claims. The configurations of the above embodiment can be partially omitted or arbitrarily combined in a different way than described above.

1: Bitcoin trading system, 10A to 10G: trading terminal, 11C: trading terminal control unit, 11D: audit terminal control unit, 12C: trading terminal communication device, 12D: audit terminal communication device, 13C: trading terminal display, 13D: audit terminal display, 14C: trading terminal various information input device, 14D: audit terminal various information input device, 15C: C trading terminal key information storage unit, 15D: audit terminal key information storage unit, 16C: trading terminal various information storage unit, 17D: audit terminal verification unit (program), 100: verification Verification server, 101... verification server side control unit, 102... verification server side communication device, 103... verification server side display, 104... verification server side various information input device, 110... verification server side first various information storage unit, 111, 121... transaction database, 112... verification server side multisig address generation unit (program), 113... verification server side key information storage unit, 114... verification server side multisig address storage unit, 115... verification server side transaction generation unit (program), 120... verification server side second various information storage unit, 122... Decryption unit (program), 123: Approval unit (program), 200: Transaction settlement server, 201: Transaction settlement server side control unit, 202: Transaction settlement server side communication device, 203: Transaction settlement server side display, 204: Transaction settlement server side various information input device, 210: Transaction settlement server side first various information storage unit, 211: Condition information storage unit, 212: Matching processing unit (program), 213: Matching result storage unit, 214: Netting contract processing unit, 220: Transaction settlement server side second various information storage unit, 221: Netting Contract processing result information storage unit, 222: central counterparty contract processing result information storage unit, 223: locking multisig address generation unit (program), 224: transaction settlement server side key information storage unit, 225: locking multisig address storage unit, 230: transaction settlement server side second various information storage unit, 231: locking transaction generation unit (program), 232: locking transaction storage unit, 233: Bitcoin token request unit (program), 234: central counterparty contract processing unit (program),

Claims (7)

A blockchain is a network in which transaction records are kept by multiple nodes and virtual currencies are managed by the network built by these nodes.
A side chain that is a side chain of the blockchain,
A trading system having a trading terminal for trading the virtual currency, a verification server for verifying the transaction, and a transaction settlement server which is a third-party organization,
The side chain is configured to be able to manage virtual currencies managed by the blockchain and to enable transactions including at least the exchange of the virtual currencies with legal tender, and information on the results of transactions executed on the side chain is reflected on the blockchain,
The transaction information in the side chain is verified by the audit terminal and the verification server,
The audit terminal is a plurality of the trading terminals selected from the trading terminals that are not actually functioning as a party to the virtual currency transaction,
A trading system characterized in that a plurality of the trading terminals are involved in transactions in the side chain multiple times as parties, and when result information of multiple transactions is generated, a netting process is performed in which intermediate result information of the transactions is omitted and only the final result information of the transaction is stored, and transaction information which is a contract only between each of the trading terminals which are parties and the transaction settlement server is generated based on the final result information of the netting process, and transactions are executed in the side chain based on the transaction information between the trading terminal and the transaction settlement server. The trading system according to claim 1, characterized in that the transaction information between the terminals that are parties in the side chain includes a configuration in which the objects of the transaction to be exchanged are mutually conditioned, and if one of the terminals of the parties does not execute the transaction contents, the transaction contents of the other terminal are also not executed. The trading system according to claim 1 or 2, characterized in that the transaction information in the side chain is subjected to a confidentiality process to keep its contents confidential. The virtual currency and the legal tender are converted into side chain tokens that can be used on the side chain and traded on the side chain, respectively;
The side chain token is configured so that the validation server authorizes issuance of the side chain token,
The trading system according to any one of claims 1 to 3, characterized in that the validation server determines the validity of the exchange value of the transaction object of the transaction information in the side chain. The transaction settlement server locks the virtual currency in the blockchain so that it cannot be used;
The transaction system according to claim 4, characterized in that a plurality of the audit terminals verify whether the virtual currency is locked, and if the audit terminal succeeds in the verification, unlocks or newly issues a side chain token equivalent to the virtual currency locked in the blockchain to the side chain. A blockchain is a network in which transaction records are kept by multiple nodes and virtual currencies are managed by the network built by these nodes.
A side chain that is a side chain of the blockchain,
A method for controlling a trading system having a trading terminal for trading the virtual currency, a verification server for verifying the transaction, and a transaction settlement server which is a third-party organization, comprising:
The side chain is configured to be able to manage virtual currencies managed by the blockchain and to enable transactions including at least the exchange of the virtual currencies with legal tender, and information on the results of transactions executed on the side chain is reflected on the blockchain,
The transaction information in the side chain is verified by the audit terminal and the verification server,
The audit terminal is selected from the trading terminals that are not actually functioning as a party to a transaction of the virtual currency;
A method for controlling a trading system, characterized in that a plurality of the trading terminals are involved in transactions in the side chain multiple times as parties thereto, and when result information of a plurality of the transactions is generated, a netting process is performed in which intermediate result information of the transactions is omitted and only final result information of the transactions is stored, and based on the final result information of the netting process, transaction information which is a contract only between each of the trading terminals which are parties thereto and a transaction settlement server which is a third party institution is generated, and transactions are executed in the side chain based on the transaction information between the trading terminals and the transaction settlement server . A transaction system including a blockchain in which transaction records are maintained by multiple nodes and virtual currency is managed in a network constructed by these nodes , a side chain which is a side chain of the blockchain , a transaction terminal which trades the virtual currency, a verification server which verifies the transactions, and a transaction settlement server which is a third-party organization,
The side chain is configured to be able to manage virtual currencies managed by the blockchain, and to enable transactions including at least the exchange of the virtual currencies with legal tender, and the result information of transactions executed on the side chain is reflected on the blockchain;
The transaction information in the side chain is verified by the audit terminal and the verification server ;
A function of performing a netting process in which, when multiple trading terminals are involved in multiple transactions on the side chain as parties and multiple pieces of transaction result information are generated, the intermediate transaction result information is omitted and only the final transaction result information is stored;
A control program for a trading system for realizing the function of generating transaction information, which is a contract only between each of the trading terminals, which are the parties, and a transaction settlement server, which is a third-party institution, based on the final result information of the netting process, and executing a transaction on the side chain based on the transaction information between the trading terminal and the transaction settlement server .

Images