Evidence management method, evidence management system and node

Abstract

To provide an evidence management method for controlling, in carrying out transparent and appropriate collection / totaling of evidences across organizations, timing to disclose an evidence between organizations in a non-centralized manner, an evidence management system, and nodes.SOLUTION: In a distributed ledger system 10 (evidence management system) including nodes of a plurality of organizations, a smart contract D11 of a distributed ledger node 3 of each of the organizations refers to information disclosed in a public area, the information being related to an evidence held in a private area of each of the plurality of organizations, and executes, when the information satisfies a predetermined condition, processing to disclose the evidence held in the private area of an organization, in the public area.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to an evidence management method, an evidence management system, and a node. [Background technology]

[0002] Distributed ledger technology has emerged as a technology that replaces transactions that have traditionally been conducted via trusted centralized institutions such as financial institutions and governments with direct transactions between users via P2P (Peer to Peer). For example, Non-Patent Document 1 discloses a technology for using virtual currency to perform settlement transactions without the need for a centralized institution such as a bank. In this virtual currency mechanism, after the validity of transaction data (hereinafter also referred to as a transaction) is judged by nodes called miners on a P2P network, confirmation processing is performed by a specific hash value calculation task called proof of work. Confirmed transactions are compiled into one block and recorded in a distributed ledger called a blockchain (hereinafter also referred to as BC).

[0003] In recent years, various derivative technologies related to BC and distributed ledgers have been proposed based on the BC implemented based on the technology in Non-Patent Document 1 above, and these technologies continue to evolve.

[0004] The main features of current BC include: (1) transactions between participants on a distributed ledger network are finalized through consensus and approval by (any or specific) participants rather than by a centralized authority; (2) multiple transactions are organized into blocks, recorded in a linked manner on the distributed ledger, and successive blocks are subjected to hash calculations, making tampering virtually impossible; and (3) all participants share the same ledger data, making it possible for all participants to confirm transactions.

[0005] Due to the above-mentioned characteristics of distributed ledger technologies, including BC, their application in a wide range of fields, such as finance and the Internet of Things (IoT), is being considered as a mechanism for managing and sharing reliable data and executing and managing transactions based on contracts.

[0006] By using a platform that provides a distributed ledger (hereinafter referred to as the distributed ledger platform), multiple entities can share information and conduct transactions without being managed by a central authority (for example, a consortium in a specific industry or multiple companies related to a supply chain).

[0007] Hereafter, the network composed of participants (and their nodes) participating in the distributed ledger will be referred to as the distributed ledger network.

[0008] In order to make distributed ledgers applicable to complex transaction conditions and a variety of applications, not just simple virtual currency transactions as described in Non-Patent Document 1, it has become possible to manage not only (transaction) data but also logic within the distributed ledger. This logic is called a smart contract (hereinafter also referred to as SC).

[0009] For example, Non-Patent Documents 2 and 3 disclose technologies related to distributed ledger platforms with such SC execution functions. In these distributed ledger platforms, transactions (hereinafter also referred to as TX) are accepted while forming a consensus among nodes at a predetermined consensus level, and information (ledger) is shared among multiple nodes by executing TX at each node.

[0010] In addition, smart contract (SC) execution executes predetermined logic for TX. It has functions.

[0011] Typical usage patterns of distributed ledger technology include the public type, in which an unspecified number of computing resources (nodes) form a distributed ledger network, such as BC based on the above-mentioned Non-Patent Document 1, as well as the permission-based type, in which a distributed ledger network is formed by nodes between specific companies / organizations, which is considered particularly promising for enterprises.

[0012] Multiple organizations participating in such a permissioned BC will be able to synchronize and link nodes based on a distributed consensus protocol, and automatically execute transactions in accordance with a pre-agreed and coded contract (SC).

[0013] In a system built using distributed ledger technology (hereinafter referred to as a distributed ledger system), one possible use case is to share evidence between organizations and compare / aggregate the evidence collected through this sharing. In order to ensure transparency regarding the handling of the information, an enterprise-type BC can be applied.

[0014] More specific use cases include comparing and aggregating information, i.e. evidence, from each participant regarding voting for governance purposes and reporting on system operation status, which is a form of operation management across organizations. In addition, it may also be used to compare and aggregate bidding information for auctions, real estate, construction, etc.

[0015] In these use cases, in order to ensure transparency regarding the management and processing of evidence, it is acceptable / desirable to ultimately disclose the evidence to each participant, but it is not acceptable / desirable to disclose the evidence at any intermediate stage before comparison or aggregation. It is not advisable to display it on the floor. [Prior art documents] [Non-patent literature]

[0016] [Non-Patent Document 1] “A Peer-to-Peer Electronic Cash System”, [online], [searched March 31, 2017], Internet<URL:https: / / bitcoin.org / bitcoin.pdf> [Patent documents]

[0017] [Patent Document 1] JP 2019-28525 A [Patent Document 2] Patent Publication No. 2021-64891 Summary of the Invention [Problem to be solved by the invention]

[0018] As a conventional technology for handling evidence, for example, a technology has been proposed that enables operational management with aligned policies and timing across nodes even in a situation where there are multiple administrators in a distributed ledger system (see Patent Document 1). This technology is a distributed ledger system composed of multiple nodes, in which at least a predetermined number of the multiple nodes each manages an operation smart contract for managing the operation of the distributed ledger system in a distributed ledger, and when at least one of the predetermined number of nodes receives a transaction, the node that received the transaction determines whether the type of the transaction is the operation smart contract or not, and executes the operation smart contract based on the result of the determination.

[0019] Also, a consortium blockchain system (see Patent Document 2) has been proposed that uses an encryption method that does not require pairing calculations.

[0020] This technology is a consortium blockchain system that includes a first computer that holds transaction data and a generation key for generating a zero-knowledge proof value, and a second computer that holds a verification key for verifying the zero-knowledge proof value, wherein the first computer uses the generation key to generate a zero-knowledge proof value based on the transaction data and transmits the generated zero-knowledge proof value to the second computer, and the second computer verifies the zero-knowledge proof value transmitted from the first computer using the verification key, receives the transaction data, and approves or rejects the transaction indicated by the transaction data based on a result of the verification of the zero-knowledge proof value.

[0021] The technology described in the above-mentioned Patent Document 1 discloses a means for collecting operational evidence from each organization using BC, but due to the nature of BC, the evidence is assumed to be made public to all organizations at all times.

