Engineering design file multi-version collaborative management method based on block chain

Abstract

The invention discloses an engineering design file multi-version collaborative management method based on a block chain, and relates to the technical field of file version collaborative management, and the method comprises the steps: obtaining the chain state data of a version event, and calculating a settlement control quantity set containing a settlement confidence coefficient lower bound, a time threshold value and a rollback probability function; according to the set and the version level, the number of initial temporary storage copies of the under-chain object and a copy set are determined, and nodes of the copy set meet fault domain coverage constraints and are sorted according to availability scores; carrying out spot check on the copy set according to a spot check interval to obtain a retrievability confidence index, dynamically calculating a temporary storage state retrievability threshold value based on the residual exposed window length and the rollback probability, and triggering redundant copy adjustment; when a long-term storage conversion condition is met, judging whether erasure coding is allowed or not, dynamically determining the number of data pieces and the number of coding pieces, and generating erasure code fragments when the recovery success probability is not lower than a final state recoverability threshold value; retrieability and consistency in the collaboration process of the multi-version engineering design files are improved.

Description

Technical Field

[0001] This invention relates to the field of collaborative document version management technology, and more specifically, to a blockchain-based method for collaborative management of multiple versions of engineering design documents. Background Technology

[0002] In the field of engineering design, as project complexity and collaboration expand, design documents often generate numerous versions, making version management, traceability, consistency, and secure sharing critical challenges. Traditional centralized version control systems or document management platforms suffer from single points of failure, rigid access control, and susceptibility to historical data tampering, making it difficult to meet the auditing and traceability requirements of multi-party collaborative scenarios with mutual trust. Blockchain technology, with its decentralized, immutable, and traceable characteristics, offers a new approach to building a trusted version management infrastructure. Existing solutions typically store file hashes or metadata on the blockchain, while storing the file entities (i.e., off-chain objects) in distributed networks or cloud storage. However, this hybrid storage model combining blockchain still faces several challenges: First, the storage of off-chain objects itself carries availability risks; storage nodes may go offline or data may be lost, and the hash references on the chain will become invalid as a result. Secondly, transactions on blockchains, especially public or consortium blockchains, may experience settlement delays and block rollbacks. Before the final confirmation of settlement, blindly performing cross-chain synchronization or long-term storage conversion may lead to inconsistencies in the state. Third, different versions have different importance, such as draft, review, and release versions. However, existing methods lack differentiated and adaptive storage protection strategies based on version level and real-time chain status. This results in either excessive redundant storage causing cost pressure or insufficient protection for critical versions. To address the above problems, this invention proposes a solution. Summary of the Invention

[0003] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a blockchain-based multi-version collaborative management method for engineering design documents to address the problems raised in the background section.

[0004] To achieve the above objectives, the present invention provides the following technical solution: A blockchain-based collaborative management method for multiple versions of engineering design documents includes the following steps: Obtain the chain state data of the version event on the blockchain, and calculate the settlement control quantity set based on the chain state data. The settlement control quantity set includes the lower bound of settlement confidence, time threshold and rollback probability function. Based on the settlement control quantity set and the version level of the version event, the initial number of temporary replicas and the initial set of temporary replicas of the off-chain object are determined, wherein the node selection of the initial set of temporary replicas satisfies the fault domain coverage constraint and is sorted according to the node availability score. According to the sampling interval and the number of samplings per round determined based on time threshold and version level, the initial temporary copy set is sampled to obtain the retrieval confidence index. The temporary retrieval threshold is dynamically calculated based on the remaining exposure window length and rollback probability. When the retrieval confidence index is lower than the temporary retrieval threshold, redundant replication adjustment is triggered to update the temporary copy set. When the off-chain object meets the preset long-term storage conversion conditions, it is determined whether erasure coding is allowed based on the settlement control quantity set and version level. If allowed, the number of data fragments is determined according to the size of the off-chain object. The number of encoded fragments is increased incrementally based on the availability confidence lower bound of the candidate fragment node set until the probability of successful recovery is not lower than the final state retrieval threshold. Then, the off-chain object is encoded into a number of encoded fragments and distributed and stored to the fragment node set to complete the long-term storage form conversion.

[0005] In a preferred embodiment, obtaining the settlement control quantity set includes: collecting basic on-chain data related to the transaction corresponding to the version event, including the block height of the block to which the transaction is included and the current standard chain head block height; continuously recording chain rollback event samples within a preset statistical window to form a rollback event sample set, and recording the time required for the transaction to reach a settlement stable state to form a settlement time sample set; calculating the settlement depth index of the version event based on the collected on-chain data block height and the current standard chain head block height, wherein the settlement depth index is used to characterize the current stability of the version event on the chain, and for chains that do not provide a strong finality flag, the confirmation depth is used as the settlement depth index; The time taken to reach a stable settlement state is treated as a random variable. Based on the sample set of settlement time, the corresponding quantile of the random variable is calculated under a preset confidence level. This quantile is used as the time threshold for reaching a stable settlement state under the preset confidence level, thus obtaining the upper bound of the time for reaching a stable settlement state under the preset confidence level. The rollback event intensity is estimated based on the rollback event sample set to characterize the frequency of rollback events within a preset statistical window. The impact weight is estimated based on the rollback depth sample to characterize the impact of the rollback depth not being less than the settlement depth indicator. A rollback probability function with the time window length parameter as the independent variable is constructed in combination with the time window length parameter to represent the probability of an impactful rollback occurring within the preset time window length, thereby obtaining the rollback probability within the preset time window. Based on the obtained time threshold and the rollback probability function represented by the time window length parameter, a combination result of the lower bound of time confidence and the lower bound of non-rollback confidence is obtained. The combination result is used as the lower bound of settlement confidence output to form a set of settlement control quantities.

