JP7171469B2 - CONFIGURATION CHANGE MANAGEMENT METHOD, CONFIGURATION CHANGE MANAGEMENT SYSTEM, AND NODES - Google Patents

Description

The present invention relates to a configuration change management method, a configuration change management system, and a node.

Distributed ledger technology is a technology that replaces transactions between related parties, which have conventionally been conducted via centralized institutions such as financial institutions and governments, with direct transactions by P2P (Peer to Peer) between related parties. (The so-called Blockchain (BC: Blockchain) is utilized. As an example of the technology, one related to Bitcoin, which is a type of virtual currency, has been proposed (see Non-Patent Document 1).

Distributed ledger technology has applications in a wide range of fields, including the financial sector and IoT (Internet of Things), as a mechanism for decentralized management and sharing of reliable data and the execution and management of transactions based on contracts. being considered.

For example, in the virtual currency using the technology described in Non-Patent Document 1, transaction data (hereinafter also referred to as transaction or TX) on the P2P network is verified by a node called a miner, and then proof of work is performed. Confirmation processing is performed by calculating a specific hash value called. Transactions that have been finalized here are grouped into one block and recorded in a distributed ledger in the form of a blockchain.

Distributed ledger technology can be categorized into several types depending on its configuration. The classification is as follows: "Public distributed ledger", in which a distributed ledger network is constructed among an unspecified number of nodes; A “consortium distributed ledger” in which a network is configured, and a “private distributed ledger” in which a distributed ledger network is configured between nodes within a specific organization.

In particular, the consortium-type distributed ledger, which has been proposed for enterprise use, is expected to streamline business processes across organizations.

In recent years, based on the BC implemented in the virtual currency using the technology described in Non-Patent Document 1 above, various derivative technologies have been proposed for BC and distributed ledger, and they continue to evolve.

The main features of current BC are: (1) In transactions between participants on the BC network, transactions are finalized by consensus building and approval by (arbitrary or specific) participants rather than by a centralized authority, ( 2) Multiple transactions are grouped into blocks, recorded in a daisy chain on a distributed ledger, and tampering is virtually impossible by performing hash calculations on consecutive blocks. (3) All participants share the same distributed ledger. to enable all participants to confirm the transaction by sharing the information.

In addition, in order to make the distributed ledger technology applicable not only to virtual currency transactions as in Non-Patent Document 1, but also to complex transaction conditions and various applications, not only (transaction) data in the distributed ledger Logic is becoming manageable. This logic is called a smart contract (SC).

In a BC-introduced system (hereinafter referred to as a BC system), a plurality of participating organizations bring together resources, which are managed individually, and constitute one system as a whole. Therefore, there is no participating organization that understands the entire system.

For BC systems with such structural characteristics, changes in the BC system configuration occur for the purpose of adding or leaving participating organizations to the BC network, adding new smart contracts that operate on BC, or updating them. do.

Here, configuration change of the BC system is defined as changing setting items related to the BC system. Specifically, configuration change of the BC system is realized by updating setting information related to management of the BC system in accordance with the change purpose and applying the setting to the system.

If the configuration change of the BC system as described above is not properly performed, there is a possibility that a failure/abnormality such as a system error or system stop occurs after the configuration change. In order to prevent this, it is generally conceivable to use a method of confirming in advance the content of the change and the effect on other setting items in response to a configuration change request.

Therefore, as a conventional technology for confirming the range of influence at the time of configuration change, for example, a network configuration change evaluation program that causes a computer to perform an evaluation of the impact of a network configuration change, and includes topology information representing the topology of the network before the configuration change. and device setting change information that is information on setting changes of devices in the network; and based on the topology information and the device setting change information obtained by the configuration change information obtaining step, A network configuration change evaluation program (see Japanese Patent Laid-Open No. 2002-100000) and the like have been proposed that cause a computer to execute an influence range extracting step of extracting information on services affected by the configuration change.

JP 2007-243855 A

"A Peer-to-Peer Electronic Cash System", [online], [searched on February 27, 2018], Internet <URL: https://bitcoin. org/bitcoin. pdf>

In the prior art described above, the effects of configuration changes are evaluated in advance, but it is based on the premise that a single management organization can manage and view network topology information. However, in the BC system, the setting information and its management structure are hierarchized and group-structured.

If we define the constituent unit as the scope of management, the organization with management authority is different for each scope of management, so as mentioned above, no one is aware of the overall picture of management. Furthermore, in the configuration change of the BC system, it is often the case that the setting change part spans multiple management ranges, and it is necessary for the administrator of the organization between the multiple management ranges to coordinate when the configuration is changed.

Based on the above, confirmation of the extent of influence using the conventional technology described above can only be performed within the authority of one organization, and cannot be applied to a BC system managed by multiple organizations. In addition, even if this is shared and confirmed by a plurality of organizations, since there is no organization that recognizes and appropriately allocates all the points that should be checked by each organization, the points that each organization should check are unclear. Therefore, there arises a problem that confirmation omissions and excessive duplication may occur.
SUMMARY OF THE INVENTION Accordingly, it is an object of the present invention to provide a technique for performing efficient and accurate confirmation of the entire system within the authority of each organization when the configuration of the BC system is changed.

A configuration change management method of the present invention for solving the above problems is a block chain system in which a plurality of organizations participate. , using a predefined impact determination rule, extracting the impact confirmation items based on the configuration information of the organization to which the node belongs, the configuration change request, the impact confirmation items, and the impact confirmation items for each organization At least one of the approval results by the administrator of the node regarding the do.

In addition, the configuration change management system of the present invention is a blockchain system in which a plurality of organizations participate, and each node of the plurality of organizations that constitutes the blockchain system receives a configuration change request to the blockchain system. , using a predefined impact determination rule, extracting the impact confirmation items based on the configuration information of the organization to which the node belongs, and regarding the configuration change request, the impact confirmation items, and the impact confirmation items for each organization At least one of the approval result by the administrator of the node is shared between nodes using a smart contract and recursive processing is performed to extract the impact confirmation items to be confirmed as the entire blockchain system. It is characterized by being a thing.

In addition, the node of the present invention is each node of a plurality of organizations that constitute a blockchain system in which a plurality of organizations have participated, and has a predefined impact determination rule for a configuration change request to the blockchain system. , extracting the impact confirmation items based on the configuration information of the organization to which the node belongs , and obtaining approval results from the administrator of the node regarding the configuration change request, the impact confirmation items, and the impact confirmation items for each organization. At least one of them is shared between nodes using a smart contract and recursive processing is performed, and an impact check item to be checked as a whole blockchain system is extracted. .

According to the present invention, when changing the configuration of the BC system, it is possible to perform efficient and accurate confirmation of the system as a whole within the authority of each organization.

FIG. 2 is a diagram illustrating an overview of processing in a BC system in Embodiment 1; FIG. 4 is a diagram illustrating an example of functions provided in each node in Embodiment 1; FIG. 2 is a diagram showing an example of a management structure of a BC system in Example 1; FIG. 4 is a table showing setting items in the management range in the first embodiment; 4 is a table representing configuration change requests in Example 1. FIG. 4 is a table showing influence determination rules in Example 1. FIG. 4 is a table showing influence confirmation items in Example 1. FIG. 4 is a table showing configuration confirmation requests in Example 1. FIG. 4 is a table showing a check item list in Example 1. FIG. FIG. 10 is a flow when a configuration change is performed in the entire system according to the first embodiment; FIG. FIG. 10 is a diagram showing a confirmation screen in Example 1; FIG. 10 is a flow when performing check item extraction processing in each node in the first embodiment; FIG. 10 is a table showing influence determination rules in Example 2. FIG. 10 is a table showing a check item list in Example 2. FIG. FIG. 11 is a flow when performing check item extraction processing in the second embodiment; FIG.

[Example 1]
--- Overview of the system ---

FIG. 1 is a diagram for explaining a processing concept in a block chain system 1 (hereinafter referred to as a BC system) as a configuration change management system according to the first embodiment. In this embodiment, for simplification of explanation, an organization such as a company operates one node in the BC system 1, and a one-to-one correspondence between the organization and the node is exemplified. However, in reality, this is not the case, and a configuration in which one organization operates multiple nodes is also conceivable.

For example, when the node 100, which is one of the nodes that configure the BC system 1, receives a configuration change request T10 as an input from another node operated by a predetermined organization, the check item extraction unit 110 extracts , acquires the setting items of the management range for which the own node has management authority, and outputs the influence confirmation item T30 that can be influenced by the configuration change request T10. The impact confirmation item T30 is added to the confirmation item list T160 of the node 100. FIG.

In addition, the node 100 determines the control range (eg, the entire consortium, the business group, each hierarchy such as a smart contract, each group, etc.) that holds the setting item for each of the output impact confirmation items T30. In the case of FIG. "Range B") to the administrator node (the node 200 in this embodiment) who has the management authority, and transmits and shares the corresponding influence confirmation item as a configuration confirmation request T20.

