JP6956062B2 - Transaction method, program, verification device and generation method - Google Patents

Description

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

Various methods have been proposed for exchanging virtual currencies realized by using distributed ledger technology represented by blockchain with real financial assets such as legal tender. For example, Patent Document 1 discloses a virtual currency management device that exchanges a virtual currency for a legal tender at a fixed price in order to stabilize the price of the virtual currency with respect to the legal currency.

Japanese Patent No. 6352463

However, the invention according to Patent Document 1 merely provides an exchange on which virtual currency can be bought and sold at a fixed price, and provides an appropriate trading place for exchanging virtual currency for financial assets. Is hard to say.

One aspect is to provide a transaction method or the like that can appropriately exchange virtual currency for financial assets.

In one aspect, the transaction method is a virtual currency whose transaction history is managed in a distributed ledger on the computer of the first user, and the virtual currency held by the first user is converted into a first token. The second user's computer is made to output a request for issuing a second token based on the financial assets held by the second user, and the first or second user's computer is made to output the first and second tokens. A transaction for exchanging the first and second tokens between the two users is generated and output, and the computer of the second user converts the first token acquired by the transaction into the virtual currency. It is characterized in that the computer of the first user is made to output a request for redemption of the financial asset based on the second token.

On one side, cryptocurrencies can be properly exchanged for financial assets.

It is a schematic diagram which shows the configuration example of a trading system. It is a block diagram which shows the configuration example of a terminal and a verification server. It is explanatory drawing which shows an example of the record layout of a user DB and a transaction DB. It is explanatory drawing which shows the outline of the currency exchange transaction. It is explanatory drawing which shows the process of a currency exchange transaction. It is explanatory drawing which shows the process of a currency exchange transaction. It is explanatory drawing which shows the process of a currency exchange transaction. It is explanatory drawing which shows the process of a currency exchange transaction. It is a flowchart which shows an example of the processing procedure which a transaction system executes.

Hereinafter, the present invention will be described in detail with reference to the drawings showing the embodiments thereof.
(Embodiment)
FIG. 1 is a schematic diagram showing a configuration example of a trading system. In the present embodiment, a transaction system for exchanging a virtual currency whose transaction history is managed in a blockchain (distributed ledger) with a legal tender on a side chain called a side chain of the block chain will be described. The trading system includes information processing devices 1, 1, 1, ... And a verification device 2. Each device is communicated and connected via a communication network N such as the Internet.

The information processing device 1 is an information processing device operated by a user who exchanges virtual currency and legal tender using this system, and is, for example, a personal computer, a server device, or the like. In the present embodiment, it is assumed that the information processing device 1 is a personal computer, and in the following description, it is read as a terminal 1 for the sake of brevity.

The user who uses this system is not particularly limited, but in the present embodiment, as an example, it is assumed that the exchange company operating the virtual currency exchange is the user. In the following description, for convenience, each user is referred to as exchanges A, B, C ..., And the terminal 1 of each exchange A, B, C ... is referred to as terminals 1a, 1b, 1c .... The terminals 1a, 1b, 1c ... Are connected to a server device (not shown) that functions as exchanges A, B, C ..., And are operated by operators of each exchange A, B, C ...

Currently, the transaction price and distribution volume of virtual currencies vary from exchange to exchange, and there is an aspect that they are not balanced. One reason for this is that there is no place for transactions and settlements between exchanges, that is, there is no professional market or common settlement infrastructure equivalent to financial transactions. In the case of financial assets such as legal tender, there is a common transaction base and a common settlement board for qualified institutional investors to conduct transactions. On the other hand, virtual currencies do not currently have such a specific common transaction base and common settlement base, and professional participants such as exchanges only operate virtual currency exchange businesses and exchange directly with each other. Therefore, this system provides a common platform necessary for professional participants such as exchanges to conduct transactions.

The verification device 2 is a device of the verifier X that verifies the appropriateness of the currency exchange transaction performed in this system, and is, for example, a server device, a personal computer, or the like. In the present embodiment, the verification device 2 is assumed to be a server device, and will be read as the verification server 2 in the following description. The verifier X checks information related to transactions such as the rate of the currency to be traded, the ID of the trader, and UTXO (Unspent Transaction Output), mainly from the viewpoint of laws and regulations, and gives approval of the transaction. The processing performed by the verification server 2 will be described in detail later.

Blockchain is a type of distributed ledger that manages the transaction history of virtual currencies. The blockchain network is formed by an unspecified number of nodes called miners, and each node verifies transactions, forms an agreement on the verification results, and updates the transaction history on the blockchain. In the present embodiment, Bitcoin (registered trademark) will be described as an example of the virtual currency. Of course, the virtual currency is not limited to Bitcoin, and may be altcoin such as Ethereum (registered trademark).

A side chain is a concept that is a side chain of a blockchain, and is a second blockchain (second distributed ledger) capable of transferring currency to and from the main blockchain. As will be described later, two-way pegs are possible between the main blockchain and the sidechain, and the currency (bitcoin) managed on the main blockchain and the side You can exchange currencies managed on the chain with each other. In the following description, for convenience, the main blockchain is referred to as the "main chain" to distinguish it from the side chain.

