JP2020135582A - Configuration change management method, configuration change management system, and node - Google Patents

Abstract

To precisely and excellently perform efficient confirmation on the whole BC system within authority of each organization when the configuration of the BC system is changed.SOLUTION: In a configuration change management system 1 as a block chain system, a node 100 which constitutes the block chain system includes an arithmetic unit 101 which performs extraction processing on an influence confirmation item based upon configuration information on the organization to which the node belongs with respect to a configuration change request to the block chain system, and performs sharing and recursive processing mutually with other nodes with respect to the influence confirmation item so as to extract an influence confirmation item to be confirmed on the whole block chain system.SELECTED DRAWING: Figure 2

Description

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

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

Such distributed ledger technology can be applied in a wide range of fields such as the financial field and IoT (Internet of Things) as a mechanism for managing and sharing reliable data and executing and managing contract-based transactions in a decentralized manner. It is being considered.

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

The distributed ledger technology can be classified into several types according to its configuration. The classification is "Public distributed ledger" in which a distributed ledger network is configured among an unspecified number of nodes, and a consortium is formed by multiple specific organizations, and the distributed ledger is distributed among the nodes owned by each organization. Examples include a "consortium-type distributed ledger" in which a network is configured, and a "private-type 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 that span organizations.

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

The main features of the current BC are: (1) In transactions between participants on the BC network, the transaction is finalized by consensus building and approval by the participants (voluntary or specific) rather than the centralized authority. 2) Collect multiple transactions as blocks, record them in a string of beads in a distributed ledger, and perform hash calculation on consecutive blocks to make tampering virtually impossible. (3) All participants have the same distributed ledger. By sharing the above, it is possible for all participants to confirm the transaction.

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

In a system in which BC is introduced (hereinafter referred to as a BC system), a plurality of participating organizations bring in resources, and the resources are managed by each of them to form one system as a whole. Therefore, there is no participating organization that understands the entire system.

For BC systems with such configuration characteristics, changes to the BC system configuration occur for the purpose of adding or leaving participating organizations to the BC network, and adding or updating smart contracts running on BC. To do.

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

If the configuration change of the BC system as described above is not performed correctly, it is possible that a failure / abnormality such as a system error or a system stop may occur after the configuration change. In order to prevent this, it is generally conceivable to use a method of confirming the change contents and the influence on other setting items in advance in response to the request for configuration change.

Therefore, as a conventional technique for confirming the range of influence at the time of configuration change, for example, a network configuration change evaluation program for causing a computer to evaluate the influence of a network configuration change, and topology information representing the topology of the network before the configuration change. Based on the configuration change information acquisition step for acquiring the device setting change information which is the information of the device setting change in the network, and the topology information and the device setting change information acquired by the configuration change information acquisition step. A network configuration change evaluation program (see Patent Document 1) that causes a computer to execute an influence range extraction step for extracting information on services affected by the configuration change has been proposed.

JP-A-2007-243855

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

In the above-mentioned prior art, the effect of the configuration change is evaluated in advance, but it is premised that a single management organization can manage and view the network topology information. However, in the BC system, the setting information and its management structure are hierarchically and group-structured.

If the structural unit is defined as a management scope, no one recognizes the overall picture of management as described above because the organizations having management authority are different in each management scope. Further, in the configuration change of the BC system, the setting change location often spans a plurality of management ranges, and it is necessary for the manager of the organization between the plurality of management ranges to cooperate when the configuration is changed.

Based on the above, the confirmation of the range of influence using the above-mentioned prior art can be performed only within the authority of one organization, and cannot be applied to a BC system managed by a plurality of organizations. In addition, even when this is shared and confirmed by a plurality of organizations, it is unclear which part should be confirmed by each organization because there is no organization that recognizes all the parts to be confirmed and allocates them appropriately. Therefore, there arises a problem that omission of confirmation or excessive duplication may occur.
Therefore, an object of the present invention is to provide a technique for performing efficient confirmation of the entire system with good accuracy within the authority of each organization when changing the configuration of the BC system.

In the configuration change management method of the present invention that solves the above problems, each node constituting the blockchain system extracts an impact confirmation item based on the configuration information of the organization to which the node belongs with respect to the configuration change request for the blockchain system. It is characterized in that processing is performed, the impact confirmation items are shared and recursively processed between the nodes, and the impact confirmation items to be confirmed as the entire blockchain system are extracted.

