JP2024019260A - Trading system, trading system control method, and trading system control program - Google Patents

Abstract

[Problem] A transaction system that allows the exchange of virtual currency and legal currency, or the exchange between legal currencies using virtual currency as an intermediary currency, quickly and at low cost, while also ensuring security safety and efficiency. to provide. [Solution] It has a blockchain in which transaction records are maintained by multiple nodes and virtual currency is managed in a network built by these nodes, and a side chain that is a side chain of the blockchain. In addition to being able to manage virtual currency managed on the blockchain, it is also configured to allow transactions, including at least the exchange of virtual currency with legal currency, and information on the results of transactions executed on the side chain is transferred to the main chain. The trading system 1 is configured such that transaction information on the side chain is monitored by multiple monitoring units different from the main chain. [Selection diagram] Figure 1

Description

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

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

JP2017-29706

However, in order to exchange "virtual currency" whose trust is secured using distributed ledger technology such as blockchain for legal currency such as yen, it is necessary to use blockchain etc., for example, POW (Proof of Work) etc. It is necessary to form a consensus among miners on the method, and it takes about 10 minutes, for example, so it takes too long for the transaction results between virtual currency and legal currency to actually be reflected in the blockchain, etc. There was a problem.
In addition, in order to exchange "virtual currency" managed on a blockchain etc. with legal currency and have the transaction results reflected on the blockchain etc., the agreement of the miners is required, and the fees of the miners are rising. There was also the problem that transaction costs were rising due to the

Therefore, the present invention enables the exchange of virtual currency and legal currency, or the exchange between legal currencies using virtual currency as an intermediary currency, quickly and at low cost, and also ensures security safety and efficiency. The purpose of the present invention is to provide a trading system, a trading system control method, and a trading system control program.

According to the present invention, the purpose is to provide 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 that is a side chain of the blockchain. The transaction system has a configuration in which the side chain is capable of managing virtual currency managed by the blockchain, and at least allows transactions including the exchange of the virtual currency with legal currency. Information on the results of transactions executed on the side chain is reflected on the main chain, and transaction information on the side chain is monitored by a plurality of monitoring units different from the main chain. trading system. This is achieved by

According to the above configuration, the side chain is configured to be able to manage the virtual currency managed by the blockchain, and at least allow transactions including the exchange of virtual currency with legal currency. The result information of the transaction is reflected on the main chain.
In the main chain, it takes a long time to form a consensus among "miners" using POW (Proof of Work), which is about 10 minutes per block. exchanges, etc.) are performed on the side chain.
For this reason, in the side chain, there is no need to wait for consensus formation in POW, so the transaction time can be shortened, and therefore, quick transactions are possible.
Also, by using a side chain, there is no need for the consensus of "miners" like in the main chain, which can also reduce costs.
Furthermore, in side chains, transactions are monitored by multiple monitoring units (e.g. verification servers, audit terminals, etc.) that are different from the main chain's "miners", making it possible to ensure the safety of transactions. There is.

Preferably, the transaction information between terminals that are parties in the side chain of the transaction system includes a mutual condition on the transaction objects to be exchanged, so that if one terminal of the parties does not execute the transaction content, the transaction information of the other terminal is The content is also characterized by including a configuration that is not executed.

According to the above configuration, transaction information between terminals that are parties in the side chain is mutually conditioned on the transaction object to be exchanged (e.g., Bitcoin token, yen token, etc.), and one terminal of the parties is informed of the details of the transaction. If not executed, the transaction content of the other terminal is also not executed, such as a delivery versatile payment swap.
Therefore, even if parties who are terminals that conduct transactions on a side chain do not have a trusting relationship with each other, they can safely conduct bilateral transactions without using a third party, such as an intermediary.

Preferably, the transaction information in the side chain of the transaction system is subjected to a concealment process to conceal its contents.

According to the configuration, the transaction information in the side chain undergoes a concealment process to conceal its contents (for example, transaction amount, token type, etc.), such as confidential transactions, confidential assets, etc. This ensures that transaction details on the side chain are not leaked to outside parties, ensuring transaction safety.

Preferably, the virtual currency and the legal currency of the trading system are each converted and traded on the side chain into a side chain token usable on the side chain, and the side chain token is traded on the side chain. It is characterized in that the monitoring unit is configured to permit its issuance.

According to the above configuration, virtual currency and legal currency are each converted and traded on the side chain into side chain tokens (e.g., Bitcoin tokens, yen tokens, etc.) that can be used on the side chain, The side chain token is configured such that a monitoring unit (for example, an audit terminal, a verification server, etc.) permits its issuance.
Therefore, in the side chain, transactions cannot be made without permission from the monitoring department, ensuring transaction security.

Preferably, the monitoring unit of the transaction system determines the validity of the exchange value of the transaction object of the transaction information in the side chain.

According to the above configuration, the monitoring unit (eg, verification server, etc.) determines the validity of the exchange value of the transaction object (eg, the exchange value of Bitcoin token and Yen token, etc.) of transaction information in the side chain.
Therefore, for example, if the exchange value of a Bitcoin token and a yen token is significantly different from market price information, the transaction will not be approved as an inappropriate transaction.
in this way. According to the present invention, it is also possible to prevent transactions with inappropriate content from occurring in the side chain.

Preferably, the transaction information of the transaction system is configured such that it is recognized as the transaction information in the side chain only after it has been repeatedly verified by a plurality of the audit sections.

According to the above configuration, transaction information is recognized as transaction information in the side chain only after it has been repeatedly verified by multiple audit departments (for example, verification servers, audit terminals, etc.). It is possible to ensure the safety of transactions in the chain.

Preferably, when the terminal of the transaction system is involved in transactions in the side chain multiple times as a party, it performs a netting process on the transaction details of the transaction information, and based on the result information of the netting process, The transaction information only between each terminal and a third party organization is generated for each terminal, and the transaction is executed on the side chain based on the transaction information with the third party organization. It is characterized by

