JP2020177372A - System for transferring digital assets between block chains - Google Patents

Abstract

To manage whether or not to allow transfer of crypto assets between different BCs that can trade any crypto assets that do not support UTXO according to certain control rules.SOLUTION: An system for transferring digital assets between BCs comprises: an owner terminal UT [i] that transmits a request to move a first digital asset VC [i] owned by an owner on a first BC to a first address owned by the owner on a second BC by transferring it between the BCs; and a federation Fed that is formed by two or more approver terminals Fm [i] for making a decision based on majority decisions and is configured to renew a membership by mutual election between the approver terminals based on a first criterion. The approver terminal, when detecting the request, causes the federation to initiate the majority decisions, and if it is determined that the transfer between the BCs is permitted based on a second criterion, executes the transfer between the BCs of a second digital asset WC [i] having the economic value equivalent to that of the first digital asset. The second digital asset is newly issued as a unique token that can be traded using a general-purpose protocol.SELECTED DRAWING: Figure 1

Description

The disclosure relates to the transfer of digital assets between blockchains, and in particular to the process of transferring a wide variety of digital assets between public chains and sidechains under predetermined control rules.

A side chain is a block chain that is attached as a side chain to an existing public chain such as a Bitcoin block chain. Hereinafter, for convenience of explanation, the public chain side of Bitcoin or the like will be referred to as a parent BC, and the side chain side serving as a side chain will be referred to as a side chain BC. As an example of the interaction between the parent BC and the side chain BC, bidirectional pegs transfer crypto assets on the parent BC to the side chain BC at a fixed or deterministic exchange rate. After that, it refers to the inter-chain transfer mechanism for returning to the original parent BC. Therefore, in the side chain BC capable of bidirectional pegging, the cryptographic asset can be imported from the parent BC and further returned to the original parent BC (see Patent Document 1 below).

By the way, when executing the peg-in process to the side chain BC side, it is necessary to execute various processes in association with the consensus rule application process, and these processes include transaction approval and export on the parent BC side. Includes locking and unlocking of crypto assets to be done. However, in the process of executing these processes, it is conceivable that an unspecified node whose reliability is not guaranteed can be involved in the consensus rule application process.

Therefore, in the following Patent Document 2 and Non-Patent Document 1, the "Federated Peg method" is a mechanism in which a coalition of a plurality of approvers is organized and this "coalition of approvers" has exclusive authority such as transaction approval. It is disclosed. In this method, a series of processes including transaction approval and lock processing of crypto assets to be exported are aggregated in the approval mechanism realized by the above-mentioned "coalition of approvers", and unspecified in BCN (Blockchain Network). Do not involve the node. In this way, in the "Federated Peg method", unspecified nodes whose reliability is not guaranteed cannot be involved in the consensus rule application process, and the computational complexity of other nodes and the amount of computation over the entire block chain are reduced. Can be done.

Special Table 2018-533103 Publication of US application US2016 / 0330034

Block Stream White Paper "Enabling Blockchain Innovations with Pegged Sidechains", Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timon, and Pieter Wuille,

In the implementation example of the existing side chain technology, there is only an implementation example in which a bitcoin corresponding to UTXO (Unspent Transaction Output) is used as a parent BC to execute bidirectional pegs with the side chain BC. In other words, the two-way peg mechanism is difficult to implement on the parent BC side in the blockchain that trades Bitcoin that does not support UTXO. Similarly, the two-way peg mechanism is difficult to implement in any blockchain that can trade any Alt Coin or any token other than Bitcoin.

Another problem with bi-directional peckable sidechains is the type of crypto assets transferred between the chains by bi-directional pegs or the source of the peg-in / out request is legal, ideological and strategic. It may not be desirable from the above point of view. To address this issue, it is necessary to manage whether or not a particular user should tolerate attempts to peg in / peg out a particular cryptocurrency according to certain control rules. Furthermore, in order to realize management based on the above control rules, whether or not the type (currency type) of the crypto asset subject to peg in / out is an acceptable type of crypto asset, or a request for peg in / out. It is also necessary to have a mechanism to specifically determine whether or not the original is an acceptable user.

In view of the above problems, in some embodiments of the present invention, it is possible to realize transfer of cryptocurrency assets to and from a blockchain capable of trading any cryptocurrency assets other than Bitcoin or Bitcoin that does not support UTXO. The purpose is to get a mechanism. Further, in view of the above problems, in some embodiments of the present invention, whether or not a specific user should allow an attempt to transfer a specific cryptocurrency asset between block chains is determined according to a certain control rule. The purpose is to obtain a mechanism that can be managed.

(1) The system according to some embodiments of the present invention blocks digital assets including one or more types of electromagnetic records capable of circulating asset values by transmitting and receiving digital information via remittance transactions. To transfer between chains
An owner terminal that sends a request to transfer the first digital asset owned by the owner on the first block chain to the first address owned by the owner on the second block chain by inter-block chain transfer.
An alliance formed by two or more approver terminals that make majority decisions and configured to renew membership by mutual election between the approver terminals based on the first criterion.
The at least one approver terminal in the coalition that has detected the request
A second digital that has an economic value equivalent to that of the first digital asset when it is determined that the block-chain transfer can be permitted based on a predetermined licensing standard by initiating the decision-making by the majority vote. Issue a new asset, execute the block-chain transfer,
The second digital asset can be traded on the second block chain side using a versatile decentralized consensus building protocol that can execute transaction approval and balance verification regardless of the type of digital asset. It is characterized by being issued as a unique token.

(2) In another embodiment of the present invention, in the system of (1) above, the owner terminal is the first digital from the approver terminal to a second address designated on the first block chain. Broadcast the first transaction to transfer the asset,
At least one approver terminal constituting the alliance
When the first transaction is received at the second address, a vote is made by the majority vote in the coalition to decide whether or not to transfer between the block chains to the first address notified from the owner terminal as the remittance destination. Perform a communication procedure that causes the coalition to initiate the process
When the transfer between blocks and chains is permitted, a second transaction in which the second digital asset having an economic value equivalent to that of the first digital asset is newly issued and the second digital asset is transferred to the first address. Is configured to be broadcast to the second block chain.
It is characterized by that.

(3) In still another embodiment of the present invention, in the system of (2), the second digital asset is the second digital asset, with the third address owned by the owner on the first block chain as the remittance destination. The approver terminal that has received a request for inter-block chain transfer to return to one block chain from the owner terminal
The third transaction of generating an asset freeze address on the second block chain to make the second digital asset virtually unusable in the future and transferring the second digital asset to the asset freeze address is the same. Send information,
When the third transaction is received at the asset freeze address, a fourth transaction for transferring the unique token between blocks and chains is generated using the third address notified from the owner terminal as a remittance destination.
When the third transaction is permitted as a result of executing the voting process for the decision based on the majority vote in the coalition, the unique token is transferred to the third address via the third transaction. , The second digital asset is configured to return to the first block chain.

From the above, the following can be considered as conventional technical problems that can be overcome by the method of transferring cryptocurrency assets between blockchains according to some embodiments of the present invention. In the "Federated Peg method" mentioned above, the selection of members in the coalition of approvers is judged with sound governance, reliability (high security), and fairness within the blockchain ecosystem in mind. Specifically, the selection of the above members is determined with a strong awareness of policies (or governance strategies) and political power balance for sound governance within the ecosystem.

On the other hand, the criteria for accepting or rejecting peg-in and peg-out requests are the functional constraints supported by the blockchain system (whether or not they support the ability to perform UTXO or SPV certification). It is often affected by technical restrictions such as whether or not it functionally supports bidirectional pegs for a particular cryptocurrency (the types of cryptocurrencies that can be handled when running bidirectional pegs). For example, balance verification using UTXO and decentralized consensus building processing (block approval, etc.) using SPV certification on the side chain BC side can only be realized by the Bitcoin block chain system. Conversely, account-based decentralized consensus building processing can be implemented with any Alt Coin blockchain system. At present, functions such as smart contracts have only been implemented in some blockchain systems such as Ethereum.

Therefore, if such technical restrictions can be removed and it becomes possible to decide whether to accept or reject peg-in requests and peg-out requests based only on control rules that consider policy criteria, safety, and crime prevention. , Has the following advantages. In other words, if the approver is selected based on the policy or control rule, the licensing criteria for peg-in and peg-out requests can be made consistent with the criteria for selecting members of the approver federation. As a result, it becomes possible to adapt the membership selection criteria of the coalition as the guidelines that direct how to determine the licensing criteria for peg-in and peg-out requests change.

Based on the above, according to some embodiments of the present invention, it is possible to realize transfer of cryptocurrency assets to and from a blockchain capable of trading any cryptocurrency assets other than Bitcoin or Bitcoin that does not support UTXO. it can. In addition, according to some embodiments of the present invention, it is managed according to a control rule based on a plurality of viewpoints whether or not a specific user should tolerate an attempt to transfer a specific crypto asset between blockchains. It is possible to realize a mechanism to do so.

As a result, by selecting approvers based on policy or control rules, it is possible to ensure consistency between the licensing criteria for peg-in and peg-out requests and the member selection criteria for the approver's federation. This makes it possible to adapt the membership selection criteria of the coalition as the guidelines that direct how to determine the licensing criteria for peg-in and peg-out requests change.

FIG. 5 is a diagram illustrating a scenario in which a pegin address is assigned to each pegin request according to some embodiments of the present invention, and a cryptographic asset is transferred from a parent BC to a side chain BC by a newly issued unique token. It is a figure exemplifying a scenario in which a coalition of approvers accepts a peg-in request or a peg-out request from a user terminal and determines whether or not the request is permitted according to some embodiments of the present invention. FIG. 5 illustrates a scenario in which each approver who is a member of a federation of approvers makes a decision by voting and making decisions according to some embodiments of the present invention. FIG. 5 illustrates a scenario in which each approver who is a member of a federation of approvers makes a decision by voting and making decisions according to some embodiments of the present invention. FIG. 5 illustrates a scenario in which each approver who is a member of a federation of approvers makes a decision by voting and making decisions according to some embodiments of the present invention. FIG. 5 illustrates a scenario for renewing membership in a federation of approvers according to some embodiments of the invention. FIG. 5 illustrates a scenario for renewing membership in a federation of approvers according to some embodiments of the invention. FIG. 5 illustrates an underlying blockchain system in which a method of transferring crypto assets between blockchains is implemented according to some embodiments of the present invention. FIG. 5 illustrates an underlying blockchain system in which a method of transferring crypto assets between blockchains is implemented according to some embodiments of the present invention. FIG. 5 illustrates an underlying blockchain system in which a method of transferring crypto assets between blockchains is implemented according to some embodiments of the present invention. FIG. 5 illustrates an underlying blockchain system in which a method of transferring crypto assets between blockchains is implemented according to some embodiments of the present invention. FIG. 5 illustrates an underlying blockchain system in which a method of transferring crypto assets between blockchains is implemented according to some embodiments of the present invention. It is a figure which illustrates the computer system which implements the function of the bidirectional peg which concerns on some embodiments of this invention by software and hardware. It is a figure which illustrates the architecture of the platform which implements the function of the bidirectional peg which concerns on some embodiments of this invention. As a comparative example to be compared with some embodiments of the present invention, it is a diagram illustrating a scenario of transferring crypto assets to and from a conventional bidirectional peggable sidechain. As a comparative example to be compared with some embodiments of the present invention, it is a diagram illustrating a scenario of transferring crypto assets to and from a conventional bidirectional peggable sidechain.