[0006] In a preferred embodiment, after forming the settlement control quantity set, it further includes: a rollback probability function with a time window length parameter as the independent variable and a synchronization execution window length for determining the cross-chain synchronization mode; wherein the synchronization execution window length is used to calculate the rollback probability within the synchronization execution window; based on a pre-stored threshold mapping table, the version level is mapped to a synchronization confidence threshold and a rollback probability upper limit. When the lower bound of the settlement confidence is greater than or equal to the synchronization confidence threshold and the rollback probability within the synchronization execution window length is less than or equal to the rollback probability upper limit, the cross-chain synchronization mode is determined to be the final state; otherwise, it is determined to be the temporary state.

[0007] In a preferred embodiment, determining the initial number of temporary replicas of an off-chain object includes: using the obtained time threshold as the upper bound of the temporary exposure period, defining the temporary exposure window length, and taking the temporary exposure window length as the sum of the time threshold and the synchronization execution window length; calculating the rollback probability within the temporary exposure window; pre-storing a replica parameter mapping table, which provides the basic number of replicas and incremental rules related to the exposure time level and rollback risk level, indexed by version level; mapping the time threshold to the exposure time level; mapping the rollback probability result within the temporary exposure window to the rollback risk level; and taking the higher of the exposure time level and the rollback risk level as the overall level. An exposure time threshold sequence and a rollback risk threshold sequence are pre-set. The exposure time level and rollback risk level are determined by the time threshold and the index of the interval where the rollback probability result within the temporary exposure window lies, respectively. The initial number of temporary replicas is obtained by looking up a table using the base number of replicas and the overall level. The replica parameter mapping table satisfies a monotonic constraint: when the version level is fixed, the number of initial temporary replicas given by the replica parameter mapping table does not decrease when the exposure time level falling within the time threshold increases; when the version level and exposure time level are fixed, the number of initial temporary replicas given by the replica parameter mapping table does not decrease when the rollback risk level falling within the temporary exposure window increases.

[0008] In a preferred embodiment, determining the initial temporary replica set includes: dividing the off-chain storage node set according to fault domain identifiers, wherein the fault domain identifiers include at least any one or a combination of organizational domains, regional domains, or cloud service domains; determining the number of fault domains to be covered from pre-stored fault domain coverage constraint parameters according to version level, wherein the initial temporary replica set covers no less than the number of fault domains to be covered; performing pull probes on each storage node within a preset probe window for no less than a preset minimum number of probes, recording the number of successful probes and the total number of probes, and calculating the node availability score, wherein the node availability score is the probe success rate; sorting candidate nodes from high to low according to the node availability score, and selecting nodes sequentially by prioritizing the coverage of uncovered fault domains, until the initial temporary replica set is full and the corresponding fault domain coverage constraint is met, and the selected node set is taken as the initial temporary replica set.

[0009] In a preferred embodiment, the redundant replication adjustment process includes: when the retrievability confidence index is lower than the temporary retrievability threshold, selecting nodes to be expanded from the candidate storage node set, performing pull probes on each candidate node for no less than the minimum number of probes within a preset probe window, recording the number of successful probes and the total number of probes, and obtaining the availability confidence lower bound of each candidate node using a confidence lower bound calculation function consistent with the sampling; using the node availability confidence lower bound as the sorting basis and combined with the fault domain coverage constraint, selecting candidate nodes in sequence to add them to the temporary replica set in order of prioritizing the coverage of uncovered fault domains, copying off-chain objects to the newly added nodes and completing the write confirmation, until the redundancy replication adjustment stops when at least one conservative probability of retrievability constructed from the complement of the product of the unretrievable probabilities of each node is not lower than a preset conservative threshold.

[0010] In a preferred embodiment, obtaining the retrievability confidence index includes: mapping version level and time threshold to sampling interval and single-round sampling number according to a pre-stored sampling parameter mapping table; selecting nodes from the current temporary replica set according to preset sampling rules to pull off-chain objects within each sampling cycle; performing consistency verification on the pulled content using the content digest registered on-chain; counting the number of successful pulls and the total number of samplings in a single round of sampling; calculating the success rate confidence lower bound based on the sampling success rate using the confidence lower bound calculation function and its confidence parameters; and using the success rate confidence lower bound as the retrievability confidence index. Simultaneously, the basic retrievability threshold is retrieved from the threshold mapping table according to the version level; the remaining exposure window length is calculated based on the difference between the time threshold and the elapsed time; the rollback probability within the remaining window is calculated using the rollback probability function; and the basic retrievability threshold is adjusted by combining the rollback risk gain coefficient to obtain a temporary retrievability threshold that dynamically changes with the remaining exposure window length and the rollback probability.

[0011] In a preferred embodiment, the preset long-term storage conversion conditions include erasure coding gating conditions. The erasure coding gating conditions include: defining the erasure coding execution window length, and looking up the gating threshold and rollback probability upper limit from the threshold mapping table according to the version level. When the lower bound of the settlement confidence in the settlement control set is not lower than the gating threshold and the rollback probability within the erasure coding execution window length is not higher than the rollback probability upper limit, it is determined that erasure coding is allowed to be performed on the off-chain object; otherwise, the temporary copy form is maintained and the long-term storage form conversion is delayed.

