Software distribution method and system based on file list difference and local area network mirror

Abstract

This invention relates to the field of software distribution technology, specifically to a software distribution method and system based on file manifest differential and local area network (LAN) mirroring. The method includes the following steps: a central server generates a latest version of the software's basic file manifest, latest version file blocks, a dynamic Merkle hash tree, and Merkle verification data; and sends the basic file manifest, the latest version file blocks, and the Merkle verification data to the LAN mirror node. In this invention, the client reconstructs the affected Merkle branches by combining the old version file blocks with the received client-specific differential packet, and verifies the reconstructed root hash using aggregated verification data. This allows for consistency constraints between the locally updated content and the latest trusted root state published by the central server during the differential merging stage, enabling tampering, transmission errors, or incorrect reuse to be identified before the final software state is formed. This balances differential distribution efficiency, LAN concurrency adaptability, and update data integrity.

Description

Technical Field

[0001] This invention relates to the field of software distribution technology, and in particular to a software distribution method and system based on file list difference and local area network mirroring. Background Technology

[0002] Software distribution technology involves the publication, transmission, updating, and synchronization of software programs, application files, configuration files, and related data between servers, network nodes, and terminal devices. Its main research contents include software version management, file list management, differential updates, file chunking, content addressing, data deduplication, cache distribution, local area network mirroring, edge node collaboration, and transmission integrity verification technologies.

[0003] In existing software distribution environments with multiple client versions, a central server continuously maintains updates for each version, or terminals directly obtain relatively complete software data. As the number of client versions, files, and update frequency increases, the central server needs to repeatedly perform version determination, difference organization, and data distribution. This easily leads to problems such as concentrated computing tasks, increased repetitive transmission volume over the wide area network (WAN), and peak-hour response queuing. For example, when hundreds of terminals in the same campus are running multiple historical versions, the central server may repeatedly prepare update content for different starting versions. Even if shareable data exists within the LAN, it may still be transmitted multiple times across the WAN. Existing LAN mirroring deployments often primarily operate by caching existing installation packages or fixed-version update packages. When client requests do not completely correspond to cached versions, the cache hit rate decreases with version fragmentation. Mirror nodes can only forward content from the central server or re-acquire the target data, making it difficult to fully leverage the advantages of LAN-based local distribution. If file difference processing mainly relies on file paths, fixed block positions, or complete file digests for judgment, minor insertions, deletions, and position migrations in the file may cause a large amount of subsequent data to be judged as changed content, leading to an increase in the size of the difference packet. Therefore, improvements are needed. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of existing technologies and to propose a software distribution method and system based on file list difference and local area network mirroring.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a software distribution method based on file list differential and local area network mirroring, comprising the following steps:

[0006] The central server generates the latest version of the software basic file list, the latest version of the file block, the dynamic Merkle hash tree, and the Merkle verification data, and sends the basic file list, the latest version of the file block, and the Merkle verification data to the local area network mirror node;

[0007] The local area network mirror node receives a list of local file characteristics from the client and determines the client version status based on a directed acyclic graph of historical version status.

[0008] The local area network mirror node uses a Rabin fingerprint sliding window and two-level fingerprint matching to determine the differential file block set;

[0009] The local area network mirror node generates a client-specific differential packet based on the differential file block set, performs proof path aggregation on the Merkle verification data to obtain aggregated verification data, and sends the client-specific differential packet and the aggregated verification data to the client;

[0010] The client reconstructs the Merkle branch using the old file blocks and the client-specific differential package, verifies and reconstructs the root hash based on the aggregated verification data, and merges the client-specific differential package after the verification is passed.

[0011] Preferably, the step of the central server generating a list of the latest software base files, the latest file blocks, a dynamic Merkle hash tree, and Merkle verification data, and sending the list of base files, the latest file blocks, and the Merkle verification data to the local area network mirror node specifically includes:

[0012] The central server traverses the latest version of the software, obtains the file path, file length and software version identifier, splits each file according to the preset file block length to obtain the latest version file block, and records the software version identifier, the file path, the file length and the block offset in the basic file list;

[0013] The central server divides the latest version file block into micro-blocks according to the preset micro-block length, calculates the SHA-256 hash value of the micro-block, arranges them into leaf nodes according to the file path, the block offset and the division order, and calculates the hash value of the parent node layer by layer to obtain the dynamic Merkle hash tree. When the latest version of the software changes, only the node hash values ​​from the affected leaf nodes to the root node are recalculated.

[0014] The central server records the node positions and node hash values ​​of the dynamic Merkle hash tree, obtains the signature root hash information by combining the root node hash value with the software version identifier in a digest signature, assembles the Merkle verification data from the node positions, the node hash values, and the signature root hash information, and sends the basic file list, the latest version file block, and the Merkle verification data to the local area network mirror node.

[0015] Preferably, the step of the local area network mirror node receiving the client's local file feature list and determining the client's version status based on the directed acyclic graph of historical version status specifically includes:

[0016] The local area network mirror node sends the feature window length to the client. The client segments the local software into local file blocks according to the feature window length, generates the local file feature list, and records the software version identifier, file path, block offset, Rabin fingerprint, and SHA-256 digest of the local file block. The local file feature list is then sent to the local area network mirror node.

[0017] The local area network mirror node establishes the cached software version and the client's historical version as version vertices in the directed acyclic graph of the historical version status, establishes the direct update relationship as directed edges, records the software version identifier in the version vertex, and records the set of changed file paths in the directed edge.

[0018] The local area network mirror node determines the latest version vertex corresponding to the latest version of the software, queries the corresponding version vertex according to the software version identifier in the local file feature list, and determines the queried version vertex as the client version status.

[0019] Preferably, the step of the local area network mirror node determining the differential file block set using the Rabin fingerprint sliding window and two-level fingerprint matching specifically includes:

[0020] The local area network mirror node retrieves the update path from the client version status to the latest version vertex, merges the set of changed file paths recorded by each directed edge in the update path, and obtains the set of file paths to be compared.

[0021] For file paths in the set of file paths to be compared that exist simultaneously in the local file feature list and the basic file list, the local area network mirror node establishes a first-level fingerprint index based on the Rabin fingerprint of the corresponding local file block, slides the file data corresponding to the latest version of the software according to the feature window length, and recursively calculates the Rabin fingerprint. The recursive formula is: ,in , These are the fingerprint remainders after right shift and before right shift, respectively. , The binary field polynomials for the shifted-out byte and the shifted-in byte, respectively. For formal variables, The number of bytes in the window. For the pre-defined irreducible polynomial, Addition for a binary field;

[0022] The local area network mirror node queries the first-level fingerprint index. Upon a match, it calculates the SHA-256 digest of the current window and performs a second-level verification with the SHA-256 digest of the matched local file block. If the verification matches, it records the source offset and target offset to form a reuse mapping and moves the window forward by the feature window length. Otherwise, it moves the window forward by 1 byte, records consecutive unmatched data as differential data segments to be transmitted, merges all data of the base file clearing the file into the differential data segment to be transmitted, and records the local file feature clearing the file as a deleted file record. The differential file block set is generated based on the reuse mapping, the differential data segment to be transmitted, and the deleted file record.

[0023] Preferably, the step of the local area network mirror node generating a client-specific differential packet based on the differential file block set, performing proof path aggregation on the Merkle verification data to obtain aggregated verification data, and sending the client-specific differential packet and the aggregated verification data to the client specifically includes:

[0024] The local area network mirror node parses the differential file block set to obtain multiplexing operation items, transmission operation items, and deletion operation items. The multiplexing operation item records the source position and the target position. The transmission operation item records the target position and differential data. The source position includes the source file path and the source offset. The target position includes the target file path and the target offset. The deletion operation item records the deleted file path. Each of the operation items and the target file length read from the basic file list are written into the memory buffer to obtain the client-specific differential packet.

[0025] The local area network mirror node determines the set of leaf nodes to be verified based on the transmission operation item and the target position of the multiplexing operation item where the source offset and target offset are inconsistent. It extracts the proof path from the leaf node to be verified to the root node from the Merkle verification data, removes internal nodes that can be reconstructed from the leaf node to be verified, and deduplicates the proof nodes with the same node position to obtain the set of shared proof nodes.

[0026] The local area network mirror node records the node position of the leaf node to be verified, the node position of the shared proof node, and the reconstruction order. It reads the signature root hash information from the Merkle verification data, combines the node position of the leaf node to be verified, the shared proof node set, the node position of the shared proof node, the reconstruction order, and the signature root hash information to form the aggregated verification data, and sends the client-specific differential packet and the aggregated verification data to the client.

[0027] Preferably, the steps of the client reconstructing the Merkle branch using the old file blocks and the client-specific differential package, verifying and reconstructing the root hash according to the aggregated verification data, and merging the client-specific differential package after the verification is passed are as follows:

[0028] The client reads the signature root hash information, the node position of the leaf node to be verified, the shared proof node set, the node position of the shared proof node, and the reconstruction order from the aggregated verification data. It uses a preset public key to verify the digital signature in the signature root hash information. After the verification is successful, the root node hash value in the signature root hash information is determined as the target root hash.

[0029] The client parses the client-specific differential packet, reads source location data from the old file block according to the reuse operation item, obtains differential data according to the transmission operation item, combines target data according to the node position of the leaf node to be verified and the target offset, calculates the SHA-256 hash value of the target data to obtain the leaf node hash value, and calculates the reconstruction root hash layer by layer according to the shared proof node set and the reconstruction order.

[0030] The client compares the reconstructed root hash and the target root hash. If they match, the client writes the corresponding data to the position corresponding to the target offset in the target file path according to the reuse operation item and the transmission operation item. The client then truncates the file according to the target file length and executes the deletion operation item to complete the merging of the client-specific differential packet.

[0031] The present invention also provides a system comprising:

[0032] Basic data generation and mirror synchronization module: The central server generates the latest version of the software basic file list, the latest version of the file block, the dynamic Merkle hash tree and the Merkle verification data, and sends the basic file list, the latest version of the file block and the Merkle verification data to the local area network mirror node;

[0033] Version status identification module: The local area network mirror node receives a list of local file features from the client and determines the client version status based on a directed acyclic graph of historical version status;

[0034] Differential file block determination module: The local area network mirror node uses Rabin fingerprint sliding window and two-level fingerprint matching to determine the differential file block set;

[0035] Differential packet generation and verification data aggregation module: The local area network mirror node generates a client-specific differential packet based on the differential file block set, performs proof path aggregation on the Merkle verification data to obtain aggregated verification data, and sends the client-specific differential packet and the aggregated verification data to the client;

[0036] Reconstruction verification and differential merging module: The client reconstructs the Merkle branch using the old file block and the client-specific differential package, verifies and reconstructs the root hash according to the aggregated verification data, and merges the client-specific differential package after the verification is passed.

[0037] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0038] In this invention, a central server generates a unified list of basic files, the latest version of file blocks, a dynamic Merkle hash tree, and Merkle verification data around the latest software version. Then, local area network (LAN) mirror nodes identify the client version status based on the client's local file feature list and a directed acyclic graph of historical version states. This allows the central server to focus on building the target version and releasing a trusted benchmark, while the mirror nodes perform differential calculations based on the actual client versions within the LAN. This reduces the burden on the central server to repeatedly organize differential data calculations and transmissions for a large number of fragmented client versions, and shortens the round-trip path of updated data in the wide area network. Using a Rabin fingerprint sliding window for rolling feature matching of file content, and further confirming candidate data through two-level fingerprint matching, reusable data segments can be identified even when file content is inserted, deleted, or shifted. This reduces the probability of large-scale repeated transmissions caused by relying solely on fixed-position comparisons, making the differential file block set closer to the client's actual missing content. Based on the differential file block set, a client-specific differential package is formed on the local area network mirror node side. This allows for the organization of reused and newly added content as needed for different version states, improving data utilization efficiency when multiple versions of clients update in parallel within the same local area network. Proof path aggregation is performed around the Merkle verification data corresponding to the differential content, merging duplicate proof nodes between multiple affected branches and reducing the scale of verification information accompanying the differential data. Simultaneously, the client reconstructs the affected Merkle branches by combining the old file blocks and the received client-specific differential package, and verifies the reconstructed root hash using the aggregated verification data. This allows for the establishment of consistency constraints between the local update content and the latest trusted root state published by the central server during the differential merging phase, ensuring that tampering, transmission errors, or incorrect reuse can be identified before the final software state is formed. This balances differential distribution efficiency, local area network concurrency adaptability, and update data integrity. Attached Figure Description

[0039] Figure 1 This is a schematic diagram of the steps of the present invention. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0041] This implementation provides a software distribution method based on file manifest differential and LAN mirroring, applicable to software update scenarios in enterprise parks, school computer rooms, data centers, production networks, and other LANs with multiple clients and differing client software versions. During implementation, the central server is responsible for storing the latest software version and its corresponding trusted verification benchmark. LAN mirror nodes are deployed in LANs close to the client networks, responsible for storing the latest software files and calculating differential data based on the actual version status of different clients. Clients store their currently used older software version and update to the latest version through the LAN mirror nodes. Data exchange between the central server, LAN mirror nodes, and clients can be conducted using TCP connections, HTTPS connections, or other reliable LAN transmission protocols. This embodiment uses HTTPS connections for illustration.

[0042] Please see Figure 1 This invention provides a technical solution for a software distribution method based on file manifest difference and local area network mirroring, comprising the following steps:

[0043] In this embodiment, the central server stores the complete software data corresponding to software version V4.0, and the local area network mirror node stores the latest version software data synchronized by the central server and the corresponding verification data. The currently installed version of the client can be V3.0, V3.1 or V3.5. The update data is organized by the differences in file content between the current version of the client and V4.0, so that different historical version clients do not need to have fixed differential packages pre-made by the central server.

[0044] The central server generates the latest version of the software basic file list, the latest version of the file block, the dynamic Merkle hash tree, and the Merkle verification data, and sends the basic file list, the latest version of the file block, and the Merkle verification data to the local area network mirror node;

[0045] In this embodiment, after the latest version of the software is built and enters the release state, the central server performs a normalized traversal on all ordinary files in the latest version software directory, unifying the path separator to forward slashes, arranging the file paths according to the byte order after UTF-8 encoding, and forming the latest version file blocks according to the same file splitting rules. The central server simultaneously establishes a basic file list describing the file path, file length, and file block position relationship, and at the same time, it establishes a dynamic Merkle hash tree for the file content. After completing the above processing, the central server synchronizes the latest version file blocks and the Merkle verification data used to verify the latest version software content to the local area network mirror node, so that the local area network mirror node has the latest version data and reliable verification basis needed to independently calculate the client's differential content.