<1> Conventional Technology (Federated Peg Method) According to some embodiments of the present invention, the transfer mechanism according to some embodiments of the present invention is described before the transfer mechanism of cryptocurrency assets between blockchains is described in detail. The conventional "Federated Peg method" will be described with reference to the flow chart of FIG. 15 for the purpose of comparison with. According to Non-Patent Document 1, in the conventional "Federated Peg method", the processing process for the transfer of crypto assets between block chains is executed according to the flow of FIG. Hereinafter, in order to give as specific a description as possible, it is assumed that the processing process shown in FIG. 15 is executed on the block chain structure as shown in FIG. 16 (a).

Referring to FIG. 16 (a), in this block chain structure, two side chains BC (SC1 and SC2 shown in FIG. 16 (a)) are attached to the parent BC (Mch shown in FIG. 16 (a)). There is. The parent BC (Mch) is configured as a chain of a plurality of blocks N _m (q) (1 ≦ q ≦ Q). Further, each of the two side chains BC (SC1, SC2) is configured as a chain of a plurality of blocks _NS1 (p) (1 ≦ p ≦ P) and is configured as a chain of _NS2 (r) (1 ≦ r ≦ R). Will be done.

According to the conventional "Federated Peg method", the process of transferring the digital asset VC1 between the block chains by the remittance transaction process is performed by an alliance organized by a plurality of approver terminals Fm [1] to Fm [3]. It is executed under supervision. The digital asset VC1 includes one or more types of electromagnetic records capable of distributing the asset value by transmission / reception within the information network, and is directed from the parent BC (Mch) to the side chain BC (SC shown in FIG. 15). The block-chain transfer is executed as follows along the flow shown in FIG. In the processing flow shown in FIG. 13, it is assumed that the first digital asset VC1 is transferred from the parent BC (Mch) shown in FIG. 14A to the side chain BC (SC1).

First, the processing flow shown in FIG. 15 starts from step ST11, and the user terminal transmits a transaction of transmitting the first digital asset (VC1) to the output endpoint of the parent BC (Mch) in the parent BC (Mch). Generate. Subsequently, the processing flow proceeds to step ST12, and when the approver terminal Fm [x] receives a transaction for transmitting the first digital asset (VC1) to the output end point, the second digital asset VC2 is locked. This corresponds to the process of locking the crypto asset VC1 to be pegged in, as shown in FIG. 16B. Then, the approver terminal Fm [x] generates hash information of the first digital asset (VC1) (corresponding to the generation of "SPV proof"). The generation of this SPV certificate is performed with a first computational complexity sufficient to authenticate the first digital asset (VC1). As a result, the actual process of inter-block chain transfer for transferring the digital assets to be pegged from the parent BC (Mch) to the side chain BC (SC1) is started.

Subsequently, the hash information is verified by the verification server on the side chain BC (SC1), and the approver terminal Fm [x] has an asset value equal to that of the first digital asset VC1 according to the result of the verification. The second digital asset VC2 is generated on the side chain BC (SC1). Subsequently, the processing flow proceeds to step ST13, and the approver terminal Fm [x] determines whether or not an event (“Re-organization”) in which the authentication of the first digital asset (VC1) is overwritten has occurred over the first waiting period. Monitor. This process is executed while holding the second digital asset (VC2) in the locked state, and the event to be monitored is called "Re-organization".

In "Re-organization", a node other than the approver terminal Fm [x] spends a second calculation amount to generate hash information of the first digital asset (VC1), and the second calculation amount is a step. It occurs by exceeding the first computational complexity spent when generating the SPV proof in ST12. Then, when "Re-organization" occurs, the transaction authentication authority possessed by the approver terminal Fm [x] is taken by a node other than the approver terminal Fm [x].

If the event does not occur after the lapse of the first waiting period during this first waiting period, the second digital asset (VC2) in the locked state is unlocked by the approver terminal Fm [x]. It is ready to be traded on the side chain BC (SC1). That is, if the transaction authentication authority is not taken by "Re-organization" until the expiration of the "Contest Period" shown in FIG. 15, the approver terminal Fm [x] transfers the second digital asset (VC2) to the side chain BC (SC1). ) Make it available for distribution. After the second digital asset (VC2) is ready for distribution on the side chain BC (SC1), the processing flow shown in FIG. 15 proceeds to step ST14. In step ST14, a remittance transaction is executed to transfer the second digital asset VC2 within the side chain BC (SC1).

On the other hand, when the process of pegging out the pegged-in crypto asset VC2 to the parent BC (Mch) side is started, the processing flow shown in FIG. 15 proceeds to step ST15. In step ST15, the occurrence of "Re-organization" is monitored over the second confirmation period. In parallel with this, a transaction for transmitting the second digital asset (VC2) to the output endpoint of the side chain BC (SC1) is generated, and the second digital asset VC2 is locked. Subsequently, the processing flow shown in FIG. 15 proceeds to step ST16, and the hash of the second digital asset (VC2) is performed by the approver terminal Fm [x] for the crypto asset VC2 to be pegged out to the parent BC (Mch). Information is generated (corresponding to the generation of "SPV proof"). This initiates the actual process of block-chain transfer to return the pegged digital assets from the side chain BC (SC1) back to the parent BC (Mch).

Subsequently, the processing flow shown in FIG. 15 proceeds to step ST17, and when the hash information is verified by the verification server on the parent BC (Mch), the approver determines whether or not an event (“Re-organization”) has occurred. The terminal Fm [x] monitors over the third standby period (Contest Period). If a re-organization that causes the transaction authentication authority to be taken by a node other than the approver terminal Fm [x] occurs before the expiration of the second waiting period in step ST18 shown in FIG. 13, the third waiting period is abnormally interrupted in step ST19. To do. Here, when the approver terminal Fm [x] further triggers a re-organization (step ST20 shown in FIG. 15) that regains the transaction approval authority, the abnormally suspended third waiting period is restarted (in step ST21). ).

Subsequently, when the third waiting period expires normally, the pegged-out first digital asset VC1 is put into a state where it can be distributed on the parent BC (Mch). That is, as shown in FIG. 16 (c), in order to peg out the pegged crypto asset VC2 to the parent BC (Mch) side, the crypto asset VC2 is unlocked and released on the side chain BC (SC1). Finally, the processing flow shown in FIG. 15 proceeds to step ST22, and a remittance transaction for remittance of the first digital asset VC1 is executed in the parent BC (Mch).

From the above, in the approach using the symmetric two-way peg SPV peg for peg-in / peg-out based on the SPV proof, the coin of the parent BC is transferred to the side chain BC side. Therefore, only the SPV proof on the side chain can lock the coins of the parent BC by sending them to a special output on the parent chain and unlock the locked coins. At that time, in order to synchronize the two blockchains, it is necessary to define two waiting periods "Contest Period" and "Confirmation Period".

In the implementation example of the existing side chain technology, there is only an implementation example in which a bitcoin corresponding to UTXO (Unspent Transaction Output) is used as a parent BC to execute bidirectional pegs with the side chain BC. In other words, the two-way peg mechanism is difficult to implement on the parent BC side in the blockchain that trades Bitcoin that does not support UTXO. Similarly, the two-way peg mechanism is difficult to implement in any blockchain that can trade any Alt Coin or any token other than Bitcoin. Therefore, depending on the type of digital asset (currency type) that uses inter-block chain transfer and the address of the transfer destination, peg-in or peg-out may not be possible.

In addition, the conventional "Federated Peg method" is expected to have the effect of solving or alleviating the problem that an unspecified node whose reliability is not guaranteed can be involved in the consensus rule application process. However, when trying to solve this problem with the conventional "Federated Peg method", the problem is how to form a coalition of approvers by selecting multiple approvers from the entire BCN (Block-Chain Network). Is newly generated. From the above, in the "Federated Peg method", how to select a plurality of approver terminals Fm [i] (1 ≦ i ≦ I) to form an alliance of approver terminals is the most effective solution to the above problem. You have to think about whether it is a solution.

In addition, another problem with bi-directional peckable sidechains is the type of crypto assets transferred between the chains by bi-directional pegs or the source of the peg-in / out request is legal, ideological and strategic. It may not be desirable from the above point of view. To address this issue, it is necessary to manage whether or not a particular user should tolerate attempts to peg in / peg out a particular cryptocurrency according to certain control rules. Furthermore, in order to realize management based on the above control rules, whether or not the type (currency type) of the crypto asset subject to peg in / out is an acceptable type of crypto asset, or a request for peg in / out. It is also necessary to have a mechanism to specifically determine whether or not the original is an acceptable user.

In view of the above problems, in some embodiments of the present invention, it is possible to realize transfer of cryptocurrency assets to and from a blockchain capable of trading any cryptocurrency assets other than Bitcoin or Bitcoin that does not support UTXO. The purpose is to get a mechanism. Further, in view of the above problems, in some embodiments of the present invention, whether or not a specific user should allow an attempt to transfer a specific cryptocurrency asset between block chains is determined according to a certain control rule. The purpose is to obtain a mechanism that can be managed.

Further, in some embodiments of the present invention, a mechanism is provided to support the achievement of the object of preventing unspecified nodes whose reliability is not guaranteed from being involved in the distributed consensus building process. Specifically, a mechanism is established to form a consensus by selecting a plurality of approvers Fm [i] (1 ≦ i ≦ I) based on selection criteria that can be adjusted according to the situation, and the selected approvers. Prevent nodes other than Fm [i] (1 ≦ i ≦ I) from participating in the distributed consensus building process.

<2> Embodiment of the present invention Next, the configuration and operation will be described in detail in an exemplary system configured as shown in FIGS. 1 to 7 according to some embodiments of the present invention. Subsequently, with respect to the embodiment of the present invention, the system according to some embodiments of the present invention will be examined by comparing the exemplary system shown in FIGS. 1 to 7 with the above-mentioned conventional "Federated Peg method". The technical effect of is described. In order to distinguish it from the conventional "Federated Peg method", a system that realizes a mechanism for transferring digital assets between block chains according to the embodiment of the present invention shown in FIGS. It will be called "Federated Gateway) system".

Hereinafter, the "Federated Gateway system" according to the embodiment of the present invention will be described with reference to FIGS. 1 to 7, but the following two points are almost the same as those of the conventional "Federated Peg method". Therefore, detailed description will be omitted. First, as a first point, even in the "Federated Gateway system", a series of processes considered necessary in view of the common general technical knowledge of those skilled in the art are naturally executed among the distributed consensus building processes. These series of processes include "proof of work generation", "transaction approval", "lock processing and unlocking of crypto assets to be exported on the parent BC side" and the like. In addition, as a second point, even in the "Federated Gateway system", the configuration in which the above series of processes are aggregated and executed in the approval mechanism by the "coalition of approvers" is the conventional "Federated Peg method". Is the same as.

