Enterprise data management method and system based on blockchain light node

Abstract

The present application relates to the field of data processing, more particularly, the present application relates to a blockchain light node-based enterprise data management method and system, the method comprising: generating a first layer summary by shuffling after segmenting business records; generating an upper layer summary by shuffling after exclusive or of adjacent three summaries using a width 3 sliding window, and iterating to a top layer unique summary. Light node initialization only synchronizes the top layer summary and the first and last boundary summaries of each layer. During verification, request neighborhood initial summaries and path intermediate summaries according to target segment indexes and neighborhood radius; reconstruct each layer summary using local boundaries and request summaries, calculate hamming distance with stored evidence summaries to obtain layer offset sequence, and then calculate weighted deviation degree coefficient, and determine tampering if the coefficient exceeds the threshold. After determining tampering, calculate layer offset difference value, scan the first abnormal starting layer exceeding the gradient threshold, and map to the tampering time range of the record segment interval. The present application realizes constant level verification interaction and supports coarse-grained tampering positioning.

Description

Technical Field

[0001] This invention relates to the field of data processing. More specifically, this invention relates to an enterprise data management method and system based on blockchain light nodes. Background Technology

[0002] In blockchain data integrity verification scenarios, light nodes often employ Merkle tree structures to conserve storage space, persisting only the root hash value. When integrity verification of a historical record is required, the light node must obtain a Merkle proof path containing a series of sibling node hashes from the full node. The length of this path is logarithmically related to the total number of records, n, and the amount of interactive data required for a single verification increases with n. However, light nodes typically only receive a few hundred KB of non-volatile storage quota, and network bandwidth must prioritize real-time business processes. As business records continue to accumulate, the communication overhead generated by verification requests can easily exceed network capacity, highlighting the growing conflict between storage and interaction.

[0003] Furthermore, the aforementioned Merkle tree-based verification mechanism can only output a binary conclusion of completeness or tampering. When tampering is detected, it cannot further determine the specific record interval or time range involved in the tampering. To trace the source of tampering, auditors have to obtain a large amount of raw data from the complete node and compare it record by record, which is inefficient. At the same time, the lightweight node cannot complete verification autonomously in offline mode and lacks independent auditing capabilities. Therefore, under the premise of strictly controlling storage to a few hundred KB and prioritizing bandwidth services, how to decouple the amount of verification interaction data from the total number of records and maintain a constant request scale, so that the lightweight node can complete the integrity determination offline autonomously with only a very small amount of synchronized data, and can coarsely locate the tampered record segment interval when tampering is detected, has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0004] To address the technical challenges of decoupling the amount of verification interaction data from the total number of records while maintaining a constant request scale, under the premise of strictly controlling storage to a few hundred KB and prioritizing bandwidth services, enabling lightweight nodes to autonomously complete integrity determination offline with only a very small amount of synchronization data, and coarsely locating the tampered record segment when tampering is detected, this invention provides solutions in the following aspects.

[0005] In the first aspect, the enterprise data management method based on blockchain light nodes includes: The business records are divided into record segments according to time sequence, and a hash operation is performed on each record segment to generate a first-level summary; Using a sliding window with a width of three, the current layer's three adjacent summaries are XORed bitwise and then hashed and compressed to generate the previous layer's summary. This process is repeated layer by layer until a unique summary is generated at the top layer. During the initialization of a light node, only the top-level digest and the first and last boundary digests of each layer are synchronized from the full node and stored. Upon receiving a verification task, the light node requests a preset number of initial neighborhood summaries and intermediate path summaries from the full node based on the target segment index and the preset neighborhood radius. The light node uses the locally stored boundary digest and the requested digest to reconstruct the digests of each layer according to the same rules, and calculates the difference between the light node and the evidence digest provided by the full node layer by layer to obtain the layer offset sequence. The light node calculates a weighted deviation coefficient based on the layer offset sequence. If the coefficient is greater than a preset threshold, it is determined that there has been tampering. When tampering is detected, the light node calculates the difference value between adjacent layers of the layer offset sequence, scans to obtain the abnormal starting layer that first exceeds the gradient threshold, and maps it to the corresponding record segment interval to locate the time range in which the tampering occurred.

[0006] Optionally, the hash operation employs the SM3 cryptographic hash algorithm.

[0007] Optionally, as the sliding window moves within each layer, there is an overlap of two summaries between adjacent windows, such that each upper-layer summary incorporates information from three adjacent lower-layer summaries.

