WO2020059865A1

WO2020059865A1 - Settlement system, settlement method, user device, and settlement program

Info

Publication number: WO2020059865A1
Application number: PCT/JP2019/037063
Authority: WO
Inventors: 盛徳大橋; 篤中平; 滋藤村; 昌義近田; 達郎石田; 大喜渡邊; 日高　浩太; 岸上　順一
Original assignee: 日本電信電話株式会社
Priority date: 2018-09-20
Filing date: 2019-09-20
Publication date: 2020-03-26
Also published as: US11893583B2; JP7021747B2; US20220051235A1; JP2020047104A

Abstract

Provided is a settlement system comprising: a service provider device 2 that transmits a model information transaction, which contains a transaction model, to a first blockchain network 4; a user device that transmits a payment information transaction, which contains a payment amount and an electronic signature generated using the transaction model, to the first blockchain network 4; and a smart contract 41. The smart contract 41 verifies the electronic signature using the payment amount and the transaction model. The service provider device 2 generates a settlement transaction using the transaction model, the electronic signature, and the payment amount, and transmits the settlement transaction to a second blockchain network 3. A plurality of output conditions are set in the transaction model. The settlement transaction can be used when any of the plurality of output conditions is met.

Description

Payment system, payment method, user device, payment program

{Circle over (1)} The present invention relates to blockchain technology, and more particularly, to technology for linking a plurality of blockchains.

(4) A mechanism that can guarantee reliability without requiring centralized management is becoming popular, especially for the digital cryptocurrency Bitcoin. In this mechanism called blockchain, the reliability of the exchanged information is ensured by the consensus building process in the distributed network, and the integrity of the system is prevented by preventing tampering such as tampering and double use throughout the system. Dripping.

(4) In the blockchain, transaction information (transactions) of virtual currency between participants is organized in units of "blocks", and each block is managed in a time series in a daisy chain. The approval of the new block is formed by an agreement algorithm in a distributed network such as Proof of Work. The approval of the new block indicates that the currency transactions recorded inside the block have been agreed system-wide. A book of a series of transaction information managed using this blockchain is called a “distribution ledger”, and each node (terminal) participating in the network holds the same distributed ledger.

By the way, in Bitcoin, there is a device in implementation called off-chain transaction. The off-chain transaction is a method in which not all transactions are recorded on the blockchain, but only the final result of transactions between two parties performed outside the blockchain is recorded on the blockchain. As described in Non-Patent Document 1, in a payment channel, which is a type of off-chain transaction, a channel that realizes virtual payment is constructed by exchanging incomplete transactions between two users. be able to.

Applying one-way payment channels such as "Spillman-style payment channel" and "CLTV-style payment channel" to create an incomplete transaction excluding the electronic signature and payment amount from the transaction for the cryptocurrency blockchain. By updating this incomplete transaction in other blockchains, it is possible to make virtual bitcoin payments on other blockchains without connecting to the cryptocurrency blockchain Conceivable.

In this method, the user can pay for the service to the service provider, but cannot pay in the opposite direction (from the service provider to the user). That is, when the payment is canceled, the service provider cannot refund the user using the same channel.

This is a form in which only the service provider has the right to broadcast the transaction generated from the latest incomplete transaction to the virtual currency blockchain, and only the user updates the amount of the incomplete transaction. Due to that. For example, assume that the user cancels the previously updated payment amount and updates an incomplete transaction with a payment amount lower than the previous payment amount. In this case, it is determined by the service provider at which point in time a transaction is generated with the incomplete transaction payment amount and is broadcast to the virtual currency blockchain.

Therefore, it is undeniable that the service provider does not broadcast a transaction with a low payment amount reflecting the cancellation to the cryptocurrency blockchain, but broadcasts a transaction with a high payment amount before the cancellation to the virtual currency blockchain.

The present invention has been made in view of the above-described problems, and an object of the present invention is to efficiently cooperate with a plurality of block chains and cancel a payment agreed between a user and a service provider on a virtual currency block. To reflect on the chain.

In order to achieve the above object, one embodiment of the present invention is a settlement system in which a first blockchain and a second blockchain are linked, and a template information transaction including a transaction template is transmitted to a network of the first blockchain. And a payment information transaction including a payment amount and a service provider device to be transmitted to the first blockchain, an electronic signature generated using the template of the transaction registered in the first blockchain, and a payment information transaction. A user device and a smart contract included in a first block chain, wherein the smart contract verifies an electronic signature included in the payment information transaction using the payment amount and the template of the transaction, The service provider device includes a first block. A settlement transaction is generated by using the transaction template registered in the transaction chain, the electronic signature, and the payment amount, and transmitted to the second blockchain network; A condition is set, and the settlement transaction becomes available when any of the plurality of output conditions is satisfied.

One aspect of the present invention is a settlement method in which a first block chain and a second block chain are linked, and the service provider device transmits a template information transaction including a transaction template to a network of the first block chain. Transmitting, the user device generates an electronic signature using the template of the transaction registered in the first blockchain, and transmits a payment information transaction including the electronic signature and the payment amount to the network of the first blockchain. And the smart contract included in the first block chain verifies the electronic signature included in the payment information transaction using the payment amount and the template of the transaction. The template of the transaction registered in the blockchain and A payment transaction is generated using the electronic signature and the payment amount, and transmitted to a second blockchain network. A plurality of output conditions are set in the template of the transaction, and the payment transaction Becomes available when any of the output conditions is satisfied.

One aspect of the present invention is a user device in a settlement system in which a first block chain and a second block chain are linked, and transmits a remittance transaction for remitting a deposit of a predetermined amount to a network of the second block chain. A remittance transaction generating unit that generates an electronic signature using the transaction template registered in the first blockchain by the service provider device, and transmits a payment information transaction including the electronic signature and the payment amount to the first blockchain. A payment transaction generation unit that transmits the transaction template to the network, wherein a plurality of output conditions are set in the transaction template, and the service provider device executes the transaction template, the electronic signature, and the payment amount. And the settlement transaction generated using , When filled with any of the plurality of output conditions, it becomes available.

One embodiment of the present invention is a payment program that causes a computer to function as the user device.

According to the present invention, a plurality of block chains can be efficiently linked, and the cancellation of payment agreed between the user and the service provider can be reflected on the virtual currency block chain.

