Blockchain-based software distribution and update methods

Abstract

This invention discloses a blockchain-based software distribution and update method, relating to the field of software distribution technology. The key technical points include the following steps: obtaining complete data of the software to be distributed and node identity authentication information of the blockchain network; wherein the node identity authentication information includes node permission level, node domain, and node trust rating; processing the complete data of the software to be distributed to obtain software block hash values; obtaining node synchronization deviation values ​​of the distributed software based on software synchronization verification data of the distributed software in each authorized node; generating differentiated software update strategies for each authorized node based on version anomaly coefficients and node synchronization deviation values; executing differentiated software updates for nodes according to the differentiated software update strategies; generating update traceability information after hash calculation and chain cascading during the software update process, thereby improving the security and stability of the entire software distribution and update system.

Description

Technical Field

[0001] This invention relates to the field of software distribution technology, and more specifically, to a blockchain-based method for software distribution and updating. Background Technology

[0002] Software distribution and updates are crucial for ensuring the stable operation and iterative upgrades of business systems. Traditional software distribution often employs a centralized architecture, relying on a single central server to store, distribute, and verify software packages. This model carries a significant risk of single point of failure. If the central server is attacked or malfunctions, the entire distribution process will be interrupted, potentially leading to security issues such as software data tampering and malware injection. Furthermore, traditional distribution methods lack access control over receiving nodes. Node authentication relies on simple usernames and passwords or IP whitelists, failing to achieve multi-dimensional verification of node permission levels, business domains, and trustworthiness. This makes it easy for unauthorized nodes to illegally obtain software data, resulting in the leakage of core business data or system intrusion. Summary of the Invention

[0003] In view of the shortcomings of existing technologies, the purpose of this invention is to provide a blockchain-based software distribution and update method.

[0004] To achieve the above objectives, the present invention provides the following technical solution:

[0005] A blockchain-based software distribution and update method, comprising the following steps:

[0006] Obtain complete data of the software to be distributed and node identity authentication information of the blockchain network; wherein, the node identity authentication information includes node permission level, node domain and node trust rating;

[0007] The complete data of the software to be distributed is processed to obtain the software block hash value; after processing the node permission level, node domain and node trust rating, a software distribution authorization node chain is built.

[0008] The software block hash value is processed with the node address of the software distribution authorization node chain to obtain the evidence storage result; based on the evidence storage result, the targeted distribution of the software is completed in the software distribution authorization node chain;

[0009] The version anomaly coefficient of the distributed software is obtained based on the real-time running data and software version traceability data of the distributed software in each authorized node, and the node synchronization deviation value of the distributed software is obtained based on the software synchronization verification data of the distributed software in each authorized node.

[0010] A differentiated software update strategy is generated for each authorized node based on the version anomaly coefficient and node synchronization deviation value;

[0011] Based on the software differential update strategy, the execution node performs differential software updates, and after hash calculation and chain cascading during the software update process, update traceability information is generated.

[0012] Preferably, the complete data of the software to be distributed includes the software installation package, software configuration file, software function description document, and software digital signature.

[0013] Preferably, the complete data of the software to be distributed is processed to obtain the software block hash value, specifically including the following steps:

[0014] The software installation package and software configuration files are divided into blocks to obtain several software data blocks.

[0015] Each software data block is hashed to obtain the basic hash value of each data block; the software function specification document and the software digital signature are hashed to obtain the document signature hash value.

[0016] The software block hash value is obtained by concatenating all the basic hash values ​​of the blocks with the document signature hash value.

[0017] Preferably, the software distribution authorization node chain is built after processing the node permission level, the domain to which the node belongs, and the node trust rating, specifically including the following steps:

[0018] Authorized nodes are selected based on node permission level and node trust rating;

[0019] The authorized nodes are classified and clustered based on their respective domains to obtain the clustering results;

[0020] Based on the clustering results and the blockchain chain structure, authorized nodes in the same field are concatenated by node address. After configuring the distribution authorization hash key for the node chain of the concatenated node addresses, a software distribution authorization node chain is built.

[0021] Preferably, the software block hash value is processed with the node address of the software distribution authorization node chain to obtain the evidence storage result, specifically including the following steps:

[0022] Extract the hash features corresponding to the software block hash values; serialize and integrate the hash features of each software block hash value to obtain a hash feature set;

[0023] Extract the node addresses of each node in the software distribution authorization node chain, and sort the node addresses hierarchically to obtain the node address sequence;

[0024] The hash feature set is associated with the node address sequence, and the associated hash features and node addresses are chained together to obtain the chain binding result.

[0025] Verify whether the hash characteristics of the chain binding result are consistent with the hash characteristics of the corresponding software block hash value, and verify whether the node address matches the node address in the software distribution authorization node chain to obtain the association binding information;

[0026] The evidence storage result is obtained by integrating the verified association and binding information.

[0027] Preferably, the targeted distribution of the software is completed in the software distribution authorization node chain based on the evidence storage results, specifically including the following steps:

[0028] Extract the software block hash value of the evidence storage result and the node address of the corresponding authorized node chain, and associate and match the software block hash value and the node address to obtain the target authorized node corresponding to each software block;

[0029] The target identifier of the target authorized node is obtained by performing block encryption processing on the software blocks of the association matching;