[0012] In a preferred embodiment, determining the number of data fragments based on the size of the off-chain object includes: dividing the off-chain object into multiple data fragments according to a partitioning strategy, wherein the partitioning strategy is at least related to the size of the off-chain object, the target size of a single fragment, and read concurrency constraints, in order to determine the number of data fragments.

[0013] In a preferred embodiment, the process of increasing the number of encoded fragments based on the availability confidence lower bound of the candidate fragment node set until the probability of successful recovery is not less than the final state retrieval threshold includes: performing pull probes on each candidate node in the candidate fragment node set within a preset probe window and recording the number of successful probes and the total number of probes; obtaining the availability confidence lower bound of each candidate node using a confidence lower bound calculation function; and using the minimum value of the availability confidence lower bound as the conservative availability representative value of fragment storage; during the process of increasing the number of encoded fragments from the number of data fragments, calculating the availability based on the conservative availability representative value using a binomial distribution model at each increment to obtain an availability of no less than the number of data fragments. The success probability of fragment recovery is calculated, and the final state retrieval threshold obtained from the threshold mapping table according to the version level is used as the stopping condition. When the success probability of recovery is not lower than the final state retrieval threshold for the first time, the current number of encoded fragments is determined. Storage nodes are selected for each encoded fragment in the fragment node set according to the fault domain coverage constraint. A fragment location set and its hash digest, fragment digest aggregation value, and hash digest of the fragment node set are generated. The number of data fragments, the number of encoded fragments, and the hash digest are written into the version registration contract of the first blockchain. At least one hot copy of the off-chain object is retained according to the version level and a corresponding retention time is set. The hot copy is recycled after the retention time is reached.