It is a figure showing the whole composition of the settlement system concerning the embodiment of the present invention. FIG. 3 is a block diagram illustrating a configuration of a blockchain client. It is a conceptual diagram which shows a "setting" process. It is a figure showing the output conditions of a remittance transaction. It is an image figure of a transaction template. It is an example of a script showing output conditions of a transaction template. It is a conceptual diagram which shows a "payment" process. 9 is a flowchart illustrating a process of creating a digital signature of a user device. It is a flowchart which shows the payment verification process of a bridging contract. It is a key map showing “cancellation” processing. It is a key map showing “payment” processing. FIG. 3 is a diagram illustrating a relationship between transactions in the virtual currency type block chain.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.

FIG. 1 is an overall configuration diagram of a payment system according to an embodiment of the present invention. This payment system is a system in which payment by virtual currency on a virtual currency type blockchain (second blockchain) and service provision by a smart contract type blockchain (first blockchain) are linked.

The virtual currency type blockchain is a distributed ledger shared by nodes participating in the P2P network 3 (hereinafter, “virtual currency type network”) of the blockchain. The transaction history of the virtual currency is registered in the virtual currency type blockchain. When a transaction describing transaction information such as where and how much virtual currency is to be transferred is broadcast to the virtual currency type network 3, a block including the transaction is generated, and the generated block is stored in the virtual currency type blockchain. Added to the end.

The smart contract type blockchain is a distributed ledger shared by nodes participating in the P2P network 4 of the blockchain (hereinafter, “smart contract type network”). When a transaction is broadcast to the smart contract type network 4, a block including the transaction is generated, and the generated block is added to the end of the smart contract type block chain. When a block is added, a script code (that is, a smart contract) registered in advance is executed on the terminal of the participating node using the transaction included in the block as an input, and the distributed ledger is updated. Ethereum, Hyperledger @ Fabric, and the like are examples of a platform for realizing such a smart contract type blockchain.

The user device 1 is a device used by a user of a service provided by the smart contract type blockchain. The user device 1 includes a transaction generation unit 11, a cancellation processing unit 12, and a blockchain client 13.

The transaction generation unit 11 generates necessary transactions in processing (steps) of “setting”, “payment”, “settlement”, and “cancel (cancel)” described later. The generated transaction is transmitted to the

corresponding blockchain networks

3 and 4 via the blockchain client 13.

In the “setting” process, the transaction generation unit 11 generates a “transfer transaction for depositing a user's address to a multisig address” (transfer transaction) and transmits it to the virtual currency network 3 (step S1). Thereafter, the user device 1 generates a “transaction for registering deposit information” (deposit information transaction) and transmits it to the smart contract type network 4 (step S2).

In the “payment” process and the “cancel” process, the transaction generation unit 11 generates a “transaction for registering an electronic signature indicating payment and a payment amount” (payment information transaction) and transmits it to the smart contract type network 4 (step). S3).

In the “payment” process, when the service provider rejects the consent to cancel, the transaction generation unit 11 transmits the “transaction to transfer the funds that the service provider of the payment transaction should receive to the user address” (penalty transaction). ) Is generated and transmitted to the virtual currency network 3 (step S8).

The cancellation processing unit 12 transmits a cancellation request to the service provider device 2 when canceling the payment information transaction registered in the smart contract type blockchain.

FIG. 2 is a block diagram showing the configuration of the blockchain client 13. The user device 1 of the present embodiment is connected to the virtual currency type network 3 and the smart contract type network 4. Therefore, the blockchain client 13 includes a virtual currency type blockchain client 14 and a smart contract type blockchain client 15.

The virtual currency type blockchain client 14 includes a distributed ledger 141 and a blockchain control unit 142. The distributed ledger 141 synchronizes slowly with all terminals (devices) connected to the virtual currency network 3 via the blockchain control unit 142, so that the latest blockchain is stored in a form close to real time. Have been.

(4) The blockchain control unit 142 cooperates autonomously with terminals connected to the virtual currency network 3 to maintain a blockchain system. Specifically, the block chain control unit 142 accesses the distribution ledger 141, and reads or updates the block chain of the distribution ledger 141. The blockchain control unit 142 transmits the transaction to the virtual currency network 3.

The smart contract type blockchain client 15 includes a distributed ledger 151 and a blockchain control unit 152. The distributed ledger 151 and the blockchain controller 152 are the same as the distributed ledger 141 and the blockchain controller 142.

The service provider device 2 is a device used by a service provider operating a service on the smart contract type blockchain. The service provider provides the user with some service (for example, digital content right registration) upon receiving payment from the user.

The service provider device 2 includes a transaction generation unit 21, a transaction template generation unit 22, and a blockchain client 23.

The transaction generation unit 21 and the transaction template generation unit 22 generate necessary transactions in “setting”, “cancel”, and “payment” among the processing of “setting”, “payment”, “cancel”, and “payment”. .

In the “setting” process and the “cancel” process, the transaction template generation unit 22 generates a “transaction for registering a transaction template” (template information transaction) and transmits it to the smart contract type network 4 (step S4). The transaction template will be described later.

In the “cancel” process, the transaction generation unit 21 generates a “transaction for registering a hash original image, which is an output condition of a transaction template” (original image transaction), and transmits it to the smart contract type network 4 (step S9).

In the “payment” process, the transaction generation unit 21 generates a “transaction to settle the deposit of the multisig address” (payment transaction) and sends it to the virtual currency network 3 (step S5). In addition, the transaction generation unit 21 generates a “transaction to execute payment and determine payment from the multisig address to the address to the service provider” (payment execution transaction), and transmits the transaction to the virtual currency network 3. (Step S10).

Since the blockchain client 23 is the same as the blockchain client 13 of the user device 1 (see FIG. 2), the description is omitted here.

特徴 As a feature of this embodiment, two smart contracts are registered in the smart contract type network 4 in advance. Specifically, the bridging contract 41 and the service contract 42 are registered in the distributed ledger 151 on each terminal connected to the network 4 according to the protocol of the smart contract type block chain.

The bridging contract is a smart contract that links the virtual currency blockchain and the smart contract blockchain. The bridging contract receives information related to payment (electronic signature, payment amount) from the user device 1 and verifies its validity.

