CN112650810A

CN112650810A - Detection method, classification method, and information processing apparatus

Info

Publication number: CN112650810A
Application number: CN201910958710.8A
Authority: CN
Inventors: 华松; 皮冰锋; 孙俊
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2019-10-10
Filing date: 2019-10-10
Publication date: 2021-04-13

Abstract

The disclosure provides a detection method, a classification method, and an information processing apparatus. The detection method for the block chain needing permission comprises the following steps: analyzing the configuration file of the block chain; determining a plurality of detection modes of predetermined types of the configuration file based on the analysis result, wherein the predetermined types comprise a security type, a performance type and a functionality type; detecting the reasonability of each detection mode of the configuration file; and providing a rationality detection result of the block chain based on the detected rationality of each detection mode.

Description

Detection method, classification method, and information processing apparatus

Technical Field

The present disclosure relates generally to detection and classification of blockchains, and more particularly, to a detection method for a blockchain requiring permission, an information processing apparatus capable of implementing the detection method, and a classification method for classifying a blockchain using a rationality detection result provided by the detection method.

Background

With the rapid development of the blockchain technology, some concepts of blockchain-based Decentralized Application (DApp) are emerging, and these applications can be understood as a collection of intelligent contract codes and peripheral codes running on the blockchain. Unlike traditional software architectures, blockchain networks have decentralized (distributed) asynchronous execution.

Blockchain networks are generally divided into public chains that are public and federation chains or private chains that require permission. For a federation chain, the overall architecture of the network is often very complex, containing many components, and it is therefore difficult to fully understand the rationality of the overall architecture in the development and design of federation chain-based decentralized applications. On the other hand, since an application requiring a licensed alliance chain or private chain may be used in a scenario involving significant benefits (e.g., a financial-related scenario such as a bitcoin, ethercoin-related scenario), there are serious consequences to the application once the rationality of the overall architecture is questioned, resulting in an application error.

Therefore, it is desirable to provide a method for helping developers and managers to understand the rationality of the blockchain framework, so as to improve the quality of blockchain applications.

Disclosure of Invention

The following presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. It should be understood that this summary is not an exhaustive overview of the invention. It is not intended to determine the key or critical elements of the present invention, nor is it intended to limit the scope of the present invention. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is discussed later.

In view of the need to understand the rationality of the blockchain framework, it is an object of the present invention to provide a detection method for blockchains requiring permission, which can help developers and managers to understand the rationality of the blockchain network architecture.

According to an aspect of the present disclosure, there is provided a method for detecting a block chain requiring a grant, the method including: analyzing the configuration file of the block chain; determining a plurality of detection modes of predetermined types of the configuration file based on the analysis result, wherein the predetermined types comprise a security type, a performance type and a functionality type; detecting the reasonability of each detection mode of the configuration file; and providing a rationality detection result of the block chain based on the detected rationality of each detection mode.

According to another aspect of the present disclosure, there is also provided a method for classifying a blockchain requiring permission, the method including obtaining a rationality detection result of the blockchain by using the detection method of the embodiment of the present disclosure; the obtained rationality detection result is input to a classification model obtained in advance to obtain the type of the block chain.

According to another aspect of the present disclosure, there is provided an information processing apparatus including a processor configured to: analyzing a configuration file of a block chain needing permission; determining a plurality of detection modes of predetermined types of the configuration file based on the analysis result, wherein the predetermined types comprise a security type, a performance type and a functionality type; detecting the reasonability of each detection mode of the configuration file; and providing a rationality detection result of the block chain based on the detected rationality of each detection mode.

According to other aspects of the present disclosure, there is also provided a program causing a computer to implement the detection method and/or the classification method as described above.

According to yet another aspect of the present disclosure, there is also provided a corresponding storage medium storing machine-readable instruction code, which, when read and executed by a machine, is capable of causing the machine to perform the above-described detection method and/or classification method.

The foregoing can provide one or more of the following benefits, according to various aspects of embodiments of the present disclosure: by using the detection method for the blockchain needing permission according to the embodiment of the disclosure, developers and managers can be helped to know the reasonability of the blockchain network architecture in multiple aspects of safety, performance, functionality and the like, and the method is beneficial to improving the efficiency of development and management and the quality of blockchain application. In addition, the classification method for classifying the block chain by using the rationality detection result provided by the detection method can help developers and managers to better understand the characteristics of the block chain, so as to assist in deeply optimizing the block chain and/or selecting a proper block chain for different application scenes.

These and other advantages of the present disclosure will become more apparent from the following detailed description of the preferred embodiments of the present disclosure when taken in conjunction with the accompanying drawings.

Drawings

The disclosure may be better understood by reference to the following description taken in conjunction with the accompanying drawings, in which like or similar reference numerals identify like or similar parts throughout the figures. The accompanying drawings, which are incorporated in and form a part of this specification, illustrate preferred embodiments of the present disclosure and, together with the detailed description, serve to explain the principles and advantages of the disclosure. Wherein:

fig. 1 is a flow chart schematically illustrating an example flow of a detection method according to one embodiment of the present disclosure.

Fig. 2 is a schematic diagram schematically illustrating a system level of a blockchain.

Fig. 3 is an explanatory diagram for explaining an example of a profile section associated with one example detection pattern determined in the detection pattern determining step in the detection method shown in fig. 1.

Fig. 4 is an explanatory diagram for explaining an example of a profile section associated with another example detection pattern determined in the detection pattern determination step in the detection method shown in fig. 1.

Fig. 5 is an explanatory diagram for explaining an example of a profile section with which still another example detection pattern determined in the detection pattern determination step in the detection method shown in fig. 1 is associated.

Fig. 6 is an explanatory view schematically showing an example of the rationality detection result provided in the detection result providing step in the detection method shown in fig. 1.

Fig. 7 is a schematic block diagram schematically illustrating one example structure of a detection apparatus according to an embodiment of the present disclosure.

Fig. 8 is a flowchart schematically illustrating an example flow of a classification method of classifying a blockchain applying a rationality detection result obtained by a detection method according to an embodiment of the present disclosure.

