JP7574990B2 - Information processing device and program - Google Patents

Description

The present invention relates to an information processing device and a program.

In recent years, distributed information systems, including distributed ledger technology, have begun to be used for cryptocurrencies, recording various types of information, and distributing assets.
Here, distributed ledger technology is a technology that has a data structure that uses digital signatures and hash pointers to make it easy to detect tampering, and achieves high availability and data integrity by storing the data in a large number of nodes distributed across a network.
A ledger that electronically manages the records held by participants is called a distributed ledger.
As an example of such a distributed information system, for example, a distributed information system such as a cryptocurrency remittance system (see Non-Patent Document 1) has been proposed. Non-Patent Document 1 proposes a technology that uses distributed ledger technology to eliminate the risk of double spending on a P2P network without the intervention of a central management institution such as a financial institution, and to safely transfer currency between individuals.
Also, a distributed information system is used to ensure the authenticity of the 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.

Generally, approval of transactions (transaction records) performed using distributed ledger technology, etc. is not carried out by all participants participating in maintaining the network, but only by participants who meet certain conditions (hereinafter referred to as "approvers") among those participating in maintaining the network.
However, conventional techniques including the technique described in the above-mentioned documents have problems such as requiring a lot of time and power consumption to select an approver and posing many security risks.

The present invention was made in light of these circumstances, and aims to provide technology that shortens processing time in a distributed information processing system related to security and can withstand a significant increase in the amount of processing that needs to be performed.

In order to achieve the above object, an information processing device according to one aspect of the present invention comprises:
An information processing device used for managing a network configured with n other information processing devices (n is an arbitrary integer value equal to or greater than 1),
a role setting means for setting a role for each of the n other information processing devices;
a connection destination determination means for determining a connection destination of each of the n other information processing devices based on the set role;
Equipped with.

A program corresponding to an information processing device according to one embodiment of the present invention is also provided as an information processing method according to one embodiment of the present invention.

The present invention provides technology that can reduce processing time in a distributed information processing system related to security and can withstand a significant increase in the amount of processing that needs to be performed.

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. 2 is a diagram for explaining an example of the function of an SN in a GLS system. FIG. 1 is a diagram showing an example of a ring-type network structure in a GLS system. FIG. 2 is a diagram showing an example of a series of processing steps from the generation of a transaction to the completion of various processes in a GLS system. FIG. 2 is a diagram for explaining an example of the function of a signal node in a GLS system. FIG. 6 is a diagram for explaining an example of the function of a signal node in a GLS system, and is a diagram showing an example different from the example of FIG. 5 . FIG. 1 is a diagram illustrating an example of a configuration of a GLS system. 8 is a block diagram showing an example of a hardware configuration of an RTN in the GLS system of FIG. 7. FIG. 8 is a functional block diagram showing an example of the functional configuration of an NN, an SN, an MN, and an RN in the GLS system of FIG. 7. 1 is an arrow chart showing an example of a flow of transaction processing in a GLS system. 1 is an arrow chart showing an example of a flow of a process for a node to join a network in a GLS system. FIG. 1 is a diagram illustrating an example of a method for applying a consistent hashing method to a GLS system.

The following describes an embodiment of the present invention with reference to the drawings.

Before explaining FIG. 1, we will explain various technologies and terminology related to an information processing device according to one embodiment of the present invention.

One of the technologies that has been used in many distributed ledger systems is called blockchain. When new information is recorded, this technology links blocks that make up a unit of data like a chain, inheriting the hash associated with the previous block, and can store various types of information.
Specifically, it is known that a blockchain can include elements such as each block being linked in one direction using a hash pointer, each block being assigned a digital signature, and containing a large number of transactions that are also linked to each other using pointers such as indexes.
In other words, blockchain is a technology that uses electronic signatures and hash pointers to maintain a data structure that makes it easy to detect tampering, and distributes and stores the data across a network, thereby achieving high availability and integrity of data.
Blockchains are usually managed by a distributed network such as P2P (Peer to Peer), and cannot be retroactively changed unless all subsequent blocks are changed. In other words, although it is not impossible to tamper with information stored as a blockchain, it is considered to be extremely difficult in reality. For this reason, blockchains are used to manage various assets and transactions, including virtual currencies such as Bitcoin.
However, problems have been pointed out in conventional distributed information systems regarding the time and power consumption required to select a transaction approver, as well as security risks.
In addition, in the method called Proof of Work adopted by Bitcoin etc., security risks have been pointed out, such as the time required for each server to send and receive information about approvers, and the so-called 51% attack, in which a confirmed transaction can be overturned by a malicious attacker, allowing a malicious third party to approve an illegal transaction. Furthermore, there is also a problem in that it is not possible to give a confirmed state (hereinafter also referred to as "finality") as irreversible information at the same time as the transaction is approved.
Furthermore, in these distributed ledger systems, there is no centralized data manager, and many participants operate computers connected to the network, share information (e.g., blockchain), and perform many calculations to approve each transaction and prevent information falsification, etc. As a result, a huge number of calculations are performed, which also poses the problem of huge amounts of electricity consumption.

Here, a transaction is data to which an electronic signature has been added to a predetermined unit of information that records, for example, the contents of a transaction, the results of various processes, etc. An electronic signature is data in which the predetermined unit of information described above is signed with the private key of the transaction creator, and to which information on the public key that pairs with the private key has been added.
That is, a transaction is information to which an electronic signature is affixed to the details of a transaction, such as when, from whom, to whom, how much, and the results of various processes.
In addition, when a transaction is approved according to certain rules, the transaction is established as information whose tampering can be easily detected at the same time as it is approved, or in the future.

In other words, participants (each node) in the network in a distributed ledger system (hereinafter referred to as the "distributed ledger network" or simply "network") verify and approve each transaction generated by the distributed ledger network, and then link multiple transactions individually or in blocks, etc. to form a "blockchain."
A node is each of the information processing devices that make up the network.
In other words, approved transactions that make up a blockchain are linked to the blocks in which the transactions are stored using hash values or other methods, making it easier to detect tampering and allowing the history of transactions from the past to the present to be tracked.

In this regard, an information processing system (hereinafter referred to as the "GLS system") including an information processing device of one embodiment of the present invention is an information processing system used for managing assets via a network, utilizing various technologies such as distributed information systems and blockchains.
The GLS system employs various structures (e.g., hierarchical network structures) described below, and the role of nodes present in each layer (e.g., approving transactions, etc.) is determined in advance. A reliable system time can be assigned to a transaction that is the subject of approval by a signal (data to which system time is assigned) described below. By performing approval with reference to such accurate system time, the GLS system can easily determine the priority order of approving nodes. Note that system time is time information that each node refers to in the GLS system.
In summary, the GLS system sets various roles related to approval according to various structures (e.g., hierarchical network structures). The GLS system then uniquely determines the hierarchy and order by using the system time that is accurately assigned to each role. As a result, the GLS system assigns clear roles, including hierarchy and order, to each node in the transaction approval process, and can significantly reduce the risk of double approval, which has been a problem in conventional distributed ledger systems.

In this embodiment, approval of a transaction is performed based on the results of verification of consistency by each node (particularly RN, which will be described later). Specifically, the verification of consistency can be performed, for example, from the following perspectives:
(1) The creator of the electronic signature is the same as the creator of the transaction, i.e., the electronic signature affixed to the transaction is genuine and not fraudulent.
(2) The transaction data has not been tampered with (confirmed by electronic signature).
(3) The target transaction is pending at the verifying node.
(4) The assets (data) included in the transaction are unused and properly held.
(5) The content of the transaction is not fraudulent. For example, in the case of a transfer of financial assets, the amount transferred must not exceed the amount of the assets held.
That is, in the GLS system, each node (particularly the RN described below) verifies the consistency of a transaction from the above-mentioned perspectives, thereby realizing approval of the transaction.

Next, the purpose of the GLS system will be explained in more detail.
First, certain conditions may be placed on the creation of transactions in a distributed ledger network.
For example, in proof of work, participants compete in computational processing by servers participating in the distributed ledger network to search for solution data (hereinafter referred to as "nonce") that meets the specified conditions. Only the participants who can find a nonce that meets the conditions generate an approved transaction based on the found nonce and send it to other participants while recording the approved transaction in their own distributed ledger. Furthermore, each participant who receives the approved transaction verifies the transaction stored in the approved transaction and the generation conditions, etc., to confirm that there is no fraud, and records it in their own distributed ledger.
Examples of technologies using a distributed ledger aimed at preventing transaction forgery and tampering include Bitcoin (see, for example, Non-Patent Document 1) and Ethereum. Various technologies (for example, proof of work) used in these methods can also be applied to the present invention.