1 to 5 show an example of a system configured to transfer digital assets between blockchains according to some embodiments of the present invention. The digital assets VC [a] to VC [d] referred to here are configured to include one or more types of electromagnetic records, and the asset value can be distributed on the network by transmission / reception via remittance transaction processing. Refers to digital information. Hereinafter, by transfer between blocks, the digital assets VC [a] to VC [d] owned by the owner on the parent BC (Mch) are transferred to the side chain BC (SC), and then the side chain BC (SC). The explanation will be given on the premise that a series of processes are executed according to the scenario of returning from SC) to the parent BC (Mch).

According to some embodiments of the present invention, the "Federated Gateway system" shown in FIGS. 1 to 5 is a two or more approver terminals Fm [i] (1 ≦ i) that make a majority decision. It comprises an federation Fed formed by ≦ I) and configured to renew membership by mutual election between approver terminals Fm [i] (1 ≦ i ≦ I) based on first criterion CR1. Further, in the system shown in FIGS. 1 to 5, four owners U [a] to U [d] who each own the first digital assets VC [a] to VC [d] are information terminals (owners). Terminal) The system is accessed from UT [a] to UT [d] via a communication line.

The first digital assets VC [a] to VC [d] may be cryptocurrencies including virtual currencies or other tokens widely distributed on the blockchain as a key currency. For example, in the examples shown in FIGS. 1 to 5, the first digital assets VC [a] to VC [d] are "bitcoin", "Counterparty", "Ethereum", and "TUSD", respectively. Of these, "Bitcoin" is a Bitcoin compatible with UTXO, and "Counterparty", "Ethereum" and "TUSD" are cryptocurrencies compatible with an account-based distributed consensus building protocol.

(2-1) Processing at the peg-in stage The following is a mechanism for transferring (peguin) the first digital assets VC [a] to VC [d] on the parent BC (Mch) to the side chain BC (SC) side. After the explanation with reference to FIG. 5, the process of returning the digital asset transferred to the side chain BC (SC) side to the parent BC (Mch) side (pegout) will be described. Further, in order to simplify the explanation, a case where the first digital asset VC [a] is transferred by transfer between blocks and chains in response to a request from the owner terminal UT [a] will be described as an example. The same applies to the case where the first digital assets VC [b] to VC [d] are transferred by inter-block chain transfer in response to a request from the terminals UT [b] to UT [d].

First, the operation of the system shown in FIG. 1 will be described. The owner U [a] of the first digital asset VC [a] operates the terminal UT [a] to block the first digital asset VC [a]. -Send a request RQ to transfer from the parent BC (Mch) to the side chain BC (SC) by interchain transfer. After that, the request RQ arrives at the address QA associated with the queue (queuing mechanism) PCM, which will be described in detail later with reference to FIG. Then, an event indicating that the request RQ has arrived at the address QA is detected by any one or more of the approver terminals Fm [1] to Fm [3] in the federation Fed (step shown in FIG. 2). ST01). Hereinafter, for the sake of simplicity, among the approver terminals Fm [i] (1 ≦ i ≦ I) constituting the federation Fed, the approver terminal that has detected the incoming call of this request RQ is Fm [x]. Notated as.

Here, when the request RQ is sent to the address QA, the terminal UT [a] is the first address (WA [a, shown in FIG. 5) of the owner U [a] on the side chain BC (SC). 1]) is specified as the remittance destination. Here, as shown in FIG. 5, the first address WA [a, 1], which is the remittance destination when performing inter-block chain transfer from the parent BC (Mch) to the side chain BC (SC), is the side chain. It is a wallet address (FIG. 5) held by the owner U [a] as a deposit destination on the BC (SC). Then, as an example of this remittance destination designation process, the owner terminal UT [a] may execute the following operations.

First, the first transaction Tx [a, 1] that transfers the first digital asset VC [a] owned by the owner U [a] on the parent BC (Mch) to the approver terminal Fm [x] (Fig. 2) is generated. Subsequently, by embedding the first address WA [a, 1] as the remittance destination on the side chain BC (SC) for the first transaction Tx [a, 1], it can be used as the remittance destination in the inter-block chain transfer. The first address WA [a, 1] is specified. Finally, when the approver terminal Fm [x] belonging to the federation Fed receives the first transaction Tx [a, 1], the approver terminal Fm [x] is notified of the first address WA [a, 1]. (P1 shown in FIG. 5).

Further, in the exemplary embodiment, after the owner terminal UT (a) generates the first transaction Tx [a, 1] (FIG. 2), the first transaction Tx [a, 1] is generated by the approver terminal Fm [a, 1]. The process of receiving x] may be executed as follows. First, at least one approver terminal Fm [x] constituting the federation Fed is owned by the request RQ for transferring the first digital asset VC [a] on the parent BC (Mch) onto the side chain BC (SC). It is detected that the call is sent from the personal terminal UT (a) and arrives at the address QA. Subsequently, the approver terminal Fm [x] creates a second address (temporary deposit wallet address IA [a] shown in FIG. 1) unique to the owner U [a] on the parent BC (Mch). And assign it to the owner terminal UT [a] (step ST00 shown in FIG. 1). When the owner terminal UT [a] detects that the second address IA [a] has been assigned after sending the request RQ to the approver terminal Fm [x] constituting the federation Fed, the second address IA The first transaction Tx [a, 1] is broadcasted to the destination [a].

The second address IA [a] is a place where the first digital asset VC [a], which is the target of inter-block chain transfer, is kept in a locked state. Normally, at the second address IA [a], until the first digital asset VC [a] is transferred onto the side chain BC (SC) and returned from the side chain BC (SC) to the parent BC (Mch) side. During that time, the first digital asset VC [a] is held in an unusable state. However, as will be described in detail below with reference to FIGS. 2 and 3, the federation Fed of the approver terminal Fm [i] (1 ≦ i ≦ m) is the block requested by the owner terminal UT [a]. -It may be decided not to allow transfer between chains. In this case, the first digital asset VC [a] that was the target of the attempt to transfer between blocks is subject to refund processing to the second address IA [a], and after the refund processing is completed, the first The digital asset VC [a] is unlocked and can be used again. Therefore, the request RQ can be interpreted as an address allocation request for requesting the approver terminal Fm [x] to assign an address for a primary deposit holding a digital asset to be transferred between blocks and chains. ..

In this way, the first transaction Tx [a, 1] sets the first digital asset VC [a] toward the second address IA [a] assigned on the parent BC (Mch) by the approver terminal Fm [x]. Forward. The same procedure as above is executed when requesting the transfer between block chains of the first digital assets VC [b] to VC [d] owned by other owners U [b] to U [d]. .. That is, the second addresses IA [b] to IA [d] created on the parent BC (Mch) by the approver terminal Fm [x] are assigned to the owner terminals UT [b] to UT [d]. Finally, the first transactions Tx [b, 1] to Tx [d, 1] generated by the owner terminals UT [b] to UT [d] are directed toward the second addresses IA [b] to IA [d]. The first digital assets VC [b] to VC [d] are transferred respectively.

When at least one approver terminal Fm [x] in the federation Fed that has detected the arrival of the request RQ receives the first transaction Tx [a, 1] at the second address WA [2], the owner terminal The first address WA [1] notified from the UT [a] is identified as the remittance destination. Subsequently, the approver terminal Fm [x] initiates a voting process that determines whether inter-block chain transfer to transfer the first digital asset VC [a] towards the side chain BC (SC) should be allowed. Invoke the procedure to do. Specifically, the approver terminal Fm [x] executes a communication procedure that causes the Fed to initiate a voting process in which a majority vote within the Fed decides whether to allow inter-block chain transfer. ..

The approver terminal Fm [x], which has received the first transaction Tx [a, 1] from the owner terminal UT [a], starts the voting process to decide whether or not to allow transfer between blocks by a majority vote within the federation Fed. Then, first, the members who participate in the voting are selected within the federation Fed. Specifically, when the voting process is started, a selection process for selecting a plurality of other approver terminals UT [i] (1 ≦ i ≦ m) participating in the voting process based on the first criterion CR1. Is started (step ST03 shown in FIG. 2). In the example shown in FIG. 2, the selection process for selecting the approver terminal Fm [i] (1 ≦ i ≦ m) may be carried out as follows.

Referring to FIG. 2, the approver terminal Fm [x] that has received the first transaction Tx [a, 1] is the approver terminal Fm [j] (1 ≦ j ≦ M) waiting to participate in the voting. The approver terminal Fm [i] (1 ≦ i ≦ m) to participate in the voting is selected from among them by the following method. For example, the approver terminal Fm [x] examines the received first transaction Tx [a, 1] based on the first criterion CR1. Subsequently, the approver terminal Fm [x] is combined from among a plurality of approver terminals Fm [j] (1 ≦ j ≦ M) based on the result of examining the received first transaction Tx [a, 1]. Select members to participate in voting within the body Fed.

Specifically, the members who participate in the voting have a plurality of approver terminals Fm [j] waiting to participate in the voting in the queue (queue) PCM (Fig. 2) on the parent BC (Mch). From 1 ≦ j ≦ M), those judged to be appropriate in view of the results of the above-mentioned examination are selected. The queuing mechanism is a mechanism for selecting members to participate in voting from a plurality of approver terminals Fm [j] (1 ≦ j ≦ M) waiting to participate in voting in the queue PCM (Fig. 2). A plurality of approver terminals Fm [j] (1 ≦ j ≦ M), which can be members participating in the voting, are selected and placed in the queuing PCM by a deterministic process. ..

In the example shown in FIG. 2, voting in the federation Fed from among a plurality of approver terminals Fm [j] (1 ≦ j ≦ M) waiting to participate in the voting in the queue PCM (FIG. 2). The procedure for selecting members to participate in may be executed as follows. For example, the approver terminal Fm [x] uses each of the plurality of approver terminals Fm [j] (1 ≦ j ≦ M) waiting to participate in the voting in the queue PCM (FIG. 2) as the first reference. Judging based on CR1. Then, the approver terminal Fm [x] selects the approver terminal Fm [i] (1 ≦ i ≦ m) judged to be appropriate based on the examination result as a member to participate in the voting within the federation Fed. ..