Fig. 9 is a block diagram showing one possible hardware configuration that can be used to implement the detection method and apparatus, the classification method, and the information processing device according to the embodiments of the present disclosure.

Detailed Description

Exemplary embodiments of the present invention will be described hereinafter with reference to the accompanying drawings. In the interest of clarity and conciseness, not all features of an actual implementation are described in the specification. It will of course be appreciated that in the development of any such actual embodiment, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which will vary from one implementation to another. Moreover, it will be appreciated that such a development effort might be complex and time-consuming, but would nevertheless be a routine undertaking for those of ordinary skill in the art having the benefit of this disclosure.

It should be noted that, in order to avoid obscuring the present invention with unnecessary details, only the device structures and/or processing steps closely related to the solution according to the present invention are shown in the drawings, and other details not so relevant to the present invention are omitted.

According to one aspect of the present disclosure, a detection method for a block chain requiring a grant is provided. Fig. 1 is a flow chart schematically illustrating an example flow of a detection method 100 for detecting the rationality of a block chain requiring admission according to an embodiment of the present disclosure.

As shown in fig. 1, the detection method 100 may include: a configuration file analyzing step S101, analyzing the configuration file of the block chain; a detection mode determining step S103 of determining a plurality of detection modes of predetermined types of the configuration file based on the parsing result, the predetermined types including a security type, a performance type, and a functionality type; a rationality detecting step S105 of detecting the rationality of each detection mode of the configuration file; and a detection result providing step S107 of providing a block chain rationality detection result based on the detected rationality of each detection mode.

By using the detection method of the embodiment, developers and managers can be helped to know the reasonability of the blockchain network architecture (more specifically, configuration files of the blockchain network) in multiple aspects of safety, performance, functionality and the like, which is beneficial to improving the efficiency of development and management and the quality of blockchain application.

The detection method of the embodiment can be applied to various block chains requiring permission, and can help developers and managers to know about rationality problems possibly existing in the complex architecture of the block chains. As an example, the blockchain to which the detection method of the present embodiment is applied may include a federation blockchain or a private blockchain.

Hereinafter, example processing performed in each step of the detection method 100 of the present embodiment shown in fig. 1 will be described taking, as an example, a profile of a super ledger, which is a federation chain requiring permission, such as illustrated in fig. 3 to 5. It can be understood by those skilled in the art based on the present disclosure that the detection method of the present embodiment can be applied to other block chains that require permission, and will not be described herein.

Reference is first made to fig. 1. After the test method 100 of the present embodiment is started, in a profile parsing step S101, a profile of a block chain is parsed. The configuration files for the blockchain may be provided, for example, by a user who is a developer or manager of the blockchain application, and the developer uses the configuration files to set the functions and/or parameters in the blockchain network architecture accordingly to implement the desired application.

In this example, the profile that the user provides to the profile parsing step S101 is a profile of a super book. The configuration file of the super ledger contains two types, namely the Yaml configuration file and the Shell startup script. The Yaml configuration file includes the following three files: (1) crypto-configuration (Crypto _ configuration for short), which is responsible for configuring certificate-related contents of the network, such as the number of certificates, certificate hierarchy, and the like; (2) configuration-transaction (ConfigTx) responsible for configuring the initial Configuration of the entire network, including the initial created blocks, organizational structures, access policies, etc.; (3) a Docker composition file, which is a Docker container configuration file that opens the entire network, includes the actual configuration information of all nodes, such as ports, IPs, environment variables, etc. The Shell start script includes the following two files: (1) sh for starting and managing all nodes of the network; (2) sh for configuring the whole network to a required initial state after all nodes have been started, e.g. involving joining of nodes into tunnels, installation of smart contracts, etc.

In the multiple configuration files of the super ledger, a single configuration file relates to many configuration parameters, and the configuration parameters in different configuration files are often correlated with each other, so that direct analysis is difficult. With the process of the profile parsing step S101, the contents of these profiles can be parsed into a clear document structure, for example, according to the concept of network components, thereby facilitating the analysis and detection of the next step. As an example, in the parsing process of the configuration file, the contents of all configuration files may be mapped to a specific database class and saved locally. Those skilled in the art can understand that the parsing process in step S101 can be implemented by various existing parsing manners, which are not described herein again.

After the parsing process of the profile parsing step S101, the detection method 100 proceeds to a detection pattern determining step S103 to determine, based on the parsing result of the profile, a risk that may exist in each profile or a problem that requires attention of the user from the viewpoint of security, performance and functionality, that is, to determine a parameter or configuration in each profile that may affect security, performance and/or functionality, as a detection pattern that subsequently requires rationality detection.

In a preferred embodiment, when determining the detection modes, one of a plurality of impact levels corresponding to each detection mode may be determined accordingly to indicate the impact of the detection content in the detection mode, in particular the consequences on the system resulting from detection of an unreasonable or unsuitable situation. By way of example, such impact levels may include errors, warnings, and prompts, where an "error" indicates that the system is rendered inoperable; "warning" indicates that the system may be in danger; "prompt" means alerting the user to focus but not generally affecting the operation of the system.

Furthermore, in a preferred embodiment, when determining a detection pattern, one or more layers of the block chain associated with the detection pattern may also be determined accordingly. As an example, fig. 2 schematically shows a system hierarchy of a superbugt-based blockchain application. As shown in fig. 2, the system of block chain application based on the super ledger book is divided into six levels, which are from top to bottom:

1. an application layer: information about the actual application and its needs towards the end user.

SDK and tool layer: application layer oriented SDK (application software development kit) and related tool libraries.

3. Intelligent contract layer: business logic of the associated intelligent contracts and their policies are applied.

4. Block chain frame layer: parts and features related to the blockchain framework, including decentralized consensus protocols, etc.

5. Account book data layer: transaction data, status databases, ledger data models, and the like.

6. Network and infrastructure layer: underlying physical devices, data storage devices, and the like.