In response to this, one of the goals of the GLS system is to provide solutions to issues such as "the fixed amount of time required for transaction approval, resulting in slow final settlement processing," "the inability to achieve the number of transactions processed per second (TPS) required for business use," and "the lack of scalability to withstand network expansion."

The GLS system aims to solve both the problems caused by centralization and the problems caused by decentralization by taking an approach from three perspectives: "decentralization of power,""centralization of management," and "pursuit of convenience." The specifics are explained below.
Decentralization of power refers to realizing a fair and secure system by eliminating the problems that have arisen from the centralization of information, such as the malicious creation or tampering of data by central administrators, causing inconvenience to users.
In the GLS system, users, as participants, can constantly verify the consistency of all data, thereby constantly monitoring for the presence or absence of malicious data or tampering.
Centralization of management refers to the realization of a system that reduces the issues of "self-responsibility of participants" and "risks in asset and data management" that were problems with conventional distributed ledgers. As a specific example, in the past, users were at risk of having their assets frozen due to loss of private keys, which are essential for managing assets. Users' private keys can be held as backups by the central administrator, and the central administrator can also take responsibility for managing the private keys.
The convenience sought means that the GLS system will achieve the "fast processing speed" and "high scalability" required in the real world, thereby achieving usability equivalent to that of a centralized system.

In other words, one of the objectives of the GLS system can be rephrased as providing a technology that not only provides the tamper-resistance of the information system and the characteristics of the above-mentioned distributed ledger technology that reduce the trust and responsibility required of a given party, but also resolves power consumption issues, shortens the time required for a transaction to be confirmed, and has the processing power to accommodate a significant increase in the number of transactions to be confirmed.
In order to achieve this objective, the GLS system employs various structures and functions, including, for example, a "hierarchical network structure" and a "ring-type 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 a GLS system.
In the GLS system, four types of roles are assigned to each of the nodes that make up the network, and various transaction-related processes are optimized by assigning each node to a layer.
Here, the nodes to which roles are assigned are, for example, four types: "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 roles played by each node will be described in detail.

The role of the RN is to perform the final approval in the approval process of transactions in the GLS system. One node is selected as this RN from among the MNs described below. The set of MNs to be selected as RNs is called root node candidates (hereinafter referred to as "RN candidates").
This allows the GLS system to speed up the overall transaction approval process by limiting the number of nodes that approve. Also, because only one RN is selected, it is possible to prevent multiple RNs from approving the same transaction. However, depending on the design, multiple RNs may simultaneously execute approval processes for different transactions.

Here, the rules for selecting an RN are not particularly specified and are arbitrary, but an example of the method is a method for selecting an RN by permutation.
A method for selecting an RN by permutation will be briefly described below. An RN is selected from each candidate MN, for example, by the following method.
For example, each MN that is a RN candidate transmits information (hereinafter referred to as a "token") including the public key of the MN and the period during which it is responsible for approval to other MNs at regular intervals. Each MN receives the token, compares its own public key with the token, and becomes an RN and performs approval if it is within the period during which it is responsible for approval.
One of the advantages of MN being a candidate for RN selection is that, for example, when approving a transaction, a reliable node (RN) has been selected in advance, which allows for high-speed approval processing according to a specified protocol. In other words, it is possible to omit the calculation of a hash value based on a nonce used in conventional distributed ledger technology, and it can be thought of as being able to approve transactions quickly by RN temporarily acting as a central server.

In addition, the prioritization of MNs used in selecting RNs is performed only based on past transactions that cannot be tampered with, as described above, making it difficult to select an unauthorized RN and functioning as a transparent and fair RN selection system.
Furthermore, the GLS system can also adopt additional rules for RN selection, such as thorough verification of transaction integrity by each node, system control that prevents the approval of fraudulent transactions through mutual monitoring by MNs, and strict installation conditions for MNs, thereby making it possible to more efficiently eliminate malicious tampering and achieve high processing speeds while ensuring security.

The role of the MN is to be a candidate to be selected as an RN, to send transactions to SNs and other MNs, to monitor MNs and RNs, etc. This will be explained in detail below.
In addition, MNs that are not selected as RNs among MNs are responsible for monitoring the approval behavior of RNs. In other words, the consistency of a transaction approved by RN is always confirmed by each node that receives the transaction, and if an inconsistent transaction is detected, the transaction is discarded. Therefore, even if an inconsistent transaction is sent, it does not spread to the entire network, so only consistent transactions are connected as a chain, and as a result, only reliable data is stored in the distributed ledger.
In addition, the GLS system may adopt a mechanism in which, for example, RNs that maliciously approve and attempt to send fraudulent transactions are registered on a blacklist managed by the MN and excluded from being candidate RNs.

For example, the GLS system may also execute control to switch the RN selected at regular intervals. As a result, even if a node goes down due to various attacks on RNs or MNs, other RN candidates will detect the node's downtime and continue approving transactions and selecting RNs as RNs, thereby preventing the entire GLS system from being stopped by an attack. Therefore, by using distributed ledger technology to eliminate the single point of failure that was previously a weakness of servers, it is expected that the system load in the GLS system will be distributed and zero system downtime will be achieved.

The role of the SN is to connect between the NN, which has the role of issuing transactions, and the MN, which has the role of approving transactions, thereby easing the load concentrated on each MN due to an increase in communication volume and assisting the information processing of each MN. A specific explanation will be given below.
As will be described in more detail later, the NN has the role of generating transactions, which are then transmitted to other NNs and SNs to which the NN is connected. The NN that receives the transaction then checks the integrity of the digital signature, etc., and stores the transaction information in its own database, etc., and forwards it to the NNs and SNs that it is connected to. This process is repeated by each node in the same way, causing the transaction to spread throughout the entire network.
In this regard, in conventional distributed ledger networks, each node first checks whether it has the latest transaction in its possession, and then transmits and receives the latest transaction it holds. This minimizes the number of times transactions are transmitted between nodes, preventing unnecessary and excessive flooding of the same transactions.
In contrast, in the GLS system, if a node (SN or NN) finds that the same information as the transaction it received is already stored in its own database, it can discard the transaction without transferring it. This makes it possible for the GLS system to prevent unnecessary and excessive flooding of the network with the same transactions. In addition, since it transmits and receives without checking whether the latest transaction exists, it plays a role in transmitting the transaction to the MN in the shortest possible time. The role of the SN will be briefly explained with reference to FIG. 2.

FIG. 2 is a diagram for explaining the details of the role of the SN in the GLS system.
In the example of FIG. 2, an example is shown in which a transaction is sent to x NNs present in the network, that is, an example is shown in which x identical transactions are sent to one SN.
In this example, since each NN is connected to y SN, simple calculations show that the same x x y transaction is sent to each of the multiple SNs. If SNs were not present on the GLS system network, a large number of identical transactions would be sent to the MN, causing a large load in processing them and causing delays in the approval process of the MN.
In contrast, when the SN acquires x number of identical transactions, it discards x-1 number of identical transactions and sends only the one remaining transaction to the MN. This means that the MN receives only the bare minimum of transactions, allowing the MN to focus solely on its own role, and is expected to improve the number of transactions processed per unit time.

In addition, as described above, by placing the SN between the NN and the MN, the SN can be used like a reverse proxy to protect the connection from the NN, a node that can be an attacker, to the MN, thereby making it possible to avoid high-load attacks on a specific MN, attacks that surround a specific node and block information, etc. This allows the GLS system to further reduce security risks and realize transaction processing.
Specifically, for example, a NN may maliciously send a large number of fraudulent transactions to a connected node, and the MN may receive all of these fraudulent transactions. This may result in a situation in which CPU resources are allocated to verifying the integrity of the fraudulent transactions, slowing down the approval processing speed of the MN's transactions, but this can be avoided by adopting the above-mentioned SN.

