JP7016389B1 - Systems and programs - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a system and a program for speeding up processing for a transaction request or ensuring consistency among a plurality of nodes in a distributed ledger technology. SOLUTION: In a distributed ledger system 10, one first node among a plurality of nodes 100 to 103 for distributing and recording a ledger is a plurality of second nodes different from the first node among the plurality of nodes. , Sends the sum of multiple logs based on multiple transactions received from the client terminal. The first node may transmit the total of a plurality of logs to the plurality of second nodes without transmitting the plurality of logs. [Selection diagram] Fig. 2

Description

The present invention relates to a system and a program relating to distributed ledger technology.

Distributed ledger technology using blockchain is used as a method of managing cryptocurrencies (virtual currency) such as Bitcoin. In recent years, it has been studied to use these techniques not only as such cryptographic assets but also as a method for managing and moving various assets (for example, Patent Document 1).

Japanese Unexamined Patent Publication No. 2018-196150

In the distributed ledger technology shown in Patent Document 1, a distributed ledger network is formed by a plurality of nodes (one leader node and a plurality of other follower nodes) connected by P2P (Peer to Peer), and the distributed ledger network is formed. The ledger is distributed and recorded by multiple nodes in.

In the conventional distributed ledger technology as described above, speeding up processing for transaction requests from client terminals and ensuring consistency among a plurality of nodes are important issues.

One of the objects of the present invention is to speed up the processing of transaction requests or ensure consistency among a plurality of nodes in the distributed ledger technology.

In the system according to the embodiment of the present invention, the first node of one of the plurality of nodes for recording the ledger in a distributed manner becomes a plurality of second nodes of the plurality of nodes different from the first node. Sends the sum of multiple logs based on multiple transactions received from the client terminal.

The first node may cause the plurality of second nodes to transmit the total of the plurality of logs without transmitting the plurality of logs.

The first node receives the plurality of transactions from the client terminal in block units including the plurality of transactions, generates the plurality of logs based on the plurality of transactions included in the block, and generates the plurality of logs. The result of summing up the plurality of logs included in the plurality of blocks may be transmitted to the second node.

The first node may store the plurality of logs.

In the program according to the embodiment of the present invention, for the first node of one of the plurality of nodes for recording the ledger in a distributed manner, the plurality of second nodes of the plurality of nodes different from the first node are used. To send the sum of multiple logs based on multiple transactions received from the client terminal.

The first node may be made to transmit the total of the plurality of logs without transmitting the plurality of logs to the plurality of second nodes.

The first node receives the plurality of transactions from the client terminal in block units including the plurality of transactions, generates the plurality of logs based on the plurality of transactions included in the block, and causes the plurality of logs. The second node may be made to transmit the result of summing up the plurality of logs included in the plurality of blocks.

The plurality of logs may be stored in the first node.

According to one embodiment of the present invention, in the distributed ledger technology, it is possible to speed up processing for transaction requests or ensure consistency among a plurality of nodes.

It is a figure which shows the outline of the distributed ledger system which concerns on one Embodiment of this invention. It is a figure which shows the outline of the distributed ledger system which concerns on one Embodiment of this invention. It is a figure which shows the outline of the distributed ledger system which concerns on one Embodiment of this invention. It is a block diagram which shows the functional structure of the reader node used in the distributed ledger system which concerns on one Embodiment of this invention. It is a figure which shows the specific example of the transaction and the log in the distributed ledger system which concerns on one Embodiment of this invention. It is a figure which shows the specific example of the cross section of a log and the final cross section of a log in the distributed ledger system which concerns on one Embodiment of this invention. It is a block diagram which shows the functional structure of the client terminal used in the distributed ledger system which concerns on one Embodiment of this invention. It is a block diagram which shows the functional structure of the follower node used in the distributed ledger system which concerns on one Embodiment of this invention. It is a figure which shows the sequence which shows the operation of the distributed ledger system which concerns on one Embodiment of this invention. It is a figure which shows the flowchart which shows the operation of the distributed ledger system which concerns on one Embodiment of this invention. It is a block diagram which shows the functional structure of the reader node used in the distributed ledger system which concerns on one Embodiment of this invention. It is a block diagram which shows the functional structure of the client terminal used in the distributed ledger system which concerns on one Embodiment of this invention. It is a figure which shows the sequence which shows the operation of exclusive control in the distributed ledger system which concerns on one Embodiment of this invention. It is a figure which shows the sequence which shows the operation of exclusive control in the distributed ledger system which concerns on the modification of one Embodiment of this invention. It is a figure which shows the sequence which shows the operation of exclusive control in the distributed ledger system which concerns on the modification of one Embodiment of this invention. It is a figure which shows the flowchart which shows the operation of the data synchronization algorithm in the distributed ledger system which concerns on one Embodiment of this invention.

Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. The embodiments shown below are examples of embodiments of the present invention, and the present invention is not construed as being limited to this embodiment. That is, it is possible to apply a known technique to a plurality of embodiments described below to modify the plurality of embodiments and carry out the embodiments in various embodiments. In the drawings referred to in this embodiment, alphabets are added after the same reference numerals or the same reference numerals to the same parts or parts having similar functions, and the repeated description thereof will be omitted.

In the following description, the transaction (TX) is information including the content of the transaction requested by the client terminal (Client Terminal; CM). A transaction is composed of a plurality of processes related to or dependent on each other, and the plurality of processes are treated as an inseparable processing unit. Specifically, if all of the plurality of processes are successful, it is determined that the transaction related to the transaction has been completed, and if a part of the plurality of processes fails, the transaction related to the transaction is performed. It is judged to have failed. In other words, the processes that make up a transaction are guaranteed to result in either "all successes" or "all failures." For example, when deposit / withdrawal processing is performed between computers, the deposit / withdrawal processing is required to be "both successful" or "both unsuccessful".

A log (or transaction log) is information in which a plurality of transactions are arranged. Specifically, the log records the order in which database updates are made based on multiple transactions. The log records the update contents such as addition, update, and deletion of data specified by the transaction in chronological order. When the process is interrupted or canceled due to a system failure or the like, the distributed ledger system refers to the log record, restores the updated data, and returns to the state before the transaction started.

