CN116910018A

CN116910018A - Block chain-based data management method and apparatus, and storage medium

Info

Publication number: CN116910018A
Application number: CN202310343867.6A
Authority: CN
Inventors: 王琛; 赵砚宇; 曹汐; 周岩
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Communications Ltd Research Institute
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Communications Ltd Research Institute
Priority date: 2023-03-31
Filing date: 2023-03-31
Publication date: 2023-10-20

Abstract

The embodiment of the application provides a data management method based on a block chain, which comprises the following steps: receiving a block header template and a generation rule issued by first block chain node equipment; then, verifying the block header template to determine a verification result; if the verification result is that the verification is successful, generating a block header based on the generation rule; wherein the block header includes a contribution check code; and (3) carrying out uplink processing on the block head so as to carry out data management based on the contribution check code, thereby improving the accuracy of reporting the contribution.

Description

Block chain-based data management method and apparatus, and storage medium

Technical Field

The present application relates to the field of blockchain technologies, and in particular, to a blockchain-based data management method and apparatus, and a storage medium.

Background

At present, the situation that the blockchain technology is applied in the telecommunication industry is very many, taking blockchain enabling federal machine learning as an example, many projects (such as base station energy conservation) all require that all levels of companies provide computing power and data to perform model construction, reasoning and other works required by base station energy conservation, but according to the national and corporate policy regulations, all levels of company data can only be used at the level and cannot be gathered to headquarter nodes. To build a more complete and accurate model, federal machine learning techniques can be used to allow each level of company to train sub-models at this level, with the parameters of the sub-models being aggregated by headquarters to form a final accurate model; although the federal machine learning (Federated Machine Learning, FML) technology can solve the above problems, but the data amounts of all levels are different and the calculation power of contribution is different, and each party needs to be encouraged to participate in contribution through an incentive mechanism, at present, no verification mechanism exists, and only accurate contribution amounts can be reported through each participating company to obey rules by conscious sense, so that hidden danger of false report data exists, and further, the problem of lower accuracy of reporting the contribution amounts exists.

Disclosure of Invention

The embodiment of the application provides a data management method and equipment based on a block chain and a storage medium, which can improve the accuracy of reporting contribution and improve the data management efficiency.

The technical scheme of the embodiment of the application is realized as follows:

in a first aspect, an embodiment of the present application provides a blockchain-based data management method, where the method is applied to a data management device, and the method includes:

receiving a block header template and a generation rule issued by first block chain node equipment;

performing verification processing on the block header template, and determining a verification result;

if the verification result is that the verification is successful, generating a block header based on the generation rule; wherein the block header includes a contribution check code;

and processing the block head uplink to perform data management based on the contribution check code.

In a second aspect, an embodiment of the present application provides a data management method based on a blockchain, where the method is applied to a first blockchain link point device, and the method includes:

determining a generation rule, and generating a block header template according to the generation rule;

and transmitting the block header template and the generation rule to data management equipment, so that the data management equipment generates a block header comprising a contribution check code based on the generation rule, and performs data management based on the contribution check code.

In a third aspect, an embodiment of the present application provides a data management apparatus, including: a receiving unit, a verification unit, a first generation unit, a processing unit,

the receiving unit is used for receiving a block header template and a generation rule issued by the first block chain node equipment;

the verification unit is used for performing verification processing on the block header template and determining a verification result;

the first generation unit is used for generating a block header based on the generation rule if the verification result is that the verification is successful; wherein the block header includes a contribution check code;

and the processing unit is used for carrying out uplink processing on the block head so as to carry out data management based on the contribution check code.

In a fourth aspect, an embodiment of the present application provides a data management apparatus, including: a first processor and a first memory; wherein,,

the first memory is used for storing a computer program capable of running on the processor;

the first processor is configured to execute the data management method as described above when the computer program is run.

In a fifth aspect, embodiments of the present application provide a first block link point apparatus, comprising: a determining unit, a second generating unit, a issuing unit,

The determining unit is used for determining a generation rule by the first block chain link point device;

the second generating unit is used for generating a block header template according to the generating rule;

the issuing unit is configured to issue the block header template and the generation rule to a data management device by using the first blockchain node device, so that the data management device generates a block header including a contribution check code based on the generation rule, and performs data management based on the contribution check code.

In a sixth aspect, embodiments of the present application provide a first block link point apparatus, the first block link point apparatus comprising: a second processor and a second memory; wherein,,

the second memory is used for storing a computer program capable of running on the processor;

the second processor is configured to execute the data management method as described above when the computer program is run.

In a seventh aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the storage medium has stored thereon computer program code which, when executed by a computer, implements the data management method as described above.

The embodiment of the application provides a data management method and equipment based on a blockchain, and a storage medium, wherein the method comprises the following steps: the first block chain link point equipment determines a generation rule and generates a block head template according to the generation rule; the first block chain node equipment transmits the block head template and the generation rule to the data management equipment, and the data management equipment can verify the block head template to determine a verification result; if the verification result is that the verification is successful, generating a block header based on the generation rule; wherein the block header includes a contribution check code; the block header is processed to perform data management based on the contribution check code. It can be seen that the data management device can receive the block header template and the generation rule issued by the first block chain node device; and then after the result of verification processing on the block header template is determined to be successful in verification, generating a block header comprising a contribution check code by utilizing a generation rule, and performing uplink processing on the block header, so that the first block chain link point equipment can perform data management based on the contribution check code. That is, in the present application, the data management device may perform the reporting process of the corresponding contribution check code to the first blockchain node device through the blockhead template and the generation rule issued by the first blockchain node device, so as to perform the verification process based on the contribution check code, thereby effectively solving the problem that the data management device exaggerates the workload of the nodes, further improving the accuracy of reporting the contribution, and simultaneously improving the data management efficiency of the first blockchain node device.

Drawings

FIG. 1 is a hierarchical schematic diagram of a blockchain in accordance with an embodiment of the present application;

FIG. 2 is a diagram of a federal machine learning architecture according to an embodiment of the present application;

FIG. 3 is a schematic view of a lateral FML according to an embodiment of the present application;

FIG. 4 is a schematic view of a longitudinal FML according to an embodiment of the present application;

FIG. 5 is a schematic diagram of federal transfer learning according to an embodiment of the present application;

FIG. 6 is a diagram illustrating a first exemplary block chain based data management method according to an embodiment of the present application;

FIG. 7 is a schematic diagram of a data management system according to an embodiment of the present application;

FIG. 8 is a schematic diagram of a secondary management system according to an embodiment of the present application;

FIG. 9 is a schematic diagram of a primary management system architecture according to an embodiment of the present application;

fig. 10 is a schematic diagram of template parameter information of a block header template according to an embodiment of the present application;

FIG. 11 is a block chain structure diagram according to an embodiment of the present application;

fig. 12 is a block header structure schematic diagram according to an embodiment of the present application;

FIG. 13 is a second exemplary block chain based data management method according to an embodiment of the present application;

FIG. 14 is a third exemplary block chain based data management method according to an embodiment of the present application;

fig. 15 is a schematic diagram of a composition structure of a data management device according to an embodiment of the present application;

Fig. 16 is a schematic diagram of a second component structure of the data management device according to the embodiment of the present application;

FIG. 17 is a schematic diagram illustrating a first block chain node device according to an embodiment of the present application;

fig. 18 is a schematic diagram of a second component structure of a first blockchain node device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. It is to be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to be limiting. It should be noted that, for convenience of description, only a portion related to the related application is shown in the drawings.

