JP2020127187A - Method for storing transaction representing asset transfer in distributed network having multiple nodes, program therefor, and node for configuring distributed network - Google Patents

Abstract

To greatly improve transaction processing speed in a method for storing a transaction representing the transfer of an asset in a distributed network.SOLUTION: A first partial network 110 that constitutes a distributed network receives a transaction 200 generated by a user terminal 140, and representing the transfer of an asset 203 from a transfer source identifier 201 to a transfer destination identifier 202, and generates a block including the transaction 200, and executes consensus building processing in the first partial network 110 for adoption (S303). Each node stores the state of the asset of the transfer source identifier that can be processed by the node, and the transfer of the asset from transfer source identifier described in one or more transactions included in the block added after total formation is recorded (S304). The transfer source identifier that can be processed in each partial network is defined, and therefore, parallel processing of transactions is executed.SELECTED DRAWING: Figure 3

Description

The present invention relates to a method for storing a transaction representing an asset transfer in a distributed network having a plurality of nodes, a program therefor, and nodes for configuring the distributed network.

A blockchain network that builds a database on a distributed network consisting of multiple nodes is highly tamper resistant due to its decentralized nature. This is because it is difficult to rewrite the entire distributed network even if the database is tampered with at any node. The block chains stored in each node function as a database in synchronization with each other.

The increase in the number of nodes increases the resistance to tampering, but on the other hand, it is necessary to store the same block chain in each node, so that the processing speed for selecting a block is generally reduced. Intuitively, it seems that the processing speed per unit time can be improved by increasing the number of nodes, but in the block chain, it will decrease conversely, so the block size will increase, and 1 or At present, various attempts have been made to reduce the data capacity of multiple transactions.

However, it is not possible to find one that can greatly improve the scalability among various attempts at present. In particular, when considering realistically managing the transfer of assets such as virtual currencies, real currencies, and stocks in a database on a distributed network, bitcoins that can handle a few transactions per second are First of all, scalability is an urgent issue in the practical application of blockchain.

The present invention has been made in view of the above problems, and an object of the present invention is to configure a method for storing a transaction representing asset transfer in a distributed network having a plurality of nodes, a program therefor, and the distributed network. In the node for doing so, it is to greatly improve the transaction processing speed per unit time.

In order to achieve such an object, a first aspect of the present invention is a method of storing a transaction representing transfer of assets in a distributed network having a plurality of partial networks, the method including: A first transaction in which a node forming the first partial network represents transfer of an asset from a transfer source identifier processable in the first partial network to a transfer destination identifier not processable in the first partial network. Receiving, the step of generating a block containing the first transaction, and the step of updating the status of the asset of the source identifier after consensus formation in the first partial network for adoption of the block. A second transaction for reflecting the transfer of the asset to the transferee identifier represented by the first transaction after consensus formation in the first sub-network for adoption of the block, the second transaction Sending a source identifier that matches the destination identifier of one transaction to a processable second sub-network.

Further, a second aspect of the present invention is characterized in that, in the first aspect, the first transaction is added with a signature by a secret key of the transfer source identifier.

Further, a third aspect of the present invention is characterized in that, in the first or second aspect, the amount of the transferred asset is a positive value.

A fourth aspect of the present invention is the method according to any one of the first to third aspects, wherein the second transaction is added with a signature indicating that consensus has been formed in the first partial network. It is characterized by being

Further, a fifth aspect of the present invention is characterized in that, in the fourth aspect, the signature of the second transaction is a single signature.

A sixth aspect of the present invention is the mark of a Merkle tree according to the fourth or fifth aspect, wherein the signature of the second transaction is based on a plurality of transactions including the first transaction in the block. It is characterized in that it is a signature for a block header including a route.

Further, a seventh aspect of the present invention is a method for storing a transaction representing an asset transfer in a distributed network having a plurality of partial networks in a node forming a first partial network of a plurality of partial networks. A program for executing the method, wherein the node transfers an asset from a transfer source identifier processable in the first partial network to a transfer destination identifier not processable in the first partial network. Receiving a first transaction representing the first transaction, generating a block containing the first transaction, and concluding an agreement in the first sub-network for adoption of the block, and A second step for reflecting the transfer of the asset to the transferee identifier represented by the first transaction after the step of updating the state and after consensus in the first sub-network on the adoption of the block; Is transmitted to the second partial network capable of processing the source identifier that matches the destination identifier of the first transaction.

Further, an eighth aspect of the present invention is a node constituting a first partial network of the plurality of partial networks for storing a transaction representing the transfer of assets in a distributed network having a plurality of partial networks. And receiving a first transaction representing a transfer of an asset from a source identifier processable in the first partial network to a destination identifier not processable in the first partial network, the first transaction Generating a block including the transaction of the block, updating the status of the asset of the transfer source identifier after consensus formation in the first partial network for adoption of the block, and the first partial network for adoption of the block. In the second transaction for reflecting the transfer of the asset to the transfer destination identifier represented by the first transaction, the transfer source that matches the transfer destination identifier of the first transaction. It is characterized in that the identifier is transmitted to a second partial network that can be processed.