The following embodiments exemplify a configuration in which a fixed information processing device such as a server is used as a leader node (LeaderNode; LN) and a follower node (FollowerNode; FN) included in the distributed ledger system. , Not limited to this configuration. Also, techniques between different embodiments can be combined as long as there is no particular technical conflict.

<First Embodiment>
[1-1. System overview]
Using FIGS. 1 to 10, the distributed ledger system 10 according to the first embodiment of the present invention, the information processing device (node 100) constituting the distributed ledger system 10, and the client terminal 400 connected to the node 100 are used. , And a program for operating them will be described. 1 to 3 are diagrams showing an outline of a distributed ledger system according to an embodiment of the present invention.

As shown in FIG. 1, the distributed ledger system 10 has ledgers (databases; DBs) arranged all over Japan, and these ledgers are synchronized with each other. That is, each client can access the distributed ledger system 10 from any ledger in Japan and request a transaction, and the data updated by the transaction is stored synchronously in each ledger. For example, when there is a transaction request (transaction) for "redelivery cost billing" from the client terminal 41 to the ledger 31 (leader node in this example) arranged in Hokkaido, the ledger 31 indicates the order of the transactions. Information (log) is generated, the log is transmitted to other ledgers 32 to 38 (follower nodes in this example), and data is updated in each ledger 31 to 38 according to the log. In this way, synchronization processing of ledgers 31 to 38 arranged all over Japan is performed based on the transaction requested for the ledger 31.

As shown in FIG. 1, the distributed ledger system 10 can be applied to a system in which a person takes the initiative in making a transaction request, such as a conventional virtual currency or asset management. For example, the distributed ledger system 10 may be applied to a system such as “redelivery cost billing” using the client terminal 41 or “room rental” using the client terminal 42. Further, the distributed ledger system 10 can also be applied to a system such as IoT (Internet of Things; Internet of Things) in which a terminal plays a central role in making a transaction request. For example, the distributed ledger system 10 automatically charges for viewing contents (for example, hourly billing by the client terminal 43), automatic billing for reading electronic books (for example, page billing by the client terminal 44), and client terminal 45. It may be applied to a service in which a charge of 1 yen or less than 1 yen (micropayment) may occur, such as an automatic charge generated by a temporary charge by the client. Further, the distributed ledger system 10 may be applied to a microservice realized by combining a plurality of independent functions.

As shown in FIG. 2, the client terminal 400 and the node 100 are communicably connected via the network 500. Further, each node 100 is communicably connected via a dedicated network 600. Each node 100 is a node that distributes and records a ledger (database). In the present embodiment, when it is not necessary to particularly distinguish the three nodes 101, 102, 103, it is simply referred to as a node 100. Further, when it is not necessary to particularly distinguish the three client terminals 401, 402, 403, it is simply referred to as a client terminal 400.

Nodes 101, 102, 103 include servers 111, 112, 113 and databases 121, 122, 123, respectively. When it is not necessary to distinguish between these servers and databases, they are simply referred to as servers 110 and databases 120. The server 110 executes data recording processing and reading processing (data update) for the database 120. The server 110 has a central processing unit (CPU) and a storage device (memory), and by cooperating with each other, various functions described below are realized. Specifically, various functions of the server 110 are realized by the CPU executing the program stored in the storage device. The storage device may be a volatile storage device for temporary storage, a non-volatile storage device, or a combination of these storage devices.

Transactions transmitted from each client terminal 400 are received via network 500, for example, by server 111. The server 111 generates a log according to the received transaction. The generated log is stored in the database 121 connected to the server 111.

The server 111 transmits the above log to the servers 112 and 113 via the dedicated network 600. When the servers 112 and 113 that have received the log store the log in the databases 122 and 123 connected to the respective servers 112 and 113, they send a response indicating that the log has been properly received and stored to the server 111. This operation is called "agreement" or "consensus building". When the consensus building from the servers 112 and 113 is confirmed, the server 111 determines that the log duplication has been performed normally. When the log is duplicated normally, the databases 121, 122, and 123 connected to the servers 111, 112, and 113 are updated based on the log. In this way, the data update based on the transaction transmitted from the client terminal 400 to one node 101 is performed synchronously in each node.

The log stored in the database 121 is used to correct the database in which incorrect data is stored when data inconsistency occurs in a later process.

The network 500 is an Internet such as a general World Wide Web (WWW), a WAN (Wide Area Network), or a LAN (Local Area Network) such as an in-house LAN.

Unlike the network 500, the dedicated network 600 is a dedicated network of the distributed ledger system 10. That is, the dedicated network 600 is a network that the client terminal 400 cannot access.

Although the description is omitted in FIGS. 1 and 2, each node 100 shown in FIG. 2 functions as one leader node 200 and a plurality of follower nodes 300 as shown in FIG. One node 100 selected from the plurality of nodes 100 by the leader election functions as the leader node 200, and the other nodes 100 function as the follower node 300. The function as the leader node 200 is handed over to the next node 100 periodically or triggered by the occurrence of an event. However, the reader node 200 may be fixed. The reader node 200 and the follower node 300 in FIG. 3 each have a server and a database, and operate as in the node 100 in FIG.

As shown in FIG. 3, a plurality of client terminals 400 are connected to the reader node 200. Each of the plurality of client terminals 400 is, for example, a communication terminal of a service provider, and is an information processing device (hardware) possessed by a provider that provides services such as a mobile communication terminal service, an automobile service, and an IoT service. Is. In each client terminal 400, a plurality of client processes (Client Process) 410 (software) are activated. For example, in general, a computer used as an information processing device is equipped with a plurality of CPU cores, so in order to improve the parallelism of processing, client processes 410 equal to or less than the number of CPU cores are started. May be good. However, the above service provider is merely an example, and can be applied to various service providers other than the above. Further, the plurality of client processes 410 may be realized by a single CPU.