[0022] In addition, in Patent Document 2, zero-knowledge proof, that is, a proposition that one has (confidential information) When proving that something (related to information) is true, one does so without conveying any knowledge other than that it is true. Although this technology is certainly useful, it is still in its infancy and is difficult to adopt as a practical solution.

[0023] As a function of Hyperledger Fabric, there is something called private data, and it is possible to store only the hash value of confidential information within a specific small group (such as the evidence mentioned above) in the BC. However, if the confidential information is only accessible to the individual, others cannot confirm its authenticity or the correctness of its handling, and it cannot be used as is for cross-organizational aggregation, etc.

[0024] Therefore, the object of the present invention is to collect and aggregate transparent and appropriate evidence across organizations. The objective of the present invention is to provide a technology that enables decentralized control of the timing of evidence disclosure between organizations. [Means for solving the problem]

[0025] The evidence management method of the present invention, which solves the above-mentioned problems, is characterized in that, in a distributed ledger system composed of nodes of multiple organizations, the smart contract of each organization references information published in a public domain regarding evidence held in the private domain of each of the multiple organizations, and, when the information satisfies a predetermined condition, executes a process to publish the evidence held in the private domain of its own organization to the public domain. Note that the above-mentioned private area refers to a state in which data can be held in a state in which it cannot be accessed by other organizations, and the public area refers to a state in which data can be held in a state in which it can be accessed by other organizations, and is not intended to refer only to a specific memory area secured by separating a data storage location or device. The evidence management system of the present invention is composed of nodes of multiple organizations. Evidence Management The system is characterized in that the smart contract of each organization references information published in a public domain regarding evidence held in the private domain of each of the multiple organizations, and, when the information satisfies a predetermined condition, executes a process to publish the evidence held in the private domain of its own organization in the public domain.

[0026] The node of the present invention is one of the nodes of multiple organizations that constitute a distributed ledger system, and refers to information published in the public domain regarding evidence held in the private domain of each of the multiple organizations, and when the information satisfies a predetermined condition, The present invention is characterized in that it holds a smart contract that executes a process to make the evidence held in the private area of ​​its own organization public in the public area. Effect of the Invention

[0027] According to the present invention, in the collection and aggregation of transparent and appropriate evidence across organizations, This makes it possible to control the timing of evidence disclosure between organizations in a decentralized manner. [Brief description of the drawings]

[0028] [Figure 1] FIG. 1 is a diagram illustrating an example of the configuration of a computer system according to an embodiment of the present invention. [Diagram 2] FIG. 2 is a block diagram showing an example of the physical configuration of a node in the present embodiment. [Diagram 3] FIG. 1 is a diagram illustrating an example of a data structure of a blockchain on a distributed ledger. [Figure 4] FIG. 13 is a diagram illustrating an example of the data structure of state information on a distributed ledger. [Figure 5A] FIG. 13 is a diagram showing an example of evidence held in a private area regarding an electronic ballot. [Figure 5B] FIG. 13 is a diagram showing an example of evidence held in a private area regarding an electronic ballot. [Figure 5C] FIG. 13 is a diagram showing an example of evidence information published in the public domain regarding electronic written ballots. [Figure 5D] FIG. 13 is a diagram showing an example of a tally result published in a public area regarding electronic open ballots. [Figure 6A] 13 is a diagram showing an example of an operational task definition stored in a public area regarding an operational execution history. FIG. [Figure 6B] 13 is a diagram illustrating an example of evidence stored in a private area regarding operation execution history. FIG. [Figure 6C] 13 is a diagram illustrating an example of evidence stored in a private area regarding operation execution history. FIG. [Figure 6D] 13 is a diagram showing an example of evidence information that is made public in a public domain regarding operation execution history. FIG. [Figure 6E] FIG. 13 is a diagram showing an example of a compilation result regarding operation execution history that is made public in a public area. [Figure 7] FIG. 2 is a diagram showing an example of a flow of an evidence management method in this embodiment. [Figure 8] FIG. 2 is a diagram showing an example of a flow of an evidence management method in this embodiment. [Figure 9] FIG. 2 is a diagram showing an example of a flow of an evidence management method in this embodiment. [Figure 10] FIG. 13 is a diagram illustrating an example of an evidence management smart contract of the present embodiment. [Figure 11] 1 is a diagram showing the concept of a Salt generation method according to an embodiment of the present invention; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0029] <Summary> Figure 1 shows an example of a configuration of a computer system in this embodiment, including a distributed ledger system 10 and an agent node 5. This embodiment is based on the premise that the distributed ledger system 10 needs to cooperate with the agent node 5. Furthermore, when this cooperation takes place, multiple connection paths between the distributed ledger system 10 and the agent node 5 are prepared so as not to depend on a single organization.

[0030] Furthermore, a method for automatically transferring evidence held in the private domain of each organization to the public domain, blockchain (hereinafter referred to as BC), depending on the status of evidence retention in multiple organizations regarding specified operations such as system operations, electronic voting, and bidding, is specified as an evidence management smart contract (hereinafter referred to as evidence management SC).

[0031] In addition, when an evidence management SC execution TX is issued as a request to start evidence disclosure to each distributed ledger node 3 that constitutes the distributed ledger system 10 together with the client node 4, the information disclosed in the BC, which is the public domain D111, regarding the evidence held in the private domain D112 of each organization's distributed ledger D1 is referenced via the distributed ledger system 10 in accordance with the evidence disclosure rules defined in this evidence management SC_D11, and when the information satisfies a specified condition, processing is executed to disclose the evidence held in the private domain D112 of the organization to the BC (public domain D111).

[0032] The process outline of this embodiment is as follows.

[0033] 1. Place the evidence management SC on the distributed ledger D1. The evidence management SC includes: A) a definition of the conditions for starting evidence disclosure, and B) a definition of the evidence aggregation processing method (e.g., aggregation logic).

[0034] 2. The Evidence Management SC refers to the information published in the public domain D111 (e.g., organization ID and the hash value of the combined evidence and salt obtained by the organization) regarding the evidence held in the private domain D112 of each organization's distributed ledger node 3, and when a condition is met, such as evidence information being published by a certain number of organizations, the SC issues an evidence publication start event to publish the evidence held in the private domain D112 of its own organization in the public domain D111.

[0035] 3. After the issuance of the above-mentioned publication start event, the evidence management SC either refuses to publish information about the evidence to the public area D111 or to update the information, or attaches information to the information regarding the timing of publication or update after the issuance of the publication start event.

[0036] 4. The Evidence Management SC performs evidence aggregation using the evidence of each organization that has been made public in the public domain D111.

