Distributed ledger system and control method for distributed ledger system

Abstract

To monitor the overall soundness of a distributed ledger system based on objective information.SOLUTION: A distributed ledger system is configured by communicably connecting distributed ledger nodes that each of a plurality of organizations has, and is capable of executing a smart contract. The smart contract manages information in a distributed ledger while building consensus among the distributed ledger nodes of the plurality of organizations. The distributed ledger node executes the smart contract according to a transaction received from another device, such as a client node of an organization. The smart contract receives a soundness monitoring result that is information acquired by a first organization monitoring soundness of the distributed ledger node of a second organization, verifies the soundness of the distributed ledger node of the second organization by verifying the received soundness monitoring result, and records a soundness verification result that is a result of verifying the soundness, in the distributed ledger.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] The present invention relates to a distributed ledger system and a method for controlling a distributed ledger system. [Background technology]

[0002] In recent years, a technology (hereinafter referred to as "distributed ledger technology") has emerged that enables transactions that were previously conducted via centralized institutions such as financial institutions and governments to be conducted directly between users by recording them in a distributed ledger (hereinafter referred to as "blockchain") managed in a P2P (Peer to Peer) network (hereinafter referred to as "distributed ledger network") made up of information processing devices of individual users, and this technology is being applied to a variety of fields.

[0003] Regarding distributed ledger technology, for example, Patent Document 1 describes a system configured for the purpose of enabling the endorsement of transactions in a blockchain to be performed in an optimized state. The above system identifies one or more endorsement requests for executing the endorsement, transmits the endorsement requests to an ordering node, monitors the performance indicators of peers, and assigns one or more endorsement requests to peers based on the performance indicators.

[0004] Furthermore, for example, Non-Patent Document 1 describes a technology that uses a distributed ledger to enable transactions that have previously been conducted via trusted centralized institutions such as financial institutions and governments to be conducted directly between users using virtual currencies.

[0005] Furthermore, for example, Non-Patent Documents 2 and 3 describe a smart contract (also called "Chaincode"), which is a technology that updates a distributed ledger by executing predefined processes triggered by events such as transactions. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Patent Application No. 2020-562204 [Non-patent literature]

[0007] [Non-Patent Document 1] “A Peer-to-Peer Electronic Cash System”, [online], [Retrieved May 26, 2023], Internet<URL:https: / / bitcoin.org / bitcoin.pdf> [Non-Patent Document 2] “Ethereum White Paper”, [online], [Retrieved May 26, 2023], Internet<URL:https: / / ethereum.org / ja / whitepaper / > [Non-Patent Document 3] “Hyperledger Fabric”, [online], [Retrieved May 26, 2023], Internet<URL:http: / / hyperledger-fabric.readthedocs.io / en / release-2.5 / > Summary of the Invention [Problem to be solved by the invention]

[0008] The above-mentioned distributed ledger technology has the following features: (1) Transactions between participants in a distributed ledger network are finalized through consensus or approval by voluntary or specific participants, rather than by a centralized authority. (2) By managing multiple transactions as blocks, linking the blocks together and recording them in a distributed ledger, and recording hash values ​​in successive blocks, it is virtually impossible to tamper with the contents of the records. (3) Since all participants share the same ledger data, all participants can verify the contents of transactions.

[0009] In this way, distributed ledger technology eliminates the need for management by a central authority and makes it possible for multiple entities to share and trade information.

[0010] There are three types of usage for distributed ledger technology: a public type that does not assume the existence of a specific administrator as described in Non-Patent Document 1, a private type that assumes the existence of a single administrator, and a consortium type that assumes the existence of multiple administrators as described in Non-Patent Document 3. Of these, the private and consortium types are also called permission types because the permission of an administrator is required to agree on operations in the distributed ledger network.

[0011] Of the above usage patterns, the consortium type is suitable for cases where multiple organizations (e.g., a consortium in a specific industry or multiple companies related to a supply chain) cooperate to operate, and is particularly promising for use in the enterprise field (finance, industry, distribution, public, IT infrastructure, social infrastructure, etc.). In the consortium type, for example, each node (hereinafter referred to as "distributed ledger node") of multiple organizations participating in the distributed ledger network (consortium) synchronizes and links based on a consensus protocol, and executes transactions according to a pre-agreed contract (smart contract).

[0012] However, if a discrepancy occurs between the actual operational state (system configuration, etc.) of an information processing system (hereinafter referred to as the "distributed ledger system") that is configured using a distributed ledger network and the operational state planned (designed) for the participating organizations as a whole, the soundness, performance, and availability of the distributed ledger system may be compromised. In addition, in a consortium type, since each participating organization prepares its own node, it is not necessarily easy to know whether the planned operational state is being maintained for the participating organizations as a whole.

[0013] In the above-mentioned Patent Document 1, an ordering service monitors the performance indicators of peers and assigns endorsement requests to peers based on the performance indicators. However, the document does not describe a mechanism for solving the above-mentioned problems that arise in the operation of a consortium-type distributed ledger system. In addition, since the performance indicators are monitored by a single organization, the monitoring results cannot be used as reliable evidence.

[0014] Non-Patent Document 3 also describes, as an Operations Service, monitoring the status of each node by acquiring health checks and metrics for each node. The same document also describes a mechanism (Service Discovery) in which a gateway discovers available nodes. However, the mechanism described in the document assumes that each organization will monitor the nodes it owns or can use, and does not monitor all of the participating organizations. In addition, since the mechanism is monitored by a single organization (single point of trust), the results of the monitoring cannot be used as reliable evidence.

[0015] The present invention has been made in consideration of the above background, and aims to provide a distributed ledger system and a method for controlling a distributed ledger system that are capable of monitoring the soundness of the distributed ledger system as a whole based on objective information. [Means for solving the problem]

[0016] One of the present inventions for solving the above problems is a distributed ledger system that includes distributed ledger nodes provided by each of a plurality of organizations and provides a distributed ledger network composed of the plurality of distributed ledger nodes, and executes a smart contract in response to a transaction received from an outside source, and the smart contract manages information in the distributed ledger while reaching a consensus among the distributed ledger nodes of the plurality of organizations, receives a health monitoring result, which is information obtained by a first organization by monitoring the health of the distributed ledger node of a second organization, verifies the health of the distributed ledger node of the second organization by verifying the received health monitoring result, and records a health verification result, which is a result of verifying the health, in the distributed ledger.

[0017] Other problems and solutions disclosed in the present application will be made clear in the detailed description and drawings. Effect of the Invention

[0018] According to the present invention, it is possible to monitor the soundness of the entire distributed ledger system based on objective information. [Brief description of the drawings]

[0019] [Figure 1] FIG. 1 is a diagram illustrating a schematic configuration of a distributed ledger system. [Figure 2A] This is an example of blockchain (BC). [Figure 2B] This is an example of a blockchain (BC) (continuation of Figure 2A). [Figure 2C] This is an example of a blockchain (BC) (continuation of Figure 2B). [Figure 2D] This is an example of a blockchain (BC) (continuation of Figure 2C). [Figure 2E] This is an example of a blockchain (BC) (continuation of Figure 2D). [Figure 2F] This is an example of a blockchain (BC) (continuation of Figure 2E). [Figure 2G]This is an example of a blockchain (BC) (continued from Figure 2F). [Diagram 3] 11 is an example of state information. [Figure 4A] 1 is an example of configuration information (organization information). [Figure 4B] This is an example of configuration information (SC agreement condition information). [Diagram 5] FIG. 2 is a block diagram illustrating health management SC, state information, and SC events. [Figure 6A] 13 is an example of state information (health monitoring method definition). [Figure 6B] 13 is an example of state information (health monitoring result). [Figure 6C] 13 is an example of state information (soundness verification result). [Figure 6D] 1 is an example of state information (configuration design information). [Figure 6E] 13 is an example of state information (configuration compliance status). [Figure 6F] 13 is an example of state information (capacity information). [Figure 6G] 13 is an example of state information (organization reliability). [Figure 6H] This is an example of state information (organization responsible for monitoring). [Figure 7] 13 is a flowchart illustrating a member registration process. [Figure 8] 13 is a flowchart illustrating an SC deploy / execute process. [Figure 9] 13 is a flowchart illustrating a health report process. [Figure 10] 13 is a flowchart illustrating a soundness cross-verification process. [Figure 11] 13 is a flowchart illustrating a configuration compliance status verification process. [Figure 12] 11 is a flowchart illustrating a reliability calculation process. [Figure 13] 13 is a flowchart illustrating a monitoring organization selection process. [Figure 14]13 is an example of a monitoring result display user interface. [Figure 15] 1 is an example of an information processing device used to realize a distributed ledger system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0020] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Note that the following embodiment is merely an example for explaining the present invention, and appropriate omissions and simplifications are made for clarity of explanation. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural.

[0021] In the following, various types of information may be described using expressions such as "information" and "data" as examples, but the various types of information may also be expressed using other data structures (such as a "table" or "list"). In the following description, when describing identification information, expressions such as "identifier," "ID," and "identification information" may be used, but these are interchangeable. In the following description, the letter "S" before a symbol indicates a processing step.

[0022] In the following description, the distributed ledger is also referred to as "blockchain" or "BC." The technology that enables direct transactions between users using the distributed ledger is hereinafter referred to as "distributed ledger technology." The P2P (Peer to Peer) network that is configured using multiple information processing devices (hereinafter referred to as "distributed ledger nodes" or "consortiums") that are communicatively connected via a communication network, which is the basis for using the distributed ledger technology, is hereinafter referred to as the "distributed ledger network." The smart contract provided by the distributed ledger technology is hereinafter referred to as "SC." The transaction issued to the smart contract (SC) is hereinafter referred to as "TX."

[0023] In this embodiment, the "soundness" is determined, for example, by the following indexes. (1) The status of each node (availability of the node from each organization, network reachability, whether the node is ready to provide services, etc.) (2) Deviation from the designed configuration (number of nodes, specifications, etc.) (3) The status of fulfillment of required performance and availability (e.g., whether the performance value of synthetic monitoring meets a certain level) (4) Correctness of settings (e.g., setting of enable / disable flag of provided functions, software version, etc.)

[0024] [First embodiment] 1 shows a schematic configuration of a distributed ledger system 1, which is an information processing system shown as a first embodiment. The distributed ledger system 1 includes one or more distributed ledger nodes 3 and one or more client nodes 4. The distributed ledger nodes 3 and the client nodes 4 are both configured using information processing devices (computers). These are connected to each other via a communication network 5 in a state where they can communicate with each other bidirectionally. The communication network 5 is a wireless or wired communication infrastructure configured using network devices, such as the Internet, a LAN (Local Area Network), a WAN (Wide Area Network), various public communication networks, and dedicated lines.