Next, the role of the NN will be explained. The NN is responsible for generating transactions in the GLS system and propagating the transactions to the NNs and SNs connected to the NN.
In addition, the NN and SN in the GLS system may be connected to multiple peer (same type) nodes and multiple higher level nodes of any design. Therefore, even if a specific node does not function properly, a transaction once transferred from the NN to the network can be detoured through other nodes, and as a result, it can reach the MN.

Next, the "ring-type network structure," which is one of the features of the GLS system, will be described with reference to FIGS.
FIG. 3 is a diagram showing an example of a ring-type network structure in a GLS system.
In the example of Fig. 3, MN and RN are placed at the center, SN is placed on the outside of them in a circle, and NN is placed on the outside of that. In such a ring-type network structure, the (network-like) distance from the center to the edge is uniform, so it is expected that information exchange will be performed quickly, widely, and efficiently.

When each node wishes to participate in the GLS system, it sends a participation application with an electronic signature generated using a public key and a private key stored in a storage unit (not shown) to an RTN (router node) (described later). The RTN determines the role of the sending node and the destination node determined based on the role based on an arbitrary rule, and transmits the determined various information to each sending node.
For example, the RTN has a list of public keys that have roles to function as MN to SN, and compares them with the public keys attached to the electronic signatures of the nodes that have requested participation. If the public keys match those registered as the respective roles, the RTN may determine a specific role, or if not, the RTN may determine the role of the NN, thereby determining the role of each node. However, the method by which the RTN determines the role of each node, the details of the role, and the criteria and method for determining the connection destination are arbitrary and not limited.

Next, a brief description will be given of the flow from the generation of a transaction in the NN to the completion of various processes with reference to Fig. 4. Fig. 4 is a diagram showing an example of the flow from the generation of a transaction in the GLS system to the completion of various processes.
In step SS1, the NN generates a transaction according to the content of the executed trade and transmits the transaction to each of the other NNs and SNs. The other NNs receiving the transaction then execute the same process as in step SS1.

In step SS2, SN receives the transaction sent from NN in step SS1 and verifies the integrity of the transaction.
In step SS2, if there is no problem with the consistency of the transaction, the SN transmits the transaction to each of the other SNs and MNs. Each of the other SNs that receive the transaction then executes the same process of step SS2.

In step SS3, the MN obtains the transaction sent from the SN in step SS2 and verifies the integrity of the transaction. In step SS3, if there is no problem with the integrity of the transaction, the MN sends the transaction to each of the other multiple MNs and RNs. Each of the other multiple MNs that receive the transaction then similarly executes the process of step SS3.

In step SS4, RN verifies the integrity of the transaction acquired in step SS3. If there is no problem with the integrity of the transaction, RN approves the transaction and generates an approved transaction.
In step SS5, the RN sends the approved transaction generated in step SS4 to each of the MNs.

In step SS6, the MN obtains the approved transaction sent in step SS5 and verifies the integrity of the approved transaction. In step SS6, if there is no problem with the integrity of the approved transaction, the MN sends the approved transaction to the SN. Each of the other MNs that received the transaction then similarly executes the process of step SS6.

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

In step SS8, NN obtains the approved transaction sent from SN in step SS7. This completes the flow from transaction generation to the end of various processes. Details of the processing by each node will be described later with reference to Figures 10 and 11, etc.

The important point here is that in the GLS system that adopts this ring-type network structure, the order of MN, SN, NN does not change from the center to the edge, and information transmission to each node is always completed with a fixed number of transfers. In addition, by minimizing the difference in timing of receiving information due to the positional relationship, it is expected that unfairness of information for each node will be eliminated and processing time will be shortened and optimized.
Specifically, in the example of Figure 3, transaction A created by a given NN is sent in the order SN, then MN. When the MN becomes an RN, it approves the received transaction A, which is then sent in the order MN, SN, and NN, so that all NNs can receive the approved transaction.
In other words, to summarise, each node to which a role is assigned in the hierarchical network structure can realise a circular self-similar structure of each node with each role in the ring structure.
The term "ring structure" as used herein means a structure in which the nodes are arranged on the network with equal network distances between them. Specifically, for example, the ring structure may be configured with one or more layers, or may have a server or the like that has information about the nodes that make up the entire network, and may have a structure that returns information about the connection destination node in response to a request from the connection request source node.
By realizing such a structure, the relative positions of each node are equalized, which prevents errors in synchronization timing and information gaps caused by distance issues, and as a result, minimizes the latency from transaction transmission, approval, and reception. Also, by realizing a ring-type network structure, it becomes easy for multiple MNs participating in the network to simultaneously execute approval processing in parallel, which speeds up transaction approval processing and ensures scalability.

In addition, in a GLS system that employs this ring-type network structure, the number of MNs and SNs may be increased or decreased depending on the amount of information flowing through the network. For example, if there are an excess of MNs compared to the amount of transactions flowing through the network, the MNs considered to be surplus may go to sleep automatically, optimizing transfers and traffic within the network. On the other hand, if there is an insufficient supply of MNs for transactions, sleeping MNs can be woken up to process the transactions. The same applies to SNs. This type of mechanism has the advantages of adjusting the scale of the network, reducing the number of transfers of transactions exchanged between nodes, improving processing speed, improving TPS, and optimizing power consumption throughout the network.

Furthermore, we will explain the details of the characteristic data structures that can be adopted in the GLS system. Specifically, we will explain (1) a header that manages MNs, (2) a signal that manages time within the system, and (3) a transaction that employs a Directed-Acyclic-Graph (DAG) that functions as a transaction record.

<Header for managing MN>
First, the header for managing the MN will be described.
The header is information having a data structure in which a list of RN candidates is recorded. The header is appended to by all RN candidates operating at the time each time a MN joins or leaves as a new RN candidate. In other words, each of all nodes participating in the GLS system network can confirm the list of MNs currently performing approval work by receiving this header information. In addition, each of all nodes participating in the network can verify the integrity of transactions by checking the history of all past participation of each MN in RN candidates and comparing it with predetermined approved transactions, thereby ensuring reliability.
Furthermore, in the GLS system, a distributed ledger that manages RN candidates is prepared separately from transactions, and newly joining MNs are managed in the form of a header. In the management of RN candidates, MNs that are scheduled to join can be rigorously screened over time against the participation conditions, which can further eliminate vulnerabilities.

<Signals that manage time within the system>
Next, signals used for managing the time within the system will be described.
A signal is a data structure that records the 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 distributed ledgers but also in the field of conventional distributed computing, there are clock value errors at each node on the network and time lags due to communication, making it extremely difficult to share absolute time.
Therefore, in the GLS system, the system time is determined in advance, and signal nodes (hereinafter referred to as "SGNs (Signal Nodes)") that transmit signals containing information about that system time are placed on the network, and the placed SGNs transmit signals at any unit time, thereby realizing the sharing of absolute time information.
This makes it possible for the GLS system to control data on a time axis in the same way as conventional centralized databases, and to provide finality.
After the signal is assigned with information about the time in the system, it is given a digital signature by a specific SGN and is transmitted to the network at an arbitrarily determined unit time. If an incorrect time is generated maliciously and assigned to a transaction, this can be detected by verifying the digital signature assigned to the signal. As an example of a verification method, each node may hold a list of public keys of official signals and verify the correctness of the signal by comparing the public key assigned to the signal.

A more detailed explanation will be given with reference to Fig. 5. Fig. 5 is a schematic diagram showing the difference in approval responsibility areas with signals as the axis.
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, since the time of the MN's role and the status of the transaction can be divided along the time axis at an arbitrary timing, for example, N1, it is possible to perform smooth and high-speed role change and transaction approval work. This signal is not used in existing distributed ledger services, etc. Therefore, there is no clear standard for which approver (node) is responsible for approving the transaction, and there remains a risk of multiple approval by multiple approvers or so-called fork occurring. In this regard, the GLS system according to the present invention adopts a time axis called a signal to control the network, and the MN responsible for approving each transaction is uniquely determined. Therefore, for example, it is possible to make a decision such as giving priority to a transaction that has been approved earlier on the time axis and discarding the remaining transactions. Furthermore, as a result, it is possible to prevent the above-mentioned double approval situation and obtain finality in the transaction.
However, it is not necessary to adopt the method relating to the approval authority of a transaction shown in Fig. 5. Moreover, the method relating to the approval authority of a transaction shown in Fig. 5 is merely an example and is not limiting.