According to the above configuration, when the terminal is involved in a transaction in the side chain multiple times as a party, netting processing is performed on the transaction content of the transaction information.
When a party engages in a transaction multiple times, in principle, the details of the transaction must be carried out each time. For example, if terminal A exchanges virtual currency with terminal B for 1 million yen, and then terminal B, which obtained the virtual currency, exchanges the same virtual currency with terminal C for 1.1 million yen, the transaction details for each transaction are as follows: Execute. At this time, if terminal B does not have any money, terminal B borrows 1 million yen and acquires virtual currency from terminal A, and then exchanges the virtual currency with terminal C for 1.1 million yen. You will have to pay back the yen. This makes it impossible to speed up transactions.

On the other hand, in the above example, if we perform a "netting process" 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 does not have to take the trouble of borrowing money for transactions with terminal A, and can perform transactions quickly.
Furthermore, in this "netting process", if terminal C has a shortage of funds even by 10,000 yen, there is a risk that the entire transaction of terminals A, B, and C will be in default.

Therefore, the present invention further generates transaction information for each terminal only between each terminal that is a party and a third party organization (for example, a transaction settlement server, etc.) based on the result information of the netting process, Transactions are executed on the side chain based on transaction information with third-party institutions.
That is, in the above example, transaction information between terminal A, terminal B, and terminal C and a third party organization such as a transaction settlement server is generated, respectively.
Specifically, there is transaction information in which a third party pays 1 million yen to terminal A, transaction information in which a third party pays 100,000 yen to terminal B, and transaction information in which a third party pays 1,100,000 yen to terminal C. Generates transaction information, etc. for transferring virtual currency to.
In this way, by generating transaction information for each terminal only between the terminals that are the parties involved and the third-party organization, for example, even if terminal C has a lack of funds, it is possible to Only the transaction with will be defaulted, and the other two transactions will be validly concluded.
Therefore, both transaction safety and efficiency can be achieved.

According to the present invention, the purpose is to provide 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 that is a side chain of the blockchain. A control method for a transaction system having a side chain, wherein the side chain is configured to be able to manage virtual currency managed by the blockchain, and at least enable transactions including exchange of the virtual currency with legal currency. In addition, the result information of transactions executed on the side chain is reflected on the main chain, and the transaction information on the side chain is monitored by a plurality of monitoring units different from the main chain. This is achieved by a method of controlling a trading system characterized by:

According to the present invention, the purpose is to provide 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 that is a side chain of the blockchain. 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 currency, and the side chain To realize a function in which the result information of transactions executed on the chain is reflected on the main chain, and the transaction information in the side chain is monitored by multiple monitoring units different from the main chain. This is achieved by the control program of the trading system.

As explained above, the present invention enables the exchange of virtual currency and legal currency, or the exchange between legal currencies using virtual currency as an intermediary currency, quickly and at low cost, and also improves security and efficiency. The present invention has the advantage that it is possible to provide a trading system, a trading system control method, and a trading system control program that can also ensure performance.

1 is a schematic explanatory diagram showing a "Bitcoin (registered trademark) transaction system 1" which is an embodiment of the "transaction system" of the present invention. FIG. 2 is a schematic explanatory diagram of the "Blockchain (main chain)" of "Bitcoin" and its "side chain" on the platform provided by the Internet network 2 etc. in FIG. 1. 2 is a schematic block diagram showing the main configuration of the "transaction settlement server 200" in FIG. 1. FIG. 4 is a schematic block diagram showing the main configuration of the "transaction settlement server side first various information storage section 210" of FIG. 3. FIG. 4 is a schematic block diagram showing the main configuration of the "second various information storage unit 220 on the transaction settlement server side" in FIG. 3. FIG. 4 is a schematic block diagram showing the main configuration of the "second various information storage unit 230 on the transaction settlement server side" of FIG. 3. FIG. 2 is a schematic block diagram showing the main configuration of the "verification server 100" in FIG. 1. FIG. 8 is a schematic block diagram showing the main configuration of the "verification server side first various information storage section 110" of FIG. 7. FIG. 8 is a schematic block diagram showing the main configuration of the "second various information storage unit 120 on the verification server side" of FIG. 7. FIG. 2 is a schematic diagram showing the main configurations of transaction terminals 10A, 10B, 10C, etc. in FIG. 1. FIG. 2 is a schematic block diagram showing a "transaction terminal 10D (E, F, G)" in FIG. 1 that functions as an "audit terminal" in this embodiment among the "transaction terminals" in FIG. 1. FIG. A schematic diagram showing a process in which the “transaction settlement server 200” in FIG. 1 performs “matching processing”, “netting processing”, etc. when each of the transaction terminals 10A to 10C sends information on a desire to trade “Bitcoin”. It is a flowchart. In addition, it shows a process in which the "transaction settlement server 200" in FIG. 1 performs "matching processing", "netting processing", etc. when each of the transaction terminals 10A to 10C sends information on a desire to trade "Bitcoin". 1 is a schematic flowchart. It is a schematic flowchart showing the process of executing individual contracts (transactions) between the finalized "transaction settlement server 200" and each "transaction terminal 10A" etc. using the platform of the present system 1. It is another schematic flowchart showing the process of executing individual contracts (transactions) between the finalized "transaction settlement server 200" and each "transaction terminal 10A" etc. using the platform of the present system 1. It is another schematic flowchart showing the process of executing individual contracts (transactions) between the finalized "transaction settlement server 200" and each "transaction terminal 10A" etc. using the platform of the present system 1. It is another schematic flowchart showing the process of executing individual contracts (transactions) between the finalized "transaction settlement server 200" and each "transaction terminal 10A" etc. using the platform of the present system 1. It is another schematic flowchart showing the process of executing individual contracts (transactions) between the finalized "transaction settlement server 200" and each "transaction terminal 10A" etc. using the platform of the present system 1. It is another schematic flowchart showing the process of executing individual contracts (transactions) between the finalized "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 and the like.
Since the embodiments described below are preferred specific examples of the present invention, various technically preferable limitations are attached thereto. Unless otherwise specified, the embodiments are not limited to these embodiments.