[0008] Optionally, the layer-by-layer boundary summary includes the first and last summary of each layer from the first layer to the layer below the top layer; The amount of persistent storage required during the initialization of the light node is fixed and does not increase with the total number of record segments.

[0009] Optionally, the preset neighborhood radius is two, and the preset number of initial neighborhood summaries is five.

[0010] Optionally, requesting a preset number of initial neighborhood summaries and intermediate path summaries from complete nodes includes: sending requests to at least two complete nodes, cross-validating the summaries returned from different complete nodes, and using the consistent summaries for subsequent steps.

[0011] Optionally, the step of calculating the difference layer by layer to obtain the layer offset sequence includes: for each layer, calculating the Hamming distance between the reconstructed summary and the evidence summary, and using the Hamming distance as the layer offset of that layer, thereby forming the layer offset sequence.

[0012] Optionally, the step of calculating the weighted deviation coefficient based on the layer offset sequence includes: multiplying the layer offset of each layer by the power of the difference between the total number of layers and the current layer number (based on a preset layer attenuation factor), summing all the products, and then dividing by a normalization factor to obtain the weighted deviation coefficient.

[0013] Secondly, the present invention provides an enterprise data management system based on blockchain light nodes, employing the following technical solution: The enterprise data management system based on blockchain light nodes includes: a digest generation module, used to acquire business records and divide them into record segments according to time sequence, perform hash operation on each record segment to generate a first-layer digest, use a sliding window with a width of three to perform bitwise XOR on the three adjacent digests of the current layer and perform hash compression to generate the upper-layer digest, iterating layer by layer until a top-level unique digest and multiple intermediate-layer digests and corresponding first and last boundary digests are generated; a light node synchronization module, used to synchronize only the top-level unique digest and the first and last boundary digests of each layer from the complete node and store them during light node initialization; and a request receiving module, used to, when a verification task is received, according to the target segment The system includes: an index and a preset neighborhood radius; a request for a preset number of initial neighborhood summaries and intermediate path summaries from the complete node; a summary reconstruction and offset calculation module; a module that receives the initial neighborhood summaries and intermediate path summaries, and uses the stored boundary summaries and the requested summaries to reconstruct the summaries of each layer according to the rules of the summary generation module; and uses the obtained evidence-based summaries to calculate the differences layer by layer to obtain the layer offset sequence; an offset determination module that calculates the weighted deviation coefficient based on the layer offset sequence, and determines that tampering has occurred when the coefficient is greater than a preset threshold; and a tampering location module that, when tampering is determined, calculates the difference value between adjacent layers of the layer offset sequence, scans to obtain the abnormal starting layer that first exceeds the gradient threshold, and maps it to the corresponding record segment interval to locate the time range in which the tampering occurred.

[0014] The present invention has the following effects: 1. This invention employs a multi-layer digest generation structure based on sliding window XOR merging. It uses a window with a width of 3 to perform bitwise XOR and SM3 compression on adjacent digests, gradually spreading modifications to lower-level record segments to higher-level digests on both sides, forming an expanded influence cone. This structure allows for the reconstruction of the complete path using only a small number of local neighborhood digests when verifying a single target segment. The required amount of auxiliary data remains constant and independent of the total number of records, effectively improving tamper detection sensitivity and reducing verification data transmission overhead. Furthermore, it uses the national cryptographic SM3 algorithm to generate fixed-length digests, exhibiting high collision resistance and tamper sensitivity, meeting the cryptographic compliance requirements of the domestic IT innovation environment.

[0015] 2. Lightweight node initialization only requires synchronizing the top-level summary and the first and last boundary summaries of each layer, with a persistent storage size of approximately 16KB, far below the budget limit and not increasing with the accumulation of records. During verification, based on the target segment index and the preset neighborhood radius k, only 2k+1 initial neighborhood summaries and a small number of intermediate path summaries are requested from the full node, keeping the data volume of a single request within a few thousand bytes, thus decoupling the verification interaction volume from the historical scale.

[0016] 3. This invention calculates the layer offset sequence by combining the reconstructed summary and the evidence summary of each layer using Hamming distance. A layer attenuation factor is introduced for weighted summarization to obtain the deviation coefficient D, which is used to determine overall integrity, avoiding false alarms caused by single-layer differences. When tampering is detected, the offset difference between adjacent layers is calculated and a gradient scan is performed to capture the first abnormal starting layer that exceeds the gradient threshold. This is then reverse-mapped to the corresponding record segment interval, achieving coarse-grained localization of the tampering time range. This dual-determination mechanism provides traceability clues while outputting integrity conclusions, and the gradient localization logic is robust to occasional bit errors or noise, reducing the risk of false alarms. Attached Figure Description