[0046] The local area network mirror node receives a list of local file characteristics from the client and determines the client's version status based on a directed acyclic graph of historical version status.

[0047] In this embodiment, when the client initiates a software update request, it does not upload all the file data of the local software. Instead, it generates local file block features according to the feature window length sent by the local area network mirror node, and organizes the software version identifier, file path, block offset, Rabin fingerprint, and SHA-256 digest into a local file feature list for uploading. The local area network mirror node locates the version vertex of the client in the directed acyclic graph of historical version states based on the software version identifier, thereby establishing a definite version evolution relationship between the client's current state and the version vertex corresponding to the latest version of the software.

[0048] Local area network mirror nodes use Rabin fingerprint sliding windows and two-level fingerprint matching to determine the differential file block set;

[0049] In this embodiment, the local area network mirror node does not directly perform a byte-by-byte full comparison of all local data on the client and all data in the latest version of the software. Instead, it first uses a directed acyclic graph of historical version states to filter file paths that may have changed, and then builds a local file block Rabin fingerprint index for the corresponding file. Candidate data is located by Rabin fingerprint, and strong consistency is confirmed by SHA-256 digest. This ensures that even if data is inserted, deleted, or moved within the file, the data range that can be directly reused in the old version of the client software can still be identified.

[0050] The local area network mirror node generates a client-specific differential packet based on the differential file block set, performs proof path aggregation on the Merkle verification data to obtain aggregated verification data, and sends the client-specific differential packet and aggregated verification data to the client.

[0051] In this embodiment, the client-specific differential packet does not require saving a completely rearranged target file. Instead, it uses reuse, transmission, and deletion operations to describe the data changes required for the client to restore from the old version to the latest version. The local area network mirror node further extracts the corresponding Merkle proof node based on the actual data location involved in the update, performs deduplication on nodes that appear repeatedly in multiple Merkle proof paths, and sends the deduplicated shared proof node and the corresponding reconstruction relationship to the client, thereby avoiding each updated microblock from carrying an independent complete Merkle proof path.

[0052] The client reconstructs the Merkle branch using the old file blocks and client-specific differential packages, verifies the reconstructed root hash based on the aggregated verification data, and merges the client-specific differential packages after the verification passes.

[0053] In this embodiment, the client first verifies the digital signature generated by the central server for the root node hash value of the latest version of the software. After confirming that the root node hash value is trustworthy, it reads the data specified by the reuse operation in the old version file and the differential data transmitted by the mirror node. It then assembles the target data affected by the update in the latest version of the software according to the target position, calculates the corresponding leaf node hash, and restores the root node hash layer by layer in combination with the shared proof node. The update result is submitted only when the restored root node hash is exactly the same as the root node hash protected by the central server's signature. When any differential data, reuse position, or proof node changes during transmission and caching, the restoration result cannot be consistent with the target root hash, and the client terminates the update and retains the old version of the software.

[0054] The central server generates the latest version of the software's basic file list, the latest version of the file blocks, a dynamic Merkle hash tree, and Merkle verification data. The specific steps for sending the basic file list, the latest version of the file blocks, and the Merkle verification data to the local area network mirror nodes are as follows:

[0055] In this embodiment, the central server performs a basic file list and Merkle verification data construction once for each officially released software version, and binds the generated results with the software version identifier to avoid the mixing of file blocks and verification data corresponding to different software versions.

[0056] The central server iterates through the latest version of the software, obtains the file path, file length and software version identifier, splits each file according to the preset file block length to obtain the latest version file block, and records the software version identifier, file path, file length and block offset in the basic file list;

[0057] In this embodiment, the preset file block length is fixed at 65536 bytes. The central server performs segmentation based on individual files. When a file's length exceeds 65536 bytes, file blocks are generated consecutively in 65536-byte increments. When the last file block's length is less than 65536 bytes, it is saved according to the remaining actual bytes of the file, without adding padding bytes to the file content. For a file with a length of 150,000 bytes, three latest version file blocks are formed sequentially with offsets of 0, 65536, and 131072, with actual lengths of 65536 bytes, 65536 bytes, and 18928 bytes, respectively. For an empty file with a length of 0 bytes, the corresponding file path and 0-byte file length are retained in the basic file list, but no latest version file block containing actual data is generated. In addition to the software version identifier, file path, file length, and block offset as defined in the claims, the basic file list also records the actual length of each file block and its SHA-256 digest, serving as auxiliary information for data indexing and transmission integrity checks by the mirror node.

[0058] Table 1 Implementation Parameter Setting Results

[0059] project This embodiment is set Setup method Preset file block length 65536 bytes The software release configuration is a fixed setting that does not change during a single update session. Preset microblock length 4096 bytes The software release configuration is a fixed setting that requires the file block length to be divisible by the preset file block length. Feature window length 65536 bytes Set to the same as the preset file block length Rabin fingerprint width 64-bit Modular reduction using an irreducible polynomial of degree 64 Rabin Modular Polynomial The central server, LAN mirror nodes, and clients all have the same parameters. Strong content validation SHA-256 The checksum is determined to be consistent when each bit of the 256-bit digest is exactly the same. Digital signature Ed25519 The central server stores the signing private key, and the client has the corresponding public key pre-installed. Single client memory buffer limit 16MiB The 512MiB differential session memory budget is determined by dividing by the maximum 32 concurrent clients. Maximum data limit for a single physical shard 16MiB Data operations exceeding the limit are split continuously according to the target offset.

[0060] As shown in Table 1, this embodiment sets the file block length and feature window length to the same value, allowing the client-side fixed block fingerprint to be directly used as the index value for sliding matching of mirror nodes. Simultaneously, it uses smaller micro-block lengths to establish Merkle leaf nodes, making the differential matching granularity and integrity verification granularity independent of each other. When the 65536-byte file block is further divided into 4096-byte micro-blocks, one complete file block corresponds to 16 complete micro-blocks. These values, as the determined implementation parameters of this embodiment, remain unchanged within the same software release version and the same differential calculation protocol version, and are not dynamically adjusted during a single software update.

[0061] The central server divides the latest version of the file into micro-blocks according to the preset micro-block length, calculates the SHA-256 hash value of the micro-blocks, and arranges them into leaf nodes according to the file path, block offset and division order. The hash value of the parent node is calculated layer by layer to obtain a dynamic Merkle hash tree. When the latest version of the software changes, only the node hash values ​​from the affected leaf nodes to the root node are recalculated.

[0062] In this embodiment, the preset micro-block length is fixed at 4096 bytes. When the last micro-block in the latest version file block is less than 4096 bytes, the SHA-256 hash value is calculated based on the actual remaining data, without zero padding. Each file path is arranged in UTF-8 encoded byte order. The latest version file blocks within the same path are arranged in ascending order of block offset. Micro-blocks within the same latest version file block are arranged in ascending order of their segmentation order, thus determining the positions of all leaf nodes. Let the... Layer The hash value of each parent node is The hash values ​​of the corresponding left and right child nodes are respectively and The expression for calculating the parent node is: ,in This indicates the level of the Merkle tree, with the level of the leaf node set to 0. This indicates the node index in the current layer. This represents the hash value of the current parent node. This represents the hash value of the left child node corresponding to the current parent node. This represents the hash value of the right child node corresponding to the current parent node. This indicates that the byte strings are concatenated in the order of left node first, right node last. This represents a SHA-256 hash operation. When the total number of nodes in a certain layer is odd, the hash of the last node in that layer is copied once and used as the corresponding right child node to participate in the parent node calculation, ensuring that the central server and the client use completely consistent tree construction rules.