The current block chain technology is a technical scheme which does not depend on a third party and performs storage, verification, transmission and communication of network data through self-distributed nodes; in the academic field, blockchains are generally divided into three layers (Layer 0, layer1, layer 2), and fig. 1 is a hierarchical schematic diagram of a blockchain, and as shown in fig. 1, the blockchain has a total of six hierarchical structures, and the six hierarchical structures are from bottom to top: a network layer, a data layer, a consensus layer, an incentive layer, a contract layer and an application layer; wherein the network layer is mainly a peer-to-peer network (P2P network), a data transmission mechanism and a data verification mechanism; the data layer is equivalent to a data structure in four core technologies of a block chain, namely a structure of a block+chain, and mainly comprises a data block, a timestamp, a hash function and a Merkle tree (Merkle tree) after chain type section, and is asymmetrically encrypted; the consensus layer mainly comprises consensus algorithm mechanisms, namely, a workload of Work (POW), a equity Proof of interest (POS), a share authorization Proof mechanism (Delegated Proof of Stake, DPOS), a practical Bayesian fault-tolerant consensus algorithm (Practical Byzantine Fault Tolerance, PBFT) and other consensus mechanisms exist at present; the incentive layer mainly comprises an issuing mechanism and an allocation mechanism; the contract layer mainly comprises an algorithm mechanism, intelligent contracts and script codes.

Federal machine learning (Federated Machine Learning, FML) is a technical framework that allows joint construction and subsequent collaborative use of machine learning models through distributed data stored by different organizations or devices, the framework being aimed at protecting privacy, improving security, and meeting regulatory regulations for data use; FIG. 2 is a schematic diagram of a federal machine learning architecture; wherein, data owner can represent Data owner, database can represent Database, sub-model can represent Sub-model, coordinator can represent dispatcher, federated model represents joint model, service user represents service user, auditor/supervisor represents Auditor/supervisor, federal learning can achieve Data owner 1 and Data owner 2 own Data not out of local, and Federal system can establish a virtual common model (joint model) through parameter exchange mode under encryption mechanism, namely under the condition of not violating Data privacy regulation.

The data of the FML is usually stored in the form of a standard database, typically a table. Taking a table as an example, a sample (sample) represents data in two dimensions (X-axis and Y-axis), typically the X-axis represents features of the data and the Y-axis represents labels of the data. Given the variety of characteristics of data, X is generally understood to be a feature vector (X1, X2, … Xn); furthermore, a unique sample ID is associated with each data sample, and different data sets may have the same sample (same sample ID) or the same characteristics. Accordingly, FML application techniques are classified based on the degree of overlap of the different dimensions, as shown in table 1 below.

TABLE 1

The manner in which FML techniques are applied differs based on the degree of overlap between the two dimensions: (1) The feature overlapping degree is low, the sample overlapping degree is high-longitudinal FML; (2) The feature overlapping degree is low, and the sample overlapping degree is low, namely federal migration learning; (3) The feature overlapping degree is high, the sample overlapping degree is low-transverse FML; (4) Feature overlap is high, sample overlap is high-FML is not applicable. FIG. 3 is a schematic view of a transverse FML, as shown in FIG. 3, where the two data sets overlap more in the "transverse" direction, i.e., the data of the two data sets overlap more in the number of features, in which case the transverse FML framework technique may be used for model training. It should be noted that FML technology is a compromise between the two contradictory requirements of strong privacy protection and high model performance, and any model trained under the FML framework is only close to the performance of traditional machine learning (data put in the same place). FIG. 4 is a longitudinal FML representation, as shown in FIG. 4, where two data sets overlap more in the "longitudinal" direction, i.e., the sample IDs of the two data sets overlap more, in which case the longitudinal FML framework technique may be used for model training; wherein labels of the upper graph represent the "label" that is applied to the sample. FIG. 5 is a schematic diagram of Federal migration learning, as shown in FIG. 5, where there is little overlap of two data sets in both directions, federal migration learning (Federated Transfer Learning, FTL) may be used in which case the FTL exploits the ability of the migration learning technique to exploit reusable knowledge across different feature domains to form a high quality FTL model, which has the advantage of overcoming the difficulties of small data volumes and weak supervision.

At present, the situation that the blockchain technology is applied in the telecommunication industry is very many, taking blockchain enabling federal machine learning as an example, many projects (such as base station energy conservation) all require that all levels of companies provide computing power and data to perform model construction, reasoning and other works required by base station energy conservation, but according to the national and corporate policy regulations, all levels of company data can only be used at the level and cannot be gathered to headquarter nodes. To build a more complete and accurate model, federal machine learning techniques can be used to allow each level of company to train sub-models at this level, with the parameters of the sub-models being aggregated by headquarters to form a final accurate model; although the federal machine learning (Federated Machine Learning, FML) technology can solve the above problems, but the data amounts of all levels are different and the calculation power of contribution is different, and each party needs to be encouraged to participate in contribution through an incentive mechanism, at present, no verification mechanism exists, and only accurate contribution can be reported through each participating company to obey rules by himself, so that hidden danger of false report data exists and further the problem of lower accuracy of reporting the contribution exists.

In addition, the uplink of the blockchain mainly depends on various algorithms of workload demonstration, the algorithms mainly depend on the calculation power of nodes, the method is not suitable for the specific environment that the blockchain nodes of the telecommunication industry participate in company/personnel fixation without competing for robbery, and if the traditional method is adopted, the problems of huge calculation power occupation, low resource occupation rate and extremely high time consumption of non-engineering calculation are caused.

In order to solve the problem of low accuracy of reporting contribution, the embodiment of the application provides a data management method and device based on a blockchain, and a storage medium, wherein the method comprises the following steps: the first block chain link point equipment determines a generation rule and generates a block head template according to the generation rule; the first block chain node equipment transmits the block head template and the generation rule to the data management equipment, and the data management equipment can verify the block head template to determine a verification result; if the verification result is that the verification is successful, generating a block header based on the generation rule; wherein the block header includes a contribution check code; the block header is processed to perform data management based on the contribution check code. It can be seen that the data management device can receive the block header template and the generation rule issued by the first block chain node device; and then after the result of verification processing on the block header template is determined to be successful in verification, generating a block header comprising a contribution check code by utilizing a generation rule, and performing uplink processing on the block header, so that the first block chain link point equipment can perform data management based on the contribution check code. That is, in the present application, the data management device may perform the reporting process of the corresponding contribution check code to the first blockchain node device through the blockhead template and the generation rule issued by the first blockchain node device, so as to perform the verification process based on the contribution check code, thereby effectively solving the problem that the data management device exaggerates the workload of the nodes, further improving the accuracy of reporting the contribution, and simultaneously improving the data management efficiency of the first blockchain node device.

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application.

Example 1

The embodiment of the application provides a data management method based on a block chain, which is applied to data management equipment. Fig. 6 is a schematic diagram of a data management method based on a blockchain according to an embodiment of the present application, as shown in fig. 6, the data management method based on a blockchain of a data management device may include the following steps:

step 101, a block header template and a generation rule issued by first block chain node equipment are received.

In the embodiment of the application, the data management device can firstly receive the block header template and the generation rule issued by the first block chain node device.

It should be noted that, in the embodiment of the present application, the blockchain may be a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, encryption algorithm, and the like. The Blockchain (Blockchain), which is essentially a decentralised database, is a string of data blocks that are generated by cryptographic means in association, each data block containing a batch of information of network transactions for verifying the validity of the information (anti-counterfeiting) and generating the next block.

It should be noted that, in the embodiment of the present application, the data management method based on the blockchain may be implemented by a data management system, and the data management system may include a data management device and a first blockchain point device.