[0017] Figure 1 This is a flowchart of steps S1-S7 in the enterprise data management method based on blockchain light nodes according to an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments.

[0019] Reference Figure 1 The enterprise data management method based on blockchain light nodes includes steps S1-S7, as detailed below: S1: Divide the business records into record segments according to time sequence, and perform a hash operation on each record segment to generate the first-level summary.

[0020] Because enterprise business records are continuously generated in a streaming manner, and blockchain light nodes can only allocate a few hundred KB of non-volatile storage space, and network bandwidth must prioritize real-time business, it is impossible to support storing each record one by one and frequent network interactions. Therefore, business records are divided into non-overlapping and temporally continuous record segments according to a preset fixed time window. Each record segment contains several original business records generated within that window and their corresponding national cryptographic trusted timestamps, which are then sequentially marked as follows: This gives each record segment a clear time attribute.

[0021] For each record segment Calculate a fixed-length 256-bit initial hash value as the data fingerprint of this record segment, i.e., the first-level digest. The subscript 1 indicates that the abstract is located in the first level of the hierarchical abstract structure. The segment number is used within this layer. The hash calculation uses the SM3 cryptographic hash algorithm approved by the State Cryptography Administration. This algorithm is a well-known technology. Its output 256-bit string has a fixed length and uniform distribution characteristics. Due to the avalanche effect of the SM3 algorithm, any small change in the content of the record segment will cause a large and irregular change in the generated digest value. Therefore, by comparing the digest, it can be determined whether the content of the record segment has been modified.

[0022] Each first-level digest is fixed at 256 bits (32 bytes). This length does not change with the size of the original record segment, allowing light nodes to store the data fingerprints of several record segments with only a small amount of storage space, without having to record the complete content. When a light node connects to the blockchain network, the first-level digest is pre-generated and continuously maintained by the full node. Light nodes can obtain the required digest fragments from the full node as needed, or they can calculate and verify them themselves after receiving the original record segment locally, thereby completing the generation of the first-level digest.

[0023] S2: Using a sliding window with a width of three, the current layer's three adjacent summaries are XORed bitwise and then hashed to compress and generate the previous layer's summary. This process is repeated layer by layer until a unique summary is generated at the top layer.

[0024] After obtaining the first-level abstract sequence Then, the number of summaries in this layer. Consistent with the total number of record segments.

[0025] As the number of record segments continues to grow with the continuous operation of the business, the number of Level 1 digests increases linearly. If all Level 1 digests are stored directly, the persistent storage overhead of the light node will exceed its non-volatile storage limit of several hundred KB.

[0026] Meanwhile, each summary in the first layer only represents the content of a single record segment, and the temporal dependencies between adjacent summaries are not included in the summary structure.

[0027] Therefore, a sliding window XOR compression operation with a width of 3 is applied to the first-level summary sequence. The three adjacent summaries in the window are XORed bitwise and then hashed using SM3 to generate the second-level summary. This reduces the number of summaries while aggregating neighborhood information into the upper-level summary.

[0028] Sliding window operation with the first The layer summary sequence generates the first layer from the input. Layer summary, the specific generation rules are as follows: for the first layer... Three consecutive summaries in the layer First, perform a bitwise XOR operation on the three 256-bit digests. Then, input the resulting 256-bit XOR value into the SM3 cryptographic hash algorithm to output a new 256-bit digest as the first digest. The index in the layer is Abstract .

[0029] The mathematical representation of this process is:

[0030] In the formula, The abstract level number is incremented from 2; This is the summary index within the current layer, and the valid range is... , For the first Total number of layer summaries.

[0031] The bitwise XOR operation allows each bit of the three input digests to be combined independently. Flipping any bit in any input digest will cause a change in the corresponding bit of the XOR result, thereby triggering an avalanche-like change in the SM3 output.

[0032] Each time the window slides forward one summary position, a new summary is generated. Layer summary, therefore the first Number of layer summaries Decreasing layer by layer.

[0033] The above operations are performed layer by layer from layer 1 upwards. After generating a new layer's summary sequence, the number of summaries for that layer is checked. Is it 1?