[0037] 5. When the evidence release begins, the Evidence Management SC issues a provisional event to notify the start of evidence release.

[0038] 6. When the evidence is made public in the public domain D111 in each organization, and the status of the disclosure satisfies certain conditions, the evidence management SC issues a provisional event to start data processing.

[0039] The outline of the processing performed when cooperation is performed between the distributed ledger system 10 and the agent node 5 is as follows.

[0040] 1. When the smart contract issues an evidence publication start event as a process for publication, the agent node 5 receives this and publishes the evidence to the public area D111.

[0041] 2. When making the above disclosure, the agent node 5 uses a predetermined number of subgroups of organizations that are generated under predetermined conditions (for example, determined for each evidence management SC or for each count), executes the disclosure of evidence and data processing within the subgroup, and discloses the results of the data processing to other subgroups. Furthermore, the agent node 5 performs data processing using the counting results within the subgroup. This may be performed in multiple stages, or may be performed without subgroups (all organizations).

[0042] 3. When the smart contract issues a provisional event to start publishing evidence as a process for publishing evidence, such as when the number of organizations that have registered evidence information in the public area reaches a certain level, the agent node 5 receives the provisional event, reaches a consensus among the organizations, confirms the start of publishing the evidence, and issues a publishing start event.

[0043] 4. Similarly, when the smart contract issues a provisional event to start data processing in response to the situation of the disclosure satisfying a specified condition, such as the number of organizations that have published evidence in the public domain D111 reaching a certain level as a result of the disclosure of evidence by each organization, the agent node 5 receives the provisional event and performs data processing after reaching a consensus among the multiple organizations. <Network configuration example> Below, an example of the configuration of a computer system assumed in this embodiment will be described with reference to Fig. 1. The computer system shown in Fig. 1 is composed of one or more distributed ledger nodes 3, one or more client nodes 4, and an agent node 5. These devices are also connected to a network 1 via a physical communication line 2.

[0044] Of these, the distributed ledger node 3 is composed of a consensus management unit 31, a smart contract execution / management unit 32 (hereinafter also referred to as the SC execution / management unit 32), a member management unit 33, a transaction management unit 34, a transaction issuing unit 35, an approved transaction distribution unit 36, a network protocol unit 37, a distributed ledger D1, configuration information D2, and participating member management information D3.

[0045] Furthermore, the distributed ledger node 3 accepts the TX using the function of the transaction manager 34, and forms a consensus with other nodes as to whether the TX can be accepted using the function of the consensus manager 31. As a result, if a consensus is formed, the distributed ledger node 3 deploys the SC and executes the deployed SC via the function of the SC execution / management unit 32, and records the history of the TX and the results of its execution in the distributed ledger D1.

[0046] Here, consensus building and SC execution do not necessarily need to be performed by all distributed ledger nodes 3; they may be performed among some distributed ledger nodes and the results distributed to other nodes (this arrangement also depends on the consensus building algorithm).

[0047] Therefore, the approved transaction distribution unit 36 ​​provides a function to distribute the results (specifically, the TX history and execution results) to distributed ledger nodes 3 that did not participate in the above-mentioned consensus formation or SC execution.

[0048] Here, communication between the distributed ledger nodes 3, such as consensus building between the distributed ledger nodes 3 and distribution of approved TX, is performed by the functions of the network protocol unit 37.

[0049] In addition, the transaction management unit 34 of the distributed ledger node 3 provides a function / interface for accepting TX in response to requests from each node such as the client node 4, and a function / interface for acquiring and viewing TX history information.

[0050] In this embodiment, the distributed ledger node 3 (the transaction issuing unit 35 that receives an instruction from the evidence management SCD 11) and the client node 4 (the transaction issuing unit 42) are capable of issuing TX.

[0051] In addition, the member management unit 33 of the distributed ledger node 3 provides functions for issuing and authenticating new members who will participate in the distributed ledger network (distributed ledger system). It is assumed that a pair of private and public keys will be used to authenticate participating organizations and their members, sign TX, control SC execution authority, etc. Such key information related to member management is stored and managed in participating member management information D3.

[0052] In addition, when the transaction manager 34 receives a TX, it appropriately checks whether the issuer of the TX is a valid participant with authority via the function of the member manager 33. However, since such functions are publicly known technologies, detailed explanations are omitted.

[0053] The configuration information D2 stores and manages information on the organizations that make up the distributed ledger network and the members (including nodes, administrators, users, etc.) that belong to those organizations. In this embodiment, this information is managed within the functions of the distributed ledger node 3 (for example, the member management unit 33 and network protocol unit 37), and it can be assumed that each node holds the information.

[0054] Also, in the distributed ledger D1, ledger information related to the evidence management smart contract D11 is stored and managed. As for the data structure, in this embodiment, it is assumed that the history of TX is stored as BC, and state information based on the execution result of TX is stored in a table. It is assumed that the values ​​are stored as Key-Value pairs in the internal table.

[0055] However, ledger information related to the evidence management smart contract D11 is held and managed in one of two areas, a public area D111 and a private area D112, and the public area D111 corresponds to the BC. In this public area D111, information related to evidence in this embodiment (e.g., a hash value of a value combining evidence and Salt) is stored in association with the organization ID.

[0056] On the other hand, the private area D112 is a storage area for data that is securely managed by the organization that is the operator of the distributed ledger node 3. That is, it is an area in which the evidence itself in this embodiment is stored. The private area D112 can also be said to be held in a state where other organizations cannot refer to it, and there are various ways to realize it. And, if it is managed by each organization and can be made public via the evidence management smart contract D11, it may be outside the distributed ledger D1. For example, in the case of Hyperledger Fabric, it may be realized by using a private data function to require private data that can only be referred to by a single organization. Otherwise, it may be stored in a storage outside the distributed ledger D1 prepared for each organization. Alternatively, it may be encrypted once with a private key unknown to other organizations, stored in a public area, and later decrypted by disclosing the private key to other organizations.

[0057] On the other hand, the client node 4 is made up of a transaction issuing unit 42, a transaction generating unit 43, and a business application 41.

[0058] A user or provider of the evidence management smart contract D11 generates TX via the transaction generation unit 43 of the client node 4, issues it via the transaction issuing unit 42, and transmits it to the distributed ledger node 3. Note that issuer information is attached to the TX, and as this information, authentication information (private key) issued by the participating member management information D3 is used.