[0063] When the latest software undergoes a partial update and the number of leaf nodes remains the same as the original version, the central server determines the micro-blocks whose content has changed based on the changed file paths and offsets, and only recalculates the corresponding leaf nodes and their ancestor nodes from the leaf nodes to the root node. When adding, deleting, or changing file lengths causes changes in the total number of leaf nodes or the positions of subsequent leaf nodes, the micro-blocks whose content has changed, as well as those whose node positions have changed due to altered arrangement, are uniformly identified as affected leaf nodes. The affected leaf nodes and their corresponding ancestor nodes are then recalculated, ensuring that the recalculation of node hash values ​​from the affected leaf nodes to the root node has a defined scope.

[0064] The central server records the node positions and node hash values ​​of the dynamic Merkle hash tree. It obtains the signature root hash information by signing the digest of the root node hash value and the software version identifier. The node positions, node hash values, and signature root hash information are combined to form Merkle verification data. The basic file list, the latest version file block, and the Merkle verification data are then sent to the local area network mirror node.

[0065] In this embodiment, each node position is represented by both the layer number and the node sequence number within the layer. For example, node position 3-15 represents the 15th node in layer 3. To avoid inconsistencies in signature input caused by different character encoding methods for the software version identifier, the central server converts the software version identifier into a UTF-8 byte string and writes a 2-byte unsigned length field before the byte string. The 2-byte unsigned length field adopts network byte order to obtain the version code. The central server calculates the signature input digest. ,in This represents the summary of the combination to be signed. This represents the deterministic encoding result of the software version identifier. Indicates the software version identifier. This represents the hash value of the root node of a dynamic Merkle hash tree. Indicates sequential concatenation of byte strings. This indicates a SHA-256 hash operation.

[0066] The central server uses the Ed25519 private key to sign the combined digest and writes the software version identifier, root node hash value, signature value, signature algorithm identifier, and public key identifier into the signature root hash information. In this embodiment, the Ed25519 private key seed length is set to 32 bytes, generated once by the cryptographically secure random number generator provided by the operating system during software distribution system initialization. A 32-byte public key is generated based on the private key seed, and the signature result length is 64 bytes. The central server's private key is stored only in a protected central-side key storage area. Local area network mirror nodes do not hold the signing private key, and the client has the corresponding public key of the central server pre-installed. Therefore, local area network mirror nodes cannot regenerate a signature that can be verified by the client for the replaced software content.

[0067] The steps for the local area network mirror node to receive the client's local file feature list and determine the client's version status based on the directed acyclic graph of historical version status are as follows:

[0068] In this embodiment, the local area network mirror node maintains a directed acyclic graph of the historical version status for each software product. Directed edges are not established between version vertices of different software products to avoid invalid update paths between different product versions.

[0069] The local area network mirror node sends the feature window length to the client. The client segments the local software according to the feature window length to obtain local file blocks, generates a local file feature list, records the software version identifier, file path, block offset of the local file block, Rabin fingerprint and SHA-256 digest, and sends it to the local area network mirror node.

[0070] In this embodiment, the local area network mirror node reads 65536 bytes from the basic parameters associated with the latest software version as the feature window length and sends it to the client. The client independently performs file splitting on each file in the current software directory, and data that is less than the feature window length at the end is still treated as a local file block. Rabin fingerprints are used to quickly filter candidate blocks, and SHA-256 digests are used to confirm that the candidate block data is completely consistent. The client only reads local files during the generation of the feature list and does not change the content of the local files. For files that do not have read permissions or fail to be read, the corresponding file path is marked as unreusable, so that the file is processed according to the data that needs to be retransmitted in subsequent differential calculations, avoiding the use of incomplete features in the matching.

[0071] The local area network mirror node establishes the cached software version and the client's historical version as version vertices in a directed acyclic graph of historical version status, and establishes direct update relationships as directed edges. The software version identifier is recorded at the version vertex, and the set of changed file paths is recorded at the directed edge.

[0072] In this embodiment, each version vertex corresponds to a specific software version identifier, such as V3.0, V3.1, V3.5, and V4.0. Directed edges are only established between two versions that the central server confirms have a direct release evolution relationship, such as V3.0 to V3.1, V3.1 to V3.5, and V3.5 to V4.0. The set of changed file paths is obtained by comparing the basic file lists of the two corresponding versions. File paths are recorded for newly added files, deleted files, and files with different lengths or SHA-256 digests. The directed acyclic graph of historical version states establishes directed edges according to the version release time from earliest to latest, without establishing back edges from newer versions to older versions, thus ensuring that there are no directed cycles. When a new version arrives at the local area network mirror node, only the corresponding version vertex and direct update edges are appended; it is not necessary to re-establish all historical version vertices.

[0073] The local area network mirror node determines the latest version vertex corresponding to the latest version of the software, queries the corresponding version vertex based on the software version identifier in the local file feature list, and determines the client version status based on the queried version vertex.

[0074] In this embodiment, the local area network mirror node uses a composite key composed of the software product identifier and the software version identifier to query the version vertex. When the query result is unique, the client version status is directly determined. When the software version identifier submitted by the client corresponds to a historical release version, but the corresponding version vertex does not yet exist in the local directed acyclic graph of historical version status, the local area network mirror node constructs the corresponding version vertex based on the saved historical version metadata before performing the query. When the software version identifier cannot be identified and there is no reliable historical version metadata, all file paths appearing in the local file feature list and the basic file list are merged and deduplicated, and directly used as the set of file paths to be compared. This avoids narrowing the file range through the directed acyclic graph of historical version status, allowing clients with unknown versions to still enter the subsequent two-level fingerprint matching process.

[0075] The specific steps for a local area network mirror node to determine the differential file block set using a Rabin fingerprint sliding window and two-level fingerprint matching are as follows:

[0076] In this embodiment, the directed acyclic graph of historical version states is only used to limit the priority comparison range. The actual determination of whether a piece of data can be reused is still constrained by both the Rabin fingerprint and the SHA-256 digest. Therefore, the historical metadata in the directed acyclic graph of historical version states only affects the comparison range and does not directly determine whether a piece of data is determined to be reused data.

[0077] The local area network mirror node retrieves the update path from the client version status to the latest version vertex, merges the set of changed file paths recorded by each directed edge in the update path, and obtains the set of file paths to be compared.

[0078] In this embodiment, when a directed path exists from the client version state to the latest version vertex, the directed path is directly used. When multiple directed paths exist, an update path is selected according to a defined three-level rule. The first priority is to select the update path with the fewest directed edges. The second priority, when the number of directed edges is the same, is to select the update path with the fewest duplicate changed file paths recorded by each directed edge. The third priority, when the first two are still the same, is to connect the software version identifiers contained in each candidate update path according to the path direction to form a version sequence string, and select the update path corresponding to the version sequence string with the smallest UTF-8 byte order. This ensures that a unique update path is always obtained for the same input state. When no reachable directed path exists from the client version state to the latest version vertex, all file paths contained in the local file feature list and the basic file list are merged and deduplicated to directly obtain the set of file paths to be compared.