Further, in the embodiment of the present application, fig. 7 is a schematic structural diagram of a data management system according to the embodiment of the present application, as shown in fig. 7, the data management system may include a data management device and a first block link point device, where the data management system may include any number of first block link point devices and any number of data management devices, and the present application is not limited in detail. For example, as shown in FIG. 7, the data management system may include a first blockchain node device and a plurality of data management devices.

It should be noted that, in an embodiment of the present application, the data management device may include a secondary management system, where the secondary management system may be located in each non-primary blockchain node, and fig. 8 is a schematic diagram of a secondary management system architecture according to an embodiment of the present application, where, as shown in fig. 8, the secondary management system architecture includes a template receiving module, a template verification module, a first template storage library, a template update feedback module, and other necessary modules.

It should be noted that, in the embodiment of the present application, the template receiving module in the secondary management system architecture is responsible for receiving the newly created/updated block header template issued by the primary management system, and the template verifying module is responsible for performing feasibility verification on the received block header template, storing the verified block header template in the first template storage library for other storage modules to call, and sending the verification result to the template updating feedback module. The first template storage is responsible for storing verified block header templates and corresponding generation rules. The template updating feedback module is responsible for sending the received verification result information (success or failure) to the primary management system node and/or other secondary management system nodes through mechanisms such as unicast/broadcast or uplink consensus. Other necessary modules are used for applying the templates and rules to realize the functions of the conventional blockchain, and are needed along with the common implementation manner in the industry, and are not repeated here.

It should be noted that, in the embodiment of the present application, the first block link point device may include a primary management system, where the primary management system may be located in a headquarter block chain node, and fig. 9 is a schematic diagram of a primary management system architecture according to the embodiment of the present application, where the primary management system architecture includes a rule generating module, a template rule base, a template generating module, a template updating notification module, a second template storage, a template receiving verification module, and other necessary modules as shown in fig. 9.

It should be noted that, in an embodiment of the present application, the rule generating module in the primary management system architecture may periodically or aperiodically generate a generation rule of "contribution check code" of the block header based on a predefined rule, expert experience, upper management system notification, and/or intelligent contract predefined information, and transmit the generated rule to the rule issuing module. The template rule base may deliver predefined rule constituent units based on the request of the rule generating module for the rule generating module to generate a complete rule template with one or more rule constituent units and other execution requirement information. The template generation module may generate a new block header template based on the contribution check code generation rule received from the rule generation module. The template update notification module can perform security processing (such as encryption by using a private key), then issue the security processing to a node of the secondary management system (secondary management system), and the issuing can be realized in a unicast and broadcast mode or can be recorded in a uplink mode. The second template storage library is used for storing the templates generated by the template generating module and the corresponding generating rules for later calling and viewing. The template receiving verification module can be used for verifying whether other nodes have received the updated template, and the module is optional; when using unicast or broadcast forms, this module is mandatory; when using blockchain-style notifications, this module may exist alone to implement all nodes to receive authentication functionality, or may be enhanced by other necessary modules on top of traditional functionality to implement authentication functionality, at which point this module may be incorporated into an existing module and need not exist alone. Other necessary modules can be used to apply the templates and rules to implement the functions of the conventional blockchain, and are generally implemented in the industry, and will not be described in detail herein.

It should be noted that, in the embodiment of the present application, the generation rule may include a specific rule of a contribution check code in the block header template.

It should be noted that, in an embodiment of the present application, the tile header template may include a template generation module in the primary management system architecture, based on the received generation rule of the "contribution check code" from the "rule generation module", and the generated tile header template.

It should be noted that, in the embodiment of the present application, fig. 10 is a schematic diagram of template parameter information of a block header template according to the embodiment of the present application, and as shown in fig. 10, the template parameter information of the block header template may include: the application does not limit the template parameter information content of the block header template specifically.

In the embodiment of the present application, the metadata of the generation rule in the template parameter information of the tile header template represents the most basic parameter information for generating one template, and the parameter information is shown in table 2 below.

TABLE 2

Among them, AI/ML technology refers to artificial intelligence (Artificial Intelligence, AI) technology/Machine Learning (ML) technology.

It should be noted that, in the embodiment of the present application, the component characteristic information in the template parameter information of the tile header template represents parameter information describing one or more rules for generating the "contribution check code", and the parameter information is shown in table 3 below.

TABLE 3 Table 3

It should be noted that, in the embodiment of the present application, the inspection object information in the template parameter information of the tile header template includes an execution inspection object parameter and an external inspection object ID parameter, such parameters are used to describe whether the inspection of feasibility is required for the template verification module in the secondary system (secondary management system), and which information needs to be inspected, by defining these information, the system can determine whether to execute the inspection, and which module is responsible for the object, and the parameter information is shown in table 4 below.

TABLE 4 Table 4

It should be noted that, in the embodiment of the present application, the inspection requirement in the template parameter information of the tile header template may include further refinement and extension of the "component characteristic information", where such parameters are used to describe which information has to be inspected by the internal or external module responsible for performing the inspection work, and by formulating which information has to be inspected, it is possible to help the system to efficiently and accurately inspect whether the related inspection function can be performed, that is, whether the feasibility of the inspection can be ensured, while ensuring that the inspection of the system is not excessive or missing, and the inspection requirement related parameters are as shown in the following table 5.

TABLE 5

It should be noted that, in the embodiment of the present application, the security information in the template parameter information of the block header template includes an encryption mode parameter and a notification mode parameter, where such parameters are used to describe the security requirements required for executing the rule, so as to ensure that the rule running process is not affected by the outside, and the parameter information is as shown in the following table 6.

TABLE 6

It should be noted that in the embodiment of the present application, two modes of receiving the block header template and the generation rule by the data management device may be provided, and the first mode may receive the block header template and the generation rule by unicast or broadcast; in addition, the block header template and the generation rule can be received through a block chain uplink mechanism, and the receiving mode of the data management device is not particularly limited.

Step 102, performing verification processing on the block header template, and determining a verification result.

In the embodiment of the application, after receiving the block header template and the generation rule, the data management device may perform verification processing on the block header template to determine a verification result.

It should be noted that, in the embodiment of the present application, the data management apparatus performs the verification process on the block header template, and the verification process may include the feasibility verification process performed on the block header template, for example, the feasibility verification of whether the data management apparatus supports the "contribution check code" generation rule on the block header template.

That is, in the embodiment of the present application, after receiving the block header template and the generation rule sent by the first blockchain template, the data management device may perform the feasibility verification process on the block header template first, and may further determine the verification result.

It should be noted that, in the embodiment of the present application, when the data management device performs verification processing on the block header template and determines a verification result, the data management device may generate feedback information according to the verification result; and may send feedback information.

It should be noted that, in the embodiment of the present application, after receiving the block header template and the generation rule sent by the first block link point device, the template receiving module in the data management device may parse the block header template and send the block header template to the template verification module, and then the template verification module in the data management device may perform verification processing on the block header template and generate feedback information according to the verification result.

It should be noted that, in the embodiment of the present application, the template verification module in the data management device may perform verification processing on the block header template, and if the verification result is that verification is successful, the block header template and the generation rule may be stored in the first template database; if the verification result is verification failure, the verification failure reason can be determined, and feedback information is generated based on the verification failure reason.

It should be noted that, in an embodiment of the present application, the first template database may include a first template repository in the secondary management system.