A ninth aspect of the present invention is a method of storing a transaction representing transfer of assets in a distributed network having a plurality of partial networks, which constitutes a first partial network of the plurality of partial networks. The node receiving a first transaction representing a transfer of an asset from a source identifier processable in the first partial network to a destination identifier not processable in the first partial network; Generating a first block containing one transaction, updating the status of the asset of the source identifier after consensus formation in the first sub-network for adoption of the first block, After consensus formation in the first sub-network for adoption of the first block, a second transaction for reflecting the transfer of the asset to the transferee identifier represented by the first transaction is Sending a transfer source identifier matching the transfer destination identifier of the first transaction to a processable second partial network, wherein a node configuring the second partial network executes the second transaction. Receiving, generating a second block containing the second transaction, and after consensus in the second sub-network about adoption of the second block, transferee of the second transaction Updating the asset status of the identifier.

Further, a tenth aspect of the present invention is a distributed network having a plurality of partial networks for storing a transaction representing the transfer of assets, the first partial network and the second partial network of the plurality of partial networks. Of the assets from the transfer source identifier that can be processed by the first partial network to the transfer destination identifier that cannot be processed by the first partial network. After receiving a first transaction representing a transfer, generating a first block containing the first transaction, and after forming an agreement in the first sub-network for adoption of the first block, the transfer source Updating the status of the asset of the identifier and reflecting the transfer of the asset to the transferee identifier represented by the first transaction after consensus in the first sub-network on the adoption of the first block; A second transaction for transmitting the second transaction to the second partial network capable of processing a transfer source identifier that matches the transfer destination identifier of the first transaction, and a node forming the second partial network, The second transaction is received after receiving the second transaction, generating a second block containing the second transaction, and after consensus formation in the second sub-network for adoption of the second block. The state of the asset of the transfer destination identifier of is updated.

According to an aspect of the present invention, a distributed network is configured by a plurality of partial networks, and a transfer source identifier that can be processed in each partial network is defined, thereby performing parallel processing of transactions and simultaneously processing a plurality of transactions. Becomes feasible.

It is a figure which shows the distributed network concerning one Embodiment of this invention. It is a schematic diagram of the normal transaction concerning one Embodiment of this invention. It is a figure for explaining the flow of the method of storing the transaction concerning one embodiment of the present invention. It is a schematic diagram of a peg transaction according to an embodiment of the present invention. It is a figure for demonstrating the consensus formation process in one Embodiment of this invention. 6 is a flowchart of a key generation method for consensus building according to an embodiment of the present invention. 7 is a flowchart of a method for determining block adoption according to an embodiment of the present invention. It is a schematic diagram of the peg transaction concerning another embodiment of the present invention. It is a figure for demonstrating the Merkle tree data concerning another embodiment of the present invention. It is a schematic diagram of the peg transaction concerning another embodiment of the present invention.

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

FIG. 1 shows a distributed network according to an embodiment of the present invention. The distributed network 100 has a plurality of partial networks that operate differently depending on the transfer source of the asset in the transaction to be stored in the database constructed on the distributed network 100. Although FIG. 1 shows the first partial network 110, the second partial network 120, and the third partial network 130, the number of partial networks is not limited to three.

Each partial network is composed of a plurality of nodes, and each node stores a communication unit 111A such as a communication interface, a processing unit 111B such as a processor and a CPU, and a storage device or a storage medium such as a memory and a hard disk. It can be configured by including a unit 111C and executing a program for performing each process. Each node may include one or a plurality of devices or servers, the program may include one or a plurality of programs, and a non-transitory program recorded in a computer-readable storage medium. Can be a product.

In the user terminal 140, a transaction representing a transfer from the transfer source identifier 201 such as the transfer source address of the asset 203 to the transfer destination identifier 202 such as the transfer destination address is generated. An application for generating such a transaction can be installed in the user terminal 140 or can be used in the user terminal 140 via a computer network such as the Internet.

With reference to FIG. 3, a method of storing a transaction representing the transfer of assets according to the present embodiment will be described. First, the transaction 200 representing the transfer of the asset 203 such as virtual currency from the transfer source identifier 201 to the transfer destination identifier 202 is generated in the user terminal 140 (S301). In the transaction 200, the transfer source identifier 201, the transfer destination identifier 202, and the amount of the transferred asset 203 are described, and a signature 204 with a secret key associated with the transfer source identifier 201 is added. For example, the private key of the transfer source identifier 201 is managed so that only the user terminal 140 or the user of the user terminal 140 can access it, and only that user can legitimately transfer the asset from the transfer destination identifier 201. ..