[0030] The encryption software block is determined based on the target identifier of the target authorized node, the encryption software block is sent to the authorized node chain, and the node address is verified to be consistent with the target identifier.

[0031] After the verified target authorized node receives the corresponding software block, the targeted software distribution is completed.

[0032] Preferably, the version anomaly coefficient of the distributed software is obtained based on the real-time running data and software version traceability data of the distributed software in each authorized node, specifically including the following steps:

[0033] The real-time operation data includes fault occurrence records and function call frequency; the software version traceability data includes the original software version hash and the distributed version hash of each node.

[0034] The abnormal values ​​of software operation are obtained by correlating the fault occurrence records with the function call frequency;

[0035] The version hash of each node is compared with the original version hash of the software to obtain the version hash deviation value;

[0036] The version anomaly coefficient is obtained by normalizing and weighting the software runtime anomaly value and the version hash deviation value.

[0037] Preferably, the node synchronization deviation value of the distributed software is obtained based on the software synchronization verification data of the distributed software in each authorized node, specifically including the following steps:

[0038] The software synchronization verification data includes node running status synchronization logs;

[0039] Based on the master node of the software distribution authorization node chain, the software version synchronization time difference and data interaction hash matching degree between each child node and the master node are obtained;

[0040] The number of synchronization anomalies is obtained by extracting anomalies from the node's running status synchronization log.

[0041] The node synchronization deviation value is obtained based on the software version synchronization time difference, data interaction hash matching degree, and the number of status synchronization anomalies.

[0042] Preferably, a differentiated software update strategy for each authorized node is generated based on the version anomaly coefficient and the node synchronization deviation value, specifically including the following steps:

[0043] The version anomaly coefficient of each authorized node is compared level by level to obtain the degree of version loss of the node software.

[0044] Determine the data collaboration status between nodes based on the node synchronization deviation value;

[0045] The degree of version degradation is linked to the data collaboration status at each level to locate the software block range corresponding to the anomaly of each node;

[0046] The urgency of updates is determined based on the degree of node version degradation, the update transmission method is determined based on the data collaboration status, and the update content adapted to a single node is determined based on the software block range.

[0047] The update urgency, update transmission method, and update content are combined to form a differentiated software update strategy for each authorized node.

[0048] Preferably, after performing hash calculations and chain concatenation during the software update process, update traceability information is generated, specifically including the following steps:

[0049] During the software update process, an update operation is performed, and a hash operation is performed on the software data corresponding to the update operation to obtain the hash verification result of the update operation.

[0050] The hash verification results generated by the previous update operation are chained together with the hash verification results generated by the current update operation to form a continuous hash verification chain.

[0051] Based on the hash verification link, update node information, update time sequence information, and update content information are integrated to generate update traceability information.

[0052] Compared with the prior art, the present invention has the following beneficial effects:

[0053] This invention utilizes block hashing to process the complete data of the software to be distributed, generating a unique and tamper-proof core identifier for each piece of software data. This effectively avoids the risk of data tampering, forgery, or replacement during software distribution. It combines node permission levels, node domains, and trust ratings to screen authorized nodes and build a node chain. The software block hash value is then linked to the node address for evidence storage, enabling matching and distribution of software blocks with authorized nodes. This solves the problems of unclear node qualifications, chaotic distribution paths, and lack of data traceability in traditional software distribution. Based on node synchronization logs, version synchronization time differences, and data interaction matching data, a node synchronization deviation value is generated to accurately measure the data collaboration status between nodes. This comprehensively and objectively reflects the actual operation and synchronization status of each node, avoiding update failures or resource waste caused by misjudgments of node status. Differentiated update strategies are customized for different nodes based on version anomaly coefficients and node synchronization deviation values, ensuring timely software version repair and security upgrades for high-risk nodes, and improving the security and stability of the entire software distribution and update system. Attached Figure Description

[0054] Figure 1 A schematic diagram illustrating the steps of a blockchain-based software distribution and update method according to an embodiment of the present invention;

[0055] Figure 2 This is a schematic diagram illustrating the steps for obtaining evidence storage results in a blockchain-based software distribution and update method according to an embodiment of the present invention. Detailed Implementation

[0056] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0057] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0058] Secondly, the term "an embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single embodiment or an embodiment selectively excluded from other embodiments.

[0059] Reference Figures 1-2 As shown.

[0060] The embodiments further illustrate the blockchain-based software distribution and update method proposed in this invention.

[0061] A blockchain-based software distribution and update method, comprising the following steps:

[0062] Obtain complete data of the software to be distributed and node identity authentication information of the blockchain network; among which, node identity authentication information includes node permission level, node domain and node trust rating;

[0063] The complete data of the software to be distributed is processed to obtain the software block hash value; after processing the node permission level, node domain and node trust rating, a software distribution authorization node chain is built.

[0064] The software block hash value is processed with the node address of the software distribution authorization node chain to obtain the evidence storage result; based on the evidence storage result, the targeted distribution of the software is completed in the software distribution authorization node chain;

[0065] The version anomaly coefficient of the distributed software is obtained based on the real-time running data and software version traceability data of the distributed software in each authorized node, and the node synchronization deviation value of the distributed software is obtained based on the software synchronization verification data of the distributed software in each authorized node.

[0066] A differentiated software update strategy is generated for each authorized node based on the version anomaly coefficient and node synchronization deviation value;