FIG. 1 is a schematic explanatory diagram showing a "Bitcoin (registered trademark) transaction system 1" which is an embodiment of the "transaction system" of the present invention.
As shown in FIG. 1, the present system 1 includes transaction terminals 10A to 10G owned by exchanges 10A to 10G for, for example, "Bitcoin", which is a virtual currency to be traded.
These transaction terminals 10A and the like are located geographically apart from each other, for example, the transaction terminal 10A is located in Tokyo, the transaction terminal 10B is located in Osaka, and the transaction terminal 10G is located 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.
Furthermore, as shown in FIG. 1, the Internet network 2 is also capable of communicating with a monitoring unit such as a "verification server 100" and a third party organization such as a "transaction settlement server 200."

Further, as shown in FIG. 1, the transaction terminal A etc. is configured to function not only as a party to a "Bitcoin" transaction but also as an "audit terminal 10A etc." which will be described later.

FIG. 2 is a schematic explanatory diagram of the "Blockchain (main chain)" of "Bitcoin" and its "side chain" on the platform provided by the Internet network 2 etc. of FIG. 1.
Currently, Bitcoin transaction prices and circulation volumes vary among exchanges and are not balanced, and there is no common transaction platform or common payment platform for Bitcoin transactions.
Therefore, the system 1 of this embodiment provides a common platform for Bitcoin transactions.

Furthermore, the "blockchain (main chain)" in FIG. 1 is a type of distributed ledger that manages the transaction history of Bitcoin, which is a virtual currency.
A blockchain network is formed by an unspecified number of nodes called miners, each of which verifies transactions, forms a consensus on the verification results, and updates the transaction history on the blockchain.
Note that in the present invention, the virtual currency is not limited to Bitcoin, and 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 block chain serving as its side chain.
This "side chain" is a network that operates with a different "algorithm" from the "main chain", as described later, but between the "main chain" and the "side chain", as described later, " The structure allows for two-way pegs.
In other words, "Bitcoin" managed on the "main chain" and "side chain token" managed on the "side chain" can be exchanged with each other.

Although the operation algorithm of the side chain is not particularly limited, the side chain according to the present embodiment operates using an algorithm called "Strong Federations."
"Strong Federations" is a system in which multiple audit terminals distributed geographically and jurisdictionally on the network perform verification operations on transactions on the side chain, and also verify transactions between the "main chain" and the "main chain". Execute the verification operation of the two-way peg of "Bitcoin".

In this embodiment, the transaction terminal 10A shown in FIG. 1 is configured to also function as an audit terminal.
This verification is performed using a ``k-of-n'' ``multi-signature scheme'' algorithm (multiple private keys are required, of which a fixed number of private keys are required).
In the "main chain", consensus among "miners" is formed using "Pow (Proof of Work)", but in the "side chain", by replacing it with "multi-signature", it is possible to maintain the security of the main chain and save time. The configuration is such that delays are unlikely to occur.

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

This platform is configured so that transactions cannot be performed without approval from the verification server. The verification server verifies the ID of the transactor, etc., but also performs the function of checking the details of the transaction from the viewpoint of laws and regulations, and not giving approval to transactions that violate laws and regulations.

Further, the transaction terminal 10A, etc., the verification server 100, the transaction settlement server 200, etc. in FIG. and are connected via a bus.

FIG. 3 is a schematic block diagram showing the main configuration of the "transaction settlement server 200" in FIG. 1.
As shown in FIG. 3, the transaction and settlement server 200 includes a transaction and settlement server-side control unit 201, and the control unit 201 includes a “transaction and settlement server-side communication device 202” that communicates with other devices, etc., and a “transaction and settlement server-side communication device 202” that communicates with other devices, It controls the "transaction/settlement server side display 203" for display and the "transaction/settlement server side various information input device 204" for inputting various information.
The control unit 201 also includes the "transaction and settlement server side first various information storage section 210", "transaction and settlement server side second various information storage section 220", and "transaction and settlement server side second various information storage section 210" in FIG. information storage unit 230”.

4 to 6 respectively show the "transaction settlement server side first various information storage section 210", "transaction settlement server side second various information storage section 220", and "transaction settlement server side second various information storage section 210" in FIG. FIG. 2 is a schematic block diagram showing the main configuration of a "various information storage section 230".
The details of these will be described later.

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

8 and 9 are schematic block diagrams showing the main configurations of the "first various information storage section 110 on the verification server side" and the "second various information storage section 120 on the verification server side" in FIG. 7, respectively. .
The details of these will be described later.

FIG. 10 is a schematic diagram showing the main configurations of 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". do.
Note that in this embodiment, for convenience of explanation, four audit terminals will be described, but the audit terminals in the present invention are not limited to this, and an appropriate number of audit terminals is required.
Furthermore, the greater the number of audit terminals, the higher the security, and the smaller the number, the faster the processing speed.
For this reason, the number of monitoring terminals is determined appropriately to balance the two.
The transaction terminals 10A, 10B, and 10C function as "transaction terminals," but 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. 1.
As shown in FIG. 10, the transaction terminal 10C has a transaction terminal side control section 11C, which includes a "transaction terminal side communication device 12C" that communicates with other devices, etc., and a "transaction terminal side communication device 12C" that displays various information. The transaction terminal side display 13C'' and the transaction terminal side various information input device 14C for inputting various information are controlled.
The control unit 11C also controls the "C transaction terminal side key information storage section 15C" and the "transaction terminal side various information storage section 16C" in FIG.
Of these, the "C transaction terminal side key information storage section 15C" will be described later.

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

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

12 to 19 are schematic flowcharts showing main operation examples of the system 1.
In this embodiment, "transaction terminal 10A", "transaction terminal B", and "transaction terminal C" in FIG. 10G" functions as an "audit terminal".

12 and 13 show that when each of the transaction terminals 10A to 10C transmits information on a desire to trade "Bitcoin", the "transaction settlement server 200" in FIG. 1 performs "matching processing" and "netting processing". It is a schematic flowchart which shows the process of performing etc.

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

In addition, transaction terminals 10A, etc. that wish to use this system 1 may deposit “collateral money” etc. to the “transaction settlement office” that manages the “transaction settlement server 200” in case a shortage of funds occurs during transactions. Take measures such as leaving it in your possession.
This allows the transaction terminal 10A and the like to use the present system 1 including the "transaction settlement server 200."