<DAG functions as a transaction record>
Next, we will explain DAG (Directed Acyclic Graph) used for managing transactions. DAG is, for example, a directed graph without a closed loop in graph theory, and is one of the technologies that can be applied in fields such as databases. In the GLS system, for example, by adopting DAG and linking transactions using hashing, it is possible to reduce waiting time due to waiting in line for transaction approval.

The GLS system can adopt these features as appropriate, so it is expected to achieve ultra-high speed processing while ensuring security equal to or greater than that of existing blockchains.
From the above, by screening MNs participating as RN candidates in advance using the header, it is possible to prevent malicious approvers from participating, thereby achieving high security.
In addition, conventional distributed ledger technology required a consensus process to determine a trustworthy node for each transaction approval. However, in the GLS system, the MN selects an approval node in advance, eliminating the need to select one for each transaction approval, enabling faster approval.

Furthermore, in the GLS system, by applying DAG to transaction management, transaction approval processing is performed in parallel, thereby ensuring scalability.
The introduction of signals gives finality to approvals. In other words, by setting multiple criteria for transactions, including a time axis, it prevents duplicate approvals. With these characteristics, the GLS system is expected to function as a scalable system that processes transactions at high speed while taking advantage of the benefits of blockchain, such as resistance to tampering, zero downtime, and ensuring transparency and fairness.
Here, tamper resistance means the difficulty of maliciously rewriting a transaction that has already been confirmed, and zero downtime means that the time that various systems and services related to the GLS system are out of function is close to zero. In addition, in the GLS system, transparency and fairness can be ensured by allowing all nodes participating in the network to refer to and constantly verify past history. This is one of the features realized by the fact that any participant can become a MN that has the authority to approve transactions.
However, the GLS system does not always need to have all of these features. In other words, there is no particular limit as to whether to adopt all or only some of the above-mentioned various features, and this may be decided arbitrarily by the provider of the GLS system, etc.

<Nodes with other roles>
Here, a description will be given of nodes other than the nodes to which the above-mentioned roles are assigned.
(1) Topology Server (hereinafter referred to as "Router Node" or "RTN")
Unlike the various nodes mentioned above (e.g., RN, MN, SN, NN), the RTN is not involved in creating or approving transactions, but acts as a server that manages the node connections of the entire network. In other words, it adjusts the number of MNs and SNs according to the ratio of the numbers of MNs, SNs, and NNs, and smoothly controls the entire network in the GLS system.
In the case of a P2P (Peer to Peer) network or the like used in a typical distributed ledger technology, it is extremely difficult to adjust the scale of the network because flexible network management cannot be performed. For this reason, for example, an increase or decrease in the number of nodes in the network may cause an excessive increase in the number of traffic transfers. In other words, unnecessary resource consumption may occur in the entire network, which may result in increased power consumption and a decrease in TPS. In contrast, the GLS system employs such a mechanism to achieve traffic adjustment and optimization of the entire network.

Incidentally, conventional centralized servers have problems such as increased latency due to DoS attacks, etc. In contrast, even if a direct attack on the RTN, which has elements of a centralized server in the GLS system, causes an increase in the server load, the core processing of the information processing system, such as transaction approval, is all executed by the MN, so that the increase in the server load on the RTN does not actually cause a decrease in latency, and data processing can be executed stably.
As for the operation method of RTN, as described above, in the GLS system, nodes with high importance (such as RNs and MNs) are generally decentralized. RTN is an exception to this rule.
That is, the RTN can be operated by the provider of the GLS system as the starting point of the entire network when performing (1) operational maintenance of the GLS system, (2) network recovery, (3) execution of rollback, etc. This allows the provider of the GLS system to, for example, stop the entire network as necessary and perform operations required for operation and management.

(2) Signal Node (SGN)
As described above, an SGN is a node that issues a signal to which the system time in the GLS system is assigned. In the case of a conventional centralized network, such a time axis is determined based on a server. However, in an area called distributed computing such as a distributed ledger, it is extremely difficult to share time in an absolute sense because of the existence of clock value errors and communication time lags in each node on the network. In order to solve such problems, in the GLS system, an SGN is operated on the network and the entire network is controlled by signals.
If there is only one SGN in a network, delays in signal transmission may occur as the network grows, which may cause problems with network synchronization. For this reason, in the GLS system, multiple SGNs are placed in the network to issue signals in parallel. An example of the placement of SGNs in a network will be specifically described below with reference to FIG. 6.

FIG. 6 is a diagram showing an example of an arrangement of SGNs in a network.
In the example of Fig. 6, 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) transmits a signal to the other nodes. 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 a signal is transmitted in a state in which an error occurs in the clock value itself contained in the signal transmitted from SGN(A) to SGN(C), each node adopts the signal with the latest time information among the received signals as the latest. In addition, the synchronization error may be reduced by taking the standard deviation of the signals received within an arbitrary time period immediately after receiving the signal.

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

The information processing system of the present invention is an information processing system including a network (hereinafter referred to as a "GLS network") including RN1, n MNs 2-1 through 2-n (n is any integer value equal to or greater than 1), p SNs 3-1 through 3-p (p is any integer value equal to or greater than 1), and q NNs 4-1 through 4-q (q is any integer value equal to or greater than 1), and an RTN (server) 5. The GLS network and the RTN 5 are configured by being connected to each other via a predetermined network (NW) such as the Internet. Furthermore, each of the nodes included in the GLS network is connected by a predetermined method such as P2P. Hereinafter, when there is no particular need to distinguish between MNs 2-1 through 2-n, SNs 3-1 through 3-p, and NNs 4-1 through 4-q, they will be collectively referred to as "RN1", "MN2", "SN3", and "NN4", respectively.
In the example of Figure 7, each node connected to the GLS network has applied to RTN5 in advance to participate in the GLS network, and the role to be played by each node has been determined and the connection destination has been specified, and the GLS network has been constructed.
That is, before constructing the GLS network, the RTN 5 obtains information about nodes that wish to participate in the GLS network. Based on the information, the RTN 5 determines the role and connection destination of each node. Then, the RTN 5 transmits information about its own role and connection destination to each node. In this way, the above-mentioned GLS network is constructed.
In addition, the GLS network may include not only RN1, MN2, SN3, and NN4, but also nodes having other roles, including, for example, an 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 a hardware configuration of the RTN in the information processing system shown in FIG.

The RTN5 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, an output unit 16, an input unit 17, a memory unit 18, a communication unit 19, and a drive 20.

The CPU 11 executes various processes according to a program recorded in the ROM 12 or a program loaded from the storage unit 18 to the RAM 13 .
The RAM 13 also stores data and the like 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 memory unit 18, a communication unit 19, and a drive 20 are connected to the input/output interface 15.

The output unit 16 is configured with, 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 configured with, for example, a keyboard, and inputs various information in response to user instructions.
The storage unit 18 is composed of a hard disk, a DRAM (Dynamic Random Access Memory), etc., 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.

The drive 20 is provided as necessary. Removable media 31, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is appropriately loaded into the drive 20. The program read from the removable media 31 by the drive 20 is installed in the storage unit 18 as necessary.
Further, the removable media 31 can 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 similar to an example of the hardware configuration of server RTN5, so a description will be omitted here.

Fig. 9 is a functional block diagram showing an example of the functional configuration of the NN, SN, MN and RN in the GLS system shown in Fig. 7. First, an example of the functional configuration of the NN 4 will be described.
As shown in FIG. 9, the CPU 60 of the NN4 functions as a transaction generation unit 80, an unapproved transaction management unit 81, an approved transaction management unit 82, a consistency verification unit 83, and a signal management unit 84 by executing various programs, etc.
The transaction generating unit 80 generates a transaction according to the content of the executed trade.

The unapproved transaction management unit 81 transmits the transaction generated by the transaction generation unit 80 to each of the other multiple NNs 4 and multiple SNs 3.

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

The consistency verification unit 83 verifies the consistency of the approved transactions obtained by the approved transaction management unit 82.

The signal management unit 84 acquires signals sent from an SGN (not shown) and manages them. In other words, the signal management unit 84 manages the system time of each of the NNs 4.