[0067] Based on the software differential update strategy, the execution node performs differential software updates, and after hash calculation and chain cascading during the software update process, update traceability information is generated.

[0068] The complete data of the software to be distributed includes the software installation package, software configuration files, software function description documents, and software digital signature.

[0069] The complete data of the software to be distributed is processed to obtain the software block hash value, specifically including the following steps:

[0070] The software installation package and software configuration files are divided into blocks to obtain several software data blocks.

[0071] Each software data block is hashed to obtain the basic hash value of each data block; the software function specification document and the software digital signature are hashed to obtain the document signature hash value.

[0072] The software block hash value is obtained by concatenating all the basic hash values ​​of the blocks with the document signature hash value.

[0073] The software installation package and software configuration file are processed by segmentation. The complete software installation package and configuration file are split into several software data blocks according to a preset data block size. For example, a software installation package of 1024KB is divided into 128KB units, resulting in 8 independent software data blocks. This segmentation method can realize fine-grained management of software data, avoid the failure of the whole software due to the corruption of a single data, and provide a data unit basis for subsequent targeted distribution and differentiated updates.

[0074] A preset hash algorithm is used to calculate the hash value for each independent software data block, generating a unique basic hash value corresponding to that data block. For example, hash value H1 is obtained after calculating the hash value for the first data block, hash value H2 is obtained after calculating the hash value for the second data block, and so on until all blocks have corresponding hash values. Each basic hash value can uniquely represent the integrity of the content of the corresponding data block. If any modification is made to the block data, its corresponding hash value will change significantly. Hash calculations are performed on the software functional specification document and the software digital signature. The same hash algorithm is used to calculate the hash value for the complete functional specification document and the digital signature, generating a unique document signature hash value. The document signature hash value can be used to verify the integrity of the software specification information and the signature, ensuring that the specification document has not been tampered with and the digital signature has not been forged during the software distribution process.

[0075] All block base hash values ​​and document signature hash values ​​are concatenated. The block base hash values ​​and document signature hash values ​​are concatenated in a preset order, and then a hash operation is performed on the concatenated overall data to obtain the final software block hash value. If there are 8 block base hash values ​​H1 to H8 and 1 document signature hash value H9, the hash values ​​are concatenated into a whole string in the order H1+H2+H3+H4+H5+H6+H7+H8+H9, and then a hash operation is performed on this string to obtain the software block hash value. The software block hash value H_total = hash algorithm (H1+H2+H3+H4+H5+H6+H7+H8+H9). Here, the plus sign only represents the sequential concatenation of hash values. During the operation, it is necessary to ensure that the encoding format and length of all hash values ​​are consistent to avoid abnormal calculation results due to differences in units or formats. This software block hash value can completely represent the integrity and uniqueness of the entire software data to be distributed.

[0076] After processing node permission levels, node domains, and node trust ratings, a software distribution authorization node chain is built, which includes the following steps:

[0077] Authorized nodes are selected based on node permission level and node trust rating;

[0078] The authorized nodes are classified and clustered based on their respective domains to obtain the clustering results;

[0079] Based on the clustering results and the blockchain chain structure, authorized nodes in the same field are concatenated by node address. After configuring the distribution authorization hash key for the node chain of the concatenated node addresses, a software distribution authorization node chain is built.

[0080] Authorized nodes are selected based on their permission levels and trust ratings. Node permission levels define the scope of a node's authority to perform software distribution, reception, and verification operations within the blockchain network. For example, node permission levels can be divided into 1 to 5 levels, where nodes at level 3 and above have software distribution and reception permissions, while nodes at level below 3 only have data query permissions. The node trust rating measures the trustworthiness of a node in its historical interactions. During the selection process, nodes that meet both the permission level threshold and the trust rating threshold are included in the set of authorized nodes. For example, nodes with a permission level ≥ 3 and a trust rating ≥ 80 are selected as authorized nodes. Nodes that do not meet these criteria are excluded from the software distribution process, thereby ensuring the basic security and reliability of the node chain.

[0081] Authorized nodes are categorized and clustered based on their respective domains to obtain clustering results. The domain of a node identifies its business context, such as finance, healthcare, industrial control, or education. During the categorization and clustering process, authorized nodes with the same domain label are grouped into the same category. Then, clustering algorithms further aggregate nodes within the same category. For example, authorized nodes in the financial sector are subdivided into clusters based on business sub-scenarios, such as payment and settlement, asset management, and risk control. Nodes in each cluster have highly similar business needs and security requirements. The clustering results are quantified using the node domain similarity calculation formula: Node Domain Similarity = Number of Shared Domain Labels / Total Number of Domain Labels. When the node domain similarity is ≥ 0.7, they are grouped into the same cluster, ensuring that the clustered node groups maintain a high degree of consistency in business scenarios and security requirements.

