JP2022061223A - Transaction system - Google Patents

Abstract

To provide a transaction system in which a system capable of guaranteeing consistency of data across distributed transactions of a smart contract regarding a transaction on a plurality of block chains can be developed.SOLUTION: In a flow for executing a smart contract, a securities chain 11 (first block chain) which is a block chain including a coordinator 11b (coordinator part) and a participant 11c (first user part), and a settlement chain 12 (second block chain) which is a block chain including a participant 12c (second user part) are provided. On the securities chain 11, a securities token is transferred between users. On the settlement chain, a settlement token is transferred between users. Accordingly, a call of a safe smart contract can be made with atomicity between the securities chain 11 and the settlement chain 12.SELECTED DRAWING: Figure 3

Description

Patent Law Article 30, Paragraph 2 Application Applicable (1) Publisher Datachain Co., Ltd. Publication address https: // github. com / datachainlab / cross Publication date January 30, 2 (2) Publisher Datachain Co., Ltd. Publication address https: // github. com / cosmos / ics / issues / 408 Date of publication April 15, 2nd year (3) Publisher Datachain Co., Ltd. Publication address https://gitcoin. co / issu / cosmos / ics / 408/4212 Date of publication May 1, 2nd year (4) Publisher Datachain Co., Ltd. Publication address https: // github. com / datachainlab / cross-chain-hackathon Date of publication May 3, 2 (5) Publisher Datachain Co., Ltd. Publication address https://datachainlab. Github. io / about_datachain. pdf Publication date June 1, 2nd year (6) Publisher Datachain Co., Ltd. Publication address https: // github. com / datachainlab / public-docs Date of publication October 5, 2nd year of Reiwa

The present invention relates to a trading system.

In order to buy and sell securities using crypto assets, a license for crypto asset exchange business and a license for financial instruments business are required. However, since there are no businesses in Japan that have both of these licenses, securities are currently being bought and sold in legal tender. In other words, securities trading using crypto assets is not currently carried out in Japan.

Ethereum, which is widely known as a platform for building smart contracts using blockchain, has adopted standards such as ERC20 and ERC1400 as tokens. ERC1400 is a standard for security tokens.

In Japan, there is no service provider that buys and sells securities using these tokens, so securities are not bought and sold using tokens, and tokens are only purchased and verified in legal currency.

On the other hand, overseas, platforms for trading securities using these tokens (for example, Polymath, Harbor, Securitize) are prepared, but these are tokens generated by smart contracts implemented on the same chain. Therefore, data of various securities and transactions will be managed on one blockchain, and complexity, processing speed, and connectivity with other networks will be issues. Here, a smart contract is a mechanism for automatically executing a contract on a blockchain.

Japanese Unexamined Patent Publication No. 2020-57863

In order to carry out value transactions, the atomicity of the transactions must be guaranteed. Here, the "atomic property" in a transaction means that the processing of the transaction is either completed or not executed at all. For example, it is unclear whether the completion of a transaction on blockchain A can always be completed on blockchain B, which conducts different value transactions, and if there is a transaction problem on chain B, the transaction on chain A is also possible. I have to stop.

The above points will be described in detail by taking DvP trading of securities as an example. Here, DvP transaction is an abbreviation of Delivery Versus Payment, which mutually conditions the delivery of securities (Delivery) and the payment of payment (Payment) so that the other is not performed unless one is performed. Means. This is a method / mechanism for avoiding the risk of "stray" in securities settlement, in which funds (or securities) are handed over, but the securities (or funds) that are the consideration for the securities are not received from the trading partner. Yes (see the Bank of Japan website).

In DvP transactions using blockchain, a chain on the fund side and a chain on the securities side are provided, and even if the transaction is completed in the chain on the fund side, can the transaction in the chain on the securities side be completed? It is unknown.

Here, a 2-way-peg method and an HTLC method (Hashed Time-Locked Contract) are being studied as a method for realizing information / value exchange between different blockchains. The 2way-peg method is a method in which the receiving chain verifies evidence of lock or burn of the sending chain of tokens and then mint the tokens on the receiving chain, which can be reversed. .. In this method, securities tokens are generated on the blockchain on the fund side, but on the fund side, the rules on the securities side (for example, whether the number of transferees has reached the upper limit, whether the transfer destination user has already been KYC, etc.) are checked. Can not. Therefore, if you check again on the securities side, it may compete with other transactions and you may not be able to trade. In addition, the HTLC method allows the receiving user to obtain the token by publishing the hash preimage, and the receiving user does not publish the hash preimage within the deadline and times out. In this case, it is a method that allows the user on the remittance side to recover the token. In this method, if the securities side rules (for example, the number of transferees has reached the upper limit and the securities cannot be transferred) are caught at the timing of releasing the pre-image, the payment will be completed, but the securities will not be delivered. There is a risk of incomplete "detachment".