The process will be described below in accordance with the flowcharts of FIGS. 12 and 13.
First, the process proceeds 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, proceed to ST2. In ST2, the "transaction settlement server 200" stores condition information of each transaction terminal 10A, etc. in the "condition information storage section 211" of FIG. 4 of the "transaction settlement server 200."
For example, 1) the condition information of transaction terminal A is that it wants to purchase "1 Bitcoin" for "1 million yen" and that it wants to sell "1 Bitcoin" for "1.1 million yen".
In addition, 2) The condition information of "Transaction Terminal 10B" is that you want to purchase "2 Bitcoin" for "1.8 million yen" and that you want to sell "1 Bitcoin" for "1 million yen". , 3) The condition information of "transaction terminal 10C" is that "1 Bitcoin" was purchased for "1.1 million yen" and that "2 Bitcoin" is to be sold 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, and the "Bitcoin" that is desired to be executed within a predetermined time (for example, from 9 a.m. to 11 a.m.) is operated. A combination with the transaction terminal 10A or the like that matches the exchange transaction conditions with a legal currency such as "yen" is searched for and stored in the "matching result storage section 213" in FIG.

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 sells "1 Bitcoin" to trading terminal B for "1 million yen." , purchases ``2 Bitcoins'' for ``1.8 million yen'' from transaction terminal 10C.
In this way, "contract between transaction terminal 10A and transaction terminal B", "contract between transaction terminal 10B and transaction terminal 10C", and "contract between transaction terminal 10C and transaction terminal 10A" are selected as candidates, and "matching result storage section 213”.

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

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

In this case, when Exchange A executes the contract with Exchange C first, if it does not have 1.1 million yen but only 100,000 yen, it borrows 1 million yen as a short-term loan. After acquiring "1 million yen" in the contract with Exchange B, he will have to repay "1 million yen".
This poses a problem in that prompt transactions are difficult.

Therefore, in this embodiment, instead of executing each contract individually, the final content of acquisition and provision of "Bitcoin" and "yen" of each exchange is calculated and each transaction in the middle is omitted. A process called "netting" is executed as follows.

In ST5, the "netting contract processing unit 214" in FIG. 4 operates, and instead of executing the three contracts of the transaction terminals 10A, 10B and 10C in the "matching result storage unit 213", it executes the contracts with the transaction terminals 10A, 10B and 10C. By making a contract with each "transaction settlement server 200", each transaction terminal 10A, 10B, and 10C acquires and/or obtains "Pitcoin" and/or "yen" that are ultimately acquired or provided by the transaction terminals 10A, 10B, and 10C. Generate contract combination information that can be provided.

Specifically, in the above example, between the transaction terminals 10A, 10B, and 10C, ultimately 1) transaction terminal 10C provides "1 Bitcoin" to 10B, and 2) transaction terminal 10B completes the transaction. Terminal 10A will be provided with 1 million yen, and transaction terminal C will be provided with 700,000 yen.
Then, the result information of this "netting contract processing" is stored in the "netting contract processing result information storage unit 221" in FIG. 5.

However, according to the contract contents in the "Netting contract processing result information storage unit 221" in FIG. A problem arises.
Therefore, in this embodiment, the "central counterparty contract processing unit (program) 234" shown in FIG. The parties to the contract in the "Netting Contract Processing Result Information" are changed to a contract with the "Transaction Settlement Server 200" and stored in the "Central Counterparty Contract Processing Result Information Storage Unit 222" in FIG. 5.

Specifically, in the above example, 1) a contract in which the transaction settlement server 200 provides "100,000 yen" to the transaction terminal 10A, and 2) a contract in which the transaction settlement server 200 provides "1 Bitcoin" to the transaction terminal 10B. Contract, 3) The transaction settlement server 200 provides "1 Bitcoin" to the transaction terminal 10C, and the transaction terminal 10C provides the transaction settlement server 200 with "700,000 yen."

In this way, by incorporating the "transaction settlement server 200" into the contract entity, even if one of the contract parties is unable to fulfill the contract contents, the entire contract will not be in default, but the "transaction settlement server 200" in which the default occurred Only the contract with the "transaction settlement server 200" will be in default, and the contracts with the other "transaction settlement servers 200" will be fulfilled.
In addition, since these contracts in the "central counterparty contract processing result information storage unit 222" are processed as netting contracts, each party can pay the full amount of legal currency (yen) necessary for the performance of the contract before netting. Since there is no need to prepare the information at the time of execution, transactions can be carried out quickly.

In this embodiment, an example has been described in which the "netting contract processing unit 214" in FIG. 4 operates and the "central counterparty contract processing unit 234" in FIG. 6 operates, but without separating these, It doesn't matter if you process it all at once.
Furthermore, when the transaction is urgent, the processes shown in FIGS. 1 to 7 may be omitted.

Next, proceed to ST7. In ST7, the "transaction settlement server 200" confirms the payment ability and collateral money of the transaction terminal 10A, etc., which is the other party to the contract, and confirms the payment ability and security deposit of the transaction terminal 10A, etc., which is the other party to the contract, regarding the "central counterparty contract". Obtain “consent”.

With the above steps, the specific transaction (contract) to be executed is determined using the main chain and side chain in Figure 1.
Further, as described above, by establishing a contract (transaction) between the "transaction settlement server 200" and each transaction terminal 10A, 10BC, and 10C, a quick and safe transaction can be guaranteed.

These transaction details include, for example, the virtual currency (Bitcoin) being traded, the type of legal currency (Yen), the transaction price equivalent to the price of the virtual currency (Bitcoin) against the legal currency (Yen), and the currency. In addition to the transaction amount (exchange amount), information such as the date and time of the transaction and the transaction terminal ID of the transaction is included.

14 to 19 show the steps of executing each contract (transaction) between the finalized "transaction settlement server 200" and each "transaction terminal 10A" etc. using the platform of this system 1 in the above-mentioned steps. It is a schematic flow chart showing.