The currency exchange transaction related to this system may be performed on the main chain, but in the present embodiment, the transaction is performed on the side chain. For example, in the case of Bitcoin blockchain, the time for a minor agreement to be formed by PoW (Proof of Work) is about 10 minutes per block, which is reflected in the blockchain after transactions between the parties. It takes time. In recent years, fees paid to miners have also risen due to scalability issues. On the other hand, since the side chain is a different network from the main chain, the consensus building method can be different. As a result, while maintaining the security of the blockchain by managing the transaction history in a decentralized manner, it is possible to achieve quick transactions, control of fees, and the like.

As will be described in detail later, the terminal 1 of the exchange converts the virtual currency or legal tender it owns into tokens whose transaction history is managed in the side chain. Then, the terminal 1 conducts a transaction related to the exchange of virtual currency and legal tender by exchanging the converted token with another exchange.

FIG. 2 is a block diagram showing a configuration example of the terminal 1 and the verification server 2. The terminal 1 includes a control unit 11, a main storage unit 12, a communication unit 13, a display unit 14, an input unit 15, and an auxiliary storage unit 16.
The control unit 11 has one or more CPUs (Central Processing Units), MPUs (Micro-Processing Units), GPUs (Graphics Processing Units), and other arithmetic processing units, and stores the program P1 stored in the auxiliary storage unit 16. By reading and executing, various information processing, control processing, etc. are performed. The main storage unit 12 is a temporary storage area for SRAM (Static Random Access Memory), DRAM (Dynamic Random Access Memory), flash memory, etc., and temporarily stores data necessary for the control unit 11 to execute arithmetic processing. Remember. The communication unit 13 is a communication module for performing processing related to communication, and transmits / receives information to / from the outside. The display unit 14 is a display device such as a liquid crystal display, and displays an image given by the control unit 11. The input unit 15 is an input interface such as a mouse and a keyboard, and receives operation input.

The auxiliary storage unit 16 is a non-volatile storage area such as a hard disk, and stores the program P1 and other data necessary for the control unit 11 to execute the process. Further, the auxiliary storage unit 16 stores the main chain key information 161, the side chain key information 162, and the concealment key information 163. The main chain key information 161 stores key information (private key, public key) corresponding to the wallet address of the user (exchange) on the main chain. The sidechain key information 162 stores key information corresponding to the user's wallet address on the sidechain. Concealing key information 163, as described later, stores a Kagijo paper used for concealing the contents of currency exchange transactions described in the transactions on the sidechain.

The verification server 2 includes a control unit 21, a main storage unit 22, a communication unit 23, and an auxiliary storage unit 24.
The control unit 11 has one or a plurality of arithmetic processing units such as CPUs, MPUs, and GPUs, and reads and executes the program P2 stored in the auxiliary storage unit 24 to perform various information processing, control processing, and the like. conduct. The main storage unit 22 is a temporary storage area such as a RAM, and temporarily stores data necessary for the control unit 21 to execute arithmetic processing. The communication unit 23 is a communication module for performing processing related to communication, and transmits / receives information to / from the outside.

The auxiliary storage unit 24 is a non-volatile storage area such as a hard disk, and stores the program P2 and other data necessary for the control unit 21 to execute the process. Further, the auxiliary storage unit 24 stores the key information 241 and the user DB 242 and the transaction DB 243. Key information 241 stores a Kagijo report of the verifier X. The user DB 242 is a database that stores information of each user (exchange). The transaction DB 243 is a database that stores information on currency exchange transactions scheduled between each user.

The auxiliary storage unit 24 may be an external storage device connected to the verification server 2. Further, the verification server 2 may be a multi-computer composed of a plurality of computers, or may be a virtual machine virtually constructed by software.

Further, in the present embodiment, the verification server 2 is not limited to the above configuration, and may include, for example, a reading unit for reading information stored in a portable storage medium, an input unit for receiving operation input, a display unit for displaying an image, and the like. good.

FIG. 3 is an explanatory diagram showing an example of the record layout of the user DB 242 and the transaction DB 243. The user DB 242 includes a user ID column, a user name column, and an account information column. The user ID column stores a user ID for identifying each user. The user name column stores the name of the user (exchange) in association with the user ID. The account information column stores the account information of the user in this system in association with the user ID. The account information includes, for example, information on the user's financial account in addition to the data required for login.

The transaction DB 243 includes a transaction ID column, a transaction execution date column, a first user column, and a second user column. As will be described later, the transaction ID column stores the transaction ID for identifying the currency exchange transaction that the users have agreed to using the tool related to this system. The transaction execution date column stores the execution date of the currency exchange transaction in association with the transaction ID. The first user column stores information on the first user side that is one party to the currency exchange transaction and exchanges the virtual currency for the legal tender in association with the transaction ID. For example, the first user column stores the user ID of the first user, the asset type (type) of the token to be exchanged (first token), the transaction volume, the information of UTXO holding the token on the side chain, and the like. ing. The second user column stores information on the second user side that is the other party of the currency exchange transaction and exchanges legal tender for virtual currency in association with the transaction ID. For example, the second user column stores the user ID of the second user, the asset type of the token to be exchanged (second token), the transaction volume, and the like.