The client processes 411-1, 411-2, ..., 411-n operate on the client terminal 401. The client processes 412-1, 412-2, ..., 421-n operate on the client terminal 402. The client processes 413-1, 413-2, ..., 413-n operate on the client terminal 403. The client processes 414-1, 414-2, ..., 414-n operate on the client terminal 404. When it is not necessary to distinguish the above-mentioned plurality of client processes, it is simply referred to as client process 410.

Each of the plurality of client processes 410 receives a transaction request from a user terminal used by each user, generates a transaction corresponding to the transaction request, and sends the transaction to the reader node 200. In the present embodiment, the client process 410 transmits a transaction to the reader node 200 for each transaction request from the user terminal, but after accumulating a plurality of transactions corresponding to the plurality of transaction requests from the user terminal, these plurality. Transactions may be collectively transmitted to the reader node 200 in one communication. Although the details will be described later, when a plurality of transactions are collectively transmitted in one communication, the plurality of transactions collectively transmitted to the reader node 200 are handled in block units.

In the example of FIG. 3, the client process 411-1 of the client terminal 401 transmits transactions TX1 to TX149 to the reader node 200. The client process 411-2 of the client terminal 401 transmits the transactions TX150 to TX500 to the reader node 200. The client process 412-1 of the client terminal 402 transmits transactions TX501 to TX1000 to the reader node 200. Each of the above transactions is transmitted from the client process 410 to the reader node 200 in each communication between the client process 410 and the reader node 200.

The reader node 200, for example, arranges a plurality of transactions TX1 to TX1000 received from each client terminal 400 in order. That is, the processing order for updating the data is determined. In this way, logs are generated based on the plurality of transactions TX1 to TX1000 and the order in which they are arranged. The log is generated for each transaction TX. That is, log 1 is generated for transaction TX1. Further, similarly to the above, a plurality of logs 1 to 1000 are generated based on the plurality of transactions TX1 to TX1000.

The reader node 200 does not send each log of the logs 1 to 1000 generated as described above to each follower node 301, 302, 303, 304 individually, but each log is based on these logs. Is calculated for, and the total of the logs based on the result of the calculation is transmitted to the follower nodes 301, 302, 303, 304. Here, when it is not necessary to particularly distinguish the plurality of follower nodes, it is simply referred to as a follower node 300. When the calculation result for each log is referred to as "log cross section", the calculation result (total of logs) for all logs 1 to 1000 can be referred to as "final cross section of log". In this case, it can be said that the leader node 200 sends only the final cross section of the logs 1 to 1000 to the follower node 300.

When the follower node 300 receives the final cross section of the above log from the reader node 200 and stores it, the follower node 300 returns to the reader node 200 that the consensus has been formed. Upon confirming the consensus building from the follower node 300, the leader node 200 determines that the follower node 300 has normally duplicated the final cross section of the log. A specific method for determining normal duplication of the final cross section of the log will be described later.

When the reader node 200 determines that the final cross section of the log has been normally received, the reader node 200 updates the data of the reader node 200 based on the final cross section of the log. Then, the follower node 300 updates the data based on the final cross section of the log, similarly to the reader node 200. The timing at which the reader node 200 updates the data and the timing at which the follower node 300 updates the data do not have to be the same. For example, after the leader node 200 updates the data, the follower node 300 refers to the state of the leader node 200 at the timing when the log is transmitted from the leader node 200 to the follower node 300 in the next cycle, and is the same as the leader node 200. Data may be updated.

After this data update, the consistency between the updated data is evaluated in each follower node 300. If there is an inconsistency in the updated data between the follower nodes 300, a correction process for correcting the inconsistency is performed. By such processing, synchronization is achieved between the follower nodes 300.

In conventional virtual currency and asset management transactions, the processing speed of each transaction is important, and processing is performed for each log according to each transaction. That is, the purpose is to improve the processing speed for each log transmitted from the reader node 200 to the follower node 300. On the other hand, in the distributed ledger system 10 according to the first embodiment, the overall processing speed is improved by performing processing by totaling a plurality of logs, instead of improving the processing speed for each log. It is an object.

[1-2. Functions of reader node 200]
The function of the reader node 200 of the distributed ledger system 10 according to this embodiment will be described with reference to FIG. FIG. 4 is a block diagram showing a functional configuration of a reader node used in the distributed ledger system according to the embodiment of the present invention. As shown in FIG. 4, the reader node 200 has a CM communication unit 210, a TX reception unit 220, an alignment processing unit 230, a log generation unit 240, a final cross-section calculation unit 245, a distributed processing unit 250, and a data update unit 260. .. These functional units are communicably connected to each other by the communication bus 290. The functions of these functional units are realized by the CPU executing a program stored in the storage device provided in the reader node 200.

The CM communication unit 210 has a function of establishing communication between the client terminal 400 and the reader node 200 when receiving a communication establishment request from each client terminal 400. For example, TCP can be used as a protocol for establishing and terminating the communication.

When the above communication is established by the CM communication unit 210, the TX reception unit 220 receives each transaction (for example, TX1 to TX1000) from the client terminal 400.

The alignment processing unit 230 performs processing for sequentially aligning a plurality of transactions received by the TX receiving unit 220. The alignment processing unit 230 may arrange the transactions in the order received by the TX reception unit 220, or may arrange the transactions according to a specific rule.

The log generation unit 240 generates a log recording the processing contents and order of a plurality of transactions arranged by the alignment processing unit 230. The log (master log) generated by the log generation unit 240 of the reader node 200 is stored in the storage device of the reader node 200. Since the master log is stored in the reader node 200, when an inconsistency occurs between the leader node 200 and the follower node 300, or between a plurality of follower nodes 300, the final cross section of the log using the master log is used. Can be recalculated.