(4) A service contract is a smart contract that executes a service (for example, content right transfer) performed by a service provider after the bridging contract confirms the validity of payment information.

Each smart contract has an API (Application Programming Interface) for checking and referring to the state of stored variables. For example, the user device 1 acquires the execution result of the service contract from its own distributed ledger 151 using the API (step S6). Further, the service provider device 2 acquires the deposit information and the payment information registered in the bridging contract from its own distributed ledger using the API (step S7). Note that the broken lines in steps S6 and S7 in FIG. 1 indicate a process of referring to the distributed ledger stored in the own device.

Next, the processing of this embodiment will be described. In the present embodiment, three basic processes of “setting”, “payment”, and “settlement” and an applied process of an applied “cancel” are performed.

FIG. 3 shows a conceptual diagram of the “setting” process. In the “setting” process, preparations are made for the next “payment” process.

First, the user device 1 generates a remittance transaction, and transmits (broadcasts) the remittance transaction to the virtual currency network 3 (step S11). The remittance transaction is a transaction in which a deposit (security deposit) of a predetermined amount is remitted from a user address (wallet) to a multisig address jointly managed by the user and the service provider.

A multisig address is an address in a cryptocurrency type blockchain that requires a plurality of electronic signatures for transactions at the time of withdrawal. In the present embodiment, a multi-sig address that requires a digital signature of a user and a digital signature of a service provider is used. Here, for example, it is assumed that 1.0 BTC has been remitted to the multisig address.

When the remittance transaction is transmitted to the virtual currency type network 3, a block including the remittance transaction is generated, and due to the gentle synchronization between the terminals, the block is distributed to all terminals connected to the virtual currency type network 3 (Blockchain). Here, it is determined that a 1.0 BTC deposit has been remitted from the user's address to the multisig address in the virtual currency type blockchain.

In the present embodiment, in the remittance transaction, after a predetermined period (first period) has elapsed, an output condition is set such that the remittance transaction can be used only with the electronic signature of the user device 1. Specifically, after a certain period of time has elapsed since the remittance transaction in step S11 was included in the blockchain, it is possible to pay out with an electronic signature of only the user. That is, the user can use the remittance transaction as an input for the next transaction after a certain period has elapsed since the block including the remittance transaction was registered in the blockchain. Such a time limit is called “time lock”. The time lock period is, for example, a time period after the remittance transaction in S11 is included in the block chain and a predetermined number of blocks (for example, 100 blocks) are connected after the block. By setting such output conditions in the remittance transaction, the user can refund (remit) the deposit of the multisig address to his / her address after the time lock period has elapsed. .

By applying a time lock to the multi-sig address, it is possible to prevent the settlement transaction by the service provider from being transmitted, thereby stopping the communication with the service provider and deadlocking the user's deposit. For example, if a time lock of 100 blocks has been applied, if 100 blocks or more have elapsed, the user will generate a refund transaction, and the deposit sent to the multi-sig address only with the user's electronic signature will be transferred to the user's address Can be remitted (refunded).

In Bitcoin, output conditions can be specified by script for the output of a transaction. The time lock is one of the attributes of the transaction, and prevents the transaction from being approved until the time or time specified by the time lock (the transaction is treated as an invalid transaction when the block is generated by the minor).

FIG. 4 is a diagram for explaining output conditions of a remittance transaction in the present embodiment. FIG. 4A is a conceptual diagram of an output condition of a remittance transaction. “User” in FIG. 4A indicates a user, and “SP” indicates a service provider. In the illustrated example, the condition that the digital signature of “User” (user) and the digital signature of “SP” (service provider) are multi-sig addresses, and the time after the time specified by the time lock (here, 100 (After block) indicates that the digital signature can be used only with the electronic signature of “User”. FIG. 4B is an example of a script for bit coins under the output conditions shown in FIG. 4A.

Next, the user device 1 transmits a transaction (deposit information transaction) for registering deposit information relating to the deposit to the smart contract type network 4 (step S12). The transaction includes at least the amount of the remitted deposit as the deposit information, and may further include information such as the ID and the multisig address of the remittance transaction in step S11.

When this transaction is transmitted to the smart contract type network 4, a block including the transaction is generated, and due to gradual synchronization between the terminals, the block is distributed to all terminals connected to the smart contract type network 4. Is reflected in Thereby, in all the terminals, the deposit information is registered in the storage area managed by the bridging contract of the distributed ledger.

(4) The service provider device 2 acquires the deposit information registered by the user device 1 from the bridging contract registered in its own distributed ledger (step S13). The service provider device 2 creates a transaction template (transaction template) using the acquired deposit information (step S14). Here, the transaction template is a form of an incomplete transaction that is a modification of the transaction of the virtual currency type blockchain. Specifically, the transaction is a transaction in which information of “remittance amount” and “all electronic signatures” is excluded from “payment transaction indicating remittance from multi-sig address” in “payment” processing described later.

(5) An image of a transaction template is shown in FIG. In the illustrated example, “all digital signatures” required for input and “remittance amount” required for output are “null” (blank). Further, in the illustrated example, there are two outputs (output 1 and output 2), and two kinds of remittance amounts are described. One is basically the amount to be remitted to the service provider, and the other is the amount to be remitted as change to the user. The destination of the output 1 is set with a hash value of a script that specifies output conditions (conditions 1 and 2) described below.

{Circle around (1)} In step S11, 1.0 BTC is deposited in the multisig address. In the next “payment” process, the user device 1 updates the “transfer amount (that is, payment amount and change)” and “electronic signature” of the transaction template within this deposit range (1.0 BTC) and updates the payment information. You will generate a transaction and submit it to the bridging contract.

In the present embodiment, a plurality of output conditions are set for the output 1 of the transaction template, and the settlement transaction of the “settlement” process described later can be used when any of the plurality of output conditions is satisfied. Here, the following two output conditions are imposed.

FIG. 6 shows an example of a bitcoin script expressing the output conditions of conditions 1 and 2.

Condition 1: Output of a transaction template (incomplete transaction) is restricted by a time lock. After a certain period (second period) of the designated time lock has elapsed, the service provider device 2 can use the settlement transaction generated using the transaction template as an input of the next transaction. it can. The certain period of the time lock is set in the script shown in FIG. 6, and the script is transmitted to the smart contract type network 4 together with the transaction template in S15, and is reflected in the distributed ledger of all terminals. The user can confirm the time lock time by looking at the script registered in his / her distributed ledger. In the example shown in FIG. 6, the certain period is a time period after the remittance transaction (FIG. 2: S11) is included in the block chain and 110 blocks are connected behind it.

Condition 2: Transaction template output is restricted by hash lock. The user can unlock the script using the original image of the hash (original data) and its signature. Here, the “hash lock” is a condition under which an original image corresponding to a designated hash is submitted at the input of the next transaction, so that a settlement transaction generated using a transaction template can be used.

In the present embodiment, the service provider device 2 generates an arbitrary original image when generating a transaction template, and sets a hash of the original image in a script. However, the original image is not disclosed at the stage of setting. As described in the condition 1, the script is shared by the user via the smart contract type network 4. Therefore, if the user device 1 can obtain the original image of the hash, the script, the original image, and the usage The payment transaction can be used together with the signature of the party.

Conditions 1 and 2 function after the transaction template is recorded in the virtual currency blockchain as a complete settlement transaction through the “settlement” process (see the “settlement” process described later). Only when either condition 1 or condition 2 is satisfied, the settlement transaction can be used.

Condition 1 indicates that the service provider device 2 can transfer the remittance from the multisig address to its own address (wallet) only after the specified time lock. Specifically, in the “settlement” process, a complete transaction is broadcast as a settlement transaction, and after the settlement transaction is included in the block chain, a certain number of blocks are connected backward (for example, 110 blocks). After the lapse of time, of the funds remitted from the multisig address, the funds received by itself (payment amount of output 1 in FIG. 5) can be freely moved.

If the service provider performs a betrayal action (refer to “cancel processing”) during this waiting time, the user must use all the funds remitted from the multisig address under condition 2 (output 1 / output 1). 2 together), that is, the money can be remitted (refunded) to its own address.