[0059] The TX issued by the client node 4 includes a hash value generated by applying a hash function to the random number for each organization generated by the salt generation unit 431 and the evidence held in the private area D112 of the organization, as well as the ID of the organization (see FIG. 11).

[0060] In addition, the business application 41 is an application that executes / manages business processing by issuing TX related to various businesses such as electronic voting and bidding, which are handled by the evidence management smart contract D11, via the transaction issuing unit 42.

[0061] In this embodiment, it is assumed that there are multiple distributed ledger nodes 3, each managed by a different organization (e.g., a different business operator or a different vendor). Similarly, it is assumed that there are multiple client nodes 4, each managed by a different user from a different organization.

[0062] Meanwhile, the agent node 5 receives various events (associated with TX) such as a publication start event issued by the evidence management smart contract D11 of the distributed ledger node 3 via the event receiving unit 511 of the agent program 51.

[0063] For example, upon receiving a publication start event issued by the evidence management smart contract D11, the agent program 51 of the agent node 5 automatically migrates the evidence in the affiliated organization to the public domain D111 and executes publication.

[0064] In addition, when making the above-mentioned disclosure, the agent program 51 of the agent node 5 uses a subgroup of a certain number of organizations including the affiliated organization to perform evidence disclosure and data processing within the subgroup, and discloses the results of the data processing to other subgroups.

[0065] In addition, the agent program 51 of the agent node 5 receives the provisional event of starting the disclosure of evidence issued by the evidence management smart contract D11, and after reaching a consensus among the organizations that make up the distributed ledger system 10, confirms the start of the disclosure of evidence and issues a disclosure start event.

[0066] Furthermore, the agent program 51 of the agent node 5 receives the provisional event of starting data processing related to evidence issued by the evidence management smart contract D11, and performs data processing of the evidence after reaching a consensus among the organizations that make up the distributed ledger system 10. The agent program 51 of the agent node 5 transmits the result of this data processing to the client node 4 or distributed ledger node 3 of the affiliated organization. The client node 4 or distributed ledger node 3 issues a TX including the result of this data processing, and stores it in the public domain D111 of the distributed ledger D1. <Hardware configuration> 2 is a block diagram showing the physical configuration of any one of the distributed ledger node 3, the client node 4, and the agent node 5 in this embodiment. Here, the distributed ledger node 3 will be taken as an example for explanation.

[0067] The distributed ledger node 3 is a computer including an interface (I / F) 100, a processor 101, and a memory 102. The I / F 100, the processor 101, and the memory 102 are connected by a data bus 103.

[0068] The distributed ledger node 3 communicates with the network 1 via the I / F 100. The processor 101 is a computing device such as a CPU. The memory 102 is a storage area for storing programs and data.

[0069] Moreover, the processor 101 reads out and executes a program from the memory 102 via the database 103, and implements necessary functions. These functions correspond to the above-mentioned consensus management unit 31 to network protocol unit 37 and the like. <Data configuration example> 3 and 4 are examples of data structures stored in the distributed ledger D1. Fig. 3 is an example of BC, which is one of the data structures managed on the distributed ledger D1.

[0070] In distributed ledger management using BC, multiple TXs are grouped together as blocks, and each block has the hash value of the previous block, so data is managed in a chain. If even one bit of the value of the previous block changes, the hash values ​​of all subsequent blocks change, making tampering difficult.

[0071] In this embodiment, for simplicity of explanation, one TX is stored in one block, but the present invention is also applicable to the case where multiple TXs are stored together in one block.

[0072] D1000 to D1006 in Fig. 3 are a series of blocks. Each block includes TX information of either deployment or execution of the evidence management SC_D11. Each block includes a hash value of the previous block and a hash value generated from state information described later.

[0073] With the above data structure, the deployment and execution TX history of evidence management SC_D11 is managed as a data chain in BC.

[0074] Among the above-mentioned blocks, D1000 is an example of a block that stores the deployment TX of the evidence management SC_D11. Such a deployment TX includes a timestamp when the TX was issued, an SC type that identifies the type of smart contract, an SC_ID that uniquely identifies the smart contract, a TX type that identifies whether the TX is deployed, executed, or referenced, and the entity of the smart contract (e.g., an executable binary). It also includes an SC input specification that allows the user to understand the function names and arguments of the smart contract.

[0075] Furthermore, it includes SC meta definitions, which are parameters determined according to the input arguments specified at the time of deployment (for example, the consensus formation conditions when executing the evidence management SC_D11 (for example, for normal SC functions, TX is accepted with the approval of three or more organizations, and for SC functions including writing to private areas, TX is accepted with the approval of one or more organizations) and various definition information, etc.).

[0076] In addition, such TX includes information about the issuer of the TX. The TX issuer information includes the issuer's member ID information and electronic signature information used to verify that the issuer and data have not been tampered with.

[0077] This electronic signature is generated using the private key of each network participating member (that is, evidence management SC provider or user) issued by the member management unit 33, and can be verified by its paired public key.

[0078] As well as information on the TX issuer, it also includes information on the TX executor / approver (in other words, information on the participants involved in consensus formation and SC execution processing using the consensus management unit 31 and the SC management / execution unit 32) and information on the approved TX distributor (in other words, information on the participants involved in the distribution processing by the approved TX distribution unit 36).

[0079] It also includes information on the Read-Write (RW) set, which is the state information referenced / updated by this TX.

[0080] On the other hand, D1004 in BC in FIG. 3 is an example of a block that stores the execution TX of the evidence management SC_D11. The execution TX of this embodiment is basically the same as the deployment TX. However, it does not have an SC entity or SC input specifications; instead, it contains the name of the SC function to be called and information on the input arguments.

[0081] In addition, the above-mentioned RW set indicates the state information that was referenced / updated when the evidence management SC_D11 (function) was deployed or executed, and includes the SC_ID, the "RW classification" that identifies whether it is a reference (Read) or an update (Write), and the key and value of the target state information.

[0082] In this way, by managing and storing the results of TX execution as a RW set, it is possible to grasp the results of the execution without executing SC. This makes it possible to share the results of SC execution with nodes that did not execute SC, making processing more efficient.

[0083] Next, Figure 4 shows an example of the configuration of state information managed on the distributed ledger D1. In distributed ledger management using BC, it is usually necessary to trace the BC to obtain the (latest) state (for example, the account balance in the case of virtual currency). Since this is inefficient, there is a method of caching the latest state information separately from the BC.

[0084] In this embodiment, it is assumed that the latest state information is stored. In this embodiment, a state data area is prepared for each evidence management SC_D11.