[0014] The technical effects and advantages of this invention's blockchain-based multi-version collaborative management method for engineering design documents are as follows: By continuously collecting on-chain state data and dynamically calculating settlement confidence, time thresholds, and rollback probabilities, this invention transforms the judgment of version stability from empirical to quantitative and verifiable, providing a precise basis for subsequent decision-making. Combining version levels and real-time risks, the invention dynamically determines and adjusts the number and distribution of temporary replicas, ensuring high retrieval while avoiding static over-configuration of storage resources, achieving a balance between reliability and cost. Through periodic sampling and dynamic threshold comparison mechanisms, it can promptly detect and trigger replica expansion. The invention effectively addresses node failures or network fluctuations, ensuring file availability during critical temporary storage periods. Furthermore, it employs a smart gating system for the transition from temporary to long-term storage, converting files to a more space-efficient erasure coding form only when on-chain settlement is sufficiently stable and rollback risks are manageable. Encoding parameters are scientifically determined to maximize storage efficiency while meeting long-term retrieval requirements. Finally, intelligent determination of cross-chain synchronization modes and version states ensures consistency and finality of version references in a multi-chain environment. Overall, this invention improves retrieval and consistency during the collaborative process of multi-version engineering design files. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the process of the blockchain-based collaborative management method for multiple versions of engineering design documents according to the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] Please see Figure 1 As shown, the embodiment Step S1: Collect chain state data related to version events, where a version event is a registration transaction event of a certain version of an engineering design document on the blockchain; generate a settlement control quantity set based on the chain state data, where the settlement control quantity set includes at least a settlement depth indicator, a time threshold for reaching a stable settlement state under a preset confidence level, a rollback probability within a preset time window, and a lower bound of settlement confidence constructed from the aforementioned quantities; and determine whether the cross-chain synchronization mode is in a temporary state or a final state based on the version level and threshold mapping table. This step involves collecting chain state data to obtain chain state data related to the settlement stability of version event v on the blockchain. This chain state data is then processed to generate a settlement control quantity set U(v). Specifically, basic on-chain data related to the transaction corresponding to version event v is obtained through the blockchain node interface or chain browsing interface, including the block height at which the transaction is included in the block. Current standard chain head block height ; and continuously record chain rollback event samples within a preset statistical window to form a rollback event sample set. ,in This indicates the time when the g-th rollback event occurs. This indicates the rollback depth of the rollback event; simultaneously, it records a sample of the time required for transactions to reach a stable settlement state within a preset statistical window, forming a settlement time sample set. Each set of settlement time samples This represents the time it takes for a transaction to go from being included in a block to reaching a stable settlement state; the above data items can be updated according to a preset period so that the output settlement control quantity set U(v) can reflect changes in the chain state; Based on the collected on-chain data block height Current standard chain head block height The settlement depth metric k(v) for version event v is calculated based on the following logic: the settlement depth metric k(v) characterizes the current stability of version event v on the chain; for chains that do not provide a strong finality flag, the confirmation depth can be used as the settlement depth metric. Accordingly, the settlement depth metric can be calculated as follows: When a transaction has not yet entered the canonical chain or has been removed from the canonical chain due to restructuring, the settlement depth indicator k(v) is set to 0 to represent an unstable state. Then, the time threshold for reaching a settlement steady state under the preset credit level is calculated. The calculation logic is as follows: In order to obtain the upper bound of the time for reaching a settlement steady state under a preset confidence level, the settlement time sample set is analyzed. Calculate the time threshold corresponding to the preset information level, whereby the time threshold can be defined as follows: Where the random variable T represents the time taken to reach a stable settlement state, and q is a preset confidence level; the time threshold Used to characterize the exposure timescale of the subsequent temporary storage phase; Furthermore, calculations are performed within a preset time window. Rollback probability within The calculation logic is as follows: the rollback probability should simultaneously reflect the rollback event within a preset time window. The probability of rollbacks occurring within the settlement depth and the degree of impact of rollback depth on the settlement depth index k(v) are considered. Therefore, the intensity of rollback events is estimated based on a sample set of rollback events. This is used to characterize the frequency of rollback events within a window; for example, if the statistical window length is W, the number of rollback events within the window is... ,but And based on the rollback depth samples, the influence weights w(k(v)) are estimated and This is used to characterize the degree of influence of rollback depth not being less than the settlement depth indicator k(v); for example, when the event sample depth within the statistical window is... ,but ; where # is the mathematical symbol for counting, representing the event sample depth within the statistical window that satisfies the condition across all samples g. The number of samples that are greater than or equal to the settlement depth indicator k(v); This yields the impactful rollback probability; the rollback probability can be constructed as follows: The rollback probability is represented by the time window length parameter Δ. Δ is the preset time window length; when Δ takes different window lengths, the rollback probability calculation results within the corresponding window are obtained; Based on the obtained rollback probability and time threshold, the results are combined to construct and output the lower bound of the settlement confidence. Specifically, the credibility of version event v reaching a stable settlement state under a preset confidence level can be decomposed into two parts: one is the time threshold. The confidence level is the time it takes for the settlement to reach a stable state; the confidence level is the non-rollback confidence level, which assumes no rollback occurs within the settlement risk assessment window and does not affect the stable settlement state. Due to the time threshold... It is a time threshold defined under a preset confidence level q, therefore, at the time threshold The probability of reaching a stable settlement state within a certain timeframe is at least a preset confidence level q, which can serve as a conservative lower bound for the time confidence level; simultaneously, based on the rollback probability... It can be obtained within the preset time window The probability of a significant rollback occurring within a certain timeframe, and based on this, within a preset time window. The lower bound of the probability that no impactful rollback will occur can be taken as: Defined as a conservative lower bound; defines a settlement risk assessment window. In this embodiment, it is preferred to take Furthermore, the lower bound of settlement confidence is constructed as a combination of the lower bound of time confidence and the lower bound of non-rollback confidence. As a reproducible implementation, the lower bound of settlement confidence can be obtained as shown in the following formula: ; Furthermore, the length of the synchronization execution window used to determine the cross-chain synchronization mode is defined as... The This means: the maximum expected execution time window from initiating a synchronization request to the target chain completing a verifiable write and providing external queries; as an implementation method, It can be determined by system deployment parameters, preferably, The upper quantile of the completion time of the cross-chain synchronization task within the most recent preset statistical window can be used to reflect the upper bound of synchronization execution under the current system operating conditions; based on this, the rollback probability within the synchronization execution window is denoted as... Its meaning is: in the cross-chain synchronous execution window Within, the probability of a version event v undergoing an impactful rollback, leading to cross-chain state distortion; This implementation associates the cross-chain synchronization threshold with the version level result, outputting a version level L(v) for version event v. The version level includes at least a temporary level and a final level, or is further subdivided into draft level, review level, delivery level, etc. The version level L(v) can be obtained by the business tag, approval status, or preset rules carried by the version event. A set of threshold mapping tables M is pre-stored, which maps different version levels to synchronization confidence thresholds. With rollback probability cap This includes configuring a higher synchronization confidence threshold and a lower rollback probability cap for higher version levels; as an example implementation, the mapping table satisfies a monotonic constraint: as the version level increases, the synchronization confidence threshold... Monotonic and unreduced with a rollback probability cap The process remains monotonous and does not increase, thus ensuring a more conservative approach to synchronizing critical versions and a more agile approach to synchronizing low-risk versions. Based on the above definition and threshold mapping, the cross-chain synchronization mode mode(v) is determined according to the following rules: When both conditions are met ;as well as , If the output cross-chain synchronization mode mode(v) is the final state, then the output cross-chain synchronization mode mode(v) is the temporary state. Through the above processing, a set of settlement control quantities is formed and output. ;in For time window length parameter The rollback probability function is represented; in this step, it is taken as... Used for calculation and take Used for determining the cross-chain synchronization mode (v); and the set of settlement control quantities Used for initializing the number of temporary copies, constructing the retrievability threshold, triggering copy adjustments, and determining erasure coding gating in subsequent steps.