(Background to the creation of the present invention)
It is known that a blockchain alone lacks the ability to interoperate with other blockchains. The relay method is known as a connection method on a cross chain that connects block chains to each other. Cross-chain means straddling different chains.

ICS (Interchain Standards) is designed by Cosmos to standardize the protocol stock needed to achieve this. Here, blockchain technology is currently in widespread use, and there are various blockchains such as Bitcoin blockchain and Ethereum blockchain. Against this background, ICS was conceived as a project to connect blockchains in order to solve issues such as blockchain speed, scalability, and interoperability.

As an application protocol using the relay method, protocols for moving and exchanging tokens using the Peg and Escrow methods are being discussed in various communities, but the tokens and states targeted by many methods are Fungible tokens (that is, alternatives). It can be expressed by a simple State such as (possible token). In Cosmos, 2way-peg of Fungible token is proposed in ics-020 as an application protocol.

Therefore, an object of the present invention is to make it possible to develop a system capable of guaranteeing data integrity in distributed transactions of smart contracts on a plurality of blockchains. In order to achieve this purpose, the present inventors have developed a framework called Cross Framework, and considered that the following elements (1) and (2) are necessary.
(1) Design a decentralized consensus protocol for the locking mechanism required for smart contracts and whether or not commits are possible.
(2) Build a mechanism that allows developers to transparently meet the requirements that contracts should meet in order to enable distributed consensus protocols.

In addition, the transaction that executes such a smart contract corresponds to the above-mentioned Cross-chain Transaction. Cross-chain Transaction is synonymous with distributed transaction performed between multiple different blockchains. Therefore, it is necessary to guarantee the reliability of transaction processing as defined by the ACID property in Cross-chain Transaction as well as general distributed transaction. Here, ACID properties are a combination of the acronyms "Atomicity", "Consistency", "Isolation", and "Durability". Since it is common technical knowledge, detailed explanation is omitted.

A smart contract is a program that can be executed on the Blockchain. They have a state, and the functions provided in many cases are exposed as functions and can be executed according to the specified conditions. It is executed by a user-generated transaction and updates the state. In the Cross Framework, smart contracts are provided by implementing a Contract Handler so that developers can dynamically call contracts on request. Each function is defined as a contract function. Cross-chain smart contract refers to a smart contract that contains calls to the contract functions of this multiple chain.

Then, I considered the following Cross Framework that enables support for the above design. Cross Framework is a framework that enables the development of Cross-chain smart contracts and the support of Cross-chain Transactions for them. The framework consists of a Cross Module to support Cross-chain Transaction and a Contract Module that provides smart contracts. The Cross Module is a module required to realize Cross-chain Transaction, and consists of a Cross Handler that implements a protocol for atomic commit with other chains via the IBC module and a store that holds their state. Will be done. The Contract Module consists of a Contract Handler that provides smart contracts and a State Store that holds those states.

Next, the above-mentioned Cross Framework design procedure will be described by dividing it into (1) Cross-chain smart contract, (2) Cross-chain Transaction, and (3) Atomic commit Protocol.

(1) Cross-chain smart contract
The Cross-chain smart contract will be described in terms of (1-1) to (1-2).
(1-1) Contract Handler and State Store
Multiple contract functions can be implemented in Contract Handler. Each contract function is given a state store for managing the state of smart contracts. Each function makes a deterministic state transition according to the call argument and the written logic, and persists that state in this state store. The state store supports general key-value store operations such as Get (K), Set (K, V), Delete (K). Get (K) means "return the value corresponding to the key specified by K". Set (K, V) means "set the value specified by V for the key specified by K". Delete (K) means "delete the value corresponding to the key specified by K". When executing contract functions sequentially in a single chain, the changes made by the transaction may be reflected in the store at each of these operations or after the function is executed, but the contract functions processed by the transaction are multiple chains. If it is distributed to, it is necessary to perform the state transition of all contracts atomically. Execution of at least one contract function needs to transition to the Prepare state, depending on the atomic commit protocol used. That is, since such contracts may conflict with other parallel transactions, the state store needs a mechanism to maintain the serializability of transactions. The Cross Framework provides a simple store that acquires locks for each change operation as an implementation of the default state store. This store can be configured to acquire the following locks for each change operation.

(1-2) Cross-chain calls
In each chain, the contract function defined in the Contract Handler can call the contract function of another chain, which is defined as Cross-chain calls. This makes it possible to develop smart contracts that include more complex protocols such as value transfer between chains, as well as being able to execute multiple functions atomically in Cross-chain Transaction.