[0025] The distributed ledger system 1 includes a consortium-type distributed ledger network composed of multiple distributed ledger nodes 3. Each of the organizations (hereinafter referred to as "participating organizations") that use the distributed ledger network has one or more distributed ledger nodes 3 and one or more client nodes 4. As this is a consortium-type distributed ledger network (consortium), in principle each organization operates its own distributed ledger node 3. Note that the distributed ledger nodes 3 and client nodes 4 owned by participating organizations only need to be in a state where they can be directly used by the participating organizations (a state where they can be operated and managed), and they do not necessarily need to be owned by the participating organizations.

[0026] As shown in the figure, the distributed ledger node 3 has the functions of a memory unit 300, a transaction management unit (hereinafter referred to as the "TX management unit 320"), a consensus management unit 325, a smart contract execution management unit (hereinafter referred to as the "SC execution management unit 330"), an approved TX distribution unit 335, a transaction issuing unit (hereinafter referred to as the "TX issuing unit 340"), a node search unit 345, a member management unit 350, and a communication unit 355.

[0027] Of the above functions, the memory unit 300 stores (stores) each piece of information (data) of the distributed ledger 310, the consortium information 302, and the participating member management information 303.

[0028] The distributed ledger 310 includes a blockchain (BC) (hereinafter referred to as "BC311"), state information 312, a business SC313 which is a smart contract (SC) that realizes processing related to the organization's business, and a soundness management SC314 which is a smart contract (SC) that performs processing related to managing the soundness of the distributed ledger system 1.

[0029] The BC 311 manages, for example, transaction (TX) history (reception history, execution history). The state information 312 manages, for example, information based on the transaction (TX) history and information required for the execution of a smart contract (SC) (hereinafter referred to as "state information"). The state information 312 is managed, for example, in a database table managed by a DBMS (Data Base Management System) such as NOSQL. The state information 312 includes, for example, information based on the execution result of the transaction (TX) managed in a key-value format.

[0030] The consortium information 302 includes information on the organizations that make up the distributed ledger network, and information on various agreement conditions (conditions for determining whether a transaction (TX) can be accepted (SC agreement conditions described below) and the like) agreed upon between the organizations (between the distributed ledger nodes 3). The SC agreement conditions are also recorded as the blockchain (BC) (BC311) of the distributed ledger 310. The consortium information 302 is shared between the distributed ledger nodes 3 of each organization.

[0031] Participating member management information 303 includes information (identification information, authentication information, various attribute information, etc.) about members of participating organizations (including nodes, administrators, users, etc.).

[0032] The TX management unit 320 receives transactions (TX) sent from client nodes 4 or other distributed ledger nodes 3. The TX management unit 320 also performs processes related to acquiring transaction (TX) history (reception history, execution history) and execution results, and presenting the transaction (TX) execution results (presentation via a user interface, etc.). When the TX management unit 320 receives a transaction (TX), it works in cooperation with the member management unit 350 to perform processes related to authenticating the issuer of the transaction (TX) (client node, member, etc.).

[0033] The consensus management unit 325 performs processing related to forming an agreement with other distributed ledger nodes 3 on whether or not to accept a transaction (TX) received from a client node 4 or a distributed ledger node 3. When an agreement is reached, the consensus management unit 325 cooperates with the SC execution management unit 330 to perform operations such as deploying a smart contract (SC), executing the deployed smart contract (SC), and recording the history and execution results of the transaction (TX) in the distributed ledger 310.

[0034] The SC execution management unit 330 performs processes related to the deployment of a smart contract (SC) and the execution of a deployed smart contract (SC) when an agreement is reached with other distributed ledger nodes 3. Note that the consensus formation and execution of the smart contract (SC) do not necessarily need to be performed by all distributed ledger nodes 3 constituting the distributed ledger network, and the consensus formation and execution of the smart contract (SC) may be performed among some of the distributed ledger nodes 3, and the results may be distributed to other distributed ledger nodes 3 via the communication network 5 in cooperation with the approved TX distribution unit 335 (the arrangement in this case depends on the consensus formation algorithm).

[0035] The approved TX distribution unit 335 distributes the results of the above-mentioned consensus formation and execution of the smart contract (SC) (such as the history and execution results of the transaction (TX)) via the communication network 5 to distributed ledger nodes 3 that are not participating in the above-mentioned consensus formation or execution of the smart contract (SC).

[0036] The TX issuing unit 340 issues a transaction (TX) to the distributed ledger node 3 (including itself). In this manner, in this embodiment, not only the client node 4 but also the distributed ledger node 3 can issue a transaction (TX) to the distributed ledger node 3.

[0037] The node search unit 345 searches the communication network 5 in response to a request sent from another information processing device such as the client node 4, and searches for a distributed ledger node 3 currently available in the distributed ledger system 1 based on the state of each distributed ledger node 3 constituting the distributed ledger system 1 and the participation status of each distributed ledger node 3 in the distributed ledger network. The above search is performed, for example, by a mechanism of service discovery (such as the gateway function in Non-Patent Document 3). Based on the search result, the node search unit 345 selects a distributed ledger node 3 to send a transaction (TX) and a distributed ledger node 3 to be used for consensus building.

[0038] The member management unit 350 performs processes related to the registration of organizations and members participating in the distributed ledger network. The member management unit 350 also performs authentication processes for participating organizations and members. For example, the member management unit 350 authenticates participating organizations and members using a pair of a private key and a public key (hereinafter referred to as a "key pair") in a public key cryptography system, signs transactions (TX), and controls the execution authority of smart contracts (SC). Information on participating organizations and members is managed in participating member management information 303.

[0039] The communication unit 355 performs processing related to communication with the client node 4 and other distributed ledger nodes 3 via the communication network 5. For example, the communication unit 355 performs communication related to consensus formation among other distributed ledger nodes 3, distribution of approved transactions (TX) to other distributed ledger nodes 3, etc.

[0040] As shown in the figure, the client node 4 has the functions of a storage unit 400, a TX issuing unit 420, a node searching unit 425, a business application 430, and a monitoring agent 435.

[0041] The storage unit 400 stores node search information 401. The node search information 401 includes information indicating distributed ledger nodes 3 currently available in the distributed ledger system 1, which have been searched for by the node search unit 425.

[0042] The TX issuing unit 420 transmits (issues) the transaction (TX) to the distributed ledger node 3. The TX issuing unit 420 generates the above transaction in response to, for example, an operational input from a member of the organization, and transmits it to the distributed ledger node 3. The transaction (TX) is accompanied by information (identification information, authentication information, etc.) about the issuer of the transaction (TX) (organization, member, client node 4).

[0043] The node search unit 425, like the node search unit 345 of the distributed ledger node 3, searches the communication network 5 and searches for currently available distributed ledger nodes 3 in the distributed ledger system 1 based on the state of each distributed ledger node 3 and the participation status of each distributed ledger node 3 in the distributed ledger network. Furthermore, based on the search results, the node search unit 425 selects the distributed ledger node 3 to which a transaction (TX) will be sent and the distributed ledger node 3 to be used for consensus building.

[0044] The business application 430 is a function realized by application software (programs and data) that executes or supports the business performed by the organization. For example, when providing a function related to the business, the business application 430 cooperates with the TX issuing unit 420 to send (issue) a transaction (TX) related to the business SC313 to the distributed ledger node 3.

[0045] The monitoring agent 435 performs processing related to monitoring the health of the distributed ledger node 3 of other organizations. The monitoring agent 435 monitors the health of the distributed ledger node 3 of other organizations according to a monitoring method (such as external monitoring or a monitoring method based on information acquired by the node search unit 345; content of the health monitoring method definition 551) described below stored in the state information 312 of the distributed ledger node 3. The monitoring agent 435 cooperates with the TX issuing unit 420 to generate a transaction (TX) for reporting (notifying) the information acquired by monitoring (information indicating the health of the distributed ledger node 3 of other organizations (hereinafter also referred to as "health monitoring result")) to the health management SC 314 of the distributed ledger node 3, and transmits (issues) the generated transaction (TX) to the distributed ledger node 3.

[0046] 2A to 2F are examples of the data structure of each block of the block chain (BC) (BC311) of the distributed ledger 310 shown in FIG. 1. In distributed ledger technology, multiple transactions (TX) are managed as blocks, and the block chain (BC) (BC311) has a structure in which each block has a hash value of the previous block. With the above structure, if even one bit of the value of the previous block changes, the hash values ​​of all subsequent blocks change, making it difficult for malicious parties to tamper with the contents.

[0047] In this embodiment, a case where one transaction (TX) and one block correspond one-to-one is illustrated, but multiple transactions (TX) may correspond to one block. In this example, the smart contracts (TX) are linked as a single blockchain (BC), but other configurations are also possible as long as each participating organization can manage and refer to them. In this example, multiple smart contracts (TX) are defined individually, but they may be aggregated into a single smart contract (TX).

[0048] Each of the blocks 311a to 311f shown in FIGS. 2A to 2F includes the following information: TX information 21, a previous block hash value 23, and a state hash value 24 (a hash value generated from state information, which will be described later).

[0049] 2A includes information on a transaction (TX) (hereinafter, referred to as "deploy TX") for deploying a business SC 313. Note that the business SC 313 is, for example, a smart contract (SC) of a business related to a business contract in a commercial transaction (transaction of virtual currency between organizations such as companies).

[0050] As shown in the figure, the TX information 21 of block 311a includes the following items: timestamp 211, SC_ID 212, TX type 213, SC entity 214, SC input specification 215, SC meta definition 216, TX issuer 217, TX executor / approver 218, approved TX distributor 219, and RW set 220.

[0051] Among these, the timestamp 211 stores the date and time (timestamp) when the transaction (TX) is issued.

[0052] The SC_ID 212 stores an identifier of the smart contract (SC) (hereinafter referred to as "SC_ID").

[0053] The TX type 213 stores information (in this example, "deploy") indicating the type of the transaction (TX) ("deploy", "execute", "reference", etc.).

[0054] The SC entity 214 stores the entity of the smart contract (SC) (for example, executable binary data (execution code), etc.).

[0055] The SC input specification 215 stores information for users to understand the function names and their arguments included in the smart contract (SC). Note that the illustrated block 311a defines a business SC 313 that includes at least the following functions (hereinafter referred to as "SC functions"). Function name: transaction(), input arguments: sender customer ID, sender customer ID, remittance amount, return value: success or failure Function name: All transactions reference(), Input argument: Customer ID, Return value: List of all transactions for a specified customer

[0056] The SC meta definition 216 stores parameters determined according to input arguments specified when the smart contract (SC) is deployed. The above parameters are, for example, the conditions of agreement (e.g., "accept TX with the approval of more than half of the participating organizations") when the smart contract (SC) (the relevant business SC) is executed, and various other definition information.