[0034] like If so, then this layer is taken as the new current layer, and the sliding window XOR compression with a width of 3 continues; if The iteration terminates when the summation reaches zero, and the unique summary of that layer becomes the unique summary of the top layer. , The floor number at the time of termination.

[0035] To ensure iteration reaches a unique top-level summary, the total number of record segments should be an odd number greater than 1. If the actual number of record segments is even, it is padded to an odd number by adding an empty record segment or a zero-summary placeholder, so that the sequence of summary numbers eventually converges to 1. The iteration terminates when the initial... When the number is odd, the total number of floors .

[0036] After the iteration is complete, in addition to obtaining the top-level summary, the summary sequence of each intermediate layer is also output, and the left boundary summary of each layer is... The right boundary summary is .

[0037] In this hierarchical structure, there is an overlap of two summaries between adjacent sliding windows: the first... Layer Summary Will simultaneously serve as the first The input elements of three adjacent windows in the layer participate in the generation. , and (If the index is valid).

[0038] This overlap mechanism allows any change in a bottom-level summary to be transmitted not only to the second-level summary directly above after XOR and SM3 hashing, but also to different positions in the upper layer corresponding to adjacent summaries in the same layer through the overlap window, and further expand the scope of influence in the upper layer, forming a cone-shaped area of ​​influence that expands horizontally with the number of layers.

[0039] S3: When a light node is initialized, it only synchronizes and stores the top-level digest and the first and last boundary digests of each layer from the full node.

[0040] Because the non-volatile storage space allocated to light nodes in a dedicated private cloud based on the ARM architecture is limited to the hundreds of KB level, and the total number of digests maintained by a full node varies with the number of business record segments... As the number of records increases linearly, if a light node synchronizes the full digest during initialization, it will immediately exceed its storage budget. Therefore, the light node utilizes the characteristic that the verification process in the hierarchical digest structure only requires local neighborhood information and boundary anchors to synchronize only the top-level unique digest and the first and last boundary digests of each layer from the trusted full node and write them to the local protected storage area, thereby decoupling the storage overhead from the total number of records.

[0041] Among them, the top-level summary of synchronization is the iteration termination time. The unique summary of the layer This digest has been written into the blockchain block header by the consensus node as the data storage value for this batch of records, while the synchronized beginning and end boundary digests of each layer refer to the data from the first block... Layer to the first The first summary of each layer With the last summary ,in For the first The number of digests for each layer is determined by the fact that light nodes send synchronization requests to at least one full node via the secure transport layer protocol to obtain these digest values.

[0042] Because the sliding window XOR compression operation with a width of three generates the first... Layer It is necessary to rely on the first Layer and ,but It does not actually exist, therefore the first The left boundary summary of a layer must be explicitly provided by the complete node and cannot be reconstructed through window operations; similarly, the right boundary summary... Due to the lack of a lower layer These boundary summaries must also be stored directly, thus becoming fixed anchor points on both sides of the hierarchical structure. In subsequent verification, they can be directly used as local known quantities of light nodes to participate in the summary reconstruction without remote requests.

[0043] With an average daily output of n Taking a single record as an example, the termination condition of hierarchical iteration... In the given formula, n represents the total number of record segments, that is, the total number of record segments into which the business records are divided according to time sequence in step S1. The total number of layers is [number], and the total number of summaries that light nodes need to synchronize is [number] from the top layer. Summary of the first and last boundaries of each layer The sum of these is approximately [number] A fixed-length 256-bit digest value, the total amount of synchronized data is approximately byte is approximately KB, this value only varies with The increase is gradual and the upper limit is much lower than the hundreds of KB of storage quota available to light nodes, thus meeting the requirement that persistent storage is fixed and does not increase with the total number of record segments.

[0044] After receiving synchronization data, the light node uses the onboard secure element or the ARMTrustZone trusted execution environment to process the received top-level digest. The data is compared and verified with the memory certificate value of the block header in this batch. When the two are consistent, it is confirmed that the data is complete and has not been replaced. Then, all the beginning and end boundary digests are written into the non-volatile memory in the order of the layer index and the read-only protection attribute is set. This initialization synchronization operation is only performed once after the node is first deployed or after unrecoverable data corruption occurs. No additional persistent write overhead is generated during the daily verification stage.

[0045] S4: When a verification task is received, the light node requests a preset number of initial neighborhood summaries and intermediate path summaries from the full node based on the target segment index and the preset neighborhood radius.