FIG. 4 is an explanatory diagram showing an outline of a currency exchange transaction. FIG. 4 conceptually illustrates how exchanges A and B carry out currency exchange transactions using a side chain. In the present embodiment, it is assumed that exchange A exchanges virtual currency and exchange B exchanges legal tender (for example, Japanese yen). First, each element constituting this system will be described with reference to FIG.

As described above, the main chain (shown as "Blockchain" in the upper left of FIG. 4) is a blockchain that manages the transaction history of virtual currencies in a decentralized manner, and is, for example, a network related to Bitcoin. On the other hand, the side chain is a blockchain that is a side chain of the main chain, and is a network that operates with an algorithm different from that of the main chain. The side chain is configured to allow bidirectional currency transfer to and from the main chain, as well as consensus building on transaction verification using a method different from that of the main chain.

The operation algorithm of the side chain is not particularly limited, but the side chain according to the present embodiment operates by an algorithm called Strong Federations. Strong Federations is a consensus building on the verification of transactions on the sidechain by multiple auditors (shown as "Federation members" in Figure 4) geographically and jurisdictionally distributed on the network. It is an algorithm that verifies bidirectional pegs with and from the main chain using a k-of-n multi-signature scheme. By replacing the consensus building performed by PoW in the main chain with multi-signature in the side chain, low latency is realized while maintaining the security of the main chain. In addition, by performing bidirectional pegs using the multi-signature technology that is also implemented in the main chain, bidirectional pegs are possible without the need for a soft fork (specification change) in the main chain.

The auditors of Strong Federations are divided into a member called Blocksigner and a member called Watchmen, and Blocksigner verifies the transaction and Watchmen checks the bidirectional pegs. However, since the distinction between the two is not an essential matter, the two are referred to herein as "auditors" without distinction.

In the present embodiment, on the above side chain, in addition to the auditor, the verifier X constructs a platform for verifying the currency exchange transaction. The platform is configured so that transactions cannot be conducted without the approval of verifier X. As will be described in detail later, the verifier X checks the transaction details mainly from the viewpoint of laws and regulations, and does not give approval to transactions that violate laws and regulations.

For example, the verifier X (verification server 2) provides a program P1 (first program, second program) in which each exchange functions as a tool for executing transaction matching, communication, transaction generation, etc., which will be described later. It is distributed so that it can be installed on each terminal 1a and 1b. As a result, a trading system including terminals 1a and 1b is generated. Exchanges A and B use the tool to search for a trading partner and negotiate the transaction details (transaction price, transaction volume, etc.). If the transaction details are agreed, exchanges A and B will exchange currencies using this platform.

Specifically, Exchange A performs Peg-in to move its own virtual currency (BTC) from the main chain to the side chain, and becomes the first token whose transaction history is managed in the side chain. Convert. In the following description, for convenience, the first token is referred to as "LBTC".

In addition, exchange B remits legal tender (Japanese yen) to verifier X by means such as financial transfer, and requests verifier X to issue a second token whose transaction history is managed in the side chain. .. In the following description, for convenience, the second token will be referred to as a "JPY token".

In the following description, it is assumed that the verifier X performs both transaction verification and token issuance, but the token issuer may be different from the verifier X.

Exchanges A and B generate transactions for exchanging acquired LBTC and JPY tokens and broadcast them to the sidechain network. In this case, the exchanges A and B send the transaction to the verifier X, and the verifier X verifies and broadcasts the transaction. The transaction is further validated by the sidechain auditor and, if approved, incorporated into the sidechain.

Subsequent processing is the reverse of the token acquisition process, with Exchange B performing a Peg-out to move the LBTC from the side chain to the main chain to acquire virtual currency, and Exchange A becoming a JPY token. Make a request for redemption of legal tender based on it, and acquire legal tender by means such as financial transfer. This completes the exchange of virtual currency for legal tender.
The details of the above-mentioned processing will be described below.

5 to 8 are explanatory views showing the process of currency exchange transactions. In FIGS. 5 to 8, the processing process related to the currency exchange transaction is conceptually illustrated in order. First, FIG. 5 illustrates how the peg-in to the side chain and the issuance of the JPY token are performed.

The terminals 1a and 1b of the exchanges A and B search (match) the counterparty of the transaction by using the above tools, respectively. Operators of exchanges A and B negotiate transaction details with the other party on the tool. Transaction details include, for example, the type of virtual currency and legal tender to be traded, the transaction price equivalent to the price of the virtual currency against the legal tender, the transaction volume (exchange amount) of the currency, the date and time of the transaction, and the transaction to be traded. Information such as a person's ID (user ID) may be included. When the transaction contents are agreed, the terminals 1a and 1b each perform processing according to the agreed transaction contents.