In condition 2, if the original image corresponding to the hash lock specified in the script is specified in the input of the transaction following the payment transaction, the payment transaction can be used only with the electronic signature of the user. The condition 2 is set as a penalty for the service provider in order to establish the cancellation. The details will be described in the "cancel" process described later.

Note that the execution order of the condition 1 or the condition 2 is as follows: (1) When the service provider performs a betrayal action for the “cancellation agreement”, the user uses the condition 2 before the time lock of the condition 1 elapses. Remit the funds (output 1) that the service provider should obtain in the settlement transaction to its own address only with the signature of the user. (2) If no betrayal by the service provider is performed, condition 1 After the elapse of the time lock, the order in which the service provider remits the funds (output 1) to be obtained by the service provider in the settlement transaction using condition 1 to its own address.

Then, in the virtual currency type block chain, the service provider device 2 waits for a time sufficient to determine the block including the remittance transaction transmitted in step S11, and then generates the template including the transaction template generated in step S14. The information transaction is transmitted to the smart contract type network 4 (step S15).

(4) As a result, a block including the template information transaction is generated, and the block is reflected in the distributed ledger of all terminals connected to the smart contract type network 4 by gradual synchronization between the terminals. Here, the transaction template is registered in the bridging contract of the smart contract type blockchain.

At this time, the service provider device 2 adds, in addition to the transaction template, information necessary for verifying the electronic signature performed in the next payment process (for example, disclosure of the virtual currency address of the user device 1) in the template information transaction. A key) and information (for example, a script shown in FIG. 6) necessary for verifying the payment process may be transmitted and registered in the bridging contract. Alternatively, the bridging contract may hold in advance information necessary for verifying the electronic signature and information necessary for verifying the payment processing.

Next, the “payment” process will be described.

FIG. 7 shows a conceptual diagram of the “payment” process. FIG. 7 shows an example in which the payment processing is performed three times while updating the payment amount.

First, in the first payment, the user device 1 acquires the transaction template registered by the service provider device 2 in the “setting” process from the bridging contract of its own distributed ledger (step S21). Then, the user device 1 creates the digital signature 1 from the transaction template (step S22).

FIG. 8 is a flowchart showing the processing in steps S21 and S22 of the user device 1. As described above, the user device 1 acquires a transaction template from the bridging contract (Step S21). Then, the user device 1 sets the payment amount 1 (here, 0.3 BTC) in the acquired transaction template, and generates the pre-signature transaction 1 (step S221). When the payment amount 1 is set, the remittance amount (1.0 BTC-0.3 BTC-payment fee) to be changed to the user is appropriately calculated and set on the user terminal. The payment fee may be determined between users, or a fixed value may be adopted for each service. Then, the user device 1 generates an electronic signature 1 for the pre-signature transaction 1 with the user's private key corresponding to the multisig address (step S223).

Returning to FIG. 7, the user device 1 generates a transaction (payment information transaction) for including the payment amount 1 and the electronic signature 1 and registering the information in the bridging contract, and sends the transaction to the smart contract type network 4. Transmit (step S23). As a result, a block including the transaction is generated, and the block is reflected in the distributed ledger of all terminals connected to the smart contract type network 4 by gentle synchronization between the terminals. Here, in the smart contract type blockchain, the payment amount 1 and the electronic signature 1 are registered in the bridging contract of each terminal.

(4) When the block including the transaction is registered in the distributed ledger, a predetermined process (payment verification) by the bridging contract is executed on all terminals (step S24).

FIG. 9 is a flowchart showing the verification processing in step S24 performed by the bridging contract. First, the bridging contract acquires the “transaction for registering the electronic signature 1 and the payment amount 1 (0.3 BTC)” transmitted by the user device 1 in step S23 (step S241). The bridging contract verifies that the sum of the payment amount 1 of the acquired transaction and the payment fee (such as the fee paid to the miner in the virtual currency blockchain) does not exceed the deposit amount (1.0 BTC). (Step S242).

If it is verified that the value does not exceed (if the validity is verified), the bridging contract verifies the electronic signature 1 included in the payment information transaction using the payment amount and the transaction template. Specifically, the bridging contract creates a pre-signature transaction by setting the payment amount 1 to a transaction template registered in advance in the bridging contract in the setting process (see FIG. 3) (step S243). When the payment amount 1 is set, the remittance amount (1.0 BTC-0.3 BTC-payment fee) to be changed to the user is appropriately calculated and set on the bridging contract. Next, the bridging contract verifies the electronic signature 1 using the created pre-signature transaction (step S244).