[0046] After the light node completes initialization and synchronization and connects to the blockchain network, when the upper-layer auditing application issues an integrity verification task for a specific historical record segment, the light node receives the task and extracts the target record segment index from it. and preset verification neighborhood radius ,in The empirical value of 2 is used; it is dimensionless and can be adjusted by the implementer according to the specific implementation scenario.

[0047] At this point, the lightweight node's local persistent storage only holds the top-level unique digest. and the first and last boundary summaries of each intermediate layer It is impossible to reconstruct the coverage target segment based solely on this local data. The complete propagation path to the top-level digest requires light nodes to request supplementary information on two types of missing digests from full nodes in the blockchain network.

[0048] The light node calculates the set of initial neighborhood summaries and intermediate path summaries required for this verification based on the local record of the summary index range of each layer, the specific location of the existing boundary summaries, and the sliding window mapping relationship with a width of three in the layer generation rules.

[0049] The initial neighborhood summary set is taken from the index of the first-level summary sequence. to Continuous A summary value, when That is, it is fixed to include , , , , Five fixed-length digests, each 256 bits long (32 bytes).

[0050] The selection logic for intermediate summaries along a path is as follows: for the first... Layer to the first Layer, with the target segment's underlying index Starting from the bottom, and based on the index offset relationship inherent in the sliding window merging, the summary index related to the propagation path of the target segment is derived layer by layer from bottom to top; if the index value derived from a certain layer is equal to 1 or equal to the total number of summaries in that layer... If the position indicates that it is exactly the beginning and end boundary digest of the already synchronized data, then the corresponding digest will not be included in the request list; otherwise, the digest corresponding to the index will be... Add to the path intermediate summary request list.

[0051] After this filtering, the actual number of intermediate path digests required is... Significantly smaller than And its size only increases with the total number of floors. The target segment index position changes smoothly and does not change with the total number of record segments. Linear growth.

[0052] The light node sends a list of requests containing the two types of digest indexes mentioned above to at least two pre-configured and distinct full nodes simultaneously via a secure transport layer protocol. Each full node retrieves the corresponding digest value by index in its local digest library and returns response data.

[0053] After receiving responses from multiple full nodes, the light node performs byte-level cross-validation on the same index digest value from different sources: if at least two different nodes return the same digest value that is completely identical byte by byte, then the digest value is determined as trusted data and temporarily stored in a temporary cache; if a small number of nodes return values ​​that are inconsistent with other nodes, then the digest value that is consistent with the majority of nodes is given priority; if the return values ​​of each node conflict with each other and a majority consensus cannot be formed, then this batch of response data is discarded, and after an interval of a random backoff time, the request is re-initiated or switched to a preset backup full node.

[0054] This cross-validation step avoids the risk of contaminating the validation input by a single complete node returning a false or corrupt digest with minimal computational and communication overhead.

[0055] After completing cross-validation and obtaining the required response, the light node obtains a consensus. Initial summary of each neighborhood and A dataset of intermediate summaries for each path, in , Under typical configurations, the total data volume requested is approximately several hundred bytes to several thousand bytes. It is usually a single digit.

[0056] The light node records these digest values, along with the top-level digest known in this verification session and the start and end boundary digests of each layer stored locally, into a temporary computing context dedicated to verification. This completes the data request and preparation for target segment integrity verification.

[0057] S5: Light nodes use locally stored boundary digests and requested digests to reconstruct the digests of each layer according to the same rules, and calculate the differences between the digests and the evidence digests provided by the full nodes to obtain the layer offset sequence.

[0058] After completing the digest request and cross-validation, the light node already holds the top-level digest within its verification context. Summary of the first and last boundaries of each layer Index range Total The initial summary of the first-level neighborhood and Intermediate summary of each path, target record segment index It has been confirmed that the original business records are not stored locally on the light node. The content cannot be directly obtained from The first-level digest is calculated using SM3 hash, but cross-validated data is already available. And its neighborhood values, therefore, starting from these reliable bottom-level summaries, the XOR compression rule with a width of three sliding windows set in the generation stage is used to reconstruct the summary values ​​of each layer on the target segment propagation path layer by layer from bottom to top.

[0059] After the reconstruction is started, the index in level 1 is Summary reconstruction value Directly equal to the obtained initial neighborhood summary ,in This is the bottom-level reconstruction benchmark for the target segment, with its left and right sides... Each neighborhood summary is also retrieved from the request set, thereby obtaining the three-element input required for the first-level window during upward reconstruction, for the layer number. from Increment to The valid index of the target segment at this layer is determined based on the index recursion relationship during sliding window merging. : Under normal circumstances , and when When the index is located at a layer boundary, it should be truncated appropriately to prevent it from going out of bounds. Then, the reconstructed summary value should be calculated layer by layer using the following formula:

[0060] In the formula For the first Reconstructed summary of layer target index location This is an SM3 cryptographic hash function. For bitwise XOR operations, among the three 256-bit digests on the right-hand side of the equation, if the indexed position belongs to the first and last boundary digest stored locally by the light node or the intermediate digest of the requested path, its stored value is directly referenced; if it belongs to the initial digest of the first-level neighborhood, then... If it belongs to the summary already reconstructed from the previous layer, then use... After the iteration is complete, the complete result is obtained. Layer Reconstruction Summary Sequence .

[0061] While constructing the reconstructed digest sequence, the light node retrieves the evidence digest at the same index position from its local temporary cache. These evidence digests, received from the complete node during the request phase and subjected to multi-source byte-level cross-verification, are considered trusted copies for each layer. The Hamming distance between the reconstructed summary and the existing summary is calculated using the following formula:

[0062] In the formula This function calculates the Hamming distance and counts the number of distinct bits in two bit strings of equal length. That is, the first Layer offset, in bits, with a value range of... arrive Integers, smaller ones This indicates that the reconstructed value of this layer is highly consistent with the original stored value, for all After the layer calculation is completed, the layer offset sequence is obtained. This sequence, along with the reconstructed summary and the evidence storage summary, is temporarily stored in the memory structure of the light node verification session.

[0063] S6: Light nodes calculate the weighted deviation coefficient based on the layer offset sequence. If the coefficient is greater than the preset threshold, it is determined that there is tampering.

[0064] The light node extracts the computed layer offset sequence from the verification session memory. ,in This represents the total number of layers in the hierarchical summary structure.

[0065] Due to the Layer offset It only reflects the local differences in the bottom-level summary of the target record segment. The initial neighborhood summary returned by the complete node may have a non-zero offset due to accidental bit errors or network jitter. The small number of bit flips caused by the tampering behavior at the bottom level will be XORed with SM3 layer by layer through sliding window and then manifested as a larger offset diffusion in the high-level summary. This makes the high-level offset significantly stronger indicative of the overall data integrity than the low-level offset. Therefore, if the offset of a certain layer is used to determine whether tampering has occurred, it is easy to generate false alarms or missed alarms.

[0066] To comprehensively utilize the offset information from each layer and reasonably reflect the amplification effect of higher-level offsets, the lightweight node performs weighted fusion of the offsets from each layer, calculating a scalarized weighted deviation coefficient. .

[0067] Weighted deviation coefficient The calculation method is as follows: first calculate each layer layer offset Multiply by a weighting factor related to layer depth, sum all the products, and finally divide by the normalization factor.

[0068] Its mathematical expression is:

[0069] In the formula, The layer number is incremented from the bottom layer to the top layer. ; For the first The layer offset, i.e., the Hamming distance between the reconstructed digest and the evidence-based digest, is expressed in bits and has a range of values. to Integers; The layer attenuation factor is taken as an empirical value. It is dimensionless and can be adjusted by the implementer according to the specific implementation scenario. power exponent Follow Increase and decrease, when When near the bottom Larger, weight Smaller, when When you reach the top floor tending to The weights approach This gives higher-level offsets a larger contribution ratio; A fixed bit length for each layer of the digest. The product is the total number of floors. As a normalization factor, The range of values ​​is mapped to an interval. , It is a dimensionless coefficient.

[0070] The weighted deviation coefficient is calculated using light nodes. Then, it is compared with the preset integrity judgment threshold. Comparison, Get experience points It is dimensionless and can be adjusted by the implementer according to the specific implementation scenario.

[0071] when This indicates that the overall offset of each layer is at a low level, there is no significant offset after the tampering signal is amplified in the higher layers, and the integrity of the data batch where the target record segment is located is not damaged, so this verification is successful.

[0072] when When this occurs, it indicates that at least one or more layers of offset have exceeded the normal fluctuation range, and the high-level offset is fully reflected after weighting. The light node determines that the data batch where the target record segment is located has been tampered with, and records the tampering conclusion in the result structure of this verification session.

[0073] Step S7: When tampering is detected, the light node calculates the difference value between adjacent layers of the layer offset sequence, scans to obtain the abnormal starting layer that first exceeds the gradient threshold, and maps it to the corresponding record segment interval to locate the time range in which the tampering occurred.