For developers of a particular blockchain application, it is not necessary to be particularly concerned with which level of the blockchain system each function or parameter is associated when setting up the particular function and parameter in the configuration file. However, in the preferred example of the detection method of the present embodiment, while determining the detection modes, the system layer (e.g., which layer or layers in the levels 1 to 6 shown in fig. 2) of the blockchain associated with each detection mode may be determined to provide a developer who is a user of the detection method of the present embodiment with a more comprehensive and in-depth understanding of the rationality of the blockchain.

Example detection patterns 1 to 14 determined for the respective profiles using the detection pattern determining step S103 from the viewpoint of security, performance, and functionality will be described below in conjunction with examples of specific parameters in the profiles shown in fig. 3 to 5. In the preferred embodiment, for each detection pattern, in addition to determining what the detection pattern needs to detect and defining criteria for determining whether the detection pattern is reasonable or appropriate, an impact level ("error", "warning" or "cue") corresponding to the detection pattern and one or more system layers (e.g., one or more of layers 1-6 shown in FIG. 2) of the blockchain associated with the detection pattern are additionally determined. Those skilled in the art will appreciate that the additional determinations of the hierarchy and system layers described above are preferred operations in this embodiment and may be omitted.

Example detection mode 1 detection of TLS settings

The detection of the TLS (transport layer security protocol) setting is of a security type, in particular related to the security of the communication. The detection of the TLS setting involves whether TLS communication is open for all network participants, including all network-related nodes, peer nodes, rank nodes, clients, Kafka nodes, Zookeeper nodes, and so on.

More specifically, the detection mode is primarily related to a Docker composition file configuration file, which may include, for example, detecting a setting of a parameter characterizing whether TLS communications are on. FIG. 3 shows a sample of parameters in the Docker composition file configuration file related to TLS settings, where the parameter "ORDERER _ GENERAL _ TLS _ ENABLED" is set to "true" indicating that TLS communication is ENABLED, which is beneficial to the communication security of the system.

In the preferred embodiment, it may be defined that it is unreasonable to detect that TLS communication is not turned on in the detection mode, and a level of influence corresponding to the detection mode (e.g., a level of consequences caused when there is an unreasonable presence in the detection mode) may be determined as a warning. Further, it may be determined that the system layer associated with the detection pattern is layer 6 (network and infrastructure layer) shown in fig. 2.

Example detection mode 2 detection of CouchDB Security

The detection of the security of the CouchDB belongs to the security type, in particular in relation to the setting of the security of the CouchDB database container. The detection mode involves a Docker composition file profile, which may include, for example, detecting whether a username and PASSWORD (such as parameters "couchhdb _ USER" and "couchhdb _ PASSWORD") of the CouchDB database container are set.

In the present preferred embodiment, it may be defined that the user name or password for which the CouchDB database container is detected in the detection pattern is not set unreasonable, and the influence level corresponding to the detection pattern is determined as the warning. Further, it may be determined that the system layer related to the detection pattern is the 5 th layer (ledger data layer) shown in fig. 2.

Example detection mode 3 detection of Consensus mechanism

The detection of the Consensus mechanism is of the security type. The detection mode relates to the Config-TX profile and may, for example, include detecting the type of Consensus mechanism set by the parameter "order. The types of the consensus mechanisms comprise Solo, Kafka and RAFT, wherein the Solo type consensus mechanism is insecure and fault-tolerant, and the Kafka type consensus mechanism and the RAFT type consensus mechanism are high in safety and fault tolerance.

In the preferred embodiment, since each type of Consensus mechanism does not cause system errors or affect system operation, but needs to remind the user of the system, it can be defined as unreasonable no matter what type of Consensus mechanism is detected. Further, an impact level corresponding to the detection of the Consensus mechanism may be determined as a cue. In addition, it can be determined that the system layer related to the detection mode is the 4 th layer (the blockchain frame layer) shown in fig. 2.

Example detection mode 4 detection of simple endorsement policy

Simple endorsement policy detection belongs to both the security type and the performance type, which detects the type of endorsement policy. Sh files, for example, may include detecting the type of endorsement policy defined by a Peer chalncodo instance-related command line statement. The types of the endorsement policy include "OR" (OR) AND ", AND fig. 4 shows a sample of a Peer chalncode instance related command line statement in a script. Note that an OR type of policy can provide higher performance, but security can be reduced; AND type policies can improve security but performance can degrade.

In the present preferred embodiment, in order to ensure that the user notices the selection of the endorsement policy, it may be defined that the detection of the OR type OR the AND type in the detection pattern is both set to unreasonable, AND the impact level corresponding to the detection pattern is determined as the warning. Further, it may be determined that the system layers associated with the detection mode are layer 2 (SDK and tool layer) and layer 3 (smart contract layer) shown in fig. 2.

Example detection mode 5 detection of Block time and Block size

The detection of block time and block size is of the performance type. The detection mode involves several parameters in the Config-TX profile that represent the block time and block size, respectively. When any one of the block time and the block size reaches a specified value, the system performs a block out operation. If the block time and the block size are set to be too large or too small, the block output efficiency of the system is affected.

In the present preferred embodiment, it may be defined that it is unreasonable to detect that the block time and/or the block size in the detection mode are set too large or too small, and the influence level corresponding to the detection mode may be determined as the cue. Further, it can be determined that the relevant system layer is layer 4 (blockchain frame layer) shown in fig. 2.

Example detection mode 6 detection of Complex endorsement policy

The detection of complex endorsement policies belongs to both performance and functional types. Sh files, for example, more complex detection of endorsement policies, such as detecting nesting of endorsement policies, conflict problems after nesting, and the like, can be performed for the order line statements related to the Peer chain instigation.

In the present preferred embodiment, nesting of endorsement policies detected in the detection pattern, conflict problems after nesting, and the like may be defined unreasonably, and the level of influence corresponding to the detection pattern may be determined as a warning. Further, it may be determined that the system layers associated with the detection mode are layer 2 (SDK and tool layer) and layer 3 (smart contract layer) shown in fig. 2.

Example detection mode 7 detection of selection of CouchDB and LevelDB