In another example, the approver terminal Fm [x] is a queue PCM (FIG. 2) of the existing approver terminals Fm [j'] (1 ≤ j'≤ M') constituting the federation Fed. ) Is selected based on the first criterion CR1. Alternatively, the approver terminal Fm [x] is a sequence of multiple approver terminals Fm [j] (1 ≦ j ≦ M) waiting to participate in the vote in the queue PCM. The order is adjusted based on the first reference CR1. Then, the approver terminal Fm [x] selects the approver terminal Fm [i] (1 ≦ i ≦ m) taken out from the queue PCM according to the FIFO algorithm as a member to participate in the voting in the federation Fed. To do.

Subsequently, when a plurality of approver terminals Fm [i] (1 ≦ i ≦ m) are selected based on the first criterion CR1 triggered by the detection of the first transaction Tx [a, 1], the federation Fed Any approver Fm [y] to which it belongs starts the voting process by simultaneously transmitting a voting start message to another approver terminal Fm [k] (k ≠ y). At this time, if the approver terminal Fm [y] simultaneously sends the voting start message at the very beginning, the other approver terminals Fm [k] (k ≠ y) start voting until the voting process is completed. You will not be able to send messages.

When this voting process starts, the approver terminal Fm [i] (1 ≦ i ≦ m) makes a decision by majority vote to determine whether or not to allow transfer between blocks. At that time, each of the approver terminals Fm [i] (1 ≦ i ≦ m) selected as voting participating members examines the received first transaction Tx [a, 1] as follows, and this examination A voting message VT indicating consent or disagreement is broadcasted according to the result of (step ST02 shown in FIG. 2).

For example, each of the approver terminals Fm [i] (1 ≤ i ≤ m) has the following list of authorization criteria that can be used to determine whether to allow inter-block chain transfer ( The list LT [A] to LT [E] shown in FIGS. 2 and 4) may be set in advance. Here, the lists LT [A] to LT [E] shown in FIGS. 2 and 4 are the types of digital assets (currency types such as Bitcoin, Ethereum, Counterparty, etc.) and blocks to be transferred between block chains. -Among the pairs consisting of remittance destination addresses for inter-chain transfer, it is composed of a permission list that lists the pairs that should be permitted for inter-block transfer and a prohibition list that enumerates the pairs that should be prohibited for inter-block transfer. To.

Further, according to the alternative embodiment shown in FIG. 2, the lists LT [A] and LT [B] may be configured as the following data structures. As shown in FIG. 2, each of the lists LT [A] and LT [B] contains one or more entries. Each entry is an attribute of one or more blockchain protocols supported by the communication functions of the approver terminals Fm [x1] and Fm [x2] corresponding to the lists LT [A] and LT [B], respectively. Is described. For example, the list LT [A] shown in FIG. 2 includes an entry described as "Asset Protocol A" and an entry described as "Asset Protocol B". Further, the list LT [B] shown in FIG. 2 includes an entry described as "Asset Protocol A" and an entry described as "Asset Protocol C".

Then, in each entry, one or more types of digital assets (currency types) whose remittances and balances can be confirmed by the corresponding blockchain protocol are listed in the "Supported Assets" column. In addition, in each entry, one or more of the addresses of the remittance destination in the inter-block chain transfer that are prohibited from remittance and balance confirmation by the corresponding block chain protocol are "Black Listed Addresses". Listed in the column.

Since the lists LT [A] and LT [B] shown in FIG. 2 have the above data structure, it is possible to determine whether or not to allow transfer between individual blocks and chains as follows. It becomes. That is, the pair consisting of the currency types of the first address WA [a, 1] and the first digital asset VC [a], which are the remittance destinations on the side chain BC (SC) side, is collated with the list. As a result, any approver terminal Fm [i "] participating in the voting process can determine the following items from the collation result.

First, it supports the currency type of digital assets subject to inter-block chain transfer among one or more block chain protocols that can be executed by any approver terminal Fm [i "] participating in the voting process. It is possible to determine whether or not there is a protocol to be used. Furthermore, when the remittance destination address of the digital asset to be transferred between blocks is the remittance destination when the block chain protocol used for the remittance processing is used. It is possible to determine whether or not the address is prohibited.

Based on the above, the pair consisting of the currency types of the first address WA [a, 1] and the first digital asset VC [a], which are the remittance destinations, is transferred between individual block chains according to the result of collating with the list. Can be determined whether or not to allow. In one example, in the lists LT [A] to LT [E] shown in FIGS. 2 and 4, one or more approvers operate the approver terminal Fm [i] (1 ≦ i ≦ m). It may be created based on the policy control data set in the terminal in. In this case, the policy control data is data that controls the terminal operation of the approver terminal Fm [i] (1 ≦ i ≦ m) by describing the permission criteria for inter-block chain transfer. At this time, the licensing criteria for inter-blockchain transfer are determined to be consistent with the policy requirements for governing the ecosystem in which digital assets circulate across multiple blockchains.

In the example shown in FIG. 4, the approver terminals Fm [1] and Fm [2] are preset with lists LT [D] and LT [C] including the above-mentioned permission list and prohibition list, respectively. .. Further, in the approver terminal Fm [3], a list LT [E] including the above-mentioned permission list and prohibition list is set in advance. Further, in the example shown in FIG. 4, the approver terminal Fm [1] communicates with the full node Nf [Mch, 2] on the parent BC (Mch) and the full node Nf [SC, 2] on the side chain BC (SC). Possiblely connected, the approver terminal Fm [2] is communicably connected to the full node Nf [Mch, 1] on the parent BC (Mch) and the full node Nf [SC, 1] on the side chain BC (SC). ing. Further, the approver terminal Fm [3] is communicably connected to the full node Nf [Mch, 3] on the parent BC (Mch) and the full node Nf [SC, 3] on the side chain BC (SC).

With the above configuration, when the block-chain transfer is performed between the parent BC (Mch) and the side chain BC (SC), the approver terminals Fm [1] to Fm [3] are the parent BC (Mch). ) And the side chain BC (SC) can exchange necessary information and data. On top of that, each of the approver terminals Fm [i] (1 ≦ i ≦ m) is the first address WA [a, 1] and the first digital asset VC [ The pair consisting of the currency type of [a] is collated with the above list (LT [C] to LT [E] shown in FIG. 4 and the like). Next, each of the approver terminals Fm [i] (1 ≦ i ≦ m) indicates a voting message VT indicating either consent or disagreement with respect to the transfer between individual blocks and chains according to the collation result. May be broadcast.

As described above, the result of the above-mentioned voting is obtained based on the majority vote by the approver terminal Fm [i] (1 ≦ i ≦ m) (step ST04 shown in FIG. 3). As a result of this voting, when it is decided to allow the transfer between blocks, at least one approver terminal Fm [y] in the approver terminal Fm [i] (1 ≦ i ≦ m) performs the following processing. By executing, the transfer between block chains is completed.

First, the approver terminal Fm [y] newly issues a second digital asset WC [a] (FIG. 1) having an economic value equivalent to that of the first digital asset VC [a] (FIG. 1). At that time, the second digital asset WC [a] uses a side chain BC (SC) using a versatile distributed agreement formation protocol capable of executing transaction approval and balance verification regardless of the currency type of the digital asset. It is issued as a unique token Tk (Fig. 1) that can be traded on the side. Then, the approver terminal Fm [y] transfers the original token Tk (FIG. 1) to the first address WA [a, 1] in the second transaction Tx [a, 2] (FIG. 3) in the side chain BC. The broadcast is transmitted to (SC) (P3 shown in FIG. 5).

Specifically, if the second transaction Tx [a, 2] to be transferred to the side chain BC (SC) of the original token Tk is permitted by voting based on a majority vote, the second transaction Tx [a, 2] is the voting process. It is digitally signed by the approver terminal Fm [i] (1 ≦ i ≦ m) who participated in the transaction. Then, the electronically signed second transaction Tx [a, 2] is broadcasted to the side chain BC (SC) side. As a result of executing the second transaction Tx [a, 2] (P3 shown in FIG. 5), the inter-block chain transfer of the digital asset to the side chain BC (SC) side is completed (shown in FIG. 3). Step ST05).

On the other hand, as a result of the above-mentioned voting by the approver terminal Fm [i] (1 ≦ i ≦ m), the transfer between the block chains of the first digital asset VC [a] requested by the owner terminal UT [a] is permitted. If it is determined not to do so, the transaction Tx [a, 3] shown in FIG. 3 is executed as a refund process. In this transaction Tx [a, 3], a refund process is performed to the owner U [a] of the first digital asset VC [a] held at the second address IA [a], and the first digital asset is processed. The VC [a] is unlocked and ready for use.

Further, in one exemplary embodiment shown in FIG. 2, the process of selecting a plurality of approver terminals Fm [i] (1 ≦ i ≦ m) participating in the voting process includes the above-mentioned permission list and prohibition list. It may be executed as follows using a list (LT [A] and LT [B] shown in FIG. 2 and the like). Here, in the example shown in FIG. 2, a list LT [A] including the above-mentioned permission list and prohibition list is set in advance in the approver terminals Fm [1] and Fm [2], respectively. Further, in the approver terminal Fm [3], a list LT [B] including the above-mentioned permission list and prohibition list is set in advance. Then, first, the approver terminal Fm [x] extracts the first address WA [a, 1] to be the remittance destination on the side chain BC (SC) side from the received first transaction Tx [a, 1]. To do. Further, the approver terminal Fm [x] detects the currency type of the first digital asset VC [a] to be transferred between blocks and chains from the received first transaction Tx [a, 1] (FIG. 2). Step ST02) shown in.

Subsequently, the approver terminal Fm [x] lists the pair consisting of the currency types of the first address WA [a, 1] and the first digital asset VC [a], which are the remittance destinations, in the above list (FIG. 2). Collate with LT [A], LT [B], etc.). Next, the approver terminal Fm [x] is selected from a plurality of approver terminals Fm [j] (1 ≦ j ≦ M) waiting to participate in the voting in the queue PCM according to the collation result. Select the appropriate device as a member to participate in the vote. At that time, in the approver terminal Fm [j] (1 ≦ j ≦ M) in the queue PCM according to the collation result with the above list (LT [A], LT [B], etc. shown in FIG. 2). The process of selecting the members to participate in the voting from the above may be executed, for example, as follows.

First, the approver terminal Fm [x] reads out the above list set in the approver terminal Fm [j] (1 ≦ j ≦ M) waiting to participate in the voting in the queue PCM. Subsequently, a terminal that does not include an entry that matches any one of the currency types of the first address WA [a, 1] and the first digital asset VC [a] to be remitted in the list is an inappropriate terminal. Exclude from participating members in the vote. On the contrary, the approver terminal Fm [x] is the following terminals among the approver terminals Fm [j] (1 ≦ j ≦ M) in the queue PCM that remain without being excluded from the participating members in the voting. Treat as. That is, a terminal that contains more entries in the list that match one of the currency types of the first address WA [a, 1] and the first digital asset VC [a] to be remitted to is another terminal. Select as a member to participate in voting with priority over the terminal.

From the above, in the embodiment shown in FIGS. 2 to 4, the list including the above-mentioned permission list and prohibition list (lists LT [A] to LT [E] shown in FIGS. 2 and 4 and the like) is voted. It can be regarded as embodying the first standard CR1, which is the selection standard for participating members. Therefore, the approver terminal Fm [x] uses the above-mentioned list including the permission list and the prohibition list as the first criterion CR1 which is the selection criterion of the members participating in the voting, and thus the approver terminal Fm [i] (1 ≦ i ≦ m) may be selected.

Similarly, in the embodiment shown in FIGS. 2 to 4, the list including the above-mentioned permission list and prohibition list is a second standard that serves as a permission standard for determining whether or not to permit transfer between individual blocks and chains. It can be regarded as a realization of CR2. Therefore, the approver terminal Fm [x] uses the list including the above-mentioned permission list and prohibition list as the second standard CR2 (permission standard) when deciding whether or not to permit the transfer between individual blocks and chains. It may be decided whether or not to allow transfer between individual block chains.

From the above, when the approver terminal Fm [y] executes this second transaction Tx [a, 2], the second digital asset WC [a] on the parent BC (Mch) is transferred to the side chain BC (SC). It will be possible to relocate. At that time, an account-based protocol may be used as an example of the distributed consensus building protocol used when the approver terminal Fm [y] executes the transfer between blocks and chains. Here, the account-based protocol is a decentralized agreement formation protocol that supports any cryptocurrency that circulates as the key currency, and is a general-purpose protocol that can perform transaction approval and balance verification regardless of the currency type of digital assets. It is a protocol with sex.