[0079] For example, the selected update paths from V3.0 to V4.0 contain three directed edges, each recording 20, 35, and 18 changed file paths respectively. Among them, 12 file paths appear repeatedly. After merging and deduplication, 61 file paths are actually obtained to be compared, without needing to rescan other unchanged file paths.

[0080] For file paths in the set of file paths to be compared that exist simultaneously in both the local file feature list and the basic file list, the local network mirror node establishes a first-level fingerprint index based on the Rabin fingerprint of the corresponding local file block. It then slides the corresponding file data of the latest software version according to the feature window length and recursively calculates the Rabin fingerprint using the following recursive formula: ,in , These are the fingerprint remainders after right shift and before right shift, respectively. , The binary field polynomials for the shifted-out byte and the shifted-in byte, respectively. For formal variables, The number of bytes in the window. For the pre-defined irreducible polynomial, Addition for a binary field;

[0081] In this embodiment, all Rabin fingerprint operations are performed on the binary field GF(2), and ordinary addition and subtraction are implemented using bitwise XOR. A byte is interpreted as an 8-bit unsigned integer, with bits 0 to 7 corresponding to the binary field polynomials. to The coefficient, the least significant bit corresponds to The bytes in the window are arranged from front to back according to the file reading direction, with the first byte of the window located at the position of the highest read count.

[0082] In this embodiment, the preset irreducible polynomial is fixed as... The degree of the polynomial is 64. Therefore, the degree of the Rabin fingerprint remainder obtained by performing modular reduction on any window polynomial is less than 64, and it is stored as a 64-bit unsigned integer, where the 0th bit of the integer represents... The coefficient, represented by the 63rd bit of the integer. The coefficients. The central server, LAN mirror nodes, and clients all use the same differential calculation protocol version. Different polynomials are not randomly generated among clients.

[0083] The feature window length is 65536 bytes, therefore the recursive formula... The value is fixed at 65536. For a complete feature window, the initial Rabin fingerprint is calculated starting from the first byte of the window. The current remainder is initially set to 0. For each byte in the window, the current remainder is shifted left by 8 bits, XORed with the binary field polynomial corresponding to the current byte, and then... Performing polynomial modulo reduction and processing 65536 bytes, the remainder is used as the Rabin fingerprint of the first window. This determines that the first window and the recursive window use the exact same byte ordering rules.

[0084] In the recursive formula, The value is the binary field polynomial corresponding to the first byte that the current window moves out. The value is the binary field polynomial corresponding to the byte newly entering the window. The LAN mirror node pre-calculates for 256 possible outgoing bytes, ranging from 0 to 255. This forms a shift-out table containing 256 64-bit remainder expressions. Each time the window is shifted right by 1 byte, the corresponding reduction result is obtained by directly looking up the table based on the shift-out byte. Then, XOR, left shift by 8 bits, adding the shift-in byte, and modulo reduction are performed to obtain a new Rabin fingerprint.

[0085] The local area network mirror node queries the first-level fingerprint index. If a match is found, the SHA-256 digest of the current window is calculated and compared with the SHA-256 digest of the matched local file block for second-level verification. If the verification matches, the source offset and target offset are recorded to form a multiplexing map, and the window is moved forward by the feature window length. Otherwise, the window is moved forward by 1 byte, and consecutive unmatched data is recorded as differential data segments to be transmitted. All data of the base file cleared of the separate file is merged into the differential data segment to be transmitted. The local file feature cleared of the separate file is recorded as a deleted file record. A differential file block set is generated based on the multiplexing map, the differential data segment to be transmitted, and the deleted file record.

[0086] In this embodiment, the first-level fingerprint index uses a 64-bit Rabin fingerprint value as the key and one or more local file block locations as the values. The first-level matching does not use distance thresholds, similarity thresholds, or error ranges; a first-level match is only determined when the 64-bit Rabin fingerprints are completely identical bit-by-bit. When the same Rabin fingerprint corresponds to multiple local file blocks, a second-level SHA-256 checksum is performed on all candidates. The second-level checksum also does not set a similarity threshold; the corresponding candidate is only accepted when the 256-bit SHA-256 digests are completely identical bit-by-bit.

[0087] When multiple candidate pairs with identical SHA-256 digests exist, the candidate pair located on the same file path as the target location is prioritized. Then, the candidate pair with the smaller absolute value of the difference between the source and target offsets is selected. If they are still tied, the candidate pair with the smaller source offset is chosen, thus obtaining a unique multiplexing map. Mirror nodes use the unmatched start position to record consecutive unmatched data. When a reusable window is found at a subsequent position, the data between the unmatched start position and the current window start position is formed into a differential data segment to be transmitted, and the entire 65536-byte feature window is skipped to continue scanning. If there is still less than one feature window of unmatched data at the end of the file, all remaining real bytes are treated as a differential data segment to be transmitted. This can handle situations where a small amount of data inserted in the middle of the file causes the entire subsequent content to be offset, without considering all subsequent content as newly added data due to changes in a fixed offset.

[0088] The local area network mirror node generates a client-specific differential packet based on the differential file block set, performs proof path aggregation on the Merkle verification data to obtain aggregated verification data, and sends the client-specific differential packet and aggregated verification data to the client in the following specific steps:

[0089] In this embodiment, the differential file block set represents the intermediate results of the differential analysis stage, and the client-specific differential package represents the data operation sequence that can be directly executed by the client. The two correspond to the differential identification stage and the differential execution stage, respectively, avoiding the direct use of file content comparison results as client file writing instructions.

[0090] The local area network mirror node parses the differential file block set to obtain multiplexing operation items, transmission operation items, and deletion operation items. The multiplexing operation items record the source location and the destination location, the transmission operation items record the destination location and differential data. The source location includes the source file path and the source offset, the destination location includes the destination file path and the destination offset, and the deletion operation items record the path of the deleted file. Each operation item and the length of the destination file read from the basic file list are written into the memory buffer to obtain the client-specific differential packet.

[0091] In this embodiment, each multiplexing operation item includes at least an operation type, source file path, source offset, target file path, target offset, and multiplexed data length; each transmission operation item includes at least an operation type, target file path, target offset, differential data length, and actual differential data; and each deletion operation item includes at least an operation type and the file to be deleted. The target file length is read from the basic file list according to the target file path and bound to the corresponding target file.

[0092] In this embodiment, the LAN mirror node reserves 512 MiB of memory as the total memory budget for the differential generation session, and the maximum number of clients simultaneously in the differential generation phase is fixed at 32. Therefore, the upper limit of the memory buffer for a single client is set to 16 MiB. The 16 MiB limit only accounts for the data load and operation item storage of the client-specific differential packet, excluding the network protocol stack cache. When the 16 MiB limit is reached, the corresponding client buffer is not expanded further; instead, the already formed operation item is encapsulated into the current physical fragment and sent, before continuing to generate the next physical fragment.