It should be noted that, in the embodiment of the present application, the template verification module in the data management device may perform verification processing on the block header template, if the verification result is that the verification is successful, the block header template and the generation rule may be stored in the first template storage, and the first template storage may store the template under a new entry or an existing entry according to whether the block header template is of a new type or an updated type, so that other necessary modules may call the new entry or the existing entry, and may generate feedback information based on the verification success information.

Further, in the embodiment of the present application, when the data management device sends the feedback information, the feedback information may be sent to the first block link point device or other block link point devices by unicast or broadcast; or, the feedback information can be sent to the first block link point device or other block link point devices through a block chain uplink mechanism; wherein, the feedback information comprises verification failure reasons or verification success information.

It should be noted that, in the embodiment of the present application, if the receiving manner of the data management device receiving the block header template and the generating rule sent by the first block chain node device is a unicast or broadcast manner, when the data management device sends the feedback information, the data management device may send the feedback information to the first block chain link point device or other block chain link point devices through the unicast or broadcast manner; if the receiving mode of the data management device receiving the block header template and the generating rule sent by the first block chain node device is a block chain uplink mechanism, the data management device can send feedback information to the first block chain link point device or other block chain link point devices through the block chain uplink mechanism.

Step 103, if the verification result is that the verification is successful, generating a block header based on the generation rule; wherein the block header includes a contribution check code.

In the embodiment of the application, after verification processing is performed on the block header template, and a verification result is determined, if the verification result is successful, the data management device generates the block header based on a generation rule; wherein the block header includes a contribution check code.

It should be noted that, in the embodiment of the present application, the conventional blockchain is composed of a blockhead and a blockbody, and fig. 11 is a block chain structure schematic diagram provided in the embodiment of the present application, as shown in fig. 11, the "difficulty" and "random number" fields in the blockhead are used for performing uplink workload verification, however, for the alliance chain and the private chain, the two fields are not applicable and have no practical meaning, so the present application removes the "difficulty" and "random number" fields in the blockhead, and adds the contribution check code field, where the newly added field has independence and does not affect the existing field functions in the existing block.

In the embodiment of the present application, when the data management device generates the block header based on the generation rule, the data management device may first generate the contribution check code according to the generation rule, and may further generate the block header according to the contribution check code.

Further, in the embodiment of the present application, when the data management device generates the contribution check code, at least one piece of feature information corresponding to the data set may be determined based on the generation rule; a hash process may then be performed based on the at least one characteristic information to determine a contribution check code.

It should be noted that, in the embodiment of the present application, after the data management device performs hash processing according to at least one feature information to determine the contribution check code, when generating the block header according to the contribution check code, the data management device may delete the "difficulty" and the "random number" fields in the block header of the conventional blockchain, and then may add the contribution check code field to the block header, so as to generate the block header including the contribution check code, and fig. 12 is a schematic block header structure provided in the embodiment of the present application, and as shown in fig. 12, the block header structure includes the contribution check code, the parent block hash value, the version number, the timestamp, and the Merkel root.

It should be noted that, in the embodiment of the present application, the data management device determines the contribution check code may be obtained by performing hash processing on at least one piece of feature information corresponding to the data set, that is, the contribution check code may be a hash value formed by at least one piece of feature information corresponding to the data set, where the hash value may be extracted based on features of a large amount of data, and the hash function has a mathematical non-falsifiable characteristic, where the hash value is very difficult to falsify, and the cost of falsification is far exceeding the cost of falsification and exaggeration, so that the generation of exaggeration behavior can be effectively prevented, thereby reducing the probability of the data management device exaggerating the workload of nodes, and further improving the accuracy of reporting the contribution.

Step 104, the block head is processed to manage data based on the contribution check code.

In the embodiment of the present application, if the verification result is that the verification is successful, the data management device may perform uplink processing on the block header after generating the block header based on the generation rule, so that the first block link point device performs data management based on the contribution check code.

It should be noted that, in the embodiment of the present application, the data management device performs uplink processing on the block header, where the uplink block header includes a contribution check code for proving the contribution and other necessary information, and the data management device may further uplink the block body, where the uplink block body includes various parameters generated by FML training, and various rules for generating the contribution check code.

Further, in the embodiment of the present application, when the first blockchain node device performs data management based on the corresponding contribution check code, if the contribution confirmation and the incentive issue are required, the template and the generation rule corresponding to the time can be extracted from the second template storage library in the primary management system, and the information of the contribution check code submitted by each node (data management device) can be obtained from the blockchain.

In the embodiment of the present application, the first block link point device may compare and check the contribution hash value generated according to the reproduction result with the "contribution check code" information submitted by each node (data management device) obtained from the block chain, to determine whether the secondary system node has fraud, and perform incentive issuing on the node company without fraud, and punish the node company with fraud.

In summary, in the embodiment of the present application, the "difficulty" and "random number" fields in the block header are removed, and the contribution check code field is newly added, so that the problem that the uplink rights are strived for by using the calculation force can be solved, the problem that the conventional block link point cannot support determining the contribution amount participating in FML calculation can be solved, and meanwhile, the primary management system and the secondary management system can perform generation, analysis and feasibility verification on the block header template, and realize notification, uplink and the like on the "contribution amount check code" and other necessary block information, and each module runs with definite work division and high efficiency, so that the management efficiency of the primary management system is improved.

The embodiment of the application provides a data management method based on a block chain, which comprises the following steps: the data management equipment receives a block header template and a generation rule issued by first block chain node equipment; performing verification processing on the block header template, and determining a verification result; if the verification result is that the verification is successful, generating a block header based on the generation rule; wherein the block header includes a contribution check code; the block header is processed to perform data management based on the contribution check code. It can be seen that the data management device can receive the block header template and the generation rule issued by the first block chain node device; and then after the result of verification processing on the block header template is determined to be successful in verification, generating a block header comprising a contribution check code by utilizing a generation rule, and performing uplink processing on the block header, so that the first block chain link point equipment can perform data management based on the contribution check code. That is, in the application, the data management device can report the corresponding contribution check code to the first blockchain node device through the blockhead template and the generation rule issued by the first blockchain node device, so as to perform verification processing based on the contribution check code, thereby effectively solving the problem that the data management device exaggerates the workload of the nodes, and further improving the accuracy of reporting the contribution.

Example two

Based on the above embodiments, still another embodiment of the present application provides a data management method based on a blockchain, which is applied to a first blockchain link point device. Fig. 13 is a schematic diagram of a second data management method based on a blockchain according to an embodiment of the present application, as shown in fig. 13, the data management method based on a blockchain of a first blockchain node device may include the following steps:

step 201, determining a generation rule, and generating a block header template according to the generation rule.

In an embodiment of the present application, the first block link point device may determine a generation rule and generate a block header template based on the generation rule.

It should be noted that, in an embodiment of the present application, the first block link point device may include a primary management system, where the primary management system may be located in a headquarter block chain node, and as shown in fig. 9, the primary management system architecture includes a rule generation module, a template rule base, a template generation module, a template update notification module, a second template storage, a template reception verification module, and other necessary modules.

It should be noted that, in the embodiment of the present application, after the first blockchain node device generates the blockhead template according to the generation rule, the blockhead template and the generation rule may be added to the second template database; or updating the second template database through the block header template.

It should be noted that, in an embodiment of the present application, the second template database may include a repository, for example, the second template database may include a second template repository in the primary management system.