Next, the user terminal 140 transmits a recording request request for the transaction 200 to the distributed network 100 (S302). A value or range of a transfer source identifier capable of processing the received transaction by itself is set in each partial network. In this embodiment, the application of the user terminal 140 can process the transfer source identifier and each partial network. The transmission destination of the recording request request of the transaction 200 is determined by referring to the correspondence with the value or range of the transfer source identifier. In the example of FIGS. 1 and 2, the first partial network 110 will receive the transaction 200.

More specifically, when transmitting the transaction 200 to the first partial network 110, the transaction 200 is transmitted to one or a plurality of nodes forming the first partial network 110. The node 111 that has received the transaction 200 stores the transaction 200 in the storage unit 111C or a storage medium or storage device accessible from the node for subsequent processing. The node 111, which has received the transaction 200 as necessary, transmits the transaction 200 to the other nodes configuring the first partial network 110, and among the plurality of nodes configuring the first partial network 110, the block adoption is performed. It will be stored in the nodes that participate in consensus building.

Then, one of the nodes 111 constituting the first partial network 110 generates a block including one or a plurality of transactions stored so far, and the first partial network 110 for adoption thereof. A consensus building process is performed (S303). When the consensus is formed, each node participating in the consensus formation adds the block to the block chain stored in each node. Each node of the first partial network 110 stores the public key corresponding to the private key of the transfer source identifier processable in the first partial network 110, and the signature 204 of the signature 204 is received when a transaction is received or a block is generated. It is possible to verify the effectiveness. The details of the consensus building process performed in the first partial network 110 will be described later. The public key is not stored in advance in each node, but whether the transaction 200 includes a public key corresponding to the private key of the signature 204 added to the transaction 200, or the public key is added to the transaction 200. Or may be calculable from the signature 204.

In addition to the blockchain, each node stores the association between the asset state and the identifier that holds the state of the asset associated with the transfer source identifier that can be processed by each node, and stores the block in the blockchain. After the addition, the transfer of the asset from the transfer source identifier described in one or more transactions included in the added block is recorded (S304). The association is not limited to the table format, but may be referred to as “asset table” for convenience. Further, the association may be stored in a storage medium or a storage device accessible from each node.

More specifically, as an example, the transfer source identifier and the transfer destination identifier processable in the distributed network 100 are a 10-digit symbol string starting with “A”, a 10-digit symbol string starting with “B”, and a “C”. Consider the case where it is a starting 10-digit symbol string. Then, the first partial network 110 has a transfer source identifier that starts with “A”, the second partial network 120 has a transfer source identifier that starts with “B”, and the third partial network 130 has a transfer source identifier that starts with “C”. It is assumed that processing is possible. In response to the agreement formation regarding the block including the transaction 200 in which the transfer source identifier 201 “A13afb3sdf” is described in the first partial network 110, each of the nodes 111 of the first partial network 110 stores each. The asset balance of the identifier “A13afb3sdf” in the asset table to be updated is updated. Specifically, the asset balance of the transfer source identifier “A13afb3sdf” is reduced by 10 BTC.

Then, the node that generated the added block or another node of the first partial network can process the transfer destination identifier in the first partial network 110 among the one or more transactions included in the added block. The transaction 400 corresponding to the transaction that does not match the transfer source identifier is transmitted to the partial network in which the transfer destination identifier matches the transfer source identifier that can be processed in the own network (S305).

Here, the transaction 400 is described as being generated after the asset table is updated, but these may be reversed. If the consensus building process (S303) includes verification that the amount of assets transferred from the transfer source identifier of each transaction included in the block is equal to or more than the balance of the transfer source identifier, the order may be reversed. If it is not included, the update processing (S304) of the asset table includes the verification that the amount of the transferred asset is equal to or more than the balance, and the transaction 400 of the transaction 400 is provided on the condition that the verification result is positive. The transmission may be executed.

Taking the transaction 400 of FIG. 4 corresponding to the transaction 200 shown in FIG. 2 as an example, the transaction 400 indicates the transfer of the asset 203 represented by the transaction 200 stored in the first partial network 110 to the transfer destination identifier 202. Is to be reflected in the processable second partial network 120, and the amounts of the transfer source identifier 401, the transfer destination identifier 402, and the transferred asset 403 are described. Unlike the transaction 200 of FIG. 2, in the transaction 400 of FIG. 4, the attached signature 404 indicates that the block containing the transaction 200 has been agreed upon for its adoption in the first partial network 110, ie, the block. It is a signature indicating that it has been added to the chain. In FIG. 4, the signature 404 is shown as “A”. Details of the signature 404 will be described later.

In the following, since the transaction 400 is for maintaining the consistency of the asset state between the partial networks and is what is called a peg, it is sometimes called a “peg transaction”, and the signature 404 is a “peg signature”. Sometimes called.