[0018] Step S2: Construct an off-chain object based on the version event. The off-chain object includes at least the engineering design file ontology, the version file ontology, the dependency list and dependency snapshot, and the evidence package metadata. Generate a content summary and off-chain object location information for the off-chain object, and write the version identifier, content summary, off-chain object location information, version level, and cross-chain synchronization mode into the version registration contract of the first blockchain. Specifically: An off-chain object O(v) is constructed based on version event v. The off-chain object O(v) includes at least the project design file ontology, version file ontology, dependency list, and dependency snapshots, such as external component library identifiers, referenced resource summaries, and evidence package metadata such as generation tool identifiers and key parameter summaries. Subsequently, a global hash or block hash aggregation is performed on the off-chain object O(v) to obtain a content digest H(v), and an off-chain object location information URI(v) is generated, such as object storage key-value pairs, distributed addressing identifiers, or resolvable access paths. The content digest result H(v) and the location information result URI(v) are output. The off-chain object is then... The object is registered to the first blockchain, specifically: only verifiable references and state information are stored on the chain, while the actual data is stored off-chain; therefore, the on-chain registration should at least include the binding relationship between the content digest result H(v) and the location information result URI(v), so that subsequent steps can use the on-chain digest to perform integrity verification on the off-chain pull results; in this embodiment, the version identifier of version event v, the content digest result H(v), the location information result URI(v), the version level of version event v, and the cross-chain synchronization mode mode(v) are written into the version registration contract of the first blockchain, so that a verifiable registration record is formed on the chain; Next, the initial number of temporary replicas and the initial set of temporary replicas are determined. The logic for this determination is as follows: Before version event v reaches a stable settlement state, off-chain objects are in the temporary exposure phase; the longer the exposure timescale or the higher the risk of short-term rollback, the more likely off-chain objects are to become unrecoverable due to factors such as node offline, permission changes, and cache eviction during this phase, thus affecting collaboration and reconciliation. Therefore, this implementation uses the time threshold output in step S1. Define the length of the temporary exposure window as the upper bound of the temporary exposure period. And select the best And calculate the rollback probability results within the temporary exposure window. ; Based on this, a set of replica parameter mapping tables is pre-stored. The mapping table is indexed by version level L(v) and gives the corresponding number of basic replicas. It also provides incremental rules related to exposure time level and rollback risk level, resulting in a higher base replica count for critical versions and a lower count for low-risk versions; simultaneously, the incremental rules satisfy a monotonic constraint: when the time threshold... The number of replicas does not decrease when the number of replicas is increased, and the rollback probability result is temporarily stored within the exposure window. The number of replicas does not decrease when the risk increases, thus ensuring that the strategy monotonically increases with risk. As a reproducible implementation, the time threshold is... Mapped to exposure time levels The rollback probability results within the temporary exposure window will be stored. Mapped to rollback risk level The overall level G(v) is then calculated from the two, and further determined by the base number of copies. The initial replica count is obtained by combining the overall rank G(v); its construction can be implemented according to the following rules: pre-set the exposure time threshold sequence. With rollback risk threshold sequence ;in , The grade value is determined by the corresponding interval number, for example, when Time to take ;when Time to take And set the overall level ; The initial number of temporary copies is then output. ; after obtaining the initial number of temporary copies Then, the initial set of temporary copies was further determined. To ensure that replicas do not fail simultaneously in the event of a domain failure, this implementation method denotes the set of off-chain storage nodes as follows: Each storage node is labeled with a fault domain identifier fd(j), and the fault domain includes at least one or a combination of organizational domains, geographic domains, or cloud service domains. This implementation method uses an off-chain storage node set Based on fault domain division, and according to pre-stored fault domain coverage constraint parameters... It is obtained by looking up the version level L(v) in a table, and the higher the version level, the more fault domains need to be covered; for example, the initial temporary copy set is required. The system covers at least two fault domains, preferably three or more. This means prioritizing nodes with higher availability while meeting fault domain coverage constraints to reduce the initial risk of unrecoverable data. To this end, during node selection, pull probes are performed on each storage node within a preset period, recording the number of successful probes and the total number of probes. The pull probes are performed within a preset probe window, and the number of probes is no less than a preset minimum. The minimum number of preset times Configure system parameters; and calculate node availability scores. Node availability score serves as the sorting criterion for replica placement. To measure the success rate of detection; then score based on node availability. Candidate nodes are sorted from highest to lowest, and nodes are selected sequentially in order of priority to cover uncovered fault domains, until the initial number of temporary replicas is reached. There are 1 node and the corresponding version event's fault domain coverage constraint is satisfied. Fault domain coverage requirements, output This is the initial set of temporary copies; Optionally, based on the analysis results obtained above, the present invention further constructs initial values ​​for the sampling plan. The construction logic is as follows: the longer the temporary exposure timescale, the more frequent or intensive the sampling needs to detect the decline in retrievability as early as possible. This embodiment is based on a pre-stored sampling parameter mapping table. Relate version level L(v) to time threshold The mapping is between the sampling interval I(v) and the number of samplings per round n(v), and satisfies the monotonic constraint: when the time threshold... When the value is increased, the sampling interval I(v) does not increase and the number of samplings per round n(v) does not decrease; as a reproducible implementation method, it can ensure that the entire temporary exposure window is maintained. At least execute Round of random inspections, among which Given the mapping table, the sampling interval is output. The number of single-round sampling checks, n(v), is output by the mapping table.