[0074] The weighted deviation coefficient has been calculated in step S6. and Greater than the integrity judgment threshold This indicates that the batch of data containing the target record segment has been tampered with, and the layer offset sequence... The magnitude of the offsets at different layers reflects the gradual amplification process of the bit difference caused by tampering propagating from the bottom to the top of the hierarchical structure. Sudden increases in the offsets between adjacent layers correspond to the characteristic that the tampered signal is significantly amplified by XOR and SM3 compression operations at a certain layer. Therefore, the light node calculates the difference values ​​between adjacent layers in the layer offset sequence to obtain the difference sequence. .

[0075] No. Layer and First Difference between layers Defined as:

[0076] In the formula, For the first The layer offset, i.e., the Hamming distance between the reconstructed summary and the evidence summary, is expressed in bits. This represents the difference in offset between adjacent layers, expressed in bits. Positive values ​​indicate an increase in offset, while negative values ​​indicate a decrease in offset.

[0077] Since the tampered signal usually exhibits a stepwise increase in offset as the number of layers increases during the diffusion process, there may be a local extreme point in the differential value sequence where the value suddenly increases beyond the background noise level. The layer where this point is located is the starting position where the abnormal signal is significantly amplified in the layered structure.

[0078] Light nodes set gradient threshold Take experience points It is dimensionless and can be adjusted by the implementer according to the specific implementation scenario. The higher the required accuracy of the abnormal initiation layer, the larger the gradient threshold.

[0079] from Initially, the light nodes sequentially check the difference values ​​of each layer. When it first appears At this time, record the layer number as the starting layer of the anomaly, denoted as . And terminate the scan.

[0080] Gradient threshold This means that when the difference in Hamming distance between two adjacent floors exceeds When the bit value is 1, it is considered that the offset change has exceeded the range of random fluctuations and belongs to the abnormal amplification caused by the tampering of the signal. Setting this threshold can avoid the non-zero but small difference value caused by occasional network transmission errors being misjudged as abnormal, so that the positioning operation focuses on the significant offset change that is really caused by the spread of tampering.

[0081] Obtain the abnormal starting layer Subsequently, the light node uses the index expansion relationship of the sliding window during hierarchical construction to reverse map the hierarchical position to the record segment range of the lower level.

[0082] For any layer in the abstract generation process The index is The abstract, which covers the first The index range of the layer record segment summary is continuous. .

[0083] On the verification path, the anomaly initiation layer The corresponding summary index is the index of the target path determined in the reconstruction phase at that layer. Therefore, the underlying record segments affected by the starting index and terminating index They are respectively:

[0084]

[0085] Since each record segment corresponds to a fixed time window and is accompanied by a reliable timestamp, the light node reads the record segment. and The timestamp information within the data can be used to determine the approximate time range in which the alteration occurred. ,in For recording segment The start time, For recording segment The termination time, the light node will specify the time range and the abnormal start layer number. The location results are then written into the output structure of this verification session.

[0086] If the light node from Start layer-by-layer scanning until None of the layers met the requirements. The layers, but the weighted deviation coefficient The threshold for judgment has been exceeded. This phenomenon indicates that although the overall offset of each layer is relatively high, there is no sudden increase in the offset of a certain layer that significantly dominates the total deviation. The reason may be that multiple bottom record segments are simultaneously subjected to micro-tampering with similar magnitudes and superimposed, or that the evidence digest provided by the complete node has a systematic deviation. In this case, the gradient scan cannot determine the unique abnormal starting layer, and the light node outputs the location failure in the verification result with an early warning prompt, suggesting that the auditors re-initiate the verification from other independent complete nodes or start the blockchain consensus layer cross-audit procedure.

[0087] The present invention also provides an enterprise data management system based on blockchain light nodes, including a processor and a memory, wherein the memory stores computer program instructions, and when the computer program instructions are executed by the processor, the enterprise data management method based on blockchain light nodes according to the first aspect of the present invention is implemented.

[0088] The system also includes other components well known to those skilled in the art, such as communication buses and communication interfaces, the settings and functions of which are known in the art and will not be described in detail here.