In the second partial network 120 that has received the peg transaction 400, one of the nodes generates a block including the peg transaction 400, and after the consensus forming process (S306) for adoption of the block is performed, the block chain of each node Added to. Each node of the second partial network 120 stores the public key corresponding to the private key of the transfer source identifier processable in the second partial network 120, and the public key associated with the peg signature by another partial network. I remember. By verifying the peg signature 404 of the transaction 400 as valid with the public key, it is possible to determine that the transaction 400 is a peg transaction. The public key is not stored in each node in advance, but whether the peg transaction 400 includes the public key corresponding to the private key of the signature 404 added to the transaction 400, or whether the public key is included in the transaction 200. It may be added. In any case, in each partial network, in other words, in which partial network the public key corresponding to the private key of the signature 404 added to the peg transaction 400 corresponds to the private key that can be signed. It is possible to confirm which partial network the so-called holder of the public key belongs to.

In order to distinguish whether the transaction received by a certain partial network is the normal transaction 200 or the peg transaction 400, it is conceivable to judge by the public key used for verifying the signature as described above. It is also possible to make a determination based on That is, if the transfer source identifier is not a transfer source identifier processable in the own network and the transfer destination identifier matches any of the transfer source identifiers processable in the own network, the transaction can be determined as a peg transaction 400. Is.

After the block is added, for the peg transaction 400 included in the block, each node updates the asset balance of the transfer destination identifier 402 of the peg transaction 400 and records the transfer of the asset 203 (S307). In the normal transaction 200, the asset balance of the transfer source identifier 201 of the asset 203 is updated as described above, while in the peg transaction 400, the asset balance of the transfer destination identifier 402 is updated. The transfer destination identifier 402 of the peg transaction 400 matches one of the transfer source identifiers that can be processed by the second partial network 120, and each node of the second partial network 120 can be accessed from the storage unit of each node or each node. The storage medium or storage device can be updated by referring to the correspondence between the transfer source identifier processable in the own network and the state of the asset associated with the identifier.

As described above, by configuring the distributed network with a plurality of partial networks and determining transfer source identifiers that can be processed in each partial network, it is possible to perform parallel processing of transactions and execute processing of multiple transactions at the same time. Become. Therefore, the transaction processing speed per unit time can be significantly improved.

In the above description, in the application used by the user terminal 140, it is assumed that the destination of the recording request request of the transaction 200 is determined by referring to the correspondence between the transfer source identifier and the value or range of the processable transfer source identifier. As described above, the transaction 200 may be transmitted to one or a plurality of partial networks, and the transaction 200 may be transferred to the partial network which can be processed unless the transaction 200 can process itself in the received partial network. Further, a forwarding node (not shown) is provided in the distributed network 100, the transaction 200 that is first transmitted from the user terminal 140 is received in the forwarding node, and the transaction 200 can be processed according to the value of the transmission source identifier 201. You may determine a partial network.

Further, in the above description, the destination of the peg transaction 400 is described as being defined in the first partial network 110, but it is conceivable that the transmission is performed in the same manner as the destination of the normal transaction 200.

Further, in the above description, the amount of the asset 203 is not particularly restricted, but it is preferable to process it as an invalid transaction if the balance is insufficient when verifying the transaction 200 as a positive value. When the value is a negative value, that is, when the transfer source identifier 201 receives the asset 203, the asset balance of the transfer destination identifier 202 is not managed in the asset table of the first network 110. However, even if a block including the transaction is added in the first partial network 110, the second partial network 120 may be processed as invalid due to insufficient balance of the transfer destination identifier 202. Occurs.

If there is no description of “only” such as “based only on XX”, “according to only XX”, “in the case of only XX”, in this specification, additional information It should be noted that it is assumed that can also be considered. Also, as an example, it should be noted that the description “b in the case of a” does not necessarily mean “always b in the case of a” unless explicitly stated.

Also, as a precaution, even if some method, program, terminal, device, server or system (hereinafter “method etc.”) has an aspect that performs an operation different from the operation described in this specification, each of the present invention The aspect is intended for the same operation as any one of the operations described in the present specification, and the existence of an operation different from the operation described in the present specification means that the method etc. It is added that it does not fall outside the scope of the embodiment.

Consensus building details Consensus building in a sub-network can be done under various consensus algorithms. As an example, k (k is an integer of 2 or more) of N (N is an integer of 2 or more) nodes participating in consensus building. Is an integer that satisfies 2≦k≦N). Considering the example of N=5 and k=3, this means that a signature by the majority of the nodes participating in consensus formation is required. Then, in order to show that the consensus is formed and the adoption of the block for which the consensus is formed is confirmed, it is necessary to add k or more signatures as a basis.