The detection of the selection of CouchDB and LevelDB belongs to both performance type and function type. The detection mode involves a Docker composition file profile that determines whether CouchDB or LevelDB is selected by a particular state database. Fig. 5 shows a sample of parameters in the Docker composition file profile related to the selection of the STATE database, where the parameter "CORE _ LEDGER _ STATE _ database" is set to "CouchDB", indicating that CouchDB is selected. From the performance point of view, for the general query, the LevelDB efficiency is higher, and the CouchDB efficiency is lower. From a functional perspective, however, CouchDB can support complex range queries and conditional queries, while LevelDB does not.

In the preferred embodiment, since selecting either CouchDB or level db does not cause a system error but requires a user to be alerted, it may be defined as unreasonable no matter which one of CouchDB and level db is selected in the detection mode. Further, an influence level corresponding to the detection mode may be determined as a cue. In addition, it may be determined that the system layer related to the detection pattern is the 5 th layer (ledger data layer) shown in fig. 2.

Example detection mode 8 detection of Domain errors

The detection of a domain error is of the functional type for detecting whether the domains of all participants are consistent. The detection mode involves a crypt-config profile that detects whether each of the organizational domains, i.e., Domain attribute suffixes, are consistent. To ensure that the system is running, the domains of all participants are consistent.

In the present preferred embodiment, it may be defined that the domain inconsistency of the detected participant in the detection pattern is not unreasonable, and the influence level corresponding to the detection pattern may be determined as an error. Further, it can be determined that the system layer related to the detection mode is the 4 th layer (block chain frame layer) shown in fig. 2.

Example detection mode 9 detection of the syntax of a Yaml File

The detection of the syntax of the Yaml file belongs to the functional type. The detection mode involves three Yaml files in the configuration file, which detect whether there are grammatical errors in these Yaml files. In order to ensure that the system runs, the Yaml file cannot have grammar errors.

In the present preferred embodiment, it may be defined that it is unreasonable to detect that there is a syntax error in the Yaml file in the detection pattern, and the influence level corresponding to the detection pattern may be determined as an error. Further, it can be determined that the system layer related to the detection mode is the 4 th layer (block chain frame layer) shown in fig. 2.

Example detection mode 10 detection of parameter variable write death

The detection of the parameter variable write-death belongs to the functional type. The detection mode involves individual profiles which detect whether parameters that need to be transferred in all profiles are dead written. If the parameters needing to be transferred are written to death, the hidden danger of the system can be caused.

In the present preferred embodiment, it may be defined that the parameter detected to be transferred in the detection pattern is not unreasonably written down, and the influence level corresponding to the detection pattern may be determined as a warning. Further, it can be determined that the system layers related to the detection mode are the layer 1 (application layer) and the layer 2 (SDK and tool layer) shown in fig. 2.

Example detection mode 11 detection of component missing

The detection of component absence is of a functional type. The detection mode involves individual profiles that detect whether the configuration of the necessary components of the network is missing. The parameters necessary for the necessary components of the network must be configured or the network cannot be opened.

In the present preferred embodiment, it may be defined that the detection of the component missing in the detection pattern is unreasonable, and the influence level corresponding to the detection pattern may be determined as an error. Further, it can be determined that the system layer related to the detection mode is the 4 th layer (block chain frame layer) shown in fig. 2.

Example detection mode 12 detection of configuration parameter inconsistency

The detection of configuration parameter inconsistencies is of the functional type. The detection mode relates to individual profiles, which detect whether parameters of corresponding parts of different profiles are consistent. The parameters of the corresponding parts of the different profiles must be consistent otherwise errors in the system will result.

In the preferred embodiment, it may be defined that the inconsistency of the parameters of the respective parts of the detection pattern for which different profiles are detected is not reasonable, and the impact level corresponding to the detection pattern may be determined as an error. Further, it can be determined that the system layer related to the detection pattern is layer 1 (application layer) shown in fig. 2.

Example detection mode 13 detection of Dockercpose Profile syntax

The detection of the Docker composition profile syntax belongs to the function type. The detection mode involves a Docker composition profile that detects whether there is a syntax error for the profile of the Docker composition tool. The configuration file of the Docker composition tool must conform to the specific syntax of the Docker composition, otherwise it will cause system errors.

In the present preferred embodiment, it may be defined that it is not reasonable to detect that the Docker composition profile in the detection pattern does not conform to the specific syntax, and the influence level corresponding to the detection pattern may be determined as an error. Further, it can be determined that the system layer related to the detection mode is the 4 th layer (block chain frame layer) shown in fig. 2.

Example detection mode 14 detection of Kafka/Zookeper correlation

The Kafka/Zookepper-related assays are of the functional type. The detection mode involves two configuration files, Config-TX and docker composition file, which detect parameter settings about Kafka/Zookeeper network configuration inside these two files. For example, the number of Zookeeper nodes must be an odd number, interworking between nodes is required, and the like.

In the present preferred embodiment, it may be defined that it is unreasonable to detect that the Kafka/Zookeeper correlation configuration does not comply with the correlation rule in the detection pattern, and the influence level corresponding to the detection pattern may be determined as an error. Further, it can be determined that the system layer related to the detection mode is the 4 th layer (block chain frame layer) shown in fig. 2.

The example detection patterns 1 to 14 determined for the respective profiles from the viewpoint of security, performance, and functionality using the processing in the detection pattern determining step S103 are described above. As can be seen from the above example detection modes, the "reasonableness" of the detection mode in the embodiments of the present disclosure covers a broad category, and in addition to defining a case that would cause a system error or a hidden trouble as "unreasonable" as understood in general, a case that does not necessarily cause an operational problem but requires the attention of a user as "unreasonable" may be defined to remind the user of the attention. This broad rationality/irrational definition is equally applicable to the detection of rationality and the description of the rationality detection results in the following.

After obtaining the detection patterns such as the example described above, the method 100 of fig. 1 may proceed to a rationality detection step S105 to detect the rationality of each detection pattern such as the example detection patterns 1 to 14 for the respective profiles. More specifically, in the rationality detecting step S105, the configuration of the parameter or function involved in each detection mode may be detected for each profile, and whether it is rational may be determined according to the criterion of whether the judgment of each detection mode is rational as the rationality of the detection mode.