(2) Cross-chain Transaction
Cross-chain Transaction will be described in terms of (2-1) to (2-4).
(2-1) Cross-chain Transaction is a distributed transaction that can be executed between chains connected by IBC channel. The Cross Framework supports multiple atomic commit protocols to ensure data integrity in transactions, and provides a state store that implements a locking mechanism to achieve it. A transaction is started when a chain that receives a request from a user verifies its contents and sends a packet containing a contract call request to the specified chain. A chain that receives a user's request to start a transaction is defined as an Initiator chain. When the Initiator chain receives the request, it executes the atomic commit flow according to the specified format. For example, if you select a two-tier commit as the atomic commit, the Initiator chain acts as the coordinator of the two-tier commit, calls the contract function of each chain included in the user's request, manages the result, and finally. It decides whether or not to commit, and each party chain that receives the decision commits or aborts.

(2-2) Creation and verification of Cross-chain transaction
In order to start the cross-chain transaction, the user creates an MsgInitiate with the following elements (i) to (iv) and submits it to the Initiator chain.
(I) Type
This is the type of commit flow. Details of each commit flow will be described later.
(Ii) Nonce
This is the nonce value.
(Iii) Timeout
It is the upper limit of Block height or Block time that a transaction can capture.
(Iv) Contract transaction This is the call information of each contract, and is an array of structures consisting of the following (iv-1) to (iv-6).
(Iv-1) ChainID
An ID that indicates the chain that processes this contract transaction.
(Iv-2) Signers
An array of accounts that must be approved to create a transaction for this contract.
(Iv-3) Call Info
Call information including contract identifiers, function names, arguments, etc. The format depends on the specifications of the Contract handler.
(Iv-4) State Constraint
It means to put a constraint on the state referenced by this contract and the state after update. However, this is optional and can be omitted.
(Iv-5) Return Value
It is the return value of the execution of this contract. However, this is optional and can be omitted.
(Iv-6) Links
It is the result of another contract call that is referenced when this contract is executed. However, this is optional and can be omitted.

Here, an account is a concept that defines a person who executes a transaction. The appropriateness of the account is verified according to the contents of the transaction. Transaction validation logic, account authorization and its identifier specifications vary by blockchain and DLT.
Cross Framework requires approval of all accounts specified by Signers ((iv-2) above) at the beginning of a transaction, but the approval method and verification method of each account use arbitrary logic. It is possible to implement it, and it is recommended to select a method suitable for the blockchain and DLT to be used. For example, there is an existing implementation that uses the signature verification of auth / StdTx of Cosmos-SDK.

The Initiator chain that receives the MsgInitiate must confirm that this Cross-chain transaction has been approved by all accounts that require approval. There are several patterns in this verification flow as shown below.
Pattern 1: If the account has a key, submit the signature by each account together with the submission of MsgInitiate to the Initiator chain to verify it.
Pattern 2: If the account does not have a key, each account asynchronously approves the ID indicating the transaction issued by the submission of MsgInitiate submitted on the Initiator chain.
Pattern 3: If the account does not have the key and the Initiator chain cannot be accessed, each account approves the chain including the Contract Module, and the result is verified on the Initiator chain via the packet. This is a good flow for authorized chains.
After verifying by any of the above methods, the Initiator chain starts the flow of performing atomic commit according to Type. Sends a packet containing the transaction of each contract specified in the contract transaction to the Contract handler of each chain. The types of commit flows and the details of each will be described in the chapter (3) Atomic commit protocol described later. Regardless of the type of commit flow, if the function of each contract declared in MsgInitiate is executed successfully, and if there is a constraint on the run-time state such as State Constraint, all transactions are committed only if they are satisfied. It is guaranteed to be done.

(2-3) State constraints and Simulation
State constraints are functions for constraining the pre-state, post-state, or both when executing a transaction. This feature is useful when you need strict state transitions when executing a contract function. When requesting a transaction to execute a contract function from an application, it can be more strictly guaranteed to execute the process only once.
Simulation is a function that can execute a contract without generating a transaction. It is possible to use this to generate constraints to be specified by State constraints. By specifying StateConstraintType at the time of Simulate request, the state of the state store that can be referenced as a constraint is returned. The user can apply a constraint using the state at the time of simulation to the transaction by specifying this in the StateConstraint of the contract transaction when creating MsgInitiate.