The final cross-section calculation unit 245 calculates the final cross-section of the log based on the cross-section of each log generated by the log generation unit 240. Specifically, the final cross-section calculation unit 245 performs a calculation based on the data update content (for example, the transfer amount) for each update target (for example, the account number) for which the data is updated, so that the final cross-section calculation unit 245 finally performs the calculation for each update target. Calculate the total of updated contents. The final section calculation unit 245 may calculate the final section for the logs generated in a predetermined period, and when the number of generated logs reaches the threshold value, until the threshold value is reached. The final cross section may be calculated for the logs generated in between.

The distributed processing unit 250 transmits (distributed processing) the final cross section of the log generated by the final cross section calculation unit 245 to the plurality of follower nodes 300. For example, the distributed processing unit 250 uses [Append Entries PRC] to transmit the final cross section of all the generated logs to a plurality of follower nodes 300. When the distributed processing unit 250 confirms that the final cross section of the log has been normally stored from the follower node 300, it is determined that the final cross section of the log has been duplicated normally.

When the data update unit 260 determines that the distribution processing unit 250 has normally duplicated the final cross section of the log, the data update unit 260 executes data update according to the final cross section of the log for the database of the reader node 200. Then, it responds to the client process 410 that the data update is completed. At this stage, the data is not updated for the database of the follower node 300, but the data of the follower node 300 may be updated at the same time as the data of the reader node 200 is updated.

[1-3. Specific examples of transactions and logs]
FIG. 5 is a diagram showing specific examples of transactions and logs in the distributed ledger system according to the embodiment of the present invention. As shown in FIG. 5, transaction TX1 is a transaction based on a transaction request to move 100,000 yen from the account number AAA to the account number BBB. Transaction TX2 is a transaction based on a transaction request to move 200,000 yen from the account number BBB to the account number CCC.

A plurality of transactions TX1 and TX2 are transmitted from the same client process 411-1. Therefore, as shown in FIG. 5, both of the plurality of transactions TX1 and TX2 may include a request for renewal processing for the account number BBB which is the same renewal target. Therefore, TX1 and TX2 are arranged in this order so that inconsistencies do not occur between these transactions. Then, log 1 and log 2 corresponding to each transaction are generated in the order of TX1 and TX2. Note that FIG. 5 illustrates a configuration including a case where a plurality of transactions request update processing for the same update target, but a plurality of transactions may not request update processing for the same update target. ..

Specifically, TX1 includes the following processes (1) to (6).
(1) Obtain the balance of the account number AAA (the balance of the account number AAA is 1 million yen).
(2) Obtain the balance of the account number BBB (the balance of the account number BBB is 10 million yen).
(3) Calculate the amount when 100,000 yen is subtracted from the account number AAA (900,000 yen).
(4) Calculate the amount when 100,000 yen is added to the account number BBB (10.1 million yen).
(5) Write 900,000 yen in the account number AAA.
(6) Write 10.1 million yen in the account number BBB.

The processes (1) to (6) of TX1 are treated as inseparable. That is, it is determined that TX1 is established when all the processes (1) to (6) are successful, and it is determined that TX1 is failed when at least one of the processes (1) to (6) fails. Will be done. TX2 is treated in the same manner as TX1.

[1-4. Specific example of the final cross section of the log]
The "cross section of the log" and the "final cross section of the log" will be described with reference to specific examples. FIG. 6 is a diagram showing a specific example of a cross section of a log and a final cross section of a log in the distributed ledger system according to the embodiment of the present invention. FIG. 6 shows the processing contents of the log 1, the log 150, and the log 1000 among the logs 1 to 1000.

In the cross section of log 1, a process of writing 100,000 yen to the account AAA (for example, a process of transferring 100,000 yen to an account AAA with a balance of 0 yen) and a process of writing 1 million yen to the account BBB (for example, the balance is The process of transferring 1 million yen to the 0 yen account BBB) is recorded. In the cross section of the log 150, a process of writing 200,000 yen in the account AAA (for example, a process of transferring 100,000 yen to the account AAA with a balance of 100,000 yen) and a process of writing 1 million yen in the account BBB (for example, the balance). The process of transferring 1 million yen to the account CCC of 0 yen) is recorded. In the cross section of the log 1000, a process of writing 300,000 yen in the account AAA (for example, a process of transferring 100,000 yen to the account AAA with a balance of 200,000 yen) and a process of writing 500,000 yen in the account BBB (for example, the balance). The process of transferring 500,000 yen from the 1 million yen account BBB to another account) is recorded.

In the past, each log was transmitted from the reader node 200 to the follower node 300, but in this embodiment, the cross sections of the logs 1 to 1000 are totaled in the reader node 200, and the final account AAA is 300,000 yen. The final cross section of the logs 1 to 1000 is calculated, that is, writing, writing 500,000 yen in the account BBB, and writing 1 million yen in the account CCC. Then, only the final cross section is transmitted from the leader node 200 to the follower node 300. That is, the reader node 200 transmits the final cross section of the plurality of logs to the follower node 300 instead of the plurality of logs.

[1-5. Functions of client terminal 400]
The function of the client terminal 400 of the distributed ledger system 10 according to this embodiment will be described with reference to FIG. 7. FIG. 7 is a block diagram showing a functional configuration of a client terminal used in the distributed ledger system according to the embodiment of the present invention. As shown in FIG. 7, the client terminal 400 has a transaction request receiving unit 420, a TX generating unit 430, an LN communication unit 450, and a TX transmitting unit 460. These functional units are communicably connected to each other by a communication bus 490. The functions of these functional units are realized by the CPU executing a program stored in a storage device provided in the client terminal 400. Each of the above functional units is executed by each client process 410 of the client terminal 400.

The transaction request receiving unit 420 receives a transaction request from a user terminal connected to the client process 410. The transaction request receiving unit 420 may receive a transaction request from the same user terminal, or may receive a transaction request from different user terminals.

The TX generation unit 430 generates a transaction TX according to the content of the transaction request received by the transaction request reception unit 420. The transaction TX is generated for each transaction request.

The LN communication unit 450 transmits a communication establishment request to the CM communication unit 210 of the reader node 200. The LN communication unit 450 transmits a communication establishment request to the CM communication unit 210 each time a transaction TX is generated by the TX generation unit 430.