[0082] Based on clustering results and a blockchain-like chain structure, authorized nodes within the same domain are concatenated by node addresses, and a distribution authorization hash key is configured to complete the construction of the software distribution authorization node chain. During the node address concatenation process, authorized nodes within the same cluster are arranged in a preset order, with the address of the preceding node serving as the preceding address of the next node, thus forming a chain structure similar to a blockchain. For example, nodes A, B, and C in the payment and settlement cluster of the financial field are concatenated sequentially, with node B's preceding address being node A's address, and node C's preceding address being node B's address, thereby constructing a node chain with temporal order and correlation. After concatenation, a unique distribution authorization hash key is configured for the entire node chain. This key is jointly generated by all authorized nodes within the chain and is used to verify the legitimacy of subsequent software distribution operations. Only the node holding this key can initiate or receive software block data. The final software distribution authorization node chain possesses both the immutable chain characteristics of a blockchain and achieves domain isolation and access control, providing secure and reliable node network support for targeted software distribution.

[0083] The notarization result is obtained by processing the software block hash value with the node address of the software distribution authorization node chain, specifically including the following steps:

[0084] Extract the hash features corresponding to the software block hash values; serialize and integrate the hash features of each software block hash value to obtain a hash feature set;

[0085] Extract the node addresses of each node in the software distribution authorization node chain, and sort the node addresses hierarchically to obtain the node address sequence;

[0086] The hash feature set is associated with the node address sequence, and the associated hash features and node addresses are chained together to obtain the chain binding result.

[0087] Verify whether the hash characteristics of the chain binding result are consistent with the hash characteristics of the corresponding software block hash value, and verify whether the node address matches the node address in the software distribution authorization node chain to obtain the association binding information;

[0088] The evidence storage result is obtained by integrating the verified association and binding information.

[0089] Software block hash values ​​are unique identifiers representing the integrity of software data. The hash feature extraction process analyzes the core attributes of the hash values, such as hash algorithm type, hash value length, and hash value segmentation characteristics, transforming each software block hash value into a structured hash feature. All hash features corresponding to software blocks are serialized and arranged in a preset order, forming an ordered hash feature set. If there are 8 software block hash values, their corresponding hash features are arranged sequentially according to the block generation order, resulting in a hash feature set containing 8 elements. The order of elements within the hash feature set is consistent with the logical order of the software blocks, ensuring the accuracy of subsequent associations.

[0090] The software distribution authorization node chain is composed of cascaded authorized nodes in the same domain. Each node has a unique blockchain address, which identifies its identity within the network. The hierarchical sorting process is based on the node's permission level, trust rating, or business priority within the chain. For example, the master node address is placed at the beginning of the sequence, followed by the addresses of each child node, or the nodes are sorted from highest to lowest trust rating, thus forming an ordered sequence of node addresses. The sorting rule is quantified using a node priority calculation formula: Node Priority = Node Permission Level × 0.6 + Node Trust Rating × 0.4. Arranging nodes from highest to lowest priority yields a node address sequence that matches the length of the hash feature set, providing an ordered node identification basis for association and binding.

[0091] The hash feature set is associated with the node address sequence, and then the associated hash features and node addresses are chained together to obtain the chained binding result. The association process involves matching the nth element of the hash feature set with the nth element of the node address sequence one-to-one. For example, the first element of the hash feature set corresponds to the first node address in the node address sequence, the second element of the hash feature set corresponds to the second node address in the node address sequence, and so on, completing the full association. The chained binding process links the associated hash features and node addresses in a blockchain chain structure. The end information of the previous association result serves as the pre-verification information for the next association result. For example, the end field of the first group of hash feature and node address binding results serves as the starting verification field of the second group of binding results, thus forming a continuous chain structure to ensure the immutability and traceability of the binding relationship.

[0092] The process involves verifying whether the hash characteristics of the chained binding result are consistent with the hash characteristics of the corresponding software block hash value, and simultaneously verifying whether the node address matches the node address in the software distribution authorization node chain, thus obtaining the associated binding information. The hash characteristic consistency check compares the hash characteristics of the chained binding result with the hash characteristics of the original software block hash value field by field. If all fields match completely, the check passes; if any field differs, the binding is deemed invalid. The node address matching check compares the node address of the chained binding result with the address whitelist of the software distribution authorization node chain to confirm whether the address belongs to the authorized node set. If the address exists in the whitelist, the check passes; otherwise, the binding is deemed invalid. Only association results that pass both checks are considered valid associated binding information. Results that fail the checks are directly discarded to prevent invalid or malicious bindings from entering the evidence storage process.

[0093] The verified association and binding information is integrated to obtain the evidence storage result. All valid association and binding information is concatenated in chain order to form complete evidence storage data. The evidence storage data includes both the hash feature set of the software block hash values ​​and the corresponding authorized node address sequence, while retaining the verification information of the chain binding. The evidence storage result is recorded in the blockchain network, thus serving as a trusted credential of the association between the software block and the authorized node.

[0094] Based on the evidence storage results, the targeted distribution of the software is completed in the software distribution authorization node chain, specifically including the following steps:

[0095] Extract the software block hash value of the evidence storage result and the node address of the corresponding authorized node chain, and associate and match the software block hash value and the node address to obtain the target authorized node corresponding to each software block;

[0096] The target identifier of the target authorized node is obtained by performing block encryption processing on the software blocks of the association matching;

[0097] The encryption software block is determined based on the target identifier of the target authorized node, the encryption software block is sent to the authorized node chain, and the node address is verified to be consistent with the target identifier.

[0098] After the verified target authorized node receives the corresponding software block, the targeted software distribution is completed.