As a method of verifying the electronic signature, it is known that in the ECDSA-type electronic signature used in bit coins and the like, a public key for verification can be restored using a message before the signature and the electronic signature.

Therefore, the bridging contract uses the information (public key, public key hash, etc.) necessary for signature verification registered in advance in step S15 in FIG. The validity of the electronic signature 1 is verified. That is, the bridging contract restores the public key using the generated pre-signature transaction and the electronic signature 1 transmitted from the user device 1, and restores the restored public key and the public key registered in advance. If they match, the digital signature 1 is verified as valid. On the other hand, if the restored public key does not match the public key registered in advance, the bridging contract verifies that the electronic signature 1 is not valid.

Then, when the validity of the electronic signature 1 is verified, the bridging contract calls the service contract (Step S245).

Returning to FIG. 7, when the electronic signature 1 is verified to be valid, the bridging contract calls the service contract to execute a service corresponding to the payment amount 1. (Step S25). Specifically, the bridging contract calls the method of the service contract with the payment amount 1 or the like as a parameter (step S25). Thereby, the service contract executes a predetermined service (for example, right transfer of digital content) according to the payment amount.

In FIG. 7, the user device 1 performs the payment process in steps S21 to S25 three times, and each time a service is provided by the service contract. The second payment process (steps S31 to S35) and the third payment process (steps S31 to S35) are the same as the first payment process (steps S21 to S25).

However, payment amount 1 (0.3 BTC) <payment amount 2 (0.6 BTC) <payment amount 3 (0.9 BTC) holds, the last payment amount (0.9 BTC) is the final settlement amount Become. Here, the second and subsequent payment amounts are obtained by adding the payment amount for the current service to the previous payment amount. In the example shown in FIG. 7, the user device 1 makes three payments, and provides a service of 0.3 BTC each time.

In FIG. 7, the user device 1 broadcasts the payment information transaction three times to the smart contract type network 4 (steps S23, S33, S43). When the “settlement” process described below is performed, the service provider device 2 cannot perform the settlement using the first and second payment information. Even if a payment transaction is generated and broadcast using the first and second payment information, it is rejected in the process of consensus verification of the virtual currency type blockchain and becomes invalid on a network basis.

処理 So far, the processing of “setting” and “payment” has been described. Here, “cancel” processing of “payment”, which is a flow different from normal payment, will be described. In the "cancel" process, unlike the "payment" process, it is possible to register an amount lower than the previously registered payment amount. Cancellation requires registering a new transaction template to invalidate the previous payment.

FIG. 10 shows an outline of the “cancel” process. By performing the processing illustrated in FIG. 10, it is considered that the cancellation of the “payment” processing has been agreed between the user and the service provider.

(4) The user device 1 transmits a cancellation request to the service provider device 2 (step S71).

(4) Upon receiving the cancel request, the service provider device 2 generates a new transaction template (another transaction template) (step S72). Specifically, the service provider device 2 generates a new original image, and generates a new transaction template and a script of output conditions using the hash of the original image. The new transaction template and output condition script are the same as the transaction template of the “setting” process (FIG. 3: S14) and the output condition script (FIG. 6) except for the hash of the original image. Although the original image is not specified, it is necessary that the original image cannot be easily estimated.

{Circle around (2)} The service provider device 2 transmits the template information transaction including the transaction template generated in step S72 to the smart contract type network 4 (step S73). As a result, a block including the template information transaction is generated, and the block is reflected in the distributed ledger of all terminals connected to the smart contract type network 4 by gentle synchronization between the terminals. Here, the new transaction template is registered in the bridging contract of the smart contract type blockchain.

At this time, the service provider device 2 adds to the template information transaction, in addition to the new transaction template, information necessary for verifying the electronic signature performed in the cancellation process (for example, disclosure of the virtual currency address of the user device 1). A key) and information necessary for verifying the payment processing (for example, a script indicating an output condition) may be transmitted and registered in the bridging contract. Alternatively, the bridging contract may hold in advance information necessary for verifying the electronic signature and information necessary for verifying the payment processing.

(4) The user device 1 acquires a new transaction template from the bridging contract of its own distributed ledger (step S74). Then, similarly to S22 and S23 in FIG. 7, the user device 1 generates a new electronic signature and registers new payment information (payment amount, electronic signature) in the bridging contract using the new transaction template. A payment information transaction (another payment information transaction) is transmitted to the smart contract type network 4 (steps S75 and S76). As a result, a block including the payment information transaction is generated, and the block is registered in the distributed ledger of all terminals connected to the smart contract type network 4. The payment amount of the new payment information is lower than the payment amount of the latest payment information transaction of “payment processing”.

When the block including the new payment information transaction is registered in the distributed ledger, payment verification by the bridging contract is executed on all terminals (step S77). That is, the bridging contract verifies the payment amount and the electronic proof of the new payment information transaction. The bridging contract performs the same payment verification as in S24 of FIG. In addition, the bridging contract verifies whether the new payment amount is lower than the payment amount of the previous payment information transaction, and if it is lower, determines that the new payment amount is valid. .

(4) The service provider device 2 acquires a new payment information transaction from its own distributed ledger, and presents the payment amount of the transaction to the service provider. The service provider checks the payment amount and determines whether or not to agree to the cancellation requested by the user. The service provider can also determine that the user does not agree with the cancellation request, such as when the user's cancellation request is improper. If they do not agree, the service provider device 2 does not perform the next step S79.

If the service provider agrees to cancel, the service provider device 2 registers the original image serving as the base of the hash set in condition 2 of the old transaction template (FIG. 3: S15) in the bridging contract. An original image transaction is generated and transmitted to the smart contract type network 4 (step S79). As a result, a block including the original image transaction is generated, and the block is registered in the distributed ledger of all terminals connected to the smart contract type network 4. As a result, the original image of the hash of the condition 2 in the old transaction template is shared by the user device 1. In the present embodiment, when the service provider device 2 transmits the original image transaction, it is considered that the service provider has agreed to the cancellation.