Further, the configuration change management system of the present invention is a blockchain system composed of a plurality of nodes, and each of the plurality of nodes has the configuration information of the organization to which the node belongs with respect to the configuration change request for the blockchain system. The feature is that the impact confirmation items to be confirmed are extracted based on the above, the impact confirmation items are shared and recursively processed between the nodes, and the impact confirmation items to be confirmed as the entire blockchain system are extracted. To do.

Further, the node of the present invention is a node that constitutes a blockchain system, and with respect to a configuration change request for the blockchain system, an impact confirmation item is extracted based on the configuration information of the organization to which the node belongs, and the present invention is performed. The impact confirmation items are shared with other nodes and recursive processing is performed, and the impact confirmation items to be confirmed as the entire blockchain system are extracted.

According to the present invention, when the configuration of the BC system is changed, it is possible to efficiently confirm the system as a whole with good accuracy within the authority of each organization.

It is a figure explaining the processing outline in BC system in Example 1. FIG. It is a figure which shows an example of the function which each node has in Example 1. FIG. It is a figure which shows an example of the management structure of the BC system in Example 1. FIG. It is a table which represents the setting item in the control range in Example 1. It is a table which represents the configuration change request in Example 1. It is a table which shows the influence determination rule in Example 1. It is a table which shows the influence confirmation item in Example 1. It is a table which represents the configuration confirmation request in Example 1. It is a table which represents the confirmation item list in Example 1. This is a flow when changing the configuration of the entire system in the first embodiment. It is a figure which shows the confirmation screen in Example 1. FIG. This is a flow when the confirmation item extraction process is performed on each node in the first embodiment. It is a table which shows the influence determination rule in Example 2. It is a table which represents the confirmation item list in Example 2. This is a flow when performing the confirmation item extraction process in the second embodiment.

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

FIG. 1 is a diagram illustrating a processing concept in a blockchain system 1 (hereinafter, BC system) which is a configuration change management system in the first embodiment. In this embodiment, for the sake of simplification of the explanation, an example is shown in which an organization such as a company operates one node in the BC system 1 and has a one-to-one correspondence between the organization and the node. However, in reality, this is not the case, and it is possible to assume a configuration in which one organization operates a plurality of nodes.

When the node 100, which is one of the nodes constituting the BC system 1, receives the configuration change request T10 as an input from, for example, another node operated by a predetermined organization, the confirmation item extraction unit 110 contains the BC configuration information T150. Acquires the setting item of the management range for which the own node has the management authority, and outputs the influence confirmation item T30 that may be affected by the configuration change request T10. The influence confirmation item T30 is added to the confirmation item list T160 of the node 100.

Further, the node 100 has a management range (example: the entire consortium, business groups, smart contracts, etc., each layer, each group, etc.) that holds the setting items for each output confirmation item T30. In the case of FIG. The corresponding impact confirmation item is transmitted and shared as a configuration confirmation request T20 to the administrator node (node 200 in this embodiment) having management authority for "range B").

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

After that, the node 200 has other nodes (here, the node 300 and the node 400) having management authority for the management range (“range C” in the case of FIG. 1) having each impact confirmation item output as described above. ), The corresponding impact 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 confirmation item list for each node. Through this series of processes, the impact confirmation items to be confirmed for the BC system as a whole are covered.

The BC system 1 is also communicably connected to the input / output devices 140 and 240 that display a list of confirmation items for each node. The input / output devices 140 and 240 are composed of an output device such as a display for displaying a confirmation 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 confirmation item list. Ru.

In addition, the approval result of the administrator regarding the confirmation item list in each node is shared within the same influence range, that is, the business etc. between the nodes of the same group through the approval result sharing unit 130, and it satisfies the predetermined condition. , The configuration change for 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 roles, but the actual data structure is the same. Therefore, it may be defined as the same table.
--- Node configuration ---

FIG. 2 is a diagram showing an example of a function provided by each node in the first embodiment. Hereinafter, unless otherwise specified, the node 100 will be described on behalf of each node.

The node 100 is composed of an arithmetic unit 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.

Of these, the arithmetic unit 101 implements a request receiving unit 120, a request transmitting unit 121, a confirmation item extraction unit 110, an influence confirmation item management unit 190, an approval result sharing unit 130, and a configuration change execution unit 180. The functions of each of these parts are implemented by the arithmetic unit 101 executing a predetermined program.

Further, the storage device 102 holds the configuration information T150, the confirmation item list T160, and the influence determination rule T170. Of these, the configuration information T150 is a set of the management range setting item list T150X of which the BC configuration information has management authority.

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

Further, the node 100 is provided with an input / output device 140 in a form linked to the node 100. The input / output device 140 serves as an interface with the administrator of the node 100.