[0057] The TX issuer 217 stores information about the issuer of the transaction (TX) (for example, an identifier (hereinafter referred to as "member ID") of the issuer (client node 4, distributed ledger node 3, administrator, user, etc.), information about the electronic signature (information used to verify the issuer and whether data has been tampered with), etc. The above electronic signature is generated using the private key of each member issued by the member management unit 350, and is verified using the public key (certificate) of the above private key.

[0058] Like the TX issuer 217, the TX executor / approver 218 stores information about participants (hereinafter referred to as "TX executors / approvers") involved in the consensus formation and smart contract (SC) execution performed by the consensus management unit 325 and the SC execution management unit 330.

[0059] The approved TX distributor 219 stores information about participants (hereinafter referred to as “approved TX distributors”) involved in the distribution process by the approved TX distributor 335.

[0060] The RW set 220 stores information that is referenced or updated during processing of the transaction (TX) (hereinafter referred to as "RW set" (RW: Read-Write)). The RW set corresponds to state information, which will be described later. The RW set and state information will be described later.

[0061] A block 311e shown in FIG. 2E is a transaction (hereinafter, referred to as "execution TX") for functioning (calling) (executing) the business SC deployed by the deploy TX of the block 311a shown in FIG. 2A.

[0062] As shown in the figure, the TX information of the illustrated block 311e includes the items of a time stamp 211, an SC_ID 212, a TX type 213, a calling function / input argument 221, a TX issuer 217, a TX executor / approver 218, an approved TX distributor 219, a RW set 220, and an SC event 222. Among the above items, the time stamp 211, the SC_ID 212, the TX issuer 217, the TX executor / approver 218, and the approved TX distributor 219 are the same as those of the block 311a in FIG. 2A, and therefore the description thereof will be omitted.

[0063] In the TX type 213, “execution” is stored if the processing executed by the execution TX includes an update processing of the distributed ledger 310, and “reference” is stored if the processing executed by the execution TX is a reference processing that does not include an update processing of the distributed ledger 310. In this example, “execution” is stored in the TX type 213.

[0064] The SC function called by the smart contract (SC) and the input arguments given to the SC function are stored in the call function / input argument 221. In this example, the call function / input argument 221 stores "Transaction ()" as the SC function and "Customer a, Customer b, \1M" as input arguments.

[0065] As described above, the RW set 220 stores information (RW set, state information) that is referenced or updated during processing of the transaction (TX). In this example, the RW set 220 stores information that is referenced / updated during deployment or execution of the smart contract (SC).

[0066] In the illustrated block 311e, the RW set 220 stores a table having one or more records each having the items SC_ID 2201, RW category 2202, Key 2203, Value 2204, and Version 2205 as the RW set.

[0067] Among the above items, SC_ID 2201 stores the identifier (SC_ID) of the smart contract (SC).

[0068] The RW section 2202 stores the SC_ID and information indicating whether it is a reference (Read) or an update (Write) (hereinafter referred to as the "RW section").

[0069] Key 2203 and Value 2204 store information referenced or updated by the smart contract (SC) identified by the SC_ID.

[0070] Information indicating the version of the information corresponding to the pair of SC_ID and Key is stored in the version 2205. The version is incremented by 1, for example, every time the information is updated.

[0071] In the example shown in the figure, the smart contract (SC) SC function “Register (Customer a, Customer b, ¥10M)” is executed, and the key “Customer a” is referenced to obtain the Value “¥100M” with version number “4” (line 1), which is then updated with the Value “¥90M”, resulting in the version number being updated to “5”, which is managed as a RW set.

[0072] In this way, the execution result of the transaction (TX) is managed as a RW set (state information). Therefore, by referring to the RW set, the execution result of the transaction (TX) can be directly obtained without executing the smart contract (SC). Therefore, for example, the execution result of the transaction (TX) can be efficiently shared among multiple distributed ledger nodes 3, including a distributed ledger node 3 that does not execute the smart contract (SC).

[0073] The SC event 222 shown in the figure stores information about events (hereinafter referred to as "event information") generated by the distributed ledger node 3. The TX manager 320 of the distributed ledger node 3 generates event information when, for example, adding a transaction (TX) history to the BC 311 of the distributed ledger 310, and stores the generated event information in the SC event 222.

[0074] The client nodes 4 and the distributed ledger nodes 3 participating in the distributed ledger system 1 can refer to the event information stored in the SC event 222 of the BC 311 via the communication network 5 (i.e., event information can be shared between each distributed ledger node 3 and between each distributed ledger node 3 and each client node 4 via the SC event 222. In addition, the distributed ledger nodes 3 and client nodes 4 can execute various processes according to the event information.

[0075] The deploy TX block of the business SC313 (block 311a shown in FIG. 2A) and the execution TX block of the business SC313 (block 311e shown in FIG. 2E) have been described above, but the deploy TX block of the health management SC314 (block 311b shown in FIG. 2B) and the execution TX block of the health management SC314 (block 311f shown in FIG. 2F) also have the same configuration. In this way, the business SC313 and the health management SC314 have a common block, and the functions of the distributed ledger node 3 for processing both can be made common. For this reason, the mechanism of this embodiment can be efficiently realized.

[0076] FIG. 3 shows the data structure of the state information 312 of the distributed ledger 310 shown in FIG. 1. The mechanism of information management by the blockchain (BC) is inefficient because it is necessary to trace the blockchain (BC) in order to obtain the latest state of information managed in the blockchain (BC) (for example, the latest balance of virtual currency when virtual currency is managed in the blockchain (BC)). Therefore, in this embodiment, a mechanism (for example, the mechanism disclosed in Non-Patent Document 3) is adopted for managing the latest state of information managed in the blockchain (BC) as state information 312, which is obtained by reflecting all the contents of the RW set described above. In this embodiment, the SC execution management unit 330 acquires the entity of the smart contract (SC) using the SC_ID as a key and executes the smart contract (SC), and the state information 312 is managed for each smart contract (SC) (a data storage area is prepared).

[0077] As shown in the figure, the illustrated state information 312 includes one or more records having the following items: SC_ID 3121 , SC entity 3122 , and internal table 3123 .

[0078] The SC_ID of the smart contract (SC) is stored in SC_ID 3121.

[0079] The entity of the smart contract (SC) (for example, executable binary data (execution code)) is stored in the SC entity 3122. This allows the SC execution management unit 330 to obtain and execute the entity of the smart contract (SC) using the SC_ID as a key.

[0080] The internal table 3123 manages information used when executing a smart contract (SC), such as the execution result of the SC. The contents of the internal table 3123 are updated every time a transaction (TX) is executed. In this example, the internal table 3123 manages the latest value of the RW set stored in the RW set 220 shown in FIG. 2E or FIG. 2F.

[0081] In the example shown in the figure, information is stored in the internal table 3123 in a key-value format, but the value may be stored in the internal table 3123 in another format, such as JSON (JavaScript Object Notation) (both "Java" and "Javascript" are registered trademarks). This allows information to be stored in the internal table 3123 as a table of an arbitrary data schema, for example. Also, by devising a key design, multiple pieces of information with different schemas can be virtually managed in the internal table 3123.

[0082] Fig. 4A is an example (hereinafter referred to as "organization information 302a") of the consortium information 302 shown in Fig. 1. The organization information 302a includes information about participating organizations.

[0083] As shown in the figure, the illustrated organization information 302a is made up of a plurality of records having items such as a business ID 3021, an organization ID 3022, and a member ID 3023.

[0084] Of the above items, the business ID 3021 stores a business ID (such as "Business A", "Business B") that is an identifier for a business conducted using the distributed ledger network.

[0085] The organization ID 3022 stores an organization ID (eg, "organization 1," "organization 2," "organization 3," "organization 4") that is an identifier of a participating organization.

[0086] The member ID 3023 stores the member IDs of the members of the participating organizations (such as "distributed ledger node 11", "client node 11", "administrator 11", "user 11", etc.).

[0087] Fig. 4B is another example (hereinafter referred to as "SC agreement condition information 302b") of the consortium information 302 shown in Fig. 1. The SC agreement condition information 302b includes information on the conditions (hereinafter referred to as "SC agreement conditions") for an agreement to be reached on a smart contract (SC) (for accepting the execution result of the smart contract (SC)), which are set for each business (for each business ID).

[0088] As shown in the figure, the illustrated SC agreement condition information 302b is made up of one or more records having items such as a business ID 3025 and an SC agreement condition D 3026.

[0089] Of the above items, the business ID 3025 stores the business ID described above.

[0090] The SC agreement conditions set for the relevant business are stored in the SC agreement conditions D3026. The SC agreement conditions are determined based on the contents of the BC311 (the SC agreement conditions stored in the SC meta definition 216 in FIG. 2A).

[0091] In the example shown in the figure, the record with the task ID "Task A" indicates that the SC agreement condition for that task is set as "a majority vote of the participating organizations is required to reach a consensus (an agreement is established)."

[0092] Also, in the example in the same figure, the record with the task ID "Task B" indicates that the following SC agreement condition is set for that task: "If the number of distributed ledger nodes 3 experiencing failures is f, then in order to reach a consensus (to have an agreement), the agreement of 2f+1 or more participating organizations is required (for example, if f is 1, then the agreement of three or more organizations is required to have an agreement)."

[0093] FIG. 5 is a diagram illustrating the health management SC 314, the state information 312 defined and manipulated by the health management SC 314, and the SC events 222 shown in FIG.

[0094] As shown in the figure, the health management SC 314 includes SC functions (health report 511, health mutual verification 512, configuration compliance status verification 513, action instruction 514, organization reliability calculation 515, monitoring organization selection 516, and various data reference 517). When executed, the SC functions access (update or reference) the state information 312 and the SC event 222 of the BC 311 as appropriate.

[0095] 13, the illustrated state information 312 includes a health monitoring method definition 551, a health monitoring result 552, a health verification result 553, configuration design information 554, a configuration compliance status 555, capacity information 556, an organization reliability 557, and a monitoring organization 558. In addition, the illustrated SC event 222 includes an action event 581.

[0096] Of the state information 312, the health monitoring method definition 551 includes information (hereinafter referred to as the "health monitoring method") that specifies (defines) common monitoring methods and monitoring means that each organization should use when monitoring the health of other organizations' configurations (distributed ledger nodes 3, client nodes 4).

[0097] The health monitoring results 552 include information regarding the results of each organization's client node 4 monitoring the health of other organization's configurations (distributed ledger nodes 3, client nodes 4) (hereinafter referred to as "health monitoring results").

[0098] The soundness verification result 553 includes information indicating the result of judging the soundness (such as whether the distributed ledger node 3 is alive or dead) of each distributed ledger node 3 by verifying the soundness monitoring results reported to each other by each organization (hereinafter referred to as the "soundness verification result").

[0099] The configuration design information 554 includes information on the configuration to be prepared and provided by each organization based on the viewpoint of the entire consortium (hereinafter referred to as "configuration design information"). The configuration design information 554 may be set in a top-down manner based on the viewpoint of the entire consortium, or may be set in a bottom-up manner based on the requests and proposals of each organization. As described later, the contents of the configuration design information 554 may be automatically modified based on an action event 581.

[0100] Configuration compliance status 555 includes information indicating the degree to which each organization's configuration complies with the configuration design information (hereinafter referred to as ``configuration compliance status'') derived by comparing and contrasting the soundness verification results 553 and the configuration design information 554.

[0101] The capacity information 556 includes information indicating the range and upper limit of resources that each organization can provide (hereinafter, referred to as "capacity information").

[0102] Organization trust 557 includes information indicating the trust of each organization when each organization monitors the configuration of other organizations (distributed ledger node 3, client node 4) (hereinafter referred to as "organization trust").

[0103] The monitoring organization 558 includes information indicating an organization in charge of monitoring the health (hereinafter referred to as the "monitoring organization").

[0104] The capacity information 556 and the monitoring organization 558 will be described in detail in a second embodiment below.

[0105] The action event 581 of the SC event 222 includes information on an event (hereinafter also referred to as an "action event") generated by the health management SC 314 when the configuration compliance status does not meet the preset standard (configuration design information). The monitoring agent 435 of the client node 4 periodically refers to the action event 581, which is the SC event 222 of the BC 311, via the communication network 5, and when it confirms that the action event 581 includes instructions for itself, it executes processing according to the contents of the action event 581 (such as processing to output information to the organization to maintain or expand the distributed ledger node 3 so that the configuration compliance information meets the standard (configuration design information)).

[0106] Health report 511, which is an SC function of health management SC 314, receives a transaction (TX) for reporting the health monitoring result sent from client node 4, and records the health monitoring result in state information 312 as health monitoring result 552 by executing the received transaction (TX).

[0107] The above-mentioned SC function, mutual soundness verification 512 verifies the soundness monitoring results notified from each organization, and records the verification results in the state information 312 as soundness verification results 553 .

[0108] The configuration compliance status verification 513 , which is the above-mentioned SC function, verifies the configuration compliance status of each organization by comparing the soundness verification results with the configuration design information, and records the verification results in the state information 312 as configuration compliance status 555 .

[0109] The action instruction 514, which is the above SC function, identifies an organization with insufficient health by referring to the configuration compliance status 555, generates an action event targeted at the identified organization (its client node 4), and stores the generated action event in the SC event 222 as the action event 581.

[0110] The organization reliability calculation 515, which is the above-mentioned SC function, calculates the organization reliability of each organization involved in the monitoring of the soundness, and records the calculated organization reliability in the state information 312 as organization reliability 557. Details of the organization reliability calculation 515 will be described in the second embodiment.

[0111] The above-mentioned SC function, monitoring organization selection 516, selects an organization in charge of monitoring the health. Details of monitoring organization selection 516 will be described in the second embodiment.

[0112] The above-mentioned SC function, various data reference 517, is a function (for example, a query function) that accesses information sources such as the distributed ledger 310, the consortium information 302, and the participating member management information 303 to acquire or reference various data.

[0113] The above-described SC functions may be implemented as independent functions, or may be implemented as a single SC function in which all or part of them are integrated.

[0114] Next, the various types of information (data) shown in FIG. 5 will be explained.

[0115] Fig. 6A is an example of the health monitoring method definition 551 shown in Fig. 5. As shown in the figure, the illustrated health monitoring method definition 551 is composed of one or more records having items such as a monitoring method ID 5511, a monitoring method 5512, a monitoring frequency 5513, a judgment criterion 5514, and a judgment method 5515.

[0116] Of the above items, the monitoring method ID 5511 stores a monitoring method ID that is an identifier for the monitoring method.

[0117] The monitoring method 5512 stores information indicating the monitoring method used for monitoring the health.

[0118] The monitoring frequency 5513 stores information indicating the frequency at which health monitoring is performed.

[0119] The determinable criteria 5514 stores information (SC agreement conditions) indicating the criteria for determining the soundness of the distributed ledger node 3.

[0120] The determination method 5515 stores information indicating the determination method used to determine the soundness of the distributed ledger node 3 based on the results of soundness monitoring by multiple organizations.

[0121] For example, the record of the health monitoring method definition 551 shown in the figure with the monitoring method ID "monitoring method 01" defines that a monitoring method using the "service discovery API" (a method in which the client node 4 of each organization monitors health based on the results of acquiring node search information 401 by the node search unit 345) is performed with a monitoring frequency of "60 seconds." The same record also defines that the health monitoring results can be accepted (decided) if the "SC agreement conditions" are satisfied, and that the life or death of each node is decided by a "majority vote" of the health monitoring results collected from multiple organizations.

[0122] Also, the record with the monitoring method ID "Monitoring method 02" in the health monitoring method definition 551 shown in the figure defines that the "TX execution time by external monitoring" of each distributed ledger node 3 from each organization's client node 4 is monitored at a monitoring frequency of "60 seconds." The same record also defines that the health monitoring results can be accepted (decided) if the "SC agreement condition" is satisfied, and that the distributed ledger node 3 is judged to be "normal" if the average execution time based on the collected reports is "less than 3 seconds."

[0123] In the illustrated example of the health monitoring method definition 551, the contents of each item are described in text format, but the contents of each item may be described in a format such as JSON (JavaScript Object Notation) (both "Java" and "Javascript" are registered trademarks). In order to efficiently express more complicated processing, the contents of each item may be described according to, for example, a programming language or DSL (Domain Specific Language).

[0124] Fig. 6B is an example of the health monitoring result 552 shown in Fig. 5. As shown in the figure, the illustrated health monitoring result 552 is composed of one or more records having items such as a monitored organization ID 5521, a monitored target 5522, a monitoring result 5523, a monitoring date and time 5524, a time span 5525, etc.

[0125] Among the above items, the monitoring organization ID 5521 stores the organization ID (hereinafter also referred to as the "monitoring organization ID") of the organization that has monitored the distributed ledger node 3 of other organizations and reported the results. Note that the monitoring organization ID 5521 may store the identifier of the client node 4 owned by the organization (hereinafter referred to as the "client node ID").

[0126] The monitoring target 5522 includes, as sub-items, an organization ID 55221 and a distributed ledger node ID 55222. The organization ID of the organization that was the monitoring target in the monitoring is stored in the organization ID 55221 (hereinafter also referred to as the "monitored target organization ID"). In addition, the distributed ledger node ID 55222 stores the identifier of the distributed ledger node 3 that was the monitoring target in the monitoring (hereinafter referred to as the "distributed ledger node ID").

[0127] Information indicating the result of the monitoring is stored in the monitoring result 5523. In this example, if the monitoring result determines that the health of the monitored distributed ledger node 3 is normal, "OK" is stored, and if the health is determined to be abnormal, "NG" is stored.

[0128] The monitoring date and time 5524 stores information (timestamp) indicating the date and time when the monitoring result of the record was reported. The monitoring agent 435 of the client node 4 monitors the health of the distributed ledger node 3 of other organizations repeatedly (periodically, etc.) according to the monitoring frequency 5513 of the health monitoring method definition 551, and reports the results to the distributed ledger node 3. Note that the above dates and times may vary slightly between organizations.

[0129] Timespan 5525 stores a timespan, which is information used for absorbing the above-mentioned variations between organizations. The timespan is set, for example, by the health management SC or the monitoring agent 435 of each organization. Verification by the mutual health verification 512 is performed in units of health monitoring results for each timespan. For example, the record indicated by reference symbol 552a in the figure indicates that the result of health monitoring performed by "organization 1" on "node 1" of "organization 2" at the date and time "(omitted):00:001" within the timespan specified by "Span1-1" was "OK."

[0130] Fig. 6C is an example of the soundness check result 553 shown in Fig. 5. As shown in the figure, the example soundness check result 553 is composed of one or more records having items such as a monitoring target 5531 and a soundness check result history 5532.

[0131] Of the above items, monitoring target 5531 (organization ID 55311, distributed ledger node ID 55312) is similar to monitoring target 5522 in FIG. 6B, so description thereof will be omitted.

[0132] The health verification result history 5532 stores the results (health verification result) of verifying the health monitoring results reported by each organization and verifying the health (OK / NG) of the distributed ledger node 3. In the example shown in the figure, the health judgment results for each time span are stored in chronological order. For example, the first line record 553a stores (in JSON format) that the health verification results of "Node 2" of "Organization 1" are "OK" for "Span1-1" and "Span1-2" and "NG" for "Span1-3."

[0133] 6D is an example of configuration design information 554. The configuration design information 554 includes information indicating the configuration to be prepared and provided by each organization as the entire consortium. As shown in the figure, the illustrated configuration design information 554 is composed of one or more records having items such as an organization ID 5541, a preparation node 5542, and specification details 5543.

[0134] Of the above items, the organization ID 5541 stores an organization ID.

[0135] The preparation node 5542 stores information indicating the number of distributed ledger nodes 3 that an organization should prepare and provide for the consortium.

[0136] The specification details 5543 stores information indicating the specifications (specs) that should be satisfied by the distributed ledger node 3 that should be prepared and provided by the organization. The above information includes, for example, information indicating the hardware specifications (processing performance and capacity of the processor, memory, storage, etc.) of the distributed ledger node 3, software specifications (type and version of software such as operating system and application software, etc.), and information indicating the functions of the distributed ledger node 3 (TX approval function, approved TX distribution, etc.). The content of the above information is determined, for example, according to the management policy of the consortium. Note that when the client node 4 monitors the soundness of the distributed ledger node 3 of other organizations, compliance with the above information may be monitored.

[0137] Fig. 6E is an example of a configuration compliance status 555. The configuration compliance status 555 includes information indicating the configuration compliance status of the distributed ledger node 3 of each organization, which is generated by comparing the soundness verification result 553 of Fig. 6C with the configuration design information 554 of Fig. 6D. As shown in the figure, the illustrated configuration compliance status 555 is composed of one or more records having items such as an organization ID 5551, a compliance status 5552, a configuration compliance rate 5553, and a time span 5554.

[0138] Of the above items, the organization ID 5551 stores an organization ID.

[0139] The compliance status 5552 stores information indicating the configuration compliance status of the organization.

[0140] The configuration compliance rate 5553 stores information indicating the configuration compliance rate of the organization.

[0141] Information indicating the time span in which the configuration compliance status of the record was confirmed is stored in the time span 5554. If the granularity of verifying the configuration compliance status for each monitoring frequency is too fine, for example, the configuration compliance status may be confirmed in units of multiple time spans.

[0142] In the case of the figure, for example, record 555a indicates that the configuration compliance status of "Organization 1" is "OK" in the time span "Span1", and the configuration compliance rate is "99.9%." Note that the time span "Span1" means that the data of "Span1-XX" in the soundness verification result 553 in FIG. 6C is aggregated.

[0143] Record 555b in the figure indicates that the configuration compliance status of "Organization 1" is "NG" for the time span "Span1", and the configuration compliance rate is "50%." As shown in the figure, the compliance status 5552 of the record stores the reason for the "NG" compliance status in this example, "one node missing," in JSON format.

[0144] 6F is an example of capacity information 556. The capacity information 556 includes information indicating the range and upper limit of resources that each organization can provide. As shown in the figure, the illustrated capacity information 556 is composed of one or more records having items such as an organization ID 5561 and a prepared node 5562.

[0145] Of the above items, the organization ID 5561 stores an organization ID.

[0146] Information indicating the range and upper limit of resources that the organization can provide for the consortium is stored in the preparation ready node 5562. In this example, the number of distributed ledger nodes 3 is stored in the preparation ready node 5562. Note that the preparation ready node 5562 may include, for example, information of the specifications shown in FIG. 6D.

[0147] 6G is an example of organization reliability 557. Organization reliability 557 includes information indicating the reliability of each organization involved in health monitoring. As shown in the figure, the illustrated organization reliability 557 is composed of one or more records having items such as organization ID 5571, health report content reliability 5572, configuration compliance reliability 5573, etc.

[0148] Of the above items, the organization ID 5571 stores an organization ID.

[0149] Information quantitatively indicating the degree to which the health monitoring results reported by the organization can be trusted (hereinafter also referred to as "health report content reliability") is stored in the health report content reliability 5572. In this example, the health report content reliability 5572 stores a value expressing the degree of agreement with the report contents of other organizations as a percentage.

[0150] The configuration compliance reliability 5573 stores information quantitatively indicating how reliable the organization is in terms of configuration compliance (hereinafter, also referred to as "configuration compliance reliability"). Note that, like the configuration compliance rate 5553 shown in Fig. 6E, the configuration compliance reliability may be grasped using a time span. Also, for example, the configuration compliance reliability may be calculated based on the cumulative value of the configuration compliance rate over a predetermined period of time in the past.

[0151] 6H is an example of a monitoring organization 558. The monitoring organization 558 stores information indicating an organization that is responsible for monitoring the health of distributed ledger nodes 3 of other organizations. As shown in the figure, the illustrated monitoring organization 558 is composed of multiple records having items such as a monitoring organization ID 5581.

[0152] A list of organization IDs of organizations in charge of monitoring and reporting health status is stored in the monitoring organization ID 5581. The record indicated by the reference numeral 558a in the figure indicates that "organization 1", "organization 3", and "organization 4" are organizations that monitor and report health status.

[0153] 7 is a flowchart explaining the process (hereinafter referred to as "member registration process S700") performed by the distributed ledger node 3 when registering a member participating in the distributed ledger network. Below, the member registration process S700 will be explained with reference to the same figure.

[0154] First, the member management unit 350 receives a member registration request (hereinafter referred to as a "member registration request") from a client node 4 or the like (S711). The member registration request includes the organization ID of the organization to which the member to be registered (hereinafter referred to as a "target member") belongs and the member ID of the target member.

[0155] Next, the member management unit 350 generates a pair of a private key and a public key (hereinafter, a pair of a private key and its public key will be referred to as a "key pair") for the target member specified in the member registration request, and associates the generated key pair with the member ID (S712).

[0156] Next, the member management unit 350 broadcasts the target member's information (organization ID, member ID, etc.) and the public key of the key pair to the other distributed ledger nodes 3 (S713). The other distributed ledger nodes 3 that receive the broadcast manage the received information as participating member management information 303.

[0157] Next, the member management unit 350 transmits the private key D31 of the key pair generated in S712 to the other distributed ledger node 3 that sent the member registration request in S711 (S714). The other distributed ledger node 3 that receives the private key D31 manages the received private key D31 in the participating member management information 303 as its own private key D31.

[0158] In the above, the member management unit 350 has been described as a function of the distributed ledger node 3, but the member management unit 350 may be implemented in other nodes, such as the client node 4 or a node dedicated to member management.

[0159] In this embodiment, the key pair generated in S712 is used to authenticate members participating in the distributed ledger network, sign various transactions (TX), control SC execution authority, etc. For example, the client node 4 issues a transaction (TX) digitally signed with a private key, and the distributed ledger node 3 that verifies this performs identity verification by verifying the digital signature using a public key corresponding to the private key. The method of generating the key pair, the method of verifying the digital signature, the method of associating the member ID with the key pair, etc. are performed by publicly known or well-known technologies, for example.

[0160] 8 is a flowchart explaining the process (hereinafter referred to as "SC deployment / execution process S800") performed by the distributed ledger node 3 when deploying or executing a smart contract (SC) to the distributed ledger 310 of the distributed ledger node 3. Below, the SC deployment / execution process S800 will be explained with reference to the same figure.

[0161] First, the TX manager 320 receives a transaction (TX) for deploying or executing a smart contract (SC) from another node such as the client node 4 (S811).

[0162] Next, the consensus manager 325 of the distributed ledger node 3 determines whether the received transaction (TX) is a deploy TX or an execution TX (S812). If the received transaction (TX) is a deploy TX (S812: deploy TX), the process proceeds to S821. If the received transaction (TX) is an execution TX (S812: execute TX), the process proceeds to S831.

[0163] In S821, the consensus manager 325 performs a process (hereinafter referred to as "consensus formation process") for forming a consensus with other distributed ledger nodes 3 regarding the execution of the received deploy TX and its addition to the BC311 (S821). The consensus formation is performed using, for example, publicly known or well-known technology. For example, when forming a consensus using the "Endorser-Orderer model" disclosed in Non-Patent Document 3, the consensus formation is performed in the following procedure.

[0164] First, the consensus management unit 325 selects distributed ledger nodes 3 with approval authority from among the distributed ledger nodes 3 (including itself) participating in the distributed ledger network, and shares the deploy TX with each of the selected distributed ledger nodes 3. Each of the selected distributed ledger nodes 3 verifies whether or not there is a problem with the shared deploy TX (verifying whether or not it has been tampered with, verifying whether or not it is legitimate, etc.).

[0165] The consensus management unit 325 obtains the verification result ("approved" or "not approved") from each of the selected distributed ledger nodes 3, compares the verification result of each distributed ledger node 3 with the preset agreement conditions (e.g., approval by two or more organizations), and determines whether to accept the deploy TX. The consensus management unit 325 then transmits the result of the determination to all distributed ledger nodes 3 participating in the distributed ledger network.

[0166] Furthermore, in this type of consensus building using the “Endorser-Orderer model,” all distributed ledger nodes 3 participating in the distributed ledger network do not need to verify the transaction (TX), and the transaction (TX) can be verified efficiently.

[0167] Once an agreement is reached, the TX distributor 36 (of the distributed ledger node 3) then broadcasts a deploy TX to all distributed ledger nodes 3 participating in the distributed ledger network. The SC execution management unit 330 of the distributed ledger node 3 that receives the deploy TX executes the received deploy TX and deploys the smart contract (SC) related to the deploy TX to the distributed ledger 310 (S822). The deployment is performed by registering the SC_ID and the entity of the smart contract (SC) as state information on the distributed ledger 310 based on the contents of the deploy TX, and adding the block of the deploy TX to the end of the blockchain (BC) (BC311).

[0168] Next, the consensus management unit 325 transmits the execution result of the deploy TX to the sender of the deploy TX (S823).

[0169] On the other hand, in S831, the consensus management unit 325 performs a consensus formation process for the execution TX similar to S821. When the consensus is established, the approved TX distribution unit 335 then broadcasts the execution TX to all distributed ledger nodes 3 participating in the distributed ledger network. The SC execution management unit 330 of the distributed ledger node 3 that receives the execution TX executes the smart contract (SC) specified by the execution TX (S832). The smart contract (SC) is executed by specifying the call function specified in the execution TX and providing input arguments to the smart contract (SC) specified in the execution TX. By executing the smart contract (SC), the contents of the distributed ledger 310 are updated, and the block of the execution TX is added to the end of the blockchain (BC) (BC311).

[0170] Next, the consensus manager 325 of the distributed ledger node 3 sends the execution result of the execution TX to the sender of the execution TX (S833).

[0171] 9 is a flowchart explaining the process (hereinafter referred to as "health report process S900") performed in the distributed ledger system 1 when a client node 4 of an organization monitors the health of a distributed ledger node 3 of another organization and reports the result to the distributed ledger node 3. The health report process S900 will be explained below with reference to the same figure. Note that it is assumed that the smart contract (SC) executed in the health report process S900 has already been deployed to each distributed ledger node 3 before the execution of the process.

[0172] The monitoring agent 435 of the client node 4 monitors the health of the distributed ledger node 3 of other organizations using the method specified in the health monitoring method definition 551 of the state information 312 (S911).

[0173] For example, the monitoring agent 435 cooperates with the node search unit 425 in accordance with one of the health monitoring method definitions 551 illustrated in FIG. 6A (here, the definition of the record whose monitoring method ID is "Monitoring method 01") to obtain information indicating whether each of the distributed ledger nodes 3 in the distributed ledger network is currently available, judges the health based on the obtained information, and treats the result as the health monitoring result.

[0174] Next, the client node 4 uses the health monitoring result of S911 as input and sends (issues) an execution TX to the distributed ledger node 3 to call (instruct execution of) the SC function “Health Report 511” of the Health Management SC 314 (S912).

[0175] When the distributed ledger node 3 receives the above-mentioned health monitoring result and execution TX, the SC execution management unit 330 executes the SC function “Health Report 511” in accordance with the execution TX, using the received health monitoring result as input (S921).

[0176] In processing the SC function "Health Report 511", the distributed ledger node 3 first checks whether the organization has the authority to report the health based on the received execution TX and the information received accompanying the execution TX (such as information on the organization of the sender of the execution TX) (S922). Then, when it is confirmed that the organization has the above-mentioned authority, the distributed ledger node 3 adds the health monitoring result received from the client node 4 to the health monitoring result 552 of the state information 312 (S923).

[0177] For example, the information of the four records indicated by the reference characters 552a to 552d in the health monitoring result 552 in Fig. 6B is information added when the health report 511 is executed by the execution TX sent from the client node 4 of "organization 1". These records store the health monitoring results of the distributed ledger nodes 3 of other organizations, "organization 2" and "organization 3", as the health monitoring results for the timespan "Span1-1".

[0178] Furthermore, the reports of health monitoring results from each organization may be subject to access restrictions, for example, so that they cannot be overwritten by organizations other than the organization that made the report (for example, access may be restricted using the "ABAC, State endorsement" method described in non-patent document 3).

[0179] Fig. 10 is a flowchart explaining the process (hereinafter referred to as "mutual soundness verification process S1000") that the distributed ledger node 3 performs when an execution TX that calls the SC function "mutual soundness verification 512" of the soundness management SC in Fig. 5 is sent from the client node 4 to the distributed ledger node 3. Below, the mutual soundness verification process S1000 will be explained with reference to the same figure.

[0180] When the distributed ledger node 3 receives the above execution TX, the SC execution management unit 330 executes the SC function “soundness mutual verification 512” of the soundness management SC (S1011).

[0181] In processing the SC function “mutual health verification 512”, the distributed ledger node 3 refers to the state information “health monitoring result 552” for the verification target period (time span) and verifies the health of the distributed ledger node 3 for the verification target period (S1012).

[0182] The above verification target period may be based on information received from the client node 4 in association with the execution TX, or may be automatically determined from the current date and time. Also, it may be the entire period that can be verified.

[0183] For example, in the health monitoring result 552 of Fig. 6B, the distributed ledger node 3 of "node 1" of organization 2 in the time span of "Span1-1" in timespan 5525 stores "OK" for both the monitoring results of "organization 1" and "organization 3" in monitoring result 5523. In this case, if reports from other participating organizations are also "OK", the judgment criterion 5514 "SC agreement condition" (here, the SC agreement condition 3026 "approval of more than half of the participating organizations" for business ID 3025 of "business A" in Fig. 4B) is satisfied, and the health verification result becomes "OK" according to judgment method 5515 "majority vote".

[0184] Returning to Figure 10, in the subsequent processing of the SC function "mutual soundness verification 512", the distributed ledger node 3 adds or updates the soundness verification result to "soundness verification result 553" in the state information 312 (S1013). For example, if the soundness verification result 553 is the content of Figure 6B, "Span1-1: OK" is added as soundness verification result history 5532 to the record of "Node 1" of "Organization 2" in the soundness verification result 553 in Figure 6C.

[0185] In the above, the case where the mutual soundness verification process S1000 is performed in response to the transmission (issuance) of an execution TX of the SC function "mutual soundness verification 512" from a client node 4 of a certain organization has been exemplified, but the mutual soundness verification process S1000 may be performed in response to other events. For example, when the soundness report process S900 is performed by the SC function "soundness report 511", the distributed ledger node 3 may determine whether or not a report has been obtained that satisfies the determination criterion for whether or not soundness verification is possible for the verification target period, and if it is determined that the report has been obtained, the SC function "mutual soundness verification 512" may be subsequently executed. In addition, the mutual soundness verification process S1000 may be performed in response to the occurrence of a predetermined SC event.

[0186] Fig. 11 is a flowchart explaining the process (hereinafter referred to as "configuration compliance status verification process S1100") performed in the distributed ledger node 3 when an execution TX of the SC function "configuration compliance status verification 513" of the health management SC 314 in Fig. 5 is sent from the client node 4 to the distributed ledger node 3 of the group of distributed ledger nodes 3, and the process (hereinafter referred to as "action process S1150") performed in the distributed ledger node 3 when an execution TX of the SC function "action instruction 514" is sent. Below, the configuration compliance status verification process S1100 and action process S1150 will be explained with reference to this figure.

[0187] First, the processes of S1111 to S1114, which correspond to the configuration compliance status verification process S1100, will be described.

[0188] Each distributed ledger node 3 in the group of distributed ledger nodes 3 receives the call of the SC function “configuration compliance status verification 513” of the health management SC 314 as the execution TX, and the SC execution management unit 330 of each distributed ledger node 3 executes the SC function “configuration compliance status verification 513” in accordance with the received execution TX (S1111).

[0189] In processing the SC function “configuration compliance status verification 513”, the distributed ledger node 3 first acquires the configuration design information 554 (S1112). Note that the SC function “configuration compliance status verification 513” acquires the configuration design information 554 using, for example, a data reference function.

[0190] In the subsequent processing of the SC function “Configuration Compliance Status Verification 513”, the distributed ledger node 3 refers to the state information 312 “Soundness Verification Result 553” for the verification period (timespan) and verifies the configuration compliance status of each organization for the verification period (S1113).

[0191] The verification target period is specified, for example, by input information from the execution TX. The verification target period may be automatically determined by the distributed ledger node 3 based on the current date and time. For example, the distributed ledger node 3 may set all unverified periods as the verification target period.

[0192] The configuration compliance status of the distributed ledger node 3 is calculated, for example, from the proportion of the period during which the health of the distributed ledger node 3 was normal during the target period, and the configuration compliance rate is calculated from the difference between the number of distributed ledger nodes 3 whose health was normal during the target period and the preparation node 5542 in the configuration design information 554. A specific explanation will be given using the health verification result 553 in Fig. 6C and the configuration design information 554 in Fig. 6D as examples.

[0193] First, from the soundness verification result 553, for example, when "Span1 (Span1-X)" is the verification target period, the soundness verification result of "Node 1" of "Organization 1" is "OK at Span1-1, OK at Span1-2, OK at Span1-3...", so the soundness of "Node 1" of "Organization 1" in the time span of "Span1" is "3÷3=100%". Similarly, the soundness of "Node 2" of "Organization 1" is "100%".

[0194] Comparing with configuration design information 554, for "Organization 1," preparation node 5542 is "2 nodes," and health verification result 553 confirms that the health of two nodes, "Node 1" and "Node 2," was "100%" (normal) during the verification period. Therefore, the compliance status during the verification period is "OK," and the compliance rate during the verification period is "100%."

[0195] In addition, the result of the soundness verification of distributed ledger node 3 of "node 1" of "organization 2" is "OK in Span1-1, OK in Span1-2, OK in Span1-3...", so the soundness of "node 1" of "organization 2" in the time span of "Span1" is "3÷3=100%". On the other hand, the soundness of "node 2" of "organization 2" is 0÷3, which is "0%".

[0196] Comparing with the configuration design information 554, for "organization 2", the preparation node 5542 is "2 nodes", and the soundness verification result 553 shows that the soundness of "node 2" is "0%", the compliance status during the verification period is "NG", and the reason is "1 node missing". Also, the configuration compliance rate is "100%+0% / 2=50%".

[0197] Returning to FIG. 11, in the subsequent processing of the SC function “Configuration Compliance Status Verification 513”, the distributed ledger node 3 adds (updates) the verification result to the state information 312 “Configuration Compliance Status” of the health management SC 314 (S1114).

[0198] In the above, the case where the configuration compliance status verification process S1100 is executed when the distributed ledger node 3 receives an execution TX of the SC function "configuration compliance status verification 513" has been described, but the configuration compliance status verification process S1100 may be executed when another event is triggered. Also, the configuration compliance status verification process S1100 may be executed according to a preset target period or execution frequency such as the monitoring frequency 5513 shown in FIG. 6A. Also, for example, the SC function "configuration compliance status verification 513" may be executed following the SC function "soundness mutual verification 512". Also, the SC function "configuration compliance status verification 513" may be executed when an SC event occurs.

[0199] Next, the processes of S1151 to S1154 and S1161 to S1163, which correspond to the action process S1150, will be described with reference to the same figure.

[0200] When each distributed ledger node 3 receives an execution TX that calls the SC function "action instruction 514" of the health management SC as the execution TX (S1151), the SC execution management unit 330 executes the SC function "action instruction 514" according to the received execution TX. Note that the SC function "action instruction 514" may be automatically executed by the distributed ledger node 3 following the SC function "configuration compliance status verification 513".

[0201] In processing the SC function “action instruction 514”, the distributed ledger node 3 first determines whether the current configuration compliance status deviates from a predetermined condition (S1152). The above condition may be, for example, that the configuration compliance status remains “NG” for a certain period of time, or that the configuration compliance rate of all or any of the organizations falls below a predetermined threshold.

[0202] In S1152, if the current configuration compliance status does not deviate from the predetermined condition (S1152: No), the action process S1150 ends. On the other hand, if the current configuration compliance status deviates from the predetermined condition (S1152: Yes), the SC function "action instruction 514" determines an action (e.g., "request for configuration review", "impose penalty", etc.) for the participating organizations of the consortium according to the current situation (S1153).

[0203] In the configuration compliance status 555 in Fig. 6E, one distributed ledger node 3 of "organization 2" is missing in "Span1", and the configuration compliance status 555 deviates from the configuration design information 554. Therefore, the SC function "action instruction 514" determines and issues an action for the consortium as follows.

[0204] First, the distributed ledger node 3 reviews the configuration and decides to add one node to the consortium to make up for the shortage. The distributed ledger node 3 also refers to the capacity information 556 to select an organization that will prepare the node. For example, when the capacity information 556 in FIG. 6F is compared with the configuration design information 554 in FIG. 6D, it is found that each of "organization 1", "organization 3", and "organization 4" has one spare node in the preparation available node 5562. Therefore, the distributed ledger node 3 decides to issue an action to request "organization 4", which currently has the fewest preparation nodes 5542, to provide a distributed ledger node 3 to the consortium instead of "organization 2". On the other hand, the distributed ledger node 3 decides to issue an action to impose a penalty (such as payment of the loss amount during the period of "Span1") on "organization 2" for not being able to prepare the configuration specified in the configuration design information 554. The distributed ledger node 3 generates an action event that instructs the actions that it has decided to issue, and stores the generated action event in the SC event 222 as an action event 581 (S1154).

[0205] The monitoring agent 435 of the client node 4 constantly monitors the SC event 222. When the monitoring agent 435 detects the occurrence of the above action event 581 (S1161), it checks whether its own organization is the target organization of the action event 581 (S1162). If its own organization is the target organization of the action event 581 (S1162: YES), the client node 4 performs processing corresponding to the action event 581 according to the contents instructed in the action event 581 (S1163). The monitoring agent 435 reports the result of performing the processing of the action event 581 to the consortium, for example, via the health management SC 314, as necessary.

[0206] For example, when each organization confirms the occurrence of action event 581 for itself, it responds according to the contents of action event 581, such as adding distributed ledger node 3 to the consortium, and reports the result to distributed ledger node 3. When distributed ledger node 3 receives the report, it updates configuration design information 554 (for example, adding one preparation node for "organization 4" and deducting one preparation node for "organization 2"). This makes it possible to correct the configuration of the consortium. In response to action event 581, organization 2 pays the penalty loss amount to the consortium, for example, as virtual currency.

[0207] As described above, according to the distributed ledger system 1 of this embodiment, objectivity can be ensured by having (multiple) other organizations carry out / verify soundness monitoring (correctness / aliveness of configuration).

[0208] In addition, as shown above, by performing a certain process using a smart contract (SC), the health monitoring results of each organization can be aggregated on-chain for analysis and processing. This eliminates the single point of trust and provides value as evidence.

[0209] In addition, the distributed ledger system 1 of this embodiment has the advantages of enabling information collection across organizations and enabling actions to be taken based on reliable evidence.

[0210] [Second embodiment] Next, we will explain the distributed ledger system 1 of the second embodiment. Note that the basic configuration of the distributed ledger system 1 of the second embodiment is similar to that of the distributed ledger system 1 of the first embodiment, so the following explanation will focus on the differences from the first embodiment.

[0211] The distributed ledger system 1 of the second embodiment has the same configuration as the distributed ledger system 1 of the first embodiment, but also has a configuration for determining the trustworthiness of each organization (hereinafter referred to as "organization trustworthiness") based on the content of each organization's report and its configuration compliance status, and for feeding back the results to the consortium and each organization. Furthermore, the distributed ledger system 1 of the second embodiment has a configuration for selecting an organization that will monitor the soundness of other distributed ledger nodes 3 based on the organization trustworthiness.

[0212] 12 is a flowchart explaining the process (hereinafter referred to as "trust calculation process S1200") that the distributed ledger node 3 in the distributed ledger system 1 of the second embodiment performs when calculating the organization trust of each organization. The trust calculation process S1200 will be explained below with reference to the same figure.

[0213] When each distributed ledger node 3 receives, from the client node 4, an execution TX that calls the SC function “organization trust calculation 515” of the health management SC 314 shown in Fig. 5 as an execution TX, it executes the SC function “organization trust calculation 515” (S1211). Note that the client node 4 transmits (issues) the above execution TX to each distributed ledger node 3 at a predetermined timing (e.g., periodically, etc.).

[0214] In processing the SC function "organization reliability calculation 515", the distributed ledger node 3 first refers to the health monitoring result 552 and the health verification result 553 in the state information 312 for the period to be calculated (e.g., a timespan, hereinafter referred to as the "calculation period"). Then, based on the acquired information, the distributed ledger node 3 calculates the reliability of the content of the health monitoring of each organization for the calculation period (hereinafter referred to as the "health report content reliability") (S1212).

[0215] The above calculation target period may be, for example, attached to the execution TX sent from the client node 4 to the distributed ledger node 3, or may be automatically set from the current date and time. In addition, all periods not included in the calculation target may be included.

[0216] The reliability of the health report contents is calculated, for example, from the degree (percentage) of agreement between the health monitoring results of the organization being calculated for each time span and the judgment results of other organizations (the consensus of the entire consortium) for each time span.

[0217] In the subsequent processing of the SC function “organization trust calculation 515”, the distributed ledger node 3 refers to the configuration compliance status 555 of the state information 312 for the calculation period, and calculates the degree of configuration compliance of each organization for the calculation period (hereinafter referred to as “configuration compliance trust”) (S1213).

[0218] The configuration compliance reliability is calculated, for example, from statistics (average value, minimum value, maximum value, etc.) of the configuration compliance rate of all time spans in the calculation target period for each organization.

[0219] In the subsequent processing of the SC function “Organization Trustworthiness Calculation 515”, the distributed ledger node 3 adds (updates) information based on the health report content trustworthiness calculated in S1212 and the configuration compliance trustworthiness calculated in S1213 as organization trustworthiness to the organization trustworthiness 557 of the state information 312 of the health management SC (S1214).

[0220] In this way, the organization reliability is calculated and recorded in the state information 312, so that an objective evaluation of the reliability of each organization can be obtained.

[0221] In addition, the reliability of the health report contents may be used as a criterion and a method for determining mutual health verification. For example, it may be used in such a way that reports from organizations with high reliability of the health report contents are given greater weight.

[0222] Furthermore, the reliability of the health report contents may be used to select an organization to monitor the health of the system. For example, priority may be given to an organization with a high reliability of the health report contents.

[0223] In this way, by utilizing the reliability of the health report content, it is expected that the accuracy of health monitoring can be improved.

[0224] In addition, the configuration compliance reliability can be used to weight the penalty amount based on the configuration compliance reliability when determining the content of the above-mentioned action event 581. This is expected to improve the soundness of the operation of the distributed ledger system 1.

[0225] In addition, one possible use of configuration compliance trust is that if an organization is short of distributed ledger nodes 3, it can request the provision of distributed ledger nodes 3 from another organization with a higher configuration compliance trust than the organization in question.

[0226] In this way, by actively utilizing the configuration compliance reliability, it is expected that the effect of promoting the maintenance and improvement of the configuration compliance rate as a consortium can be achieved.

[0227] 13 is a flowchart explaining the process (hereinafter referred to as "monitoring organization selection process S1300") that the distributed ledger node 3 in the distributed ledger system 1 of the second embodiment performs when selecting an organization that will monitor the health of the distributed ledger node 3. The monitoring organization selection process S1300 will be explained below with reference to the same figure.

[0228] When each distributed ledger node 3 receives, from the client node 4, an execution TX that calls the SC function “Select monitoring organization 516” of the health management SC 314 shown in Fig. 5 as an execution TX, it executes the SC function “Select monitoring organization 516” (S1311). The client node 4 transmits (issues) the above execution TX to each distributed ledger node 3 at an appropriate timing (e.g., periodically, etc.).

[0229] In processing the SC function "Select monitoring organization 516", the distributed ledger node 3 first acquires information (such as SC agreement conditions) used to select a monitoring organization based on the determinable criteria 5514 of the health monitoring method definition 551 in the state information 312 (S1312). For example, in the above processing, if the determinable criteria 5514 stores "SC agreement conditions", the distributed ledger node 3 acquires the SC agreement conditions included in the consortium information 302 stored in the memory unit 300 of the distributed ledger node 3. In this example, the SC agreement condition "approval from three or more organizations" is acquired.

[0230] In the subsequent processing of the SC function “Select monitoring organization 516”, the distributed ledger node 3 obtains the organization trust level 557 of the state information 312 (S1313).

[0231] Next, in the above process, the distributed ledger node 3 determines the monitoring organization using the information acquired in S1312 and S1313 (S1314). For example, the distributed ledger node 3 selects three organizations to at least satisfy the SC agreement conditions. For example, when the organization reliability 557 is the content of FIG. 6G, the SC function "select monitoring organization 516" selects "organization 1", "organization 3", and "organization 4" in descending order of health report content reliability 5572.

[0232] In the subsequent processing of the SC function “select monitoring organization 516”, the distributed ledger node 3 adds (updates) the selected organization to the monitoring organization 558 of the state information 312 (S1315).

[0233] The monitoring agent 435 of the client node 4 of each organization obtains the monitoring organization 558, for example, via the health management SC 314, and if it is selected as the monitoring organization, monitors the health of other organizations and reports to the distributed ledger node 3.

[0234] Also, for example, the health management SC 314 uses the information of the monitoring organization 558 to check whether the organization has the authority in S922 of FIG.

[0235] In the above, organizations that at least satisfy the judgment possible criteria 5514 (SC agreement conditions) are selected, but it is also possible to select a few more organizations to be on the safe side. By doing so, it is possible to reduce the risk of a shortage of monitoring organizations when, for example, there are only organizations with low reliability of the health report contents.

[0236] As described above, by selecting the minimum number of monitoring organizations based on the identifiable criteria for health monitoring (especially the agreement conditions for the distributed ledger system, such as the SC agreement conditions), it is possible to ensure objectivity in monitoring the health of the distributed ledger nodes 3 while also improving the efficiency of resource and processing amounts.

[0237] <Provision of health information> The distributed ledger system 1 described above includes a mechanism for providing users with information managed in the distributed ledger 310 of the distributed ledger node 3 at any time. The mechanism may directly access the distributed ledger 310 to obtain the information, or may obtain the information using a smart contract (SC) deployed in the distributed ledger node 3 (distributed ledger 310) like the health management SC 314. The mechanism for providing the information may be provided in the distributed ledger node 3 or the client node 4, or in a node other than those (such as a web server).

[0238] 14 is an example of a screen (hereinafter, referred to as a "health information providing screen 1400") that is presented to a user by an information processing device that provides the above information. The illustrated health information providing screen 1400 displays information that focuses on the organization whose logged-in organization ID is "organization 1."

[0239] The example health information screen 1400 displays each organization's configuration compliance status 1411, health verification result history 1412, health monitoring results of other organizations by the organization in question 1413, health monitoring results of the organization in question by other organizations 1414, and organizational reliability 1415 of each organization participating in the consortium.

[0240] In this way, users in each organization can easily check the contents of the state information 312 via the health information provision screen 1400, which can be useful in managing the health of their own organization's distributed ledger node 3.

[0241] <Technical effect> As described above, the distributed ledger node 3 in the distributed ledger system 1 of this embodiment receives soundness monitoring results that are the results of a first organization monitoring the soundness of a distributed ledger node 3 of a second organization, verifies the received soundness monitoring results from multiple organizations, and records the soundness verification results that are the results of the verification in the distributed ledger 310. As a result, the objective soundness verification results for the distributed ledger nodes 3 of each organization can be aggregated and managed in the distributed ledger 310, and the soundness of the distributed ledger system 1 as a whole can be efficiently monitored based on objective information.

[0242] In addition, since the acquisition and verification of health monitoring results are performed by smart contracts (SC), information on the health of each organization can be managed as on-chain information in a distributed ledger. This makes it possible to provide highly reliable / evidence-based information by eliminating a single point of trust.

[0243] Furthermore, the distributed ledger node 3 compares the soundness verification result with the configuration design information of the second organization, thereby generating a configuration compliance status, which is information indicating the degree to which the organization complies with the configuration design information, and records it in the distributed ledger 310. Therefore, the configuration compliance information of the distributed ledger node 3 of each organization used to judge soundness can be managed and provided as highly objective information.

[0244] Furthermore, if the configuration compliance status of the second organization does not satisfy the configuration design information, the distributed ledger node 3 records information instructing the second organization to review the configuration of the distributed ledger node 3 in the distributed ledger 310. Therefore, the second organization can recognize that a review of the distributed ledger node 3 is necessary by referring to the above information.

[0245] In addition, if the configuration compliance status of the second organization does not satisfy the configuration design information, the distributed ledger node 3 records information in the distributed ledger indicating that a penalty will be imposed on the second organization due to a lack of configuration of the distributed ledger node 3. Therefore, by referring to the above information, the second organization can recognize that it is necessary to review the distributed ledger node in order to avoid the penalty.

[0246] In addition, the distributed ledger node 3 generates an organization trust level, which is the trust level of each of multiple organizations, based on the configuration compliance status and records it in the distributed ledger, thereby being able to provide the organization trust level of each organization.

[0247] In addition, the distributed ledger node 3 generates an organization trust level, which is the trust level of each of multiple organizations, based on the health monitoring results and records it in the distributed ledger, thereby being able to provide the organization trust level of each organization.

[0248] In addition, the client node 4 of the organization monitors the health of the second organization in accordance with the health monitoring method definition 551 of the distributed ledger 310, thereby preventing variations in health monitoring methods between organizations.

[0249] In addition, since the distributed ledger node 3 determines the monitoring organization based on the health monitoring results, it can select a highly reliable organization as the monitoring organization.

[0250] In addition, since the distributed ledger node 3 determines the monitoring organization based on the organization trust level, it is possible to select a highly reliable organization as the monitoring organization.

[0251] In addition, since the distributed ledger node 3 selects the monitoring organization based on the configuration compliance status, it is possible to select a highly reliable organization as the monitoring organization.

[0252] <Example of information processing device> 15 is an example of an information processing device (computer) used to realize the distributed ledger system 1 described in the first and second embodiments. The client node 4 and the distributed ledger node 3 are configured using, for example, an information processing device 10 shown in the figure.

[0253] The illustrated information processing device 10 includes a processor 11, a main storage device 12 (memory), an auxiliary storage device 13 (external storage device), an input device 14, an output device 15, and a communication device 16. These are communicatively connected via a bus, a communication cable, etc. Examples of the information processing device 10 include personal computers, various server devices, office computers, general-purpose machines (mainframes), smartphones, tablets, etc.

[0254] The information processing device 10 may be realized, in whole or in part, by using virtual information processing resources provided by using virtualization technology, process space separation technology, or the like, such as a virtual server provided by a cloud system. In addition, all or in part of the functions provided by the information processing device 10 may be realized by a service provided by a cloud system via an API (Application Programming Interface), for example. In addition, all or in part of the functions provided by the information processing device 10 may be realized by using, for example, Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), or the like.

[0255] The processor 11 is configured using, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), a GPU (Graphics Processing Unit), an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), an AI (Artificial Intelligence) chip, etc.