[0099] The process involves extracting the hash values ​​of software blocks from the evidence storage results and matching them with the corresponding authorized node addresses in the authorized node chain. This association and matching process identifies the target authorized node for each software block. The evidence storage results pre-establish a chained binding between software block hash values ​​and authorized node addresses. During extraction, each software block hash value is matched one-to-one with its bound node address according to the chained order of the evidence storage. For example, if the hash value of the first software block is bound to the address of node A, then the target authorized node for that block is node A; if the hash value of the second software block is bound to the address of node B, then the target authorized node is node B. This process continues until all blocks are matched with their corresponding target nodes, ensuring that each software block has a unique receiving node and preventing chaotic distribution or unauthorized reception.

[0100] After association and matching, the software blocks are encrypted to obtain the target identifier of the target authorized node. The block encryption uses an encryption algorithm agreed upon with the target authorized node, such as an asymmetric encryption algorithm. The target node's public key is used to encrypt the corresponding software block, and only the target node holding the corresponding private key can decrypt the block. The target identifier is generated by combining the encrypted software block hash value and the node address: Target Identifier = Hash Algorithm (Encrypted Software Block Hash Value + Node Address), where the plus sign represents data concatenation. The target identifier generated by this formula contains both the encryption characteristics of the software block and the address information of the target node, uniquely identifying the correspondence between the encrypted block and the target node, preventing the block from being tampered with or forwarded to non-target nodes.

[0101] The encrypted software block is determined based on the target identifier of the target authorized node. This encrypted software block is then sent to the authorized node chain, and the consistency between the node address and the target identifier is verified. Before sending, the corresponding encrypted software block is extracted based on the target identifier, ensuring that each encrypted block carries a unique target identifier. The encrypted block and the target identifier are then sent together to the authorized node chain. Upon receipt, the node chain initiates a verification process. The pre-stored node address is parsed from the target identifier and compared with the actual address of the node currently requesting to receive the block. Simultaneously, the hash value of the encrypted block in the target identifier is verified to match the received hash value. Verification is considered valid only when the node address completely matches the address in the target identifier and the hash value verification passes; otherwise, the request to receive the block is rejected, effectively preventing malicious nodes from stealing or tampering with software blocks.

[0102] Once verified, the target authorized node receives the corresponding software block, completing the targeted software distribution. After verification, the target authorized node uses its own private key to decrypt the encrypted software block, obtain the original software block data, and store it in a designated local path. When all software blocks have been successfully distributed to the corresponding target authorized nodes, the nodes concatenate the blocks into complete software data as needed, thus completing the entire targeted software distribution process. This process uses dual verification of encryption and address to ensure that software blocks can only be received by authorized target nodes, and relies on the immutability of the blockchain node chain to achieve accuracy and security in software distribution.

[0103] The version anomaly coefficient of the distributed software is obtained based on the real-time running data and software version traceability data of the distributed software in each authorized node. The specific steps include:

[0104] Real-time operational data includes fault occurrence records and function call frequency; software version traceability data includes the original software version hash and the distributed version hash of each node.

[0105] The abnormal values ​​of software operation are obtained by correlating the fault occurrence records with the function call frequency;

[0106] The version hash of each node is compared with the original version hash of the software to obtain the version hash deviation value;

[0107] The version anomaly coefficient is obtained by normalizing and weighting the software runtime anomaly value and the version hash deviation value.

[0108] Real-time operational data includes fault occurrence records and function call frequencies. Software version traceability data includes the original software version hash and the distribution version hashes for each node. Fault occurrence records are used to count the number of crashes, freezes, and function failures that occur during software operation. Function call frequencies are used to measure the usage frequency of each software function, reflecting the activity level and potential risks of the function. The original software version hash is a baseline hash value generated before software distribution, representing the original software data characteristics that have not been tampered with. The distribution version hashes for each node are the actual hash values ​​generated after the node receives the software, used to reflect data changes during software distribution or operation.

[0109] Software operational anomalies are determined by correlating fault occurrence records with function call frequencies. During the correlation analysis, fault occurrence records are categorized and statistically analyzed; for example, faults are divided by functional modules, and the number of faults for each functional module is counted. The degree of anomaly is then calculated by combining this with the call frequency of the corresponding functional module. If a functional module has a high call frequency but few faults, it indicates that the function is running stably and has a low operational anomaly value. Conversely, if a functional module has a low call frequency but many faults, or a high call frequency with a simultaneously increasing number of faults, it indicates that the function has operational risks and a high operational anomaly value. Software operational anomaly value = number of faults / function call frequency.

[0110] The version hash of each node is compared with the original software version hash to obtain the version hash deviation value. The version hash comparison involves comparing the character differences between the distributed version hash and the original version hash bit by bit, counting the number of inconsistent characters, and then combining this with the total hash value length to calculate the degree of deviation. For example, if the original version hash is 64 bits long, and a node's distributed version hash differs from the original version hash by 8 characters, the version hash deviation value = number of inconsistent characters / total hash value length = 8 / 64 = 0.125. This value ranges from 0 to 1; a larger value indicates a more severe degree of software data tampering or corruption, and a worse version consistency.