The details of each of the above-mentioned parts will be described below. The request receiving unit 120 should confirm the configuration change request regarding the BC system 1, that is, the configuration change request T10 from the outside of the BC system 1 (example: another node), or the configuration change from the inside of the BC system 1, that is, the existing node. Receive the configuration confirmation request T20 that describes the impact confirmation items.

In this embodiment, the node 100 can view only the requests issued to the management range for which the node 100 has the management authority, and the configuration change request T10 and the configuration confirmation request T20 are managed between organizations having appropriate authority. It shall be shared only within the scope.

The confirmation item extraction unit 110 receives a configuration change request and a configuration confirmation request shared from another node from the request reception unit 120, and the own node assigns management authority from the BC configuration information T150 held by the own node. After acquiring the setting item T150X of the management range to have, the impact analysis is performed using the impact determination rule T170, and the impact confirmation item T30, which is a list of individual setting items that can be affected by the request, is extracted. 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 impact confirmation item T30 has a different result for each node.

The request transmission unit 121 is a processing unit that transmits the influence confirmation item extracted by the confirmation item extraction unit 110 to another node (that is, an administrator node) having management authority for the management range possessing the item.

In this request transmission unit, the node having the management authority for the management range of the influence confirmation item is referred to the administrator node information T153X (described in FIG. 4 described later) described in the management range setting item list T150X. Acquire and send the impact confirmation item to the corresponding node as a configuration confirmation request T20.

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

The approval result sharing unit 130 is a processing unit that shares the result of approval of the confirmation 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 the signature information required for approval may be shared. When the approval result satisfies certain conditions, the configuration change process described later is executed.
The configuration change execution unit 180 is a processing unit that actually performs the configuration change of the BC system 1 in response to the above-mentioned approval result.
--- 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 each of the three layers of the consortium layer, the business layer, and the SC layer.

Here, the business group is divided into two groups, A and B. Further, the business A group operates two SCs, a transaction SC (smart contract, hereinafter referred to as SC) and a user management SC, and the business B group operates a transaction. The SC is running.

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

In addition, Org1 to 4 of Org1 to Org6 participating in business A are the administrator nodes of business A group, and Org5 to 8 of Org1,2,Org5 to 8 participating in business B are of business B group. It is an administrator node.

Among the SCs executed in the business A group, Org1 to 4 execute the transaction SC, of which Org1 and 2 execute the administrator node, and Org1 to 4 execute the user management SC, among which Org3 and Org3. 4 is the administrator node.
Further, it is Org 5 to 8 that execute the transaction SC executed in the business B group, and Org 7 and 8 are the administrator nodes.

Further, as shown in the figure, it is assumed in the following embodiments that newOrg is added as a member node to the consortium, the business B group, and the transaction SC of the layer below it as the configuration change request T10 for the existing node configuration. However, for the sake of simplification of the description, the processes related to the present invention such as the configuration change request to the business B group and below, the influence item extraction process, and the confirmation item list are omitted in the following figures and explanations.

In this embodiment, a configuration change policy, which is a condition for changing the configuration information of the management range, is defined in each management range, and according to this, in each management range, among the entire administrator node. It is assumed that the configuration change process can be executed by the approval of n nodes. This policy is referred to as "n-of-administrator node".

It should be noted that such a schematic diagram is a diagram created for easy understanding of the BC system configuration for the sake of explanation, and no one knows the whole picture of the BC system 1 in actual operation. Therefore, it should be noted that there is no table that can grasp all the groups to which each node belongs.

Subsequently, the concept of the control 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. The setting items in the management range X are defined as a list format, the name of the management range T151X, the member node T152X belonging to the management range, the administrator node T153X having the management authority for the management range, and the configuration for the setting items of the management range. It consists of a change policy T154X and a setting item T155X specific to each management range.

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

The above-mentioned SC approval policy is a policy indicating how many nodes among the nodes that executed the SC should return the approval before the SC execution result is described in the block as the correct result. It is expressed in the form of an n-of-node as in the configuration change policy T154X.

Further, the block acquisition execution authority represents the authority to acquire the block of the block chain through the API, and in the example of the figure, the conditional expression expresses that only the administrator of Org1 or Org2 can acquire the block information.
--- Tables, etc. ---

FIG. 5 shows the configuration change request T10 in this embodiment. In this embodiment, the configuration change request T10 is externally given to the BC system 1. The configuration change request T10 is in a list format, and is composed of a request ID (T11), a management range T12 to be configured, an item name T13, information before change T14, information after change T15, and outline T16.

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

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

Further, 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 in this example, it points to the "member node" in the management range "consortium".

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