The node 200 receives the configuration confirmation request T20 transmitted from the node 100. FIG. Similarly to the node 100, the node 200 acquires setting items within the management range for which the own node has management authority from the BC configuration information T151 held by the own node, and affects setting items that can be affected by the configuration confirmation request T20. Output as a confirmation item. Also, the node 200 adds the output influence confirmation items to its own confirmation item list T161.

After that, the node 200 manages other nodes (here, the nodes 300 and 400) that have management authority over the management range ("range C" in the case of FIG. ), the corresponding influence confirmation item is shared as the configuration confirmation request T20.

In this way, by recursively sharing and propagating the configuration confirmation request T20 starting from the configuration change request T10, items to be confirmed, that is, impact confirmation items, are extracted across each management range in the BC system 1. . The result is also added to the check item list for each node. With this series of processes, the impact confirmation items to be confirmed for the entire BC system are covered.

The BC system 1 is also communicably connected to input/output devices 140 and 240 that display a check item list for each node. The input/output devices 140 and 240 are composed of an output device such as a display for displaying the check item list, and an input device such as a keyboard for the administrator of each node to perform an approval operation regarding the contents of the check item list. be.

Note that the approval result of the administrator regarding the check item list in each node is shared among the nodes within the same influence range, that is, the tasks, etc., of the same group through the approval result sharing unit 130, and when it satisfies a predetermined condition. , the configuration change to the BC system 1 is reflected.

Here, the configuration change request T10 and the configuration confirmation request T20 are defined as different data in terms of role, but the actual data structure is the same. Therefore, they can be defined as the same table.
--- Node configuration ---

FIG. 2 is a diagram showing an example of functions provided in each node according to the first embodiment. Hereinafter, unless otherwise specified, the node 100 will be described as a representative of each node.

The node 100 includes an arithmetic device 101 such as a CPU, a storage device 102 such as a hard disk drive, and a communication device 103 such as a network interface card.

Among them, the arithmetic unit 101 implements a request reception unit 120 , a request transmission unit 121 , a confirmation item extraction unit 110 , an impact confirmation item management unit 190 , an approval result sharing unit 130 and a configuration change execution unit 180 . The functions of these units are implemented by the arithmetic unit 101 executing a predetermined program.

The storage device 102 also holds configuration information T150, a check item list T160, and an influence determination rule T170. Among them, the configuration information T150 is a set of setting item lists T150X of the management range for which the BC configuration information has the management authority.