As described above, there are many possible combinations of nodes in which the signature by the k nodes can satisfy the predetermined condition in the agreement algorithm, depending on the values of N and k. There are aspects that complicate the handling of. This is because, for example, in order to subsequently verify the signature of a block, it is necessary to individually confirm whether or not a plurality of signatures attached to the block satisfy a predetermined condition. Therefore, it is preferable that a single signature as described below is used to indicate that agreement has been reached regarding the selection of blocks in the partial network. This applies not only to the consensus formation regarding the adoption of the block but also the consensus formation for adding the peg signature 404 to the peg transaction 400.

The network 500 illustrated in FIG. 5 has N of 5 as an example, and includes a first node 510, a second node 520, a third node 530, a fourth node 540, and a fifth node 550. As illustrated for the first node 510, each node includes a communication unit 511 such as a communication interface, a processing unit 512 such as a processor and a CPU, and a storage unit 513 including a storage device or a storage medium such as a memory and a hard disk. It is a computer provided with, and each processing described below can be realized by executing a predetermined program. The node 510 may include one or a plurality of devices or servers, and the program is One or a plurality of programs may be included, and the program can be recorded in a computer-readable storage medium to provide a non-transitory program product. The hardware configurations of the other nodes are similar. Although the first node 510 will be mainly described below, similar processing can be performed in other nodes. The network 500 may include nodes that do not participate in consensus building.

The predetermined program defines the rules related to the agreement algorithm and the rules related to the setup, and should be stored in a storage device or a storage medium accessible from the storage unit 513 or the first node 510 via the network. You can

A process to be executed in order for N nodes participating in consensus building to transition from a state in which they can communicate with each other to a state in which consensus building regarding block adoption can be executed is called “setup”. The setup is started by receiving a setup request from outside or inside the network 500, and FIG. 5 shows an example in which the request is transmitted from the outside. The request may include the number k of signatures required for consensus formation, and may be set in advance in a rule concerning setup. Further, the request can include designation of N nodes that participate in consensus building, and this designation may be defined in advance in a rule relating to setup.

When the values of N and k are determined in any form, and the execution of the setup process proceeds, each node has one public key assigned to all nodes participating in consensus formation, each node participating in consensus formation. Will hold N public key shares assigned to the node, and 1 private key share assigned to the node. Further, each node also holds the values of N and k or the value of k/N. The value of N can also be obtained from the number of public key shares.

The private key and the public key have a relationship that the plaintext signed by the private key can be verified by the public key, and the same applies to the private key share and the corresponding public key share. Here, the “secret key share” is generated so that a signature with a secret key can be generated using a signature with a predetermined number k of secret key shares out of a set of N secret key shares. One of a set of private key shares. Therefore, without knowing the secret key, a signature corresponding to the public key can be generated based on k secret key shares, and the signature can be added to the block for which consensus is formed. The added signature can be verified by the public key.

To further explain the example in FIG. 5, one public key assigned to the entire network 500 is PK (abbreviation of Public Key), a secret key corresponding to the public key is SK (abbreviation of Secret Key), and the first node 510, the second node 520, the third node 530, the fourth node 540, and the fifth node 550 are assigned public key shares and secret key shares PK1 and SK1, PK2 and SK2, PK3 and SK3, respectively. , PK4 and SK4, PK5 and SK5. After the setup, for example, the first node stores PK, PK1 to PK5, and SK1 in its storage unit 513 or a storage device or storage medium that can communicate with the node. These stored data will be accessible from the node in the subsequent consensus building process or its concluding process.

Here, the public key PK is necessary for verification of the finally added signature, but may not be generated at the setup stage. This is because the node or device that verifies the signature only needs to have the public key PK at the time of verification, and each node of the network 500 does not necessarily have to have the public key PK at the time of initial setting.

FIG. 6 shows the flow of these key generation methods according to this embodiment. Here, as an example, consider a (k−1)th degree polynomial f(x), and each value of f(xi) (i is an integer from 1 to N representing the i-th node, and xi is an arbitrary integer) The private key share SKi for the node is assumed.

First, the i-th node determines a (k-1)th degree polynomial fi(x) having aim (m is an integer from 0 to k-1) as a coefficient (S601). Each node can calculate fi(x) by selecting or generating aim and storing it according to the setup rule.

Next, the i-th node uses the generator g1 of the cyclic group G1 to transmit the value of aim·g1 in each m from 0 to k−1 or a message including the value to another node (S602). Further, the i-th node transmits the value of fi(xj) or a message including it to the j-th node (j is an integer from 1 to N). Here, fi(xj) may be transmitted before m and aim·g1, or may be transmitted at the same time.
The generator g1 is stored in each node and known, or given from one of the nodes to the N nodes participating in consensus formation, the N nodes can access and use it. It should be possible. Similarly, with respect to the value of the integer xi that gives the secret key share f(xi) to the i-th node, each of the N nodes can access and can be used. For example, these values may be stored in a storage unit of each node or a storage device or storage medium accessible from each node.