Further, the changed information T15 represents the changed contents of the configuration change item T13 when the configuration change request T10 is used. In this embodiment, "newOrg" is added to the existing "Org1 to Org8" as the item name "member node" of the management range "consortium".
Further, the outline T16 is a description of the configuration change request T10 in natural language. This item is a value described as representing the intention of the configuration change.

Subsequently, 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 regularities indicating that when certain setting information is changed, other setting items are affected in the BC system 1.

The impact judgment rule T170 in this embodiment is not described in the management range unit such as the business A group or the transaction SC, but describes a common rule between layers such as a more general business layer or SC layer. Is.

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

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

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

Specifically, for organizational information and other information contained in smart contracts and consortium setting information, the parts described in the same word are extracted, and a person or an automatic system performs appropriate abstraction. , It is described in the influence determination rule T170 as a correlation.

Another method for creating the impact determination rule T170 is to extract setting items that have been changed at the same time from the history of past configuration changes in the BC system 1 and dynamically add them to the impact determination rule T170. Conceivable.
Further, it is also conceivable to define the network topology information determined from the business requirements determined in the upstream process or the like as the impact determination rule T170.

In this embodiment, the impact determination rule T170 is shared by the participants of the BC system 1, but access may be restricted based on the management authority of the node 100.

Further, FIG. 7 shows the influence confirmation item T30 extracted from the configuration information T150 by inputting the configuration change request T10 or the configuration confirmation request T20 by the confirmation item extraction unit 110.

The influence confirmation item T30 is composed of a request ID (T31), a management range T32 to be reconfigured, an item name T33, pre-change information T34, post-change information T35, and an outline T36.

Of these, the information T34 before change describes the current value of the impact confirmation item. Further, the changed information T35 is blank. Further, the outline T36 inherits the outline T16 of the configuration change request T10, and is described as representing the intention of the configuration change.
Further, FIG. 8 shows a configuration confirmation request T20 that summarizes the impact confirmation items to be transmitted for each administrator node in order to share the impact confirmation item T30 with other nodes.

The 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 content T24 before the change, a content T25 after the change, and an outline T26.

The configuration confirmation request T20 has the same format as the impact confirmation item T30, but the impact confirmation item T30 represents the impact confirmation item extracted for the configuration change request, whereas the configuration confirmation request T20 expresses it. It is defined as a separate request for each administrator node to send. Therefore, in the configuration confirmation request T20, the management range of each line is the same.
Subsequently, FIG. 9 shows an example of the confirmation item list T160 output to each node after the influence confirmation of the configuration change request T10 in this embodiment is completed.

The confirmation item list T160 is defined as a list for storing the configuration change request T10, the configuration confirmation request T30, and the influence confirmation 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 an outline T166.

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

Further, in this embodiment, in the case of Org3 having no reference authority for the configuration change request T10, only the confirmation items related to the business A group and the user management SC to which the own node has the authority are displayed in the confirmation item list T160.
--- Configuration change management method (Example 1) ---

Subsequently, the actual procedure of the configuration change management method in this embodiment will be described with reference to the figure. Various operations corresponding to the configuration change management method described below are realized by a program executed by each node 100 in the blockchain system 1 which is a configuration change management system. The program is composed of code for performing various operations described below.

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

Next, each node starting from the node that received the above-mentioned configuration change request T10 (that is, the corresponding nodes having authority in the management range T12) recursively performs the confirmation item extraction process (details are explained in FIG. 12). It is executed, the influence confirmation items to be confirmed across the management range in the BC system 1 are extracted, and the confirmation item list T160 is generated at each node (s2). Details of this step will be described later.
After that, each node in the BC system 1 displays the above-mentioned confirmation item list T160 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 confirmation item list T160 displayed by the input / output device 140 as described above. The above-mentioned administrator browses this screen 1000, confirms the contents of the confirmation item list T160, and makes a judgment of approval or correction of the configuration change based on the influence confirmation item.

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

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

If there is no problem with this, the approval button 1001 for approving the configuration change will be pressed. On the other hand, if there is a problem, the rejection button 1003 for rejecting the configuration change can be pressed, or the value of "information after change" in the confirmation item list T160 can be modified. When the above-mentioned administrator corrects the "changed information", the correction button 1002 for transmitting the correction content after the correction is pressed. Then, the node 100 that receives this transmits the corrected confirmation item information to another node that has authority in the management range of the corresponding setting item as a configuration change request (In the case of this embodiment, Org2, Org3, Org4, Send to each node of).

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

As a result of the above sharing, when the managers of all the nodes having authority in the management range T12 perform the approval process (s5: yes), each corresponding node performs the configuration change process according to the configuration change request T10. Batch execution at 180 (s6).