(2-4) Link and Cross-chain calls
In order to call the contract function outside the other Contract handler as introduced in Cross-chain calls above, it is necessary to consider the following elements a to c.
The contract functions of each Contract Handler may be executed in parallel on their respective chains.
b. Execution of an external contract function must be atomic with the execution of the calling function.
c. The return value of executing an external contract function can be referenced by the calling function.
Of these, a and b are realized by the atomic commit protocol. Link is a function for satisfying the element of c above.
Link has the following structure.
type Link struct {
SrcIndex uint8
}
SrcIndex specifies the index of the contract transaction that indicates the transaction that handles the execution of the called contract function.
Upon receiving MsgInitiate, the Initiator chain resolves the Link information of each element of the contract transaction as an object ConstantValueObject containing the ChainID and return value of the called contract function, and the external call in the contract function that refers to the Link is this ConstantValueObject. Is replaced by.
Then, it is executed in the following steps 1 to 3.
Step 1: The function that references the external contract of the Contract Handler needs to set the ChainID indicating the referenced chain in addition to the call information. This is implemented by Channel ID, Interchain DNS domain name, etc.
type ChainID interface {
Equal (ChainID) bool
}
Step 2: The Initiator chain resolves as an object ConstantValueObject containing the ChainID and return value of the called contract function based on the Links information of each element of the contract transaction.
type ConstantValueObject struct {
ChainID ChainID
Value [] byte
}
Step 3: The Initiator chain sets the contract transaction as a coordinator, the ConstantValueObject of step 2, and the call information of the reference destination as packet data according to the atomic commit flow, and sends it to the Contract handler of each chain.
Step 4: The contract handler of the chain executes the contract function according to the call information of the received packet. When calling an external contract function in a function, it is compared with the ChainID and call information of the reference destination in the program, and if they match, the Value of ConstantValueObject is returned. If they do not match, the processing of the function fails.

(3) Atomic commit protocol The atomic commit protocol is a protocol that enables a set of a plurality of operations to be executed as one process, and for example, two-layer commit and three-layer commit are used as typical ones. In Cross Framework, two types of protocols, Simple commit protocol and Two-phase commit protocol, can be used. The Simple commit protocol is limited to two parties. Two-phase commit can support more than two parties.

The two-phase commit protocol and the simple commit protocol will be described in detail in (3-1) and (3-2) below, respectively.
(3-1) Two-phase commit protocol
In two-layer commit (2PC), one chain is used as a coordinator, and a group of chains that execute and commit other contract functions is used as a party to commit or reach an aborted state in the following flow. The coordinator requests the party shippants to prepare for the commit, and if all the party shippants succeed, the coordinator issues a commit request to all the party shippants. If even one person fails to prepare for the commit, an abort request is made to all party sipants.

The commit flow will be described with reference to FIG. In the figure, X is the coordinator, A, B, and C are the parties, and the arrows are the direction of the request for each step of the flow.
Step 1: Initiate step
The user submits a transaction start request "MsgInitiate" to the Initiator chain. The Initiator chain sends a packet "PacketPrepare" requesting "Prepare" to the party chain containing the function of the contract specified in "MsgInitiate" as the coordinator of the two-tier commit. Step 2: Prepare step
Upon receiving the "PacketPrepare", each party chain executes the contract function specified in the contract transaction described in "(2-2) Creating and verifying the Cross-chain transaction" above (however, at this time). No actual commit was made). If the execution is successful, save the change operation to the state store and acquire the lock to the change target. Since the details of this locking mechanism have been described in "(1-1) Contract Handler and State Store" above, the description will not be repeated. Finally, "PREPARE_RESULT_OK" indicating success is set in "Status" of the packet "PacketPrepareAcknowledgement" and returned.
On the other hand, if the execution fails, the change operation is discarded, and "PREPARE_RESULT_FAILED" indicating the failure is set in "Status" of the packet "PacketPrepareAcknowledgement" and returned.
Step 3: Confirm step
The coordinator chain receives the ACK “PacketPrepareAcknowledgement” transmitted by each party chain in the Prepare step (step 2). For each ACK process, the following state transitions 1 to 3 are performed.
1. Waiting for the next ACK
2. If the "Status" of the received ACK is "PREPARE_RESULT_OK" and there is an unreceived ACK, transition to 1. When all are received, set "COMMIT" in "Status" of "PacketCommit" to send a commit request to each party chain, and proceed to the Commit step of step 4.
3. If the "Status" of the received ACK is "PREPARE_RESULT_FAILED", set "ABORT" to "Status" of "PacketCommit" to make an abort request to each party chain, and send it. Go to step Step 4: Commit step
When a commit request is made, each party chain applies the change operation saved in the Prepare step (step 2) to the state store, removes the lock, and sends a “PacketCommitAcknowledgement” to the coordinator chain to indicate that it has been completed. Send. When there is an abort request, each party chain deletes the change operation and lock saved in the Prepare step (step 2) and sends a "PacketCommitAcknowledgement" indicating completion to the coordinator chain.