(4) When the block including the original image transaction is registered in the distribution ledger of each terminal, a service cancellation process by a bridging contract is executed on all terminals (step S80). The bridging contract calls the service contract according to the payment amount of S74 in order to cancel the already executed service. Specifically, the bridging contract calls a service contract method using a predetermined amount (for example, a difference amount between the previous payment amount and the current payment amount) as a parameter. Thereby, the service contract cancels the predetermined service according to the difference amount.

Finally, the “settlement” process will be described.

FIG. 11 is a diagram showing the “settlement” process. The service provider device 2 closes the payment at an arbitrary timing and reflects the payment on the virtual currency type blockchain. First, the service provider device 2 acquires a final payment amount, an electronic signature, and a transaction template from its own distributed ledger (bridging contract) (step S51).

Here, the final payment amount, the electronic signature, and the transaction template are the payment amount 3, the electronic signature 3, and the transaction template in FIG. 7 when the cancellation process is not performed. If it has been done, it is the new payment amount, the electronic signature, and the transaction template in FIG.

Then, the service provider device 2 sets the payment amount and the electronic signature acquired in S51 in the transaction template to generate a settlement transaction. The settlement transaction at this time is a “transaction from the multi-sig address to which the digital signature of only the user device 1 has been added”. That is, the settlement transaction at this point is not a valid transaction because the electronic signature of the service provider device 2 is not provided.

Therefore, the service provider device 2 attaches an electronic signature to the settlement transaction with its own private key corresponding to the multisig on its own terminal in order to make the remittance from the multisig address valid, and the virtual currency type block. A payment transaction valid on the chain is created (step S52). The settlement transaction after the signature has two electronic signatures of the user and the service provider, and thus is effective on the virtual currency type blockchain.

{Circle around (2)} The service provider device 2 transmits the settlement transaction after the signature to the virtual currency network 3 (step S53). The service provider needs to transmit a settlement transaction before 100 blocks are connected after the block of the remittance transaction is registered in the distribution ledger, depending on the output condition of the remittance transaction (S11 in FIG. 3). .

When the settlement transaction is transmitted to the virtual currency network 3, a block including the settlement transaction is generated, and the loose synchronization between the terminals causes the block to be distributed to all terminals connected to the virtual currency network 3 Is reflected in

Thereby, the change of the output 2 of the settlement transaction is remitted to the user's address. On the other hand, the payment amount of the output 1 of the settlement transaction satisfies one of the conditions 1 and 2 of the script indicated by the hash set at the destination of the output 1 of the settlement transaction (transaction template) in the virtual currency blockchain. In this case, the settlement transaction can be used.

According to this, in the present embodiment, the service provider is made to perform the cancellation of the payment. That is, in the present embodiment, by transmitting the original image transaction by the service provider, it is possible to prevent a transaction in which the user agrees with the cancellation requested by the user and makes the transaction cancel.

Specifically, the service provider can obtain a predetermined payment amount from the deposit remitted to the multisig address after the elapse of the period specified by the time lock of the condition 1. In the illustrated example, the period (T2) after 110 blocks have been connected since the block of the remittance transaction (S11 in FIG. 3) was registered in the distribution ledger. That is, the service provider device 2 performs the payment execution transaction for remitting the payment amount specified in the payment transaction to its own address after the elapse of the time lock period of the condition 1 (T2) (step S56).

Further, when the service provider device 2 agrees to the cancellation, in step S79 in FIG. 10, the service provider device 2 registers the original image of the hash used in the old transaction template in the distribution ledger of the bridging contract and discloses it to the user. I have. Therefore, even if the service provider betrayed the user by falsifying the cancellation agreement and sent the settlement transaction using the old transaction template that should have been canceled, the user will still be By using the original image of, the hash lock of the condition 2 can be released.

In this case, the user transmits a penalty transaction for remitting the payment amount of the output 1 specified in the settlement transaction to his / her address before the time lock period (T2) of the condition 1 elapses. The payment amount to be paid to the service provider can be recovered to the address (step S55). The change of the output 2 of the settlement transaction is remitted to the user's address by registering the settlement transaction (S53) in the blockchain.

As described above, in the present embodiment, when the service provider agrees to cancel, the penalty transaction of the user under the condition 2 functions as a penalty (fine), so that it is difficult for the service provider to take an action that betrays the user. Become. That is, it is difficult for the service provider to remit the payment amount of output 1 of the settlement transaction to its own address before the user by imposing an output condition on the settlement transaction (transaction template).

処理 Hereinafter, the processing after S53 will be described separately for a case where the cancel processing is not performed and a case where the cancel processing is performed.

<When cancel processing is not performed>
The service provider device 2 transmits the payment transaction generated using the payment amount 3, the electronic signature 3, and the transaction template in FIG. 7 to the virtual currency network 3 (step S53). The service provider device 2 transmits the settlement transaction until the period (T1) specified by the output condition of the remittance transaction (S11 in FIG. 3).

Then, after a period (T2) specified by the time lock of the condition 1 has elapsed, the service provider apparatus 2 setstle the payment amount (output 1) specified in the payment transaction to its own address. Is transmitted to the virtual currency type network 3 (step S56).

With this, the payment amount 3 of 0.9 BTC is remitted from the multisig address to the address of the service provider, and the settlement is completed.

Until the service provider device 2 transmits the settlement transaction to the virtual currency network 3 (step S53), that is, until the service provider closes the payment, the user device 1 performs the n-th payment process shown in FIG. To rewrite the payment amount and receive additional service provision.

<When cancel processing is performed>
The service provider device 2 transmits, in principle, the settlement transaction generated using the new payment amount registered in the cancellation process, the electronic signature, and the transaction template to the virtual currency network 3 (step S53). The service provider device 2 transmits the settlement transaction until the period (T1) specified by the output condition of the remittance transaction (S11 in FIG. 3).

Here, the user monitors whether the cryptocurrency type blockchain includes a settlement transaction in preparation for the service provider to betray the user with knowledge of the penalty (to make the cancellation wrong), and settle the settlement transaction. Is verified (S54). Specifically, the user device 1 refers to its own distributed ledger to determine whether or not there is a settlement transaction, and if there is a settlement transaction, the payment amount of the settlement transaction is determined by the cancellation process. Verify whether the payment amount is sent.