[0256] The main memory device 12 is a device used by the processor 11 when executing a program, and is, for example, a read only memory (ROM), a random access memory (RAM), a non-volatile memory (NVRAM (Non Volatile RAM)), etc. Various functions realized in each component of the distributed ledger system 1 are realized by each processor 11 reading out programs and data stored (memorized) in the auxiliary memory device 13 into the main memory device 12 and executing them.

[0257] The auxiliary storage device 13 is a device that stores programs and data, and can be configured, for example, by various storage systems such as SSDs (Solid State Drives), hard disk drives, optical storage devices (CDs (Compact Discs), DVDs (Digital Versatile Discs), etc.), NASs (Network Attached Storage), etc., read / write devices for non-transient recording media such as IC cards, SD cards, and optical recording media, and non-transient storage areas of cloud servers. Programs and data can be read into the auxiliary storage device 13 from other information processing devices equipped with non-transient recording media or non-transient storage devices via a recording medium reader or communication device 16. The programs and data stored (stored) in the auxiliary storage device 13 are read into the main storage device 12 as needed.

[0258] The input device 14 is an interface that accepts input of information from the outside, and is, for example, a keyboard, a mouse, a touch panel, a card reader, a pen-input tablet, a voice input device, or the like.

[0259] The output device 15 is an interface that outputs various information such as the process progress and the process result to the outside. The output device 15 is, for example, a display device (liquid crystal monitor, LCD (Liquid Crystal Display), graphic card, etc.) that visualizes the above-mentioned various information, a device that converts the above-mentioned various information into voice (voice output device (speaker, etc.)), and a device that converts the above-mentioned various information into text (printer, etc.). For example, the information processing device 10 may be configured to input and output information to and from other devices via the communication device 16.