When the transaction contents are agreed upon, the transaction settlement server 200 and the transaction terminals 10A, 10B, and 10C perform processing according to the agreed transaction contents.
Specifically, in the above example, 1) a contract in which the transaction settlement server 200 provides "100,000 yen" to the transaction terminal 10A, and 2) a contract in which the transaction settlement server 200 provides "1 Bitcoin" to the transaction terminal 10B. Contract, 3) The transaction settlement server 200 provides "1 Bitcoin" to the transaction terminal 10C, and the transaction terminal 10C enters into a contract to provide the transaction settlement server 200 with "700,000 yen."

14 to 19, first, the "transaction settlement server 200" provides "1 Bitcoin" to the "transaction terminal 10C", and the "transaction terminal 10C" The process of contracting to provide "700,000 yen" to "payment server 200" will be explained.

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

Specifically, the "lock multisig address generation unit (program) 223" shown in FIG. Using the public key of ``audit terminal side key information storage section 15D'' and the public key of ``transaction settlement server side key information storage section 224'' (FIG. 5) of transaction settlement server 200, ``1 bit A ``lock multisig address'' for locking the ``coin'' is generated and stored in the ``lock multisig address storage section''.

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

Next, the process advances to ST12. In ST12, the "locking transaction generation unit (program) 231" (FIG. 6) of the transaction settlement server 200 operates and writes "1" to the "locking multisig address" of the "locking multisig address storage section 225" in FIG. A "locking transaction" in which "Bitcoin" is deposited is generated and stored in the "locking transaction storage unit 232" in FIG.

Next, the process advances 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 locks the 1 Bitcoin in the main chain.

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

Next, the process advances to ST14. In ST14, the "Bitcoin token request unit (program) 233" (FIG. 6) of the transaction settlement server 200 operates, and the transaction settlement server 200 stores the "locking transaction" information in the "locking transaction storage section 232" of FIG. , information such as the public key of the transaction settlement server 200 used when generating the "lock multisig address" in the "lock multisig address storage unit 225" in FIG. 5 is sent to the "audit terminal 10D etc.", and the transaction settlement server 200 sidechain address, requesting the transmission of a sidechain token, such as a "Bitcoin token", to be traded.

Next, the process advances to ST15. In ST15, the audit terminal 10D etc. stores the private key of the audit terminal 10D etc. in the "audit terminal side key information storage section 15D" in FIG. 11, and the public key etc. in the "transaction settlement server side key information storage section 224" in FIG. This information is used to verify whether or not the "Bitcoin" is locked in the main chain.

Next, the process advances to ST16. In ST16, the "Strong Federations" algorithm used in the side chain determines whether an appropriate number of audit terminals 10D, etc. among the multiple audit terminals 10D, etc. have succeeded in verification.

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

Next, the process advances to ST18. In ST18, the "transaction settlement server 200" sends the information of the "UTXO" that holds the "1 Bitcoin token" acquired above to the "verification server 100", and the "transaction database 111" in FIG. Register it in association with "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 be able to process the transaction at the time of transaction verification. You can disapprove and void the transaction.

Next, the process advances to ST19. In ST19, the "transaction terminal 10C" remits legal currency (700,000 yen) to the verifier managing the verification server 100 or the yen token issuer by means such as financial transfer, and the transaction history is managed on the side chain. For example, the verification server is requested to issue a "700,000 yen token" which is a "side chain token".

In this embodiment, the "verification server 100" was described as one that both verifies transactions and issues yen tokens, but in the present invention, the issuer of yen tokens is the "verification server 200". It doesn't matter if they are different.

Next, the process advances to ST20. In ST20, the "verification server side multisig address generation unit (program) 112" in FIG. 8 operates, and the public key of the transaction terminal 10C in the "C transaction terminal side key information storage unit 15D" in FIG. Using the public key of the verification server in the "verification server side key information storage unit 113", a multisig address is generated with the input of electronic signatures of the transaction terminal 10C and the verification server 200 as a cancellation condition, and the "verification server side" shown in FIG. multisig address storage unit 114”.

Next, the process advances to ST21. In ST21, the "verification server side transaction generation unit (program) 115" shown in FIG. 8 operates and deposits "700,000 yen token" to the multisig address of the "verification server side multisig address storage section 114" shown in FIG. Generate transactions and broadcast them to the sidechain network.

As a result, the "700,000 yen token" cannot be used on this platform unless it is approved (signed) by the "verification server 100".

Next, the process advances to ST22. In ST22, the "verification server 100" registers the "UTXO" information indicating that the "transaction terminal 10C" holds the "700,000 yen token" in the "transaction database 121" of FIG. 9.

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

Therefore, in this embodiment, in preparation for such a situation, the transaction settlement server and the transaction terminal C perform a "Delivery Versus Payment Swap" (mutual conditions for Bitcoin tokens and Yen tokens). (hereinafter referred to as "DVP Swap").

"DVP Swap" is a method that makes it possible to exchange virtual currencies such as Bitcoin and "Yen Token" through bilateral transactions without the need for a third party (intermediary), while eliminating the need for a mutual trust relationship.
Therefore, even if the parties involved in the terminals conducting transactions on the side chain do not have a trusting relationship with each other, they can safely conduct bilateral transactions without involving a third party, such as an intermediary.

The "DVP swap" will be explained below. In this embodiment, the "transaction settlement server 200" generates a "multisig address" using the respective public keys of the "transaction settlement server 200" and the "transaction terminal 10C". Then, a transaction is generated in which "1 Bitcoin token" and "700,000 yen token" are deposited using the multisig address.

Then, the "transaction settlement server 200" and the "transaction terminal 10C" each input (add) their respective electronic signatures to the transaction and broadcast it.
Specifically, it is as follows.

In ST24, the "transaction settlement server 100" stores the transaction settlement server 200 of the "transaction settlement server side key information storage section 224" in FIG. 5 and the "C transaction terminal side key information storage section 13C" of FIG. 10, and the transaction terminal 10C. Using the public key, inputting the electronic signature of the transaction settlement server 200 and the transaction terminal 10C is a cancellation condition, and the output of "1 Bitcoin token" with the output destination address of the "transaction terminal 10C" is stored as a transaction. .