Next, an example of the functional configuration of SN3 will be described.
As shown in FIG. 9, the CPU 100 of SN3 executes various programs and the like to function as an unapproved transaction manager 120, an approved transaction manager 121, a consistency verification unit 122, and a signal manager 123.
The unconfirmed transaction manager 120 acquires the transaction sent from the NN 4. If the unconfirmed transaction manager 120 determines that there is no problem with the integrity of the acquired transaction, it transmits the transaction to each of the other multiple SNs 3 and multiple MNs 2.

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

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

The signal management unit 123 acquires signals sent from SGNs (not shown) and manages them. In other words, the signal management unit 123 manages the system time of each of the SNs 3.

Next, an example of the functional configuration of the MN 2 will be described.
As shown in FIG. 9, the CPU 140 of the MN 2 functions as an unapproved transaction management unit 160, an approved transaction management unit 161, a consistency verification unit 162, a signal management unit 163, and an RN processing unit 164 by executing various programs, etc.
The unconfirmed transaction manager 160 acquires the transaction sent from SN 3. If the unconfirmed transaction manager 160 determines that there is no problem with the integrity of the acquired transaction, it transmits the transaction to each of the other multiple MNs 2 and RNs 1.

The approved transaction management unit 161 acquires the approved transactions sent from RN1, which will be described later.

The integrity verification unit 162 verifies the integrity of the transactions acquired by the unapproved transaction manager unit 160 and the approved transactions acquired by the approved transaction manager unit 161 .
That is, the consistency verification unit 162 monitors the approval behavior of the RN.
Monitoring the approval behavior of an RN specifically includes, for example, checking whether the created block number matches, whether the public key embedded in the created block belongs to the correct RN, whether a signal is embedded in the block and if it indicates a time earlier than the previous block, whether the shard number and the shard to which the approving RN belongs are the same if shards (described below) exist, whether the digital signature of the block creator represents the creator, and whether there are any problems with the integrity of the transactions stored in the block.

The signal management unit 163 acquires signals sent from an SGN (not shown) and manages them. In other words, the signal management unit 163 manages the system time of each MN2.

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

Finally, an example of the functional configuration of RN1 will be described.
As shown in FIG. 9, the CPU 180 of RN1 executes various programs and the like to function as an unapproved transaction acquisition unit 200, an approved transaction generation unit 201, and an approved transaction management unit 202.
The unapproved transaction acquisition unit 200 acquires the transaction sent from the MN 2.

The approved transaction generation unit 201 verifies the consistency of the transaction acquired by the unapproved transaction acquisition unit 200. If it is determined that there is no problem with the consistency verification, 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 multiple MNs 2.

The signal management unit 203 acquires signals transmitted from an SGN (not shown) and manages them. In other words, the signal management unit 203 manages the system time of each RN1.

Next, an example of the flow of transaction processing executed in the NN 4, SN 3, and MN 2 will be described with reference to Fig. 10. Fig. 10 is an arrow chart showing an example of the flow of transaction processing related to the NN, SN, and MN.
In the example of Figure 10, the series of processes executed in relation to a transaction in NN4, SN3, and MN2 will be collectively referred to as transaction processing, and the various processes executed in relation to a transaction performed in each of the NN, SN, MN, and RN will be referred to as NN-side transaction processing, SN-side transaction processing, MN-side transaction processing, and RN-side transaction processing, respectively.

In step S1, the transaction generation unit 80 of the NN 4 generates a transaction according to the contents of the executed trade.
Here, NN4 may generate an unapproved transaction by creating new data based on information of past approved transactions and attaching a digital signature to the data. The unapproved transaction here refers to a transaction that has not yet been approved by RN1.

In step S2, the unconfirmed transaction management unit 81 of NN4 transmits the transaction generated in step S1 to each of the other multiple NN4s and multiple SN3s.

In step S21, the unconfirmed transaction management unit 120 of SN3 acquires the transaction sent from NN4 in step S2.

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

In step S23, the unconfirmed transaction management unit 120 of SN3 transmits the transaction whose consistency was confirmed in step S22 to each of the other SN3s and MN2s.

In step S41, the unapproved transaction management unit 160 of MN2 acquires the unapproved transaction sent from SN3 in step S23.

In step S42, the consistency verification unit 162 of MN2 verifies the consistency of the transaction acquired in step S41. If there is a problem with the consistency verification, the transaction is discarded.

In step S43, the unconfirmed transaction management unit 160 of MN2 transmits the transaction that was determined to have no problems in the integrity verification in step S42 to each of the other multiple MN2s and RN1s.

In step S61, the unapproved transaction acquisition unit 200 of RN1 acquires the transaction sent from MN2 in step S43.

In step S62, the approved transaction generation unit 201 of RN1 verifies the integrity of the transaction obtained in step S61. If there is a problem with the integrity verification, the transaction is discarded.

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

In step S64, the approved transaction manager 202 of RN1 transmits the approved transaction generated in step S63 to each of the multiple MNs 2.
Furthermore, in step S65, the approved transaction manager 202 of RN1 stores the generated approved transaction in a database or the like (not shown).

In step S44, the approved transaction management unit 161 of MN2 obtains the approved transaction sent from RN1 in step S64.

In step S45, the integrity verification unit 162 of MN2 verifies the integrity of the approved transaction acquired in step S44. If there is a problem with the integrity verification, the transaction is discarded.

In step S46, the approved transaction manager 161 of the MN 2 transmits the approved transaction whose consistency has been confirmed in step S45 to each of the other multiple MNs 2 and multiple SNs 3.
Furthermore, in step S47, the approved transaction manager 161 of MN2 stores the approved transaction, the consistency of which has been confirmed, in a database (not shown) or the like.

In step S24, the approved transaction management unit 121 of SN3 obtains the approved transaction sent from MN2 in step S46.

In step S25, the integrity verification unit 122 of SN3 verifies the integrity of the approved transaction obtained in step S24. If there is a problem with the integrity verification, the transaction is discarded.

In step S26, the approved transaction manager 121 of SN3 transmits the approved transaction whose consistency was confirmed in step S25 to each of the other multiple SNs 3 and multiple NNs.
Here, the approved transaction manager 121 may determine the destination node based on, for example, any criterion. That is, for example, the approved transaction manager 121 may transmit the approved transaction to each node without determining a particular priority, or, for example, if there is a node to which the approved transaction should be preferentially transmitted based on any criterion, the approved transaction may be transmitted preferentially to that node.
In step S27, the approved-transaction manager 121 of SN3 stores the approved transactions that have been determined to have no problems in the consistency verification in a database (not shown) or the like.

In step S3, the approved transaction management unit 82 of NN4 obtains the approved transaction sent from SN3 in step S26.

In step S4, the integrity verification unit 83 of the NN4 verifies the integrity of the approved transaction obtained in step S3. If there is a problem with the integrity verification, the transaction is discarded.

In step S5, the approved transaction manager 82 of the NN 4 transmits the approved transactions that have been determined to have no problems in the consistency verification in step S4 to each of the other NNs 4.
In step S6, the approved transaction manager 82 of the NN 4 stores the approved transactions that have been determined to have no problems in the consistency verification in a database (not shown) or the like, whereby the transaction processing ends.

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

Although not explained in the above embodiment, the GLS network is not always fixed, and there may be new nodes (hereafter referred to as "joining nodes") that wish to join the GLS network. Therefore, with reference to FIG. 11, we will briefly explain the details of various processes when there is a node that wishes to join.

In step S81, the RTN 5 acquires information regarding a registration list of all nodes (hereinafter referred to as "all node information"), including information on all nodes currently constituting the GLS network.
There is no particular limitation on the method by which RTN5 obtains all node information. For example, RTN5, which manages the entire GLS network, may have a DB in which information regarding the GLS network is currently always stored, and may obtain all node information from there.

Here, in step S61, the participation wishing node transmits to the RTN 5 information indicating that it wishes to participate in the GLS network (hereinafter referred to as "participation wishing information").
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 a role for the participating node based on the all-node information acquired in step S81 and the participation wish information acquired in step S82.
Furthermore, in step S84, the RTN 5 determines a specific connection destination in the GLS network of the participating node based on the all-node information acquired in step S81 and the participation request information acquired in step S82.

In step S85, RTN5 transmits information regarding the role selected in step S83 and the connection destination determined in step S84 to the node wishing to participate.

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