[0260] The input device 14 and the output device 15 constitute a user interface that realizes interactive processing with the user (receiving information, providing information, etc.).

[0261] The communication device 16 is a device that realizes communication with other devices. The communication device 16 is a wired or wireless communication interface that realizes communication with other devices via the communication network 5, and is, for example, a NIC (Network Interface Card), a wireless communication module, a USB module, or the like.

[0262] The information processing device 10 may be implemented with, for example, an operating system, a file system, a DBMS (DataBase Management System) (relational database, NoSQL, etc.), a KVS (Key-Value Store), etc.

[0263] Although an embodiment of the present invention has been described in detail above with reference to the drawings, the specific configuration is not limited to this embodiment, and designs that do not deviate from the gist of the present invention are also included. [Explanation of symbols]

[0264] 1 Distributed ledger system, 3 Distributed ledger node, 300 Memory unit, 302 Consortium information, 303 Participating member management information, 310 Distributed ledger, 311 Blockchain (BC), 312 State information, 313 Business SC, 314 Health management SC, 320 TX management unit, 325 Consensus management unit, 330 SC execution management unit, 335 Approved TX distribution unit, 340 TX issuing unit, 345 Node search unit, 350 Member management unit, 355 Communication unit, 4 Client node, 400 Memory unit, 401 Node search information, 420 TX issuing unit, 425 Node search unit, 430 Business application, 435 Monitoring agent, 511 Health report, 512 Health mutual validation, 513 Configuration compliance status validation, 514 Action instruction, 515 Organization trust calculation, 516 Selection of monitoring organization, 517 Various data reference, 551 Health monitoring method definition, 552 Health monitoring result, 553 Health verification result, 554 Configuration design information, 555 Configuration compliance status, 556 Capacity information, 557 Organization reliability, 558 Monitoring organization, S700 Member registration process, S800 SC deployment / execution process, S900 Health report process, S1000 Health mutual verification process, S1100 Configuration compliance status verification process, S1150 Action process, S1200 Reliability calculation process, S1300 Monitoring organization selection process, 1400 Health information provision screen