Next, the process advances to ST25. In ST25, the "transaction settlement server 200" includes the "transaction settlement server side key information storage section 224" in FIG. 5, the "C transaction terminal side key information storage section 13C" in FIG. 10, and the "verification server side key information storage section 13C" in FIG. transaction settlement server 200, transaction terminal 10C, and verification server 100'' of ``Transaction Settlement Server 200'', transaction terminal 10C, and verification server 100'', with input of electronic signatures of the three parties as a release condition, and output destination to the address of ``Transaction Settlement Server 200'' or The output of the "700,000 yen token" as the "multisig address" of the transaction settlement server 200 and the verification server 100 is stored in the transaction.

When generating the above-mentioned transaction, the "transaction settlement server 200" receives from a third party the type and quantity of "1 Bitcoin token" and "700,000 yen token" exchanged in the transaction, that is, the transaction details. To ensure confidentiality, encrypted transactions are generated so that only those involved can view them.

Specifically, the ``transaction settlement server 200'' uses techniques called ``confidential transactions'' and ``confidential assets,'' which are anonymization processes, to determine the details of transactions. Generate an encrypted transaction.

Therefore, the transaction details on the side chain will not be leaked and the security of the transaction can be ensured.

The "confidential transaction" that encrypts the transaction amount will be explained below.
Confidential transactions are a method of concealing the transaction volume of "Bitcoin tokens" and "Yen tokens" published on the blockchain, and are a method of encrypting 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 by the following equation (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. By doing so, commitment C(a) is generated.
In a confidential transaction, the quantity of each input and output stored in the transaction is expressed as 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 an additive property, and the sum of the plurality of commitments C(a) is equal to the commitment C(a) of the sum of committed transaction amounts (a).
For example, the relationship C(1)+C(1)=C(2) holds true.
Therefore, the transaction amount (a) can be verified by subtracting the sum of the commitments C(a) of each output from the sum of the commitments C(a) of each input and checking whether it becomes 0.
As a result, a party who knows the private key (x) can know the transaction amount (a), while a third party cannot know the transaction amount (a).

In addition, in the confidential transaction, a range proof such as a ring signature is further used to prove that the transaction amount (a) to be committed is 0 or more.

Next, we will explain ``confidential assets,'' which conceal the type (asset type) of ``tokens'' and the like to be traded in addition to the transaction volume.
Confidential assets are a method that applies confidential transactions, and in addition to the transaction volume, it is a method that conceals the types (asset types) of "Bitcoin tokens" and "Yen tokens" being traded.

Confidential Asset calculates commitment using different base points for each type such as "Bitcoin token".
For example, if we assume two types of "Bitcoin token" and "Yen token" with transaction volume (a) and (b), commitment C(a) of "Bitcoin token" etc. with transaction volume (a) is expressed as In addition to calculating by (1), the commitment C(b) of "Bitcoin token" etc. of transaction amount (b) is calculated by the following equation (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, commitments C(a), C( b) Calculate.

Then, write commitments C(a) and C(b) as the quantities of each input and output, and set base points H and I according to the type of "Bitcoin token" etc. for each commitment C(a), Label C(b).

Thereby, the transaction amounts (a) and (b) are made confidential.
However, if base point H is set as a fixed value, the type of "Bitcoin token" etc. will be known, so in confidential assets, base point H is replaced with A as shown in the following equation (3).
A=H+rG...(3)
r is a secret field value known only to the parties involved. When base point H is replaced with A, equation (1) is expressed by the following equation (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 secret key x is replaced by (x, r).

While a party who knows the random number r can know the type of "Bitcoin token" etc. from base point A, a third party cannot.
In addition, in the confidential asset, base point A is further configured with a ring signature in order to prevent currency creation.

In addition, although we explained the so-called "DVP swap" on a single chain above, even if multiple transactions are generated and currency exchange is performed, such as "DVP swap" or "atomic swap" on a cross-chain. good.
That is, 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" are able to exchange "1 Bitcoin token" and "700,000 yen token" by eliminating the need for a trust relationship through the "DVP swap" as described above. It is possible to generate transactions with encrypted transaction details.

Next, the process proceeds to ST26 in FIG. 17. In ST26, the "transaction settlement server 200" uses the private key of the "transaction settlement server 200" in the "transaction settlement server side key information storage unit 224" in FIG. Enter and send to "transaction terminal 10C".

Next, the process advances to ST27. In ST27, the "transaction terminal 10C" inputs an electronic signature to the received transaction using the private key of the "transaction terminal 10C" in the "C transaction terminal side key information storage section 15C".

At this time, if the "transaction terminal 10C" commits a fraudulent act and changes the output destination of the "700,000 yen token" that should be output to the "transaction settlement server 200", the electronic signature input by the "transaction settlement server 200" validation fails and the transaction is determined to be invalid.
In this manner, through the above-described steps, transactions can be carried out with peace of mind without involving a third party and without having a relationship of trust with the other party.

Next, the process advances 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, and also make sure that the "verification server 100" can verify the transaction. In addition, the "transaction settlement server 200" and the "transaction terminal 10C" also transmit the private key used to conceal the transaction.

Next, the process advances to ST29. In ST29, the "decryption unit (program) 122" shown in FIG. ), decrypts information representing transaction details such as type.

Next, the "approval unit (program) 123" in FIG. 9 operates and verifies whether the decrypted transaction content is appropriate or not. If it is appropriate, it approves the transaction, and if it is not, it approves the transaction. do not.

Specifically, for example, the "approval unit (program) 123" of the "verification server 100" determines the "transaction settlement" based on the quantity of "Bitcoin tokens" and the quantity of "yen tokens" exchanged in the above transaction. The transaction price (exchange rate) of the currency exchange transaction performed between "server 200" and "transaction terminal 10C" is calculated.

"Bitcoin token" corresponds to virtual currency and "yen token" corresponds to legal currency, so the calculated price corresponds to the buying and selling price of virtual currency against legal currency.
Furthermore, the "verification server 200" acquires current market price information of virtual currency relative to legal currency from a predetermined external API (Application Programmable Interface).

Then, the "verification server 100" determines whether the difference between the transaction price calculated above and the transaction price (distribution route) of a commonly distributed virtual currency is equal to or greater than a predetermined threshold.
If it is determined that the difference between the two is greater than or equal to the 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 and regulations and self-regulations, are generally in place to control inappropriate transactions.
On the other hand, this system 1 is a decentralized transaction system using blockchain, and there is no centralized administrator to manage transactions.
However, if transactions are completely left to the user, there is a risk that inappropriate transactions will be conducted in view of general financial transaction regulations.

For example, there is a risk that money laundering could occur if parties collude to exchange a small amount of Japanese yen for a large amount of virtual currency (Bitcoin).
Therefore, in this embodiment, the "verification server 100" verifies the transaction details to prevent inappropriate transactions.

For example, as described above, the verification server verifies the exchange rate of the currency exchanged by the transaction and determines whether the transaction is inappropriate.
In addition, the "verification server 100" verifies information related to the transaction, such as the ID and UTXO of each transaction terminal, and determines whether the transaction is inappropriate.

Note that in this embodiment, verification is performed based on the currency exchange rate, party ID, UTXO, etc., but the present invention is not limited to this, and for example, currency transactions Verification may be performed based on quantity, etc.

That is, the "verification server 100" only needs to be able to determine whether or not the transaction is a valid transaction with matching transaction details, and the conditions for this determination are not particularly limited.

Next, in ST31 of FIG. 18, the "approval unit (program) 123" of the "verification server 100" determines that the transaction is a proper transaction, and if the verification is successful, the "verification server 100" Using the private key of the "verification server 100" in the "verification server side key information storage unit 113", an electronic signature is added to the transaction and broadcast to the side chain network.

Next, the process advances to ST32. In ST32, the transaction broadcast from the "verification server 100" is verified by the "audit terminal 10D, etc.".
The "audit terminal 10D" etc. operate the "audit terminal verification unit (program) 17D" shown in FIG. If the transaction is verified by the algorithm of "Federation" and the transaction is agreed to be added to the side chain in a block, each audit terminal 10D etc. inputs an electronic signature of "Auditing terminal 10D" etc. to the block.

The Audit Terminal 10D and the like verify transactions and form consensus using the ``Strong Federation'' algorithm used in the side chain, rather than using ``Pow'', which relies on the computing power of the terminal.
In the strong federation, processing is performed in a round-robin manner, and one of the audit terminals 10D or the like is selected as a master in order from among a plurality of audit terminals and performs verification.
The master audit terminal 10D or the like verifies the script of each transaction broadcast on the side chain network and generates block candidates to be added to the side chain.
The master "inspection terminal 10D" or the like transmits the generated block candidates to other "inspection terminals."

Next, the process advances 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 block is added to the side chain between the ``transaction settlement server 200'' and the ``transaction terminal 10C.'' transactions are successfully incorporated into the sidechain.

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

Next, the process advances 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 locks "1 Bitcoin" on the main chain.

Next, in ST35, the "transaction 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 Embed in.

Next, the process advances to ST36. In ST36, each "audit terminal 10D" etc. that received the "peg-out" request is connected to the "UTXO" of the "verification server 100" on the side chain where the "transaction terminal 10C" holds the "Bitcoin token". Verify.

Next, the process advances to ST37. In ST37, if a predetermined number of audit terminals 10D etc. succeed in the verification and approve the peg-out, each "audit terminal 10D" etc. inputs an electronic signature to the locking transaction and unlocks the "Bitcoin".

By unlocking "1 Bitcoin", the "transaction terminal 10C" can send "Bitcoin" to its own wallet address.
Note that the "Bitcoin" that will be 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. That's fine.

In addition, the locking transaction in which the "transaction settlement server 200" locks "Bitcoin" at the time of peg-in and the locking transaction that the "transaction terminal 10C", which is the counterparty of the transaction, unlocks at the time of peg-out do not necessarily match. It may also be a locking transaction generated by another "transaction terminal 10C" in another transaction.

Next, the process advances to ST38. In ST38, the "transaction settlement server 200" transmits to the transmission server a request for redemption of legal currency (700,000 yen) based on the "yen token" acquired through the above transaction.

Next, the process advances to ST39. In ST39, the "verification server 100" that received the redemption request checks whether the "transaction settlement server 200" owns the "700,000 yen token" and then checks the "700,000 yen token" held by the "transaction settlement server 200". The legal currency (700,000 yen) equivalent to "Yen Token" is transferred to the account of the transaction settlement server by means such as financial transfer.

In this way, in this embodiment, the "transaction terminal 10C" performs peg-out to move "1 Bitcoin token" from the side chain to the main chain, and acquires "1 Bitcoin". The "transaction settlement server 200" requests redemption of legal currency (700,000 yen) based on the "yen token" and acquires the legal currency (700,000 yen) by means such as financial transfer.
As a result, the exchange between "1 Bitcoin" of the "transaction settlement server 200" and the legal currency (700,000 yen) of the "transaction terminal 10C" is completed.

Furthermore, in this embodiment, the side chain is configured to ensure the safety of transactions because transactions are executed using "tokens" managed by the audit terminal 10D or the like and the verification server 100.

Subsequently, 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 the present system 1.
In this case, the above-mentioned "transaction terminal 10C" provides "700,000 yen" to the "transaction settlement server 200", and the same steps are executed.

Further, another transaction, a contract for providing "1 Bitcoin" to "transaction terminal 10C", is also executed using this system 1.
In that case, the above-mentioned "transaction terminal 10C" provides "1 Bitcoin" to the "transaction settlement server 200", and the same steps are executed.

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

Note that the "verification server 100" may be configured to not only verify transactions but also output a record of transactions performed by each transaction, that is, a report of currency exchange transactions performed on this platform.
For general financial transactions, transaction records must be submitted in response to requests from financial authorities.
Correspondingly, the "verification server 100" decrypts the encrypted transaction contents of each transaction using the anonymizing private key, and outputs a transaction record.
As a result, transaction records on this platform are kept confidential from general users, while transaction records can be viewed as needed.

In this embodiment, the exchange between virtual currency such as Bitcoin and yen, which is a legal currency, has been explained as an example. It is also possible to use it as the legal tender of other countries.

In addition, in this embodiment, the exchange between virtual currency and legal currency has been explained as an example, but virtual currency can be used as an intermediary currency to exchange, for example, yen and US dollar, yen and Vietnamese dong, etc. It is also possible to have a configuration in which
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, Japanese yen, US dollar, Vietnamese dong, Malaysian It becomes possible to mutually exchange ringgit through virtual currencies such as Bitcoin.

In the embodiment described above, the case where it is realized as an apparatus has been described as an example, but the present invention is not limited to this, and the present invention can be implemented as a magnetic disk (floppy disk (registered trademark)) as a program that can be executed by a computer. ) disk, hard disk, etc.), optical disk (CD-ROM, DVD, etc.), magneto-optical disk (MO), semiconductor memory, etc., and may be stored and distributed in storage media.