When communication is established by the LN communication unit 450, the TX transmission unit 460 transmits the transaction TX generated by the TX generation unit 430 to the TX reception unit 220 of the reader node 200.

[1-6. Functions of follower node 300]
The function of the follower node 300 of the distributed ledger system 10 according to the present embodiment will be described with reference to FIG. FIG. 8 is a block diagram showing a functional configuration of a follower node used in the distributed ledger system according to the embodiment of the present invention. As shown in FIG. 8, the follower node 300 has a cross-section receiving unit 310, a cross-section storage unit 320, a consensus building unit 330, and a data updating unit 340. These functional units are communicably connected to each other by a communication bus 390. The functions of these functional units are realized by the CPU executing a program stored in the storage device provided in the follower node 300.

The cross-section receiving unit 310 receives the final cross-section of the log transmitted by the distributed processing unit 250. The cross-section storage unit 320 stores the final cross-section of the log received by the cross-section receiving unit 310 in a storage device or a database provided in the follower node 300. The consensus building unit 330 returns to the reader node 200 that the consensus building has been formed when the final cross section of the log is normally stored by the cross section storage unit 320. The data update unit 340 confirms the data of the reader node 200 when the section receiving unit 310 receives the final section of the log, and sets the final section of the log to the database of the follower node 300 according to the data of the reader node 200. Perform the corresponding data update.

[1-7. Operation of distributed ledger system 10]
FIG. 9 is a diagram showing a sequence showing the operation of the distributed ledger system according to the embodiment of the present invention. First, the client terminal 400 generates a transaction TX in response to a transaction request from the user terminal (step S701). The generated transaction TX is transmitted to the reader node 200 (step S702).

When the transaction TX is received in the reader node 200 (step S711), the received transaction TX are arranged in the order of reception, for example (step S712). Then, a log is generated based on the processing content and order of the arranged transaction TX (step S713). When the number of generated logs reaches the threshold value (step S714), the final cross section of the log is calculated for the logs generated until the threshold value is reached (step S715). The final cross section of the calculated log is transmitted from the reader node 200 to the plurality of follower nodes 301 and 302 (step S716).

When the final cross section of the log transmitted from the reader node 200 is received at the follower nodes 301 and 302, a process of storing the final cross section of the log in each follower node is performed (steps S721 and S731). When the final cross section of the log is normally stored, the consensus building is returned to the leader node 200 (steps S722 and S732). By confirming the consensus building, the leader node 200 determines that the final cross section of the log has been normally duplicated at the follower nodes 301 and 302, and updates the data (step S717). Then, the reader node 200 notifies the client terminal 400 that the data update has been performed normally (steps S718 and S703).

In FIG. 9, in the follower nodes 301 and 302, the data is not updated based on the final cross section of the log, but the final cross section of the log is transmitted from the reader node 200 to the follower nodes 301 and 302 in the next cycle. At the timing, the follower nodes 301 and 302 refer to the state of the leader node 200 and update the data based on the final cross section of the log received in the previous cycle in the same manner as the leader node 200. However, the data update based on the final cross section of the logs of the follower nodes 301 and 302 may be performed at the same timing as the data update of the reader node 200.

FIG. 10 is a diagram showing a flowchart showing the operation of the distributed ledger system according to the embodiment of the present invention. In the flowchart of FIG. 10, the same steps as those of the sequence of FIG. 9 are designated by the same reference numerals as those of FIG. Since the flow from the start of the operation flow, the occurrence of the transaction TX (step S701) to the generation of the log (step S713) is the same as in FIG. 9, the description thereof will be omitted.

After the log generation in S713, it is determined whether or not the conditions for calculating the final cross section of the log are satisfied (step S802). If it is determined in S802 that the conditions for calculating the final cross section of the log are not satisfied (“No” in step S802), the process returns to S701 and waits for the occurrence of the next transaction TX. On the other hand, when it is determined in S802 that the conditions for calculating the final cross section of the log are satisfied (“Yes” in step S802), the calculation of the final cross section of the log is performed (step S715). In S802, for example, it is determined whether or not the number of generated logs has reached the threshold value. In this case, if the number of generated logs reaches the threshold value, it is determined that the conditions for calculating the final cross section of the logs are satisfied. Then, the final cross section of the log calculated in S715 is transmitted from the reader node 200 to the follower node 300 (step S716).

After S716, the leader node 200 confirms the consensus building (step S803). In S803, if consensus building cannot be confirmed from all the follower nodes 300 (“No” in step S803), the steps S716 → S803 are repeated. On the other hand, when consensus building is confirmed from all the follower nodes 300 (“Yes” in step S803), data update (step S717) and completion notification (step S718) are performed at the leader node 200. Subsequently, the same data update as in S717 is performed in the follower node 300 (step S804).

In conventional distributed ledger technology, it has been required to quickly process individual transactions required by client terminals. Therefore, each time a log is generated based on the transaction related to the transaction, each log is transmitted from the leader node to the follower node. However, since it is necessary to establish communication between the reader node and the follower node each time a log is transmitted, there is a problem that the time for transmitting multiple logs becomes long and the throughput decreases. rice field.

However, according to the distributed ledger system 10 according to the present embodiment, in the establishment of one communication between the reader node 200 and the follower node 300, the final cross section of the log in which a plurality of logs are totaled is obtained from the reader node 200 to the follower node. It can be transmitted to 300. Therefore, it is possible to improve the throughput in the synchronous processing between the nodes in the distributed ledger network.

<Second Embodiment>
The distributed ledger system 10A according to the second embodiment of the present invention will be described with reference to FIGS. 11 to 16. In the following description, among the configurations of the distributed ledger system 10A, the configuration having the same characteristics as the distributed ledger system 10 according to the first embodiment includes the alphabet "A" after the same reference numerals as those of the distributed ledger system 10. , And a detailed explanation may be omitted. When the distributed ledger system 10A according to the second embodiment is described with reference to the drawings and the like of the first embodiment, the alphabet "A" is added to the reference numerals shown in FIGS. 1 to 10. explain. In the following description of the distributed ledger system 10A, the differences from the distributed ledger system 10 will be mainly described.