Claims

1. a distributed ledger node provided by each of a plurality of organizations; providing a distributed ledger network comprising the plurality of distributed ledger nodes; 1. A distributed ledger system, comprising: Execute smart contracts according to transactions received from outside, The smart contract comprises: Manage information in a distributed ledger while forming a consensus among the distributed ledger nodes of the plurality of organizations; receiving health monitoring results, which are information obtained by the first organization monitoring the health of the distributed ledger node of the second organization; Verifying the health of the distributed ledger node of the second organization by verifying the received health monitoring results; Recording a soundness verification result, which is a result of verifying the soundness, in the distributed ledger; Distributed ledger system.

2. The distributed ledger system of claim 1, The distributed ledger records configuration design information, which is information indicating the configuration of the distributed ledger nodes that should be prepared and provided by each of the organizations; The smart contract comprises: generating a configuration compliance status, which is information indicating a degree to which the organization complies with the configuration design information, by comparing and contrasting the soundness verification result of the second organization with the configuration design information of the second organization; Recording the generated configuration compliance status in the distributed ledger; Distributed ledger system.

3. The distributed ledger system according to claim 2, The smart contract determines whether the configuration compliance status of the second organization satisfies the configuration design information, and if not, records in the distributed ledger information instructing the second organization to review the configuration of the distributed ledger node, or information instructing the third organization to prepare a distributed ledger node on behalf of the second organization. Distributed ledger system.