Then, in the j-th node, fi(xj) is added for i from 1 to N to calculate f(xj), that is, the secret key share SKj (S604). If the polynomial f(x) is defined as

Although this is not known to any node, by considering f(xj) as in the following equation, the value of f(xj) can be calculated without each node knowing f(xj) itself. It can be calculated at each node.

Further, since each node can calculate m and aim·g1 at its own node and already has received from other nodes, SKj·g1 is calculated as the public key share PKj according to the following equation. It is possible (S206).

The calculation of the public key share PKi by this formula is possible for all nodes without knowing f(x) because m and aim.g1 and xi are known for all i.

The pair of the public key share and the secret key share obtained in this way is a hash function that gives the hash value h of the block for which consensus is to be formed, which is a mapping from arbitrary data to the cyclic group G2 whose source is g2, By defining SKj·h obtained by multiplying h by SKj as a signature sj, a mapping e from G1×G2 to a cyclic group GT whose generator is gT, and a bilinear mapping satisfying the following equation is defined. It can be seen that Here, a and b are arbitrary integers.

That is, when the i-th node receives the hash value h and the signature sj of the block for consensus formation from the j-th node, using the public key share PKj known by the above algorithm,

Therefore, the signature sj received from the j-th node can be verified using the known generator g1. The hash value may be calculated from the consensus building target block at each node by defining a hash function in the setup rule.

The order of the generators g1 and g2 is preferably a prime number, and the number of elements of the cyclic groups G1 and G2 generated by each generator is preferably 32 bytes, that is, about 256 bits or more. Here, the operations in the cyclic groups G1 and G2 are described additively. For example, the operation of repeatedly adding the generator g1 a times a is expressed as a·g1 and is called “multiply a by the generator g1”. .. Note that the multiplication of elements of a set of integers such as ax is also used as a notation in this specification, but it should be noted that this is different from multiplication in the cyclic additive group.

In the above description, the value of the (k−1)th degree polynomial function f(x) is defined as the secret key share, and the public key share is a value obtained by multiplying the secret key share by the generator of the cyclic group. However, if a signature with a secret key can be generated using signatures with a predetermined number k of secret key shares out of a set of N secret key shares, different signature schemes can be adopted. In this case, instead of giving a set of secret key shares generated by any node of the network 500 or a node outside thereof to each node, each secret key share can be generated in a distributed manner in each node. Is desirable.

Further, in the above description, the public key share PKj and the secret key share SKj in the j-th node have been described as an example, but when describing the processing performed there centering on the i-th node, it is natural. , Addition that the subscripts are changed appropriately.

FIG. 7 shows a flow of a method for determining a block selection according to an embodiment of the present invention. From the state where the setup is completed, the first node 510 generates a block and transmits the first message including the block to the N nodes participating in consensus formation (S701). The transmitting node can also receive the block itself. Here, messages can be directly or indirectly transmitted and received between the nodes, and data related to consensus building can be transmitted to other nodes constituting the network 100 and data can be received from the other nodes. ..

Each node that receives the first message evaluates the effectiveness of the block based on the consensus building rules defined in the programs that the nodes have (S702). Details of effectiveness evaluation include various things such as whether the sender is a legitimate sender node, whether the data format of the block satisfies a certain format and other certain conditions according to the application, whether branching has occurred, etc. Rules may be included, and different rules may exist depending on the node. In addition, it may be necessary to send and receive messages to and from other nodes in order to evaluate the effectiveness.

If the node is evaluated as valid, the node transmits to each node a second message having the signature si for the hash value h of the block for which consensus is formed by the secret key share f(xi) accessible by the node ( S703-1). The signature can be performed by multiplying the hash value by the secret key share given to the node. The destination may include its own node. If the block is evaluated as invalid, the block is rejected (S703-2).

After k signatures are collected at the jth node, the node synthesizes these signatures to generate a signature corresponding to the public key PK (S704). Specifically, each node periodically or intermittently determines whether or not the condition of k/N is satisfied, and if satisfied, receives k or k or more secret key shares. F(0)·h can be calculated as the signature SK·h by the private key SK corresponding to the public key PK from the signature by Here, the (k-1)th degree polynomial f(x) can be uniquely determined if k or more points (xi, f(xi)) are known, and the value of f(0) is unknown. What is considered as the value of the secret key SK is used. If k points (xi, f(xi)·h) are known from the k signatures, the function f(x)·h is determined. The calculation of f(0)·h can be performed using, for example, Lagrange interpolation.

The public key PK can be calculated, for example, by Lagrange interpolation from k or more points (xj, PKj)=(xj, f(xj)·g1). This can be done at the setup stage. It may be distributed as needed, or it may be generated by a node or device inside or outside the network 500 for verifying a signature based on the k public key shares PKj at the time of verification or before verification. ..