[2-1. System overview]
Since the outline of the distributed ledger system 10A according to the second embodiment is almost the same as that of the distributed ledger system 10 according to the first embodiment, the description thereof will be omitted. In the distributed ledger system 10A, transactions transmitted from the client process 410A to the reader node 200A are collectively transmitted in block units, a plurality of transactions are aligned by exclusive control, and the final cross section of the log is data-synchronized. It differs from the distributed ledger system 10 according to the first embodiment in that it is transmitted from the leader node 200A to the follower node 300A by an algorithm.

Explaining with reference to FIG. 3, in the distributed ledger system 10A, the client process 410A does not send a transaction to the reader node 200A for each transaction request from the user terminal, but makes a plurality of transaction requests from the user terminal. After accumulating a plurality of corresponding transactions, the plurality of transactions are collectively transmitted to the reader node 200A in one communication. A plurality of transactions collectively transmitted to the reader node 200A are handled in block units.

Transactions are grouped by client process 410A. That is, the client process 411A-1 collectively transmits, for example, transactions TX1 to TX149 to the reader node 200A in one communication. Similarly, the client process 411A-2 transmits, for example, transactions TX150 to TX500, and the client process 412A-1 transmits, for example, transactions TX501 to TX1000 together in one communication to the reader node 200A. In addition, logs 1 to 1000 generated based on transactions TX1 to TX1000 are also generated in block units. That is, each of log 1 to log 149, log 150 to log 500, and log 501 to log 1000 is generated in block units.

Boundaries are defined between different blocks. Specifically, the transactions TX1 to TX149 are given a block identifier indicating that each transaction belongs to, for example, the first block. Similarly, the transactions TX150 to TX500 are given a block identifier indicating that each transaction belongs to the second block. Similarly, transactions TX501 to TX1000 are given a block identifier indicating that each transaction belongs to the third block. These block identifiers are assigned by the reader node 200A. However, the block identifier may be assigned by the client process 410A. In addition to attaching a block identifier to a transaction as described above, a table for managing each transaction TX and the block to which each transaction TX belongs may be provided.

[2-2. Function of reader node 200A]
The function of the reader node 200A of the distributed ledger system 10A according to the present embodiment will be described with reference to FIG. FIG. 11 is a block diagram showing a functional configuration of a reader node used in the distributed ledger system according to the embodiment of the present invention. Each functional unit of the reader node 200A shown in FIG. 11 is similar to each functional unit of the reader node 200 of FIG. 4, but the configurations of the alignment processing unit 230A and the distributed processing unit 250A are the alignment processing unit 230 and the alignment processing unit 230 of FIG. It is different from the distributed processing unit 250. Further, the function of the TX receiving unit 220A is different from the function of the TX receiving unit 220 of FIG.

First, the TX receiving unit 220A receives a plurality of transactions from the client terminal 400A during one communication established by the CM communication unit 210A. For example, TCP can be used as a protocol for establishing and terminating the communication. In the data part of TCP, the block identifier, the number of transactions associated with the block identifier (the number of transactions included in the block), and the transaction contents (including the key to be updated and the value of data update) are included. included. The TX receiving unit 220A receives a plurality of transactions in block units as described above. The TX receiving unit 220A receives the information defining the block together with the transaction. That is, the TX receiving unit 220A receives information defining boundaries between different blocks.

Further, as shown in FIG. 11, the alignment processing unit 230A has an exclusive control function 231A. The exclusive control function 231A has a function of adding a control (exclusive control) for sequentially updating data to each transaction arranged in series in order to prevent a collision of data updates. As the exclusive control function 231A, for example, a strict two-phase locking (S2PL) protocol can be adopted. The final cross-section calculation unit 245A calculates the final cross-section of the log using the log to which the exclusive control function is added in this way.

The distributed processing unit 250A has a data synchronization algorithm function 251A. The data synchronization algorithm function 251A is an algorithm for sending the final cross section of the log from the reader node 200A to the plurality of follower nodes 300A, and is used between the plurality of follower nodes 300A so as not to cause inconsistency among the plurality of follower nodes 300A later. It is an algorithm that synchronizes with. The data synchronization algorithm function 251A may be a distributed consensus algorithm (Raft) or a partial function thereof.

When the log is generated in block units, the alignment processing unit 230A performs transaction alignment processing only in each block, and does not switch transactions between different blocks. On the other hand, when the log is not generated in block units (that is, the boundaries of blocks are released), the alignment processing unit 230A performs alignment processing of transactions straddling between blocks. That is, in this case, the alignment processing unit 230A can replace the transactions of different blocks. When the log is generated in block units, the information that defines the block boundaries is also inherited in the log. On the other hand, if the log is not generated in block units, the information that defines the block boundaries is deleted or invalidated.

When the distributed processing unit 250A confirms that the duplication of the final cross section of the log is normally performed in the majority of the follower nodes 300A, it is considered that the duplication of the final cross section of the log is completed. On the other hand, if the number of follower nodes 300A indicating that the final cross section of the log has been duplicated normally is less than half, the distributed processing is retried or waits until the number reaches the majority.

[2-3. Functions of client terminal 400A]
A function of the client terminal 400A of the distributed ledger system 10A according to the present embodiment will be described with reference to FIG. FIG. 12 is a block diagram showing a functional configuration of a client terminal used in the distributed ledger system according to the embodiment of the present invention. Each functional unit of the client terminal 400A shown in FIG. 12 is similar to each functional unit of the client terminal 400 of FIG. 7, but each functional unit of the client terminal 400 is provided with a TX buffering unit 440A. Is different.