The rule generating module in the primary management system receives a manual instruction or based on a predefined rule and the like, starts a new/updated task of the block header template, generates a new or extracts relevant parameters of a corresponding composition template from a template rule base based on the manual instruction or the predefined rule/policy or a built-in AI algorithm and the like, determines a composition rule of a contribution check code and issues the composition rule to the template generating module, the template generating module can generate a new block header template based on the received composition rule, then the template generating module can send the new block header template to a second template storage, the second template storage can create a new entry, then the block header template and the generation rule are added to the corresponding entry directory, and if the block header template is updated, the second template storage can store the new template to the existing entry directory and update the corresponding version number.

Further, in the embodiment of the present application, the second template repository may feed back, to the template generation module, information whether the tile header template and the generation rule store success or whether the tile header template update succeeds, so that the template generation module may send the new tile header template and the generation rule to the template update notification module, so that the template update notification module performs subsequent notification.

And 202, issuing the block header template and the generation rule to the data management equipment so that the data management equipment generates the block header comprising the contribution check code based on the generation rule and performs data management based on the contribution check code.

It should be noted that, in the embodiment of the present application, after the first block link point device determines the generation rule and generates the block header template according to the generation rule, the block header template and the generation rule may be issued to the data management device, so that the data management device generates the block header including the contribution check code based on the generation rule and performs data management based on the contribution check code.

It should be noted that, in an embodiment of the present application, the data management device may include a secondary management system, where the secondary management system may be located in each non-primary blockchain node, and as shown in fig. 8, the secondary management system architecture includes a template receiving module, a template verification module, a first template repository, a template update feedback module, and other necessary modules.

It should be noted that, in the embodiment of the present application, when the first block link point device sends the block header template and the generation rule to the data management device, the first block link point device may send the block header template and the generation rule to the data management device in a unicast or broadcast manner; alternatively, the chunk header templates and the generation rules may be sent to the data management device via a blockchain uplink mechanism.

The embodiment of the application provides a data management method based on a block chain, which comprises the following steps: the first block chain link point equipment determines a generation rule and generates a block head template according to the generation rule; the first blockchain node device issues a blockhead template and a generation rule to the data management device, so that the data management device generates a blockhead comprising a contribution check code based on the generation rule, and performs data management based on the contribution check code. It can be seen that the first blockchain node device may determine the generation rule first, and then generate the blockhead template according to the generation rule; and then the block header template and the generation rule can be issued to the data management device, so that the data management device generates a block header based on the generation rule, the block header comprises a contribution check code, and the first block chain node device can perform data management based on the contribution check code, thereby improving the data management efficiency of the first block chain node device.

Example III

Based on the above embodiments, still another embodiment of the present application provides a blockchain-based data management method applied to a data management system including a data management device and a first blockchain link point device. Fig. 14 is a schematic diagram III of a data management method based on a blockchain according to an embodiment of the present application, as shown in fig. 14, the data management method based on a blockchain of a data management system may include the following steps:

step 301, the first blockchain node device determines a generation rule, and generates a blockhead template according to the generation rule.

It should be noted that, in the embodiment of the present application, as shown in fig. 10, the template parameter information of the tile header template may include: the application does not limit the template parameter information content of the block header template specifically.

Further, in an embodiment of the present application, as shown in fig. 7, the data management system may include a data management device and a first block link point device, where the data management system may include any number of first block link point devices and any number of data management devices, and the present application is not limited in detail. For example, as shown in FIG. 7, the data management system may include a first blockchain node device and a plurality of data management devices.

Step 302, the first blockchain node device issues a blockhead template and a generation rule to the data management device, so that the data management device generates a blockhead including a contribution check code based on the generation rule, and performs data management based on the contribution check code.

Step 303, the data management device performs verification processing on the block header template, and determines a verification result.

Step 304, if the verification result is that the verification is successful, generating a block header based on the generation rule; wherein the block header includes a contribution check code.

It should be noted that, in the embodiment of the present application, the conventional blockchain is composed of a blockhead and a blockbody, as shown in fig. 11, the "difficulty" and "random number" fields in the blockhead are used for performing the workload certification of the uplink, however, the two fields are not applicable to the alliance chain and the private chain, and have no practical significance, so the present application removes the "difficulty" and "random number" fields in the blockhead, and adds the contribution check code field, and the newly added field has independence and does not affect the existing field functions in the existing block.

Further, in an embodiment of the present application, as shown in fig. 12, a parent block hash value, a version number, a timestamp, merkel root, and a contribution check code are included in the block header structure.

Step 305, performing uplink processing on the block header to perform data management based on the contribution check code.

The embodiment of the application provides a data management method based on a block chain, which comprises the following steps: the first block chain link point equipment determines a generation rule and generates a block head template according to the generation rule; the first block chain node equipment transmits the block head template and the generation rule to the data management equipment, and the data management equipment can verify the block head template to determine a verification result; if the verification result is that the verification is successful, generating a block header based on the generation rule; wherein the block header includes a contribution check code; the block header is processed to perform data management based on the contribution check code. It can be seen that the data management device can receive the block header template and the generation rule issued by the first block chain node device; and then after the result of verification processing on the block header template is determined to be successful in verification, generating a block header comprising a contribution check code by utilizing a generation rule, and performing uplink processing on the block header, so that the first block chain link point equipment can perform data management based on the contribution check code. That is, in the present application, the data management device may perform the reporting process of the corresponding contribution check code to the first blockchain node device through the blockhead template and the generation rule issued by the first blockchain node device, so as to perform the verification process based on the contribution check code, thereby effectively solving the problem that the data management device exaggerates the workload of the nodes, further improving the accuracy of reporting the contribution, and simultaneously improving the data management efficiency of the first blockchain node device.

Example IV

Based on the above embodiments, still another embodiment of the present application provides a data management method based on a blockchain, where a conventional blockchain component is composed of a blockhead and a blockbody, and as shown in fig. 11, the "difficulty" and the "random number" in the blockhead are used for performing the workload certification of the uplink. For the alliance chain and the private chain, the two fields are not applicable, and have no practical application meaning, and as the participants of the alliance chain and the private chain are relatively few and do not need to rely on strong calculation force to carry out workload certification like a public chain (especially the bitcoin and the ethernet coin), the design of the corresponding part of the block head should consider to solve the verification problem of the authenticity of the added content.

In the practical application process, the federal learning needs each node to jointly participate in the training of the model, and in the process, the workload contribution of each node is mainly in two aspects, namely the number of times of participating in the training and the data amount provided by the training. The former can be proved by the number of times of the uplink, and the latter can cause the volume of the blockchain to be excessively large due to the excessive data volume, so that a corresponding proving method is not available at present, but can only be embodied by unilateral statement and unconditional trust. In order to solve this problem, the application proposes that the method can be solved by hashing one or more types of proprietary features of a data set for single training and then putting the hashed data feature values into fields of a block header, and the method can not solve the trust problem in real time, but has the relevant evidence, and can be verified by performing actual operations in a database to the node in the later stage. The method is a newly added mode based on signature authentication, and can not directly carry out the verification, but the application scene is mainly that a alliance chain or a private chain is used, the invasion probability is small, and related nodes generally only have the attempt of exaggerating the workload of the nodes and other aversion attempts are usually avoided by other security measures, so the method has feasibility. The newly added field has independence, does not influence the existing field and functions of the existing block, and only needs to newly add functions without modifying other functions, so that the newly added field can be combined with other existing multiple security modes, and the exaggeration workload of the node is effectively prevented.

It should be noted that, in the embodiment of the present application, the specific composition structure of the block header is shown in fig. 12, where the block header removes the "difficulty" and the "random number" in the block header that is not commonly used in the application scenarios of the telecommunications industry alliance chain and the private chain, and the "contribution check code" field is newly added, where the field is a hash value composed of one to multiple types of data features used in FML single training, and in view of the hash value being extracted based on the features of a large amount of data, and the mathematical non-counterfeitable characteristic of the hash function, the difficulty of forging the hash value is very high, far exceeding the cheating exaggeration cost, and the generation of the exaggeration behavior can be effectively prevented.