Also, the confirmation item list T160 is a set of impact confirmation items output for each node. The influence determination rule T170 is a set of rules describing the influence between setting items of the configuration information.

Further, the node 100 is provided with an input/output device 140 linked thereto. The input/output device 140 has a role as an interface with the administrator of the node 100 .

The details of each unit described above will be described below. The request receiving unit 120 receives a configuration change request T10 regarding the BC system 1 from outside the BC system 1 (eg, another node), or a configuration change request T10 from inside the BC system 1, that is, an existing node. Receives a configuration confirmation request T20 describing impact confirmation items.

In this embodiment, the node 100 can view only requests issued to the management scope for which the node 100 has management authority, and the configuration change request T10 and the configuration confirmation request T20 can be sent between organizations with appropriate authority, that is, management shall be shared only in scope.

The confirmation item extraction unit 110 receives a configuration change request or a configuration confirmation request shared by another node from the request reception unit 120, and extracts the management authority of the own node from the BC configuration information T150 held by the own node. After acquiring the setting items T150X of the management range, the processing unit analyzes the influence using the influence determination rule T170, and extracts the influence confirmation item T30, which is a list of individual setting items that can be influenced by the request. Here, since the configuration information held by the node depends on the management range in which the node participates and the authority of the node, the result of the influence check item T30 differs for each node.

The request transmission unit 121 is a processing unit that transmits the impact confirmation item extracted by the confirmation item extraction unit 110 to another node (that is, administrator node) that has management authority over the management range that holds the item.

This request transmission unit selects a node having management authority over the management range of the impact confirmation item by referring to administrator node information T153X (described later in FIG. 4) described in the management range setting item list T150X. and transmit the impact confirmation items to the corresponding node as a configuration confirmation request T20.

The impact check item management unit 190 adds the impact check item T30 extracted by the check item extraction unit 110 to the check item list T160, and also responds to the configuration change request T10 and the configuration check request T20 shared by other nodes. , is a processing unit that compares with the contents of the check item list T160 and determines whether or not there is already the check item list T160.

The approval result sharing unit 130 is a processing unit that shares the result of approval of the check item list T160 by the administrator of each node via the input/output device 140 with other nodes. Here, not only the approval result but also signature information required for approval may be shared. If the approval result satisfies a certain condition, configuration change processing, which will be described later, is executed.
The configuration change executing unit 180 is a processing unit that actually changes the configuration of the BC system 1 in response to the approval result described above.
---Management structure in BC system---

FIG. 3 shows the management structure of the BC system 1 in this embodiment. The management structure in the BC system 1 of this embodiment defines the BC system 1 as a set of management ranges arranged in three layers, namely, the consortium layer, the business layer, and the SC layer.

Here, the business groups are divided into two groups, A and B. In addition, two SCs, a transaction SC (smart contract; hereinafter referred to as SC) and a user management SC, operate in the business A group. SC is working.

As for the existing node configuration of this embodiment, among the organizations Org1 to Org8 participating in the consortium, each node of Org1, 2, 5, and 6 is the administrator node of this consortium.

Among Org1 to Org6 participating in task A, Org1 to 4 are administrator nodes of task A group, It is an administrator node.

Of the SCs executed in the work A group, Org1 to 4 execute transaction SCs, of which Org1 and 2 are administrator nodes, and Orgs1 to 4 execute user management SCs, of which Org3, 4 is the administrator node.
Also, Orgs 5 to 8 execute the transaction SC executed in the business B group, and Orgs 7 and 8 are administrator nodes.

Further, as shown in the figure, addition of newOrg as a member node to the consortium, the business B group, and the transaction SC in the lower layer as a configuration change request T10 for the existing node configuration is assumed in the following embodiments. However, for the sake of simplification of explanation, processing related to the present invention, such as a configuration change request to the business B group or lower, influence item extraction processing, check item list, etc., will be omitted from the drawings and explanations below.

In this embodiment, in each management range, a configuration change policy is defined as a condition for changing the configuration information of that management range. It is assumed that configuration change processing can be executed by approval of n nodes. This policy is denoted as "n-of-admin node".

It should be noted that these schematic diagrams are diagrams created to facilitate understanding of the BC system configuration for the sake of explanation, and no one knows the overall picture of the BC system 1 in actual operation. Therefore, it should be noted that there is no such table that can grasp to which group each node belongs.

Next, the concept of the management range described above will be described with reference to FIG. FIG. 4 is a diagram showing a table T150X representing setting items in a certain management range X. As shown in FIG. The setting items in this management range X are defined in a list format. It consists of a change policy T154X and setting items T155X unique to each management range.

Here, SC version, SC description language, SC approval policy, and block acquisition execution authority, which are setting items of the transaction SC, are defined as setting items T155X unique to the management range.
Hereinafter, the notation OrgX will be used as the name of the organization that configures the member node and administrator node.

The above-mentioned SC approval policy is a policy that indicates how many nodes out of the nodes that have executed the SC have to return approval before the SC execution result is described in the block as a correct result. Like the configuration change policy T154X, it is expressed in the form of n-of-nodes.

In addition, the block acquisition execution authority represents the authority to acquire the block of the blockchain through the API, and in the example of the figure, it is expressed by the conditional expression that only the administrator of Org1 or Org2 can acquire the block information.
--- Configuration of tables, etc. ---

FIG. 5 shows a configuration change request T10 in this embodiment. In this embodiment, the configuration change request T10 is given to the BC system 1 from the outside. The configuration change request T10 is in a list format and consists of a request ID (T11), a management range T12 subject to configuration change, an item name T13, pre-change information T14, post-change information T15, and a summary T16.