If the payment amount of the settlement transaction is not the payment amount transmitted in the cancellation process (in the case of verification NG), the user device 1 specifies the payment amount in the output 1 of the settlement transaction before the period (T2) of the condition 1 elapses. A penalty transaction for transferring the payment amount to its own address is transmitted to the virtual currency network 3 (step S55). As a result, the user can return the payment amount (output 1) to be paid to the service provider in the settlement transaction to his / her address as a penalty. When the settlement transaction is not transmitted, the user device 1 transmits a refund transaction to refund the deposit remitted to the multisig address in the remittance transaction to its own address.

(4) When the payment amount of the settlement transaction is the payment amount transmitted in the cancellation process (in the case of verification OK), the user device 1 does not transmit the penalty transaction of S55. As a result, the service provider device 2 transmits the settlement execution transaction after the lapse of the period (T2) of the condition 1 (S56). As a result, the service provider can remit the payment amount specified in the output 1 of the settlement transaction and agreed on in the cancellation process to its own address.

FIG. 12 shows the relationship of transactions in the virtual currency type blockchain. The remittance transaction 121 is a transaction for the user to remit a 1.0 BTC deposit to the multisig address, as described in S11 of FIG. If the settlement transaction 123 (FIG. 11: S53) is not transmitted during the output condition of the remittance transaction (for example, a time lock of 100 blocks), the user transmits the refund transaction 122 and transmits the 1.0 BTC transferred by the remittance transaction. To get your deposit back to your own address. Thus, it is possible to prevent the contact with the service provider from being interrupted and the user's deposit from being deadlocked.

On the other hand, when the settlement transaction 123 (FIG. 11: S53) is transmitted during the output condition of the remittance transaction, and the service provider rejects the cancellation processing agreement, the user sets the settlement transaction (output The penalty transaction 124 (FIG. 11: S55) is transmitted according to the condition 2 of 1), and the payment amount (0.7 BTC) set in the output 1 of the settlement transaction is remitted to the address of the user (user).

Also, in the case where the settlement transaction 123 has been transmitted and the cancellation process has not been performed or the agreed cancellation process has been correctly performed, the service provider determines the condition 1 of the settlement transaction (output 1). The payment execution transaction 125 (FIG. 11: S56) is transmitted, and the payment amount (0.7 BTC) set in the output 1 of the payment transaction is remitted to the address of the own (service provider).

釣り The change 2 (0.3 BTC) of the settlement transaction output 2 is remitted to the user's address when the settlement transaction is registered in the blockchain.

In this embodiment, the virtual currency block of the user terminal 1 is adjusted by adjusting the time lock period (T1) of the remittance transaction and the time lock period (T2) of the condition 1 of the settlement transaction (transaction template). Reduce the cost of monitoring the chain. Specifically, by setting the time lock period to T1 <T2, the time lock for the settlement transaction is always set to be longer than the time lock for the transmission transaction. As a result, the service provider must transmit the settlement transaction before the time lock of T1 expires (step S53). Cannot use the settlement transaction (transfer the payment amount of output 1 to its own address).

Therefore, if it can be guaranteed that T2 of condition 1 registered with the transaction template is longer than T1, the user device 1 does not need to monitor the settlement transaction of the service provider device 2 at least until the time T1. Confirm the settlement transaction between T1 and T2. More specifically, the user device 1 connects to the virtual currency network 3 between T1 and T2, or refers to its own distributed ledger, and determines whether or not the settlement transaction is already included in the block. Then, it is confirmed whether or not the settlement transaction is valid (S54). Therefore, by setting the periods of T1 and T2, the period during which the user device is connected to the virtual currency type blockchain is limited, and the need to constantly monitor the blockchain is eliminated.

In this embodiment, it is guaranteed that T1 <T2 using a smart contract. Specifically, when registering the transaction template (Step S15 in FIG. 3 and Step S73 in FIG. 10), the bridging contract sets the time of the transaction template to be shorter than the time lock period (T1) of the remittance transaction. It is determined whether or not the lock period (T2) is long. If T1 <T2 is not satisfied, an error message is transmitted to the service provider device 2. Note that T1 is set in a transaction template input (script) as shown in FIG.

In the embodiment described above, a plurality of output conditions are set in the transaction template (output 1), and the settlement transaction can be used when any of the plurality of output conditions is satisfied. Thus, in the present embodiment, a plurality of block chains can be efficiently linked, and the cancellation of payment agreed between the user and the service provider can be reflected on the virtual currency block chain. Specifically, even if the service provider betrayed the user by reversing the cancellation agreement and sent a settlement transaction using the old transaction template that should have been cancelled, The hash lock of the condition 2 can be released by using the original image of the hash disclosed by the service provider in the processing. That is, the user sends a penalty transaction for remittance of the payment amount specified in the settlement transaction to his / her address before the time lock period of Condition 1 elapses, and recovers the deposit to his / her address. Can be.

As described above, in the present embodiment, the output condition is imposed on the transaction template. Thus, if the service provider agrees to cancel, the penalty transaction of the user according to Condition 2 functions as a penalty. Also, due to the time lock constraint of Condition 1, it is difficult for the service provider to remit the payment amount of the settlement transaction to its own address before the user. Therefore, it becomes difficult for the service provider to take action to betray the user.

In addition, in the present embodiment, the user can cancel the transmitted payment information transaction by performing the cancellation process shown in FIG. Further, by transmitting the original image transaction by the service provider, the user can confirm that the service provider has agreed to cancel.

Further, in this embodiment, the user device transmits a remittance transaction for remitting a predetermined amount of deposit to the multisig address to the network of the virtual currency blockchain, and the first period (T1) elapses in the remittance transaction. Then, an output condition that enables the use of the remittance transaction only by the electronic signature of the user device is set. Thus, in the present embodiment, it is possible to prevent the contact with the service provider from being interrupted and the user's deposit from being deadlocked.

Further, in the present embodiment, the plurality of output conditions of the transaction template include a time lock in which the settlement transaction can be used after the elapse of the second period, and the smart contract uses the second period rather than the first period. Verify if it is long. As a result, in this embodiment, the period during which the user checks the virtual currency type blockchain (virtual currency type network 3 or its own distributed ledger) is limited, and it is necessary to constantly connect to the blockchain and monitor settlement transactions and the like. Operating costs are reduced.