The TX buffering unit 440A buffers the transaction TX generated by the TX generation unit 430A. That is, the TX buffering unit 440A has a temporary storage device, and the transaction TX is temporarily stored in the storage device. The TX buffering unit 440A is set with a threshold value for the number of transaction TX to be buffered. The TX buffering unit 440A generates a trigger signal when the number of transaction TX to be buffered reaches the threshold value. For example, the TX buffering unit 440A generates a trigger signal when the number of transaction TX to be buffered reaches 100. Alternatively, the TX buffering unit 440A may be provided with a function of measuring a predetermined period instead of setting the threshold value. In this case, the TX buffering unit 440A generates a trigger signal every time a predetermined period elapses. For example, the TX buffering unit 440A generates a trigger signal every 0.1 seconds. However, the above values are merely examples and are not limited to the above values.

The LN communication unit 450A transmits a communication establishment request to the CM communication unit 210A based on the trigger signal generated by the TX buffering unit 440A.

The TX transmitter 460A transmits a transaction to the reader node 200A in the previous cycle to the TX receiver 220A of the reader node 200A during one communication established by the LN communication unit 450A, and then the current one. A plurality of transactions generated before the trigger signal is generated in the cycle are collectively transmitted in one block. When the TX transmission unit 460A transmits a plurality of transactions in response to the trigger signal, the transaction TX temporarily stored in the TX buffering unit 440A is deleted, and the buffering of the transaction TX in the next cycle is started.

[2-4. Exclusive control function]
A specific sequence of exclusive control is shown in FIG. FIG. 13 is a diagram showing a sequence showing the operation of exclusive control in the distributed ledger system according to the embodiment of the present invention. As shown in FIG. 13, when the reader node 200A receives a block containing a plurality of transactions (step S810A), the alignment processing unit 230A arranges the transactions TX1 and TX2 in this order. The exclusive control function 231A adds a process of locking the data update of each node before the process of transaction TX1 (step S812A) is performed (step S811A). After S811A and S812A, the updated data is persisted in each node (step S813A). Specifically, in S813A, data update (rewriting of the database) of each node is performed with the contents specified by S812A. The lock applied by S811A after S813A is released (step S814A). After the lock is released, processing for transaction TX2 (steps S815A to S818A) is performed. Since the processing content of transaction TX2 is the same as the processing content of transaction TX1, detailed description thereof will be omitted. In this case, the order of transactions TX1 and TX2 may be reversed.

In other words, the above exclusive control locks the update processing for each node (ledger) for one target transaction (for example, TX1) among a plurality of transactions before the processing of the target transaction. Then, each node (ledger) is subjected to update processing according to the target transaction, and the lock is released after the update processing.

FIG. 14 is a diagram showing a sequence showing the operation of exclusive control in the distributed ledger system according to the modified example of the embodiment of the present invention. The example shown in FIG. 14 is an example in which exclusive control is performed in block units when a plurality of blocks are received. In FIG. 14, the case where two blocks are received is illustrated, but the number of blocks to be received may be three or more. In FIG. 14, block BL1 includes transactions TX1 to TX149, and block BL2 contains transactions TX150 to TX500. In FIG. 14, the block BL1 is arranged by the alignment processing unit 230A in the order of transactions TX1 to TX149. Similarly, the blocks BL2 are arranged in the order of transactions TX150 to TX500. Although not shown, of course, transactions TX501 to 1000 may be arranged in order after these processes.

When the exclusive control function 231A receives the blocks BL1 and BL2 (steps S820A-1 to S820A-2), the exclusive control function 231A for the data update of each node before the processing of the transactions TX1 to TX149 (steps S822A to S823A) is performed. A process for locking is added (step S821A). After S822A to S823A, the updated data is persisted in each node (step S824A). Specifically, in S824A, the data of each node is updated with the contents specified by S822A to S823A. The lock applied by S821A after S822A to S823A is released (step S825A). After the lock is released, processing (steps S826A to S830A) for transactions TX150 to TX500 of the block BL2 is performed. Since the processing contents of the transactions TX150 to TX500 are the same as the processing contents of the transactions TX1 to TX149, detailed description thereof will be omitted. In this case, the processing order of the transactions TX1 to TX149 in the block BL1 and the processing order of the transactions TX150 to TX500 in the block BL2 cannot be exchanged, but the order of the blocks BL1 and BL2 may be reversed.

FIG. 15 is a diagram showing a sequence showing the operation of exclusive control in the distributed ledger system according to the modified example of the embodiment of the present invention. The example shown in FIG. 15 is an example in which when a plurality of blocks are received, exclusive control is performed for a plurality of transactions included in each block after eliminating the boundaries between the blocks. In FIG. 15, the case where two blocks (BL1 and BL2) are received is illustrated, but the number of blocks to be received may be three or more. In FIG. 15, block BL1 includes transactions TX1 to TX149, and block BL2 contains transactions TX150 to TX500. In the example of FIG. 15, when the TX receiving unit 220A receives the blocks BL1 and BL2, the boundaries of the respective blocks are eliminated, and each transaction included in these blocks is treated independently. Then, as shown in FIG. 15, the TX1, TX500, TX149, and TX150 are arranged in this order by the alignment processing unit 230A so as to straddle between the blocks.

Specifically, as shown in FIG. 15, when the exclusive control function 231A receives the blocks BL1 and BL2 (steps S840A-1 to S840A-2), the transaction TX1 (steps S840A-1 to S840A-2) straddles the blocks. The same processing as in FIG. 13 is performed in the order of steps S841A to S844A), TX500 (steps S845A to S848A), TX149 (steps S849A to S852A), and TX150 (steps S853A to S856A).

In the case of FIGS. 14 and 15, the reader node 200A generates a plurality of logs 1 to 500 based on the transactions TX1 to TX500 included in the block BL1 and the block BL2, and is generated for the follower node 300A. The result (final cross section) of summing up a plurality of logs 1 to 500 is transmitted.