In this embodiment, only one configuration change request T10 is exemplified for the sake of simplification of explanation, but in reality configuration change requests are issued with the same configuration to the business B group and below.

Among the above, the management range T12 corresponds to the management range in the management structure of the BC system 1 in FIG. Here, the value is one of consortium, business groups A and B, transaction SC, and user management SC.

Also, the item name T13 is a name indicating one setting item in the management range T12. This corresponds to the item name in FIG. 4, and indicates "member node" in the management range "consortium" in this example.

The pre-change information T14 represents the current contents of the configuration change item T13. In this embodiment, values of "Org1 to Org8" are defined as the item name "member node" of the management range "consortium".

Further, post-change information T15 represents post-change content of the configuration change item T13 when changed by the configuration change request T10. This embodiment shows a state in which "newOrg" is added in addition to the existing "Org1 to Org8" as the item name "member node" of the management range "consortium".
The outline T16 describes the configuration change request T10 in natural language. This item is a value described as representing the intention of configuration change.

Next, FIG. 6 shows an example of the influence determination rule T170. The influence determination rule T170 in this embodiment is a table showing rules and regularity indicating that when certain setting information is changed in the BC system 1, other setting items are affected.

The impact determination rule T170 in this embodiment is not described in units of management ranges such as the business A group and the transaction SC, but describes common rules between layers such as more general business layers and SC layers. is.

Such an influence determination rule T170 spans multiple layers, and in FIG. 6, for example, the influence on member nodes of the SC layer and the SC approval policy is defined with respect to the addition of member nodes to the business layer.

The influence determination rule T170 is a list including an ID (T171), an influence source setting item T172, and an influence destination setting item T175. Of these, the setting item T172 of the influence source and the setting item T175 of the influence destination are defined with management layers (T173, T176) and setting item names (T174, T177), respectively.

It is assumed that the influence determination rule T170 in this embodiment is static information created in advance by correlating setting items in the configuration information T150 in another BC system on the same base.

Specifically, for organizational information and other information contained in smart contracts, consortium setting information, etc., extract the parts described with the same words, and after human or automatic system performs appropriate abstraction , is described in the influence determination rule T170 as a correlation.

As another method for creating the impact determination rule T170, there is a method of extracting simultaneously changed setting items from the history of past configuration changes in the BC system 1 and dynamically adding them to the impact determination rule T170. Conceivable.
A method of defining network topology information determined from business requirements determined in an upstream process or the like as the impact determination rule T170 is also conceivable.

Although the influence determination rule T170 is shared by the participants of the BC system 1 in this embodiment, access may be restricted based on the management authority of the node 100. FIG.

FIG. 7 also shows the impact check item T30 extracted from the configuration information T150 by the check item extraction unit 110 by inputting the configuration change request T10 or the configuration check request T20.

The impact check item T30 is composed of a request ID (T31), a management range T32 to be changed, an item name T33, pre-change information T34, post-change information T35, and a summary T36.

Of these, the pre-change information T34 describes the current values of the impact confirmation items. Also, the post-change information T35 is blank. The summary T36 inherits the summary T16 of the configuration change request T10, and is described as representing the intention of the configuration change.
Also, FIG. 8 shows a configuration confirmation request T20 in which influence confirmation items are collected and transmitted to each administrator node in order to share the influence confirmation items T30 with other nodes.

This configuration confirmation request T20 is composed of a request ID (T21), a management range T22 to be changed, an item name T23 of an impact confirmation item, a pre-change content T24, a post-change content T25, and an outline T26.

This configuration confirmation request T20 has the same format as the impact confirmation item T30. It is defined as a separate request for each administrator node to be sent. Therefore, the management range of each row is the same in the configuration confirmation request T20.
Next, FIG. 9 shows an example of a check item list T160 that is output to each node after checking the impact of the configuration change request T10 in this embodiment.

This check item list T160 is defined as a list that stores the configuration change request T10, the configuration check request T30, and the impact check item T20 for each node.
The configuration is composed of an ID (T161), a management range T162, an item name T163, pre-change information T164, post-change information T165, and a summary T166.

In this embodiment, as the check item list T160 of Org1, in addition to the configuration change request T10 that changes the setting of the consortium, the member node that is the setting item of the business A group and the SC approval policy that is the setting item of the transaction SC are included. , is output as a check item list T160.

Further, in this embodiment, in the case of Org3, which does not have the reference authority for the configuration change request T10, only the confirmation items regarding the task A group and the user management SC for which the own node has authority are displayed as the confirmation item list T160.
---Configuration Change Management Method (Embodiment 1)---

Next, the actual procedure of the configuration change management method in this embodiment will be described with reference to the drawings. Various operations corresponding to the configuration change management method described below are implemented by programs executed by each node 100 in the blockchain system 1 as the configuration change management system. This program is composed of codes for performing various operations described below.

FIG. 10 is a diagram showing a flow example 1 of the configuration change management method according to this embodiment. Here, first, it is assumed that a configuration change request T10 is issued from outside the BC system 1. FIG. A predetermined management node receives the configuration change request T10 and distributes the configuration change request to other nodes having authority over the management range T12 described in the configuration change request T10 for sharing (s1).

Next, each node starting from the node that received the configuration change request T10 described above (that is, the corresponding nodes that have authority over the management range T12) recursively performs the check item extraction process (details are explained in FIG. 12). Execute, extract impact confirmation items to be confirmed across the management range in the BC system 1, and generate a confirmation item list T160 at each node (s2). Details of this step will be described later.
After that, each node in the BC system 1 displays the check item list T160 described above on the input/output device 140 for the administrator of the node (s3).

FIG. 11 shows a specific example of the screen 1000 of the check item list T160 displayed on the input/output device 140 as described above. The above-mentioned administrator browses this screen 1000, confirms the contents of the check item list T160, and determines whether to approve or correct the configuration change based on the impact check items.