Then, in this embodiment, the second digital asset WC [a] trades on the side chain BC (SC) side using the account-based decentralized consensus building protocol corresponding to the first digital asset VC [a]. Is issued as a unique token Tk that can be used. Further, in this embodiment, the unique token Tk that can be traded on the side chain BC (SC) side using the account-based decentralized consensus building protocol can be exchanged for an existing cryptocurrency at an adjustable variable rate. It may be an undistributed digital asset.

(2-2) Processing in the pegout stage In the block-chain transfer described above using FIGS. 1 to 5, the first digital assets VC [a] to VC [d] on the parent BC (Mch) are side-chain BC. It is a mechanism to move to the (SC) side, and in Non-Patent Document 1, it is called a pegin starting from the parent BC (Mch). On the other hand, the inter-block chain transfer of returning a digital asset once pegged to the side chain BC (SC) side to the parent BC (Mch) is called pegout in Non-Patent Document 1, and in the example shown in FIG. 5, the first Both peg-in and peg-out scenarios targeting the digital asset VC [a] are shown.

Hereinafter, using the example shown in FIG. 5, after pegging the first digital asset VC [a] to the side chain BC (SC) side, the digital asset once pegged is returned to the parent BC (Mch) between the block chains. The scenario when the transfer (peg out) is executed will be described. In this scenario, among a plurality of approver terminals Fm [k] (1 ≦ k ≦ N) constituting the federation Fed, the approver terminal Fm [a] receives the pegout request rq from the owner terminal UT [a]. It is executed with x'] as the execution subject. Here, the request rq is a request for inter-block chain transfer for returning the second digital asset WC [a] held by the owner U [a] on the side chain BC (SC) to the parent BC (Mch). Is. Further, in the inter-block chain transfer in this case, the owner U [a] uses the third address (WA [a, 3] shown in FIG. 5) on the parent BC (Mch) as the remittance destination. [A] corresponds to an operation of returning the digital asset once pegged to the side chain BC (SC) side to the parent BC (Mch).