For example, in the rationality detection step S105, for the detection of the TLS setting of the example detection mode 1, the setting of a parameter in the Docker composition file profile, which characterizes whether the TLS communication is on, may be detected, and the detection mode is determined to be unreasonable when the TLS communication is not on, otherwise the detection mode is determined to be rational to be provided to the subsequent processing as the rationality of the detection mode. In contrast, for the detection of the Consensus mechanism of example detection mode 3, the type of Consensus mechanism set by the parameter "order.

In this way, it is possible to complete the detection of each of the above-described example detection patterns 1 to 14 in the rationality detection step S105, and obtain the processing result of each detection pattern.

Next, the method 100 of fig. 1 may proceed to step S107. In step S107, a rationality detection result of the block chain may be provided based on the rationality of each detection mode.

As an example, the rationality detection result may include one of a plurality of influence levels corresponding to each detection pattern and rationality information indicating the detected rationality of each detection pattern. Preferably, the impact levels may include errors, warnings, and prompts, for example. Accordingly, for a detection mode in which the detection result is not reasonable, the rationality information thereof may include, for example, specific contents of an error, warning, or prompt given for the detection mode. Alternatively, for a detection mode whose detection result is unreasonable, the rationality information thereof may also be simply "unreasonable" or the like indicating that the detection result is unreasonable. For example, the rationality information of the detection pattern with a rational detection result may be blank or normalized "normal". Those skilled in the art will appreciate that the specific impact level and the setting of the rationality information may be set appropriately according to the application and the user requirement, and are not limited to the above examples, and will not be described herein again.

In a preferred embodiment, the rationality detection result may also include the type of each detection mode, such as security, performance and/or functionality. Furthermore, in a preferred embodiment, the rationality detection result may also include one or more layers of the blockchain associated with each detection mode.

In this way, the rationality detection result comprehensively provided can reflect the rationality of the configuration file of the block chain in many aspects, thereby facilitating the subsequent development, adjustment and application of users.

An example of the rationality detection report provided by the processing in step S107 in the present preferred embodiment will be described below with reference to fig. 6. Fig. 6 is an explanatory diagram schematically showing an example of the rationality detection result provided in the detection result providing step in the detection method shown in fig. 1, which shows that a rationality detection report is given based on the rationality detection in step S105 for the example detection patterns 1 to 14 determined in step S103 of the detection method shown in fig. 1.

As shown in the table of fig. 6, for each of the example detection patterns 1-14, the type of the detection pattern (security, performance, and/or functionality), the impact level (error, warning, or prompt) corresponding to the detection pattern, the system layer (one or more of layers 1-6 in fig. 2) of the block chain associated with the detection pattern, and rationality information for the detection pattern are given sequentially from left to right.

In this table, the type of detection mode, the influence level, and the system layer of the associated block chain are described in detail in the description of step S103, and are not repeated here. Here, the contents of the rationality information will be mainly described.

As an example, in the example shown in fig. 6, the detection results of the detection patterns 1 to 5, 7 to 8, 10, 12 to 14 are all "unreasonable", and therefore the rationality information in the table of fig. 6 shows the specific contents of errors, warnings or prompts given for these unreasonable detection patterns. Since the detection results of the

detection patterns

6, 9, and 11 are "reasonable", the rationality information of these detection patterns in the table of fig. 6 is blank.

More specifically, in the present example, for a detection mode in which the detection result of the rationality may be "unreasonable" or "rational", rationality information with specific contents or blank rationality information may be given according to the result for the user to refer to. For example, for the TLS setting of the example detection mode 1, since the detection in step S105 indicates that the TLS communication is not on and thus the detection result of the detection mode is "unreasonable", the rationality information given for the detection mode in the table of fig. 6 is "communication safety hazard", as the specific content of the warning. In contrast, for the complicated endorsement policy detection of the example detection pattern 6, since the detection result of the detection pattern is "reasonable" because the detection in step S105 indicates that there is no nesting or the like, the reasonableness information of the blank should be given for the detection pattern in the table of fig. 6. Similar scenarios apply to the

example detection patterns

2, 5, 8-14 in the table of fig. 6.

On the other hand, in the present example, for a detection mode that is artificially defined as "unreasonable" to remind the user of attention regardless of the detection result, the same rationality information can be given for the user to refer to regardless of the result of detection in the detection mode. For example, for the consensus mechanism of example detection mode 3, it is possible to give rationality information of "Solo-insecure fault tolerance, Kafka/Raft-high security and high fault tolerance" no matter whether the detection result in step S105 indicates that the specific type of the consensus mechanism is Solo, Kafka, or Raft. As an alternative, different rationality information may also be given based on the result of detection in the detection mode. For example, also for the consensus mechanism of the example detection mode 3, when the detection result in step S105 indicates that the specific type of the consensus mechanism is a Solo type, rationality information of "Solo-insecure fault tolerance" may be given as specific content of the prompt; and when the detection result shows that the specific type of the consensus mechanism is Kafka/Raft type, providing rationality information of 'Kafka/Raft-high safety and high fault tolerance' as specific content of prompt. Similar scenarios apply to the

example detection patterns

4 and 7 in the table of fig. 6.

Examples of rationality detection results obtained with embodiments of the present disclosure are described above with reference to the table of fig. 6. Based on the description and examples given in this disclosure, those skilled in the art will understand that the rationality detection result may be presented in any suitable form. For example, for a detection pattern whose detection result is "reasonable", an entry to be associated therewith may be directly omitted from the rationality detection result. That is, with the example table shown in fig. 6, the rows of the

detection patterns

6, 9, 11 whose detection results are "reasonable" may be deleted directly, so that the table of fig. 6 shows only the remaining eleven rows.

The detection method according to the embodiment of the present disclosure is described above with reference to fig. 1 to 6. By using the detection method disclosed by the embodiment of the disclosure, developers and managers can be helped to know the rationality of the block chain, so that the subsequent development, adjustment and application of users are facilitated.