Therefore, the screen 1000 includes, in addition to the confirmation item list T160, an approval button 1001 for approving the configuration change, a correction button 1002 for transmitting corrections to the configuration change to other nodes, and a rejection button 1003 for rejecting the configuration change. there is However, this is an example, and only one of the correct button 1002 and the reject button 1003 may be implemented.

Such a screen 1000 is displayed to the administrator of the node via the display of the input/output device 140 or the like. FIG. 11 shows an example of a screen displayed to the administrator of "Org1". The administrator of Org1 can check the effect of the configuration change by comparing the "pre-change information" and the "post-change information" in the check item list T160 on the screen.

If there is no problem, an approval button 1001 is pressed to approve the configuration change. On the other hand, if there is a problem, a rejection button 1003 for rejecting the configuration change can be pressed, or the value of "post-change information" in the confirmation item list T160 can be corrected. When the above-mentioned administrator corrects the "post-change information", he/she presses a correction button 1002 for transmitting the correction contents after this correction. Then, the node 100 receiving this transmits the corrected confirmation item information as a configuration change request to other nodes that have authority over the management range of the corresponding setting item (in this embodiment, Org2, Org3, Org4, Org2, Org3, Org4, to each node of the network).

On the other hand, each node acquires the result of the approval process performed by the administrator on the confirmation item list T160 (s4). The approval processing here means whether to approve, reject, or correct the confirmation item list T160, and the "result" corresponding to the button pressed on the screen 1000 is shared among the corresponding nodes. be. That is, the approval result of each node is shared by the approval result sharing unit 130 .

As a result of the above-mentioned sharing, when the administrators of all nodes who have authority over the management range T12 have performed approval processing (s5: yes), each node performs configuration change processing in accordance with the configuration change request T10. 180 collectively executes (s6).

On the other hand, if the administrator of one or more nodes among all the nodes that have authority over the management range T12 does not perform the approval process (s5: no), and if a certain node performs the modification process by the administrator for the configuration change If received (s7: yes), the modification is transmitted as a configuration change request to each node having authority over the management range T12 (s8), and the process is repeated from s1.

On the other hand, if the configuration change has not undergone correction processing (s7: no) and the configuration change has been rejected (s9), each corresponding node assumes that the configuration change has been rejected and performs the configuration change processing. end the process.

In this embodiment, the approval result sharing unit 130 performs configuration change processing when all nodes approve, but in reality, configuration change processing is performed when predetermined conditions are met. may be

Here, the predetermined condition may be approval of a node that satisfies the configuration change policy set in the n-of-manager node format in each management range in the entire management range.

Also, although each node performs configuration change processing in this embodiment, this is not the only option. For example, it is conceivable that a node representing each management range receives the approval result and issues a configuration change transaction to the BC system 1 .
Here, the details of step s2 in the above-described flow, ie, the check item extraction process will be described based on the flow of FIG.

In this case, in this flow, one node (here, node X) among the nodes participating in the BC system 1 is the subject of the configuration change request T10 or the configuration confirmation request T20 (hereinafter collectively referred to as T20). (referred to as "request") is input.
First, the node X checks whether the input request is already listed in the confirmation item list T160 (s10).

As a result of the above check, if the request has already been entered in the confirmation item list T160 (s10: yes), the node X ends the process. This conditional branching process clarifies the conditions for terminating the recursive process, and avoids duplication of the process, thereby speeding up and reducing the weight of the process as a whole.

On the other hand, if the request is not listed in the check item list T160 as a result of the above check (s10: no), the node X adds the request to the check item list T160 of the node X (s11), From the influence determination rules T170, the rules for which the node X has the management authority are extracted and obtained (s12).

In addition, the node X refers to each rule obtained in s12, and from the setting information T151X of the management range in the configuration information T150 held by this node, sets the setting items affected by the input request as the influence confirmation items T30. Extract (s13).

Subsequently, the node X adds the above-mentioned request and the impact check item T30 extracted in s13 to the check item list T160 as an impact check item for which the manager approves at this node X (s14).

Also, the node X obtains a list of other nodes that have management authority over the management range of the impact confirmation item T30 extracted in s13 by referring to the administrator node list T152X of the configuration information T150 (s15).

After that, the node X inputs the impact confirmation item T30 extracted in s13 as a configuration confirmation request T20 to the node list acquired in s15, and executes confirmation item extraction processing (s16).

By repeating this process, the effect confirmation item T30 extracted within the scope of authority of node X using the configuration change request T10 as an input is shared with other nodes as a configuration confirmation request T20, and the shared node receives the configuration confirmation request T20. A chain is generated in which T20 is used as an input to extract the influence confirmation item again and share it with other nodes as a configuration confirmation request T20.
By the above processing, the influence of the configuration change is confirmed not only by the node authorized to the configuration change request T10 but also by the entire BC system.

In this embodiment, the processing units for communicating with other nodes, such as the request transmitting unit 120, the request receiving unit 121, and the approval result sharing unit 130, are separately defined. may be defined as a processing unit.

One way to implement this is to use a smart contract. Specifically, a smart contract is created in which all organizations participate separately from work, and state information (stored on the blockchain) is used for configuration change requests, configuration confirmation requests, and approval results under each management scope authority. data).