Then, if necessary, the generated single signature SK·h is broadcast or transmitted to other nodes (S705). Since the effectiveness of k or more nodes has already been evaluated, it may be possible to add a block to the block chain of the node at the time of successful synthesis. Each node may be able to add a block in response to transmitting the combined signature to the node and receiving a predetermined number or more of combined signatures.

Finally, the block for consensus formation is added to the block chain of each node with the signature SK·h added (S706). As a result, the adoption of the block in the network 700 is confirmed.

In the above description, the case where one secret key share is given to each node is considered, but it is also possible to give a plurality of shares to one node. Further, in the above description, the details of the block to be evaluated for validity are not mentioned, but the block may include one or a plurality of transactions, or may include any one or a plurality of data. it can. It is also possible to apply the spirit of the present invention to the evaluation of effectiveness by a computer network having a plurality of nodes for one or a plurality of data that do not necessarily form a chain.

Details of Peg Signature The peg signature 404 can be generated by an agreement algorithm that is the same as or corresponding to the agreement algorithm used for consensus formation regarding the adoption of the block in the first partial network 110. Alternatively, it can be generated by a consensus algorithm different from the consensus algorithm adopted in the selection of the blocks in the first partial network 110.

In any case, the peg signature 404 may be, for example, one or more signatures with one or more private keys for the hash value of the peg transaction 400 or a portion thereof. The second partial network 120 that has received the peg transaction 400 verifies the validity of the peg signature 404 when the peg transaction 400 is received or when the block including the peg transaction 400 is generated.

According to this method, the transfer destination identifier included in the block does not match the transfer source identifier processable in the first partial network 110, even though the consensus is once formed for the adoption of the block. For every transaction, a corresponding peg transaction 400 must be generated and consensus formed for each to be signed as the first partial network 110. As the number of partial networks increases, the number of transactions in which the transfer destination identifier does not match the transfer source identifier processable in the first partial network 110 also increases, and the consensus forming process increases.

Therefore, another method uses the Merkle tree. In order to generate the peg signature 404, first, a plurality of transactions included in a block added in the first partial network 110 or a transfer source identifier of the transfer destination of the transactions that can be processed in the first partial network 110 is transferred. Compute the Merkle root of a Merkle tree based on transactions that do not match the identifier. The signature of the Merkle root with the private key is set as the peg signature 404.

The peg transaction 400 corresponds to the normal transaction 200 in which the transfer destination identifier does not match the transfer source identifier processable in the first partial network 110, and is used to verify the validity of the peg signature 404 in addition to the peg signature 404. Merkle tree data M for one or more necessary nodes is added. Here, in the present specification, “merkle tree data” is data of one or a plurality of nodes forming the Merkle tree, and specifically, one or a plurality of hash values. The peg transaction 400 is data that matches the normal transaction 200 or includes the normal transaction 200, generates a hash value of the peg transaction 400 or a part thereof, and receives the hash value and the peg transaction 400 and the Merkle tree data M. It is possible to calculate the Merkle root by using and to verify whether the peg signature 404 is a signature for the Merkle root using the public key of the first partial network 110. For example, ECDSA can be used as the encryption method. In the case of ECDSA, the public key can be calculated from the signature.

FIG. 9 shows an example of the Merkle tree. It is assumed that a block including four transactions has been added to the first partial network 110. Then, it is assumed that the peg transaction 400 corresponding to the second transaction tx2 is transmitted to the second partial network 120. In this case, since the hash value of the second transaction tx2 is obtained as the hash value of the peg transaction 400 or a part thereof, the hash value of the node 1 and the hash value of the node 6 are sent to the peg transaction 400 as the Merkle tree data M. If added, the Merkle route of the node 7 can be calculated in the second partial network 120.

If the signature for the block added in the first partial network 110 is the signature for the block header of the block and the signature includes the Merkle root of the Merkle tree of the block, the signature for the block is unchanged. It can be used as the peg signature 404. In this case, in addition to the Merkle tree data M, the block header or data B obtained by removing the Merkle tree root from the block header is added to the peg transaction 400, and the block header is generated in the second partial network 120. Then, it is possible to verify whether the peg signature 404 is a signature for the block header using the public key of the first partial network 110.

As another method, it is conceivable to send the entire block added in the first partial network 110 to the second partial network 120 as the peg transaction 400. In this case, since the block includes a transaction whose transfer destination identifier does not match the transfer source identifier processable by the second partial network 120, unnecessary data is transmitted, but the first data is transmitted. The additional signature to the peg transaction 400 in the partial network 110 can be omitted, and the signature added in the consensus formation regarding the block adoption can be directly considered as the peg signature 404.

In this method, in the second partial network 120 that has received the block (corresponding to the “first block”), the transfer destination identifier included in the block is a transfer source that can be processed by the second partial network 120. A block (corresponding to a "second block") including one or a plurality of transactions that match the identifier or these corresponding transactions is generated and is an object of consensus formation.