[0019] Step S3: When the cross-chain synchronization mode is in the temporary state, perform periodic sampling inspection on the temporary replica set and use the content digest to perform consistency verification on the pulled content, obtain the retrievability confidence index and compare it with the temporary state retrievability threshold, trigger replica adjustment until the retrievability target is met. Specifically: according to step S2, the sampling parameter mapping table The output sampling interval I(v) and the number of samplings per round n(v) are used; within each sampling cycle, the current temporary copy set is used. Its initial time The system selects nodes according to a preset sampling rule to pull off-chain objects. The pulled objects are either whole objects or object blocks. After pulling, the content digest H(v) registered on the chain is used to perform a consistency check on the pulled content. If the check passes, it is recorded as a success; otherwise, it is recorded as a failure. Thus, the number of successes m(v) and the total number of successes n(v) are obtained in a single round of sampling. The system also calculates a function based on a pre-stored confidence lower bound. The retrieveability confidence index and its confidence parameters define the retrieveability confidence index as the lower bound of the success rate obtained based on successful sampling, i.e., the retrieveability confidence index. Subsequently, a threshold for the retrievability of the temporary state is defined. The longer the temporary exposure period or the higher the risk of short-term rollback, the higher the requirement for the retrieval of off-chain objects. Therefore, the threshold should be dynamically adjusted according to the remaining exposure window and the rollback risk; for this purpose, the remaining exposure window length is defined. ;in This represents the elapsed time for version event v since it entered the staging stage, as shown in the threshold mapping table. Find the basic retrievability threshold by version level (L(v)). Then, the rollback probability function is used to calculate the rollback probability within the remaining window. Thus, the threshold for the retrievability of the temporary state is obtained. ;in The rollback risk gain coefficient is used to characterize the rollback probability relative to the threshold of temporary state retrievability. The incremental contribution intensity; the Configurable initial value And in Within the range; Retrievability confidence index The replica adjustment trigger result is obtained by comparing it with the temporary retrieval threshold. Redundancy replication adjustment is triggered in the candidate storage node set. In the process, for each candidate node j, at least the minimum number of probes are performed within the preset probe window. Pull probe, record the number of successful probes. Total number of detections The same confidence lower bound function is used to obtain the node availability confidence lower bound. Lower bound of node availability confidence Based on the sorting criteria and combined with fault domain coverage constraints Candidate nodes are selected sequentially to be added to the temporary replica set, prioritizing the coverage of uncovered fault domains, and the current temporary replica set is updated. The process continues until the stopping condition is met, at least one conservative probability of being retrievable after a node is constructed as the product complement of the probabilities of being unretrievable for each node, as shown in the following formula: ; when The condition for stopping is that the set of temporary copies is first established. At this point, the adjusted set of temporary copies is output. With the number of copies And copy the off-chain object O(v) to the newly added node to complete the write confirmation; Optionally, a quick review and sampling inspection can be performed to update the retrieveability confidence index. until Or it may reach a preset retry limit; wherein the preset retry limit can be set according to specific needs, and in this embodiment it is preferably 1 to 3 times; if If no adjustment is needed or the criteria are met after adjustment, then erasure coding gating is performed under the condition that the retrievability criteria are met: Define the erasure coding execution window length. It is determined by system deployment parameters or by taking the upper quantile value of the time consumption statistics of the most recent erasure coding task, and is mapped by a threshold mapping table. Find the gate threshold by version level L(v) With rollback probability cap When both conditions are met and Output the trigger result that allows erasure coding. Otherwise output The This serves as the input for step S4, which performs erasure coding and long-term storage format conversion.

[0020] Step S4: When the erasure coding gate is satisfied, perform erasure coding on the off-chain object to form an erasure coding object, and write the erasure coding result into the version registration contract; and when the cross-chain synchronization mode is in the final state and the final state synchronization gate is satisfied, write the final state reference record containing the version identifier, content summary and erasure coding commitment information into the target chain. This step outputs the erasure coding trigger result in step S3. Based on this, the long-term storage form conversion of off-chain objects and the final state solidification of cross-chain objects are synchronized, and key results are written on-chain for auditing and review. Specifically: when At that time, erasure coding is performed on the off-chain object O(v) and an erasure coding object is generated. Among them, the erasure coding object consists of the number of data fragments. With the number of encoded fragments The determined set of fragments constitutes the data fragment number. The number of coded segments is determined by a preset segmentation strategy, which is at least related to the size of the off-chain object, the size of a single segment target, and read concurrency constraints; In this implementation, an incremental determination method is used: First, the set of candidate fragment nodes is defined as follows. It is a set of off-chain storage nodes. The set of nodes that meet the fragment storage conditions, which include at least accessibility, sufficient storage capacity, and fault domain coverage constraints. Pre-screening; and the set of candidate fragment nodes. It must contain at least the current set of temporary copies. The nodes in the candidate fragment node set or their update results; subsequently, in the candidate fragment node set In the process, for each candidate node j, the lower bound of node availability confidence is obtained based on the probe. Based on this, a conservative availability representative value is constructed. As a feasible method, ; Then from Starting from increasing At each increment, calculate the minimum value that can be obtained under the conservative availability q(v). Probability of successful recovery of available fragments Its construction logic is at least If any fragment is available, it can be recovered, and can be obtained by summing the binomial distributions: Where s represents the number of encoded fragments. The number of segments that can be retrieved from each segment; And based on the final state retrievability threshold preset in step S4. As a stopping condition, From the threshold mapping table The threshold is found by version level L(v), and the higher the version level, the larger the threshold. When the first satisfaction Stop incrementing and output the above. As the result of the number of encoded fragments; then based on the number of data fragments With the number of encoded fragments Off-chain object O(v) performs erasure coding to generate a number of code fragments. Each fragment is then distributed and stored in a fragment node set. To reduce the associated failure risk, the selection of fragment nodes follows the same fault domain coverage constraint as step S2, that is, each fragment node is labeled with a fault domain identifier fd(j), and... The number of fault domains covered is not less than the preset coverage constraints. Simultaneously, the location information of each segment is used to form a segment location set. And calculate fragment summaries or fragment summary aggregate values. As a basis for consistency verification of erasure coding objects; after erasure coding is completed, a set of hot replicas may be optionally retained. Used for high-frequency access and emergency recovery, including the number of hot copies. The hot copy retention time is defined as follows: The value obtained from the version level lookup table is not less than 1. ,in The basic retention period, where η is the linkage coefficient; when the hot copy retention time is reached... Alternatively, hot copies can be recovered after random sampling shows that the retrievability of fragments is stable, thereby reducing long-term storage costs. Regarding on-chain recording, the erasure coding results and auditable information are written into the version registration contract of the first blockchain, including: erasure coding parameters, i.e., the number of data fragments. With the number of encoded fragments Fragment location set hash digest, fragment digest aggregate value and fragment node set The hash digest is used to verify the integrity and retrieval of erasure-coded objects; subsequently, in terms of cross-chain final state solidification synchronization, if the output mode(v) of step S1 is the final state and the current version event v satisfies the final state synchronization gate, the gate can reuse SCL(v) and the hash digest of the erasure-coded object. The determination rule is to write the final state reference record containing the version identifier, content digest H(v), and erasure coding commitment information into the target chain, so that the target chain can verify the content consistency and off-chain deliverability of the version; otherwise, maintain the temporary state reference and wait for the next round of gating to be satisfied before performing the final state solidification synchronization. Through the above steps, the off-chain object can be reproducibly converted from a temporary copy to an erasure coding long-term storage form, and on-chain verifiable registration consistent with the final state solidification of cross-chain objects can be completed.