On the other hand, when the administrator of one or more of all the nodes having the authority in the management range T12 does not perform the approval process (s5: no), and a certain node corrects the configuration change by the administrator. When received (s7: yes), the modification is transmitted as a configuration change request to each node having authority in the management range T12 (s8), and processing is performed again from s1.

On the other hand, if the configuration change has not been corrected (s7: no) and the configuration change has been rejected (s9), each node performs the configuration change processing assuming that the configuration change has been rejected. No, the process ends.

In this embodiment, in the approval result sharing unit 130, the configuration change process is performed when all the nodes approve, but this is not the case, and the configuration change process is performed when a predetermined condition is satisfied. May be.

The predetermined conditions here include obtaining the approval of a node that satisfies the configuration change policy set in the no-of-administrator node format in each management range in the entire management range.

Further, in this embodiment, it is assumed that each node performs the configuration change process, but this is not the case either. For example, it is conceivable that the node representing each management range receives the approval result and issues the configuration change transaction to the BC system 1.
Here, the details of step s2 in the above flow, that is, the confirmation item extraction process, will be described based on the flow of FIG.

In this case, in this flow, one of the nodes participating in the BC system 1 (here, node X) is the main body, and the configuration change request T10 or the configuration confirmation request T20 (hereinafter, these are collectively referred to). It is a process that inputs (referred to as "request").
First, the node X checks whether the input request is already described in the confirmation item list T160 (s10).

As a result of the above check, if the request has already been described in the confirmation item list T160 (s10: yes), the node X ends the process. By this conditional branching process, the end condition of the recursive process is clarified, and the process as a whole is speeded up and lightened by not performing duplicate process.

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

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

Subsequently, the node X adds the above-mentioned request and the impact confirmation item T30 extracted in s13 to the confirmation item list T160 as an impact confirmation item for which the administrator performs approval processing on this node X (s14).

Further, the node X acquires a list of other nodes having management authority for the management range of the influence 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 influence confirmation item T30 extracted in s13 as the configuration confirmation request T20 to the node list acquired in s15, and executes the confirmation item extraction process (s16).

By repeating such processing, the influence confirmation item T30 extracted within the scope of the authority of the node X is shared with other nodes as the configuration confirmation request T20 by inputting the configuration change request T10, and the sharing destination node shares the configuration confirmation request. A chain occurs in which the influence confirmation item is extracted again with T20 as an input and shared as a configuration confirmation request T20 with other nodes.
By the above processing, the influence of the configuration change is confirmed not only on the node authorized for the configuration change request T10 but also on the entire BC system.

In this embodiment, the processing unit that communicates with other nodes such as the request transmitting unit 120, the request receiving unit 121, and the approval result sharing unit 130 is defined separately, but this summarizes the communication functions with other nodes. It may be defined as a processing unit.

As one of the implementations to realize this, a method using a smart contract can be considered. Specifically, a smart contract in which all organizations participate separately from business is created, and configuration change requests, configuration confirmation requests, and approval results are held in state information (held on the blockchain) under each management scope authority. Data) to be shared.