The terminal 1a performs a peg-in to move the virtual currency held by the exchange A from the main chain to the side chain. Specifically, the terminal 1a sends the virtual currency to a special address in the main chain and locks (freezes) it so that it cannot be used. The terminal 1a transmits information indicating that the virtual currency is locked in the main chain to the auditor's server device (not shown) or embeds it on the side chain, and sends the LBTC to the side chain address specified by the exchange A. Ask the auditor to send.

More specifically, the terminal 1a uses the public key published by each of the plurality of auditors and the public key of the exchange A corresponding to the wallet address on the side chain to generate virtual currency on the main chain. Generate a multisig address to keep locked. Then, the terminal 1a generates a locking transaction in which the virtual currency is deposited at the multisig address and broadcasts it to the network of the main chain. As a result, the virtual currency of the main chain cannot be unlocked without entering the auditor's electronic signature, making it unusable. The terminal 1a transmits the information of the locking transaction and the information such as the public key of the exchange A used at the time of generating the multisig address to the server device of the auditor.

To be precise, the terminal 1a uses the homomorphism of the elliptic curve to generate a new public key from each auditor's public key, and the generated public key is used to generate the above multisig address. , In the present embodiment, the description will be omitted for the sake of brevity.

The server device of each auditor verifies whether or not the virtual currency is locked in the main chain by using the private key of each auditor and the information such as the public key of the exchange A received from the terminal 1a. .. Strong Federations approves peg-ins if a certain number (at least a majority) of the auditors successfully validate. In this case, the LBTC equivalent to the virtual currency locked in the main chain is unlocked or newly issued in the side chain and sent to the wallet address of the exchange A.

The terminal 1a transmits the UTXO information holding the LBTC acquired above to the verification server 2 and registers it in the transaction DB 243. When the exchange A uses the LBTC in which the UTXO is registered without the permission of the verifier X, for example, the verification server 2 does not approve the transaction at the time of verifying the transaction described later, and invalidates the transaction.

On the other hand, the terminal 1b of the exchange B transfers the legal tender held by the exchange B to the verifier X by means such as financial transfer, and requests the verification server 2 to issue a JPY token. When the issuance request is received, the verification server 2 newly generates a JPY token equivalent to the transferred legal currency and sends it to the exchange B.

In this case, the verification server 2 uses the public key of the verifier X in addition to the public key of the exchange B to generate a multisig address, generates a transaction in which a JPY token is deposited at the multisig address, and sidechains. Broadcast to your network. As a result, the JPY token cannot be used on this platform without the approval (signature) of the verifier X.

FIG. 6 conceptually illustrates how a transaction is generated and verified. In order to exchange the above-mentioned LBTC and JPY tokens, the terminals 1a and 1b generate and broadcast a transaction for transmitting the tokens they own to the other party.

In this case, if the terminals 1a and 1b each generate a transaction and send a token to the other party, there is a possibility that the exchange cannot be established due to the fraudulent act of the other party. For example, there may be a case where Exchange A sends LBTC to Exchange B, but Exchange B does not send JPY tokens to Exchange A.

In preparation for the above situation, terminals 1a and 1b exchange tokens by atomic swap. Atomic swap is a method that enables the exchange of virtual currencies (tokens) through bilateral transactions without the need for mutual trust.

Specifically, either terminal 1a or 1b generates a multisig address using the public keys of exchanges A and B, and generates a transaction in which the LBTC and JPT tokens are deposited in the multisig address. Then, the terminals 1a and 1b each input (add) the electronic signatures of the exchanges A and B to the transaction and broadcast the transaction.

In the present embodiment, as an example, it is assumed that the terminal 1a of the exchange A generates a transaction. The terminal 1a stores the LBTC UTXO registered in the verification server 2 as a transaction input. Further, the terminal 1a acquires the information of the UTXO in which the JPY token of the exchange B is held from the terminal 1b, and stores the UTXO as the input of the transaction.

Next, the terminal 1a uses the public keys of the exchanges A and B, and the input of the electronic signatures of the exchanges A and B is a condition for cancellation, and the output destination is the address (public key) of the exchange B. Store the output in a transaction.

Further, the terminal 1a uses the public keys of the exchange A, the exchange B, and the verifier X to cancel the input of the electronic signatures of the three parties, and the output destination is the address of the exchange A. Store the output of in a transaction.

The terminal 1a inputs the electronic signature of the exchange A into the transaction using the private key of the exchange A, and transmits the electronic signature to the terminal 1b of the exchange B. The terminal 1b inputs an electronic signature into the received transaction using the private key of the exchange B. At this time, if Exchange B commits a fraudulent act and modifies the output destination of the JPY token to be paid to Exchange A, the verification of the electronic signature entered by Exchange A fails and the transaction is determined to be invalid. .. As a result, it is possible to carry out a transaction without a relationship of trust with the other party without going through a third party.

Although the so-called single-chain atomic swap has been described above, a plurality of transactions may be generated to exchange currencies as in the case of cross-chain atomic swap. That is, the number of transactions generated by terminals 1a and 1b is not limited to a single number.