[0111] The software runtime anomalies and version hash deviations are normalized and weighted to obtain a version anomaly coefficient. Normalization maps both anomalies to a range of 0 to 1, eliminating the influence of different metrics. For example, the runtime anomaly is scaled to its maximum value: Normalized runtime anomaly = Current runtime anomaly / Maximum value of all node runtime anomalies. Similarly, the normalized version hash deviation is obtained. Weighting assigns weights to the two metrics based on business needs. For example, the runtime anomaly weight is set to 0.6, and the version hash deviation weight is set to 0.4, with a sum of weights of 1. The version anomaly coefficient = Normalized runtime anomaly × 0.6 + Normalized version hash deviation × 0.4. This coefficient ranges from 0 to 1; a higher value indicates a more severe software version anomaly, requiring priority for updates, providing a quantitative basis for formulating subsequent differentiated update strategies.

[0112] The node synchronization deviation value of the distributed software is obtained based on the software synchronization verification data of the distributed software in each authorized node, specifically including the following steps:

[0113] Software synchronization verification data includes node running status synchronization logs;

[0114] Based on the master node of the software distribution authorization node chain, the software version synchronization time difference and data interaction hash matching degree between each child node and the master node are obtained;

[0115] The number of synchronization anomalies is obtained by extracting anomalies from the node's running status synchronization log.

[0116] The node synchronization deviation value is obtained based on the software version synchronization time difference, data interaction hash matching degree, and the number of status synchronization anomalies.

[0117] The node operation status synchronization log fully records the interaction process between each authorized node and the master node, including the version synchronization initiation time, data interaction content, status verification results, and synchronization failure reasons, which can comprehensively reflect the actual situation of collaborative operation between nodes.

[0118] Based on the master node of the software distribution authorization node chain, the software version synchronization time difference and data interaction hash matching degree between each child node and the master node are obtained. The software version synchronization time difference refers to the difference between the time when a child node initiates a version synchronization request and the time when the master node completes the version update and broadcasts it. It is used to measure the timeliness of version updates between nodes; a larger time difference indicates a more severe version synchronization lag. The data interaction hash matching degree refers to the consistency ratio of hash values ​​of data exchanged between the child node and the master node. It is obtained by comparing the hash values ​​of data received by the child node with the hash values ​​of data sent by the master node, and calculating the proportion of matching characters to the total number of characters. A higher matching degree indicates better data transmission integrity. The data interaction hash matching degree = number of matching characters / total number of characters, with a value range of 0 to 1.

[0119] The anomaly count is obtained by extracting anomalies from the node's runtime status synchronization log. Anomaly extraction involves traversing each record in the synchronization log, identifying anomalies such as synchronization failures, data verification errors, and connection interruptions, and counting the number of anomalies occurring within a specified time window. For example, if a child node experiences 3 synchronization failures and 2 data verification errors within a 24-hour time window, the state synchronization anomaly count is 5. This value directly reflects the stability of the node synchronization process; a higher anomaly count indicates a higher risk in node collaborative operation.

[0120] The node synchronization deviation value is calculated by combining the software version synchronization time difference, data interaction hash matching degree, and the number of state synchronization anomalies. Before calculation, each indicator needs to be normalized to eliminate differences in units: for example, the weight of normalized time difference is set to 0.4, the weight of normalized matching deviation is set to 0.3, and the weight of normalized anomaly count is set to 0.3. The node synchronization deviation value = normalized time difference × 0.4 + normalized matching deviation × 0.3 + normalized anomaly count × 0.3, with a value range of 0 to 1. The higher the deviation value, the worse the synchronization status between the node and the master node, and the more prominent the data coordination problem between nodes.

[0121] Based on the version anomaly coefficient and node synchronization deviation value, a differentiated software update strategy is generated for each authorized node, specifically including the following steps:

[0122] The version anomaly coefficient of each authorized node is compared level by level to obtain the degree of version loss of the node software.

[0123] Determine the data collaboration status between nodes based on the node synchronization deviation value;

[0124] The degree of version degradation is linked to the data collaboration status at each level to locate the software block range corresponding to the anomaly of each node;

[0125] The urgency of updates is determined based on the degree of node version degradation, the update transmission method is determined based on the data collaboration status, and the update content adapted to a single node is determined based on the software block range.

[0126] The update urgency, update transmission method, and update content are combined to form a differentiated software update strategy for each authorized node.

[0127] The version anomaly coefficient of each authorized node is compared level by level to determine the degree of version degradation of the node software. The version anomaly coefficient is a quantitative indicator measuring the degree of software version anomaly, ranging from 0 to 1. During the level-by-level comparison, the version anomaly coefficients of all authorized nodes within the same domain are sorted, and the degree of version degradation is quantified based on the difference between the node's own anomaly coefficient and the domain's average anomaly coefficient. Version degradation degree = Current node version anomaly coefficient - Domain average version anomaly coefficient. If the result is positive and the larger the value, the higher the degree of version anomaly of the node compared to the domain average, indicating more severe version degradation. If the result is negative, the node's version status is better than the average, indicating less version degradation. For example, if a node's version anomaly coefficient is 0.8 and the domain average coefficient is 0.4, then the version degradation degree is 0.4, indicating significant version degradation at this node, requiring close monitoring.

[0128] The data collaboration status between nodes is determined based on the node synchronization deviation value. The node synchronization deviation value is a quantitative indicator measuring the consistency of collaboration between a node and its master node, ranging from 0 to 1. A lower deviation value indicates more timely data synchronization, higher data integrity, and a more stable collaboration status; a higher deviation value indicates lagging node synchronization, abnormally frequent data interactions, and a poorer collaboration status. Synchronization deviation values ​​are divided into multiple levels, for example, 0 to 0.3 represents a stable collaboration status, 0.3 to 0.7 represents a fluctuating collaboration status, and 0.7 to 1 represents an abnormal collaboration status, thus intuitively reflecting the level of data collaboration between nodes.