It should be noted that, in the embodiment of the present application, the contribution check code not only solves the problem of robbing the uplink rights by using computing force, but also solves the problem that the conventional block link point cannot support determining the contribution of participating in FML calculation. The original participation in FML calculation usually adopts to directly uplink a large amount of information, or newly create a chain, or only the information of the participants is uplink, and the parameters proposed by the proposal are directly on the block head of the block chain, so that the problem that the uplink information of the solution is too much or too little and the contribution cannot be recorded is solved.

It should be noted that, in the embodiment of the present application, the number of bits of the contribution check code may be formulated based on the corresponding scenario, the service requirement, and the security requirement, and the main characteristic basis of the contribution check code may include, but is not limited to, the number of data pieces, the size of a data file, the corresponding data of a specific item (such as the information of the data of the 100 th, 200 th, and 300 th pieces), the generating data of a specific time interval (such as the information of the 1 st piece of data generated after every 30 minutes interval), the total duration of the generating of the data set, and the generating time of the x-th piece of the data set, and the contribution check code may be obtained through calculation in the formula (1).

Contribution check code = Hash (feature 1 corresponds to a string of binary values + … + feature N corresponds to a string of binary values) formula (1)

The selection rules and detailed information of the feature 1 and the feature 2 … feature N may be formulated and issued through a smart contract (smart contract) or a primary management system (first blockchain node device).

Illustratively, in an embodiment of the present application, the selection rules may include the following: (1) The training logs are arranged according to the time sequence, log entries of a specific time interval (such as the first piece after 1800 s) are taken together to form a character string, and then hash processing (such as sha-256 and the like) is carried out; (2) The application does not limit the mode of selecting rules and the mode of dynamically combining various sub-rules in a specific way by carrying out hash processing on a character string formed by the number of the items of the training set, training data of specific number intervals (such as 1 st, 3001, 6001 … … and last 1) ordered according to specific rules (such as time sequence), file size of the training set and the like.

It should be noted that, in the embodiment of the present application, as shown in fig. 9, the primary management system architecture includes a rule generating module, a template rule base, a template generating module, a template update notification module, a second template storage, a template receiving verification module, and other necessary modules.

It should be noted that, in an embodiment of the present application, the rule generating module in the primary management system architecture may periodically or aperiodically generate a generation rule of "contribution check code" of the block header based on a predefined rule, expert experience, upper management system notification, and/or intelligent contract predefined information, and transmit the generated rule to the rule issuing module. The template rule base may deliver predefined rule constituent units based on the request of the rule generating module for the rule generating module to generate a complete rule template with one or more rule constituent units and other execution requirement information. The template generation module may generate a new tile header template based on the received "contribution check code" generation rule from the "rule generation module". The template update notification module can perform security processing (such as encryption by using a private key), then issue the security processing to a node of the secondary management system (secondary management system), and the issuing can be realized in a unicast and broadcast mode or can be recorded in a uplink mode. The second template storage library is used for storing the templates generated by the template generating module and the corresponding generating rules for later calling and viewing. The template receiving verification module can be used for verifying whether other nodes have received the updated template, and the module is optional; when using unicast or broadcast forms, this module is mandatory; when using blockchain-style notifications, this module may exist alone to implement all nodes to receive authentication functionality, or may be enhanced by other necessary modules on top of traditional functionality to implement authentication functionality, at which point this module may be incorporated into an existing module and need not exist alone. Other necessary modules can be used to apply the templates and rules to implement the functions of the conventional blockchain, and are generally implemented in the industry, and will not be described in detail herein.

It should be noted that, in the embodiment of the present application, the template creation/template update procedure for the primary management system may include the following steps: step 1: the rule generating module receives a manual instruction or decides to start a new/updated task of the block head template based on a predefined rule and the like; step 2: the rule generation module generates new or extracts relevant parameters corresponding to the composition template from a template rule base based on manual instructions or predefined rules/policies or built-in AI algorithm and the like, determines composition rules of a contribution check code and sends the composition rules to the template generation module; step 3: the template generating module generates a new template based on the received composition rule; step 4: the template generating module sends the new template to a second template storage library; step 5 (a): creating a new entry aiming at a block header template new task, and storing the new entry under a corresponding entry directory by a second template storage library; step 5 (b): aiming at the block head template updating task, the second template storage library stores the new template under the existing entry list and updates the corresponding version number; step 6: the second template storage library feeds back a notice of successful storage to the template generation module, otherwise, failure information is fed back to the rule generation module; step 7: the template generating module sends the new template to the template updating notification module; step 8: the template update notification module notifies the new template and related notification information (such as a generation rule of a 'contribution check code') through a unicast/broadcast mode of a proprietary network or through an existing blockchain uplink mechanism based on a predefined mode; step 9: according to the system safety requirement and the like, executing the following step (a) or step (b); step (a) is optional, if other nodes are notified through a unicast/broadcast mode of the private network, the template receiving verification module is responsible for receiving feedback of the other nodes, after receiving feedback of all the nodes, the template receiving verification module sends notification to other necessary modules to enable the other necessary modules to start to use a new template to realize related functions of the blockchain, otherwise failure information is fed back to the rule generating module; step (b) is optional, if the notice is carried out through the existing blockchain uplink mechanism, the template receiving verification module is independent and is responsible for receiving broadcast feedback of other blockchain nodes, after receiving the feedback of all nodes, the module sends notice to other necessary modules to enable the module to start to use a new template to realize the related function of the blockchain, otherwise, failure information is fed back to the rule generating module; step 10: the template receiving verification module informs the template updating notification module after receiving the confirmation notification of all the nodes; step 11: the template update notification module notifies the other nodes of the formal use (or notification of non-use) of the new template again through the unicast/broadcast mode of the private network selected in the step 9, and the feedback is not required to be received again; step 12: if the other nodes do not receive the formal use notification sent by the node in the specific time, a query (unicast or broadcast) is sent, and the template update notification module sends a new template formal use (or non-use) notification to the other nodes again in a unicast mode aiming at the condition that the message in the step 11 is not successfully sent; step 13: alternatively, if the notification is performed through the existing blockchain uplink mechanism, the "template receiving verification module" does not exist independently, the function of the "template receiving verification module" is realized by enhancing the existing "other necessary modules", namely, the other necessary modules realize the notification of the new template through the uplink process, and if the other nodes do not support the published template, the "other necessary modules" are fed back to the "template receiving module" related failure information.

It should be noted that, in the embodiment of the present application, the above steps 1 to 12 may be performed for the case of updating the unicast/broadcast notification template; steps 1-8 and step 13 are performed for the case of uplink notification template update. For the failure information in step 6, step 9 (b) and step 13, the failure information is gathered to the rule generating module, and the module reports the failure condition information upwards, so that the flow is ended.

Further, in an embodiment of the present application, as shown in fig. 8, the secondary management system (data management device) architecture includes a template receiving module, a template verification module, a first template repository, a template update feedback module, and other necessary modules.