When generating the above-mentioned transaction, the terminal 1a encrypts the quantity and type of tokens exchanged in the transaction, that is, the transaction contents so that only the parties can view the transaction contents in order to conceal the transaction contents from a third party. Generate a transaction. Specifically, the terminal 1a generates a transaction in which the transaction content is encrypted by using a method called Confidential Transactions and Confidential Assets.

Confidential transaction is a method of concealing the transaction volume of virtual currency (token in this embodiment) disclosed by the blockchain, and is a method of encrypting the transaction volume by using homomorphic encryption. In the confidential transaction, the Pedersen commission is used, and the transaction volume a is expressed by the commitment C (a) represented by the following equation (1).

C (a) = xG + aH ... (1)

x is the secreting factor shared by the parties, and G and H are the base points (discrete logarithmic points) on the elliptic curve. As shown in equation (1), in addition to the base point G that converts the private key into the public key in ordinary elliptic curve cryptography, the commitment C (commitment C) is added by adding the base point H for encrypting the transaction volume a. a) is generated. In a confidential transaction, the quantity of each input and output stored in the transaction is represented by the commitment C (a), and the commitment C (a) is described in the script of each input and output instead of the quantity.

The 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 the committed transaction volumes a. For example, the relationship of C (1) + C (1) = C (2) holds. Therefore, the transaction volume 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 the total becomes 0. As a result, the party who knows the private key x can know the transaction amount a, while the third party cannot know the transaction amount a.

Further, in the confidential transaction, a ring signature is used to prove that the transaction amount a to be committed is 0 or more, but in the present embodiment, the description will be omitted for the sake of brevity.

Confidential assets are a method that applies confidential transactions, and are a method that conceals the type of virtual currency (asset type) to be traded in addition to the transaction volume. Confidential assets calculate commitments using different base points for each type of cryptocurrency. For example, assuming two types of virtual currencies with transaction volumes a and b, respectively, the commitment C (a) of the virtual currency with transaction volume a is calculated by the formula (1), and the commitment of the virtual currency with transaction volume b. C (b) is calculated by the following equation (2).

C (b) = xG + bI ... (2)

I is a base point on the elliptic curve like H. As can be seen by comparing equations (1) and (2), for confidential assets, commitments C (a) and C (b) are calculated by selecting different base points H and I depending on the type of virtual currency. do. Then, the commitments C (a) and C (b) are described as the quantities of each input and output, and the base points H and I according to the type of virtual currency are set to the respective commitments C (a) and C (b). Label. As a result, the transaction volumes a and b are kept secret.

However, since the type of virtual currency is known with the base point H as a fixed value, in the confidential asset, the base point H is replaced with A as shown in the following equation (3).

A = H + rG ... (3)

r is a secret random number known only to the parties. When the base point H is replaced with A, the 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 the equations (1) and (4), the private key x is replaced with (x, r). A party who knows the random number r can know the type of virtual currency from the base point A, but a third party cannot.

In the Confidential Asset, the base point A is further composed of a ring signature in order to prevent the creation of currency, but in the present embodiment, the description will be omitted for the sake of brevity.

As described above, the terminals 1a and 1b exchange tokens by atomic swap, eliminating the need for a trust relationship, and generate a transaction in which the transaction content is encrypted. In the present embodiment, the terminals 1a and 1b transmit the generated transaction to the verification server 2 and request the verification of the transaction. The terminals 1a and 1b also transmit the private key used for concealing the transaction so that the verification server 2 can verify the transaction.

When the verification request is received, the verification server 2 uses the private key transmitted from the terminals 1a and 1b to decrypt information representing the transaction content such as the token exchange amount (transaction amount) and type. Then, the verification server 2 verifies whether or not the decrypted transaction content is appropriate.

For example, the verification server 2 calculates the transaction price (exchange rate) of the currency exchange transaction between exchanges A and B from the quantity of LBTC exchanged in the above transaction and the quantity of JPY tokens. Since LBTC corresponds to virtual currency and JPY token corresponds to legal tender, the calculated price corresponds to the selling price of virtual currency with respect to legal tender. Further, the verification server 2 acquires the current market value information of the virtual currency for the legal tender from a predetermined external API (Application Programmable Interface). Then, the verification server 2 determines whether or not the difference between the transaction price calculated above and the transaction price (distribution rate) of the virtual currency that is generally distributed is equal to or greater than a predetermined threshold value. If it is determined that the difference between the two is equal to or greater than the threshold value, the verification server 2 determines that the transaction is related to an inappropriate transaction and does not approve the transaction.

In financial transactions, various regulations including laws and regulations, self-regulations, etc. are generally set in order to crack down on inappropriate transactions. On the other hand, this system is a decentralized transaction system using blockchain, and there is no centralized administrator who manages transactions. However, if the transaction is completely entrusted only to the user, there is a risk that inappropriate transactions will be carried out in view of general financial transaction regulations. For example, if the parties collude and exchange a small amount of Japanese yen for a large amount of virtual currency, there is a risk that an act such as money laundering will occur.