[0129] The method hierarchically binds the degree of version degradation to the data collaboration status to pinpoint the range of software blocks corresponding to anomalies at each node. The binding process centers on the degree of node version degradation, combining it with the data collaboration status to trace the source of the anomaly. If a node has severe version degradation and an abnormal collaboration status, the difference between the distributed version hash and the original version hash is further compared to locate the specific inconsistent software blocks. If a node has minor version degradation but fluctuating collaboration status, the focus is on the data blocks that experienced anomalies during synchronization. This hierarchical binding method locks down the smallest range of software blocks causing node anomalies, avoiding indiscriminate updates to the entire software and improving update efficiency.

[0130] The urgency of updates is determined based on the degree of node version degradation, the update transmission method is determined based on the data collaboration status, and the update content adapted to a single node is determined based on the software block range. The urgency level is determined by setting thresholds based on version degradation; for example, a version degradation level ≥ 0.3 is considered highly urgent, 0.1 to 0.3 is moderately urgent, and < 0.1 is low-urgent. The update transmission method is selected in conjunction with the data collaboration status: incremental transmission is used in a stable collaboration state, breakpoint resumption is used in a fluctuating collaboration state, and full retransmission is used in an abnormal collaboration state. The update content is determined based on the located software block range, generating only update packages containing abnormal blocks to ensure that the update content only adapts to the actual abnormal situation of the current node.

[0131] By integrating the urgency of updates, the transmission method, and the content of the updates, a differentiated software update strategy is formed for each authorized node. For example, for nodes with high version degradation and abnormal collaboration status, a highly urgent update strategy is adopted, involving full retransmission and overwriting of abnormal blocks; for nodes with low version degradation and stable collaboration status, a low-urgency update strategy is adopted, involving incremental transmission and updating only necessary blocks. Each node's update strategy is unique and targeted, ensuring the timeliness and completeness of updates for high-risk nodes while avoiding unnecessary updates for low-risk nodes, thus achieving precise and efficient software updates.

[0132] After performing hash calculations and chain concatenation during the software update process, update traceability information is generated, which specifically includes the following steps:

[0133] During the software update process, an update operation is performed, and a hash operation is performed on the software data corresponding to the update operation to obtain the hash verification result of the update operation.

[0134] The hash verification results generated by the previous update operation are chained together with the hash verification results generated by the current update operation to form a continuous hash verification chain.

[0135] Based on the hash verification link, update node information, update time sequence information, and update content information are integrated to generate update traceability information.

[0136] During software update execution, update operations are performed, and the corresponding software data is hashed to obtain a hash verification result. Update operations encompass specific actions such as software block replacement, configuration modification, and feature patch loading. Each update operation corresponds to changes in one or more pieces of software data. The hash calculation uses a preset encrypted hash algorithm to process the changed software data, thereby generating a unique hash verification result. The hash verification result corresponds one-to-one with the content of the update operation. If any tampering occurs with the updated software data, the corresponding hash verification result will change, thus achieving integrity verification of the update content. For example, after patching a software block, a hash calculation is performed on the new data of that block to obtain a hash value H. update1 This value is the hash verification result of this update operation.

[0137] The hash verification results generated by previous update operations are chained together with the hash verification results generated by the current update operation to form a continuous hash verification chain. The chaining involves using the hash verification result of the previous update as the input to the current update hash operation. The current hash verification result = hash algorithm(previous hash verification result + current update software data), where the plus sign represents data concatenation. For example, the hash value H obtained from the first update... update1 The second update will include H. update1 After concatenating the data with the second updated software data, a hash operation is performed to obtain H. update2 The third update will include H. update2 After concatenating the data with the third updated software data, the result is H. update3 This process continues in a chain-like structure. This association method ensures that the hash verification result of any update operation depends on the results of all previous updates. If the update data in any link is tampered with, all subsequent hash verification results will become invalid, thus guaranteeing the immutability and traceability of the update chain.

[0138] The update traceability information is generated by integrating update node information, update timing information, and update content information based on the hash verification link. Update node information records the authorized node address and identity of the node performing the update operation; update timing information records the initiation and completion time of each update operation; and update content information records the software block range and change details corresponding to each update. The integration process binds this information one-to-one with the hash verification link to form a complete traceability data set. For example, H... update1 Bind H to node A, update time, and block 1 change information. update2By binding the changes to node A, update time, and block 3, a complete update traceability information system is formed, containing the entire update history. This information is recorded in the blockchain network, and the legitimacy and integrity of any update operation can be verified by tracing the hash verification link, thus achieving reliable traceability of the entire software update process.