According to another aspect of the present disclosure, a detection device is also provided. A detection apparatus according to an embodiment of the present disclosure will be described below with reference to fig. 7. Fig. 7 is a schematic block diagram schematically illustrating one example structure of a detection apparatus according to an embodiment of the present disclosure.

As shown in fig. 7, the detection apparatus 700 may include: a configuration file analysis unit 701 configured to analyze a configuration file of the block chain; a detection mode determination unit 703 that determines a plurality of detection modes of predetermined types of the configuration file based on the analysis result, the predetermined types including a security type, a performance type, and a functionality type; a reasonableness detection unit 705 that detects the reasonableness of each detection mode of the configuration file; and a detection result providing unit 707 providing a result of the rationality detection of the block chain based on the detected rationality of each detection mode.

The detection device and the units thereof can perform the detection method and the operation and/or processing of the steps thereof described above with reference to fig. 1 to 6, for example, and achieve similar effects, and a repeated description is not repeated here.

According to still another aspect of the present disclosure, there is provided a classification method for classifying a blockchain using a rationality detection result obtained by a detection method according to an embodiment of the present disclosure. Fig. 8 is a flowchart schematically illustrating an example flow of a classification method of classifying a blockchain using a rationality detection result obtained by a detection method according to an embodiment of the present disclosure

As shown in fig. 8, the classification method 800 includes: step S801, obtaining a rationality detection result of a block chain by using the detection method according to the embodiment of the disclosure; step S803, the obtained rationality detection result is input to a classification model obtained in advance to obtain the type of the block chain.

As discussed in the description of the detection method of the embodiment of the present disclosure, the rationality detection result of the block chain obtained by the detection method of the embodiment of the present disclosure can comprehensively reflect the rationality of the block chain. Therefore, the rationality detection results of the blockchain network can be used as features to classify blockchains to help developers and managers to better understand the characteristics of their blockchains.

Next, specific processing performed in each step of the classification method of the present embodiment will be described, continuing with example detection patterns 1 to 14 used in the above detection method and the rationality detection result shown in, for example, fig. 6 as examples.

As an example, the rationality detection result of the block chain obtained in step S801 may be based on the rationality detection result shown in fig. 6, but needs to be preprocessed to be expressed in the form of a characteristic vector.

For example, a plausibility detection result in the form of a vector shown in the following formula (1) may be constructed:

M＝(Pattern₁,Pattern₂,…,Pattern_N)…..(1)

wherein each element Pattern in the vector M_iA vector obtained from the rationality detection result of the detection pattern i is shown (i is 1,2, …, N is a natural number, and indicates the total number of detection patterns, for example, N is 14 in the example of the table of fig. 6).

As an example, each element Pattern in the rationality detection result M_iFor example, it may take the form of the following equation (2)

Pattern_i＝(Valueⁱ _Level,Valueⁱ _Layer,Valueⁱ _Type,Valueⁱ _{Resonableness})…..(2)

As shown in formula (2), each element Pattern_iAre all a vector containing four elements, respectively Valueⁱ _Level、Valueⁱ _Layer、Valueⁱ _TypeAnd Valueⁱ _{Resonableness}And (4) showing. Accordingly, the rationality detection result M in the formula (1) actually takes the form of a matrix.

In the formula (2), Valueⁱ _LevelThe influence level of the detection mode included in the detection result of the characterization detection mode i corresponds to an error, a warning, or a prompt, and the values thereof may be between 1 and 0, for example, 1, 0.5, and 0, respectively, in descending order of the values of the error, the warning, and the prompt.

Valueⁱ _LayerThe system layer included in the detection result of the characterization detection mode i (i.e. the system layer associated with the detection mode i) corresponds to one or more of layers 1 to 6 shown in fig. 2, and the value may be between 1 and 6. For example, when the detection pattern i corresponds to one system layer, Value_LevelTaking the value as the serial number of the system layer; value when the detection pattern i corresponds to two or more system layers_LevelThe value is the average of the numbers of these system layers.

Valueⁱ _TypeThe type included in the detection result of the characterization detection mode i (i.e. the type of the detection mode i) corresponds to three types of security, performance and functionality, and values may be 1,2 and 3, respectively.

Valueⁱ _{Resonableness}The property of the rationality information included in the detection result of the characterization detection mode i (i.e. whether the detection mode i is rational or not) corresponds to two cases of "rational" and "unreasonable", and values thereof may be 1 and 0, respectively.

In this way, a rationality detection result matrix M in the form of the above equations (1) and (2) can be constructed for a rationality detection report including the type of detection mode, the impact level, the associated system layer, and the rationality information as a feature matrix characterizing the overall state and properties of the network, such a feature matrix being able to represent well the features of the current network in terms of functionality, security, and performance.

After the feature matrix M of the rationality detection results, for example, in the form of the above equations (1) and (2), is obtained, it may be input to a classification model trained in advance to obtain a classification result that determines the network in step S803. Those skilled in the art will appreciate that the training and application processes (classification processes) of the classification model correspond to each other, and therefore the application process of the classification model is described herein first in a centralized manner, and then the training process is described briefly.

In a preferred embodiment, the result of classifying the blockchain application by the classification model employed in step S803 may include a security type, a performance type, and an extensible type.

Note that although the features represented by the rationality detection result obtained by the detection method of the embodiment of the present disclosure cover security, performance, and functionality, and do not seem to correspond to security, performance, and extensibility one to one, because there is a correspondence between the features and types of "security" and "performance", respectively, and in view of the "impossible triangle" between the types of "security", "performance" ("efficiency") and "extensibility", the features representing security, performance, and functionality may still be used to achieve the distinction of the three categories of security, performance, and extensibility. The "impossible triangle" of Security (Security), Efficiency (Efficiency), Scalability (Scalability) is a common consensus in the current blockchain technology, i.e. usually, these three factors are difficult to be considered for blockchain framework and network. With this insight, the features characterized in the preferred embodiment based on the rationality detection result enable a determination of network characteristics that is difficult to achieve in the prior art by analyzing system components or configurations.