[2-5. Data synchronization algorithm function]
A specific sequence of data synchronization algorithms is shown in FIG. FIG. 16 is a diagram showing a flowchart showing the operation of the data synchronization algorithm in the distributed ledger system according to the embodiment of the present invention. The flowchart of FIG. 16 is similar to the flowchart of FIG. 10, but the flowchart of FIG. 16 consensus-builds the follower node 300A in that communication is established when the number of transaction TX reaches the threshold value. At the time of confirmation, when the agreement of the majority of all the follower nodes 300A is confirmed, it is considered that the duplication of the final cross section of the log is completed, and the consistency of the data of the follower node 300A is confirmed. It is different from the flowchart of. In the following description, the description of the same configuration as that of FIG. 10 will be omitted, and the points different from the configuration of FIG. 10 will be mainly described.

First, when a transaction TX occurs in the client terminal 400A (S701A), it is confirmed whether or not the condition for transmitting the transaction TX is satisfied each time the transaction TX occurs (step S805A). When it is determined in S701A that the condition for transmitting the transaction TX is satisfied (“Yes” in S701A), a communication establishment request is transmitted from the client terminal 400A to the reader node 200A (step S801A). On the other hand, if it is determined in S701A that the condition for transmitting the transaction TX is not satisfied (“No” in S701A), the process returns to S701A and waits for the occurrence of the next transaction TX.

Further, in S803A, if consensus building cannot be confirmed from a majority (for example, 2/3 or more) of all follower nodes 300A (“No” in step S803A), the steps S716A → S803A are repeated. On the other hand, when consensus building is confirmed from a majority (for example, 2/3 or more) of all follower nodes 300A (“Yes” in step S803A), data update (step S717A) and completion notification (step S718A) in the leader node 200A. Is done.

Further, after updating the data of S804A, the consistency of the data between the follower nodes 300A is confirmed (step S806A). In S806A, when data inconsistency is confirmed in a part of the follower node 300A (“No” in step S806A), the follower node 300A data is corrected (step S807A).

Here, since the consensus building of the majority is confirmed in S803A, in S807A, the majority of the follower nodes 300A have the same data. That is, since it is highly probable that the data of the majority of the follower nodes 300A having the same data is the correct data, the data of the other follower nodes 300A are corrected. Specifically, the final cross section of the log stored in the reader node 200A is retransmitted to another follower node 300A, and the follower node 300A updates the data based on the final cross section of the log. After the data of S807A is corrected, the consistency of S806A is confirmed again.

According to the distributed ledger system 10A according to the present embodiment, a log for exclusive control is formed for a plurality of transactions received by the reader node 200A, and the final cross section of the log generated using the log is data-synchronized. By transmitting to a plurality of follower nodes 300A using an algorithm, synchronization between each node can be achieved while ensuring consistency in each node. In particular, when a plurality of transactions are transmitted from the client terminal 400A to the reader node 200A in block units, it is assumed that the plurality of transactions include a request for update processing for the same update target. Even if there is, inconsistency between a plurality of nodes can be suppressed without causing a data update collision.

Although one embodiment of the present invention has been described above with reference to the drawings, the present invention is not limited to the above-described embodiment and can be appropriately modified without departing from the spirit of the present invention. For example, a system in which a person skilled in the art appropriately adds, deletes, or changes the design based on the distributed ledger system of the present embodiment is also included in the scope of the present invention as long as the gist of the present invention is provided. Will be. Further, each of the above-described embodiments can be appropriately combined as long as there is no contradiction with each other, and technical matters common to each embodiment are included in each embodiment even if there is no explicit description.

Of course, other effects different from the effects brought about by the embodiments described above, which are obvious from the description of the present specification or which can be easily predicted by those skilled in the art, will naturally occur. It is understood that it is brought about by the present invention.

10: Distributed ledger system, 31-38: Ledger, 41-47: Client terminal, 100-103: Node, 110-113: Server, 120-123: Database, 200: Reader node, 220: Receiver, 230: Alignment processing unit, 231A: Exclusive control function, 240: Log generation unit, 250: Distributed processing unit, 251A: Data synchronization algorithm function, 260: Data update unit, 290: Communication bus, 300-304: Follower node, 310: Cross section Receiver, 320: Section storage, 330: Consensus formation, 340: Data update, 390: Communication bus, 400-404: Client terminal, 410-414: Client process, 420: Transaction request receiver, 430: Generation Unit, 440: Buffering unit, 450: Communication unit, 460: Transmitter unit, 490: Communication bus, 500: Network, 600: Dedicated network

Claims (8)

A first node is selected from a plurality of nodes for distributing and recording a ledger, and from the first node to a plurality of second nodes different from the first node among the plurality of nodes, from a client terminal. A system that sends the sum of multiple logs generated at a given threshold based on multiple received transactions. The first node of one of the plurality of nodes for distributing and recording the ledger is based on a plurality of transactions received from the client terminal for the plurality of second nodes different from the first node of the plurality of nodes. A system that transmits the total of the plurality of logs without transmitting the plurality of logs generated at a predetermined threshold . The first node is
The plurality of transactions are received from the client terminal in block units including the plurality of transactions.
Generate the plurality of logs based on the plurality of transactions contained in the block, and generate the plurality of logs.
The result of summing up the plurality of logs contained in the plurality of blocks is transmitted to the plurality of second nodes.
The system according to claim 1 or 2. The system according to any one of claims 1 to 3, wherein the first node stores the plurality of logs. For one first node selected from a plurality of nodes that distribute and record the ledger, a plurality of the plurality of nodes received from the client terminal to the plurality of second nodes different from the first node among the plurality of nodes. A program for executing the transmission of the sum of multiple logs generated with a predetermined threshold based on a transaction. Based on a plurality of transactions received from a client terminal to a plurality of second nodes different from the first node among the plurality of nodes for the first node of one of the plurality of nodes for recording the ledger in a distributed manner. A program for executing the transmission of the total of the plurality of logs without transmitting the plurality of logs generated at a predetermined threshold . To the first node
The plurality of transactions are received from the client terminal in block units including the plurality of transactions.
Generate the plurality of logs based on the plurality of transactions included in the block, and generate the plurality of logs.
The result of summing up the plurality of logs included in the plurality of blocks is transmitted to the plurality of second nodes.
The program according to claim 5 or 6. The program according to any one of claims 5 to 7, wherein the first node stores the plurality of logs.

Images