Therefore, in the present embodiment, the verification server 2 verifies the transaction content to prevent inappropriate transactions. For example, the verification server 2 verifies the exchange rate of the currency exchanged by the transaction as described above, and determines whether or not the transaction is inappropriate. In addition, the verification server 2 verifies information related to the transaction such as the user ID and UTXO of each user, and determines whether or not the transaction is inappropriate.

In the above, verification is performed based on the currency exchange rate, the ID of the party, UTXO, etc., but the present embodiment is not limited to this, and verification is performed based on, for example, the transaction volume of currency. You may go. That is, the verification server 2 may be able to determine whether or not the transaction content is an appropriate transaction that meets a predetermined condition, and the determination condition is not particularly limited.

FIG. 7 conceptually illustrates how the transaction is broadcast and the auditor verifies the transaction. As described above, the verification server 2 verifies the transaction and determines whether or not the transaction is proper. If it is determined that the transaction is proper and the verification is successful, the verification server 2 adds an electronic signature to the transaction using the private key of the verifier X and broadcasts it to the sidechain network.

The broadcasted transaction is verified by the server equipment of each of the multiple auditors. As mentioned earlier, the auditor's server equipment verifies transactions and forms consensus using Strong Federations algorithms rather than PoW, which relies on the computing power of the server equipment. In Strong Federations, processing is performed in round robin, and one of the auditors is elected as the master in order for verification.

The auditor's server device, which became the master, validates the script of each transaction broadcast on the sidechain network and generates block candidates to be added to the sidechain. The auditor's server device, which is the master, sends the generated block candidates to the server devices of other auditors. The server device of the other auditor verifies the block candidates received from the master and determines whether or not they agree to add them to the sidechain. If it is determined to agree, the auditor's server device enters the auditor's digital signature in the block. When an electronic signature is input from a predetermined number of auditors' server devices among a plurality of auditors, the block is added to the side chain.

As described above, since Strong Federations does not rely on the computing power of the server device, the computing load is greatly reduced, the time required for consensus building is shortened, and quick transactions can be realized. On the other hand, by requiring the consent of a predetermined number of auditors, the security (Byzantine resistance) guaranteed in the main chain can be maintained.

If the auditor approves the transaction by the above process, the transaction between exchanges A and B is normally incorporated into the sidechain. As a result, the LBTC is delivered to the exchange B, and the JPY token is delivered to the exchange A.

FIG. 8 illustrates how pegouts from the sidechain and fiat currency are redeemed. The terminal 1b of the exchange B sends a peg-out request to the auditor's server device or embeds it in the side chain in order to convert the side chain LBTC into the main chain virtual currency (BTC). Specifically, the terminal 1b requests the release of the above-mentioned locking transaction that locks the virtual currency on the main chain.

When accepting a peg-out request, each auditor's server device verifies the UTXO on the sidechain where Exchange B holds the LBTC. When a predetermined number of auditors'servers succeed in verification and approve the pegout, each auditor's server enters a digital signature in the locking transaction to unlock the virtual currency. The virtual currency to be unlocked is not limited to the virtual currency locked by Exchange A in this transaction, and may be a virtual currency locked in another transaction. When the lock of the virtual currency is released, the terminal 1b of the exchange B can transfer the virtual currency to its own wallet address.

Note that the locking transaction in which exchange A locked the virtual currency at the time of peg-in and the locking transaction unlocked by exchange B, which is the counterparty of the transaction, at the time of peg-out do not always match, and other users in other transactions It can also be a generated locking transaction.

The terminal 1a of the exchange A transmits a redemption request for legal tender based on the JPY token acquired by the above transaction to the verification server 2. When the redemption request is received, the verification server 2 checks whether Exchange A holds the JPY token, and then transfers the legal currency equivalent to the JPY token held by Exchange A by means of financial transfer or the like. Send money to Exchange A.

From the above, by using this system, exchange of virtual currency and legal tender can be realized without the risk of so-called counterparties. In addition, it can be exchanged by bilateral transactions without going through a third party, and the parties can control the currency to be bought and sold by themselves. Furthermore, by combining the processing performed by the verifier X, it is possible to impose certain restrictions on currency exchange transactions.

It is preferable that the verification server 2 can output not only transaction verification but also transaction records performed by each transaction, that is, a report of currency exchange transactions performed on this platform. In general financial transactions, it is necessary to submit transaction records at the request of financial authorities. Correspondingly, the verification server 2 decrypts the transaction content encrypted in each transaction using the secret key for concealment, and outputs the transaction record. As a result, the transaction record on this platform can be kept secret from general users, and the transaction record can be viewed as needed.

FIG. 9 is a flowchart showing an example of a processing procedure executed by the trading system. The processing contents executed by the transaction system will be described with reference to FIG. In the following description, for convenience, it is assumed that the exchanges A and B have already agreed to the currency exchange transaction, and the amount of currency to be traded, the brand of the currency, the transaction date, etc. have been decided.