(3-2) Simple commit protocol
This Simple commit protocol is an atomic commit protocol that has restrictions on the number of parties. Unlike two-tier commits, parties are limited to two, and one of them must act as a coordinator.
The commit flow will be described with reference to FIG.
Step 1: Initiate
The user submits “MsgInitiate” to the Initiator chain to initiate a Cross-chain transaction. In this simple commit protocol flow, the Initiator chain doubles as a coordinator and a party sipant.
Step 2: Prepare (A)
A prepares the contract function specified by "MsgInitiate". If the execution is successful, save the change operation to the state store and acquire the lock to the change target. Since the details of this locking mechanism have been described in "(1-1) Contract Handler and State Store" above, the description will not be repeated. After that, a packet "PacketDataCall" containing the call information of B's contract function is created and sent to the channel with B. If execution fails, the processing of this transaction is aborted and terminated.
Step 3: Commit (B)
B receives a “PacketDataCall” and executes the specified contract function. If the execution is successful, commit. After that, set "COMMIT_OK" as "Status" in "PacketCallAcknowledgement" and send to the channel with A. If execution fails, abort. After that, set "COMMIT_FAILED" as "Status" in "PacketCallAcknowledgement" and send it to the Channel with A.
Step 4: Commit (A)
A receives "PacketCallAcknowledgement" and confirms its "Status". If "Status" is "COMMIT_OK", A applies the change operation saved at the time of Prepare to the state store and removes the lock. If "Status" is "COMMIT_FAILED", A discards the change operation saved at the time of Prepare and deletes the lock.

According to the present invention, unlike the 2-way-peg, for example, the rules on the securities side cannot be checked on the fund side, so when the securities token side is checked again, the transaction competes with other transactions and the transaction is unsuccessful. You can avoid problems such as.

This is the commit flow. This is the commit flow. This is a flow for executing a smart contract (first embodiment). It is a schematic diagram of a simulated code (first half). It is a schematic diagram of a simulated code (second half). It is a schematic diagram of a simulated code. This is a flow for executing a smart contract (third embodiment).

(First Embodiment)
An embodiment of the transaction system of the present invention based on the design concept described in the above solution will be described with reference to FIG. FIG. 3 is a sequence flow of securities transactions (in other words, a flow of executing a smart contract).

The transaction system of the present embodiment includes a securities chain 11 as a blockchain (corresponding to a first blockchain) and a settlement chain 12 as a blockchain (corresponding to a second blockchain). The coordinator 11b (corresponding to the coordinator section) and the party shippant 11c (corresponding to the first user section) are arranged on the securities chain 11 side, and the party shippant 12c (corresponding to the second user section) is the settlement chain 12 Arranged on the side. In this embodiment, 100 securities tokens are transferred from User A to User B on the securities chain between two users (hereinafter referred to as Users A and B), and from User B to User A on the payment chain. The instruction is to transfer 100,000 yen worth of settlement tokens. At that time, a framework capable of calling a secure smart contract having atomicity between the securities chain 11 and the settlement chain 12 is provided.

The coordinator 11b, the party shippant 11c, the party shippant 12c, and the relay 13 are each realized by a computer, and the coordinator 11b, the party shippant 11c, and the party shippant 12c form a distributed network. The coordinator 11b and the party sipants 11c, 12c communicate with each other via the relay 13. Users A and B correspond to the party shippant 11c and the party shippant 12c, respectively.

The coordinator section 11b includes an IBC Module and a Cross Module as a layered structure.

The party sipant 11c has an IBC Module, a Cross Module, and a Contract Module as a layered structure. A securities token issuance contract and a transfer contract are defined in the Contract Handler that constitutes the Contract Module on the securities chain 11 side. The simulated code is divided into the first half and the second half and shown in FIGS. 4A and 4B, respectively. Like the party shippant 11c, the party shippant 12c includes an IBC Module, a Cross Module, and a Contract Module as a layered structure. A contract for issuing a payment token and a transfer contract are defined in the Contract Handler that constitutes the Contract Module on the payment chain 12 side. The simulated code is shown in FIG.

Assuming that the smart contract is executed, the following processing is performed. A contract function called to transfer a securities token from user A to user B on the securities chain 11 (transfer in FIG. 4A), and to transfer a payment token from user B to user A on the payment chain 12. A transaction (MsgInitiate) having a contract function (transfer in FIG. 5) called to is created and sent to the coordinator 11b. The following sequence flow is executed on the premise that the above processing is executed. This sequence flow can be divided into two phases, mainly a "preparation phase" and a "commit phase".