In addition, in the present embodiment, the service provider device 2 does not intervene in the “payment” process, and the entire process from payment verification to service provision is performed on the smart contract blockchain. Thus, in the present embodiment, the service provider device 2 does not need to connect to the smart contract blockchain from verification of payment to provision of the service. That is, since the service provider device 2 does not need to constantly monitor the smart contract type blockchain, the operation cost is reduced.

Further, in the present embodiment, the service provider device 2 does not mediate from the time of payment verification to the provision of the service, so that a series of payment processing is correctly executed due to the failure of the service provider device 2 or the fraud of the service provider. You can avoid situations that are not done.

Further, in the present embodiment, since the bridging contract and the service contract of the smart contract type block chain autonomously execute the provision of the service from the verification of the payment, it is necessary to construct a more transparent and auditable system. Can be.

Further, in the present embodiment, the transaction template is registered in the smart contract type blockchain, and the user device 1 and the service provider device 2 acquire and use the transaction template from their own distributed ledgers. , The block enlargement can be suppressed, and the calculation cost of the block can be reduced.

In the present embodiment, a transaction using a multisig address that requires a user's digital signature and a service provider's digital signature is used. Thus, it is possible to prevent the user device 1 from automatically registering the settlement transaction in the virtual currency type blockchain and using the virtual currency. That is, in the present embodiment, only the service provider device 2 can add its own electronic signature to the payment transaction and register it in the virtual currency blockchain. That is, the service provider device 2 can control the timing of the settlement, and can determine the settlement at an arbitrary timing.

The user device 1 and the service provider device 2 described above include, for example, a CPU (Central Processing Unit), a memory, a storage (HDD: Hard Disk Drive, SSD: Solid State Drive), and a communication device. A general-purpose computer system including an input device and an output device can be used. In this computer system, each function of each device is realized by the CPU executing a predetermined program loaded on the memory. For example, each function of the user device 1 and the service provider device 2 is such that the CPU of the user device 1 is a program for the user device 1 and a service provider device is a program for the service provider device 2. The two CPUs are implemented by executing each of them.

The program for the user device 1 and the program for the service provider device 2 must be stored in a computer-readable recording medium such as an HDD, SSD, USB memory, CD-ROM, DVD-ROM, or MO. Or via a network.

The present invention is not limited to the above embodiment, and various modifications can be made within the scope of the invention. For example, as shown in FIG. 1, the smart contract of the present embodiment includes two types of smart contracts, a bridging contract and a service contract. However, one smart contract may have both functions of a bridging contract and a service contract.

Also, in the present embodiment, the case of one service contract has been described as an example, but there may be a plurality of service contracts. In this case, each service contract implements a different type of service, and the bridging contract calls the service contract corresponding to the service specified in the payment information transaction.

1: User device 11: Transaction generation unit 12: Cancel processing unit 13: Blockchain client 14: Blockchain client for virtual currency 15: Blockchain client for smart contract 2: Service provider device 21: Transaction generation unit 22: Transaction Model generation unit 23: Blockchain client 24: Blockchain client for virtual currency 25: Blockchain client for smart contract 3: Network of virtual currency blockchain 4: Network of smart contract blockchain 41: Bridging contract 42: Service contract

Claims

A settlement system in which a first blockchain and a second blockchain are linked,
A service provider device for transmitting a template information transaction including a transaction template to the first blockchain network;
A user device for transmitting a payment information transaction including an electronic signature generated using the template of the transaction registered in the first block chain and a payment amount to the network of the first block chain;
And a smart contract included in the first blockchain.
The smart contract verifies an electronic signature included in the payment information transaction using the payment amount and the template of the transaction,
The service provider device generates a settlement transaction using the template of the transaction registered in the first blockchain, the electronic signature, and the payment amount, and transmits the transaction to the network of the second blockchain;
A plurality of output conditions are set in the template of the transaction, and the settlement transaction can be used when any of the plurality of output conditions is satisfied.
The settlement system according to claim 1, wherein
The user device transmits a request to cancel the payment information transaction to the service provider device, and another request generated using another transaction template registered in the first block chain by the service provider device. Sending another payment information transaction for cancellation, including the electronic signature and the other payment amount, to the first blockchain network;
The service provider device transmits another template information transaction including the template of the other transaction to the network of the first block chain, and agrees with the other payment information transaction registered in the first block chain. And transmitting an original image transaction including the original image of the hash specified by the hash lock included in the plurality of output conditions to the network of the first block chain.
The settlement system according to claim 1, wherein
The user device transmits a remittance transaction for remitting a predetermined amount of a deposit to a multisig address to a network of the second block chain,
The settlement system according to claim 1, wherein the remittance transaction is set with an output condition that allows the use of the remittance transaction only with the electronic signature of the user device after a first period has elapsed.
The settlement system according to claim 3, wherein
The plurality of output conditions include a time lock in which the settlement transaction becomes available after a second period has elapsed,
The payment system according to claim 1, wherein the smart contract verifies whether a second period is longer than a first period.
A settlement method in which a first block chain and a second block chain are linked,
The service provider device
Sending a template information transaction including a transaction template to the first blockchain network,
The user device
Generating an electronic signature using the template of the transaction registered in the first blockchain,
Sending a payment information transaction including the electronic signature and a payment amount to a network of a first blockchain;
The smart contract included in the first block chain verifies the electronic signature included in the payment information transaction using the payment amount and the template of the transaction,
The service provider device generates a settlement transaction using the template of the transaction registered in the first blockchain, the electronic signature, and the payment amount, and transmits the transaction to the network of the second blockchain;
A plurality of output conditions are set in the template of the transaction, and the settlement transaction can be used when any of the plurality of output conditions is satisfied.
A user device in a settlement system in which a first block chain and a second block chain are linked,
A remittance transaction generator for transmitting a remittance transaction for remitting a predetermined amount of the deposit to the network of the second blockchain;
A payment transaction that generates an electronic signature using a template of a transaction registered in a first blockchain by a service provider device, and transmits a payment information transaction including the electronic signature and a payment amount to a network of the first blockchain. A generating unit,
A plurality of output conditions are set in the template of the transaction. The settlement transaction generated by the service provider device using the template of the transaction, the electronic signature, and the payment amount is the plurality of transactions. A user device that can be used when any of the output conditions is satisfied.
A payment program for causing a computer to function as the user device according to claim 6.