The terminal 1b of the exchange B transmits (outputs) a request for issuing a JPY token (second token) based on the legal tender of the exchange B to the verification server 2 (step S11). The verification server 2 issues a JPY token equivalent to the legal tender held by the exchange B (step S12). Specifically, the verification server 2 uses the public key of the exchange B and the public key of the verifier X to address the multisig address with the input of the electronic signatures of the exchange B and the verifier X as a cancellation condition. Issuance of JPY tokens to.

The terminal 1a of the exchange A generates and broadcasts a locking transaction that locks the virtual currency held by the exchange A unusably on the main chain (step S13). Specifically, the terminal 1a includes a public key corresponding to the wallet address of exchange A on the side chain, and a public key of each of a plurality of auditors who manage the movement of currency between the main chain and the side chain. Is used to generate and broadcast a transaction with a virtual currency deposited at a multisig address.

The terminal 1a outputs a conversion request for converting the virtual currency locked by the locking transaction into an LBTC (first token) on the side chain (step S14). Specifically, the terminal 1a outputs the information of the locking transaction and the information such as the public key of the exchange A, and requests the auditor to peg in to the side chain. When the request is received from the terminal 1a, the auditor's server device verifies whether the virtual currency is locked in the main chain, and if approved, unlocks the UBTC UTXO on the side chain, or a new LBTC. Is issued.

The terminal 1a transmits the LBTC UTXO information acquired by the process of step S14 to the verification server 2 and registers the UTXO in the transaction DB 243 (step S15).

The terminal 1a generates a transaction for exchanging the LBTC held by the exchange A and the JPY token held by the exchange B, which is the counterparty of the transaction (step S16). Specifically, the terminal 1a uses the multisig address to generate a transaction in which the input of the electronic signature of each of the exchanges A and B is used as the output cancellation condition. For example, the terminal 1a first stores the LBTC in which the UTXO is registered in step S15 as an input in the transaction. Further, the terminal 1a acquires the information of the UTXO of the JPY token from the terminal 1b of the exchange B, and stores the JPY token held by the UTXO in the transaction as an input.

Further, the terminal 1a uses the public keys of the exchanges A and B, and the input of the electronic signatures of the exchanges A and B is a condition for cancellation, and the output destination is the address (public key) of the exchange B. Store the output in a transaction. Further, the terminal 1a uses the public keys of the exchange A, the exchange B, and the verifier X to cancel the input of the electronic signatures of the three parties, and the output destination is the address of the exchange A. Store the output of in a transaction.

In step S16, the terminal 1a uses the secret public key shared with the terminal 1b of the exchange B to generate a transaction in which the transaction details such as the quantity and type of tokens are encrypted and described.

The terminal 1a inputs the electronic signature of the exchange A into the generated transaction and transmits it to the terminal 1b of the exchange B (step S17).

When a transaction is received from the terminal 1a of the exchange A, the terminal 1b of the exchange B inputs the electronic signature of the exchange B into the transaction (step S18). The terminal 1b transmits a transaction to the verification server 2 and requests verification (step S19).

When the transaction is received from the terminal 1b, the verification server 2 verifies the transaction and determines whether or not to approve the transaction (step S20). For example, the verification server 2 verifies information related to transactions such as token exchange rate, user ID of each user who is a trader, and UTXO, and determines whether or not to approve it. If it is determined not to approve (S20: NO), the verification server 2 ends a series of processes.

When it is determined to approve (S20: YES), the verification server 2 inputs (adds) the electronic signature of the verifier X to the transaction and broadcasts it to the sidechain network (step S21). In this case, each auditor's server device verifies the transaction, and if approved, the transaction is added to the sidechain block. The verification server 2 notifies the terminals 1a and 1b that the transaction has been broadcast (step S22).

When the notification is received from the verification server 2, the terminal 1b of the exchange B sends a conversion request to the auditor to convert (peg out) the LBTC on the side chain to the virtual currency on the main chain (step S23). Specifically, the terminal 1b outputs a request for releasing the virtual currency locked by the locking transaction on the main chain. In this case, the auditor's server device verifies the LBTC UTXO acquired by the exchange B in the above transaction, and if approved, inputs an electronic signature in the locking transaction to unlock the virtual currency.

When the notification is received from the verification server 2, the terminal 1a of the exchange A transmits a redemption request for legal tender to the verification server 2 based on the JPY token acquired by the above transaction (step S24). When the redemption request is received from the terminal 1a, the verification server 2 redeems the legal tender equivalent to the JPY token to the exchange A (step S25). The verification server 2 ends a series of processes.

The financial assets to be traded are not limited to legal tender, and may be financial products such as government bonds and stocks.

Further, the second blockchain for currency exchange is not limited to the side chain, and may be, for example, a private chain, an off-chain, or the like.

Further, the side chain may be a block chain capable of bidirectional pegging with the main chain, and may operate by an algorithm such as SPV verification (Simplified Payment Verification).

Further, in the above, only the JPY token corresponding to the legal tender is multi-signatured with the electronic signature of the verifier X, but the LBTC corresponding to the virtual currency may also be the multi-signature with the electronic signature of the verifier X.