[0085] The state information holds the SC_ID and the actual state of that SC. This enables the SC execution / management unit 32 to obtain and execute the SC entity using the SC_ID as a key.

[0086] The state information also includes an internal table D1104 for holding the execution results of evidence management SC_D11. The contents of this internal table D1104 are updated every time TX is executed. Information on evidence management SC_D11 is also stored in this state information.

[0087] Here, if we look at the internal table D1104 of D1110, it corresponds to the RW set described in the explanation of Figure 3, and the latest state reflecting all of the RW sets is held. In a typical implementation example, data is held in key-value format like this, but it is also possible to use a format such as JavaScript Object Notation (JSON) for the value. You can store any structured data, which means you can have tables with any data schema.

[0088] Furthermore, by devising a clever key design, it is possible to virtually manage multiple tables (information with different schemas) within an internal table. To simplify the explanation, the internal table related to evidence management SC_D11 described below is a case in which structured data is stored in the value, and the description of the key-value-version and the like is omitted.

[0089] The example shown in Figure 4 shows an example in which an internal table D1104 holds information on evidence published in the public area D111 (BC), evidence held in the private area D112, and evidence aggregation results published in the public area D111 (BC).

[0090] Specific examples of the above-mentioned state information are shown in Figures 5A to 5D and 6A to 6E. Figure 5A is a diagram showing an example of evidence held in the private domain D112 in the distributed ledger node 3 of "organization 1," and Figure 5B is a diagram showing an example of evidence related to "organization 2."

[0091] In this example, the state information is managed as evidence, which is the result of an electronic open vote conducted by members of each organization on a topic common to each organization that makes up the distributed ledger system 10.

[0092] The data structure links values ​​such as the voting result (yes / no), which serves as evidence, Salt, and the evidence hash value, to a voting ID that uniquely identifies the voting case as a key. Of these, the Salt is generated by the Salt generation unit 431 of the client node 4, issued as a transaction including this, and held by the evidence management SC_D11. The evidence hash value is generated by applying a value obtained by combining the evidence with the Salt value to a hash function. The hash function is held by the evidence management SC_D11 so that it can be used.

[0093] 5C shows an example in which the voting results of each organization for the case "Vote 1" that is currently published in the public domain D111 of the distributed ledger D1 of the distributed ledger node 3 are used as evidence information. The structure of the evidence information is such that the voting ID that uniquely identifies the voting case is used as a key, and values ​​such as the organization ID indicating the organization that voted, the evidence hash value, the salt, and the evidence are linked to the voting ID.

[0094] However, before evidence disclosure begins, neither of these values, Salt nor Evidence, are stored in the state information of this public domain D111. The example in Fig. 5C shows a state in which, after evidence disclosure begins, automatic migration from the private domain D112 to the public domain D111 has been completed for the evidence of "Organization 1" for "Vote 1." In other words, at this point in time, automatic migration to the public domain D111 has not yet been completed for the evidence of "Organization 2" and "Organization 3."

[0095] Moreover, Fig. 5D shows an example of the result of tallying up the values ​​of evidence automatically transferred to the above-mentioned public area D111. In the example of Fig. 5D, the case of "Vote 1" has "For: 10, Against: 3, Abstain: 2," indicating a state in which it has been determined that it has "passed" by a majority vote in favor, and the case of "Vote 2" has "For: 3, Against: 7, Abstain: 2, Not Voted: 3," indicating a state in which it has been determined that it has "rejected" by a majority vote against.

[0096] Fig. 6A shows an example of a definition of the system operation work performed by an organization, i.e., an operation work definition. The data structure is such that an operation ID that uniquely identifies the operation type is used as a key, and values ​​such as the operation (contents) and operation command are linked to the operation ID.

[0097] FIG. 6B is a diagram showing an example of evidence held in the private domain D112 in the distributed ledger node 3 of “Organization 1,” and FIG. 6C is a diagram showing an example of evidence related to “Organization 2.”

[0098] This data structure is an example in which evidence as a history of system operation work performed in the organization is used as state information, and values ​​such as an operation execution ID that uniquely indicates the history of the operation work, evidence, Salt, and evidence hash value are linked to the above-mentioned operation ID as a key. The evidence here includes values ​​such as the execution results of operation work such as data backup, and the execution log.

[0099] The Salt is generated by the Salt generation unit 431 of the client node 4, issued as a transaction including the Salt, and held by the evidence management SC_D11. The evidence hash value is generated by applying a value obtained by combining the evidence with the Salt value to a hash function. The hash function is held by the evidence management SC_D11 so that it can be used.

[0100] 6D shows an example in which evidence information is the operation performance of each organization for the case of "Operation 1" currently published in the public domain D111 of the distributed ledger D1 of the distributed ledger node 3. The configuration is such that an operation ID that uniquely identifies the operation type is used as a key, and values ​​such as an operation execution ID, organization ID, evidence hash value, Salt, and evidence are linked to it.

[0101] However, before evidence disclosure begins, neither of these values, Salt nor Evidence, are stored in the state information of this public domain D111. The example in Fig. 6D shows a state in which, after evidence disclosure begins, automatic migration from the private domain D112 to the public domain D111 has been completed for evidence of "Organization 1" for "Operation 1." In other words, at this point in time, automatic migration to the public domain D111 has not yet been completed for evidence of "Organization 2" and "Organization 3."

[0102] Moreover, Fig. 6E shows an example of the result of tallying up the values ​​of evidence automatically migrated to the above-mentioned public domain D111. The example in Fig. 6E shows a state in which the case of operation execution ID "1" in "operation 1" has been judged as "failed" because "organization 2 failed," and a state in which the case of operation execution ID "2" in "operation 2" has been judged as "successful" because "all organizations were successful and the results of all organizations matched."

[0103] Although not shown in the figure, an example of the data structure of the configuration information D2 will be described below. This configuration information D2 stores information on the organizations that make up the distributed ledger network and the members that belong to those organizations (including the distributed ledger nodes 3, clients 4, agent nodes 5, administrators, users, etc.). The data structure is composed of the values ​​of the business D2000, organization ID_D2001, and member ID_D2002.