100 distributed network 110 first partial network 111 node of first partial network 111A communication unit 111B processing unit 111C storage unit 120 second partial network 130 third partial network 140 user terminal 200 normal transaction 201 transfer source identifier 202 transfer Destination identifier 203 Asset 204 Signature 400 Peg transaction 401 Transfer source identifier 402 Transfer destination identifier 403 Asset 404 Peg signature 500 Network 510 First node 511 Communication unit 512 Processing unit 513 Storage unit 520 Second node 530 Third node 540th 4 node 550 Fifth node B Block header or data obtained by removing the Merkle tree root from the block header M Merkle tree data 1 to 7 Merkle tree nodes

Claims (8)

A method of storing a transaction representing an asset transfer in a distributed network having a plurality of sub-networks, wherein a node constituting a first sub-network of the plurality of sub-networks comprises:
Receiving a first transaction representing the transfer of an asset from a source identifier processable in the first partial network to a destination identifier not processable in the first partial network;
Generating a block containing the first transaction;
Updating the status of the asset of the source identifier after consensus in the first sub-network on adoption of the block;
After consensus in the first sub-network on the adoption of the block, a second transaction for reflecting the transfer of the asset to the transfer destination identifier represented by the first transaction, the first transaction, Sending a source identifier corresponding to the destination identifier of the transaction to a processable second sub-network. The method according to claim 1, wherein the first transaction has a signature added by a private key of the transfer source identifier. The method according to claim 1, wherein the second transaction is added with a signature indicating that consensus has been formed in the first partial network. The signature of the second transaction is a signature for a block header including a Merkle root of a Merkle tree based on a plurality of transactions including the first transaction in the block. the method of. A program for causing a node constituting a first partial network of a plurality of partial networks to execute a method of storing a transaction representing transfer of assets in a distributed network having the plurality of partial networks, the method comprising: Is the node
Receiving a first transaction representing the transfer of an asset from a source identifier processable in the first partial network to a destination identifier not processable in the first partial network;
Generating a block containing the first transaction;
Updating the status of the asset of the source identifier after consensus in the first sub-network on adoption of the block;
After consensus in the first sub-network on the adoption of the block, a second transaction for reflecting the transfer of the asset to the transfer destination identifier represented by the first transaction, the first transaction, Sending a transfer source identifier that matches the transfer destination identifier of the transaction to a processable second partial network. A node constituting a first sub-network of said plurality of sub-networks for storing a transaction representing an asset transfer in a distributed network having a plurality of sub-networks,
Receiving a first transaction representing a transfer of an asset from a source identifier processable in the first partial network to a destination identifier not processable in the first partial network, and executing the first transaction Generate a block containing
Updating consensus in the first sub-network on adoption of the block, updating the state of the asset of the source identifier,
After consensus in the first sub-network on the adoption of the block, a second transaction for reflecting the transfer of the asset to the transfer destination identifier represented by the first transaction, the first transaction, A transfer source identifier that matches the transfer destination identifier of the transaction of 1. to the processable second partial network. A method of storing a transaction representing an asset transfer in a distributed network having a plurality of sub-networks, wherein a node constituting a first sub-network of the plurality of sub-networks comprises:
Receiving a first transaction representing the transfer of an asset from a source identifier processable in the first partial network to a destination identifier not processable in the first partial network;
Generating a first block containing the first transaction;
Updating the state of the asset of the source identifier after consensus in the first sub-network for adoption of the first block,
A second transaction for reflecting the transfer of the asset to the transferee identifier represented by the first transaction after consensus formation in the first sub-network for adoption of the first block, Transmitting a transfer source identifier matching the transfer destination identifier of the first transaction to a processable second partial network, wherein the node forming the second partial network comprises:
Receiving the second transaction,
Generating a second block containing the second transaction;
Updating the status of the asset of the transferee identifier of the second transaction after consensus in the second sub-network for adoption of the second block. A distributed network having a plurality of sub-networks for storing transactions representing the transfer of assets,
A first partial network and a second partial network of the plurality of partial networks;
A node configuring the first partial network,
Receiving a first transaction representing a transfer of an asset from a source identifier processable in the first partial network to a destination identifier not processable in the first partial network, and executing the first transaction Generate a first block containing
Updating consensus in the first sub-network on the adoption of the first block, updating the state of the assets of the source identifier,
A second transaction for reflecting the transfer of the asset to the transferee identifier represented by the first transaction after consensus formation in the first sub-network for adoption of the first block, Sending a source identifier matching the destination identifier of the first transaction to a processable second partial network,
A node constituting the second partial network,
Receiving the second transaction and generating a second block containing the second transaction;
The distributed network, wherein after the consensus is formed in the second partial network regarding the adoption of the second block, the status of the asset of the transfer destination identifier of the second transaction is updated.

Images