Alternatively, the classification model adopted in step S803 is obtained by training based on the rationality detection result obtained from the blockchain used for training by the detection method according to the embodiment of the present disclosure, which is labeled in advance with the type of the blockchain.

For example, a specific implementation of the classification model may employ a Convolutional Neural Network (CNN). Those skilled in the art will appreciate that the training of the classification model and the application process (classification process) correspond to each other, and therefore, the form of the rationality detection result used in the training process may be a form similar to the above-described feature matrix M obtained in reference to step 801, except that the rationality detection result used in the training phase as the training data is previously labeled with its type (safety type, performance type, or extensible type). Any method for training the existing classification model can be adopted, for example, the method for constructing the loss function and optimizing the loss function based on the accuracy of the classification result can be used to obtain the specific parameters of the classification model, and the detailed description is omitted here.

Note that for a trained classification model, the number of input feature vectors (corresponding to the number of detection patterns) should be fixed. The feature vectors into which the rationality check results are translated may have different numbers for different block chains. If the number of feature vectors of the rationality detection result of the block chain to be classified is greater than the number of input channels of the classification model, it should be reduced (e.g., randomly picked) to be consistent with the number of input channels of the classification model; if the number of feature vectors of the rationality detection result of the block chain to be classified is smaller than the number of input channels of the classification model, the feature vectors should be increased (for example, a plurality of all 0 vectors whose elements are all 0) to be consistent with the number of input channels of the classification model, and details are not repeated here.

An example of a classification method for classifying a blockchain using a rationality detection result is described above with reference to fig. 8. The foregoing description is by way of example only, and is not intended as limiting the scope of the disclosure. For example, the feature matrix and the feature vector used to characterize the rationality detection result are not limited to the forms of the above equations (1) and (2). Feature vector Pattern for detection Pattern i in equation (2)_iMay be two instead of four (Value)ⁱ _LevelAnd Valueⁱ _{Resonableness}) Three (Value)ⁱ _LevelAnd Valueⁱ _{Resonableness}Addition of Valueⁱ _LayerOr Valueⁱ _Type) Or other suitable number. On the basis of the above description, a person skilled in the art may make various suitable modifications, which are not described in detail herein.

By using the classification method of the embodiment, the block chain can be classified according to the rationality detection result, so that developers and managers can be helped to better understand the characteristics of the block chain, and the deep optimization of the block chain and/or the selection of a proper block chain for different application scenes are assisted.

For example, the safety type blockchain can be applied to the financial application scene of electronic money transaction, such as digital asset transaction and share right transaction. A performance (efficiency) type blockchain may be suitable for non-financial scenarios, such as IoT (internet of things) applications, which need to process large amounts of concurrent data, with high requirements for efficiency. The block chain of the expandable type can be suitable for application scenes with fast updating and iteration, such as scenes of financing of medium and small enterprises, and the like, wherein the scenes need to be updated and changed frequently, such as addition of new enterprises, addition of new financing channels, and the like.

According to still another aspect of the present disclosure, there is provided an information processing apparatus. The information processing apparatus may implement the detection method for a block chain requiring permission according to an embodiment of the present disclosure, which may include a processor configured to: analyzing a configuration file of a block chain needing permission; determining a plurality of detection modes of predetermined types of the configuration file based on the analysis result, wherein the predetermined types comprise a security type, a performance type and a functionality type; detecting the reasonability of each detection mode of the configuration file; and providing a rationality detection result of the block chain based on the detected rationality of each detection mode.

The processor of the information processing apparatus may be configured to perform the operations and/or processes of the detection method and its respective steps described above with reference to fig. 1 to 6, for example, and achieve similar effects, and a repeated description thereof will not be provided herein.

As an example, the blockchain includes a federation blockchain or a private blockchain.

In a preferred embodiment, the rationality test results comprise: one of a plurality of influence levels corresponding to each detection pattern, and rationality information indicating the detected rationality of each detection pattern.

Preferably, the plurality of impact levels includes errors, warnings, and prompts.

In a preferred embodiment, the rationality detection result includes the type of each detection mode.

In a preferred embodiment, the rationality detection result comprises one or more layers of block chains associated with each detection mode.

Fig. 9 is a block diagram illustrating one possible hardware configuration 900 that may be used to implement the detection method and detection apparatus, the classification method, and the information processing device according to the embodiments of the present disclosure.

In fig. 9, a Central Processing Unit (CPU)901 performs various processes in accordance with a program stored in a Read Only Memory (ROM)902 or a program loaded from a storage section 908 to a Random Access Memory (RAM) 903. In the RAM 903, data necessary when the CPU 901 executes various processes and the like is also stored as necessary. The CPU 901, ROM 902, and RAM 903 are connected to each other via a bus 904. An input/output interface 905 is also connected to bus 904.

The following components are also connected to the input/output interface 905: an input section 906 (including a keyboard, a mouse, and the like), an output section 907 (including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker, and the like), a storage section 908 (including a hard disk, and the like), a communication section 909 (including a network interface card such as a LAN card, a modem, and the like). The communication section 909 performs communication processing via a network such as the internet. The driver 910 may also be connected to the input/output interface 905 as necessary. A removable medium 911 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like can be mounted on the drive 910 as needed, so that a computer program read out therefrom can be mounted in the storage section 908 as needed.

In addition, the present disclosure also provides a program product storing machine-readable instruction codes. The instruction codes can be read and executed by a machine to execute the detection method and/or the classification method according to the embodiment of the disclosure. Accordingly, various storage media such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. for carrying such a program product are also included in the disclosure of the present disclosure.

That is, the present disclosure also proposes a storage medium storing machine-readable instruction codes, which, when read and executed by a machine, can cause the machine to perform the above-described detection method for a block chain requiring permission according to an embodiment of the present disclosure. The instruction code includes an instruction code portion for performing the following operations: analyzing the configuration file of the block chain; determining a plurality of detection modes of predetermined types of the configuration file based on the analysis result, wherein the predetermined types comprise a security type, a performance type and a functionality type; detecting the reasonability of each detection mode of the configuration file; and providing a rationality detection result of the block chain based on the detected rationality of each detection mode.