Although not described in the above embodiment, differences between MNs and RNs in the GLS system and "minors" in existing systems will now be described in detail.
Miners, which are widely used in existing systems, perform mining for transaction approval by searching for hash values that match certain conditions. Note that mining specifically refers to the search for hash values in the series of processes that approve transactions.
The idea behind this is to ensure fairness and security of the entire system by introducing randomness into the nodes responsible for approval.
In contrast, in the GLS system, it is possible to change the node (particularly the RN) responsible for approval in response to a specific trigger (for example, a user operation).
For example, in one method, the GLS system may randomly determine the node in charge of approval at the time of user operation by passing an arbitrary token between MNs or between an MN and an RN. In this way, the GLS system can artificially impart randomness to the determination of the node in charge of approval, and prevent only a specific node from becoming the approver.
As another example, in one method, unlike existing systems, the GLS system may determine the node responsible for approval based on the content of the transaction generated based on various user operations, time information (signals) assigned when the transaction was generated, and the configuration of the entire network.
Specifically, for example, the GLS system may vary the hash values generated depending on the contents of a transaction generated based on various user operations, the timing of generation, etc., and may determine a node (e.g., RN) responsible for approval by combining and referring to these hash values. Also, a node (e.g., RN) responsible for approval corresponding to a specific hash value may be determined depending on the overall network configuration at that time.
These elements are difficult to predict and manipulate before a transaction is generated. In other words, the GLS system combines different random elements to impart a high degree of randomness to the decision of the node responsible for approval, thereby ensuring fairness and security (reducing the risk of information being tampered with).

Although not described in the above embodiment, the significance of signals (signal nodes) in the GLS system will be supplemented in detail below.
In conventional distributed ledger systems, problems have often been pointed out, such as the fact that when viewed from the perspective of an arbitrary node, the order in which information is received may differ from the order in which the information is processed, and that the time information (timestamp) assigned to received information is not necessarily accurate.
In this regard, there have been attempts to obtain accurate time information by receiving the timestamp added when processing information from a dedicated server, rather than from the server that processed the information. For example, in the blockchain of Blueprint of Works, there have been attempts to solve the above-mentioned problem by using "block numbers" instead of timestamps. However, even when using "block numbers", it was difficult to calculate a time that was more precise than the block generation interval (the agreed-upon time).
In contrast, a signal node in the GLS system has the following elements:
(1) In the past, time information was obtained actively by sending a request to a dedicated server. However, signal nodes distribute time information via P2P at any arbitrary time, so that each node (server) can passively receive the time information.
(2) In the conventional method using a dedicated server, there is a risk of attacks on the dedicated server, whereas a signal node can serve as any node within the GLS system, making it difficult to identify the node (server) distributing time information from outside.
Therefore, a GLS system that employs signal nodes has the following advantages (features), for example:
(a) When installing dedicated servers, the load increases in proportion to the number of servers installed. However, the GLS system allows signal nodes to be operated in a P2P manner, so the load on signal nodes does not increase as the scale of the system increases.
(b) In the GLS system, it is easy to conceal the location of a signal node. Even if the location is discovered and the system goes down (is attacked), the signal node can be reinstalled simply by registering the IP address or domain of the signal node as a connection destination in another node (e.g. RTN), so the GLS system can be easily restored.
(c) As described above, time information transmitted from a signal node can be digitally signed, so that other nodes can easily identify whether the time information received is from a legitimate source when receiving the time information. Furthermore, because digitally signed time information can only be issued by the signal node, it can also prevent attacks such as transmitting information with a future date.
Using this method, the GLS system can realize the "installation of a server that transmits time information," which was difficult to apply in conventional distributed ledger systems, and it becomes possible to obtain accurate time information even at intervals shorter than the block generation interval.
To explain these advantages in more detail, for example, in a conventional distributed ledger system, when viewed from the viewpoint of an arbitrary server, accurate time information cannot be obtained, making it difficult to confirm whether information has been processed or not, and therefore there are cases where the same content must be processed. However, in the GLS system, a method can be adopted in which a node to be processed is assigned at any time, assuming accurate time information. Therefore, duplication of processing of the same content can be significantly reduced, and the scalability of the entire system can be significantly improved.
Here, in the example of the technology that employs a "block number" to obtain the time, for example, a possible solution would be to shorten the interval at which blocks are generated.
However, in Proof of Work, the approvers of the blockchain are randomly determined, and multiple approvers may process the same transaction. Therefore, each node must focus on verifying multiple blocks that contain transactions with the same content. In addition, combined with the characteristic that only blocks that have been verified are distributed to other nodes, this results in a problem of uneven block extension or sharing of the same blocks throughout the system.
This causes a bias in the time information received by each node, and in a proof-of-work system that requires synchronization and sharing of blocks, the overall processing speed of the system decreases. Although such problems remain in the GLS system, the processing speed is improved by adopting the above-mentioned "signal."
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, it can smoothly verify and distribute them with a small load. In addition, the GLS system can reduce unintended information sharing by allowing information to flow in only one direction using a circular network configuration. Therefore, bias in time sharing within the network is eliminated. Furthermore, the GLS system aims to further improve efficiency by separating the approver and the time information distributor, and by separating the verification process and distribution route of each piece of information.
On the other hand, in order to improve the processing speed of blocks or transactions, if there are nodes, such as the sender and receiver, for which it is desirable to give priority to the transmission of transactions (or blocks), a mechanism can be adopted in which transactions are distributed preferentially to those nodes.

Also, for example, in the above embodiment, the timing at which the contents of the transaction are finalized is described as being the point at which approval is given by the RN, but this is not particularly limited.
For example, if confirmation is made after verification of the consistency of multiple nodes, the redundancy of the system can be improved but the processing performance will decrease.On the other hand, if confirmation is made after approval of one node, the redundancy of the system will be lost but the processing performance will be improved, so the timing of confirmation is at the discretion of the provider.
In other words, the GLS system may determine the consistency when all relevant nodes have verified the consistency (determined that there is no problem), or it may determine the consistency when, for example, the transaction is stored in each block or when the transaction is linked to the previous transaction.

For example, although not described in the above embodiment, a node that may be employed in a GLS system may also transmit transactions to nodes of the same rank (having the same role) to which it is connected. Furthermore, in this case, each of the nodes of the same rank to which it is connected may receive the transaction in the same manner and then execute the transaction processing flow according to the above steps.

For example, in the above embodiment, the term blockchain has been described as referring to a database structure composed of blocks, but is not limited to this. For example, the term "blockchain" may be used in a broader sense to refer to various distributed information systems, P2P networks, transaction approval mechanisms, etc.

Also, for example, although not described in the above embodiment, the GLS system may adopt a mechanism in which, when a new MN wishes to join the network, a vote is held among MNs that are RN candidates to determine whether or not they may join, and as a result, only MNs that are able to participate become RN candidates.
In existing public distributed ledgers, approval by anonymous third parties was permitted, making it difficult to take effective measures against so-called 51% attacks. However, in the GLS system, by adding installation conditions to the MNs, which are nodes with approval authority as described above, an entity responsible for the ownership of MNs (e.g., the provider of the GLS system) can hold more than 50% of normal MNs at all times, making it possible to take effective measures against so-called 51% attacks.

Further, for example, in the above embodiment, each node constituting the GLS network has been described as being connected by a method such as P2P, but the following will be further supplemented.
That is, as described above, the GLS network connection in the above embodiment can adopt, for example, the so-called hybrid P2P technology, which allows free control of the network structure and facilitates control of the communication path of transactions from the center to the edge.
On the other hand, existing services related to blockchain technology use general P2P, so the communication route of transactions is random, and it is difficult to control the communication route from an arbitrary node to a specific node. Therefore, a route close to the optimum is generally selected for communication, but even if high-speed transaction approval is achieved, there is a limit to the improvement of the average latency.
In contrast, the GLS system in the above-described embodiment employs hybrid P2P, which makes route selection easy, and therefore allows the selection of the optimal communication route, making it possible to reduce the average latency more than with general P2P.
In addition, although an increase in latency is inevitable as the network scale expands, in the GLS system, for example, when the GLS network spans multiple countries, the rate at which the latency increases can be reduced by implementing a connection that prioritizes nodes with low latency between nodes and network sharding, and the structure also makes it easy to respond to external infrastructure changes such as 5G. Such flexibility of the system itself can be said to be a unique feature not seen in existing services that use blockchain, etc.