The coordinator 11b confirms the received transaction (MsgInitiate) and verifies that there is no problem in the transaction format. (Step S1). If there is even one problem, the transaction is immediately discarded and the process ends. If there is no problem, the process proceeds to step S2.

The coordinator 11b creates a packet (PacketPrepare) based on the verified transaction (MsgInitiate) and sends it to the party shippant 11c of the securities chain 11 and the party shippant 12c of the settlement chain 12 via the relay 13 (step S2, Step S3). This packet (PacketPrepare) corresponds to the "first packet" according to claim 1.

The party 11c of the securities chain 11 confirms the packet received via the relay 13 and verifies whether or not 100 securities tokens can be transferred from the user A to the user B (step). S4). Specifically, execute the contract function specified in the received packet (PacketPrepare) (note that it is not actually committed at this time).

If the execution fails, the change operation is discarded, and for the coordinator 11b of the securities chain 11, "PREPARE_RESULT_FAILED" is set in "Status" of the packet (PacketPrepareAcknowledgement) (in other words, "Status" cannot be executed. (Set) and transmitted via the relay 13 (steps S6 and S10). The packet (PacketPrepareAcknowledgement) transmitted here corresponds to the "third packet" according to claim 1. If the execution is successful, the change operation is saved in its own state store and the lock to the change target is acquired (step S5). After the lock is acquired, set "PREPARE_RESULT_OK" to "Status" of the packet (PacketPrepareAcknowledgement) for the coordinator 11b of the securities chain 11 (in other words, set "Status" to be executable). Is transmitted via (steps S6 and S10). The packet (PacketPrepareAcknowledgement) transmitted here corresponds to the "second packet" according to claim 1.

Can the party 12c of the payment chain 12 confirm the packet (Packet Prepare) received via the relay 13 and transfer the payment token for 100,000 yen from the user B to the user A as the consideration for the securities token? Verify (step S7). Specifically, execute the contract function specified in the received packet (PacketPrepare) (note that it is not actually committed at this time).

If the execution fails, the change operation is discarded and "PREPARE_RESULT_FAILED" is set in "Status" of the packet (PacketPrepareAcknowledgement) for the coordinator 11b of the securities chain 11 (in other words, "Status" cannot be executed. (Set) and transmitted via the relay 13 (steps S9 and S10). The packet (PacketPrepareAcknowledgement) transmitted here corresponds to the "fifth packet" according to claim 1. If the execution is successful, the change operation is saved in its own state store and the lock to the change target is acquired (step S8). After acquiring the lock, set "PREPARE_RESULT_OK" to "Status" of the packet (PacketPrepareAcknowledgement) for the coordinator 11b of the securities chain 11 (in other words, set "Status" to be executable). Is transmitted via (steps S9 and S10). The packet (PacketPrepareAcknowledgement) transmitted here corresponds to the "fourth packet" according to claim 1.

By the above-mentioned processing, the coordinator 11b receives the packet (PacketPrepareAcknowledgement) from each party (in this embodiment, the parties 11c and 12c).

The coordinator 11b confirms the received packet (PacketPrepareAcknowledgement) (step S11), and performs the following processing according to the “Status”. That is, if even one packet of "Status = PREPARE_RESULT_FAILED" is received, the process proceeds to step S12 in order to make an abort request. When a packet of "Status = PREPARE_RESULT_OK" is received from all the parties (parts 11c and 12c in this embodiment), the process proceeds to step S12 to make a commit request.

The commit phase starts from step S12. In step S12, when making an abort request, a packet (PacketCommit) is created, "Status" is set to "ABORT", and all parties (in this embodiment, parties 11c and 12c). Multicast via the relay 13 (steps S13, S14, S16). The packet for making this abort request corresponds to the "seventh packet" according to claim 1. In step S12, when making a commit request, a packet (PacketCommit) is created, "Status" is set to "COMMIT", and all parties (in this embodiment, parties 11c and 12c). Multicast via relay 13 (steps S13, S14, S16). The packet for making this commit request corresponds to the "sixth packet" according to claim 1.

In step S14, when the status of the received packet (PacketCommit) is “COMMIT”, the party 11c applies the change operation saved in the preparation phase to the state store, deletes the lock, and causes the coordinator 11b. A packet (PacketCommitAcknowledgement) indicating completion is transmitted (steps S15 and S18).
The packet (PacketCommitAcknowledgement) transmitted at the time of this commit corresponds to the "eighth packet" according to claim 1.

On the other hand, when the “Status” of the received packet is “ABORT”, the change operation and the lock saved in the preparation phase are deleted, and a packet (PacketCommitAcknowledgement) indicating completion is transmitted to the coordinator 11b (step S15, S18). The packet (PacketCommitAcknowledgement) transmitted at the time of this abort corresponds to the "nineth packet" according to claim 1.
Since the processes performed in steps S16 and S17 are the same as the processes performed in steps S14 and S15, respectively, detailed description thereof will be omitted.

As described above, according to the present embodiment, the feasibility is inquired to each of the party shippant 11c of the securities chain 11 and the party shippant 12c of the settlement chain 12, and the feasibility can be confirmed by both parties. Only commit the result of calling the contract function in multiple chains. Therefore, unlike 2way-peg, the funds side cannot check the rules on the securities side (for example, whether the number of transferees has reached the upper limit, whether the transferee user has already completed KYC, etc.), so the securities chain side again. When checked, it is possible to avoid problems such as competition with other transactions and unsuccessful transactions.

(Second Embodiment)
The process described in the first embodiment described above can also be used for other transactions (for example, a testamentary trust) that require the atomicity of the transaction. In this case, the securities chain 11 can be read as an inheritance chain (corresponding to the first block chain), and the settlement chain 12 can be read as an asset chain (second block chain), and can be applied to the transaction of a testamentary trust.

The decedent presents a will or asset to the trust company, which is registered as a smart contract on the inheritance chain. In the past, when the decedent died, the heir contacted the trust company, and the trust company had to inquire of the asset management company about the assets to see if the will could be executed.

In this embodiment, when inquiring to the asset chain whether it is possible to move the asset based on the will registered on the inheritance chain, the atomicity is guaranteed, so unlike the case of using 2way-peg, it is a heritage. It does not meet the conditions of division, and there is no need to check that it is impossible to divide the heritage by covering it. In addition, the trust company can confirm the execution results of both the execution of the will and the execution of the asset split.

(Third Embodiment)
A third embodiment of the present invention will be described with reference to the flowchart of FIG. The present embodiment is different from the first embodiment in that the processing performed by the coordinator 11b and the party sipant 11c is performed by the combined unit 11bc. As a result, one party can skip the commit preparation. Further, as in the first embodiment, the processing of the present embodiment will be described by taking securities transactions as an example. However, the process described in this embodiment can also be used for other transactions (for example, a testamentary trust) that require the atomicity of the transaction. Since the details of this point are described in the second embodiment, the description thereof will be omitted. The trading system of the present embodiment is designed based on a commit protocol (Simple Commit protocol) that can omit the commit preparation of one party. This commit method differs from the two-layer commit of the first embodiment in that the number of parties is limited to two. In addition, one of the party sipants will play the role of coordinator.

The combined unit 11bc is realized by a computer. The combined unit 11bc and the party 12c form a distributed network. The dual-purpose unit 11bc and the party sipant 12c communicate with each other via the relay 13.

Since the process performed before step S101 is the same as that of the first embodiment, the description will not be repeated. In step S101, the combined unit 11bc confirms the received transaction (MsgInitiate) and verifies that there is no problem in the transaction format. If there is even one problem, the transaction is immediately discarded and the process ends.

Here, in the present embodiment, since the dual-purpose unit 11bc also serves as a coordinator and a party shippant, it is possible to transfer 100 securities tokens from user A to user B at this timing. (Step S102).

Specifically, execute the contract function specified in the received transaction (MsgInitiate) (note that it is not actually committed at this time). If execution fails, the processing of this transaction is aborted and terminated.

If the execution is successful, the dual-purpose unit 11bc saves the change operation in its own state store as a party shippant and acquires a lock on the change target (step S103). After the lock can be acquired, the call information of the contract function of the payment chain is included (in this embodiment, the contract function called to transfer the payment token for 100,000 yen on the payment chain from user B to user A). A packet (PacketDataCall) is created and transmitted to the party 12C (steps S104 and S105). This packet corresponds to the "first packet" according to claim 5.

In step S106, the party 12c receives the packet (PacketDataCall) and executes the designated contract function. If the execution is successful, commit is performed (step S107). After that, "COMMIT_OK" is set in "Status" of the packet (PacketCallAcknowledgement) and transmitted to the dual-purpose unit 11bc (steps S108 and S109). The packet (PacketCallAcknowledgement) transmitted to the dual-purpose unit 11bc at the time of this commit corresponds to the "second packet" according to claim 5. If execution fails, abort. After that, "COMMIT_FAILED" is set in "Status" of the packet (PacketCallAcknowledgement) and transmitted to the dual-purpose unit 11bc (steps S108 and S109). The packet (PacketCallAcknowledgement) transmitted to the dual-purpose unit 11bc at the time of this abort corresponds to the "third packet" according to claim 5.

The dual-purpose unit 11bc confirms the packet (PacketCallAcknowledgement) received from the party shippant 12c as a process performed by the party shippant, and commits if "Status" is COMMIT_OK (applies the saved change operation to the state store). Remove the lock). If “Status” is COMMIT_FAILED, abort (remove the saved change operation and lock).

As described above, according to the present embodiment, the atomicity of transactions is guaranteed in the securities chain 11 and the settlement chain 12. Therefore, unlike 2way-peg, the rules on the securities side (for example, limited to private placements) cannot be checked on the fund side, so when the securities token side is checked again, the transaction will compete with other transactions and the transaction will be unsuccessful. It is possible to avoid problems such as becoming.

(Modified example of the third embodiment)
In the present embodiment, the party sipant on the securities chain 11 side is in charge of the role as a coordinator, but the party sipant 12c on the settlement chain 12 side may be in charge of the role as a coordinator. When this embodiment is applied to a use case of a testamentary trust, a dual-purpose unit 11bc can be mounted on the inheritance chain side and a party sipant 12c can be mounted on the asset chain side. However, the party sipant 12c may be mounted on the inheritance chain side, and the combined portion 11bc may be mounted on the asset chain side.

11 Securities Chain, Inheritance Chain 11b Coordinator 11c, 12c Party Shipant 12 Settlement Chain, Asset Chain 13 Relayer

Claims (8)

A trading system for atomically executing smart contracts related to transactions between the first blockchain and the second blockchain.
The coordinator section and the first user section on the first blockchain side,
The second user part on the second blockchain side and
Have,
The coordinator unit transmits the first packet created based on a predetermined transaction to which the contract function is specified to the first and second user units.
When the first user unit succeeds in executing the contract function of the first packet received from the coordinator unit, the first user unit acquires the storage of the change operation in its own state store and the lock to the change target. , The second packet with the status made executable is sent to the coordinator section, and if the execution fails, the change operation to its own state store is discarded and the status is made unexecutable. To the coordinator section
When the second user unit succeeds in executing the contract function of the first packet received from the coordinator unit, the second user unit acquires the storage of the change operation in its own state store and the lock to the change target. , The fourth packet that made the status executable is sent to the coordinator section, and if the execution fails, the change operation to its own state store is discarded and the status is made infeasible. To the coordinator section
Based on the executionability verification results of the packets received from the first and second user units, the coordinator unit sends a sixth packet to the sixth packet in order to make a commit request when the status of all the packets is executable. It is transmitted to the first and second user units, and if the status of at least one packet is infeasible, a seventh packet is transmitted to the first and second user units in order to make an abort request.
When the first and second user units receive the sixth packet from the coordinator unit, the first and second user units apply the change operation saved in advance to the state store, remove the lock, and send the eighth packet to the coordinator. A trading system characterized in that when the 7th packet is transmitted to the coordinator unit and the 7th packet is received from the coordinator unit, the change operation and the lock stored in advance are deleted and the 9th packet is transmitted to the coordinator unit. .. The transaction system according to claim 1, further comprising a relay that mediates communication between the coordinator unit and the first and second user units. The transaction system according to claim 1 or 2, wherein the first blockchain is a securities chain, and the second blockchain is a settlement chain. The trading system according to claim 1 or 2, wherein the first blockchain is an inheritance chain, and the second blockchain is an asset chain. A trading system for atomically executing smart contracts related to transactions between the first blockchain and the second blockchain.
A coordinator section and a first user section provided on the first blockchain side, and a dual-purpose section that also serves as a first user section.
The second user part on the second blockchain side and
Have,
When the predetermined transaction to which the contract function is specified can be realized, the dual-purpose part acquires the storage of the change operation in its own state store and the lock to the change target as the first user part. The first packet is transmitted to the second user unit, and if it cannot be realized, the process is terminated and the process is terminated.
The second user unit executes the contract function based on the first packet received from the combined unit, commits if the execution is successful, and executes the second packet whose status is made executable. It is transmitted to the dual-purpose unit, and if execution fails, it is aborted, and a third packet whose status is disabled is transmitted to the dual-purpose unit.
When the combined unit receives the second packet from the second user unit, the combined unit applies the change operation previously saved as the first user unit to the state store, deletes the lock, and displays the lock. A transaction system characterized in that when the third packet is received from the second user unit, the change operation previously stored as the first user unit is discarded and the lock is deleted. The transaction system according to claim 5, further comprising a relay that mediates communication between the combined unit and the second user unit. The trading system according to claim 5 or 6, wherein the first block chain is one of a securities chain and a settlement chain, and the second block chain is the other chain. The trading system according to claim 5 or 6, wherein the first block chain is one of an inheritance chain and an asset chain, and the second block chain is the other chain.

Images