[0089] It should be noted that those skilled in the art can make various modifications and improvements without departing from the inventive concept, and these all fall within the scope of protection of this invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A method for enterprise data management based on blockchain light nodes, characterized in that: include: The business records are divided into record segments according to time sequence, and a hash operation is performed on each record segment to generate a first-level summary; Using a sliding window with a width of three, the current layer's three adjacent summaries are XORed bitwise and then hashed and compressed to generate the previous layer's summary. This process is repeated layer by layer until a unique summary is generated at the top layer. During the initialization of a light node, only the top-level digest and the first and last boundary digests of each layer are synchronized from the full node and stored. Upon receiving a verification task, the light node requests a preset number of initial neighborhood summaries and intermediate path summaries from the full node based on the target segment index and the preset neighborhood radius. The light node uses the locally stored boundary digest and the requested digest to reconstruct the digests of each layer according to the same rules, and calculates the difference between the light node and the evidence digest provided by the full node layer by layer to obtain the layer offset sequence. The light node calculates a weighted deviation coefficient based on the layer offset sequence. If the coefficient is greater than a preset threshold, it is determined that there has been tampering. When tampering is detected, the light node calculates the difference value between adjacent layers of the layer offset sequence, scans to obtain the abnormal starting layer that first exceeds the gradient threshold, and maps it to the corresponding record segment interval to locate the time range in which the tampering occurred.

2. The enterprise data management method based on blockchain light nodes according to claim 1, characterized in that, The hash operation uses the SM3 cryptographic hash algorithm.

3. The enterprise data management method based on blockchain light nodes according to claim 1, characterized in that, As the sliding window moves within each layer, there is an overlap of two summaries between adjacent windows, so that each upper-layer summary incorporates information from three adjacent lower-layer summaries.

4. The enterprise data management method based on blockchain light nodes according to claim 1, characterized in that, The first and last boundary summaries of each layer include the first and last summaries of each layer from the first layer to the layer below the top layer; The amount of persistent storage required during the initialization of the light node is fixed and does not increase with the total number of record segments.

5. The enterprise data management method based on blockchain light nodes according to claim 1, characterized in that, The preset neighborhood radius is two, and the preset number of initial neighborhood summaries is five.

6. The enterprise data management method based on blockchain light nodes according to claim 1, characterized in that, The step of requesting a preset number of initial neighborhood summaries and intermediate path summaries from complete nodes includes: sending requests to at least two complete nodes, cross-validating the summaries returned from different complete nodes, and using the consistent summaries for subsequent steps.

7. The enterprise data management method based on blockchain light nodes according to claim 1, characterized in that, The stepwise calculation of differences to obtain the layer offset sequence includes: for each layer, calculating the Hamming distance between the reconstructed summary and the evidence summary, and using the Hamming distance as the layer offset of that layer, thereby forming the layer offset sequence.

8. The enterprise data management method based on blockchain light nodes according to claim 1, characterized in that, The calculation of the weighted deviation coefficient based on the layer offset sequence includes: multiplying the layer offset of each layer by the power of the difference between the total number of layers and the current layer number, which is a preset layer attenuation factor; summing all the products and dividing by the normalization factor to obtain the weighted deviation coefficient.

9. An enterprise data management system based on blockchain light nodes, characterized in that: include: The summary generation module is used to acquire business records and divide them into record segments according to time sequence. It performs a hash operation on each record segment to generate the first-level summary. It uses a sliding window with a width of three to perform bitwise XOR on the three adjacent summaries of the current layer and then performs hash compression to generate the next-level summary. It iterates layer by layer until a unique top-level summary, multiple intermediate-level summaries, and corresponding first and last boundary summaries are generated. The light node synchronization module is used to synchronize and store only the top-level unique digest and the start and end boundary digests of each layer from the full node during light node initialization. The request receiving module is used to request a preset number of initial neighborhood summaries and intermediate path summaries from the complete node when a verification task is received, based on the target segment index and the preset neighborhood radius. The summary reconstruction and offset calculation module is used to receive the initial neighborhood summary and the intermediate path summary, and reconstruct the summaries of each layer according to the rules of the summary generation module using the stored boundary summary and the requested summary, and calculate the differences layer by layer to obtain the layer offset sequence using the obtained evidence summary. The offset determination module is used to calculate a weighted offset coefficient based on the layer offset sequence, and to determine that tampering has occurred when the coefficient is greater than a preset threshold. The tampering location module is used to determine that tampering has occurred, calculate the difference value between adjacent layers of the layer offset sequence, scan to obtain the abnormal starting layer that first exceeds the gradient threshold, and map it to the corresponding record segment interval to locate the time range in which the tampering occurred.

Images