4. The distributed ledger system according to claim 2, The smart contract determines whether the configuration compliance status of the second organization satisfies the configuration design information, and if not, records information in the distributed ledger indicating that a penalty will be imposed on the second organization due to a lack of configuration of the distributed ledger node. Distributed ledger system.

5. The distributed ledger system according to claim 2, The smart contract generates an organization trust level, which is a trust level of each of the multiple organizations, based on the configuration compliance status, and records the generated organization trust level of each of the multiple organizations in the distributed ledger. Distributed ledger system.

6. The distributed ledger system according to claim 2 or 5, The smart contract generates an organization trust level, which is a trust level of each of the multiple organizations, based on the health monitoring result of each of the multiple organizations, and records the generated organization trust level in the distributed ledger. Distributed ledger system.

7. The distributed ledger system of claim 1, A plurality of client nodes, each of which is owned by one of the plurality of organizations and communicatively connected to the distributed ledger node, The client node of the first organization: monitoring the health of the distributed ledger nodes of the second organization; generating the transaction including the health monitoring result obtained by the monitoring; Sending the generated transaction to the distributed ledger node; Distributed ledger system.

8. The distributed ledger system of claim 7, The distributed ledger records a health monitoring method definition, which is information indicating a monitoring method used when the organization monitors the health of the distributed ledger node of the second organization; the client node monitors the health of the second organization according to the monitoring method of the health monitoring method definition; Distributed ledger system.