[0021] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0022] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0023] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and inventive constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0024] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0025] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0026] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A blockchain-based multi-version collaborative management method for engineering design documents, characterized in that, Including the following steps: Obtain the chain state data of the version event on the blockchain, and calculate the settlement control quantity set based on the chain state data. The settlement control quantity set includes the lower bound of settlement confidence, time threshold and rollback probability function. Based on the settlement control quantity set and the version level of the version event, the initial number of temporary replicas and the initial set of temporary replicas of the off-chain object are determined, wherein the node selection of the initial set of temporary replicas satisfies the fault domain coverage constraint and is sorted according to the node availability score. According to the sampling interval and the number of samplings per round determined based on time threshold and version level, the initial temporary copy set is sampled to obtain the retrieval confidence index. The temporary retrieval threshold is dynamically calculated based on the remaining exposure window length and rollback probability. When the retrieval confidence index is lower than the temporary retrieval threshold, redundant replication adjustment is triggered to update the temporary copy set. When the off-chain object meets the preset long-term storage conversion conditions, it is determined whether erasure coding is allowed based on the settlement control quantity set and version level. If allowed, the number of data fragments is determined according to the size of the off-chain object. The number of encoded fragments is increased incrementally based on the availability confidence lower bound of the candidate fragment node set until the probability of successful recovery is not lower than the final state retrieval threshold. Then, the off-chain object is encoded into a number of encoded fragments and distributed and stored to the fragment node set to complete the long-term storage form conversion.

2. The blockchain-based multi-version collaborative management method for engineering design documents according to claim 1, characterized in that, The acquisition of the settlement control quantity set includes: collecting basic on-chain data related to the transactions corresponding to the version event, including the block height of the block in which the transaction is included and the current standard chain header block height; continuously recording chain rollback event samples within a preset statistical window to form a rollback event sample set, and recording the time required for the transaction to reach a settlement stable state to form a settlement time sample set; calculating the settlement depth index of the version event based on the collected on-chain data block height and the current standard chain header block height, wherein the settlement depth index is used to characterize the current stability of the version event on the chain, and for chains that do not provide a strong finality flag, the confirmation depth is used as the settlement depth index; The time taken to reach a stable settlement state is treated as a random variable. Based on the sample set of settlement time, the corresponding quantile of the random variable is calculated under a preset confidence level. This quantile is used as the time threshold for reaching a stable settlement state under the preset confidence level, thus obtaining the upper bound of the time for reaching a stable settlement state under the preset confidence level. The rollback event intensity is estimated based on the rollback event sample set to characterize the frequency of rollback events within a preset statistical window. The impact weight is estimated based on the rollback depth sample to characterize the impact of the rollback depth not being less than the settlement depth indicator. A rollback probability function with the time window length parameter as the independent variable is constructed in combination with the time window length parameter to represent the probability of an impactful rollback occurring within the preset time window length, thereby obtaining the rollback probability within the preset time window. Based on the obtained time threshold and the rollback probability function represented by the time window length parameter, a combination result of the lower bound of time confidence and the lower bound of non-rollback confidence is obtained. The combination result is used as the lower bound of settlement confidence output to form a set of settlement control quantities.

3. The blockchain-based multi-version collaborative management method for engineering design documents according to claim 2, characterized in that, After forming the settlement control set, it also includes: a rollback probability function with the time window length parameter as the independent variable and a synchronization execution window length for determining the cross-chain synchronization mode; wherein the synchronization execution window length is used to calculate the rollback probability within the synchronization execution window; based on a pre-stored threshold mapping table, the version level is mapped to a synchronization confidence threshold and a rollback probability upper limit. When the lower bound of the settlement confidence is greater than or equal to the synchronization confidence threshold and the rollback probability within the synchronization execution window length is less than or equal to the rollback probability upper limit, the cross-chain synchronization mode is determined to be the final state; otherwise, it is determined to be the temporary state.

4. The blockchain-based multi-version collaborative management method for engineering design documents according to claim 3, characterized in that, Determining the initial number of temporary replicas for off-chain objects includes: using the obtained time threshold as the upper bound of the temporary exposure period, defining the temporary exposure window length, and taking the temporary exposure window length as the sum of the time threshold and the synchronous execution window length; calculating the rollback probability within the temporary exposure window; pre-storing a replica parameter mapping table, which uses version level as an index to provide the basic number of replicas and incremental rules related to the exposure time level and rollback risk level; mapping the time threshold to the exposure time level; mapping the rollback probability result within the temporary exposure window to the rollback risk level; and taking the higher of the exposure time level and the rollback risk level as the overall level; and pre-setting the exposure. The time threshold sequence and rollback risk threshold sequence are defined, where the exposure time level and rollback risk level are determined by the time threshold and the index of the interval where the rollback probability result within the temporary exposure window lies, respectively. The initial number of temporary replicas is obtained by looking up a table using the base replica count and the overall level. The replica parameter mapping table satisfies a monotonic constraint: when the version level is fixed, as the exposure time level falling within the time threshold increases, the initial number of temporary replicas given by the replica parameter mapping table does not decrease; when the version level and exposure time level are fixed, as the rollback risk level falling within the temporary exposure window increases, the initial number of temporary replicas given by the replica parameter mapping table does not decrease.

