JP7231909B2 - Information processing device and program - Google Patents

Description

The present invention relates to an information processing apparatus and program.

In recent years, distributed information systems such as distributed ledger technology have begun to be used for recording cryptocurrencies, various types of information, and circulating assets.
Here, the distributed ledger technology has a data structure that uses electronic signatures and hash pointers to easily detect tampering, and holds the data in a large number of nodes distributed on the network, thereby achieving high availability and It is a technology that realizes data identity and the like.
A ledger that electronically manages records held by participants is called a distributed ledger.
As an example of such a distributed information system, a distributed information system such as a cryptocurrency remittance system (see Non-Patent Document 1) has been proposed. In Non-Patent Document 1, distributed ledger technology eliminates the risk of double spending on a P2P network without going through a central management institution such as a financial institution, and executes safe currency remittances between individuals. A technique to do so has been proposed.
Also, a distributed information system is used to ensure the credibility of data, and a technique for managing data such as changes in rights has been proposed (see Patent Document 1).

JP 2018-55203 A

Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008.

Here, the approval of transactions (transaction records) generally performed by distributed ledger technology etc. is not performed by all participants participating in maintaining the network, but by the participants participating in maintaining the network. Among them, only participants who satisfy a predetermined condition (hereinafter referred to as "approver") execute.
However, conventional techniques including the techniques described in the above-mentioned documents have problems such as requiring a lot of time and power consumption in selecting an approver and having many security risks.

SUMMARY OF THE INVENTION The present invention has been made in view of such circumstances, and aims to provide a technique that can shorten the processing time in a distributed information processing system related to security and that can withstand a large increase in the number of processes to be executed. aim.

In order to achieve the above object, an information processing device according to one aspect of the present invention includes:
An information processing device used for managing a network composed of n (n is an arbitrary integer value of 1 or more) other information processing devices,
role setting means for setting a role for each of the n other information processing devices;
connection destination determining means for determining a connection destination of each of the n other information processing apparatuses based on the set role;
Prepare.

A program corresponding to the information processing apparatus of one aspect of the present invention is also provided as the information processing method of one aspect of the present invention.

ADVANTAGE OF THE INVENTION According to this invention, the technique which shortens the processing time in the distributed information processing system regarding security, and can withstand a large increase in the processing which should be performed can be provided.

1 is a diagram showing the concept of a hierarchical network structure related to a GLS system including an information processing device according to an embodiment of the present invention; FIG. FIG. 2 is a diagram for explaining an example of SN functions in the GLS system; 1 illustrates an example of a ring-type network structure for the GLS system; FIG. FIG. 3 is a diagram showing an example of a series of processing flows from generation of a transaction to completion of various types of processing in the GLS system; FIG. 3 is a diagram for explaining an example of functions of a signal node in the GLS system; FIG. FIG. 6 is a diagram for explaining an example of the functions of a signal node in the GLS system, and is a diagram showing an example different from the example of FIG. 5; It is a figure which shows an example of a structure of a GLS system. 8 is a block diagram showing an example of the hardware configuration of RTN in the GLS system of FIG. 7; FIG. 8 is a functional block diagram showing an example of functional configurations of NN, SN, MN and RN in the GLS system of FIG. 7; FIG. 4 is an arrow chart showing an example of the flow of transaction processing in the GLS system; FIG. 11 is an arrow chart showing an example of the flow of network participation processing of a node in the GLS system; FIG. It is a figure explaining an example of the method of applying a consistent hashing method to a GLS system.

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, embodiments of the present invention will be described with reference to the drawings.

Here, before describing FIG. 1, various techniques and terminology related to the information processing apparatus according to one embodiment of the present invention will be described.

Conventionally, there is a technology called blockchain as one of the technologies used in many distributed ledger systems. With this technology, when new information is newly recorded, the blocks that make up the data unit inherit the hash associated with the previous block, linking them like a chain to store various types of information. can do.
Specifically, in a blockchain, each block is unidirectionally linked using a hash pointer, each block is given an electronic signature, a large number of transactions are included, and transactions are also indexed. It is known that it can contain elements such as linked by pointers of .
In other words, blockchain uses electronic signatures, hash pointers, etc. to maintain a data structure that makes it easy to detect falsification, and distributes and retains the data on a network to ensure high availability and identity of data. It is a technology that realizes
Blockchains are usually managed by a decentralized network such as P2P (Peer to Peer) and cannot be retroactively changed without changing all subsequent blocks. In other words, although it is not impossible to falsify information stored as a blockchain, it is considered extremely difficult in reality. For this reason, blockchain is used to manage various assets and transactions, including virtual currencies such as Bitcoin.
However, in conventional distributed information systems, problems have been pointed out regarding time and power consumption when selecting transaction approvers, and security risks.
In addition, in the method called proof of work adopted by bitcoin etc., it takes time for each server to send and receive information about the approver, and a confirmed transaction called the so-called 51% attack can be stolen by a malicious attacker. It has been pointed out that there is a security risk that unauthorized transactions may be approved by a malicious third party that could be overturned. Furthermore, there is also the problem that when a transaction is approved, it is not possible to provide a fixed state (hereinafter also referred to as “finality”) as information that is not overturned at the same time as the transaction is approved.
Furthermore, in systems related to these distributed ledgers, many participants operate computers connected to the network, and information (for example, blockchain) are shared, and many calculations are performed to approve each transaction and prevent forgery of information. As a result, a huge number of calculations are performed, so there is also the problem of a huge amount of power being consumed.

Here, a transaction is, for example, data in which an electronic signature is attached to a predetermined unit of information that records the details of a transaction, the results of various processes, and the like. An electronic signature is data obtained by signing a predetermined unit of the information described above with the private key of the transaction creator, and data to which public key information paired with the private key is added.
In other words, a transaction is information in which an electronic signature is added to the details of a transaction such as when, from whom, to whom, how much, and the results of various processes.
In addition, by approving a transaction according to a predetermined rule, at the same time as the approval or in the future, the transaction is determined as information whose falsification can be easily detected.

In other words, participants (each node) participating in a network in a distributed ledger system (hereinafter referred to as "distributed ledger network" or simply "network") verify each transaction generated by the distributed ledger network. After approval, a “blockchain” is constructed by linking multiple transactions individually or in block units.
Note that a node is each information processing device that constitutes a network.
In other words, for the approved transactions that make up the blockchain, tampering can be easily detected by linking the blocks in which the transactions are stored using hash values, etc. History can be tracked.

In this regard, an information processing system (hereinafter referred to as a "GLS system") including an information processing apparatus according to an embodiment of the present invention is a distributed information system, a block chain, and other various technologies that can be used via a network. It is an information processing system that is used for the management of assets that have been acquired.
The GLS system employs various structures (for example, hierarchical network structure) to be described later, and the roles (for example, transaction approval, etc.) of nodes existing in each hierarchy are determined in advance. Then, it is possible to assign a reliable intra-system time to a transaction to be approved by a signal (data assigned an intra-system time), which will be described later. By performing approval with reference to such accurate system internal time, the GLS system can easily determine the priority of nodes to be approved. The system time is time information referred to by each node in the GLS system.
In summary, the GLS system sets various roles for authorization according to various structures (eg, hierarchical network structure). Then, the GLS system uniquely determines the rank and order by using the time within the system that is accurately assigned to each role. As a result, in the GLS system, in the transaction approval process, each node is given a clear role including the order and order, and the problem of double approval in the conventional distributed ledger system is eliminated. Risk can be greatly reduced.

Here, transaction approval in this embodiment is executed based on the result of consistency verification by each node (especially RN described later). This consistency verification can be specifically performed from the following viewpoints, for example.
(1) The creator of the electronic signature must match the creator of the transaction. In other words, the electronic signature attached to the transaction must be by the creator and not fraudulent.
(2) The transaction data has not been tampered with (confirmation by electronic signature).
(3) The transaction in question is pending at the verifying node.
(4) Assets (data) included in the transaction are unused and properly held.
(5) The contents of the transaction are not fraudulent. For example, in the case of remittance of financial assets, the amount exceeding the amount of assets held must not be remitted.
That is, in the GLS system, each node (particularly, the RN described later) verifies the consistency of the transaction from the viewpoint as described above, thereby realizing approval of the transaction.

Subsequently, the purpose of the GLS system will be explained in more detail.
First, the generation of transactions in the distributed ledger network may be subject to certain conditions.
For example, in proof-of-work, participants compete with servers participating in a distributed ledger network to find solution data (hereinafter referred to as "nonce") that satisfies defined conditions. Then, only the participant who was able to find a nonce that satisfies the conditions generates an approved transaction based on the found nonce, sends it to the other participants, and adds the approved transaction to its own distributed ledger. Record transactions. In addition, each participant who received the approved transaction verifies the transaction stored in the approved transaction and the generation conditions, etc., to confirm that there is no fraud and It will be recorded in the type ledger.
Examples of technologies using a distributed ledger for the purpose of preventing forgery and falsification of transactions include Bitcoin (see Non-Patent Document 1, for example) and Ethereum. Various techniques (eg, proof of work) used in these methods can also be applied in the present invention.