In addition, a method to realize this by using a private group (information can be shared only between specific organizations within a smart contract) (Hyperledger Fabric”, [online], [Search on February 27, 2018], Internet < URL: http: // hyperledger-fabric.readedocs.io/en/latest/>) is also conceivable.

Further, in this embodiment, the management structure has a tree shape, but this is not the case in practice. For example, even in the case of inter-SC cooperation or inter-business group cooperation, the confirmation item extraction process can be performed without any problem.

Further, the scope of application of this embodiment is not limited to the BC system. The management authority may also span multiple organizations for apps and operation management tools that work with the BC system. At this time, this method can be applied by defining apps and tools as a new management scope. Even a distributed system completely independent of the BC system can be applied when there are a plurality of control ranges.

As described above, when the configuration of the BC system 1 which is decentralized is changed, it is possible to confirm all the impact confirmation items of the BC system as a whole within the scope of the authority of each organization.

In addition, the impact confirmation items for each organization are collectively output, and the administrator approves or corrects each node, so that the confirmation man-hours for the entire BC system can be reduced.

In addition, by sharing the results approved by the administrators between the nodes and performing the configuration change processing collectively under the prescribed rules, the risk of errors and system outages is reduced compared to performing the configuration change processing individually. It is also possible. Further, by recursively performing the confirmation item extraction process, the end condition of the process can be clarified.

In addition, by sharing the configuration change request, configuration confirmation request, and approval result using a smart contract, the processing of Example 1 can be automated on the BC system, and a trail from which the impact confirmation items have been extracted can be left. ..

In addition, the recursive processing method is used to search whether the configuration change request and configuration confirmation request shared by other nodes match the confirmation item list of the own node and terminate the processing if they match. The amount of calculation and time can be reduced.
[Example 2]

In the first embodiment, the administrator of the node 100 gives an approval or correction instruction to the confirmation item list of each organization through the input / output device 140. However, when modifying the impact confirmation items, the node administrator had to consider the details of the modification. Therefore, it is premised that the node administrator needs some knowledge about the setting of the BC system 1.

Therefore, in this embodiment, by applying the impact judgment rule to which the conditional expression is given, the correction plan is output together with the impact confirmation item for the important impact confirmation item in the confirmation item extraction process, and this is the node management. The form presented to the person is shown. This makes it possible for the node administrator to modify the impact confirmation items without having to think about the modification details.

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

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

Further, as a processing flow, the effect confirmation item T30 extracted by the confirmation item extraction unit 110 is given the changed information unlike the first embodiment. After that, the changed information is inherited by the configuration confirmation request T20 and the confirmation item list T160, and is displayed to the node administrator as a correction proposal. In addition, the above-mentioned correction-required flag is also added to the confirmation item list T160.

Here, the influence determination rule T170P in this embodiment is shown in FIG. The impact determination rule T170P in this embodiment is defined as a set of rules that describe the configuration requirements of the BC system 1.

As such a requirement, for example, if OrgX is included in the SC approval policy of the SC layer, it can be assumed that OrgX must be a member node in the business group that reports directly to it. Further, for example, regarding Role, which is a unique setting item indicating a role in a group, if a certain organization is defined as Role = Y as a rule derived from business requirements, it is necessary to be an administrator node of user management SC. It is also possible 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 influence source T172P and the influence destination T175P are composed of a management layer (T173P, T176P) and an item name (T174P, T177P), respectively.

This is an addition of the conditional expression T178P to the influence determination rule T170 of the first embodiment. The conditional expression T178P expresses the relationship between the influence source T172P and the influence destination T175P by the conditional expression. For example, in the line of ID1, it means that OrgX of the influence source (node belonging to the SC approval policy) is always included in the member node of the parent business group.

When the influence determination rule T170P is used for the configuration change request T10, the changed information T35 calculated based on the conditional expression T178P is given to the output influence confirmation item T30. The impact confirmation item T30 to which the changed information is given indicates that it is not the “item that should be confirmed” in the first embodiment but the “item that needs to be specifically changed in this way”. This is a confirmation item that the node administrator should pay more attention to than a normal confirmation item.

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

The confirmation item list T160 in this embodiment is shown in FIG. The confirmation item list T160 is composed of the same ID (T161) as in the first embodiment, the management range T162, the item name T163, the information before change T164, the information after change T165, the outline T166, and the correction-required flag T167. ..

The correction required flag T167 is a flag given by the impact confirmation item management unit 190 to the impact confirmation item to which the changed information is given by the conditional impact 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 the changed information is described. This changed information is displayed to the node administrator as a correction proposal of the impact confirmation item. In other words, the correction required flag is notified to the node administrator together with the correction proposal.
--- Configuration change management method (Example 2) ---

The flow of the confirmation item extraction process in this embodiment is shown in FIG. As a premise, the overall flow is the same as in the first embodiment (FIG. 10). On the other hand, the difference in the confirmation item extraction process is that if the input is a configuration confirmation request with information after the change, a correction-required flag is set and added to the confirmation item list.

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

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

When the input is not a configuration confirmation request with information after the change (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, when the input is a configuration confirmation request with information after the change (s20: yes), the node X sets the request as an impact confirmation item having a high priority to be corrected in the confirmation item list T160 with a correction required flag. Add (s21).

After adding the above request to the confirmation item list T160, the node X extracts the influence judgment rule to which the own node has the authority (s12) and extracts the influence confirmation item from the influence judgment rule (s12) as in the first embodiment. s13).
After that, the node X determines whether or not each of the influence confirmation items extracted in s13 is described in the changed information as a process peculiar to the second embodiment (s22).

As a result of this determination, when there is no description of the changed information in the impact confirmation item (s22: No), the node X adds the impact confirmation item to the confirmation item list T160 of its own node as in the first embodiment (s14). ..

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

After that, as in the first embodiment, the confirmation item extraction process of acquiring the list of other nodes having management authority for each impact confirmation item (s15) and inputting the impact confirmation item as the confirmation item list T160 for that node is performed. Performs recursive processing such as execution (s16).

After the above-mentioned recursive processing is completed, the administrator for each node confirms the confirmation item list T160 for each node via the input / output device 140. At this time, the node X sets the modified configuration confirmation request added to the confirmation item list T160 with the modification required flag in s20 as the confirmation item to be modified, and the node administrator displays the modification proposal. Display for. At this time, if there is a correction-required flag, it may be displayed in color.

By adopting this form, the node administrator can distinguish high-priority impact confirmation items, and by approving the displayed revision proposal, the impact confirmation items do not have to be considered by themselves. Can be modified.

Further, even if the node administrator does not have a certain level of knowledge about the BC system 1, it is possible to efficiently find the items requiring correction in the configuration change of the BC system 1 and correct them as appropriate.

Although the best mode for carrying out the present invention has been specifically described above, the present invention is not limited to this, and various modifications can be made without departing from the gist thereof.

According to this embodiment, when changing the configuration of the BC system, it is possible to efficiently confirm the setting items that are not omitted in the entire BC system while using only the information that can be known for each organization. This enables accurate configuration change processing while maintaining the decentralization characteristic of the BC system. That is, when the configuration of the BC system is changed, it is possible to efficiently confirm the system as a whole with good accuracy within the authority of each organization.

The description herein reveals at least the following: That is, in the configuration change management method of the present embodiment, each node extracts an impact confirmation item from the configuration information in the node by using a predefined impact determination rule when extracting the impact confirmation item. May be.

According to this, it is possible to streamline the extraction of impact confirmation items, and by extension, when changing the configuration of the BC system, it is possible to perform more efficient confirmation of the entire system with good accuracy within the authority of each organization. It becomes.

Further, in the configuration change management method of the present embodiment, when each node extracts the impact confirmation item, as the impact determination rule, the smart contract or the correlation based on the common keyword between the configuration information is specified. The impact confirmation item may be extracted from the configuration information in the node by using the impact determination rule generated by.

According to this, it is possible to accurately extract the impact confirmation items according to the rules based on the past results by knowledgeable people, etc., and by extension, when changing the configuration of the BC system, within the authority of each organization, the entire system Therefore, more efficient confirmation can be performed with good accuracy.

Further, in the configuration change management method of the present embodiment, the impact determination rule that each node identifies an item that has been changed at the same time based on the configuration change history in the blockchain system and defines the item as an impact confirmation item. May be generated or updated.

According to this, it is possible to generate and update the impact judgment rule based on the configuration change after consensus building at the administrator node etc. in the BC system, and under the rule based on the judgment result by a person with skill and experience. It is possible to extract the influence confirmation items of. As a result, when changing the configuration of the BC system, it is possible to perform more efficient confirmation of the entire system with good accuracy within the authority of each organization.

Further, in the configuration change management method of the present embodiment, each node uses a smart contract to make at least one of the configuration change request, the impact confirmation item, and the approval result regarding the impact confirmation item with another node. You may share it.

According to this, sharing of impact confirmation items between nodes becomes efficient, and by extension, when changing the configuration of the BC system, more efficient confirmation of the entire system is performed with good accuracy within the authority of each organization. It becomes possible to do.

Further, in the configuration change management method of the present embodiment, each node holds the impact confirmation item shared by the other node by the configuration change request or the configuration confirmation request from the other node regarding the impact confirmation item. If the impact confirmation item for the item has been extracted by comparing with the list of impact confirmation items to be performed, the subsequent recursive processing may be omitted.

According to this, it is possible to eliminate the waste of recursive processing, and by extension, when changing the configuration of the BC system, it is possible to perform more efficient confirmation of the entire system with good accuracy 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 as the entire blockchain system, a list of impact confirmation items for each organization is sent to the node administrator. It may be displayed and a predetermined process corresponding to the approval, correction, or rejection of the configuration change, which is the confirmation result 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 item and use it as a material for the judgment, and the processing based on the result of such judgment is automatically executed. Will be done. As a result, when changing the configuration of the BC system, it is possible to perform more efficient confirmation of the entire system with good accuracy 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 confirmation item for each organization among the nodes, and the approval result satisfies a predetermined agreement condition. , The configuration change processing may be performed collectively, or the configuration change processing may be rejected when the agreed conditions are not satisfied.

According to this, after consensus building between the administrator nodes, the configuration change process can be comprehensively executed / rejected. More efficient confirmation can be performed 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 between the nodes, and the approval result does not satisfy the predetermined agreement condition, and the impact confirmation When a part of the list of items is modified by the administrator, the content of the modification process is shared with other nodes as a configuration change request, and the impact confirmation item extraction process and the impact are related to the configuration change request. The processing of mutual sharing and recursive processing of the confirmation items between the nodes and the extraction of the influence confirmation items to be confirmed as the entire blockchain system may be re-executed.

According to this, the modification regarding the configuration change request corresponds to the situation proposed by the administrator, and this can be processed as a new configuration change request. As a result, BC
When changing the system configuration, it is possible to perform more efficient confirmation of the entire system with good accuracy within the authority of each organization.

Further, in the configuration change management method of the present embodiment, each node should prioritize confirmation or correction in the blockchain system by using a predetermined conditional expression impact determination rule when extracting the impact confirmation item. The impact confirmation items may be extracted.

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

1 BC system (configuration change management system)
100 Node 101 Arithmetic logic unit 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 unit T10, T20 Configuration Change request T30 Impact confirmation item T150 Node possession BC configuration information T151 Node possession BC configuration information T152 Node possession BC configuration information T150X Management range X Setting item list T160, T161 Confirmation item list T170 Impact judgment rule 200 Node 300 node

Claims (12)

Each node that makes up the blockchain system
Regarding the configuration change request for the blockchain system, the impact confirmation items are extracted based on the configuration information of the organization to which the node belongs, the impact confirmation items are shared and recursively processed between the nodes, and the blockchain system A configuration change management method characterized by extracting impact confirmation items that should be confirmed as a whole. Each of the above nodes
The configuration change management method according to claim 1, wherein when extracting the impact confirmation item, the impact confirmation item is extracted from the configuration information in the node by using a predefined impact determination rule. Each of the above nodes
When extracting the impact confirmation item, the impact determination rule generated by specifying the correlation based on the common keyword between the smart contract or the configuration information is used as the impact determination rule, and the configuration information in the node is used. The configuration change management method according to claim 2, wherein the impact confirmation item is extracted from. Each of the above nodes
The second aspect of claim 2 is characterized in that, based on the configuration change history in the blockchain system, items that have been changed at the same time are specified, and the impact determination rule that defines the item as an impact confirmation item is generated or updated. Configuration change management method. Each of the above nodes
The configuration change management according to claim 1, wherein at least one of the configuration change request, the impact confirmation item, and the approval result for the impact confirmation item is shared with another node using a smart contract. Method. Each of the above nodes
The impact confirmation items shared by other nodes by the configuration change request or the configuration confirmation request from other nodes related to the impact confirmation item are compared with the list of impact confirmation items held by the own node, and the impact confirmation for the item is performed. The configuration change management method according to claim 1, wherein when the extraction of items is completed, the subsequent recursive processing is omitted. Each of the above nodes
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 approval or correction of the configuration change which is the confirmation result by the administrator is displayed. The configuration change management method according to claim 1, wherein a predetermined process corresponding to the rejection is executed. Each of the above nodes
The approval result of the impact confirmation item for each organization is shared between the nodes, and when the approval result meets the predetermined agreement conditions, the configuration change process is collectively performed or the agreement conditions are not satisfied. The configuration change management method according to claim 7, wherein the configuration change processing is rejected in some cases. Each of the above nodes
When the approval result of the impact confirmation item for each organization is shared between the nodes, the approval result does not meet the predetermined agreement conditions, and a part of the list of the impact confirmation items is corrected by the administrator. , The content of the modification process is shared with other nodes as a configuration change request, and regarding the configuration change request, the effect check item extraction process, mutual sharing and recursive process between the nodes for the impact check item, and the block. The configuration change management method according to claim 7, wherein each process of extracting the impact confirmation item to be confirmed as the entire chain system is re-executed. Each of the above nodes
The second aspect of claim 2 is characterized in that, when extracting the impact confirmation items, the impact confirmation items to be confirmed or corrected with priority in the blockchain system are extracted by using a predetermined conditional expression impact determination rule. Configuration change management method. In a blockchain system composed of a plurality of nodes, each of the plurality of nodes performs an impact confirmation item extraction process based on the configuration information of the organization to which the node belongs with respect to a configuration change request for the blockchain system. , A configuration change management system characterized in that the impact confirmation items are shared and recursively processed between nodes, and the impact confirmation items to be confirmed as the entire blockchain system are extracted. A node that constitutes a blockchain system. Regarding a configuration change request for the blockchain system, the impact confirmation item is extracted based on the configuration information of the organization to which the node belongs, and the impact confirmation item is shared with other nodes. A node characterized in that it shares and recursively processes with each other and extracts impact confirmation items to be confirmed as the entire blockchain system.

Images