[0104] Among these, business D2000 is a group that performs specific operations (such as system operation and electronic voting) in the distributed ledger network. Organization ID_D2001 indicates an organization participating in the distributed ledger network. Furthermore, member ID_D2002 is information that identifies members of participating organizations. Specifically, it is information that identifies administrators, distributed ledger nodes 3, client nodes 4, agent nodes 5, and users. Note that an organization does not necessarily need to have a distributed ledger node 3, and may simply use the distributed ledger system 10 via a client node 4. <Member Registration> The actual procedure of the evidence management method in this embodiment will be described below with reference to the drawings. The various operations corresponding to the evidence management method described below are realized by a program that is read into memory and executed by the nodes (distributed ledger node 3, client node 4) and agent node 5 that make up the evidence management system 10. This program is composed of codes for performing the various operations described below.

[0105] The following describes the process flow in this embodiment. Figure 7 is a flow diagram showing an example of a new registration process for a member participating in a distributed ledger network.

[0106] In this case, the member management unit 33 of the distributed ledger node 3 receives a member registration request from another node such as the client node 4 (S101). Here, the above-mentioned member registration request includes a member ID that uniquely identifies the requesting member.

[0107] Next, the member management unit 33 generates a pair of a private key D31 and a public key D32 by a known general method, and associates this with the member ID accepted in S101 (S102).

[0108] Next, the member manager 33 broadcasts the member ID to be newly registered and the public key D32 generated in S102 to other nodes (S103).

[0109] The broadcasted member ID and public key D32 information is stored as participating member management information D3 on each node.

[0110] Furthermore, the member management unit 33 returns the private key D31 generated in S102 to the node that made the member registration request (S104). The node that received this private key D31 stores it in the participating member management information D3 as its own private key D31.

[0111] In this embodiment, it is assumed that the pair of private key and public key generated as described above will be used to authenticate network participants, sign TX, control execution authority of evidence management SC_D11, and so on.

[0112] Specifically, for example, the client node 4 or the agent node 5 issues a TX digitally signed with the issued private key, and a verification node such as the distributed ledger node 3 verifies the digital signature using the public key, thereby realizing identity verification.

[0113] It should be noted that the method for generating a pair of a public key and a private key, the method for verifying a signature, and the method for linking a key and an ID may be any publicly known or well-known technology, and therefore will not be described in detail in the first embodiment.

[0114] In addition, in this embodiment, the functions of the member management unit 33 are shown as functions within the distributed ledger node 3, but it is also possible to set up an external node dedicated to member management and have that node provide functions equivalent to the member management unit 33. <Transaction processing> 8 is a flow diagram showing an example of TX execution processing, that is, deployment and execution processing of evidence management SC_D11. Here, the transaction manager 34 of the distributed ledger node 3 receives a TX from a TX issuer such as a client node 4 (S201). Then, this TX is passed to the consensus manager 31, and deployment and execution processing of evidence management SC_D11 is performed according to the type of the TX.

[0115] A case where the above-mentioned TX received by the consensus management unit 31 is the deploy TX of the evidence management SC_D11 (the judgment in S202 is "YES") will be described. In this case, the consensus management unit 31 first performs a consensus building process with other distributed ledger nodes 3 as to whether the received TX can be executed or whether it can be added to the end of the BC as a block (S203). As a specific consensus building process method, a publicly known or well-known technology may be applied.