On the other hand, the GLS system requires a certain amount of time for transaction approval, and the final settlement process is slow, and the number of transactions per second required for business use (hereinafter referred to as "TPS ( One of the purposes is to realize solutions to problems such as "cannot realize "Transaction Per Second"" and "lack of scalability to withstand network expansion".

In the GLS system, by approaching from the three perspectives of "decentralization of power", "centralization of management", and "pursued convenience", both the above-mentioned issues due to centralization and issues due to decentralization can be resolved. We aim to solve A specific description will be given below.
Decentralization of power is a fair and secure system that eliminates the disadvantages of users due to the malicious creation or falsification of data by central administrators, which has become a problem due to the centralization of information. It refers to realizing
In the GLS system, the user, as a participant, constantly verifies the consistency of all data, so that the presence or absence of malicious data or falsification can be constantly monitored.
Centralization of management refers to the realization of a system that reduces the "self-responsibility of participants" and "risks in managing assets and data", which are problems of conventional distributed ledgers. As a specific example, conventionally, a user has the risk of all assets being frozen due to the loss of a secret key or the like that is essential for asset management. A user's private key can be held as a backup by a central administrator, and responsibility for private key management can also be assumed by the central administrator.
The pursued convenience means that the GLS system realizes usability equivalent to that of a centralized system by realizing "fast processing speed" and "high scalability" required in the real world.

In other words, one of the objectives of the GLS system is, for example, in addition to the tamper resistance of the information system possessed by the above-mentioned distributed ledger technology and the characteristics of reducing the trust and responsibility required of a given party, as well as the consumption In other words, it provides a technology that solves the power problem, shortens the time required to confirm transactions, and retains processing power that can accommodate a large increase in the number of transactions to be confirmed.
In order to achieve this purpose, the GLS system employs various structures and functions such as a "hierarchical network structure" and a "circular network structure".

First, the "hierarchical network structure", which is one of the features of the GLS system, will be described.
FIG. 1 is a diagram for explaining the concept of a hierarchical network structure in the GLS system.
In the GLS system, four types of roles are set for each of the nodes constituting the network, and each node is assigned to each layer, thereby optimizing various types of processing related to transactions.
Here, the node to which the role is set includes, for example, “root node (hereinafter referred to as “RN”)”, “master node (hereinafter referred to as “MN”)”, “super node (hereinafter referred to as “SN ")" and "Normal Node (hereinafter referred to as "NN")". Next, the details of the role played by each node will be described.

The RN's role is to provide final approval in the transaction approval process in the GLS system. One node is selected as this RN from among MNs described later. A set of MNs to be selected as RNs is called a root node candidate (hereinafter referred to as "RN candidate").
This allows the GLS system to speed up the transaction approval process as a whole by limiting the number of nodes to approve. Also, since only one RN is selected, it is possible to prevent a situation in which multiple devices approve the same transaction. However, depending on the design, a plurality of RNs may simultaneously perform approval processing for different transactions.

Here, the rules for RN selection are not particularly defined and are arbitrary, but for example, an RN selection method based on permutation can be mentioned.
A method of selecting RNs by permutation will be briefly described below. The RN is selected from each candidate MN by, for example, the following method.
For example, each MN that is an RN candidate transmits information (hereinafter referred to as a "token") including the public key of each RN candidate MN and the corresponding authorization period to other MNs at regular intervals. . Each MN receives the token, compares the token with its own public key, and if it is within the period in which it is in charge of authorization, becomes an RN and executes authorization.
In this way, one of the advantages of the MN becoming an RN election candidate is that, for example, when approving a transaction, a trustworthy node (RN) is selected in advance, which enables high-speed approval processing according to a predetermined protocol. can be realized. In other words, it is possible to omit the hash value calculation based on the nonce used in the conventional distributed ledger technology, and to think that the RN can temporarily approve the transaction by acting like a central server. can be done.

In addition, the prioritization of MNs used for RN selection is performed only from past transactions that cannot be falsified as described above, making it difficult to select unauthorized RNs and ensuring transparent and fair RN selection. Function.
Further, the GLS system enforces, for example, thorough verification of transaction integrity by each node, system control to prevent unauthorized transaction approval through mutual monitoring by MNs, strict installation requirements for MNs, etc. It can also be adopted in addition to the rules, thereby more efficiently eliminating malicious falsification, etc., and realizing high processing speed while ensuring security.

The MN's role is to be a candidate for election to the RN, to send transactions to SNs and other MNs, to monitor MNs and RNs, and so on. A detailed description will be given below.
Among MNs, MNs that have not been elected as RNs have a role of monitoring the RN's approval behavior. In other words, the integrity of a transaction endorsed by an RN must be verified by each node that receives the transaction, and if an inconsistent transaction is detected, the transaction will be discarded. Therefore, even if an inconsistent transaction is sent, it will not spread to the entire network, so only consistent transactions will be connected as a chain, and as a result, only credible data will be stored on the distributed ledger. stored in
On top of that, for example, the GLS system adopts a mechanism in which an RN that maliciously approves and attempts to transmit an unauthorized transaction is registered in a blacklist managed by the MN and is excluded from RN candidates. good too.

Also, for example, the GLS system may perform control to switch the RN to be selected at fixed time intervals, for example. As a result, even if a node goes down due to various attacks on the RN or MN, other RN candidates detect the down of each node, and by continuing to approve transactions and select RNs as RNs, A situation in which the entire GLS system stops can be avoided. Therefore, by using distributed ledger technology to eliminate the single point of failure that was the weak point of servers until then, it is expected that the GLS system will distribute the system load and realize zero system downtime.

The role of the SN is to connect the NN, which has the role of issuing transactions, and the MN, which has the role of approving transactions, so as to act as an intermediary, thereby alleviating the load concentrated on each MN due to an increase in communication traffic. It is to assist the information processing of each MN. A specific description will be given below.
Although the details will be described later, the NN has a role of generating transactions, and the transactions generated by the NN are transmitted to other NNs and SNs to which the NN is connected. Then, the NN that received the transaction confirms the consistency of the digital signature, etc., stores the transaction information in its own database, etc., and transfers it to the connected NN and SN. By repeating such exchanges by each node in the same way, the transaction spreads throughout the network.
In this regard, in a conventional general distributed ledger network or the like, the latest transaction held by each is sent and received through a process of confirming the presence or absence of the latest transaction held by each. This minimizes the number of times transactions are sent and received between nodes, thereby preventing the flood of unnecessary and excessive identical transactions.
On the other hand, in the GLS system, each node (SN or NN), if the same information as the transaction received by itself is already stored in its own database or the like, does not transfer the transaction. can be discarded. As a result, the GLS system can prevent the network from being flooded with unnecessary and excessive identical transactions. In addition, since it transmits and receives without checking whether there is the latest transaction, it has the role of transmitting the transaction to the MN in the shortest possible time. The role of SN will be briefly described with reference to FIG.

FIG. 2 is a diagram for explaining the details of the role of SNs in the GLS system.
The example of FIG. 2 shows an example in which a transaction is transmitted to x NNs existing in the network, that is, an example in which x identical transactions are transmitted to one SN. It is
In this example, each NN is connected to y SNs, so a simple calculation would result in x×y identical transactions being sent to each of a plurality of SNs. If there were no SNs on the network of the GLS system, a large number of identical transactions would be sent to the MN, causing a heavy load on their processing and causing delays in the MN's approval process.
On the other hand, when SN acquires x identical transactions, SN discards x−1 identical transactions and sends only one remaining transaction to MN, so MN receives Only a minimal number of transactions will be involved, allowing the MN to focus solely on its own role, and can be expected to increase the number of transactions processed per unit time.

In addition, as described above, by placing the SN between the NN and the MN, it is possible to protect the connection from the NN, which can be an attacker, to the MN like a reverse proxy, thereby enabling high-speed access to a specific MN. It is possible to avoid load attacks and attacks such as encircling specific nodes and blocking information. This allows the GLS system to further reduce security risks and achieve transaction processing.
Specifically, for example, an NN can maliciously send a large amount of unauthorized transactions to a node to which it is connected, and the MN receives all of these unauthorized transactions. As a result, CPU resources may be used to verify the integrity of unauthorized transactions, and the MN's transaction approval processing speed may drop. , this can be circumvented.

Next, the role of the NN will be explained. The role of the NN is to generate a transaction in the GLS system and to spread the transaction to the NN and SN connected to itself.
The NN and SN in the GLS system may be connected to a plurality of arbitrarily designed same-level (homogeneous) nodes and a plurality of higher-level nodes. Therefore, for example, even if a specific node does not function normally, the transaction once transferred from the NN to the network can use another node as a detour route, and as a result reaches the MN. be able to.

Next, with reference to FIGS. 3 and 4, the "circular network structure", which is one of the features of the GLS system, will be described.
FIG. 3 is a diagram showing an example of a ring network structure for the GLS system.
In the example of FIG. 3, MN and RN are arranged in the center, SN are arranged in a circle on the outer side, and NN are arranged further on the outer side. Such a ring-shaped network structure is expected to exchange information quickly, extensively and efficiently because the distance from the center to the end (network-like) is uniform.

Here, each node, when desiring to participate in the GLS system, sends a participation application attached with an electronic signature generated using a public key and a private key stored in a storage unit (not shown) to an RTN, which will be described later. (router node). Based on arbitrary rules, the RTN determines the role of the node that is the transmission source and the connection destination node that is determined based on the role, and transmits the determined various information to each node that is the transmission source.
For example, the RTN has a list of public keys that function as MNs to SNs, and checks the list with the public key attached to the electronic signature of each node that requests participation. The role of each node may be determined by determining a predetermined role if it matches the public key registered as the respective role, and otherwise determining the role of the NN. However, the method by which the RTN determines the role of each node, the details of the role, and the criteria and method by which the connection destination is determined are arbitrary and not limited.

Next, with reference to FIG. 4, a brief description will be given of the flow from the generation of a transaction in the NN to the end of various processes. FIG. 4 is a diagram showing an example of the flow from transaction generation to completion of various processes in the GLS system.
At step SS1, the NN generates a transaction according to the details of the executed transaction, and transmits the transaction to each of the other NNs and SNs. A plurality of other NNs that have received the transaction here similarly execute the process of step SS1.

At step SS2, SN obtains the transaction sent from NN at step SS1 and verifies the integrity of the transaction.
At step SS2, the SN sends the transaction to each of the other SNs and the MNs if there is no problem with the integrity of the transaction. A plurality of other SNs that have received the transaction here similarly execute the processing of step SS2.

In step SS3, MN obtains the transaction sent by SN in step SS2 and verifies the integrity of the transaction. At step SS3, the MN sends the transaction to each of the other MNs and RNs if there is no problem with the integrity of the transaction. A plurality of other MNs that have received the transaction here similarly execute the process of step SS3.

At step SS4, the RN verifies the integrity of the transaction obtained at step SS3. At step SS4, if there is no problem with the integrity of the transaction, the RN approves the transaction and generates an approved transaction.
At step SS5, the RN sends the approved transaction generated at step SS4 to each of the MNs.

At step SS6, the MN obtains the approved transaction sent at step SS5 and verifies the integrity of the approved transaction. In step SS6, MN sends the approved transaction to SN if there is no problem with the consistency of the approved transaction. A plurality of other MNs that have received the transaction here similarly execute the process of step SS6.

At step SS7, SN obtains the approved transaction sent from MN at step SS6 and verifies the integrity of the approved transaction. In step SS7, SN sends the approved transaction to NN if there is no problem with the consistency of the approved transaction.

At step SS8, NN obtains the approved transaction sent from SN at step SS7. This completes the flow from transaction generation to the end of various processes. The details of the processing by each node will be described later with reference to FIGS. 10 and 11 and the like.

The important point here is that in the GLS system that adopts this circular network structure, the order of MN, SN, and NN does not change from the center to the end, and information transmission to each node is always completed with a fixed number of transfers. It is a point to do. In addition, by minimizing the difference in the timing of receiving information due to the positional relationship, unfairness of information for each node can be eliminated, and processing time can be shortened and optimized.
Specifically, in the example of FIG. 3, transaction A created by a given NN is sent in the order of SN and MN. When the MN becomes the RN, it approves the received transaction A and sends it in the order of MN, SN, NN, and all NNs can receive the approved transaction.
In summary, each node assigned a role by the hierarchical network structure can realize a circular self-similar structure of each node of each role by the ring structure.
Note that the ring structure referred to here means a structure in which the nodes are arranged on the network with equal network distances. Specifically, for example, a circular structure is composed of one or more multiple layers, or there is a server or the like that has information about the nodes that make up the entire network. It is sufficient to have a structure for returning information.
By realizing such a structure, the positional relationship of each node becomes even, so it is possible to prevent synchronization timing errors and information disparities due to distance problems, resulting in transaction transmission, approval, and reception. latency to is minimized. In addition, by realizing a ring-shaped network structure, it becomes easy for multiple MNs participating in the network to simultaneously execute approval processing in parallel, speeding up the transaction approval processing and ensuring scalability. .

Also, in a GLS system that employs this ring-type network structure, the number of MNs and SNs may be increased or decreased according to the amount of information flowing through the network. For example, if there are an excess of MNs relative to the amount of transactions flowing through the network, the MNs deemed redundant may automatically sleep to optimize forwarding and traffic within the network. On the other hand, when the supply of MNs is insufficient for transactions, it is also possible to use them for transaction processing by waking up sleeping MNs. The same applies to SN. Such a mechanism has advantages such as adjusting the scale of the network, reducing the number of transfers of transactions exchanged between nodes, improving the processing speed and TPS, and optimizing the power consumption of the entire network.

In addition, details of characteristic data structures that may be employed in the GLS system are described. Specifically, for example, (1) a header that manages MN, (2) a signal that manages time within the system, and (3) a transaction that employs DAG (Directed-Acyclic-Graph) that functions as a transaction record will be explained. .

<Header for managing MN>
First, the header for managing the MN will be explained.
A header is information having a data structure in which a list of RN candidates is recorded. Then, the addition to the header is performed in all RN candidates operating at that time each time the MN joins or leaves as a new RN candidate. In other words, all nodes participating in the network of the GLS system can confirm the list of MNs currently performing approval work by receiving this header information. In addition, all nodes participating in the network can verify the consistency of transactions by checking the history of past participation of all MNs in RN candidates and comparing them with predetermined approved transactions, Reliability can be guaranteed.
Furthermore, in the GLS system, a distributed ledger for managing RN candidates is prepared separately from transactions, and in the form of headers, newly entering MNs are managed. In the management of RN candidates, vulnerabilities can be further eliminated by strictly reviewing the approval of MNs that are scheduled to enter the market over time in light of the participation conditions.

<Signals that manage the time in the system>
Next, the signals used for managing the time in the system will be explained.
A signal is a data structure that records the intra-system time within the network in the GLS system, and is transmitted by a signal node, which will be described later.
Here, not only in the distributed ledger, but in the area called conventional distributed computing, there is an error in the clock value at each node on the network, and there is a time lag due to communication, and absolute time sharing is extremely difficult. It was difficult.
Therefore, in the GLS system, a signal node (hereinafter referred to as "SGN (Signal Node)") that transmits a signal containing information on the system internal time is determined in advance and arranged on the network. , and the SGNs that are arranged transmit signals at arbitrary unit time intervals, thereby realizing sharing of absolute time information.
As a result, in the GLS system, data can be controlled on the time axis in the same manner as a conventional centralized database, and finality can be imparted.
This signal is given an electronic signature by a predetermined SGN after being given information on the time in the system, and is transmitted to the network every arbitrarily set unit time. If an incorrect time is intentionally generated and attached to a transaction with malicious intent, it can be detected by verifying the electronic signature attached to the signal. As an example of the verification method, each node may have a list of public keys of official signals, and verify the correct signals by comparing them with the public keys assigned to the signals.

A more detailed description will be given with reference to FIG. FIG. 5 is a schematic diagram showing the difference in areas in charge of approval centered on signals.
In the example of FIG. 5, N1 indicates an arbitrary timing at which approval authority is switched from MN-A to MN-B. In this way, in the GLS system, the time in charge of the MN and the status of the transaction can be divided along the time axis at an arbitrary timing such as N1, so smooth and high-speed change in charge and transaction approval work can be achieved. can be executed. This signal is not used by existing distributed ledger services. Therefore, there is no clear standard as to which approver (node) is in charge of approving a transaction, and there remains the risk of multiple approvals by multiple approvers or so-called forks. In this regard, in the GLS system according to the present invention, the MN that is in charge of approving each transaction is uniquely determined by controlling the network by adopting a time axis called a signal. Therefore, for example, it is possible to decide to give priority to the transaction approved earlier on the time axis and to discard the remaining transactions. Furthermore, as a result, it is possible to prevent situations such as the double authorization described above and obtain finality in transactions.
However, the method related to transaction approval authority shown in FIG. 5 does not necessarily have to be adopted. Further, the methodology for transaction approval authority shown in FIG. 5 is exemplary only and not limiting.

<DAG that functions as a record of transactions>
Next, a DAG (Directed Cyclic Graph) used for transaction management will be described. A DAG is, for example, a directed graph without a cycle in graph theory, and is one of the technologies that can be applied in fields such as databases. Even in the GLS system, for example, by adopting DAG and linking transactions with hash or the like, there is a possibility that waiting time due to waiting for approval of transactions can be reduced.

In the GLS system, such features can be appropriately adopted, so it can be expected to realize ultra-high-speed processing while ensuring security equal to or higher than that of conventional blockchains.
As described above, by screening MNs participating in RN candidates in advance using headers, participation by malicious approvers can be prevented, and high security can be achieved.
Conventionally, with distributed ledger technology, consensus processing was required to determine a reliable node for each transaction approval. Since there is no need to select for each approval, high-speed approval is possible.

Furthermore, in the GLS system, by applying DAG to transaction management, transaction approval processing is performed in parallel, thereby ensuring scalability.
And by introducing signals, we give finality to the approval. In other words, by providing a plurality of judgment criteria including a time axis for transactions, double approval or the like can be prevented. With these features, the GLS system can process transactions at high speed and function as a highly scalable system while taking advantage of blockchain's advantages such as "tamper resistance, zero downtime, transparency and fairness". can be expected.
Here, tamper resistance means the difficulty of maliciously rewriting a transaction that has been confirmed once, and zero downtime means that the time during which various systems and services related to the GLS system stop functioning is infinitely zero. means that In addition, in the GLS system, past history can be referred to by all nodes participating in the network and always verified to ensure transparency and fairness. This is one of the features realized by allowing any participant to become a MN that can have transaction approval authority.
However, a GLS system need not always have all these features. That is, it is not particularly limited whether all of the various features described above are adopted or only some of them are adopted, and may be arbitrarily determined by the GLS system provider or the like.

<Nodes with other roles>
Here, other nodes different from the nodes to which the above roles are set will be described.
(1) Topology server (hereinafter referred to as "router node" or "RTN")
An RTN is a node that operates as a server that manages the node connection destinations of the entire network without being involved in the creation or approval of transactions like the above-mentioned various nodes (for example, RN, MN, SN, NN). be. That is, the number of MNs and SNs is adjusted according to the ratio of the number of MNs, SNs, and NNs, and the entire network in the GLS system is smoothly controlled.
In the case of a P2P (Peer-to-Peer) network or the like that is adopted in ordinary distributed ledger technology, it is extremely difficult to adjust the scale of the network because flexible network management cannot be performed. Therefore, an excessive increase in the number of traffic transfers may occur due to, for example, an increase or decrease in the number of nodes in the network. In other words, unnecessary resource consumption may occur in the entire network, resulting in increased power consumption and decreased TPS. On the other hand, in the GLS system, by adopting such a mechanism, it is possible to realize traffic adjustment and optimization of the entire network.

Note that conventional centralized servers have problems such as increased latency due to DoS attacks and the like. On the other hand, even if a direct attack on the RTN, which has a centralized server element in the GLS system, causes an increase in the server load, all the core processing of the information processing system, such as transaction approval, Since the MN executes, an increase in the server load on the RTN does not actually cause a drop in latency, and the data can be processed stably.
As for the operation method of the RTN, as described above, in the GLS system, nodes of high importance (for example, RN, MN, etc.) are, in principle, distributed. RTN is an exception to this rule.
That is, the RTN is operated by the provider of the GLS system as a starting point for the entire network when performing (1) operational maintenance of the GLS system, (2) network recovery, and (3) rollback execution. can be done. As a result, the provider of the GLS system can, for example, stop the entire network as necessary and perform work necessary for operation and management.

(2) Signal node (SGN)
The SGN is, as described above, a node that issues a signal to which system internal time is assigned in the GLS system. In the case of conventional centralized networks, such time axis is determined based on the server. However, in the area called distributed computing such as distributed ledgers, there are errors in the clock value of each node on the network and time lags due to communication, so sharing time in an absolute sense is extremely difficult. Have difficulty. In the GLS system, in order to solve such problems, the SGN is operated on the network and the entire network is controlled by signals.
Note that if there is only one SGN in the network, there is a possibility that a delay will occur in signal transmission as the network grows, causing a problem in synchronizing the network. Therefore, in the GLS system, multiple SGNs can be placed in the network to issue signals in parallel. An example of the arrangement of SGNs in a network will be specifically described below with reference to FIG.

FIG. 6 is a diagram showing an example of the arrangement of SGNs in a network.
The example of FIG. 6 shows an example in which a plurality of SGNs SGN(A) to SGN(C) are arranged in the network of the GLS system. That is, each node of SGN(A) to SGN(C) will transmit a signal to another node. This reduces the synchronization error of the entire network due to the positional relationship of the SGNs. However, in the example of FIG. 6, even if the signals transmitted from SGN(A) to SGN(C) contain errors in the clock values themselves, the respective nodes cannot receive the signals. The signal with the most recent time information is adopted as the latest one. In addition, the synchronization error may be reduced by taking the standard deviation of the signals received within an arbitrary period of time immediately after receiving the signals.

Next, an example of the configuration of the GLS system will be described with reference to FIG. FIG. 7 is a block diagram showing an example configuration of a GLS system including an information processing apparatus according to an embodiment of the present invention.

The information processing system of the present invention includes an RN1, n MNs 2-1 to 2-n (n is an arbitrary integer value of 1 or more), and p SNs 3-1 to 3-p (p is 1 or more). an arbitrary integer value), q NNs 4-1 to 4-q (q is an arbitrary integer value of 1 or more) (hereinafter referred to as a “GLS network”), and an RTN (server) 5 is an information processing system. The GLS network and the RTN 5 are configured to be mutually connected via a predetermined network (NW) such as the Internet. Also, each node included in the GLS network is connected by a predetermined method such as P2P. Then, hereinafter, when there is no particular need to distinguish between MN2-1 to 2-n, SN3-1 to 3-p, and NN4-1 to 4-q, they are collectively referred to as "RN1". , “MN2”, “SN3” and “NN4”.
In the example of FIG. 7, each node connected to the GLS network applies to the RTN 5 in advance for participation in the GLS network, and the role to be played by each node is determined and the connection destination is specified. and a GLS network has been constructed.
That is, the RTN 5 acquires information on nodes that wish to participate in the GLS network before constructing the GLS network. The RTN 5 determines each role and connection destination of each node based on the contents. The RTN 5 then transmits information on its own role and connection destination to each node. This builds the GLS network described above.
The GLS network may include not only RN1, MN2, SN3, and NN4, but also nodes having other roles, such as SGN (not shown), as appropriate.

Next, an example of the hardware configuration of each node included in the GLS network will be described with reference to FIG.
FIG. 8 is a block diagram showing an example of the hardware configuration of RTN in the information processing system shown in FIG.

The RTN 5 is composed of, for example, a computer, and includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, a bus 14, an input/output interface 15, and an output unit. 16 , an input unit 17 , a storage unit 18 , a communication unit 19 and a drive 20 .

The CPU 11 executes various processes according to programs recorded in the ROM 12 or programs loaded from the storage unit 18 to the RAM 13 .
The RAM 13 also stores data necessary for the CPU 11 to execute various processes.

The CPU 11 , ROM 12 and RAM 13 are interconnected via a bus 14 . An input/output interface 15 is also connected to this bus 14 . An output unit 16 , an input unit 17 , a storage unit 18 , a communication unit 19 and a drive 20 are connected to the input/output interface 15 .

The output unit 16 includes, for example, a display such as a liquid crystal display, a speaker, and the like, and outputs various information as images and sounds.
The input unit 17 is composed of, for example, a keyboard or the like, and inputs various kinds of information according to user's instruction operations.
The storage unit 18 is configured by a hard disk, a DRAM (Dynamic Random Access Memory), or the like, and stores various information.
The communication unit 19 controls communication with other devices (for example, RN1, MN2, SN3, NN4, etc.) via a GLS network including the Internet.

A drive 20 is provided as required. A removable medium 31 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory is mounted in the drive 20 as appropriate. A program read from the removable medium 31 by the drive 20 is installed in the storage unit 18 as necessary.
The removable medium 31 can also store various data stored in the storage unit 18 in the same manner as the storage unit 18 .

Note that the hardware configuration of RN1, MN2, SN3, NN4, etc. can be the same as an example of the hardware configuration of server RTN5, so the description is omitted here.

FIG. 9 is a functional block diagram showing an example of functional configurations of NN, SN, MN and RN in the GLS system of FIG. First, an example of the functional configuration of NN4 will be described.
As shown in FIG. 9, the CPU 60 of the NN 4 executes various programs to create a transaction generation unit 80, an unapproved transaction management unit 81, an approved transaction management unit 82, a consistency verification unit 83, It functions as a signal manager 84 .
The transaction generator 80 generates a transaction according to the details of the executed transaction.

The unapproved transaction management unit 81 transmits the transaction generated by the transaction generation unit 80 to each of the other multiple NN4 and multiple SN3.

The approved transaction management unit 82 acquires approved transactions transmitted from SN3, which will be described later.

The consistency verification section 83 verifies the consistency of the approved transaction acquired by the approved transaction management section 82 .

The signal management unit 84 acquires and manages signals transmitted from the SGN (not shown). That is, the signal management unit 84 manages the intra-system time of each NN4.

Next, an example of the functional configuration of SN3 will be described.
As shown in FIG. 9, the CPU 100 of SN3 functions as an unapproved transaction management unit 120, an approved transaction management unit 121, a consistency verification unit 122, and a signal management unit 123 by executing various programs. do.
Unapproved transaction manager 120 acquires the transaction sent from NN4. In addition, when the unapproved transaction management unit 120 determines that there is no problem in verifying the consistency of the acquired transaction, the unapproved transaction management unit 120 transmits the transaction to each of the other plurality of SN3s and the plurality of MN2s.

The approved transaction management unit 121 acquires approved transactions transmitted from the MN2, which will be described later.

The consistency verification unit 122 verifies the consistency of the transactions acquired by the unapproved transaction management unit 120 and the approved transactions acquired by the approved transaction management unit 121 .

The signal management unit 123 acquires a signal transmitted from an SGN (not shown) and manages it. That is, the signal management unit 123 manages the internal system time of each of SN3.

Next, an example of the functional configuration of MN2 will be described.
As shown in FIG. 9, the CPU 140 of the MN2 executes various programs and the like to create an unapproved transaction management unit 160, an approved transaction management unit 161, a consistency verification unit 162, a signal management unit 163, It functions as the RN processing unit 164 .
Unapproved transaction manager 160 acquires the transaction sent from SN3. Further, when the unapproved transaction management unit 160 determines that there is no problem in verifying the integrity of the acquired transaction, it transmits the transaction to each of the other plurality of MN2 and RN1.

Approved transaction management unit 161 acquires an approved transaction transmitted from RN1, which will be described later.

The consistency verification unit 162 verifies the consistency of the transactions acquired by the unapproved transaction management unit 160 and the approved transactions acquired by the approved transaction management unit 161 .
That is, the consistency verification unit 162 monitors the approval behavior of the RN.
Note that the monitoring of the approval behavior of the RN specifically means, for example, whether the created block numbers match, whether the public key embedded in the created block belongs to the correct RN, and whether the signal is embedded in the block. If there is a shard to be described later, is the shard number the same as the shard to which the approved RN belongs? whether there is a problem with the integrity of the transaction stored in the block.

The signal management unit 163 acquires signals transmitted from the SGN (not shown) and manages them. That is, the signal management unit 163 manages the intra-system time of each MN2.

The RN processing unit 164 executes various processes related to the selection of RN5.

Finally, an example of the functional configuration of RN1 will be explained.
As shown in FIG. 9, the CPU 180 of RN1 functions as an unapproved transaction acquisition unit 200, an approved transaction generation unit 201, and an approved transaction management unit 202 by executing various programs.
The unapproved transaction acquisition unit 200 acquires the transaction sent from MN2.

Approved transaction generation unit 201 verifies the consistency of transactions acquired by unapproved transaction acquisition unit 200 . If it is determined that there is no problem with the verification of consistency, the approved transaction generation unit 201 approves the transaction and generates an approved transaction.

The approved transaction management unit 202 transmits the approved transaction generated by the approved transaction generation unit 201 to each of the plurality of MN2.

A signal management unit 203 acquires a signal transmitted from an SGN (not shown) and manages it. That is, the signal management unit 203 manages the intra-system time of each RN1.

Next, an example of the flow of transaction processing executed in NN4, SN3 and MN2 will be described with reference to FIG. FIG. 10 is an arrow chart showing an example of the flow of transaction processing relating to NN, SN and MN.
In the example of FIG. 10, a series of processes executed in relation to transactions in NN4, SN3 and MN2 are collectively referred to as transaction processing. NN side transaction processing, SN side transaction processing, MN side transaction processing, and RN side transaction processing.

In step S1, the transaction generator 80 of NN4 generates a transaction according to the content of the executed transaction.
Here, the NN 4 may generate an unapproved transaction by creating new data based on the information of past approved transactions and adding an electronic signature to it. Also, the unapproved transaction referred to here refers to a transaction before being approved by RN1.

In step S2, the unapproved transaction manager 81 of NN4 transmits the transaction generated in step S1 to each of the other NN4 and SN3.

At step S21, the unapproved transaction manager 120 of SN3 acquires the transaction sent from NN4 at step S2.

In step S22, the consistency verification unit 122 of SN3 verifies the consistency of the transaction obtained in step S21. Note that if there is a problem with consistency verification, the transaction is discarded.

In step S23, the unapproved transaction manager 120 of SN3 transmits the transaction whose consistency is recognized in step S22 to each of the other SN3s and MN2s.

At step S41, the unapproved transaction manager 160 of MN2 acquires the unapproved transaction sent from SN3 at step S23.

In step S42, the consistency verification unit 162 of MN2 verifies the consistency of the transaction obtained in step S41. Note that if there is a problem with consistency verification, the transaction is discarded.

In step S43, the unapproved transaction management unit 160 of MN2 transmits the transaction for which it is determined that there is no problem in verifying consistency in step S42, to each of the other plurality of MN2 and RN1.

At step S61, the unapproved transaction acquisition unit 200 of RN1 acquires the transaction transmitted from MN2 at step S43.

In step S62, the approved transaction generator 201 of RN1 verifies the consistency of the transaction obtained in step S61. Note that if there is a problem with consistency verification, the transaction is discarded.

In step S63, the approved transaction generation unit 201 of RN1 approves the transaction and generates an approved transaction if it is determined in step S62 that there is no problem in verifying the integrity of the transaction.

At step S64, the approved transaction manager 202 of RN1 transmits the approved transaction generated at step S63 to each of the plurality of MN2.
Also, in step S65, the approved transaction management unit 202 of RN1 saves the generated approved transaction in a database or the like (not shown).

At step S44, the approved transaction manager 161 of MN2 acquires the approved transaction transmitted from RN1 at step S64.

In step S45, the consistency verification unit 162 of MN2 verifies the consistency of the approved transaction acquired in step S44. Note that if there is a problem with consistency verification, the transaction is discarded.

In step S46, the approved transaction management unit 161 of MN2 transmits the approved transaction whose consistency is recognized in step S45 to each of the other multiple MN2 and multiple SN3.
Also, in step S47, the approved transaction manager 161 of MN2 saves the approved transaction whose consistency is recognized in a database or the like (not shown).

At step S24, the approved transaction manager 121 of SN3 acquires the approved transaction transmitted from MN2 at step S46.

In step S25, the consistency verification unit 122 of SN3 verifies the consistency of the approved transaction acquired in step S24. Note that if there is a problem with consistency verification, the transaction is discarded.

In step S26, the approved transaction manager 121 of SN3 transmits the approved transaction whose consistency is recognized in step S25 to each of the other multiple SN3s and multiple NNs.
Here, the approved transaction management unit 121 may determine the destination node based on arbitrary criteria, for example. That is, for example, the approved transaction management unit 121 may transmit approved transactions to each node without determining the order of priority. Priority may be given to sending approved transactions.
Also, in step S27, the approved transaction manager 121 of SN3 saves the approved transaction, which has been judged to have no problem in the consistency verification, in a database or the like (not shown).

At step S3, the approved transaction manager 82 of NN4 acquires the approved transaction transmitted from SN3 at step S26.

In step S4, the consistency verification unit 83 of NN4 verifies the consistency of the approved transaction acquired in step S3. Note that if there is a problem with consistency verification, the transaction is discarded.

In step S5, the approved transaction management unit 82 of NN4 transmits to each of the other NN4 the approved transactions determined to have no problem in the verification of consistency in step S4.
Also, in step S6, the approved transaction management unit 82 of NN4 saves the approved transaction determined to have no problem in the verification of consistency in a database or the like (not shown). This completes the transaction processing.

Although one embodiment of the present invention has been described above, the present invention is not limited to the above-described embodiment, and modifications, improvements, etc. within the range that can achieve the object of the present invention are included in the present invention. Consider.

Although not described in the above embodiments, the GLS network is not always fixed, and there are new nodes that wish to join the GLS network (hereinafter referred to as "nodes wishing to join"). sometimes. Therefore, the details of various processes when there is a node desiring to join will be briefly described with reference to FIG. 11 .

In step S81, the RTN 5 acquires information on a registration list of all nodes (hereinafter referred to as "all node information") including information on all nodes that currently configure the GLS network.
The method by which the RTN 5 acquires all node information is not particularly limited. All node information may be acquired.

Here, in step S61, the node desiring to join transmits information to the effect that it desires to join the GLS network (hereinafter referred to as "desire to join information") to the RTN5.
Therefore, in step S82, the RTN 5 acquires the participation request information transmitted from the participation request node in step S61.

In step S83, the RTN 5 selects the role of the node desiring to join based on the information of all nodes acquired in step S81 and the information desiring to join acquired in step S82.
Further, in step S84, the RTN 5 determines a specific connection destination of the node desiring to join in the GLS network based on the all node information acquired in step S81 and the information desiring to join acquired in step S82.

In step S85, the RTN 5 transmits information regarding the role selected in step S83 and the connection destination determined in step S84 to the node desiring to join.

Therefore, in step S62, the node desiring to join acquires the information on the role and connection destination transmitted in step S85. Further, in step S63, the node desiring to join refers to the information on the role and connection destination acquired in step S62, and connects to the GLS network.
Then, in step S86, the RTN 5 adds the information about the node desiring to participate to the all-node information, and stores the information in a database or the like (not shown) as new all-node information.

Although not described in the above embodiments, the differences between the MN and RN in the GLS system and the "minor" in the existing system will be described in detail.
Miners, which are widely used in existing systems, perform mining in transaction approval by searching for hash values that match specific conditions. Note that mining particularly means searching for hash values in transaction approval among a series of processes for transaction approval.
The idea is to ensure the fairness and safety of the entire system by giving randomness to the node responsible for approval.
On the other hand, in the GLS system, it is possible to change the node (especially RN) in charge of approval by a specific trigger (for example, user's operation).
For example, in one method, the GLS system may randomly determine who is in charge of the approval node at the timing of the user's operation by passing arbitrary tokens between MNs or between MN and RN. As a result, the GLS system quasi-randomizes the determination of the node in charge of approval, thereby avoiding that only a specific node becomes the approver.
Also, for example, in one method, the GLS system differs from existing systems in that the contents of transactions generated based on various user operations, time information (signals) given when generating transactions, and the overall network Depending on the configuration, etc., the node responsible for approval may be determined.
Specifically, for example, the GLS system changes hash values to be generated according to the contents of transactions generated based on various user operations, the timing of generation, etc., and combines and refers to these hash values. A node (eg, RN) responsible for approval may be determined. Also, a node (for example, RN) in charge of approval corresponding to a specific hash value may be determined according to the configuration of the entire network at that time.
It should be noted that these elements are elements that are difficult to predict and manipulate arbitrarily in advance of transaction generation. In other words, the GLS system ensures fairness and security by giving a high degree of randomness to the decision of the node in charge of approval by multiplying different elements with such randomness. reduce the risk of being

Also, although the description is omitted in the above embodiment, the significance of the signal (signal node) in the GLS system will be supplemented in detail.
In conventional distributed ledger systems, the order of information received and the order in which the information was processed may differ when viewed from the perspective of any node. It was often pointed out that stamps were not always accurate.
In this respect, conventionally, for example, attempts have been made to obtain accurate time information by receiving information from a dedicated server instead of the server that processed the information, for example, the time stamp added when information was processed. Also, for example, in the Bluef of Works blockchain, an attempt was made to solve the above-mentioned problem by using "block numbers" instead of timestamps. However, for example, even when using a "block number", it is difficult to calculate a time finer than the block generation interval (agreed time).
On the other hand, a signal node in the GLS system has the following elements.
(1) Conventional acquisition of time information was performed by an active method of sending a request to a dedicated server, whereas signal nodes distribute time information by P2P every arbitrary time. Therefore, each node (server) can passively receive time information.
(2) In the conventional method using a dedicated server, there is a risk of attack on the dedicated server. To make it difficult to identify a node (server) distributing time information.
Therefore, the GLS system employing the signal node has the following advantages (features), for example.
(a) When installing dedicated servers, the load increases according to the number of installed servers. No increase in load on nodes.
(b) The GLS system makes it easy to keep the locations of signal nodes secret. Also, even in the unlikely event that the location is discovered and the system goes down (attacked), simply registering the IP address and domain of the signal node as a connection destination to another node (eg RTN) Since the re-installation is completed, the GLS system can be easily restored.
(c) As described above, the time information transmitted from the signal node can be given a digital signature. can be easily identified. Furthermore, since time information with a digital signature can be issued only by a signal node, it is possible to prevent attacks such as sending information with a future date, for example.
With this method, the GLS system realizes "installation of a server that transmits time information", which was difficult to apply in the conventional distributed ledger system, and the interval is smaller than the block generation interval. can also obtain accurate time information.
To explain these advantages in detail, for example, in conventional distributed ledger systems, when viewed from the viewpoint of any server, accurate time information cannot be obtained, so it is difficult to check whether information is being processed. Due to the difficulty, there were cases where the same content had to be processed. However, in the GLS system, it is possible to adopt a method of allocating nodes to be processed at arbitrary time intervals on the premise of accurate time information. Therefore, it is possible to greatly reduce duplication of processing that processes the same content, and to greatly improve the scalability of the entire system.
Here, in the example of the technology that employs the "block number" to acquire the time, for example, a solution of shortening the block generation interval is conceivable.
However, blockchain approvers in proof of work are randomly determined, and the same transaction may be processed by multiple approvers. Therefore, each node should focus on verifying multiple blocks containing transactions with the same content. In addition, coupled with the characteristic of distributing only blocks that have been verified to other nodes, there arises a problem that, as a result, there is a bias in expanding blocks or sharing the same blocks in the entire system.
As a result, the time information received by each node is also biased, and the processing speed of the entire system decreases in proof-of-work that assumes synchronization and sharing of blocks. Although such a problem remains in the GLS system, the above-mentioned "signal" is used to improve the processing speed.
Specifically, for example, the amount of information in a signal is smaller than that in a block or transaction, and the types of information included are also smaller. Therefore, even if each node receives multiple signals, verification and distribution can be performed smoothly with a small load. In addition, in the GLS system, unintended sharing of information can be reduced by allowing information to flow only in one direction through a ring-shaped network configuration. Therefore, the imbalance in time sharing within the network is eliminated. In addition, the GLS system separates the approver from the time information distributor, and separates the verification process and distribution route of each information to achieve further efficiency.
On the other hand, in order to improve the processing speed of blocks or transactions, if there are nodes where it is desirable to preferentially transmit transactions (or blocks), such as the source and destination of the remittance, they It is also possible to adopt a mechanism in which transactions are preferentially distributed to nodes of

Also, for example, in the above-described embodiment, the timing at which the content of the transaction is confirmed is explained as being performed at the time when the RN approves it, but it is not particularly limited to this.
For example, if the consistency is confirmed by verifying the consistency of a plurality of nodes, the redundancy of the system can be improved, but the processing performance is lowered. On the other hand, if the decision is made with the approval of one node, the redundancy as a system is lost, but the processing performance is improved, so the timing of decision is arbitrary by the provider.
That is, the GLS system may decide when the integrity of all target nodes has been verified (determined to be no problem), or when the transaction is stored in each block or when the transaction is It may be determined at the point when it is linked to the previous transaction.

Also, for example, although not explained in the above embodiments, a node that can be employed in the GLS system may also transmit a transaction to a node of the same rank (having the same role) as a connection destination. Furthermore, in this case, each node of the same rank as the connection destination may similarly receive and execute the flow of transaction processing according to the above steps.

Also, for example, in the above-described embodiments, the term "blockchain" has been described as referring to the structure of a database composed of blocks, but it is not particularly limited to this. For example, the term “blockchain” may be used in a broader sense to include various distributed information systems, P2P networks, transaction approval mechanisms, and the like.

Also, for example, although not described in the above embodiments, when a new MN wishes to participate in the network, the GLS system votes to determine whether or not to allow participation by MNs that are RN candidates. A mechanism may be adopted in which only MNs that have become possible become RN candidates.
With existing public distributed ledgers, approval work by anonymous third parties was permitted, making it difficult to take effective countermeasures against the so-called 51% attack. By adding installation conditions to nodes with approval authority, such as MNs, an entity responsible for MN ownership (e.g., GLS system provider, etc.) always owns 50% or more of normal MNs. Therefore, effective countermeasures can be taken against the so-called 51% attack.

Also, for example, in the above-described embodiments, each node that configures the GLS network has been described as being connected by a scheme such as P2P.
That is, as described above, the connection of the GLS network in the above-described embodiments can adopt so-called hybrid P2P technology, for example. This enables free control of the network structure and facilitates control of communication paths for transactions from the center to the end.
On the other hand, in services related to existing blockchain technology, since general P2P is adopted, the communication path of transactions becomes random, making it difficult to control the communication path from an arbitrary node to a specific node. Therefore, communication is generally performed by selecting a path that is close to the optimum, but even if high-speed transaction approval is achieved, there is a limit to improvement in the average latency value.
On the other hand, in the GLS system in the above-described embodiment, by adopting hybrid P2P that facilitates route selection, the optimum communication route can be selected, so the average value of latency can be reduced more than general P2P. becomes possible.
In addition, an increase in latency is unavoidable due to the expansion of the network scale. In addition, implementation of network sharding etc. can reduce the speed of increase in latency described above, and in addition, it becomes structurally easier to respond to external infrastructure changes such as 5G. Such flexibility of the system itself can be said to be a unique feature not found in existing services using blockchains.

Here, the advantages and synergistic effects of the "hierarchical network structure" and "circular network structure" of the GLS system in the above-described embodiments will be briefly supplemented.
In the GLS system, in addition to setting the role of each node according to the hierarchical network structure, by building the connection between nodes as a circular network structure for each role, the network for each layer can be connected in a self-similar manner. can.
That is, regardless of the number of nodes according to the embodiment of the GLS system, it becomes easy to construct a network having a structure that efficiently propagates transactions. Therefore, in the GLS system, information transmission between MNs is made efficient, and approved transactions to be referred to at the time of approval are synchronized at high speed. As a result, the GLS system can be expected to further improve the processing speed of transaction approval.
In addition, the GLS system enables the generation of unapproved transactions to approval, and speeds up synchronization processing. In addition, since the network structure can be freely controlled, it is possible to easily control the communication path of transactions from the center to the end, thereby reducing the average value of latency.
The GLS system achieves extremely high-speed and efficient transaction processing by combining the advantages of the "hierarchical network structure" and the "circular network structure" and their synergistic effects.

Here, the signal and signal node (SGN) in the above-described embodiments are further supplemented.
As mentioned above, in the GLS system, signals are an important function to prevent transaction tampering. In other words, a signal is always embedded in a transaction in the GLS system, and by referring to this signal, each node can grasp the time when the creation of the transaction was approved, and the like.
Therefore, the GLS system may adopt, for example, the following methods together in order to improve signal accuracy.
(1) If the time at which a signal is embedded in a transaction or the like is older than the last received signal, the old signal can be discarded. This may allow each transaction to always have the latest signal.
(2) Install a plurality of signal nodes and distribute signals to each signal node. This may allow efficient signal transfer.
(3) It may be possible to statistically process the time when each signal is embedded (for example, calculate the standard deviation) and determine the intra-system time based on that.
(4) Each node may be able to determine which signal node generated the signal embedded in the transaction by verifying the public key or the like.
It should be noted that the signal node does not necessarily have to assign a signal to a transaction if the order in which the transactions are processed has no meaning, or if another signal has already been assigned to the transaction.

In addition, for example, it is possible to manage created and approved transactions in chronological order by signals embedded in transactions, so it is possible to add time-based superiority or inferiority to each transaction.
Specifically, for example, in the voting of each masternode (MN) when deciding to elect or withdraw from a new masternode (MN), by referring to the time of the signal, it is possible to determine whether it is a consistent and correct vote. can do. As a result, the master node (MN) can be elected more accurately, thereby further reducing the security risk of the entire system.
Specifically, a consistent process is realized by verifying the signal time at each timing, such as candidacy, voting, vote counting, election, continuation, change in MN list, candidacy, etc. in election and withdrawal of MN. It is possible to consider whether or not

Also, for example, although not described in the above embodiments, the GLS system can apply a technique called consistent hashing or the like to further reduce network traffic. A specific application method in the GLS system will be described below with reference to FIG.
Here, a technique called consistent hashing is known as a method of distributing and holding a large amount of data in arbitrary nodes. Even in the GLS system, a device that applies this consistent hashing method can be implemented.
In other words, each node distributes and holds various information in the GLS system (for example, how to hold a transaction, which RN approves which transaction, etc.), thereby reducing the communication traffic of the entire system. be able to.
Looking at the example of FIG. 12, each of MN-A to C stores hash values of two or more blocks (four in the example of FIG. 12). These two or more blocks are based on the idea of distributed possession of the consistent hashing method, and the block immediately before the information in charge of each node (hereinafter referred to as the "responsible shard") and the information different from the responsible shard. is a block.
In the example of FIG. 12, MN-A creates block A and calculates a hash value of block A when verifying a transaction. Then, an object (information) to be referred to is selected according to the calculated hash value. In the example of FIG. 12, it is MN-B. MN-B verifies transaction B for which it is responsible for verification, generates block B storing transaction B, and then connects block A or the previous block in the same shard. That is, in the example of FIG. 12, the transaction is not only verified, but approved and given finality only when it is linked to the next related block.
In this way, in the GLS system, transactions are linked across the responsible shards distributed and held by each MN. Therefore, in the GLS system, transactions can be verified redundantly by multiple nodes. Even if there is, the entire system can be easily restored.
If there is no unverified transaction and there is an unconfirmed transaction in the block, the MN can approve the unapproved block by creating and concatenating a block that does not store the transaction.
Also, information such as transactions of block A is sent to MN-B via an arbitrary SN. This allows MN-B to verify the transaction.

Here, for example, attacks such as intentional approval of inconsistent transactions are also assumed. Therefore, in the GLS system, when an abnormality is recognized in the verification of consistency by another MN connected to the MN, for example, when an abnormal transaction is included in the block of the connection destination candidate immediately before approval, May be concatenated to earlier normal blocks. As a result, finality is not assigned to abnormal transactions, and attacks such as those described above can be effectively dealt with.
Also, for example, in the GLS system, if any MN (for example, MN-B) stops functioning due to a failure, another MN (for example, MN-C) takes over processing and generates blocks. good.
In summary, in the GLS system that applies the method of consistent hashing, each node does not hold all information like a general distributed ledger network, but each node is responsible for its own shard and It suffices to have at least two pieces of information related (referenced) by itself, and it is possible to greatly reduce the amount of information in the entire network. On the other hand, even if malicious transactions are detected, final finality cannot be obtained because no blocks are linked to blocks containing abnormal transactions. As a result, in the GLS system to which the consistent hashing technique is applied, it is possible to reduce the amount of information in the entire network and realize processing while maintaining the processing capacity of each node without lowering security accuracy.

Here, the application of DAG in the GLS system in the above-described embodiment will be further supplemented.
DAGs are similar to blockchains in that they are directional, but unlike so-called blockchains, DAGs can execute approval processes in parallel. This is because the DAG can perform the approval work for each transaction without grouping transactions into blocks, which can be expected to dramatically improve the latency of the TPS and the entire system.
On the other hand, if a DAG is simply used, for example, to receive transactions derived from an arbitrary node, it is necessary to send a list of transactions it owns. In other words, each time you try to synchronize derived transactions, you have to send the list of transactions. In addition, a node that receives a list of transactions must derive, check, or retrieve each transaction, which takes time for synchronization. In the conventional distributed ledger technology, by synchronizing on a block-by-block basis, it is possible to identify to what extent "synchronization" has occurred. This allows multiple transactions to be confirmed together, improving the speed of information synchronization. On the other hand, the GLS system improves the synchronization speed of information by expanding the blockchain for each shard. In addition, by adding hash pointers to blocks in other shards for each block, a block-based DAG is adopted. Furthermore, mutual monitoring between different shards can be realized by performing verification when connecting blocks with other shards. This allows you to enjoy the scalability of sharding while maintaining tamper resistance.

Also, for example, a not-illustrated GWN (Gateway Node) that can be included in the GLS network will be described, although the description has been omitted in the above-described embodiment (especially the GLS network in FIG. 7).
The GWN is a node that has a function of connecting to the network of the GLS system and other external services or networks, and executing conversion processing based on the acquired predetermined data.
Specifically, for example, when the GLS system is used as a financial asset transaction system, it can be used to manage financial assets, manage data of high importance such as financial assets, and perform conversion processing.
In the past, when acquiring data, conventional central management systems were at risk of being hacked by malicious attackers because the servers could be directly accessed via the Internet. In addition, there is a risk that data may be tampered with by malicious attackers.
In order to solve the above problem, the GWN takes measures such as closing ports with firewalls to block unidirectional connections from each node that constitutes the GLS network to the GWN, and also prohibit access to On the other hand, one-way communication from the GWN to each node constituting the GLS network is permitted.
That is, the GLS system can easily keep the location of the GWN secret. In addition, even if the installation location is discovered and the system goes down (attacked), simply registering the GWN's IP address or domain as a connection destination to another node (for example, RTN) will restore the system. Since the installation is completed, the GLS system can be restored easily.
Here, since each transaction sent and received in the GLS system is saved only after passing the integrity verification, it has not been tampered with by requesting information through a one-way connection from the GWN to the GLS network. Also, data with guaranteed reliability can be transmitted and received, and data synchronization can be performed normally.
Next, processing in the GWN will be specifically described. First, when the GWN performs processing based on information acquired from other external services or networks, it connects unidirectionally from the GWN, acquires data, and based on the read contents, transactions in the GLS system to create The created transaction is approved by itself, MN, etc., and is unidirectionally transmitted to each node constituting the GLS network. Each node that receives this transmits it to each connection destination, thereby synchronizing the entire GLS network. Next, when the GWN acquires a transaction in the GLS system and executes processing based on the read contents, the GWN unidirectionally connects to each node constituting the GLS network and acquires the transaction. The GWN then executes predetermined processing for other external services or networks based on the acquired transaction. In this way, the GWN performs approval processing based on the acquired transaction, unidirectionally connects to each node constituting the GLS network, and transmits the approved transaction.

Also, for example, although only a brief explanation was given in the above-described embodiment, the structure of transactions in the GLS system will be explained in more detail. The transaction structure in the GLS system may be freely designed for each product that handles different data, but for example, an example of the transaction structure will be described in detail.
The transaction model in the GLS system can be developed on either a UTXO (Unspent Transaction Output) basis or an account basis. can do. Therefore, after identifying the owner of the UTXO and confirming the existence of the Txin (Transaction Input) and the original TxOut (Transaction Output), the consistency of the amount and the like is verified.
Also, for example, the transaction approval work may be performed by adding the RN's digital signature according to the following procedure. That is, the RN compares the new approval target transaction (X) with the transaction immediately preceding (X), and confirms the UTXO consistency of both data. This verifies transaction integrity.

Also, for example, although the description is omitted in the above embodiment, when the GLS system is applied to a system such as a crypto asset exchange, a plurality of different types of transactions may be adopted in the GLS system.
Specifically, for example, the GLS system may employ two types of transactions: order transactions and trade transactions.
For example, an order transaction is embedded with its own TxIn (currency ID, amount, digital signature, creator's public key, etc.) by the NN and sent to the GLS network or the like as an asset trading application form. On the other hand, for example, the RN acquires the transmitted order transactions, generates a trade transaction in the form of approval based on a plurality of order transactions that meet the conditions, and transmits it to the NN. The NN acquires the transmitted trade transaction, and generates an order transaction again from TxOut (remittance destination address, currency ID, amount, etc.) of the acquired trade transaction. By repeating this flow and connecting transactions with hash values, etc., the chain is extended as a distributed ledger that describes the history of asset transactions.

Also, for example, although not described in the above embodiments, all or part of the methods related to the GLS system (roles set for each node, especially the RN approval method, etc.) are so-called private type or consortium type. It can be applied not only to the distributed ledger of the public type, but also to the public distributed ledger.

Also, for example, the system configuration shown in FIG. 7 and the hardware configuration of the server 5 shown in FIG. 8 are merely examples for achieving the object of the present invention, and are not particularly limited.
That is, for example, each server of the information processing system according to one embodiment of the present invention may be configured on a single piece of hardware, or may be configured on a plurality of pieces of hardware according to its functions and the number of processes. Alternatively, it may be implemented on an existing information processing device.

Also, for example, nodes having functions are not limited to the examples in FIG. 1 and the like, and may be arbitrary.
That is, for example, although the RN is configured to have a predetermined function, this is merely an example. For example, at least part of the functions provided by the RN may be provided by another information processing device (for example, MN, SN, etc.).
In other words, it is sufficient for the information processing system to have a function capable of executing the above-described series of processes as a whole. Not limited.

Also, for example, the series of processes described above can be executed by hardware or by software.
Also, one functional block may be composed of hardware alone, software alone, or a combination thereof.

When executing a series of processes by software, a program constituting the software is installed in a computer or the like from a network or a recording medium.
The computer or the like may be a computer built into dedicated hardware.
Also, the computer or the like may be a computer capable of executing various functions by installing various programs, such as a server, a general-purpose smart phone, or a personal computer.

A recording medium containing such a program not only consists of a removable medium (not shown) that is distributed separately from the device main body in order to provide the program to the user, but is also preinstalled in the device main body and delivered to the user. It may be composed of a provided recording medium or the like.

In this specification, the steps of writing a program recorded on a recording medium are not necessarily processed chronologically according to the order, but may be executed in parallel or individually. It also includes the processing to be performed.

Furthermore, the contents of the steps shown in the above-described embodiments (particularly FIG. 4 and FIG. 10) are examples and are not particularly limited.
Specifically, for example, in step SS1 in FIG. 4, the NN is supposed to transmit the generated transaction to each of the other multiple NNs and the multiple SNs. may send transactions to
Also, for example, in step SS2 of FIG. 4, the SN may not send the consistency-verified transaction to each of the other SNs and MNs, but directly to the RN, for example. It should be noted that when such steps are employed, some of the steps in FIG. 4 may be changed or omitted as appropriate.

Further, in this specification, the term "system" means an overall device composed of a plurality of devices, a plurality of means, or the like.

In other words, the information processing apparatus to which the present invention is applied only needs to have the following configuration, and can take various forms.
That is, the information processing apparatus to which the present invention is applied is
An information processing device used for managing a network composed of n (n is an arbitrary integer value of 1 or more) other information processing devices,
role setting means for setting a role for each of the n other information processing devices;
connection destination determination means for determining connection destinations of each of the n other information processing apparatuses based on the set roles;
Prepare.
As a result, it is possible to provide a technology that can shorten the processing time in a distributed information processing system related to security and that can withstand a large increase in the number of processes to be executed.

Further, each of the n other information processing devices executes a process according to the role set by the role setting means in units of predetermined unit information,
The role setting means, for each of the n other information processing devices,
a first role including at least a role related to approval of the predetermined unit information;
a second role including at least a role related to the generation of the predetermined unit information;
a third role including a role of exchanging between the other information processing apparatus to which the first role is assigned and the other information processing apparatus to which the second role is assigned;
can be set at least one of

Further comprising hierarchical structure determining means for determining a hierarchical structure corresponding to the role set by the role setting means for each of the n other information processing devices constituting the network,
The connection destination determination means can determine the connection destination including the hierarchical structure determined by the hierarchical structure determination means.

Further, the selection and order of other information processing apparatuses that perform approval in the first role can be determined based on time information given to each of the other information processing apparatuses.

Further, the connection destination determining means can determine the connection destination by arranging each of the n information processing apparatuses in a ring shape.

1 ... root node (RN)
180 CPU
200 Unapproved transaction acquisition unit 201 Approved transaction generation unit 202 Approved transaction management unit 203 Signal management unit 2 Master node (MN)
140 CPU
160... Unapproved transaction manager 161... Approved transaction manager 162... Consistency verification unit 163... Signal manager 164... RN processor 3... Super node (SN)
100 CPU
120... Unapproved transaction manager 121... Approved transaction manager 122... Consistency verification unit 123... Signal manager 4... Normal node (NM)
60 CPU
80 Transaction generation unit 81 Unapproved transaction management unit 82 Approved transaction management unit 83 Consistency verification unit 84 Signal management unit 5 Topology server (RTN)

Claims (7)

An information processing device used for managing a network composed of n (n is an arbitrary integer value of 1 or more) other information processing devices,
role setting means for setting a role for each of the n other information processing devices;
connection destination determining means for determining a connection destination of each of the n other information processing apparatuses based on the set role;
with
each of the n other information processing devices executes a process according to the role set by the role setting means in units of predetermined unit information;
The role setting means, for each of the n other information processing devices,
a first role including at least a role related to approval of the predetermined unit information;
a second role including at least a role related to the generation of the predetermined unit information;
a third role including a role of exchanging between the other information processing apparatus to which the first role is assigned and the other information processing apparatus to which the second role is assigned;
set at least one of
The selection and order of other information processing devices for approval of the first role are determined based on time information given to each of the other information processing devices,
Information processing equipment. further comprising hierarchical structure determination means for determining a hierarchical structure for each of the n other information processing devices constituting the network according to the role set by the role setting means;
2. The information processing apparatus according to claim 1 , wherein said connection destination determination means determines said connection destination including said hierarchical structure determined by said hierarchical structure determination means. The connection destination determining means determines the connection destination by arranging each of the n information processing devices in a ring shape.
The information processing apparatus according to claim 1 or 2 . The role setting means further sets a fourth role related to distribution of the time information to each of the n other information processing devices.
The information processing apparatus according to any one of claims 1 to 3. the time information is distributed with a digital signature;
The information processing apparatus according to any one of claims 1 to 4. An information processing method for an information processing device used for managing a network composed of n (n is an arbitrary integer value equal to or greater than 1) other information processing devices,
a role setting step of setting a role for each of the n other information processing devices;
a connection destination determination step of determining a connection destination of each of the n other information processing apparatuses based on the set roles;
with
each of the n other information processing devices executes a process according to the role set by the role setting step in units of predetermined unit information;
In the role setting step, for each of the n other information processing devices,
a first role including at least a role related to approval of the predetermined unit information;
a second role including at least a role related to the generation of the predetermined unit information;
a third role including a role of exchanging between the other information processing apparatus to which the first role is assigned and the other information processing apparatus to which the second role is assigned;
set at least one of
The selection and order of other information processing devices for approval of the first role are determined based on time information given to each of the other information processing devices,
Information processing methods. A program executed by an information processing device used for managing a network composed of n (n is an arbitrary integer value of 1 or more) other information processing devices,
a role setting step of setting a role for each of the n other information processing devices;
a connection destination determination step of determining a connection destination of each of the n other information processing apparatuses based on the set roles;
Execute control processing including
each of the n other information processing devices executes a process according to the role set by the role setting step in units of predetermined unit information;
In the role setting step, for each of the n other information processing devices,
a first role including at least a role related to approval of the predetermined unit information;
a second role including at least a role related to the generation of the predetermined unit information;
a third role including a role of exchanging between the other information processing apparatus to which the first role is assigned and the other information processing apparatus to which the second role is assigned;
set at least one of
The selection and order of other information processing devices for approval of the first role are determined based on time information given to each of the other information processing devices,
program.

Images