Here, the advantages and synergistic effects of the "hierarchical network structure" and "ring-type network structure" of the GLS system in the above-mentioned embodiment will be briefly supplemented.
In the GLS system, in addition to setting the role of each node in a hierarchical network structure, the connections between nodes are constructed as a circular network structure for each role, making it possible to connect networks for each hierarchy in a self-similar manner.
In other words, regardless of the number of nodes in the GLS system, it is easy to build a network with a structure that efficiently propagates transactions. Therefore, in the GLS system, the transmission of information between MNs is made more efficient, and approved transactions that should be referenced at the time of approval are synchronized at high speed. As a result, the GLS system is expected to further improve the processing speed for transaction approval.
Furthermore, the GLS system can improve the speed of unapproved transactions, from generation to approval, and synchronization processing, etc. In addition, since the network structure can be freely controlled, it is easy to control the communication path of transactions from the center to the edge, and the average latency can be reduced.
In the GLS system, extremely high-speed and efficient transaction processing is realized by combining the respective advantages of the "hierarchical network structure" and the "ring-type network structure" and by utilizing the synergistic effects of these two.

Here, the signals and signal nodes (SGN) in the above embodiment will be 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 each node can refer to the signal to know the time when the transaction was created and approved.
Therefore, in order to improve the accuracy of the signal, the GLS system may adopt, for example, the following methods in combination.
(1) If the time when a signal was embedded in a transaction is older than the last signal received, the older signal can be discarded. This may allow each transaction to always have the latest signal.
(2) A plurality of signal nodes may be installed and each signal node may distribute a signal, thereby making it possible to efficiently provide a signal.
(3) The time at which each signal is embedded may be statistically processed (for example, by calculating the standard deviation) and the time within the system may be determined based on that.
(4) Each node may be able to determine which signal node generated each signal embedded in a transaction by verifying a public key, etc.
Note that a signal node does not necessarily have to assign a signal to a transaction if the transaction does not have any significance in terms of the order of processing, or if another signal has already been assigned to the transaction.

For example, by using signals embedded in transactions, it is possible to manage transactions that have been created and approved in chronological order, making it possible to assign a time-based ranking to each transaction.
Specifically, for example, when each master node (MN) votes to select a new master node (MN) or decide to withdraw, it is possible to determine whether the vote is consistent and correct by referring to the signal time. This allows for more accurate selection of master nodes (MN), further reducing the security risk of the entire system.
Specifically, by verifying the time of signals at each point in time, such as when an MN is selected or withdrawn, when nominating, voting, vote counting, winning, continuing, changes to the MN list, and nominating, it is possible to determine whether a consistent process has been achieved.

In addition, although not described in the above embodiment, the GLS system can further reduce network traffic by applying a technique called consistent hashing. A specific application method in the GLS system will be described below with reference to FIG. 12.
Here, a technique called consistent hashing is known as a method for distributing and storing a large amount of data among arbitrary nodes. In the GLS system, too, a technique that applies this consistent hashing technique can be implemented.
In other words, by having each node hold various types of information in the GLS system (for example, how to hold transactions, which RN will approve which transactions, etc.), the amount of communication throughout the system can be reduced.
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 the block immediately before the information each node is responsible for (hereinafter referred to as the "responsible shard"), based on the idea of distributed ownership of the consistent hashing method, and a block of information different from the responsible shard.
In the example of FIG. 12, when verifying a transaction, MN-A generates block A and calculates the hash value of block A. Then, depending on the calculated hash value, it selects the target (information) to be referenced. In the example of FIG. 12, this is MN-B. MN-B verifies transaction B, which it is responsible for verifying, generates block B in which transaction B is stored, and then links it to 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 is approved and given finality only after it is linked to the next related block.
In this way, in the GLS system, transactions are linked across the shards that each MN holds in a distributed manner. Therefore, the GLS system can perform transaction verification in a redundant manner by multiple nodes, which not only reduces the amount of communication in the entire system, but also makes it easy to restore the entire system even if verification by any node is lost.
If there are no unverified transactions but there are unconfirmed transactions in a block, the MN can approve the unconfirmed block by generating and concatenating a block that does not contain any transactions.
Also, information such as the transaction of block A is sent to MN-B via an arbitrary SN, which 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, if an abnormality is found in the verification of consistency by another MN connected to the MN, for example, if an abnormal transaction is included in a block that is a candidate for linking immediately before approval, the MN may be linked to a normal block that precedes the block. This prevents finality from being given to the abnormal transaction, making it possible to effectively deal with attacks such as those described above.
Also, for example, in the GLS system, if any MN (e.g., MN-B) stops functioning due to a failure, another MN (e.g., MN-C) may take over the processing and perform block generation, etc.
In summary, in a GLS system that applies the consistent hashing method, each node does not hold all the information as in a general distributed ledger network, but only needs to hold the minimum of two pieces of information: the shard that it is responsible for and the information that it is involved in (the reference target), which makes it possible to greatly reduce the amount of information in the entire network. On the other hand, even if a malicious transaction is detected, no blocks are linked to the block containing the abnormal transaction, so finality cannot be obtained. As a result, in a GLS system that applies the consistent hashing method, 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 reducing the accuracy of security.

Here, the application of DAG in the GLS system in the above embodiment will be further supplemented.
DAGs are similar to blockchains in that they are directional, but unlike blockchains, they can execute approval processes in parallel. This is because DAGs can execute approval processes for individual transactions without bundling transactions into blocks, which is expected to dramatically improve the latency of TPS and the entire system.
On the other hand, when DAG is simply used, for example, in order to receive a transaction derived from an arbitrary node, it is necessary to send a list of transactions held by the node. In other words, every time a derived transaction is to be synchronized, a list of transactions must be sent. In addition, a node that receives a list of transactions must check or search for each transaction to see if it was derived, and synchronization takes time. In addition, in conventional distributed ledger technology, the extent to which the transactions have been "synchronized" is identified by synchronizing on a block-by-block basis. This allows multiple transactions to be confirmed together, improving the synchronization speed of information. On the other hand, in the GLS system, the blockchain is extended for each shard to improve the synchronization speed of information. In addition, a DAG is adopted on a block-by-block basis by adding a hash pointer with the block of another shard for each block. Furthermore, by performing verification when linking a block with another shard, mutual monitoring between different shards can be realized. This allows the scalability of sharding to be enjoyed while maintaining tamper resistance.

Further, for example, although description has been omitted in the above embodiment (particularly, the GLS network in FIG. 7), a GWN (Gateway Node) (not shown) that may be included in the GLS network will be described.
The GWN is a node that has the function of connecting to the GLS system network and other external services or networks, and executing conversion processing based on specific data that it acquires.
Specifically, for example, when the GLS system is used as a financial asset transaction system, it can be used to manage financial assets and to manage and convert data of high importance such as financial assets.
In the past, conventional central management systems allowed direct access to the server via the Internet to retrieve data, which meant there was a risk of the system being hacked by malicious attackers, and there was also a risk of the data being tampered with by malicious attackers.
To solve the above problem, the GWN takes measures such as closing ports with a firewall to block one-way connections from each node in the GLS network to the GWN and prohibit access to the GWN from outside, while allowing one-way communication from the GWN to each node in the GLS network.
That is, the GLS system can easily conceal the location of the GWN. Even if the location is discovered and the system goes down (is attacked), the GLS system can be easily restored by simply registering the IP address or domain of the GWN as a connection destination in another node (e.g., RTN).
Here, because each transaction sent and received in the GLS system has the characteristic that only those that pass integrity verification are stored, data that has not been tampered with by information requests made via a one-way connection from the GWN to the GLS network and whose authenticity is guaranteed can be sent and received, and data synchronization can be performed normally.
Next, the processing in the GWN will be specifically described. First, when the GWN executes processing based on information acquired from other external services or networks, it connects unidirectionally from the GWN, acquires data, and creates a transaction in the GLS system based on the read content. The created transaction is approved by itself or MN, etc., and is sent unidirectionally to each node constituting the GLS network. Each node that receives this transmits it to each connection destination, thereby executing synchronization in the entire GLS network. Next, when the GWN acquires a transaction in the GLS system and executes processing based on the read content, it connects unidirectionally from the GWN to each node constituting the GLS network and acquires the transaction. Then, the GWN executes a predetermined processing for other external services or networks based on the acquired transaction. In this way, the GWN executes an approval process based on the acquired transaction, connects unidirectionally to each node constituting the GLS network, and transmits the approved transaction.