5. The blockchain-based multi-version collaborative management method for engineering design documents according to claim 1, characterized in that, Determining the initial temporary replica set includes: dividing the off-chain storage node set according to fault domain identifiers, where fault domain identifiers include at least one or a combination of organizational domains, regional domains, or cloud service domains; determining the number of fault domains to be covered from pre-stored fault domain coverage constraint parameters based on version level, ensuring that the initial temporary replica set covers no less than the number of fault domains to be covered; performing pull probes on each storage node within a preset probe window for no less than a preset minimum number of probes, recording the number of successful probes and the total number of probes, and calculating the node availability score, where the node availability score is the probe success rate; sorting candidate nodes from high to low according to their node availability scores, and selecting nodes sequentially by prioritizing the coverage of uncovered fault domains, until the initial temporary replica set is reached and the corresponding fault domain coverage constraint is satisfied, with the selected node set serving as the initial temporary replica set.

6. The blockchain-based multi-version collaborative management method for engineering design documents according to claim 1, characterized in that, The redundant replication adjustment process includes: when the retrievability confidence index is lower than the temporary retrievability threshold, selecting nodes to be expanded from the candidate storage node set, performing pull probes on each candidate node for no less than the minimum number of probes within a preset probe window, recording the number of successful probes and the total number of probes, and using the same confidence lower bound calculation function as the sampling to obtain the availability confidence lower bound of each candidate node; using the node availability confidence lower bound as the sorting basis and combined with the fault domain coverage constraint, selecting candidate nodes in sequence according to the priority of covering uncovered fault domains and adding them to the temporary replica set, copying off-chain objects to the new nodes and completing the write confirmation, until the redundancy replication adjustment stops when at least one conservative probability of retrievability constructed by the complement of the product of the unretrievable probabilities of each node is not lower than the preset conservative threshold.

7. The blockchain-based multi-version collaborative management method for engineering design documents according to claim 1, characterized in that, The retrieveability confidence index is obtained by: mapping version level and time threshold to sampling interval and number of sampling rounds according to a pre-stored sampling parameter mapping table; selecting nodes from the current temporary replica set according to preset sampling rules to pull off-chain objects within each sampling cycle; performing consistency verification on the pulled content using the content digest registered on-chain; counting the number of successful pulls and the total number of sampling rounds; calculating the success rate confidence lower bound based on the sampling success rate using the confidence lower bound calculation function and its confidence parameters; and using the success rate confidence lower bound as the retrieveability confidence index. Simultaneously, the basic retrieveability threshold is retrieved from the threshold mapping table according to the version level; the remaining exposure window length is calculated based on the difference between the time threshold and the elapsed time; the rollback probability within the remaining window is calculated using the rollback probability function; and the basic retrieveability threshold is adjusted by combining the rollback risk gain coefficient to obtain a temporary retrieveability threshold that dynamically changes with the remaining exposure window length and rollback probability.

8. The blockchain-based multi-version collaborative management method for engineering design documents according to claim 1, characterized in that, The preset long-term storage conversion conditions include erasure coding gating conditions. The erasure coding gating conditions include: defining the erasure coding execution window length, and looking up the gating threshold and rollback probability upper limit from the threshold mapping table according to the version level. When the lower bound of the settlement confidence in the settlement control set is not lower than the gating threshold and the rollback probability within the erasure coding execution window length is not higher than the rollback probability upper limit, it is determined that erasure coding is allowed to be performed on the off-chain object; otherwise, the temporary copy form is maintained and the long-term storage form conversion is delayed.

9. The blockchain-based multi-version collaborative management method for engineering design documents according to claim 1, characterized in that, Determining the number of data fragments based on the size of the off-chain object includes: dividing the off-chain object into multiple data fragments according to a partitioning strategy, wherein the partitioning strategy is at least related to the size of the off-chain object, the target size of a single fragment, and read concurrency constraints, in order to determine the number of data fragments.

10. The blockchain-based multi-version collaborative management method for engineering design documents according to claim 1, characterized in that, The process of increasing the number of encoded fragments based on the availability confidence lower bound of the candidate fragment node set until the probability of successful recovery is not less than the final state retrieval threshold includes: performing pull probes on each candidate node in the candidate fragment node set within a preset probe window and recording the number of successful probes and the total number of probes; using a confidence lower bound calculation function to obtain the availability confidence lower bound of each candidate node; and using the minimum value of the availability confidence lower bound as the conservative availability representative value of fragment storage; as the number of encoded fragments increases from the number of data fragments, at each increase, based on the conservative availability representative value and using a binomial distribution model, calculating the probability of successful recovery of fragments with a availability of not less than the number of data fragments. The success probability is calculated, and the final state retrieval threshold obtained from the threshold mapping table according to the version level is used as the stopping condition. When the success probability of recovery is not lower than the final state retrieval threshold for the first time, the current number of encoded fragments is determined. Storage nodes are selected for each encoded fragment in the fragment node set according to the fault domain coverage constraint. A fragment location set and its hash digest, fragment digest aggregation value and hash digest of the fragment node set are generated. The number of data fragments, the number of encoded fragments and the hash digest are written into the version registration contract of the first blockchain. At least one hot copy of the off-chain object is retained according to the version level and a corresponding retention time is set. The hot copy is recycled after the retention time is reached.

Images