[0093] When the differential data carried by a single transmission operation exceeds 16 MiB, it is divided into multiple transmission operation items with 16 MiB as the maximum data length per segment, based on the target offset in ascending order. Each split transmission operation item re-records the corresponding target offset and the actual differential data length. The data length of the last transmission operation item is allowed to be less than 16 MiB. The client-specific differential packet is logically maintained as a complete operation sequence. Each physical fragment is appended with the same update session number, a fragment sequence number that increments continuously from 0, and the total number of fragments. The client only performs the final commit after all fragments have been received completely.

[0094] The local area network mirror node determines the set of leaf nodes to be verified based on the transmission operation items and the target position of the multiplexing operation items whose source offset and target offset are inconsistent. It extracts the proof path from the leaf node to be verified to the root node from the Merkle verification data, removes internal nodes that can be reconstructed from the leaf node to be verified, and deduplicates the proof nodes with the same node position to obtain the set of shared proof nodes.

[0095] In this embodiment, the mirror node maps the target byte range covered by the transmission operation to the Merkle leaf node corresponding to the 4096-byte microblock. Simultaneously, it maps the multiplexed data that has undergone position shifting to the leaf node covered by the target position of the multiplexed data. Duplicate leaf nodes are deduplicated according to their node positions to obtain the set of leaf nodes to be verified. If an operation item covers at least one byte in a microblock, the corresponding leaf node of that microblock is added to the set of leaf nodes to be verified.

[0096] The proof path aggregation adopts a deterministic Merkle multi-proof construction method. For each node in the set of leaf nodes to be verified, it is processed layer by layer from the leaf layer to the root node. When the sibling node of the current node can be calculated from the leaf node to be verified or the internal node that has been reconstructed in the previous layer, the sibling node is not added repeatedly from the Merkle verification data. When the sibling node cannot be reconstructed from the target data already available on the client side, the hash value of the sibling node is read from the Merkle verification data, and the node position composed of the level number and the node sequence number within the level is added to the shared proof node set as a unique key. When multiple proof paths request the same node position, only one copy of the corresponding node hash value is retained, and merging is not based on the similarity of hash values.

[0097] The local area network mirror node records the node position of the leaf node to be verified, the node position of the shared proof node, and the reconstruction order. It reads the signature root hash information from the Merkle verification data, combines the node position of the leaf node to be verified, the set of shared proof nodes, the node position of the shared proof node, the reconstruction order, and the signature root hash information into aggregated verification data, and sends the client-specific differential packet and aggregated verification data to the client.

[0098] In this embodiment, the reconstruction order is recorded from low to high according to the Merkle tree hierarchy. Within the same level, the reconstruction order is recorded from small to large according to the intra-level node number of the parent node. Each reconstruction record includes the parent node position, left input position, and right input position. The left and right input positions point to the leaf node to be verified, the shared proof node, or an already generated internal node, respectively. The client can determine the left and right order of each hash connection by following the predetermined order, without needing to infer the correspondence between proof nodes. The LAN mirror node cannot modify the root node hash value in the signature root hash information to make the client accept it, because the root node hash value is protected by the digital signature of the central server. When the LAN mirror node modifies the shared proof node, differential data, or reconstruction order, the final calculation result will fail the target root hash consistency check.

[0099] Table 2 Statistical Results of Differential Distribution Simulation

[0100] project Scene 1 Scene 2 Scene 3 Latest software data volume 256MiB 512MiB 1024MiB Reusable target data volume 242MiB 436MiB 796MiB Differential data volume to be transmitted 14MiB 76MiB 228MiB Differential data as a percentage of the latest version 5.47% 14.84% 22.27% Independent proof path corresponding node reference count 57344 330752 1050624 After aggregation, the number of shared proof nodes is increased. 1124 4886 14731 Untampered data root hash verification Consistent Consistent Consistent

[0101] As shown in Table 2, in the three simulation scenarios where reusable data constitutes a large proportion of the target software, differential data to be transmitted can be generated based on the old client data, with a smaller amount of complete data than the latest software version. Specifically, 14MiB divided by 256MiB yields 5.47%, 76MiB divided by 512MiB yields 14.84%, and 228MiB divided by 1024MiB yields 22.27%. The proportions in the table are consistent with the corresponding data volumes. Meanwhile, multiple independent proof paths corresponding to the leaf nodes to be verified contain duplicate ancestor nodes. By deduplicating nodes according to their positions and omitting internal nodes that can be reconstructed from the updated leaf nodes, the actual number of shared proof nodes sent is lower than the node reference count when each leaf node carries its own complete proof path. The data in the table is used to illustrate the data relationships during the implementation process and does not constitute a limitation on the actual software scale or differential proportions.

[0102] The client reconstructs the Merkle branch using the old file blocks and client-specific differential packages, verifies and reconstructs the root hash based on the aggregated verification data, and merges the client-specific differential packages after verification. The specific steps are as follows:

[0103] In this embodiment, the client uses a temporary update directory to save the target data before officially rewriting the current software file, and keeps the old version of the software directory as a read-only data source during differential execution, thereby avoiding the situation where other reuse operations cannot continue to read the corresponding source data after a certain reuse operation overwrites the old version of the data in advance.

[0104] The client reads the signature root hash information, the node position of the leaf node to be verified, the set of shared proof nodes, the node position and reconstruction order of the shared proof nodes from the aggregated verification data, and uses the preset public key to verify the digital signature in the signature root hash information. After the verification is successful, the root node hash value in the signature root hash information is determined as the target root hash.

[0105] In this embodiment, when the client installs the software distribution program, it writes the central server's Ed25519 public key into the protected program resources or the operating system's trusted key storage area, and selects the corresponding public key through the public key identifier in the signature root hash information. The client regenerates the combined digest of the software version identifier and the root node hash value using the same software version identifier encoding method as the central server, and verifies the 64-byte Ed25519 signature using a preset public key. Signature verification is a binary judgment, with no confidence threshold set. If signature verification fails, the update is immediately terminated, and differential operations sent by the local area network mirror node are not parsed as trusted update content. If signature verification succeeds, the 32-byte root node hash value protected by the signature is used as the unique target root hash for this update. When key rotation is required, the old and new public keys and their corresponding public key identifiers are preset when the client software is released. New public keys sent separately by the local area network mirror node and not included in the client's trusted public key set are not accepted.

[0106] The client parses the client-specific differential packet, reads the source position data from the old file block according to the reuse operation item, obtains the differential data according to the transmission operation item, combines the target data according to the node position of the leaf node to be verified and the target offset, calculates the SHA-256 hash value of the target data to obtain the hash value of the leaf node, and calculates the reconstruction root hash layer by layer according to the shared proof node set and reconstruction order.

[0107] In this embodiment, after parsing the operation item, the client first performs a boundary check. The source offset, target offset, and data length are all represented using 64-bit unsigned integers. The range of reused data satisfies that the sum of the source offset and the reused data length is not greater than the actual length of the source file, and the range of written data satisfies that the sum of the target offset and the written data length is not greater than the target file length recorded in the basic file manifest. If any addition results in a 64-bit integer overflow, or if any range exceeds the corresponding file boundary, the client-specific differential packet is directly determined to be invalid and the update is terminated. No truncation of out-of-bounds data is performed before continuing execution.