Further, in the present embodiment, the exchange, which is a virtual currency exchange company, has been described as a user, but it goes without saying that the user may be an individual or the like.

From the above, according to the present embodiment, the currency exchange transaction can be appropriately performed by converting the virtual currency and the legal tender into tokens and performing the transaction for exchanging each token on the blockchain.

Further, according to the present embodiment, by generating a transaction using atomic swap, currency exchange can be performed by bilateral transaction while eliminating the need for a relationship of trust between the parties.

Further, according to the present embodiment, it is possible to prevent an inappropriate transaction from being performed by the verifier X verifying the transaction.

Further, according to the present embodiment, by conducting currency exchange transactions on the side chain, it is possible to achieve quick transactions, control of fees, and the like.

Further, according to the present embodiment, the transaction content can be concealed from a third party.

The embodiments disclosed this time should be considered as exemplary in all respects and not restrictive. The scope of the present invention is indicated by the scope of claims, not the above-mentioned meaning, and is intended to include all modifications within the meaning and scope equivalent to the scope of claims.

1 Terminal (information processing device)
11 Control unit 12 Main storage unit 13 Communication unit 14 Display unit 15 Input unit 16 Auxiliary storage unit P1 Program 2 Verification server (verification device)
21 Control unit 22 Main storage unit 23 Communication unit 24 Auxiliary storage unit P2 program

Claims (10)

A transaction method using a plurality of computers including a first computer related to a first user, a second computer related to a second user, and a third computer related to a verifier.
Said first computer, a virtual currency transaction history is managed in a distributed register, it converts the virtual currency in which the first user's the first token,
Said second computer, and send the financial assets the second user's the verifier outputs a request for issuing a second token based on the financial asset to the third computer,
Wherein one of the plurality of computers, and generates and outputs the transaction to exchange the first and second tokens between said first and second users,
It said second computer, convert said first token obtained by the transaction in the virtual currency,
Transactions wherein said first computer, and outputting a redemption request for the financial assets based on the second token to the third computer. Upon receiving the issuance request, the third computer generates the second token equivalent to the financial asset sent to the verifier.
When the third computer receives the redemption request, the third computer sends the financial asset equivalent to the second token to the source of the redemption request.
The transaction method according to claim 1. When the third computer receives the redemption request and the source of the redemption request holds the second token, the third computer makes the source of the redemption request the financial equivalent of the second token. Send assets
The transaction method according to claim 2, wherein the transaction method is characterized by the above. It is appropriate for the third computer to make a transaction for exchanging the first and second tokens based on a comparison between the exchange rate of the first token and the second token and the circulation rate of a virtual currency that is generally distributed. Determine if or not and approve the transaction if the transaction is appropriate
The transaction method according to any one of claims 1 to 3, wherein the transaction method is characterized in that. Any of claims 1 to 3 , wherein the transaction for exchanging the first and second tokens is a transaction including both a transaction relating to the first token and a transaction relating to the second token. The transaction method described in item 1. On the computer of the first or second user
Using the public key of each of the first and second users and the public key of the verifier who verifies the transaction related to the exchange of the first and second tokens, each of the first and second users Generate the transaction that requires the electronic signature and the electronic signature of the verifier.
The transaction method according to claim 5 , wherein the generated transaction is transmitted to the verifier. On the computer of the first user
Generate and output a locking transaction that locks the virtual currency held by the first user so that it cannot be used.
Based on the locked virtual currency, a conversion request to the first token whose transaction history is managed in a second distributed ledger different from the distributed ledger is output.
The second user's computer, based on said first token obtained by the transaction, according to claim 1 to 6, characterized in that to output a release request of the virtual currency is locked by the locking transaction The transaction method described in any one of the items. The second distributed ledger is a distributed ledger in which a plurality of auditors manage the transfer of funds to and from the distributed ledger.
To the first computer
Using the public key of the first user and the public key of each of the plurality of auditors, the locking transaction is generated.
The conversion request is output to the plurality of auditors to acquire the first token.
The transaction method according to claim 7 , wherein the second computer outputs the cancellation request to the plurality of auditors to acquire the virtual currency. The transaction content related to the exchange of the first and second tokens is encrypted by using the private key shared between the first and second users on the computer of the first or second user. The transaction method according to any one of claims 1 to 8, wherein a transaction is generated. A virtual currency whose transaction history is managed in a distributed ledger, the virtual currency held by the first user is converted into a first token, and the first token is exchanged with a second user. the processing of outputting a redemption request for the financial assets based on the second token more acquired transaction to be replaced with a second token issued based on the financial assets of the second user to the verifier computer The first program to be executed by the first user's computer is distributed so as to be installed on the first user's computer.
The financial asset held by the second user is sent to the verifier, a request for issuing the second token based on the financial asset is output to the verifier's computer, and the user and the first user a second program for executing processing for converting the first token more acquired the second token transaction to be replaced with the first token to the virtual currency to the second user's computer, A generation method for generating a trading system including the first and second user computers by causing the computer to execute a process of delivering the computer for installation on the second user's computer.

Images