9. The distributed ledger system of claim 7, The client node monitors the health by checking whether the distributed ledger node of the second organization is alive or dead using a service discovery function. Distributed ledger system.

10. The distributed ledger system of claim 1, The distributed ledger records a health monitoring method definition, which is information indicating a monitoring method used when the organization monitors the health of the distributed ledger node of the second organization; The smart contract selects a monitoring organization, which is the organization responsible for monitoring the distributed ledger nodes of each of the multiple organizations, based on at least one of an agreement condition of the smart contract, a soundness determination criterion included in the soundness monitoring method definition, and the soundness monitoring result, and records information indicating the selected monitoring organization in the distributed ledger. Distributed ledger system.

11. 7. The distributed ledger system of claim 6, The smart contract determines a monitoring organization that is the organization responsible for monitoring the distributed ledger nodes of each of the multiple organizations based on the organizational trust level, and records information indicating the determined monitoring organization in the distributed ledger. Distributed ledger system.

12. The distributed ledger system according to claim 2, The smart contract records information in the distributed ledger indicating a weighting when selecting a monitoring organization that is the organization responsible for monitoring the distributed ledger node of the second organization according to the configuration compliance status of the organization. Distributed ledger system.

13. a distributed ledger node provided by each of a plurality of organizations; providing a distributed ledger network comprising the plurality of distributed ledger nodes; Execute smart contracts according to transactions received from outside, The smart contract manages information in a distributed ledger while forming a consensus among the distributed ledger nodes of the multiple organizations. A method for controlling a distributed ledger system, comprising: The smart contract, receiving health monitoring results, the health monitoring results being information obtained by the first organization monitoring the health of the distributed ledger nodes of the second organization; verifying the health of the distributed ledger node of the second organization by verifying the received health monitoring results; and A step of recording a soundness verification result, which is a result of verifying the soundness, in the distributed ledger; A method for controlling a distributed ledger system.

14. A method for controlling a distributed ledger system according to claim 13, comprising: The distributed ledger records configuration design information, which is information indicating the configuration of the distributed ledger nodes to be prepared and provided by each of the organizations; and A step in which the smart contract generates a configuration compliance status, which is information indicating the degree to which the organization complies with the configuration design information, by comparing and contrasting the soundness verification result of the second organization with the configuration design information of the second organization, and records the generated configuration compliance status in the distributed ledger; The method for controlling a distributed ledger system further comprises:

15. A method for controlling a distributed ledger system according to claim 14, comprising: The smart contract determines whether the configuration compliance status of the second organization satisfies the configuration design information, and if not, records information instructing the second organization to review the configuration of the distributed ledger node in the distributed ledger; The method for controlling a distributed ledger system further comprises:

Images