It should be noted that, in the embodiment of the present application, the template receiving module in the secondary management system architecture is responsible for receiving the notification issued by the primary management system and the newly created/updated block header template, and the template verifying module is responsible for performing feasibility verification on the received block header template, storing the verified block header template in the first template storage library for other storage modules to call, and sending the verification result to the template updating feedback module. The first template storage is responsible for storing verified block header templates and corresponding generation rules. The template updating feedback module is responsible for sending the received verification result information (success or failure) to the primary management system node and/or other secondary management system nodes through mechanisms such as unicast/broadcast or uplink consensus. Other necessary modules are used for applying the templates and rules to realize the functions of the conventional blockchain, and are needed along with the common implementation manner in the industry, and are not repeated here.

It should be noted that, in the embodiment, the template creation/template update procedure for the secondary management system may include the following steps: the method for transmitting templates and notifications for unicast/broadcast situations, i.e. situations where a primary management system transmits templates and notifications via unicast and broadcast of an independent network, comprises the following steps: step 1: the template receiving module is responsible for receiving the notification and the template sent by the primary management system, analyzing the notification and the template, and then sending the template to the template verification module; step 2: the template verification module performs feasibility analysis on the newly issued template, if so, whether a contribution check code generation rule is supported or not, and the like; step 3 (a): if the feasibility analysis result in the step 2 is yes, sending confirmation information to a template updating feedback module, sending the template to a template storage library, and then executing the step 4, and the step 3 (b): if the analysis result is that the information is not supported, sending failure notification, unsupported reasons and the like to a template updating feedback module; step 4: the template storage stores the newly created or updated type according to the template, and stores the template under a new entry or an existing entry for other necessary modules to call; step 5: the template updating feedback module sends the confirmation result information and the additional information (such as failure reasons) to corresponding nodes of the primary management system and/or other secondary management systems through a predefined unicast or broadcast mode; wherein steps 1 and 2 are sequentially performed, and steps 4 and 5 are performed when the case of step 3 (a) is satisfied; when the condition of step 3 (b) is met, only step 5 is executed.

Further, in an embodiment of the present application, for the uplink notification case, that is, for the case that the primary management system sends the newly added or updated template through the template uplink, the method may include the following steps: step 1: the other necessary modules receive the uplink request in a traditional mode and forward the uplink request to the template receiving module; step 2: the template receiving module analyzes the received request and then sends the template to the template verification module; step 3: the template verification module performs feasibility analysis on the newly issued template, if so, whether a contribution check code generation rule is supported or not, and the like; step 4 (a): if the feasibility analysis result in the step 3 is that the feasibility analysis result is that the step is supported, sending confirmation information to a template updating feedback module, sending the template to a template storage library, and then executing the step 5; step 4 (b): if the analysis result is that the information is not supported, sending failure notification, unsupported reasons and the like to a template updating feedback module; step 5: the template storage stores the newly created or updated type according to the template, and stores the template under a new entry or an existing entry for other necessary modules to call; step 6: the template updating feedback template is sent to other necessary modules according to the collected information (successful support or failure); step 7: other necessary modules send the information to corresponding nodes of the primary management system and/or corresponding nodes of other secondary management systems through the confirmation step of the traditional block chain uplink request; wherein, the steps 1-3 are sequentially executed, and when the condition of the step 4 (a) is met, the steps 5-7 are executed; when the condition of step 4 (b) is met, only step 6-7 is executed.

Further, in the embodiment of the present application, the application implementation of the uplink information trace back may be as follows: the headquarter node/system can start FML work first, obtain the template predefined or newly generated by the primary management system to which the proposal belongs and the related data for FML training, and then send the template to the corresponding company nodes of each level in unicast and broadcast modes or send the information in uplink modes; each node can respectively train the submodel and interact with each other according to the algorithm requirement of the FML, and the block head of the uplink block contains a contribution check code and other necessary information for proving the contribution; the block body of the uplink block will contain various parameters generated by FML training and, optionally, various rules for generating the contribution check code. When the training is finished and contribution confirmation and excitation release are required, operation and maintenance personnel of the first-level management system node extract templates and generation rules corresponding to the time from a second template storage library of the first-level management system, and acquire contribution check code information submitted by each node from a blockchain. The operation and maintenance personnel can enter the secondary management system node in the field, selectively retrain related data, uplink information and the like according to rules for checking the generation template, compare and check the contribution hash value generated according to the reproduction result with the recorded contribution check code information, judge whether the secondary system node has deception, excite and issue the node company without deception, and punish the node company with deception.

Example five

Based on the above embodiments, the embodiment of the present application provides a data management device, fig. 15 is a schematic diagram of the composition structure of the data management device, and as shown in fig. 15, the data management device 10 further includes a receiving unit 11, a verifying unit 12, a first generating unit 13, a processing unit 14,

the receiving unit 11 is configured to receive a block header template and a generation rule issued by the first blockchain node device;

the verification unit 12 is configured to perform verification processing on the block header template, and determine a verification result;

the first generating unit 13 is configured to generate a block header based on the generation rule if the verification result is that the verification is successful; wherein the block header includes a contribution check code;

the processing unit 14 is configured to perform uplink processing on the block header to perform data management based on the contribution check code.

In an embodiment of the present application, further, fig. 16 is a schematic diagram of a composition structure of a data management device, as shown in fig. 16, the data management device 10 according to the embodiment of the present application may further include a first processor 15, a first memory 16 storing executable instructions of the first processor 15, further, the data management device 10 may further include a communication interface 17, and a bus 18 for connecting the first processor 15, the first memory 16, and the communication interface 17.

In an embodiment of the present application, the first processor 15 may be at least one of an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a digital signal processor (Digital Signal Processor, DSP), a digital signal processing device (Digital Signal Processing Device, DSPD), a programmable logic device (ProgRAMmable Logic Device, PLD), a field programmable gate array (Field ProgRAMmable Gate Array, FPGA), a central processing unit (Central Processing Unit, CPU), a controller, a microcontroller, and a microprocessor. It will be appreciated that the electronics for implementing the above-described processor functions may be other for different devices, and embodiments of the present application are not particularly limited. The data management device 10 may further comprise a first memory 16, which first memory 16 may be connected to the first processor 15, wherein the first memory 16 is adapted to store executable program code comprising computer operating instructions, which first memory 16 may comprise a high speed RAM memory, and may further comprise a non-volatile memory, e.g. at least two disk memories.

In an embodiment of the application, a bus 18 is used to connect the communication interface 17, the first processor 15 and the first memory 16 and the mutual communication between these devices.

In an embodiment of the application, the first memory 16 is used to store instructions and data.

Further, in the embodiment of the present application, the first processor 15 is configured to receive a block header template and a generation rule issued by the first blockchain node device; performing verification processing on the block header template, and determining a verification result; if the verification result is that the verification is successful, generating a block header based on the generation rule; wherein the block header includes a contribution check code; and processing the block head uplink to enable the first block link point device to conduct data management based on the contribution check code.

In practical applications, the first Memory 16 may be a volatile Memory (RAM), such as a Random-Access Memory (RAM); or a nonvolatile Memory (non-volatile Memory), such as a Read-Only Memory (ROM), a flash Memory (flash Memory), a Hard Disk (HDD) or a Solid State Drive (SSD); or a combination of memories of the above kind and providing instructions and data to the first processor 15.

The embodiment of the application provides data management equipment, which receives a block header template and a generation rule issued by first block chain node equipment; performing verification processing on the block header template, and determining a verification result; if the verification result is that the verification is successful, generating a block header based on the generation rule; wherein the block header includes a contribution check code; the block header is processed to perform data management based on the contribution check code. It can be seen that the data management device can receive the block header template and the generation rule issued by the first block chain node device; and then after the result of verification processing on the block header template is determined to be successful in verification, generating a block header comprising a contribution check code by utilizing a generation rule, and performing uplink processing on the block header, so that the first block chain link point equipment can perform data management based on the contribution check code. That is, in the application, the data management device can report the corresponding contribution check code to the first blockchain node device through the blockhead template and the generation rule issued by the first blockchain node device, so as to perform verification processing based on the contribution check code, thereby effectively solving the problem that the data management device exaggerates the workload of the nodes, and further improving the accuracy of reporting the contribution.