Further, the storage medium may be any storage medium that can store a program and is readable by a computer. The storage format of the storage medium is not particularly limited.

In addition, the OS (operating system), MW (middleware) such as database management software, network software, etc. that are running on the computer based on the instructions of the program installed on the computer from the storage medium realize this embodiment. A part of each process may be executed.

Furthermore, the storage medium in the present invention is not limited to a medium independent of a computer, but also includes a storage medium in which a program transmitted via a LAN, the Internet, etc. is downloaded and stored or temporarily stored.

Further, the computer in the present invention may execute each process in the present embodiment based on a program stored in a storage medium, and may be a device consisting of a single personal computer or the like, or a plurality of devices connected to a network. It may also be a system that is

Furthermore, the computer in the present invention is not limited to a personal computer, but also includes arithmetic processing units, microcomputers, etc. included in information processing equipment, and is a general term for devices and devices that can realize the functions of the present invention through programs. ing.

The embodiments of the present invention have been described above. However, the present invention is not limited to the above embodiments, and various changes can be made without departing from the scope of the claims. A part of the configuration of the above embodiment may be omitted or may be arbitrarily combined in a manner different from that described above.

DESCRIPTION OF SYMBOLS 1... Bitcoin transaction system, 10A to 10G... Transaction terminal, 11C... Transaction terminal side control unit, 11D... Audit terminal side control unit, 12C... Transaction terminal side communication device, 12D. ... Audit terminal side communication device, 13C... Transaction terminal side display, 13D... Audit terminal side display, 14C... Transaction terminal side various information input devices, 14D... Audit terminal side various information input devices, 15C...C transaction terminal side key information storage unit, 15D...Audit terminal side key information storage unit, 16C...Transaction terminal side various information storage unit, 17D...Audit terminal verification unit (program), 100 ...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 section, 115... Verification server side transaction generation section (program), 120... Verification server side second various information storage section, 122... Decoding section (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 section, 211... Condition information storage section, 212... Matching processing section (program), 213... Matching result storage section, 214... Netting contract processing section, 220... Transaction settlement server side second various information storage section, 221... Netting contract processing result information storage section, 222... Central counterparty contract processing result information storage unit, 223...Lock multisig address generation unit (program), 224...Transaction settlement server side key information storage unit, 225...Lock 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 department (program)

Claims (9)

A blockchain where transaction records are kept by multiple nodes and virtual currency is managed in a network built by these nodes.
A transaction system comprising a side chain that is a side chain of the blockchain,
The side chain is configured to be able to manage the virtual currency managed by the blockchain, and at least allow transactions including the exchange of the virtual currency with legal currency, as well as transactions executed on the side chain. The transaction result information is reflected on the main chain,
The transaction system is characterized in that transaction information in the side chain is monitored by a plurality of monitoring units different from the main chain. The transaction information between the terminals that are the parties in the side chain has a structure in which mutual conditions are set on the transaction objects to be exchanged, so that if one terminal of the parties does not execute the transaction contents, the transaction contents of the other terminal will not be executed. 2. The transaction system according to claim 1, further comprising: 3. The transaction system according to claim 1, wherein the transaction information in the side chain is subjected to concealment processing to conceal its contents. The virtual currency and the legal currency are each converted and traded on the side chain into side chain tokens that can be used on the side chain,
4. The transaction system according to claim 1, wherein the side chain token is configured to be issued by the monitoring unit. The transaction system according to any one of claims 1 to 4, wherein the monitoring unit determines the validity of the exchange value of the transaction object of the transaction information in the side chain. Any one of claims 1 to 5, wherein the transaction information is recognized as the transaction information in the side chain only after being verified repeatedly by a plurality of the audit departments. The trading system described in Section. When a terminal participates in a transaction in the side chain multiple times as a party, it performs a netting process on the transaction details of the transaction information, and based on the result information of the netting process, it interacts with each terminal that is a party. A claim characterized in that the transaction information only with a third-party organization is generated for each terminal, and a transaction is executed on the side chain based on the transaction information with the third-party organization. The transaction system according to any one of claims 1 to 6. A blockchain where transaction records are kept by multiple nodes and virtual currency is managed in a network built by these nodes.
A side chain that is a side chain of the blockchain, the method for controlling a transaction system comprising:
The side chain is configured to be able to manage the virtual currency managed by the blockchain, and at least allow transactions including the exchange of the virtual currency with legal currency, as well as transactions executed on the side chain. The transaction result information is reflected on the main chain,
A method for controlling a transaction system, characterized in that the transaction information in the side chain is monitored by a plurality of monitoring units different from the main chain. A transaction system that has a blockchain in which transaction records are maintained by multiple nodes and virtual currency is managed in a network built by these nodes, and a side chain that is a side chain of the blockchain,
The side chain is configured to be able to manage the virtual currency managed by the blockchain, and at least allow transactions including the exchange of the virtual currency with legal currency, as well as transactions executed on the side chain. Transaction result information is reflected in the main chain,
A control program for a transaction system for realizing a function in which the transaction information in the side chain is monitored by a plurality of monitoring units different from the main chain.

Images