[0108] For legitimate multiplexing operations, the client recalculates the SHA-256 digest of the corresponding local file block when actually reading data from the source location, and compares it bit-by-bit with the SHA-256 digest recorded when generating the local file feature list. If they are inconsistent, it indicates that the old file data has changed after the differential calculation is completed. The client terminates the current update session and regenerates the local file feature list, not continuing to use the already generated multiplexing operation. If they are consistent, the corresponding bytes are then read from the specified source location of the old file, which remains in read-only state. This incorporates local file changes occurring between the update request initiation and the client's execution of the differential packet into the defined exception handling process.

[0109] For legitimate transmission operations, the client reads the data carried in the client-specific differential packet. When the same microblock to be verified contains both multiplexed data and transmission data, different data fragments are combined into the same 4096-byte target microblock according to the target offset of each operation item. If the microblock at the end of the target file is less than 4096 bytes, the actual data range is determined according to the actual length of the target file, and no extra bytes are padded. The client calculates the SHA-256 hash value of each target microblock to obtain the corresponding leaf node hash. According to the reconstruction order specified by the aggregated verification data, the left and right inputs are read item by item. The two 32-byte hash values ​​are concatenated in the order of left input first and right input last, and then the SHA-256 operation is performed to form the parent node hash until the unique 32-byte hash value corresponding to the root node position is obtained as the reconstruction root hash.

[0110] The client compares and reconstructs the root hash and the target root hash. If they match, the client writes the corresponding data to the target offset position in the target file path according to the multiplexing operation item and the transmission operation item. The client then truncates the file according to the target file length and performs the deletion operation item, thus completing the merging of the client-specific differential packets.

[0111] In this embodiment, both the reconstructed root hash and the target root hash are 32 bytes. Complete byte-by-byte consistency is used as the pass condition, without setting a similarity threshold, error range, or tolerance. Integrity verification fails if any single byte is inconsistent. Upon verification failure, the client deletes the temporary target file generated during the update, does not perform the deletion operation, does not overwrite the current old version of the software, and returns the software version identifier and update session number of the failed verification to the local area network mirror node. The local area network mirror node then regenerates the corresponding client-specific differential package. If root hash verification fails twice consecutively for the same target software version, the client stops reusing the current differential result and requests the complete latest version of the software file to avoid infinitely repeating the same failed differential session.

[0112] Upon successful verification, the client creates a temporary target file based on the target file path. It then writes the source location data corresponding to the multiplexing operation and the differential data corresponding to the transmission operation according to the target offset. After writing, the file is truncated according to the target file length recorded in the basic file list to prevent data residue from older versions that were located beyond the end of the target file. After all newly added and modified files have been written, the client replaces the current file with the temporary target file using an atomic renaming method within the same file system. Then, it performs a deletion operation to remove historical files that do not exist in the latest version of the software. After all operations are completed, the current software version identifier is updated to the software version identifier corresponding to the signature root hash information.

[0113] To further illustrate the integrity verification process, when a differential data segment sent by a local area network (LAN) mirror node to a client undergoes a 1-byte change during transmission, the recalculated SHA-256 hash value of the corresponding microblock differs from the hash value of the corresponding leaf node when the central server constructs the dynamic Merkle hash tree. This difference propagates along the reconstruction order to the parent and root nodes, resulting in a reconstructed root hash that is inconsistent with the target root hash. Therefore, the client will not submit a temporary target file. Similarly, when the shared proof node itself changes, it alters the calculation result of its corresponding parent node. The LAN mirror node also cannot re-establish a matching relationship by modifying the signature root hash information because it does not possess the central server's signature private key.

[0114] In another implementation scenario, if reusable data in an older client file is unexpectedly corrupted before the local file feature list is generated, the LAN mirror node performs a second-level verification based on the current SHA-256 digest uploaded by the client during the differential data generation process. The corrupted data cannot match the SHA-256 digest of the corresponding window in the latest software version, therefore no corresponding reuse mapping is generated, and it is reassigned as part of the differential data segment to be transmitted. For older source files that have changed after the local file feature list is generated, the changes are detected through a second SHA-256 verification before the client performs the reuse operation, thus covering both types of local data anomalies before and after differential calculation.

[0115] In actual deployment, each time the central server releases a new version of the software, it completes the construction of the basic file list, the latest version file blocks, the dynamic Merkle hash tree, and the Merkle verification data. It can then synchronize the same latest version data to multiple local area network (LAN) mirror nodes without needing to pre-create a differential packet for each historical client version within the LAN. After receiving the local file feature list from the client, different LAN mirror nodes prioritize comparing files based on their own stored historical version status directed acyclic graph. They then directly use the cached latest version file data for Rabin fingerprint sliding window matching and SHA-256 level 2 verification. Therefore, different historical client versions generate client-specific differential packets corresponding to their own older version data.

[0116] When there are a large number of clients, the LAN mirror node controls the number of concurrent sessions to 32 clients simultaneously generating differential packets. Clients entering from the 33rd to the subsequent 32nd session enter a first-in-first-out (FIFO) waiting queue, only entering the differential generation phase after an existing differential generation session has ended and released its corresponding memory. This ensures that the 512MiB differential session memory budget is not exceeded. For clients already in the differential generation phase, the single client buffer never exceeds 16MiB, and client-specific differential packets exceeding the capacity are transmitted through continuous physical fragmentation.

[0117] In summary, this implementation establishes unified, up-to-date software file data and a Merkle root of trust protected by digital signatures through a central server. Local area network (LAN) mirror nodes, combined with client-side local file characteristics and a directed acyclic graph of historical version states, determine the actual file range to be compared. Then, using a fixed 64-degree irreducible polynomial, a fixed 65536-byte feature window, and a Rabin fingerprint sliding window with a defined byte order, it locates data whose position has changed but whose content can still be reused. Bit-by-bit consistency verification using SHA-256 digests eliminates erroneous candidate data corresponding to Rabin fingerprint collisions. Based on the determined reused data, data to be transmitted, and deleted files, a client-specific differential packet is generated. Shared proof nodes are organized for the actual affected Merkle leaf nodes, enabling the client to check whether the updated data provided by the LAN mirror nodes is consistent with the latest software version based on the target root hash protected by the central server's signature. Before the update verification passes, the old version data and the current software state remain unchanged. After verification, temporary file replacement and deletion operations complete the submission. This makes version identification, differential generation, verification data generation, and client merging a software distribution process with clearly defined parameters, definite judgment conditions, and repeatable implementation.

[0118] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A software distribution method based on file manifest difference and local area network mirroring, characterized in that, Includes the following steps: The central server generates the latest version of the software basic file list, the latest version of the file block, the dynamic Merkle hash tree, and the Merkle verification data, and sends the basic file list, the latest version of the file block, and the Merkle verification data to the local area network mirror node; The local area network mirror node receives a list of local file characteristics from the client and determines the client version status based on a directed acyclic graph of historical version status. The local area network mirror node uses a Rabin fingerprint sliding window and two-level fingerprint matching to determine the differential file block set; The local area network mirror node generates a client-specific differential packet based on the differential file block set, performs proof path aggregation on the Merkle verification data to obtain aggregated verification data, and sends the client-specific differential packet and the aggregated verification data to the client; The client reconstructs the Merkle branch using the old file blocks and the client-specific differential package, verifies and reconstructs the root hash based on the aggregated verification data, and merges the client-specific differential package after the verification is passed.