[0139] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0140] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0141] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A blockchain-based software distribution and update method, characterized by, The method includes the following steps: Obtain complete data of the software to be distributed and node identity authentication information of the blockchain network; wherein, the node identity authentication information includes node permission level, node domain and node trust rating; The complete data of the software to be distributed is processed to obtain the software block hash value; after processing the node permission level, node domain, and node trust rating, a software distribution authorization node chain is built, which specifically includes the following steps: Authorized nodes are selected based on node permission level and node trust rating; The authorized nodes are classified and clustered based on their respective domains to obtain the clustering results; Based on the clustering results and the blockchain chain structure, authorized nodes in the same field are concatenated by node address. After configuring the distribution authorization hash key for the node chain of the concatenated node address, a software distribution authorization node chain is built. The notarization result is obtained by processing the software block hash value with the node address of the software distribution authorization node chain, specifically including the following steps: Extract the hash features corresponding to the software block hash values; serialize and integrate the hash features of each software block hash value to obtain a hash feature set; Extract the node addresses of each node in the software distribution authorization node chain, and sort the node addresses hierarchically to obtain the node address sequence; The hash feature set is associated with the node address sequence, and the associated hash features and node addresses are chained together to obtain the chain binding result. Verify whether the hash characteristics of the chain binding result are consistent with the hash characteristics of the corresponding software block hash value, and verify whether the node address matches the node address in the software distribution authorization node chain to obtain the association binding information; The evidence storage result is obtained by integrating the verified associated binding information; Based on the evidence storage results, the targeted distribution of the software is completed in the software distribution authorization node chain, specifically including the following steps: Extract the software block hash value of the evidence storage result and the node address of the corresponding authorized node chain, and associate and match the software block hash value and the node address to obtain the target authorized node corresponding to each software block; The target identifier of the target authorized node is obtained by performing block encryption processing on the software blocks of the association matching; The encryption software block is determined based on the target identifier of the target authorized node, the encryption software block is sent to the authorized node chain, and the node address is verified to be consistent with the target identifier. After the verified target authorized node receives the corresponding software block, the targeted software distribution is completed. The version anomaly coefficient of the distributed software is obtained based on the real-time running data and software version traceability data of the distributed software in each authorized node, and the node synchronization deviation value of the distributed software is obtained based on the software synchronization verification data of the distributed software in each authorized node. A differentiated software update strategy is generated for each authorized node based on the version anomaly coefficient and node synchronization deviation value; Based on the software differential update strategy, the execution node performs differential software updates, and after hash calculation and chain cascading during the software update process, update traceability information is generated. 2.The blockchain-based software distribution and update method according to claim 1, characterized in that, The complete data of the software to be distributed includes the software installation package, software configuration files, software function description documents, and software digital signature. 3.The blockchain-based software distribution and update method according to claim 2, characterized in that, The complete data of the software to be distributed is processed to obtain the software block hash value, specifically including the following steps: The software installation package and software configuration files are divided into blocks to obtain several software data blocks. Each software data block is hashed to obtain the basic hash value of each data block; the software function specification document and the software digital signature are hashed to obtain the document signature hash value. The software block hash value is obtained by concatenating all the basic hash values ​​of the blocks with the document signature hash value. 4.The blockchain-based software distribution and update method according to claim 1, wherein, The version anomaly coefficient of the distributed software is obtained based on the real-time running data and software version traceability data of the distributed software in each authorized node. The specific steps include: The real-time operation data includes fault occurrence records and function call frequency; the software version traceability data includes the original software version hash and the distributed version hash of each node. The abnormal values ​​of software operation are obtained by correlating the fault occurrence records with the function call frequency; The version hash of each node is compared with the original version hash of the software to obtain the version hash deviation value; The version anomaly coefficient is obtained by normalizing and weighting the software runtime anomaly value and the version hash deviation value. 5.The blockchain-based software distribution and update method according to claim 1, wherein, The node synchronization deviation value of the distributed software is obtained based on the software synchronization verification data of the distributed software in each authorized node, specifically including the following steps: The software synchronization verification data includes node running status synchronization logs; Based on the master node of the software distribution authorization node chain, the software version synchronization time difference and data interaction hash matching degree between each child node and the master node are obtained; The number of synchronization anomalies is obtained by extracting anomalies from the node's running status synchronization log. The node synchronization deviation value is obtained based on the software version synchronization time difference, data interaction hash matching degree, and the number of status synchronization anomalies.

6. The blockchain-based software distribution and update method according to claim 1, characterized in that, Based on the version anomaly coefficient and node synchronization deviation value, a differentiated software update strategy is generated for each authorized node, specifically including the following steps: The version anomaly coefficient of each authorized node is compared level by level to obtain the degree of version loss of the node software. Determine the data collaboration status between nodes based on the node synchronization deviation value; The degree of version degradation is linked to the data collaboration status at each level to locate the software block range corresponding to the anomaly of each node; The urgency of updates is determined based on the degree of node version degradation, the update transmission method is determined based on the data collaboration status, and the update content adapted to a single node is determined based on the software block range. The update urgency, update transmission method, and update content are combined to form a differentiated software update strategy for each authorized node.

7. The blockchain-based software distribution and update method according to claim 6, characterized in that, After performing hash calculations and chain concatenation during the software update process, update traceability information is generated, which specifically includes the following steps: During the software update process, an update operation is performed, and a hash operation is performed on the software data corresponding to the update operation to obtain the hash verification result of the update operation. The hash verification results generated by the previous update operation are chained together with the hash verification results generated by the current update operation to form a continuous hash verification chain. Based on the hash verification link, update node information, update time sequence information, and update content information are integrated to generate update traceability information.

Images