Embodiments of the present application provide a computer-readable storage medium having stored thereon a program which, when executed by a processor, implements a blockchain-based data management method as described above.

Specifically, the program instructions corresponding to a blockchain-based data management method in the present embodiment may be stored on a storage medium such as an optical disc, a hard disk, or a usb disk, and when the program instructions corresponding to a blockchain-based data management method in the storage medium are read or executed by an electronic device, the method includes the following steps:

The embodiment of the present application provides a first blockchain node device, fig. 17 is a schematic diagram of the composition structure of the first blockchain node device, as shown in fig. 17, the first blockchain node device 20 further includes a determining unit 19, a second generating unit 20, a issuing unit 21,

The determining unit 19 is configured to determine a generation rule by using the first block link point device;

the second generating unit 20 is configured to generate a block header template according to the generating rule;

the issuing unit 21 is configured to issue the block header template and the generation rule to a data management device by using the first blockchain node device, so that the data management device generates a block header including a contribution check code based on the generation rule, and performs data management based on the contribution check code.

In an embodiment of the present application, further, fig. 18 is a schematic diagram of a second component structure of the first blockchain node device, as shown in fig. 18, the first blockchain node device 20 according to the embodiment of the present application may further include a second processor 22, a second memory 23 storing executable instructions of the second processor 22, further, the first blockchain node device 20 may further include a communication interface 24, and a bus 25 for connecting the second processor 22, the second memory 23 and the communication interface 24.

In an embodiment of the present application, the second processor 22 may be at least one of an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a digital signal processor (Digital Signal Processor, DSP), a digital signal processing device (Digital Signal Processing Device, DSPD), a programmable logic device (ProgRAMmable Logic Device, PLD), a field programmable gate array (Field ProgRAMmable Gate Array, FPGA), a central processing unit (Central Processing Unit, CPU), a controller, a microcontroller, and a microprocessor. It will be appreciated that the electronics for implementing the above-described processor functions may be other for different devices, and embodiments of the present application are not particularly limited. The first block link point device 20 may further comprise a second memory 23, which second memory 23 may be connected to the second processor 22, wherein the second memory 23 is adapted to store executable program code comprising computer operation instructions, which second memory 23 may comprise a high speed RAM memory, and may further comprise a non-volatile memory, e.g. at least two disk memories.

In an embodiment of the application, a bus 25 is used to connect the communication interface 24, the second processor 22 and the second memory 23 and the mutual communication between these devices.

In an embodiment of the application, the second memory 23 is used for storing instructions and data.

Further, in the embodiment of the present application, the second processor 22 is configured to determine a generation rule by using the first block link point device, and generate a block header template according to the generation rule; the first blockchain node device issues the blockhead template and the generation rule to data management equipment, so that the data management equipment generates a blockhead comprising a contribution check code based on the generation rule, and performs data management based on the contribution check code.

In practical applications, the second Memory 23 may be a volatile Memory (RAM), such as a Random-Access Memory (RAM); or a nonvolatile Memory (non-volatile Memory), such as a Read-Only Memory (ROM), a flash Memory (flash Memory), a Hard Disk (HDD) or a Solid State Drive (SSD); or a combination of the above types of memories and provides instructions and data to the second processor 22.

The embodiment of the application provides first block chain link point equipment, which determines a generation rule and generates a block head template according to the generation rule; the first blockchain node device issues a blockhead template and a generation rule to the data management device, so that the data management device generates a blockhead comprising a contribution check code based on the generation rule, and performs data management based on the contribution check code. It can be seen that the first blockchain node device may determine the generation rule first, and then generate the blockhead template according to the generation rule; and then the block header template and the generation rule can be issued to the data management device, so that the data management device generates a block header based on the generation rule, the block header comprises a contribution check code, and the first block chain node device can perform data management based on the contribution check code, thereby improving the data management efficiency of the first block chain node device.

The first block chain link point equipment determines a generation rule and generates a block head template according to the generation rule;

the first blockchain node device issues the blockhead template and the generation rule to data management equipment, so that the data management equipment generates a blockhead comprising a contribution check code based on the generation rule, and performs data management based on the contribution check code.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of a hardware embodiment, a software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, magnetic disk storage, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of implementations of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each block and/or flow of the flowchart illustrations and/or block diagrams, and combinations of blocks and/or flow diagrams in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart block or blocks and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart block or blocks and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks and/or block diagram block or blocks.

The foregoing description is only of the preferred embodiments of the present application, and is not intended to limit the scope of the present application.

Claims

1. A blockchain-based data management method, the method being applied to a data management device, the method comprising:

2. The method of claim 1, wherein the generating a block header based on the generation rule comprises:

and generating the contribution check code according to the generation rule, and generating the block header according to the contribution check code.

3. The method of claim 2, wherein the generating the contribution check code according to the generation rule comprises:

determining at least one piece of characteristic information corresponding to the data set based on the generation rule;

and carrying out hash processing according to the at least one piece of characteristic information, and determining the contribution check code.

4. The method of claim 1, wherein the template parameter information of the tile header template comprises: rule metadata, composition characteristic information, inspection object information, inspection requirements, security information are generated.

5. The method according to claim 1, wherein the method further comprises:

receiving the block header template and the generation rule in a unicast or broadcast mode; or,

the block header template and the generation rule are received through a blockchain uplink mechanism.

6. The method according to claim 1, wherein the method further comprises:

the feedback information is sent to the first block link point equipment or other block link point equipment in a unicast or broadcast mode; wherein the feedback information includes the verification result; or,

and sending the feedback information to the first block link point device or other block link point devices through a block chain uplink mechanism.

7. The method according to claim 1, wherein the method further comprises:

if the verification result is that the verification is successful, storing the block header template and the generation rule into a first template database;

if the verification result is verification failure, determining a verification failure reason, and generating feedback information based on the verification failure reason.

8. A method of blockchain-based data management, the method being applied to a first blockchain link point device, the method comprising:

9. A data management system comprising a first blockchain node device and a data management device, the method comprising:

the first blockchain node device issues the blockhead template and the generation rule to data management equipment so that the data management equipment generates a blockhead comprising a contribution check code based on the generation rule and performs data management based on the contribution check code;

the data management equipment performs verification processing on the block header template and determines a verification result;

if the verification result is that the verification is successful, generating the block header based on the generation rule; wherein the block header includes a contribution check code;

The data management device performs uplink processing on the block head to perform data management based on the contribution check code.

10. A data management apparatus, characterized in that the data management apparatus comprises: a receiving unit, a verification unit, a first generation unit, a processing unit,

11. A data management apparatus, characterized in that the data management apparatus comprises: a first processor and a first memory; wherein,,

the first processor being adapted to perform the method of any of claims 1-7 when the computer program is run.

12. A first block link point device, the first block link point device comprising: a determining unit, a second generating unit, a issuing unit,

13. A first block link point device, the first block link point device comprising: a second processor and a second memory; wherein,,

the second processor being adapted to perform the method of claim 8 when the computer program is run.

14. A computer readable storage medium, characterized in that the storage medium has stored thereon a computer program code which, when executed by a computer, performs the method of any of claims 1-7 or 8.