2. The software distribution method based on file list difference and local area network mirroring according to claim 1, characterized in that, The central server generates a list of the latest software base files, the latest file blocks, a dynamic Merkle hash tree, and Merkle verification data. The specific steps for sending the list of base files, the latest file blocks, and the Merkle verification data to the local area network mirror node are as follows: The central server traverses the latest version of the software, obtains the file path, file length and software version identifier, splits each file according to the preset file block length to obtain the latest version file block, and records the software version identifier, the file path, the file length and the block offset in the basic file list; The central server divides the latest version file block into micro-blocks according to the preset micro-block length, calculates the SHA-256 hash value of the micro-block, arranges them into leaf nodes according to the file path, the block offset and the division order, and calculates the hash value of the parent node layer by layer to obtain the dynamic Merkle hash tree. When the latest version of the software changes, only the node hash values ​​from the affected leaf nodes to the root node are recalculated. The central server records the node positions and node hash values ​​of the dynamic Merkle hash tree, obtains the signature root hash information by combining the root node hash value with the software version identifier in a digest signature, assembles the Merkle verification data from the node positions, the node hash values, and the signature root hash information, and sends the basic file list, the latest version file block, and the Merkle verification data to the local area network mirror node.

3. The software distribution method based on file list difference and local area network mirroring according to claim 1, characterized in that, The steps for the local area network mirror node to receive the client's local file feature list and determine the client's version status based on the directed acyclic graph of historical version status are as follows: The local area network mirror node sends the feature window length to the client. The client segments the local software into local file blocks according to the feature window length, generates the local file feature list, and records the software version identifier, file path, block offset, Rabin fingerprint, and SHA-256 digest of the local file block. The local file feature list is then sent to the local area network mirror node. The local area network mirror node establishes the cached software version and the client's historical version as version vertices in the directed acyclic graph of the historical version status, establishes the direct update relationship as directed edges, records the software version identifier in the version vertex, and records the set of changed file paths in the directed edge. The local area network mirror node determines the latest version vertex corresponding to the latest version of the software, queries the corresponding version vertex according to the software version identifier in the local file feature list, and determines the queried version vertex as the client version status.

4. The software distribution method based on file list difference and local area network mirroring according to claim 3, characterized in that, The specific steps for the local area network mirror node to determine the differential file block set using the Rabin fingerprint sliding window and two-level fingerprint matching are as follows: The local area network mirror node retrieves the update path from the client version status to the latest version vertex, merges the set of changed file paths recorded by each directed edge in the update path, and obtains the set of file paths to be compared. For file paths in the set of file paths to be compared that exist simultaneously in the local file feature list and the basic file list, the local area network mirror node establishes a first-level fingerprint index based on the Rabin fingerprint of the corresponding local file block, slides the file data corresponding to the latest version of the software according to the feature window length, and recursively calculates the Rabin fingerprint. The recursive formula is: ,in , These are the fingerprint remainders after right shift and before right shift, respectively. , The binary field polynomials for the shifted-out byte and the shifted-in byte, respectively. For formal variables, The number of bytes in the window. For the pre-defined irreducible polynomial, Addition for a binary field; The local area network mirror node queries the first-level fingerprint index. Upon a match, it calculates the SHA-256 digest of the current window and performs a second-level verification with the SHA-256 digest of the matched local file block. If the verification matches, it records the source offset and target offset to form a reuse mapping and moves the window forward by the feature window length. Otherwise, it moves the window forward by 1 byte, records consecutive unmatched data as differential data segments to be transmitted, merges all data of the base file clearing the file into the differential data segment to be transmitted, and records the local file feature clearing the file as a deleted file record. The differential file block set is generated based on the reuse mapping, the differential data segment to be transmitted, and the deleted file record.

5. The software distribution method based on file list difference and local area network mirroring according to claim 1, characterized in that, The steps of generating a client-specific differential packet based on the differential file block set, aggregating the proof path of the Merkle verification data to obtain aggregated verification data, and sending the client-specific differential packet and the aggregated verification data to the client are as follows: The local area network mirror node parses the differential file block set to obtain multiplexing operation items, transmission operation items, and deletion operation items. The multiplexing operation item records the source position and the target position. The transmission operation item records the target position and differential data. The source position includes the source file path and the source offset. The target position includes the target file path and the target offset. The deletion operation item records the deleted file path. Each of the operation items and the target file length read from the basic file list are written into the memory buffer to obtain the client-specific differential packet. The local area network mirror node determines the set of leaf nodes to be verified based on the transmission operation item and the target position of the multiplexing operation item where the source offset and target offset are inconsistent. It extracts the proof path from the leaf node to be verified to the root node from the Merkle verification data, removes internal nodes that can be reconstructed from the leaf node to be verified, and deduplicates the proof nodes with the same node position to obtain the set of shared proof nodes. The local area network mirror node records the node position of the leaf node to be verified, the node position of the shared proof node, and the reconstruction order. It reads the signature root hash information from the Merkle verification data, combines the node position of the leaf node to be verified, the shared proof node set, the node position of the shared proof node, the reconstruction order, and the signature root hash information to form the aggregated verification data, and sends the client-specific differential packet and the aggregated verification data to the client.

6. The software distribution method based on file list difference and local area network mirroring according to claim 5, characterized in that, The steps of reconstructing the Merkle branch using the old file blocks and the client-specific differential package, verifying and reconstructing the root hash based on the aggregated verification data, and merging the client-specific differential package after successful verification are as follows: The client reads the signature root hash information, the node position of the leaf node to be verified, the shared proof node set, the node position of the shared proof node, and the reconstruction order from the aggregated verification data. It uses a preset public key to verify the digital signature in the signature root hash information. After the verification is successful, the root node hash value in the signature root hash information is determined as the target root hash. The client parses the client-specific differential packet, reads source location data from the old file block according to the reuse operation item, obtains differential data according to the transmission operation item, combines target data according to the node position of the leaf node to be verified and the target offset, calculates the SHA-256 hash value of the target data to obtain the leaf node hash value, and calculates the reconstruction root hash layer by layer according to the shared proof node set and the reconstruction order. The client compares the reconstructed root hash and the target root hash. If they match, the client writes the corresponding data to the position corresponding to the target offset in the target file path according to the reuse operation item and the transmission operation item. The client then truncates the file according to the target file length and executes the deletion operation item to complete the merging of the client-specific differential packet.

7. The system of the software distribution method based on file list difference and local area network mirroring according to any one of claims 1-6, characterized in that, include: Basic data generation and mirror synchronization module: The central server generates the latest version of the software basic file list, the latest version of the file block, the dynamic Merkle hash tree and the Merkle verification data, and sends the basic file list, the latest version of the file block and the Merkle verification data to the local area network mirror node; Version status identification module: The local area network mirror node receives a list of local file features from the client and determines the client version status based on a directed acyclic graph of historical version status; Differential file block determination module: The local area network mirror node uses Rabin fingerprint sliding window and two-level fingerprint matching to determine the differential file block set; Differential packet generation and verification data aggregation module: The local area network mirror node generates a client-specific differential packet based on the differential file block set, performs proof path aggregation on the Merkle verification data to obtain aggregated verification data, and sends the client-specific differential packet and the aggregated verification data to the client; Reconstruction verification and differential merging module: The client reconstructs the Merkle branch using the old file block and the client-specific differential package, verifies and reconstructs the root hash according to the aggregated verification data, and merges the client-specific differential package after the verification is passed.

Images