Also, a method of realizing this using a private group (information can be shared only between specific organizations within a smart contract) (Hyperledger Fabric”, [online], [searched February 27, 2018], Internet < URL: http://hyperledger-fabric.readthedocs.io/en/latest/>) is also conceivable.

Also, in this embodiment, the management structure is tree-like, but in reality it is not limited to this. For example, even when inter-SC cooperation or inter-business group cooperation is performed, confirmation item extraction processing can be performed without any problem.

Also, the scope of application of this embodiment is not limited to the BC system. For applications and operation management tools linked with BC systems, there are cases where the management authority extends over multiple organizations. In this case, this method can be applied by defining applications and tools as a new management scope. Even a distributed system that is completely independent of the BC system is applicable when there are multiple management ranges.

As described above, when changing the configuration of the non-centralized BC system 1, it is possible to check the impact confirmation items without omission for the entire BC system within the scope of authority of each organization.

In addition, by collectively outputting the impact confirmation items for each organization and allowing the administrator to approve or correct them for each node, it is possible to reduce the number of confirmation man-hours for the entire BC system.

In addition, the results approved by administrators are shared between nodes, and configuration change processing is performed collectively under predetermined rules, reducing the risk of errors and system stoppages compared to individual configuration change processing. is also possible. Furthermore, by recursively performing the confirmation item extraction process, the conditions for terminating the process can be clarified.

In addition, by sharing configuration change requests, configuration confirmation requests, and approval results using smart contracts, the processing of Example 1 can be automated on the BC system, and a trail of extracted impact confirmation items can be left. .

In addition, a recursive processing method that searches for a match between the configuration change request and configuration confirmation request shared from other nodes with the check item list of the own node and terminates the processing if the check item list matches is used for recursive processing. Such calculation amount and time can be reduced.
[Example 2]

In the first embodiment, the administrator of the node 100 issues approval or correction instructions through the input/output device 140 for each organization's check item list. However, when modifying the impact check items, the node administrator had to think about what to modify. Therefore, it is assumed that the node manager needs some knowledge about the settings of the BC system 1 .

Therefore, in this embodiment, by applying the influence determination rule to which the conditional expression is attached, when the confirmation item extraction process is performed, for the important influence confirmation items, the impact confirmation items and their correction proposals are output. It shows the form presented to the person. As a result, it is possible to modify the impact confirmation items without the need for the node administrator to think about modification details.

In this embodiment, for example, a flag as a correction required item (hereinafter referred to as a correction required flag) and a correction proposal can be given to the check item list T160 for each node shown in FIG. The node administrator can confirm the confirmation items with correction required flags and their correction proposals through the input/output device 140 .

In this case, the influence determination rule T170 is defined as a table with conditional expressions, unlike the rules already exemplified in FIG. In addition, the influence confirmation item management unit 190 performs a process of adding a correction required flag to the confirmation item.

As for the flow of processing, post-change information is added to the impact check item T30 extracted by the check item extraction unit 110, unlike the first embodiment. After that, the post-change information is inherited by the configuration confirmation request T20 and the confirmation item list T160, and is displayed to the node manager as a correction proposal. In addition, the check item list T160 is provided with the above-mentioned correction required flag.

FIG. 13 shows the influence determination rule T170P in this embodiment. The influence determination rule T170P in this embodiment is defined as a set of rules describing the necessary conditions for the configuration of the BC system 1. FIG.

Such a requirement could be, for example, that if OrgX is included in the SC approval policy of the SC layer, OrgX should be a member node in its immediate business group. Also, for example, regarding Role, which is a unique setting item indicating a role within a group, as a rule derived from business requirements, if a certain organization is defined as Role=Y, it must be an administrator node of the user management SC. It is also possible to think that there is

The influence determination rule T170P of this embodiment is composed of an ID (T171P), an influence source T172P, an influence destination T175P, and a conditional expression T178P. Of these, the source of influence T172P and the destination of influence T175P are respectively composed of management layers (T173P, T176P) and item names (T174P, T177P).

This is obtained by adding a conditional expression T178P to the influence determination rule T170 of the first embodiment. The conditional expression T178P expresses the relationship between the source of influence T172P and the destination of influence T175P by a conditional expression. For example, the ID1 line indicates that the influence source (node belonging to the SC approval policy) OrgX is always included in the member nodes of its parent's business group.

When this impact determination rule T170P is used for the configuration change request T10, the post-change information T35 calculated based on the conditional expression T178P is added to the output impact check item T30. The impact check item T30 to which the post-change information is added indicates that it is not the "item that should be checked" in the first embodiment, but the "item that specifically needs to be changed". This is a confirmation item that the node administrator should pay more attention to than the usual confirmation items.

When the conditional expression T178P is blank, it indicates that the influence determination rule is the same as in the first embodiment, which means that compatibility with the first embodiment is maintained. (Example: row with ID3).

FIG. 14 shows a check item list T160 in this embodiment. The check item list T160 includes an ID (T161), a management range T162, an item name T163, pre-change information T164, post-change information T165, an overview T166, and a correction required flag T167, which are the same as in the first embodiment. .

The correction required flag T167 is a flag given by the influence confirmation item management unit 190 to the influence confirmation item to which post-change information is added by the conditional influence determination rule T170P.

When the correction required flag is True (line 3 in the figure), the confirmation item is not the configuration change request T10 given in advance, and post-change information is described. This post-change information is displayed to the node manager as a correction proposal for the impact confirmation item. In other words, the correction required flag is notified to the node manager together with the correction proposal.
---Configuration Change Management Method (Embodiment 2)---

FIG. 15 shows a flow of confirmation item extraction processing in this embodiment. As a premise, the overall flow is the same as that of the first embodiment (FIG. 10). On the other hand, the check item extraction process is different in that when the input is a configuration check request with post-change information, a correction required flag is set and added to the check item list.

The details of the confirmation item extraction processing flow are shown below. First, as in the first embodiment, the node X matches the input (configuration change request T10 or configuration confirmation request T20) with the confirmation item list T160 to search for a match with the existing impact check item (s10).

If the input does not match the existing impact confirmation item (s10: no), the node X identifies whether the input is a configuration confirmation request with post-change information as a process specific to the second embodiment (s20).

If the input is not a configuration confirmation request with post-change information (s20: no), the node X adds the request to the confirmation item list T160 of the node X as in the first embodiment (s11).

On the other hand, if the input is a configuration confirmation request with post-change information (s20: yes), the node X adds the request to the confirmation item list T160 with a correction required flag as a high-priority impact confirmation item to be corrected. Add (s21).

After adding the above-described request to the check item list T160, the node X extracts the impact determination rule for which the node has authority (s12), and extracts the impact check item from the impact determination rule ( s13).
After that, the node X determines whether or not each of the influence confirmation items extracted in s13 is described in the post-change information as a process specific to the second embodiment (s22).

As a result of this determination, if the post-change information is not described in the impact confirmation item (s22: No), the node X adds the impact confirmation item to its own node's confirmation item list T160 in the same manner as in the first embodiment (s14). .

On the other hand, if post-change information is described in the impact confirmation item (s22: Yes), node X can determine that this impact confirmation item is an impact confirmation item derived from the conditional expression impact determination rule T170P. As in s21, a correction required flag is given and added to the confirmation item list T160 (s23).

Thereafter, in the same manner as in the first embodiment, a check item extracting process of obtaining a list of other nodes that have management authority for each impact check item (s15) and inputting the impact check items to the node as a check item list T160 is performed. Execute (s16), recursive processing is performed.

After the above-described recursive processing is completed, the administrator for each node checks the check item list T160 for each node via the input/output device 140. FIG. At this time, the node X treats the configuration confirmation request with post-change information added to the confirmation item list T160 with the correction required flag in s20 as a confirmation item to be corrected, and the node administrator display for At this time, if there is a correction required flag, it may be displayed in color.

By adopting this form, node administrators can distinguish impact confirmation items with high priority. can be modified.

Moreover, even if the node administrator does not have knowledge of the BC system 1 above a certain level, he or she can efficiently find items to be corrected in changing the configuration of the BC system 1 and make appropriate corrections.

Although the best mode for carrying out the present invention has been specifically described above, the present invention is not limited to this, and can be variously modified without departing from the scope of the invention.

According to this embodiment, when changing the configuration of the BC system, it is possible to efficiently confirm setting items that are not overlooked in the BC system as a whole while using only information that can be obtained for each organization. This enables accurate configuration change processing while maintaining decentralization, which is a feature of the BC system. That is, when changing the configuration of the BC system, it is possible to perform efficient and accurate confirmation of the system as a whole within the authority of each organization.

At least the following will be clarified by the description of this specification. That is, in the configuration change management method of the present embodiment, when extracting the impact confirmation items, each of the nodes uses a predefined impact determination rule to extract the impact confirmation items from the configuration information in the node. may be

According to this, it is possible to extract impact confirmation items more efficiently, and in turn, when changing the configuration of the BC system, it is possible to confirm more efficiently and accurately as a whole system within the authority of each organization. becomes.

Further, in the configuration change management method of the present embodiment, each of the nodes specifies a correlation based on a common keyword between smart contracts or the configuration information as the impact determination rule when extracting the impact confirmation items. The influence confirmation item may be extracted from the configuration information of the node using the influence determination rule generated by the above.

According to this, it is possible to extract the impact confirmation items with high accuracy according to the rules based on the past performance by those with knowledge. As a result, more efficient confirmation can be performed with good accuracy.

Further, in the configuration change management method of the present embodiment, each of the nodes identifies simultaneously changed items based on the configuration change history in the blockchain system, and the impact determination rule prescribes the items as impact confirmation items. may be generated or updated.

According to this, it is possible to create and update impact determination rules based on configuration changes that have been reached through consensus building in administrator nodes, etc. in the BC system, and under rules based on the judgment results of people with skills and experience. It is possible to extract items to confirm the impact of As a result, when changing the configuration of the BC system, it is possible to perform more efficient and accurate confirmation of the system as a whole within the authority of each organization.

Further, in the configuration change management method of the present embodiment, each node transmits at least one of the configuration change request, the impact confirmation item, and the approval result regarding the impact confirmation item to other nodes using a smart contract. You can share it.

According to this, the sharing of impact confirmation items etc. between nodes becomes efficient, and in turn, when changing the configuration of the BC system, within the authority of each organization, more efficient confirmation of the system as a whole can be performed with good accuracy. can be done.

Further, in the configuration change management method of the present embodiment, each of the nodes holds, in its own node, the impact confirmation item shared by the other node in response to the configuration change request or the configuration confirmation request from the other node regarding the impact confirmation item. If the list of impact confirmation items is compared and the extraction of impact confirmation items for the item is completed, the subsequent recursive processing may be omitted.

According to this, it is possible to eliminate wasteful recursive processing, and eventually, when changing the configuration of the BC system, it is possible to perform more efficient and accurate confirmation of the entire system within the authority of each organization. Become.

Further, in the configuration change management method of the present embodiment, after each node extracts the impact confirmation items to be confirmed for the entire blockchain system, a list of impact confirmation items for each organization is sent to the node administrator. may be displayed, and predetermined processing corresponding to approval, correction, or rejection of the configuration change, which is the result of confirmation by the administrator, may be executed.

According to this, the user of the administrator node in the BC system, that is, the administrator, can appropriately recognize the impact confirmation items and use them as materials for making judgments, and the processing based on the results of such judgments can be automatically executed. will be As a result, when changing the configuration of the BC system, it is possible to perform more efficient and accurate confirmation of the system as a whole within the authority of each organization.

Further, in the configuration change management method of the present embodiment, each node shares the approval result of the impact check item for each organization among the nodes, and when the approval result satisfies a predetermined agreement condition, , the configuration change processing may be performed collectively, or the configuration change processing may be rejected if the agreement conditions are not satisfied.

According to this, it is possible to comprehensively execute/reject configuration change processing after consensus building between administrator nodes. Furthermore, it is possible to perform efficient confirmation with good accuracy.

Further, in the configuration change management method of the present embodiment, each node shares the approval result of the impact confirmation item for each organization among the nodes, and if the approval result does not satisfy a predetermined agreement condition, the impact confirmation When a part of the list of items is subject to correction processing by the administrator, the content of the correction processing is shared with other nodes as a configuration change request. Mutual sharing and recursive processing between nodes for confirmation items and extraction of impact confirmation items to be confirmed in the entire blockchain system may be re-executed.

According to this, it is possible to deal with the situation where the administrator proposes a modification of the configuration change request, and treat this as a new configuration change request to be processed. By extension, BC
When changing the configuration of the system, it is possible to perform more efficient and accurate confirmation of the system as a whole within the authority of each organization.

In addition, in the configuration change management method of the present embodiment, when extracting the impact confirmation items, each node uses an impact determination rule with a predetermined conditional expression to prioritize confirmation or correction in the blockchain system. It is also possible to extract influence confirmation items.

According to this, it is possible to efficiently identify a specific event or the like for which knowledge has been obtained by the above-described conditional expression, and to extract the impact confirmation items corresponding to this. As a result, when changing the configuration of the BC system, it is possible to perform more efficient and accurate confirmation of the system as a whole within the authority of each organization.

1 BC system (configuration change management system)
100 Node 101 Arithmetic device 102 Storage device 102 Program 103 Communication device 110 Confirmation item extraction unit 120 Request reception unit 121 Request transmission unit 130 Approval result sharing unit 140 Input/output device 180 Configuration change execution unit 190 Impact confirmation item management units T10, T20 Configuration Change request T30 Impact confirmation item T150 Node-owned BC configuration information T151 Node-owned BC configuration information T152 Node-owned BC configuration information T150X Management range X setting item list T160, T161 Check item list T170 Impact determination rule 200 Node 300 Node

Claims (10)

In a blockchain system in which multiple organizations participate , each node of the multiple organizations, which constitutes the blockchain system ,
With respect to a configuration change request to the blockchain system , using a predefined impact determination rule, extracting impact confirmation items based on the configuration information of the organization to which the node belongs, and extracting the configuration change request, the impact confirmation item, and at least one of the results of approval by the administrator of the node regarding the impact confirmation items for each organization. A configuration change management method characterized by extracting items. each node,
When extracting the impact confirmation item, the configuration information in the node is used as the impact determination rule generated by specifying the correlation based on the common keyword between the smart contract and the configuration information. extract the impact confirmation items from
2. The configuration change management method according to claim 1 , wherein: each node,
Based on the configuration change history in the blockchain system, identify the items that have been changed at the same time, and generate or update the impact determination rule that defines the items as impact confirmation items;
2. The configuration change management method according to claim 1 , wherein: each node,
Regarding the impact confirmation items shared from other nodes by the configuration change request or the configuration confirmation request from other nodes regarding the impact confirmation items, the impact confirmation items are compared with the list of impact confirmation items held by the self-node, and the impact confirmation is performed on the relevant items. 2. The configuration change management method according to claim 1, wherein when extraction of items has been completed, subsequent recursive processing is omitted. each node,
After extracting the impact confirmation items to be confirmed for the entire blockchain system, the list of impact confirmation items for each organization is displayed to the node administrator, and the administrator approves or corrects the configuration change as the confirmation result. 2. The configuration change management method according to claim 1, wherein predetermined processing corresponding to or rejection is executed. each node,
Sharing the approval results of the above-mentioned impact confirmation items for each organization between nodes, and when the approval results meet predetermined agreement conditions, collectively perform configuration change processing, or do not meet the agreement conditions 6. The configuration change management method according to claim 5 , wherein the configuration change processing is rejected if the configuration change processing is performed. each node,
When the approval results of the aforementioned impact confirmation items for each organization are shared between nodes, and the approval results do not satisfy the predetermined agreement conditions, and a part of the list of impact confirmation items is subject to correction processing by the administrator. , the content of the correction process is shared with other nodes as a configuration change request, and with respect to the configuration change request, extraction processing of the impact confirmation item, mutual sharing and recursion processing of the impact confirmation item between nodes, and the block Re-execute each process of extracting impact confirmation items that should be confirmed for the entire chain system,
6. The configuration change management method according to claim 5 , wherein: each node,
When extracting the impact confirmation items, using an impact determination rule with a predetermined conditional expression, extracting impact confirmation items that should be preferentially confirmed or corrected in the blockchain system;
2. The configuration change management method according to claim 1 , wherein: A blockchain system in which multiple organizations participate ,
Each node of the plurality of organizations constituting the blockchain system ,
With respect to a configuration change request to the blockchain system , using a predefined impact determination rule, extracting impact confirmation items based on the configuration information of the organization to which the node belongs, and extracting the configuration change request, the impact confirmation item, and at least one of the results of approval by the administrator of the node regarding the impact confirmation items for each organization. characterized by extracting items,
A configuration change management system characterized by: Each node of the plurality of organizations that constitutes a blockchain system in which the plurality of organizations participate ,
With respect to a configuration change request to the blockchain system , using a predefined impact determination rule, extracting impact confirmation items based on the configuration information of the organization to which the node belongs, and extracting the configuration change request, the impact confirmation item, and at least one of the results of approval by the administrator of the node regarding the impact confirmation items for each organization. characterized by extracting items,
A node characterized by

Images