[0116] For example, Practical Byzantine Fault Tolerance ( It is possible to adopt an algorithm called PBFT (Primary Block Chaining) which requires a certain number of nodes (two-thirds) to agree on the consensus among all nodes participating in the consensus process (i.e., verification nodes).

[0117] As another example, see the literature ("Hyperledger Fabric", [online e], [Retrieved March 31, 2017], Internet<URL:http: / / hyperledger-fabric.readthedocs.io / en / latest / > In the distributed ledger system described in ), a consensus algorithm called the Endorser-Orderer model is used. In the Endorser-Orderer model, a portion of the distributed ledger nodes 3 with approval authority are selected from the distributed ledger nodes 3 and send TX. The transaction is then sent to the selected distributed ledger nodes, who then verify that there are no problems and return a confirmation if there are no problems.

[0118] If a predetermined consensus condition (e.g., approval by two or more organizations) is met, the TX is accepted. Furthermore, the approved TX is distributed to all distributed ledger nodes 3. In the Endorser-Orderer model, all distributed ledger nodes 3 do not need to verify the TX, making it more efficient than PBFT.

[0119] Here, we will briefly explain the flow after consensus formation based on the Endorser-Orderer model. The distributed ledger node 3 sends the received TX to the distributed ledger node 3 that is participating in the distributed ledger network and has the authority to approve the TX.

[0120] Meanwhile, each distributed ledger node 3 that receives this TX verifies the signature on the TX to ensure that it has not been tampered with and that the contents of the TX are valid.

[0121] The distributed ledger node 3 returns the confirmation result to the distributed ledger node 3 that sent the above-mentioned TX. If the predetermined consensus formation conditions are met, the TX is considered approved, and the consensus formation is completed when the confirmation is completed.

[0122] The consensus management unit 31 broadcasts the approved TX to all distributed ledger nodes 3 using the function of the approved TX distribution unit 36.

[0123] The consensus management unit 31, which has received this approved TX, registers the evidence management SC_D11 included in the TX in the distributed ledger D1 via the SC execution / management unit 32 (S204). Specifically, based on the contents of the TX, the SC_ID and the SC entity are registered as state information on the distributed ledger D1, and a block including this deployed TX is added to the end of the BC.

[0124] Finally, the consensus manager 31 returns the execution result of the deploy TX to the TX issuer (S205).

[0125] The case where the received TX is an execution TX of the evidence management SC_D11 (the judgment in S202 is "NO") will be described. In this case, the consensus formation process is performed in the same way as the deployment TX (S206). This consensus formation process is the same as S207.

[0126] When the above-mentioned consensus formation is completed, the consensus management unit 31 executes the evidence management SC_D11 via the SC execution / management unit 32 to update the contents of the distributed ledger D1 (S207). Specifically, the call function and input arguments specified in the execution TX are given to the evidence management SC_D11 (which is assumed to have already been registered) having the SC_ID specified in the execution TX, and executed.

[0127] Then, the consensus management unit 31 updates the contents of the distributed ledger D1 based on the execution result. Based on the execution result, the consensus management unit 31 updates the state information D12 related to this evidence management SC_D11 and adds the execution TX as the last block of the BC. Finally, the consensus management unit 31 returns the execution result of this execution TX (for example, the return value of the function) to the TX issuer (S209). <Evidence Management SC Flow> Fig. 9 is a flow diagram showing an example of processing in the evidence management SC_D11, and Fig. 10 is a diagram showing the internal configuration of the evidence management SC_D11. In this case, when each distributed ledger node 3 receives a call for the SC function "evidence registration" of the evidence management SC_D12 by an execution TX issued by the client node 4 (S301), for example, the SC execution / management unit The function of 32 executes the evidence registration process in accordance with this execution TX.

[0128] Next, the evidence management SC_D11 of each distributed ledger node 3 stores the evidence and Salt contained in the TX broadcast from the transaction issuer 42 of the client node 4 in the private area D112 of the distributed ledger D1 (S302).

[0129] The processes of generating TX in the transaction generating unit 43 and issuing TX in the transaction issuing unit 42 in the client node 4 are as already explained (FIG. 11).

[0130] Furthermore, the evidence management SC_D11 of the distributed ledger node 3 inputs the evidence and salt obtained in S302 together into a hash function to generate a hash function, and publishes this as an evidence hash value in the public domain D111 (S303). At this time, the evidence hash value is associated with the organization ID and the ID of the target event (voting ID, operation ID, etc.) and stored in the state information.

[0131] By executing the above-mentioned S301 to S303 in the distributed ledger node 3 of each organization, records including evidence hash values ​​made public by each organization are accumulated in the public domain D111 of the distributed ledger D1.

[0132] The evidence management SC_D11 of the distributed ledger node 3 refers to the information published in the public area D111 of the distributed ledger D1 and determines, for example, whether evidence hash values ​​(information related to evidence) have been published by a certain number of organizations or more (S304).

[0133] If it is found as a result of the above-mentioned judgment that the evidence hash value has been made public by a certain number of organizations or more (S304: Yes), the evidence management SC_D11 issues an evidence publication start event (S305). The event issued by the SC event is embedded in a BC, and the distributed ledger node 3 that received the BC notifies the agent node 5 of the organization.

[0134] Note that after the publication start event of S305 is issued, the evidence management SC_D11 shall refuse even if it receives a request to publish information about evidence (e.g., evidence hash value) to the public domain D111 or a request to update the information from the client node 4. Alternatively, the evidence management SC_D11 may assign information about the timing of publication or update after the publication start event is issued to the information such as the evidence hash value, making it possible to verify it later.

[0135] Meanwhile, the agent program 51 of the agent node 5 receives the above-mentioned publication start event at the event receiving unit 511, and migrates the evidence held in the private area D112 of the distributed ledger D1 of the organization to the public area D111, i.e., executes publication (S306).

[0136] It is preferable that the agent node 5 discloses the evidence in the above-mentioned S306 within a subgroup of a certain number of organizations including its own organization. In this case, data processing such as aggregation of the disclosed evidence is also performed for the subgroup, and the results of the data processing are disclosed to other subgroups.

[0137] The evidence management SC_D11 executes a predetermined data processing using the evidence of each organization that is published in the public domain D111 (S307).

[0138] Examples of this data processing include, but are not limited to, tallying up the results of an electronic ballot when the evidence is the results, and determining whether or not a system operation task has been performed and whether or not it has been successful across the entire organization.

[0139] The evidence management SC_D11 issues TX regarding the result of the above-mentioned data processing through the transaction issuing unit 35 and broadcasts it to the distributed ledger node 3 of each organization (S308). The evidence management SC_D11 of the distributed ledger node 3 stores the received data processing result in the state information as an evidence aggregation result (S309).

[0140] In addition, when processing data in S307 described above, the evidence management SC_D11 generates a hash value of the evidence and Salt stored in the private area D112, and proceeds with the process after confirming that this hash value matches the evidence hash value published in the public area D111. Through this confirmation, it is possible to perform aggregation, etc., while ensuring that no fraudulent acts such as tampering with the evidence have been performed. <Other examples> In addition, the evidence management SC_D11 may issue a provisional event for starting evidence disclosure when disclosing evidence in the public domain D111.

[0141] In this case, the agent program 51 of the agent node 5 receives the above-mentioned provisional event and requests the client node 4 or the distributed ledger node 3 of its own organization to issue a TX inquiring about the authenticity of the provisional event, thereby forming a consensus between the organizations.

[0142] When the start of the publication of evidence is thereby determined, the evidence management SC_D11 can issue a publication start event.

[0143] In addition, when the evidence management SC_D11 receives evidence from each organization and the disclosure status satisfies a predetermined condition, such as when a certain number of organizations have disclosed evidence, the transaction issuing unit 35 issues a provisional event regarding the start of data processing.

[0144] In this case, upon receiving the provisional event related to the above-mentioned data processing, the agent node 5 requests the client node 4 or the distributed ledger node 3 of its own organization to issue a TX inquiring about the authenticity of the provisional event, thereby forming a consensus between the organizations.

[0145] When the data processing of the evidence is thereby determined, the evidence management SC_D11 can execute the data processing.

[0146] Although the embodiments of the present invention have been described in detail above with reference to the drawings, the specific configuration is not limited to these embodiments, and designs that do not deviate from the gist of the present invention are also included.

[0147] According to this embodiment, transparent and appropriate evidence can be collected / aggregated across organizations. This makes it possible to decentralize control over the timing of evidence disclosure between organizations.

[0148] The description of this specification makes at least the following clear: That is, in the evidence management method of the present embodiment, the smart contract may execute a predetermined data processing by using the evidence published in the public domain.

[0149] This makes it possible to efficiently process data such as the presence / absence / success of device operation and electronic voting in each organization. In addition, in the collection / collection of transparent and appropriate evidence across organizations, the timing of evidence disclosure between organizations can be controlled in a decentralized manner. It becomes possible to control it easily.

[0150] In addition, in the evidence management method of this embodiment, the smart contract, in the data processing, calculates a calculated value obtained by a certain calculation procedure based on the evidence stored in the private area and the information published in the public area. Alternatively, it may be possible to confirm that the calculated value based on the information matches the actual value.

[0151] This makes it possible to confirm and guarantee that values ​​have not been tampered with between the public and private domains, i.e., the authenticity of evidence. Furthermore, in the transparent and appropriate collection / aggregation of evidence across organizations, the timing of evidence disclosure between organizations can be improved. It is possible to control the above in a decentralized manner. The calculated value obtained by the above-mentioned certain calculation procedure can be, for example, a hash value.

[0152] In the evidence management method of the present embodiment, when the smart contract holds the evidence in a private area, the evidence may be managed in a state in which the evidence is combined with a unique value for each organization. Note that the unique value may be, for example, a random number.

[0153] This makes it difficult to infer the original evidence from its hash value, even if the data size of the evidence is small or the value itself is simple. This will ultimately facilitate disclosure of evidence between organizations in the collection and aggregation of transparent and appropriate evidence across organizations. Timing can be controlled decentralized.

[0154] In addition, in the evidence management method of this embodiment, the smart contract may issue a publication start event for the evidence as a process for the publication, and the agent nodes of the multiple organizations may receive the publication start event and publish the evidence to the public area.

[0155] This makes it possible to accurately and smoothly disclose evidence to the private sphere, even when the number of organizations involved is large. In addition, in the collection and aggregation of evidence across organizations in a transparent and appropriate manner, the timing of evidence disclosure between organizations can be determined in a decentralized manner. It becomes possible to control it effectively.

[0156] Furthermore, in the evidence management method of this embodiment, in a subgroup generated by a smart contract or a predetermined rule in advance, the disclosure and the data processing may be executed within the subgroup at the time of disclosure, and the result of the data processing may be disclosed to other subgroups. In this way, the data is first compiled within the subgroup, and the result is disclosed to others, making it possible to limit the scope of disclosure of evidence to the subgroup. In addition, in the collection / collection of transparent and appropriate evidence across organizations, The timing of evidence disclosure can be controlled in a decentralized manner.

[0157] In addition, in the evidence management method of this embodiment, the smart contract may, after the issuance of the publication start event, refuse to publish the information regarding the evidence to the public area or to update the information, or may attach information to the information regarding the timing of publication or update after the issuance of the publication start event.

[0158] This makes it possible to prevent evidence from being tampered with after it has been made public. In turn, this will facilitate disclosure of evidence between organizations in the collection and aggregation of evidence in a transparent and appropriate manner across organizations. The timing of this can be controlled decentralized.

[0159] Furthermore, in the evidence management method of this embodiment, the smart contract may issue a provisional event to start publishing evidence in response to the trigger as a process for making the evidence public, and the agent node may receive the provisional event, reach a consensus among the multiple organizations, confirm the start of publishing the evidence, and issue the publication start event.

[0160] This makes it possible to avoid situations where, for example, an organization wants to view evidence from another organization and issues a disclosure start event even in a situation where the conditions for disclosure start are not met, causing the evidence to be made public. It becomes possible to control it effectively.

[0161] Furthermore, in the evidence management method of this embodiment, when the evidence is made public in the public domain in each of the multiple organizations and the status of the publication satisfies a predetermined condition, the smart contract may issue a provisional event regarding the start of the data processing, and an agent node of a predetermined organization may receive the provisional event and perform the data processing after reaching a consensus among the multiple organizations.

[0162] This makes it possible to prevent situations where, for example, an organization wants to check the aggregated values ​​of evidence and processes data arbitrarily. In addition, in the collection / aggregation of evidence in a transparent and appropriate manner across organizations, the timing of evidence disclosure between organizations can be adjusted. It can be controlled decentralized. [Explanation of symbols]

[0163] 1 Network 2. Physical communication lines 3 Distributed Ledger Nodes 10 Distributed ledger system (evidence management system) 100 Interfaces 101 Processor 102 Memory 103 Data Bus 31 Consensus Management Department 32 Smart Contract Execution / Management Department (SC Execution / Management Department) 33 Member Management Department 34 Transaction Management Unit 35 Transaction Issuer 36 Approved Transaction Distribution Unit 37 Network Protocol Section 4 Client Nodes 41 Business Applications 42 Transaction Issuer 43 Transaction Generation Unit 431 Salt generation part 5 Agent Node 51 Agent Program 511 Event receiver D1 Distributed Ledger D11 Evidence Management Smart Contract D111 Public Area D112 Private Area D2 configuration information D3 Participant Management Information

Claims

1. In a distributed ledger system consisting of nodes from multiple organizations, the smart contracts of each organization are With regard to evidence held in a private area of ​​each of the multiple organizations, information published in a public area is referenced, and when the information satisfies a predetermined condition, a process is executed to publish the evidence held in the private area of ​​the organization in question in the public area.

13. An evidence management method comprising:

2. The smart contract comprises: Executing a predetermined data processing using the evidence published in the public domain.

2. The method of claim 1, wherein the method comprises:

3. The smart contract comprises: In the data processing, confirming that a calculated value obtained by a certain calculation procedure based on the evidence held in the private area matches a calculated value contained in the information published in the public area or based on the information; 3. The method of claim 2, wherein the evidence is managed by a computer.

4. The smart contract comprises: When the evidence is stored in a private area, the evidence is managed in a state where the evidence is combined with a unique value for each organization.

2. The method of claim 1, wherein the method comprises:

5. The smart contract comprises: As a process for making the evidence public, a publication start event is issued for the evidence; The agent nodes of the multiple organizations include: In response to the publication start event, the evidence is published to the public domain.

3. The method of claim 2, wherein the evidence is managed by a computer.

6. In the smart contract or a subgroup generated in advance according to a predetermined rule, When making the disclosure, the disclosure and the data processing are performed within the subgroup, and the results of the data processing are made public to other subgroups.

6. The method of claim 5, wherein the method comprises:

7. The smart contract comprises: After the publication start event is issued, refusing to publish the information on the evidence to the public domain or to update the information, or adding information on the timing of publication or update after the publication start event is issued to the information.

6. The method of claim 5, wherein the method comprises:

8. The smart contract comprises: As a process for disclosing, a provisional event for starting disclosure of evidence is issued in response to the trigger; The agent node: In response to the provisional event, a consensus is reached among the multiple organizations, the start of publication of the evidence is finalized, and the publication start event is issued.

6. The method of claim 5, wherein the method comprises:

9. The smart contract comprises: When the evidence is published to the public domain in each of the plurality of organizations and a status of the publication satisfies a predetermined condition, a provisional event is issued regarding the start of the data processing; The agent node of a given organization receiving the hypothetical event, forming a consensus among the multiple organizations, and then performing the data processing; 6. The method of claim 5, wherein the method comprises:

10. An evidence management system composed of nodes of multiple organizations, The smart contract of each organization refers to information published in a public domain regarding evidence held in a private domain of each of the multiple organizations, and executes a process for publishing the evidence held in the private domain of the organization in the public domain when the information satisfies a predetermined condition.

1. An evidence management system comprising:

11. A node of multiple organizations that constitutes a distributed ledger system, The system holds a smart contract that refers to information published in a public domain regarding evidence held in a private domain of each of the multiple organizations, and executes a process to publish the evidence held in the private domain of the organization in the public domain when the information satisfies a predetermined condition. A node characterized by:

Images