From the viewpoint of fraud prevention and reliability, in the pegout that returns the digital asset once pegged to the parent BC (Mch), the approver terminal Fm that locks the first digital asset VC [a] at the start of pegin. It is preferable that [x "] detects the above rq and serves as a starting point for a series of subsequent processes. Hereinafter, with reference to FIG. 5, a digital peg-in to the side chain BC (SC) side is performed. The scenario when the block-chain transfer (peg out) that returns the asset to the parent BC (Mch) is described in detail.

Further, in one exemplary embodiment, the owner terminal UT [a] has a third address WA [a, which is a remittance destination on the side chain BC (SC) side with respect to the approver terminal Fm [x']. The mechanism for notifying 3] may be realized as follows. First, the owner terminal UT [a] transfers the second digital asset WC [a] to the asset freeze address XA [a] with respect to the third transaction Tx [a, 4] with respect to the third address WA [a]. , 3] is embedded as a remittance destination on the parent BC (Mch). Subsequently, the owner terminal UT [a] transmits the third transaction Tx [a, 4] including the third address WA [a, 3] to the asset freeze address XA [a].

Upon receiving the request rq, the approver terminal Fm [x'] sets an asset freeze address (XA [a] shown in FIG. 5) for making the second digital asset WC [a] virtually unusable in the future. Generated on the side chain BC (SC). Then, for decision-making based on a majority vote within the Union Fed, a voting process (as described above using FIGS. 1 to 4) by a plurality of approver terminals Fm [h] (1 ≦ h ≦ n). The same) is executed. If the third transaction Tx [a, 4] is allowed as a result of this voting process being executed, the approver terminal Fm [y'] in the federation Fed will have an economy equivalent to the second digital asset WC [a]. Issue a new unique token Tk'with value.

Further, the approver terminal Fm [y'] generates a fourth transaction Tx [a, 5] that transfers the original token Tk'between the blocks and chains. Here, in the fourth transaction Tx [a, 5], the third address WA [a, 3] notified from the owner terminal UT [a] is designated as the remittance destination. Finally, the approver terminal Fm [x'] transfers the original token Tk'to the third address WA [a, 3] via the fourth transaction Tx [a, 5] (P4 shown in FIG. 5).

In parallel with this, the approver terminal Fm [x'] broadcasts a third transaction Tx [a, 4] that transfers the second digital asset WC [a] to the asset freeze address XA [a]. After that, when the third transaction Tx [a, 4] is received at the asset freeze address XA [a] on the side chain BC (SC), the second digital asset WC [a] transferred to the asset freeze address XA [a] a] will be virtually unusable in the future.

This unique token Tk'can be traded on the parent BC (Mch) side using a versatile decentralized agreement formation protocol that can execute transaction approval and balance verification regardless of the currency type of digital assets. Issued as a digital asset. Furthermore, as an example of the distributed consensus building protocol used when the approver terminal Fm [y'] pegs out the original token Tk'from the side chain BC (SC) to the parent BC (Mch), an account-based protocol is used. You may use it. Here, the account-based protocol is a decentralized agreement formation protocol that supports any cryptocurrency that circulates as the key currency, and is a general-purpose protocol that can perform transaction approval and balance verification regardless of the currency type of digital assets. It is a protocol with sex.

Then, in this embodiment, the second digital asset WC [a] trades on the side chain BC (SC) side using the account-based decentralized consensus building protocol corresponding to the first digital asset VC [a]. Is issued as a unique token Tk'that can be used. Further, in this embodiment, the unique token Tk', which can be traded on the side chain BC (SC) side using the account-based decentralized consensus building protocol, is exchanged for an existing cryptocurrency at an adjustable variable rate. It may be a possible undistributed digital asset. As described above, it is possible to realize a peg-out in which the owner U [a] returns the second digital asset WA [a] on the side chain BC (SC) to the parent BC (Mch) side.

(2-3) Renewal of memberships constituting the coalition Next, regarding the federation Fed formed by two or more approver terminals Fm [i] (1 ≦ i ≦ I) who make a decision by majority vote. The mechanism for updating the membership of the member approver terminal Fm [i] (1 ≦ i ≦ I) will be described with reference to FIGS. 6 and 7. In the examples shown in FIGS. 6 and 7, the approver terminal Fm [i] is a member of the federation Fed by mutual election between the approver terminals Fm [i] (1 ≦ i ≦ I) based on the first criterion. The membership of (1 ≦ i ≦ I) is updated as follows.

For the approver terminal Fm [h] (1 ≦ h ≦ H), which is the initial member of the federation Fed at the start of the new side chain BC (SC), the block that started the side chain BC (SC). It can be determined in a reasonably distributed manner from the people trusted by the chain user U [0]. However, after that, the existing approver terminal Fm [i] (1 ≦ i ≦ I) can be evaluated, and the membership of the approver terminal Fm [i] (1 ≦ i ≦ I) forming the federation Fed can be changed. Mechanism is required. It either accepts the new approver terminal Fm [z1] as a new member by the existing approver terminal Fm [i] (1 ≦ i ≦ I) belonging to the federation Fed (scenario shown in FIG. 6) or is existing. This can be achieved by a voting VT that determines based on a majority vote whether to exclude the approver terminal Fm [z2] from the federation Fed (scenario shown in FIG. 7).

Next, a scenario in which a new approver terminal Fm [z1] is accepted as a new member when updating the membership constituting the federation Fed by voting VT within the federation Fed will be described in detail with reference to FIG. In the scenario shown in FIG. 6A, the terminal UT [y] operated by the terminal user U [y] has the same data structure as the lists LT [A] and LT [B] shown in FIG. It is assumed that the list LT [G] is set in advance. Further, at the start of the scenario shown in FIG. 6A, the existing members constituting the federation Fed are described as a plurality of approver terminals Fm [k] (1 ≦ k ≦ n).

When the scenario shown in FIG. 6A is started, the terminal UT [y] executes the participation request transaction Tx [y, 6] with the address YA “y” associated with the queue PCM as the destination. (Step ST21 shown in FIG. 6). Now, the approver terminal Fm [y]], which is one of the plurality of approver terminals Fm [k] (1 ≦ k ≦ n), is the participation request transaction Tx [y, 6] to the address YA [y]. The following description will be given on the assumption that an incoming call has been detected. With the execution of the participation request transaction Tx [y, 6], the terminal UT [y] is included in the list LT [G] associated with itself. The entry information is advertised to all the nodes in the parent BC (Mch). As described above with reference to FIGS. 2 and 4, each entry information is a block chain that can be supported by the terminal UT [y]. -The type of protocol, the types of digital assets that can be supported for each protocol type, and the prohibited remittance destination addresses for each protocol type are listed.

On the other hand, the approver terminal Fm [y "] requests the participation of a new member for the approver terminal Fm [k] (k ≠ k", 1 ≦ k ≦ n), which is another member in the federation Fed. A message notifying the start of the voting process according to the above is broadcasted (step ST23 shown in FIG. 6). After that, when the voting process described above is started, each of the approver terminals Fm [k] (1 ≦ k ≦ n) is based on the above entry information advertised in the parent BC (Mch) for the terminal UT [y]. The terminal UT [y] is evaluated (step ST22 shown in FIG. 6). As a result, each of the approver terminals Fm [k] (1 ≦ k ≦ n) determines whether the terminal UT [y] has sufficient suitability as a new member of the federation Fed, and the result of the judgment is A voting VT that agrees or disagrees with the participation request is performed according to the request (Fig. 6 (b)). Then, as a result of the voting shown in FIG. 6B, when the terminal UT [y] is finally decided to participate as a new member of the federation Fed, the terminal UT [y] is the union Fed. It is registered as a new member Fm [z1] (step ST24 shown in FIG. 6B).

In one example, each of the approver terminals Fm [k] (1 ≦ k ≦ n) has sufficient suitability for the terminal UT [y] as a new member of the Union Fed based on the following criteria: You may decide whether or not it is.
(B) Is the terminal UT [y] capable of executing a wide variety of blockchain protocols (is the number of entry information contained in the list LT [G] large)?
(B) Can the terminal UT [y] handle a wide variety of digital assets?
(C) Regarding the set of remittance destination addresses prohibited for each protocol type, is there a lot of overlap with the existing member approver terminal Fm [k] (1 ≦ k ≦ n)?

As illustrated in (c) above, regarding the set of remittance destination addresses prohibited for each protocol type, the existing members, the approver terminal Fm [k] (1 ≦ k ≦ n) and the terminal UT [y]. ], It is highly probable that it suggests the following. In other words, it is considered to suggest that there is a large disagreement between the existing coalition Fed and the terminal UT [y] regarding the policy for proper governance across multiple blockchains. From the above, the approver terminal Fm [k] (1 ≦ k ≦ n) constituting the federation Fed has an opinion between the existing federation Fed and the terminal UT [y] regarding the block chain governance policy. It is possible to determine whether or not the terminal UT [y] can participate in the federation Fed in consideration of whether or not there is a difference.

As described above, in the embodiment described above with reference to FIGS. 6 and 7, in the alternative embodiment, the criteria for selecting an appropriate approver terminal [c] as a member of the federation Fed is set for each terminal. It was based on the entry information contained in the associated list LT [G]. However, in some embodiments of the invention, the members of the Union Fed are more general when renewing the membership of the approver terminal Fm [i] (1 ≦ i ≦ I) that constitutes the Union Fed. It is also possible to select according to the standardized criteria. That is, the first criterion CR1, which is a criterion for selecting an appropriate approver terminal [c] as a member of the federation Fed, may be set as follows.

First, the following policy control data is input in advance to the approver terminal Fm [i] (1 ≦ i ≦ I), which is an existing member of the federation Fed, by operating the terminal of one or more approvers. To. The above-mentioned policy control data is data used to describe a policy request regarding the governance of an ecosystem in which digital assets are distributed across a plurality of block chains, and to perform policy control on the operation of terminals. Subsequently, in the approver terminal Fm [i] (1 ≦ i ≦ I), which is a member of the federation Fed, a standard consistent with the policy control data is generated as the first reference CR1 and set in the terminal. .. Finally, based on this first criterion CR1, the memberships constituting the federation Fed are renewed by mutual election between the approver terminals Fm [i] (1 ≦ i ≦ I).

In addition, the scenario of excluding the existing approver terminal Fm [z2] from the federation Fed when renewing the membership that constitutes the federation Fed by voting VT within the federation Fed is described in detail with reference to FIG. explain. At the start of the scenario shown in FIG. 7A, the existing members constituting the federation Fed are referred to as a plurality of approver terminals Fm [k] (1 ≦ k ≦ n). When a plurality of approver terminals Fm [k] (1 ≦ k ≦ n) continuously monitor the operating state of each terminal among the terminals and find a terminal ineligible as a member of the federation Fed. Advertise to all members of the Union Fed.

Specifically, when a terminal Fm [z2] ineligible as a member of the federation Fed is found in the federation Fed in the following points, the identification information of the terminal Fm [z2] is associated. Advertised to all members within the body Fed. For example, among a plurality of approver terminals Fm [k] (1 ≦ k ≦ n) belonging to the Union Fed, a terminal that is dormant for a certain period of time is considered to be ineligible as a member of the Union Fed. .. In addition, a terminal in which the communication connection with the parent BC (Mch) has been inactive for a certain period of time is also considered ineligible as a member of the federation Fed.

When the ineligible terminal Fm [z2] as described above is found in the federation Fed, a voting process similar to that described above is initiated using FIG. 6 and the approver terminal Fm [k] (1 ≦). Each of k ≦ n) evaluates the ineligibility of the terminal Fm [z2] as a member of the federation Fed. As a result, each of the approver terminal Fm [k] (1 ≦ k ≦ n) determines whether or not the terminal Fm [z2] is ineligible as a member of the federation Fed, and the terminal is determined according to the result of the determination. A vote VT agrees or disagrees with the exclusion of Fm [z2] from the members of the Fed (Fig. 7 (a)). Then, as a result of the voting shown in FIG. 7A, when it is finally decided to exclude the terminal Fm [z2] from the members of the federation Fed, the terminal Fm [z2] is the federation Fed. Excluded from the members (Fig. 7 (b)).

From the above, a predetermined default approver terminal is appointed as a member constituting the alliance in the "Federated Peg method" described in Non-Patent Document 1. As a result, the "Federated Peg method" described in Non-Patent Document 1 does not provide a mechanism or procedure for selecting a new approver terminal each time as needed. On the other hand, in the "Federated Gateway system" according to some embodiments of the present invention, existing members Fm [i] (1 ≦ i ≦ m) who participate in voting within the federation Fed vote. Then, the approver terminal Fm [z1] to be a new member is selected according to the voting result.

In the "Federated Gateway system" according to some embodiments of the present invention, the above mechanism of selecting a new member by voting of an existing member who has the right to vote in the coalition is executed as an on-chain mechanism. To. This on-chain mechanism clarifies the selection criteria for the new approver terminal fm [z1], and decides to add a new approver terminal Fm [z1] or delete the existing approver terminal Fm [z2]. The transparency of the process to be done is maintained.

(2-4) Technical Advantages of the System According to the Embodiment of the Present Invention Next, regarding the embodiment of the present invention, the "Federated Gateway system" shown in FIGS. 1 to 5 and the conventional "Federated Peg method" described above. The technical effect of the "Federated Gateway system" according to the embodiment of the present invention will be described with reference to the above. The reliability of crypto assets transferred from the parent BC (Mch) to the side chain BC (SC) and their transactions depends entirely on the reliability guarantee capability on the public chain side, and the side chain BC ( SC) itself does not guarantee the reliability. Further, the following can be considered as the conventional purposes of using the side chain BC (SC) attached to the existing parent BC (Mch).

(A) Implement a new script extension on the sidechain side for the purpose of adding a new script extension with almost no changes to the existing implementation or operation rules on the parent BC (Mch) (for example). Since Bitcoin cannot realize script processing that can execute smart contracts, the sidechain side handles private smart contract processing between the seller and the purchaser).
(B) When verifying the validity of transaction data from the parent BC (Mch) such as Bitcoin through "two-way pegs", on a full node (which requires expensive and high processing power hardware). It enables verification of validity based on SPV certification (Simplified Payment Verification Proof) that can be executed even on a lightweight client such as a smartphone, instead of PoW certification (Proof of work) that can only be executed.

On the other hand, the conventional "side chain technology" and the conventional "Federated Peg method" have the following problems.
(A) As an example of implementing the conventional side chain technology and Federated Peg method, implementation of a bidirectional peg function for transferring Bitcoin corresponding to UTXO between the parent BC (Mch) and the side chain BC (SC). There is only an example. In other words, the parent BC cannot realize BCN that can trade any crypto asset that can be remitted by the account-based decentralized consensus building protocol. In particular, in the conventional implementation example (Non-Patent Document 1), there is only an implementation example in which a bitcoin corresponding to UTXO is bidirectionally pegged between the parent BC and the side chain BC. In addition, the two-way peg mechanism is difficult to implement on the parent BC side in a blockchain that trades Bitcoin that does not support UTXO. Similarly, the two-way peg mechanism is difficult to implement in any blockchain that can trade any Alt Coin or any token other than Bitcoin.

(B) In a system in which a side chain BC is attached to a parent BC based on the existing side chain technology, in addition to validity verification within a single block chain and application of decentralized consensus building rules, both sides of the block chain It is necessary to implement a mechanism for validation verification and application of distributed consensus building rules when facing pegs. Also, a single crypto asset is effectively associated with multiple blockchains, and each blockchain can also handle multiple different crypto assets per blockchain, resulting in crypto assets. Management and transaction monitoring become more complicated and difficult. Also, regarding the implementation of the wallet function on the user terminal, it is possible to support multiple different virtual currencies and any various tokens at the same time without being aware of the difference in type (with the same user interface and the same user operability). (See Non-Patent Document 1).

(C) If it is more profitable to mine a specific side chain BC instead of the parent BC, the cryptocurrency miner will focus on mining that side chain BC. As a result, there may be a shortage of nodes that provide Computing Power to the parent BC side. In that case, a serious shortage of the computing power supply required for the maintenance and growth of the blockchain may occur on the parent BC side (see Non-Patent Document 1).
In addition, in the conventional "Federated Peg method", since there is a one-to-one correspondence between the bitcoin pegged on the side chain BC and the bitcoin on the parent BC, a fee is charged when executing a transaction on the side chain BC. The fees to be charged will also be billed and settled with Bitcoin. As a result, the ups and downs of the Bitcoin price are directly reflected in the commission price within the side chain BC, making it difficult for the operation manager of the blockchain system to make policy adjustments.

(D) Another problem with bi-directional peckable sidechains is the type of crypto assets transferred between chains by bi-directional pegs or the source of the peg-in / out request is legal, ideological and strategic. It may not be desirable from a practical point of view. To address this issue, it is necessary to manage whether or not a particular user should tolerate attempts to peg in / peg out a particular cryptocurrency according to certain control rules. Furthermore, in order to realize management based on the above control rules, whether or not the type of cryptocurrency subject to peg in / out is an acceptable crypto asset or the use that is acceptable to the requester who requested peg in / out. There is also a need for a mechanism to specifically determine whether or not a person is a person.

On the other hand, in the "Federated Gateway system" according to some embodiments of the present invention, regarding the currency type of the digital asset to be pegged and the protocol for executing the pegin, the approver terminals Fm [i1] and Fm [ The currency types and protocols supported by i2] may differ from each other. Therefore, it is necessary to provide a mechanism for appropriately handling individual block-chain transfer requests even when different currency types corresponding to different protocols are mixed. Therefore, in the conventional "Federated Peg method", all approver terminals handle only Bitcoin, which is simple, but in the "Federated Gateway system" according to some embodiments of the present invention, different protocols are supported. We have realized a more advanced mechanism that can deal with the situation where different currency types are mixed as follows.

That is, in the "Federated Gateway system" according to some embodiments of the present invention, the majority decision-making is initiated by the federation Fed shown in FIGS. 1 to 5. After that, a majority vote within the Fed will determine whether inter-block chain transfers should be allowed based on certain licensing criteria. As a result, when it is determined that permission is permitted, a new second digital asset WC [u] having an economic value equivalent to that of the first digital asset VC [u] (u = a, b, c, d) is issued. , Perform block-chain transfer. This second digital asset WC [u] is on the side chain BC (SC) side using a versatile distributed consensus building protocol that can perform transaction approval and balance verification independent of the type of digital asset. It is issued as a unique token Tk that can be traded.

Based on the above, according to some embodiments of the present invention, it is possible to realize transfer of cryptocurrency assets to and from a blockchain capable of trading any cryptocurrency assets other than Bitcoin or Bitcoin that does not support UTXO. it can. In addition, according to some embodiments of the present invention, it is managed according to a control rule based on a plurality of viewpoints whether or not a specific user should tolerate an attempt to transfer a specific crypto asset between blockchains. It is possible to realize a mechanism to do so. In particular, according to the embodiments shown in FIGS. 2 and 4, individual remittance destinations and digital assets to be transferred in inter-block chain transfer are based on the permission list and prohibition list set in each approver terminal. It is possible to determine whether or not the type of is permitted.

As a result, by selecting approvers based on policy or control rules, it is possible to ensure consistency between the licensing criteria for peg-in and peg-out requests and the member selection criteria for the approver's federation. This makes it possible to adapt the membership selection criteria of the coalition as the guidelines that direct how to determine the licensing criteria for peg-in and peg-out requests change.

This unique token Tk can be traded on the parent BC (Mch) side using a versatile decentralized consensus building protocol that can execute transaction approval and balance verification regardless of the type of digital asset. Issued as a digital asset. At that time, an account-based protocol may be used as an example of the distributed consensus building protocol used when the approver terminal Fm [y] executes the transfer between blocks and chains. Here, the account-based protocol is a decentralized agreement formation protocol that supports any cryptocurrency that circulates as a key currency, and is versatile enough to perform transaction approval and balance verification regardless of the type of digital asset. It is a protocol having.

Then, in this embodiment, the second digital asset WC [a] trades on the side chain BC (SC) side using the account-based decentralized consensus building protocol corresponding to the first digital asset VC [a]. Is issued as a unique token Tk that can be used. Further, in this embodiment, as a unique token Tk that can be traded on the side chain BC (SC) side using the account-based distributed consensus building protocol, it can be exchanged for an existing cryptocurrency at an adjustable variable rate. Undistributed digital assets can be adopted.

<3> Software and hardware that implement the basic functions of the block chain By the way, in the above-mentioned inter-block chain transfer system with reference to FIGS. 1 to 7, the transaction details of the digital assets owned by each owner are justified. It is necessary to implement basic mechanisms such as the formation of decentralized agreements on gender and the authentication of owners of digital assets. In general, the above-mentioned distributed consensus building process includes a process performed between nodes regarding electronic signature of a transaction, transaction approval, and balance verification. Therefore, how these basic mechanisms are executed on what kind of hardware configuration and how they are realized as specific information processing by software will be described with reference to FIGS. 8 to 14.

In the implementation example shown in FIG. 8, a network 1 that holds a plurality of blocks is provided by a block chain, and the network 1 includes a plurality of nodes 3a to 3c. The plurality of nodes 3a to 3c are computers having, for example, a processor or memory. Further, a plurality of terminal devices 2a, 2b, 2c are connected to the network 1, the terminal device 2a is used by the user 8 who desires to issue a digital certificate for the digital asset 4a, and the terminal devices 2b, 2c are systems. Used by the managers 9a and 9b of.

When the user 8 wishes to issue an electronic certificate certifying that the owner of the digital asset 4a is the user 8, the user 8 inputs the digital asset 4a into the terminal device 2a and inputs the digital asset 4a into the terminal device 2a. Instructs registration of 4a in network 1. Then, the terminal device 2a creates a block 4 (first block) including the digital asset 4a owned by the user 8. The block 4 includes an electronic signature 4b created by encrypting the digital asset 4a of the user 8 with the private key of the user 8. Further, the block 4 may include an identifier that uniquely identifies the user 8.

The terminal device 2a transmits the registration request of the created block 4 to one of the plurality of block chain nodes 3a to 3c in the network 1. The plurality of blockchain nodes 3a to 3c distribute and hold the block 4 by the blockchain in response to the registration request of the block 4. The plurality of second terminal devices 2b and 2c acquire blocks 4, 4-1 (second block) including the digital asset 4a from the network 1 as approval target blocks. The plurality of second terminal devices 2b and 2c include electronic signatures 5a and 5n indicating registration approval of the digital asset 4a and approval target blocks 4,4-1 in response to input from the managers 9a and 9b. Create blocks 4-1 and 4-2. That is, the approval target blocks 4, 4-1 with the electronic signatures 5a and 5n added are the new blocks 4-1 and 4-2.

For example, when the managers 9a and 9b confirm and confirm that the owner of the digital asset 4a included in the approval target blocks 4 and 4-1 is the user 8 by another procedure such as offline, the administrator 9a and 9b can confirm. Enter the registration approval. Then, the plurality of second terminal devices 2b and 2c output the registration request of the blocks 4-1 and 4-2 to the network 1. The plurality of blockchain nodes 3a to 3c distribute and hold blocks 4-1 and 4-2 by the blockchain in response to the registration request of blocks 4-1 and 4-2.

If there is a signature number-satisfied block in which the number of electronic signatures 5a and 5n to be included reaches a predetermined number among the held blocks 4,4-1 and 4-2, this is indicated by the plurality of nodes 3a to 3c. One of them detects it. In the example of FIG. 1, it is assumed that the node 3c detects that the block 4-2 is the signature number satisfying block. Then, the node 3c creates a block 4-3 (third block) including the digital certificate 6 certifying that the owner of the digital asset 4a is the user 8 and the block 4-2.

For example, node 3c has a certificate issuing unit 7 including a smart contract. The certificate issuing unit 7 assigns the digital signature 6a (validation electronic signature) of the certificate issuing unit 7 to the digital asset 4a to obtain the digital certificate 6. The electronic signature 6a of the certificate issuing unit 7 is also the electronic signature of the node 3c. Then, a plurality of nodes 3a to 3c distribute and hold the created blocks 4-3 by a block chain. In this way, the blocks 4-3 to which the digital certificate 6 is attached are distributed and held by the block chain, so that the digital asset 4a is activated and any user can use the terminal device used by himself / herself. Can be used to refer to block 4-3. Further, the digital certificate 6 included in the block 4-3 confirms that the owner of the digital asset 4a included in the block 4-3 is the user 8.

For example, a terminal device (not shown) used by a user who uses the digital asset 4a acquires the public key (public key of the certificate issuing unit 7) of the nodes 3a to 3c itself from the nodes 3a to 3c, and the terminal. The device verifies the validity of the digital certificate 6 with the acquired public key. For example, the terminal device decrypts the digital signature included in the digital certificate 6 with the acquired public key, and if the decrypted data matches the digital asset 4a, the terminal device determines that the digital certificate 6 is correct. If the terminal device can be verified correctly, it can be determined that the owner of the digital asset 4a is the user 8, and if the block 4-3 includes the identifier of the user 8, the owner of the digital asset 4a can determine that. It can be seen that the user 8 is indicated by the identifier. If the digital asset 4a is the public key of the user 8, the user who uses the digital asset 4a securely encrypts the data transmitted to the user 8's identifier with the public key. Can be sent to.

The user 8 can invalidate the activated digital asset 4a at the will of the user 8. For example, the terminal device 2a outputs a block registration request including a flag indicating destruction and block 4-3 to the network 1 in response to receiving an input instructing the destruction of the digital asset 4a from the user 8. .. The plurality of nodes 3a to 3c distribute and hold the corresponding blocks by the block chain in response to the registration request. When any one of the plurality of nodes 3a to 3c detects that the held block contains a flag indicating discard, the nodes 3a to 3c digitally sign the information contained in the block. Generate a block containing (electronic signature for invalidation) and its block. Then, the plurality of nodes 3a to 3c distribute and hold the generated blocks by the block chain.

When one of the blockchain nodes digitally signs a block containing a flag indicating destruction, the digital asset 4a included in the block becomes invalid. In this way, when invalidating the digital asset 4a, the user 8 only needs to perform the registration procedure of the block indicating the destruction, and the trouble of the administrator is not required. As a result, the digital asset 4a can be quickly invalidated.

The terminal device 2a is an electronic signature in which the information in the block 4-3 is encrypted with the private key of the user 8 in the block generated when the user 8 receives the input instructing the destruction of the certification target information 4a. The owner's electronic signature) may be included. When the plurality of nodes 3a to 3c detect that the block held in response to the registration request includes a flag indicating destruction, the electronic signature of the user 8 is decrypted with the public key (owner public key) of the user 8. .. Subsequently, the decrypted data is compared with the information in the block 4-3, and if they match, it is determined that the electronic signature of the user 8 is valid. When it is confirmed that the electronic signature is valid, the plurality of nodes 3a to 3c generate a block including the node's own electronic signature for the information contained in the block and the block, and are distributed by the block chain. Hold. In this way, by adding the electronic signature of the user 8 to the block indicating the destruction of the digital asset 4a and invalidating the digital asset 4a after verifying the electronic signature, the digital asset is created by a third party other than the user 8. It is possible to prevent 4a from being invalidated.

Next, an implementation example in which the issuance and management of digital certificates in BCN (Blockchain Network) is realized without using a centrally managed server will be described with reference to FIG. Hereinafter, the digital certificate will be simply referred to as a certificate, and BCN can pass electronic information even if some nodes are down, and high availability is realized. In the implementation example shown in FIG. 9, a plurality of nodes 200, 200a to 200f are connected via network switches 31 to 35. Each of the nodes 200, 200a to 200f is a computer that functions as one node on the BCN. Further, a plurality of terminal devices 100, 100a to 100c are connected to the network shown in FIG. The plurality of terminal devices 100, 100a to 100c are computers used by users 41, 42 who perform transactions via the network, or network administrators 51, 52.

FIG. 10 shows a configuration example of the hardware of the terminal device 100 (100a to 100c) used in the mounting example of FIG. 8, and the entire device of the terminal device 100 (100a to 100c) is controlled by the processor 101. There is. A memory 102 and a plurality of peripheral devices are connected to the processor 101 via a bus 109. The memory 102 is used as the main storage device of the terminal device 100. In the memory 102, a program to be executed by the processor 101 is read, and various data necessary for processing by the processor 101 are stored. The peripheral device connected to the bus 109 includes an OS program, an application program, and a storage device 103 that stores various data and writes and reads the data. Further, the peripheral devices include a graphic processing device 104, an input interface 105, an optical drive device 106, a device connection interface 107, and a network interface 108.

The graphic processing device 104 displays an image on the screen of the monitor 21 in accordance with an instruction from the processor 101. The input interface 105 transmits signals sent from the keyboard 22 and the mouse 23 to the processor 101. The optical drive device 106 reads the data recorded on the optical disk 24. The device connection interface 107 is a communication interface for connecting peripheral devices to the terminal device 100, and can connect the memory device 25 and the memory reader / writer 26. The memory device 25 is a recording medium capable of communicating with the device connection interface 107, and the memory reader / writer 26 reads and writes data to and from the memory card 27. The network interface 108 transmits / receives data to / from the outside via the network switch 31. The same applies to the hardware configurations of the nodes 200, 200a to 200f, the terminal devices 2a to 2c, and the nodes 3a to 3c.

The terminal devices 100, 100a to 100c or the nodes 200, 200a to 200f realize their respective processing functions by, for example, executing a program recorded on a computer-readable recording medium. For example, the program is stored in the storage device 103 (or the optical disk 24, the memory device 25, the memory card 27, etc.), and the processor 101 loads the program into the memory 102 and executes the program. This program can be executed after being installed in the storage device 103, for example, under the control of the processor 101.

In the implementation examples shown in FIGS. 8 and 9, a system having such a hardware configuration is used to issue and manage certificates using a blockchain. FIG. 11 shows an example of the BCNs shown in FIGS. 8 and 9, and two BCNs (60, 61) are provided. BCN (60) is a blockchain network for storing blocks 60a and 60b related to electronic information trading. BCN (61) is a BCN used to store blocks 61a, 61b for certificates.

Hereinafter, the functions possessed by the terminal device and the node in order to carry out the processing related to BCN (60, 61) will be described. FIG. 12 is a block diagram showing an example of the functions of the terminal device and the node, and the terminal device 100 used by the user 41 has an OS (110) and a Web browser (120). The Web browser (120) has a certificate utilization unit 121 that requests and refers to a public key registration, and the certificate utilization unit 121 sends a public key registration request, a public key destruction request, and so on. Performs processing such as using the public key of another user. The terminal device 100a used by the administrator 51 has an OS (110a) and a Web browser (120a), and the Web browser (120a) has a certificate management unit 122a that performs a certificate issuance procedure. ..

Node 200 has an OS 210, a Web server 220, and a blockchain subsystem 230. The blockchain subsystem 230 distributes and holds blocks via two BCNs (60,61). For example, the block chain subsystem 230 has a block storage unit 231 and stores a block acquired from the terminal device 100 or another block chain node 200a in the block storage unit 231. The blockchain subsystem 230 also has a smart contract 232 that issues and invalidates certificates on BCN (61).

Similarly, the node 200a has an OS (210a), a Web server 220a, and a blockchain subsystem 230a. The blockchain subsystem 230a has a block storage unit 231a for holding a block and a smart contract 232a for issuing or invalidating a certificate. The user 41, who is a blockchain participant, uses the terminal device 100 to perform a transaction via BCN (60), and also performs proof of identity by a certificate via BCN (61). The administrator 51 manages the electronic information held by the BCN (60) and issues and manages the certificate held by the BCN (61) by using the terminal device 100a.

For example, the user 41 uses the terminal device 100 to create data including the value of the reference flag “0” (registration) and the public key, and digitally signs the data with his / her private key. Digital signature is to encrypt the data to be signed or the hash value of the data with a private key. Hereinafter, the encrypted data generated by digitally signing is simply referred to as "signature". Then, the user 41 registers the signed data on the BCN (61) by using the terminal device 100a. At this time, each participant keeps the private key. The administrator 51 uses the terminal device 100a to create data in which his / her signature is given to the block before issuing the certificate (reference flag is “0”). Then, the administrator 51 registers the created data on the BCN (61) using the terminal device 100a.

When the smart contract 232,232a on the blockchain network 61 confirms the number of approved blocks in excess of the specified number, the reference flag of the block is set to a value "1" (valid) larger than "0". Change to. Further, the smart contract 232,232a generates a block in which the signature of the smart contract 232,232a is given to the block. Then, the smart contract 232,232a requests that the generated block be newly registered in the blockchain subsystems 230 and 230a as a public key certificate.

The other user who sends the electronic information to the user 41 encrypts the information to send the public key included in the certificate of the reference flag whose value is larger than "0" registered on the BCN (61) to the user 41. Used for. To invalidate the public key certificate of the user 41, the user 41 digitally signs the data in which the value of the reference flag is set to "-1" (invalid), and requests the blockchain subsystem 230 to register. The smart contract 232 reads the block whose reference flag value is "-1" and verifies by signature whether the user 41 has registered. If the smart contract 232 can be verified, the block is signed by the smart contract 232 itself and registered in the blockchain subsystem 230. As a result, the certificate can be invalidated without bothering the administrator 51.

<4> Information processing system infrastructure for constructing a block chain system On the other hand, the basic mechanism of the block chain described above using FIGS. 8 to 12 (electronic signature of transaction, approval, verification of balance, etc.) is It is often realized by using a cloud computing platform, a server cluster, etc. as an information processing platform. Therefore, in the system implementation examples shown in FIGS. 13 and 14, it is used for a cloud computing platform, a server cluster, or the like that implements the above-mentioned basic blockchain mechanism using FIGS. 8 to 12. We have realized a system in which a person's information terminal can communicate and connect. In this system, it is possible to access the blockchain-related functions provided in the system from the user's information terminal. Further, the system implementation examples shown in FIGS. 13 and 14 are configured as an information system in which a multi-layer structure related to information processing is realized by a plurality of server devices, similar to a Web site having a Multi-Tier configuration.

As shown in FIG. 13, system 500 has one or more applications 502 that need to access backend system 504 through communication path 506. The back-end system 504 has, for example, one or more components 504 (504A, 504B, ..., 504N) that make up BCN (Blockchain Network), and one or more applications make up BCN. Access one or more components. Each application 502 can be run by a computer device, which uses known communication and data protocols and APIs to connect to and interact with the back-end system 504 through communication path 506. be able to. For example, each computer device can run application 502 to perform a dialogue with the components of BCN.

The back-end system 504 and the components 504 of BCN can be implemented using one or more computational resources and can be connected to one or more data sources 508 via a communication path 506. The back-end system 504 and the component 504 of BCN can communicate with the data source 108 using the standards, protocols, and / or APIs for each data source, and the application 502 is of the BCN. The components 504 (504A-504N) can be accessed.

An example of the application stack of each application 502 is shown in FIG. Each application stack includes an application layer 502A, a service layer 502B, and a data layer 502C. Since only the resource identifier, digital asset signature, and authorization consent are stored in the blockchain, the processing of the resource itself and the processing of accessing the resource are performed by the participating applications.

In the example shown in FIG. 14, application layer 502A includes API registries, actor registries, service registries, product registries, data registries and transformations, events, workflows, authorizations and delegations. Service layer 502B includes blockchain transactions, data distribution elements, network node management, and access control. The data layer 502C includes peer-to-peer file transfer, graph data storage, identifier management, and encryption and key management elements. The structure and relationship of the block database are shown in the lower half of FIG. As shown, each block header 300 holds a portion of the data in the distributed database, a block hash, and a Merkle root, and is associated with the block transaction and its corresponding data.

Mch Parent BC (Public Chain)
SC (SC1, SC2) Side chain BC (Side chain)
Tx [u, v] (u = 1, ..., μ, v = 1, ..., γ) Transaction Fm [i] (1 ≦ i ≦ I) Approver terminal Fed Approver terminal association UT [i] ( 1 ≤ i ≤ I) User terminal (owner terminal)
U [i] (1 ≤ i ≤ I) User (owner of digital assets)
VC [a], VC [b], VC [c], VC [d], VC1 1st digital asset WC [a], WC [b], WC [c], WC [d], VC2 2nd digital asset VT Voting IA [i] (1 ≤ i ≤ I) Primary deposit address WA [i, j] (1 ≤ i ≤ I, 1 ≤ j ≤ J) Remittance destination address XA [i] Asset freeze address QA, YA address PCM queue
1 Network 2a, 2b, 2c Terminal equipment 3a, 3b, 3c Node 4,4-1,4-2,4-3 Block 4a Certification target information 4b, 5a, 5n, 6a Electronic signature 6 Electronic certificate 7 Certificate issuance Part 8 User 9a, 9b Administrator 100 Terminal device 101 Processor 102 Memory 104 Graphic processing device 105 Input interface 106 Optical drive device 200, 200a to 200f Node 300 Block header 500 System 502 Application 502A Application layer 502B Service layer 502C Data layer 504 Back-end system 506 Communication path 504 (504A, ..., 504N) BCN (Blockchain Network)
508 Data source

Claims (10)

In a system that transfers digital assets, including one or more types of electromagnetic records, that can circulate asset values by sending and receiving digital information via remittance transactions between block chains.
An owner terminal that sends a request to transfer the first digital asset owned by the owner on the first block chain to the first address owned by the owner on the second block chain by inter-block chain transfer.
An alliance formed by two or more approver terminals that make majority decisions and configured to renew membership by mutual election between the approver terminals based on the first criterion.
The at least one approver terminal in the coalition that has detected the request
A second digital that has an economic value equivalent to that of the first digital asset when it is determined that the block-chain transfer can be permitted based on a predetermined licensing standard by initiating the decision-making by the majority vote. Issue a new asset, execute the block-chain transfer,
The second digital asset can be traded on the second block chain side using a versatile decentralized consensus building protocol that can execute transaction approval and balance verification regardless of the type of digital asset. A system characterized by being issued as a unique token. The owner terminal broadcasts a first transaction for transferring the first digital asset from the approver terminal to a second address designated on the first block chain.
At least one approver terminal constituting the alliance
When the first transaction is received at the second address, a vote is made by the majority vote in the coalition to decide whether or not to transfer between the block chains to the first address notified from the owner terminal as the remittance destination. Perform a communication procedure that causes the coalition to initiate the process
When the transfer between blocks and chains is permitted, a second transaction in which the second digital asset having an economic value equivalent to that of the first digital asset is newly issued and the second digital asset is transferred to the first address. Is configured to be broadcast to the second block chain.
The system according to claim 1, wherein the system is characterized by the above. A request for inter-block chain transfer for returning the second digital asset to the first block chain is received from the owner terminal using the third address that the owner has on the first block chain as a remittance destination. The approver terminal is
The third transaction of generating an asset freeze address on the second block chain to make the second digital asset virtually unusable in the future and transferring the second digital asset to the asset freeze address is the same. Send information,
When the third transaction is received at the asset freeze address, a fourth transaction for transferring the unique token between blocks and chains is generated using the third address notified from the owner terminal as a remittance destination.
When the third transaction is permitted as a result of executing the voting process for the decision based on the majority vote in the coalition, the unique token is transferred to the third address via the third transaction. 2. The system of claim 2, wherein the second digital asset is configured to return to the first block chain. One or more approvers perform terminal operations to enter policy control data into one or more of the approvers terminals that describe policy requirements for governing an ecosystem in which digital assets circulate across multiple blockchains. When done,
The approver terminal sets a list that serves as the authorization standard that is consistent with the policy control data, and sets the type of the first address and the first digital asset that are the remittance destinations on the second block chain side. By examining according to the above list, it is judged whether or not the transfer between block chains is permitted.
The list lists the pairs that should be permitted for inter-block chain transfer among the pairs consisting of the type of the digital asset that is the target of inter-block chain transfer and the address that is the remittance destination of the inter-block chain transfer. The system according to any one of claims 1 to 3, wherein the system includes a permission list and a prohibition list listing the pairs for which transfer between block chains should be prohibited. One or more approvers perform terminal operations to enter policy control data into one or more of the approvers terminals that describe policy requirements for governing an ecosystem in which digital assets circulate across multiple blockchains. When this is done, a criterion consistent with the policy control data is set as the first criterion.
It is configured to renew membership by mutual election between the approver terminals based on the first criterion.
The system according to any one of claims 1 to 4, wherein the system is characterized by the above. When the voting process of determining the permission or disapproval of the inter-block chain transfer by the majority vote in the coalition is started, the approver terminal receiving the first transaction from the owner terminal receives the voting based on the second criterion. Execute the process of selecting other approver terminals to participate in the process,
A feature of the voting process is that a plurality of the approver terminals selected based on the second criterion make a decision by majority vote to determine whether or not to allow the transfer between blocks and chains. The system according to any one of claims 1 to 4. The decentralized agreement formation protocol, which has versatility to perform transaction approval and balance verification regardless of the type of digital asset, uses an account-based protocol corresponding to any cryptocurrency circulating as a key currency. Realized,
The second digital asset is issued as the proprietary token that can be traded on the second block chain side using the account-based protocol corresponding to the first digital asset, at an adjustable variable rate. An undistributed digital asset that can be exchanged for existing cryptocurrencies,
The system according to any one of claims 1 to 4, wherein the system is characterized by the above. At least one approver terminal constituting the alliance
When the request to transfer the first digital asset on the first block chain to the first address on the second block chain as a remittance destination is received from the owner terminal, it is unique to the owner. The second address is created on the first block chain and assigned to the owner terminal.
The owner terminal sends the request to at least one approver terminal constituting the coalition, and then the approver terminal assigns the second address on the first block chain to the second address. 1 Broadcast the first transaction for transferring digital assets,
The system according to any one of claims 1 to 7, wherein the system is characterized by the above. At least one approver terminal constituting the alliance locks the first digital asset in response to the reception of the first transaction, and the locked state of the first digital asset is between block chains. Claims 1 to 1, wherein the unique token transferred to the second block chain by the transfer is maintained until it is returned to the first block chain by the reverse block-chain transfer. The system according to any one of 8. Embedding the first address as a remittance destination on the second block chain for the first transaction of transferring the first digital asset owned by the owner from the owner terminal to the approver terminal. Notifies the first address to at least one approver terminal belonging to the federation.
By embedding the third address as a remittance destination on the first block chain for the third transaction that transfers the second digital asset to the asset freeze address, the third address is made into the union. Notify at least one of the approver terminals belonging to
The system according to any one of claims 1 to 9, wherein the system is characterized by the above.