In addition, for example, although only a simple explanation has been given in the above embodiment, the structure of a transaction in the GLS system will be described in more detail. The structure of a transaction 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 based on either UTXO (Unspent Transaction Output) or account, but for example, a transaction structure in an existing Bitcoin service can be adopted as a UTXO-based account model. Therefore, the owner of the UTXO is identified, and the existence of Txin (Transaction Input) and the original TxOut (Transaction Output) is confirmed, and then the consistency of the amount, etc. is verified.
Also, for example, the transaction approval process may be performed by adding the RN's digital signature according to the following procedure: That is, the RN compares the new transaction (X) to be approved with the transaction immediately preceding (X) and checks the consistency of the UTXOs of both data. This verifies the consistency of the transaction.

Furthermore, for example, although not described in the above embodiment, when the GLS system is applied to a system such as a cryptocurrency 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, the NN embeds its own TxIn (currency ID, amount, digital signature, creator's public key, etc.) in the order transaction and transmits it to the GLS network or the like as an application for buying and selling assets. In response, for example, the RN acquires the transmitted order transaction, generates a trade transaction in the form of approval based on multiple order transactions that meet the conditions, and transmits it to the NN. The NN acquires the transmitted trade transaction, and again generates an order transaction from the TxOut (remittance address, currency ID, amount, etc.) of the acquired trade transaction. This flow is repeated, and by linking 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 embodiment, all or some of the methods related to the GLS system (such as the roles set for each node, and in particular the RN approval method) can be applied not only to so-called private or consortium-type distributed ledgers, but also to public-type distributed ledgers.

Furthermore, 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 an 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 multiple pieces of hardware depending on its functions and number of processes, or may be realized on an existing information processing device.

Also, for example, the nodes having the functions are not limited to the example shown in FIG. 1 and may be any.
That is, for example, a configuration is shown in which a certain function is provided in the RN, but this is merely an example. For example, at least a part of the function provided in the RN may be provided in another information processing device (for example, the MN or the SN).
In other words, it is sufficient that the information processing system is provided with the functionality to execute the above-described series of processes as a whole, and the functionality used to realize this functionality is not limited to the example of FIG. 1 .

Furthermore, for example, the above-described series of processes can be executed by hardware or software.
Furthermore, one functional block may be configured as a single piece of hardware, a single piece of software, or a combination of both.

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

The recording medium containing such a program may be configured not only as a removable medium (not shown) that is distributed separately from the device body in order to provide the program to the user, but also as a recording medium that is provided to the user in a state where it is already installed in the device body.

In this specification, the steps of writing a program to be recorded on a recording medium include not only processes that are performed chronologically according to the order, but also processes that are not necessarily performed chronologically but are executed in parallel or individually.

Furthermore, the contents of the steps shown in the above-described embodiment (particularly, FIG. 4 and FIG. 10) are merely examples and are not particularly limited.
Specifically, for example, in step SS1 of FIG. 4, the NN transmits the generated transaction to each of the other multiple NNs and multiple SNs, but it may also be configured to transmit the transaction only to the SN without transmitting it to the other multiple NNs.
Also, for example, in step SS2 in Fig. 4, the SN may transmit the transaction for which the integrity has been verified directly to the RN, rather than transmitting it to each of the other SNs and MNs. Note that, if such a step is adopted, some of the steps in Fig. 4 may be modified or omitted as appropriate.

In addition, in this specification, the term "system" refers to an overall device that is composed of multiple devices, multiple means, etc.

In other words, it is sufficient for an information processing device to which the present invention is applied to have the following configuration, and various embodiments can be adopted.
That is, the information processing device to which the present invention is applied is
An information processing device used for managing a network configured with n other information processing devices (n is an arbitrary integer value equal to or greater than 1),
a role setting means for setting a role for each of the n other information processing devices;
a connection destination determination means for determining a connection destination of each of the n other information processing devices based on the set role;
Equipped with.
This makes it possible to provide a technique that can shorten the processing time in a distributed information processing system related to security and can withstand a significant increase in the amount of processing to be executed.

Moreover, the n other information processing devices each execute a process according to the role set by the role setting means for a predetermined unit of information;
The role setting means sets, 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 communicating between the other information processing device to which the first role is assigned and the other information processing device to which the second role is assigned; and
At least one of the following can be set.

The network further includes a hierarchical structure determination unit that determines a hierarchical structure of each of the n other information processing devices constituting the network according to the role set by the role setting unit,
The connection destination determination means includes the hierarchical structure determined by the hierarchical structure determination means and is capable of determining the connection destination.

In addition, the selection and order of other information processing devices that perform approval in the first role can be determined based on time information assigned to each of the other information processing devices.

The connection destination determination means can also determine the connection destination by arranging each of the n information processing devices 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: Unconfirmed transaction management unit 161: Acknowledged transaction management unit 162: Integrity verification unit 163: Signal management unit 164: RN processing unit 3: Supernode (SN)
100...CPU
120: Unconfirmed transaction management unit 121: Acknowledged transaction management unit 122: Integrity verification unit 123: Signal management unit 4: Normal node (NM)
60...CPU
80: Transaction generation unit 81: Unconfirmed transaction management unit 82: Acknowledged transaction management unit 83: Integrity verification unit 84: Signal management unit 5: Topology server (RTN)

Claims (7)

An information processing device used for managing a network configured with n other information processing devices,
a role setting means for setting a role for each of the n other information processing devices;
a connection destination determination means for determining a connection destination of each of the n other information processing devices based on the set role;
Equipped with
each of the n other information processing devices executes a process according to the role set by the role setting means for each unit of predetermined information;
The role setting means sets, for each of the n other information processing devices,
A first role including at least a role of performing a verification process before approval of the unit information;
A second role including at least a role of preferentially executing approval processing when approving the unit information;
a third role including at least a role that is a candidate to be selected as the connection destination having the second role in accordance with a predetermined priority order ;
Set at least one role among
the connection destination having the third role that has not been selected as the connection destination having the second role monitors the approval process of the connection destination having the second role.
Information processing device. The selection and order of the other information processing devices that perform the approval in the first role are determined based on time information assigned to each of the other information processing devices.
The information processing device according to claim 1 . a hierarchical structure determination unit that determines a hierarchical structure of each of the n other information processing devices constituting the network in accordance with the role set by the role setting unit,
The information processing apparatus according to claim 1 , wherein the connection destination determination means determines the connection destination based on the hierarchical structure determined by the hierarchical structure determination means. the connection destination determination means arranges each of the n information processing devices in a ring shape and determines the connection destination;
The information processing device according to claim 1 . the role setting means further sets a fourth role relating to the delivery of the time information to each of the n other information processing devices.
The information processing device according to claim 2 . An information processing method for an information processing device used to manage a network configured with n other information processing devices, comprising:
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 devices based on the set roles;
Including,
each of the n other information processing devices executes a process according to the role set in the role setting step, for each unit of predetermined information;
The role setting step performs the following for each of the n other information processing devices:
A first role including at least a role of performing a verification process before approval of the unit information;
A second role including at least a role of preferentially executing approval processing when approving the unit information;
a third role including at least a role that is a candidate to be selected as the connection destination having the second role in accordance with a predetermined priority order ;
Set at least one role among
the connection destination having the third role that has not been selected as the connection destination having the second role monitors the approval process of the connection destination having the second role.
Information processing methods. A program executed by an information processing device used to manage a network configured by n 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 devices based on the set roles;
Including,
each of the n other information processing devices executes a process according to the role set in the role setting step, for each unit of predetermined information;
The role setting step performs the following for each of the n other information processing devices:
A first role including at least a role of performing a verification process before approval of the unit information;
A second role including at least a role of preferentially executing approval processing when approving the unit information;
a third role including at least a role that is a candidate to be selected as the connection destination having the second role in accordance with a predetermined priority order ;
Set at least one role among
the connection destination having the third role that has not been selected as the connection destination having the second role monitors the approval process of the connection destination having the second role.
program.

Images