The storage medium may include, for example, but is not limited to, a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, and the like.

In the foregoing description of specific embodiments of the disclosure, features described and/or illustrated with respect to one embodiment may be used in the same or similar manner in one or more other embodiments, in combination with or instead of the features of the other embodiments.

Furthermore, the methods of the embodiments of the present disclosure are not limited to being performed in the chronological order described in the specification or shown in the drawings, and may be performed in other chronological orders, in parallel, or independently. Therefore, the order of execution of the methods described in this specification does not limit the technical scope of the present disclosure.

Further, it is apparent that the respective operational procedures of the above-described method according to the present disclosure can also be implemented in the form of computer-executable programs stored in various machine-readable storage media.

Moreover, the object of the present disclosure can also be achieved by: a storage medium storing the above executable program code is directly or indirectly supplied to a system or an apparatus, and a computer or a Central Processing Unit (CPU) in the system or the apparatus reads out and executes the program code.

At this time, as long as the system or the apparatus has a function of executing a program, the embodiments of the present disclosure are not limited to the program, and the program may also be in any form, for example, an object program, a program executed by an interpreter, a script program provided to an operating system, or the like.

Such machine-readable storage media include, but are not limited to: various memories and storage units, semiconductor devices, magnetic disk units such as optical, magnetic, and magneto-optical disks, and other media suitable for storing information, etc.

In addition, the client information processing terminal can also implement the embodiments of the present disclosure by connecting to a corresponding website on the internet, and downloading and installing computer program codes according to the present disclosure into the information processing terminal and then executing the program.

In summary, according to the embodiments of the present disclosure, the present disclosure provides the following schemes, but is not limited thereto:

scheme 1, a method for detecting a block chain requiring admission, the method comprising:

analyzing the configuration file of the block chain;

determining a plurality of detection modes of predetermined types of the configuration file based on the analysis result, wherein the predetermined types comprise a security type, a performance type and a functionality type;

detecting the reasonability of each detection mode of the configuration file; and

based on the detected rationality of the respective detection modes, a rationality detection result of the block chain is provided.

Scheme 2 the detection method of scheme 1, wherein the blockchain comprises a federation blockchain or a private blockchain.

Scheme 3, the detection method according to

scheme

1 or 2, wherein the rationality detection result comprises: one of a plurality of influence levels corresponding to each detection pattern, and rationality information indicating the detected rationality of each detection pattern.

Scheme 4, the detection method according to

scheme

1 or 2, wherein the rationality detection result includes a type of each detection mode.

Scheme 5, the detection method according to

scheme

1 or 2, wherein the rationality detection result comprises one or more layers of block chains associated with each detection mode.

Scheme 6, the detection method of scheme 3, the plurality of impact levels comprising errors, warnings, and reminders.

Scheme 7, a classification method for a block chain requiring permission, the classification method comprising:

obtaining a rationality detection result of the block chain by using the detection method according to any one of the schemes 1 to 6;

the obtained rationality detection result is input to a classification model obtained in advance to obtain the type of the block chain.

Scheme 8 the classification method according to scheme 7, wherein the classification model is obtained by training based on the rationality detection result obtained from the blockchain used for training by the detection method according to any one of the schemes 1 to 6, which is labeled with the type of the blockchain in advance.

Scheme 9 the classification method of scheme 7, wherein the types of blockchains include a security type, a performance type, and an extensible type.

An information processing apparatus according to claim 10, comprising:

a processor configured to:

analyzing a configuration file of a block chain needing permission;

Scheme 11 the information processing apparatus according to scheme 10, wherein the blockchain comprises a federation blockchain or a private blockchain.

The information processing apparatus according to claim 12 or claim 10 or 11, wherein the rationality detection result includes: one of a plurality of influence levels corresponding to each detection pattern, and rationality information indicating the detected rationality of each detection pattern.

Case 13, the information processing apparatus according to

case

10 or 11, wherein the rationality detection result includes a type of each detection mode.

Scheme 14, the information processing apparatus according to

scheme

10 or 11, wherein the rationality detection result includes one or more layers of a block chain associated with each detection mode.

Case 15, the information processing apparatus according to case 12, the plurality of impact levels including an error, a warning, and a prompt.

A storage medium storing machine-readable instruction code which, when read and executed by a machine, is capable of causing the machine to perform a detection method for a blockchain requiring permission, the detection method comprising:

analyzing the configuration file of the block chain;

Finally, it is also noted that, in the present disclosure, relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements may include not only those elements but other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

While the disclosure has been disclosed by the description of specific embodiments thereof, it will be appreciated that those skilled in the art will be able to devise various modifications, improvements, or equivalents of the disclosure within the spirit and scope of the appended claims. Such modifications, improvements and equivalents are intended to be included within the scope of the present disclosure as claimed.

Claims

1. A method for detection of a blockchain requiring permission, the method comprising:

analyzing the configuration file of the block chain;

2. The detection method of claim 1, wherein the blockchain comprises a federation blockchain or a private blockchain.

3. A test method according to claim 1 or 2, wherein the rationality test result comprises: one of a plurality of influence levels corresponding to each detection pattern, and rationality information indicating the detected rationality of each detection pattern.

4. A detection method according to claim 1 or 2, wherein the rationality detection result includes a type of each detection mode.

5. A detection method according to claim 1 or 2, wherein the rationality detection result comprises one or more layers of a block chain associated with each detection mode.

6. The detection method of claim 3, the plurality of impact levels comprising errors, warnings, and prompts.

7. A classification method for a block chain requiring permission, the classification method comprising:

obtaining a rationality detection result of a block chain by using the detection method according to any one of claims 1 to 6;

8. A classification method according to claim 7, wherein the classification model is derived by training based on fitness detection results derived from a blockchain used for training using a detection method according to any one of claims 1 to 6, pre-labeled with the type of blockchain.

9. The classification method according to claim 7, wherein the types of blockchains include a security type, a performance type, and an extensible type.

10. An information processing apparatus comprising:

a processor configured to:

analyzing a configuration file of a block chain needing permission;