Self-auditing method capable of being quickly verified in distributed storage

Abstract

The invention discloses a self-auditing method capable of quickly verifying in distributed storage, which comprises the following steps of: firstly, initializing a public parameter, signing an intelligent contract, and generating a public key and a private key; blocking and partitioning the file and generating corresponding labels and auditing auxiliary information, wherein the labels are sent to a storage service provider; the storage service provider verifies the label after receiving the label; the intelligent contract generates an auditing challenge and sends the auditing challenge to the storage service provider; the storage service provider starts self-auditing to generate corresponding evidence and verifies the evidence; and the user updates the data according to the virtual coordinates. Aiming at the efficiency and safety problems of data auditing in distributed storage, the homomorphic Hash technology is adopted, and the auditing efficiency of multiple dimensions is remarkably improved. And in consideration of the time sensitivity of the file, the method also supports rapid dynamic operation, so that the calculation overhead is greatly reduced. In addition, in order to enhance integration with the block chain, the self-auditing process and the consensus algorithm are seamlessly integrated.

Description

Technical Field

[0001] The present invention relates to distributed storage, self-auditing and data updating technology, and in particular to a self-auditing method capable of rapid verification in distributed storage. Background Art

[0002] Distributed storage refers to a storage architecture that stores data in multiple physical locations (usually different servers, nodes, or data centers). Each storage node stores a portion of the data, and they are connected through the network to form a unified storage system. At present, there are still some problems with distributed storage, such as the existing system model has security issues after the introduction of third-party auditors, low audit efficiency, and does not support block-level data updates.

[0003] The traditional distributed storage audit model has users, third-party auditors, and storage service providers. However, auditing through third-party auditors may lead to the leakage of user privacy. Therefore, self-auditing improves the security of the entire audit process by removing third-party auditors. Users generate (v,k+1,1)-configuration through SBIBD technology, which enables storage service providers to complete audits without third-party auditors. The specific construction process of SBIBD is as follows:

[0004] V = {0, 1, ..., v-1} is a set containing v elements, B = {B0, B1, ..., B b-1} is a set containing b elements, where B i T = {V, B} is a subset of V with length k. It is called a (b, v, r, k, λ)-configuration if the following conditions are met: For an element a in V, it appears in exactly r elements in B. For an element (a, b) in V, it appears in exactly λ elements in B. k < v, which means that no element in B contains all the elements of V.

[0005] For a (b,v,r,k,λ)-configuration, if k=r and b=v are satisfied, it is called a symmetric balanced incomplete block design, also known as a (v,k+1,λ)-configuration. The premise of this configuration is that bk=vr and r(k-1)=λ(v-1).

[0006] In traditional data updates, each update requires recalculating a large number of labels, which wastes a lot of computing resources. Virtual coordinates can greatly reduce computing overhead by unbinding labels from indexes.

[0007] In summary, existing self-auditing schemes face several challenges, as the inherent complexity of self-auditing usually requires additional computational and communication operations, resulting in increased overhead. Some schemes utilize techniques such as hash functions and two-phase commit to speed up verification, while others support batch auditing through polynomial commitments and document identifiers; in addition, label aggregation using RSA key encryption technology and prime hash functions is combined with a single-layer authentication mechanism for fast dynamic operations.

[0008] However, current self-auditing schemes are optimized for specific auditing stages. Strengthening each stage individually does not bring significant efficiency improvements. On the contrary, optimizing multiple stages simultaneously is expected to significantly improve auditing efficiency. However, not adopting a holistic optimization approach may aggravate computational and communication overheads. Summary of the invention

[0009] Purpose of the invention: The purpose of the present invention is to address the deficiencies in the prior art and to provide a self-auditing method that can be quickly verified in distributed storage.

[0010] Technical solution: A self-auditing method for quickly verifying distributed storage of the present invention comprises the following steps:

[0011] Step (1), initialize relevant public parameters according to the input security parameter λ, and at the same time, the user signs a relevant smart contract with the storage service provider to generate a (v, k+1, 1)-configuration table;

[0012] In which the user generates two multiplicative cyclic groups of order p (G1,G T ), select g from G1 as the generator, and generate the bilinear map e:G1×G1→G T ; and generating a homomorphic hash function H having homomorphic properties;

[0013] Step (2), the user first generates a private key α← R Z P and x← R Z p , and then use the private key α to generate the public key y = g α , use the private key x to generate a homomorphic tag, and then broadcast the obtained public and private keys to all storage service providers;

[0014] Step (3): The user divides the file into n file blocks, each file block m i Each is divided into multiple sectors m i,j , and generate the corresponding homomorphic label σ i,j and audit auxiliary information, and send the file blocks and corresponding homomorphic tags to the corresponding storage service provider;

[0015] Step (4), the storage service provider verifies the received file blocks and homomorphic tags, and stores them after verification;

[0016] Step (5), the smart contract generates challenge information Ω based on the number of file blocks and other information, and sends it to the storage service provider, and then starts self-audit;

[0017] Step (6): After receiving the challenge information, the storage service provider generates corresponding evidence and completes the aggregation and rapid verification of evidence with other storage service providers. The specific method is as follows:

[0018] Step (6.1), Storage Service Provider SSP i After receiving the challenge information Ω, generate the corresponding evidence σ i and μ i ; After each storage service provider generates the corresponding evidence, it performs two rounds of interaction according to the (v,k+1,1)-configuration to generate the final evidence. The method is:

[0019] If j∈E i , SSP j I will put my part of the evidence (σ i ,μ i )Sent to SSP i , but because j∈E j , so SSP j No need to send proof to yourself. i After receiving k parts of evidence sent from other storage service providers, the intermediate evidence (P ij ,Γ ij ) is used to complete the final aggregation of evidence;

[0020] If i∈E j , SSP j The intermediate evidence (P ji, Γ ji )Sent to SSP i , will be passed through the intermediate evidence (P ij ,Γ ij ) Calculate the final evidence (P, Γ);

[0021] Step (6.2), the storage service provider obtains the complete evidence and verifies it;

[0022] Step (6.3), the storage service provider sends the verification result to the smart contract, and the smart contract uploads the result and challenge information to the blockchain to form an audit log;

[0023] Step (7), the user implements real-time update of data based on the virtual coordinate structure.

[0024] Furthermore, the detailed method of step (3) is as follows:

[0025] Step (3.1), the user will file m = ({m 1,1 ,...,m 1,s},...,{m n,1 ,...,m n,s}) is divided into n blocks in sequence, and each file block is divided into s sectors;

[0026] Step (3.2), user selects id← R Z P and w← R Z P To generate auxiliary information, the user initializes the virtual coordinate set VI = ({VI 1,1 ,...,VI 1,s},...,{VI n,1 ,...,VI n,s}), where each element is randomly assigned a value and the id will be used as the identifier of the file;

[0027] Step (3.3), for sector m i,j , the user generates the corresponding label σ through formula (1) i,j ;

[0028]

[0029] Step (3.4), for file block m i , the user will generate label verification information Can help storage service providers verify file block m i , i and j represent the index subscripts of the traversal;

[0030] In step (3.5), the user sends the file block and homomorphic label, label verification information, and virtual coordinate set information to the corresponding storage service provider and smart contract; at the same time, the user deletes the local file copy and only retains the virtual coordinate set for file update.

[0031] Furthermore, the specific process of step (4) is as follows:

[0032] Step (4.1), Storage Service Provider SSP i After receiving the file block and homomorphic label, label verification information, and virtual coordinate set information, calculate As auxiliary information for verifying the label, CS stands for SSP i The size of the received file chunk set;

[0033] Step (4.2), based on the information obtained in step (4.1), SSP i Verify the correctness of the received label using formula (2);

[0034]

[0035] Step (4.3), after verification, SSP i The file blocks and homomorphic tags, tag verification information and virtual coordinate sets are stored. If the verification fails, SSP i The data will be reported to the user as correct.

[0036] Furthermore, the specific process of generating the challenge in step (5) is as follows:

[0037] Step (5.1), based on the input challenge parameter c, the smart contract randomly selects c numbers from [1,n] to form a challenge index set I = {idx1,...,idx c}, and select a parameter for each element in I to form a parameter set Q = {q j} j∈I ,q j ← R Z P ;

[0038] Step (5.2), based on the result (I, Q), the smart contract will calculate As audit support information;

[0039] Step (5.3), the smart contract sends a challenge message Ω = {B, I, Q} to each storage service provider.

[0040] Furthermore, the specific process of aggregating and verifying the evidence in step (6) is as follows:

[0041] Storage Service Provider SSP i After receiving the challenge information Ω = {B, I, Q}, the corresponding evidence is generated by formulas (3) and (4);

[0042]

[0043] In the above formula, m iI[j] , Q[j] are intermediate variables used to verify data integrity;

[0044] When SSP i After receiving k parts of evidence sent from other storage service providers, use formulas (5) and (6) to calculate the intermediate evidence (P ij ,Γ ij ) is used to complete the final aggregation of evidence;

[0045]

[0046] The formula for calculating the final evidence (P, Γ) is as follows:

[0047]

[0048] When the storage service provider gets the complete evidence, calculate the intermediate variable Finally, the storage service provider will verify the evidence through formula (9);

[0049] e(P,g)=e(A*H(Γ)*H(w) B ,y)(9).

[0050] Furthermore, the specific process of data updating in step (7) is as follows:

[0051] Step (7.1), when the user needs to change m ij Modified to hour;

[0052] First the user calculates the new virtual coordinates Calculate new homomorphic labels using new virtual coordinates Then the user will Sent to the corresponding storage service provider, The storage service provider will verify the data after receiving it. If the verification is successful, the smart contract will receive a confirmation message. After receiving the confirmation message, the smart contract will store the data correctly. And send confirmation information to the user;

[0053] Step (7.2), when the user Insert into m ij and m ij+1 hour;

[0054] First the user calculates the new virtual coordinates Calculate new homomorphic labels using new virtual coordinates If you insert before the first sector Insert after the last sector The user will Sent to the corresponding storage service provider, The smart contract receives the data and the storage service provider verifies it. If the data is verified, the smart contract sends a confirmation message. After receiving the confirmation message, the smart contract stores the data correctly. And send confirmation information to the user;

[0055] Step (7.3), the user wants to delete m ij hour;

[0056] The user will send index information to the storage service provider and the smart contract; when the storage service provider deletes the corresponding files and tags, it will send a confirmation message to the smart contract and the user; after receiving the confirmation message, the smart contract will delete the corresponding virtual index information and send a confirmation message to DO; after the deletion is completed, all subsequent blocks and virtual indexes must move forward.

[0057] Beneficial effects: Compared with the prior art, the present invention has the following advantages

[0058] (1) To solve the inefficiency problem of current self-auditing solutions, the present invention uses homomorphic hashing technology to implement batch auditing, allowing users to audit multiple files with minimal resource consumption; at the same time, it realizes label aggregation and fast verification to improve audit efficiency and reduce computational overhead.

[0059] (2) To perform label recalculation in dynamic operations, the present invention implements fast dynamic operations by using a virtual index structure, allowing dynamic operations to be performed without recalculating a large number of labels, thereby significantly reducing computational overhead. In addition, the present invention can be applied to blockchain storage and integrated with consensus algorithms to improve versatility.

[0060] (3) The present invention is the first to publicly propose a solution for distributed storage self-auditing. Through security analysis and experimental evaluation, the present invention has higher security and lower communication and computing costs compared with other solutions. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Figure 1 It is a system model diagram of the present invention;

[0062] Figure 2 A flowchart of evidence aggregation in step (6) of the present invention;

[0063] Figure 3 An efficiency graph of label generation according to an embodiment of the present invention;

[0064] Figure 4 This is an efficiency diagram of label verification in one embodiment of the present invention;

[0065] Figure 5 An efficiency diagram of evidence generation in one embodiment of the present invention;

[0066] Figure 6 This is an efficiency diagram of evidence verification in one embodiment of the present invention. DETAILED DESCRIPTION

[0067] The technical solution of the present invention is described in detail below, but the protection scope of the present invention is not limited to the embodiments.

[0068] like Figure 1As shown, the present invention mainly involves three entities, namely, users, smart contracts, and storage service providers. At present, most distributed storage systems have introduced third-party auditors or audit organizers, who are responsible for sending audit requests, distributing files, aggregating evidence, etc. However, third-party auditors may be curious about the user's information, resulting in privacy leakage.

[0069] To solve the defects of the prior art, the present invention uses SBIBD technology to achieve self-auditing, but self-auditing requires two rounds of interaction. Therefore, the present invention also uses homomorphic hashing technology to achieve batch auditing, which can audit multiple files at a time. At the same time, the present invention also improves the verification speed, aggregates a large amount of repeated information together for verification, and greatly improves the audit efficiency; even more, in order to support fast dynamic operations, the present invention also designs an efficient virtual coordinate structure to manage label index changes and avoid label recalculation.

[0070] To facilitate understanding of the technical solution, here we first introduce the (v,k+1,1)-configuration configuration to implement the self-audit process, where v = k ∧2 +k+1, k is a prime number.

[0071] First, according to formulas (10) and (11), construct B = {B0, B1, ..., B b-1}, where |B i |=k+1,B ij Indicates B i The j-th element of .

[0072]

[0073] We get B = {B0, B1, ..., B b-1}, according to formula (12), construct E={E0,E1,...,E b-1}, In the self-audit, storage service providers need to interact based on E.

[0074]

[0075] The present invention provides a (7,3,1)-configuration according to the above algorithm, as shown in Table 1.

[0076] Table 1

[0077]

[0078]

[0079] A homomorphic hash function is a homomorphic hash function that satisfies the following properties, which can greatly improve the efficiency of auditing. A homomorphic hash function is homomorphic and unforgeable.

[0080] The homomorphism means that for two messages (A, B) and parameters (α, β), it must satisfy: H(αA+βB)=H(A) α *H(B) β .

[0081] The unforgeability property means that there is no algorithm with polynomial time complexity that can forge (A, B, C, α, β) satisfying the following conditions: C! = αA + βB and H(C) = H(A) α *H(B) β .

[0082] In order to facilitate the understanding of the technical solution of this embodiment, the meanings of the relevant variables are explained, and the specific contents are shown in Table 2.

[0083] Table 2

[0084]

[0085]

[0086] The self-auditing method for distributed storage that can be quickly verified in this embodiment includes the following steps:

[0087] Step (1), initialize relevant public parameters according to the input security parameter λ, and the user signs a relevant smart contract with the storage service provider to generate a (v, k+1, 1)-configuration;

[0088] In which the user generates two multiplicative cyclic groups of order p (G1,G T ), select g from G1 as the generator, and generate the bilinear map e:G1×G1→G T ; and generating a homomorphic hash function H having homomorphic properties;

[0089] Step (2), the user first generates a private key α← R Z P and x← R Z p , and then use the private key α to generate the public key y = g α , use the private key x to generate a homomorphic tag, and then broadcast the obtained public and private keys to all storage service providers;

[0090] Step (3): The user divides the file into n file blocks, each file block m i Each is divided into multiple sectors m i,j , and generate the corresponding homomorphic label σ i,j and audit auxiliary information, and send the file blocks and corresponding homomorphic tags to the corresponding storage service provider;

[0091] Step (4), the storage service provider verifies the received file blocks and homomorphic tags, and stores them after verification;

[0092] Step (5), the smart contract generates challenge information Ω based on the number of file blocks and other information, and sends it to the storage service provider, and then starts self-audit;

[0093] Step (6): After receiving the challenge information, the storage service provider generates corresponding evidence and completes the aggregation and rapid verification of evidence with other storage service providers. The specific method is as follows:

[0094] Step (6.1), Storage Service Provider SSP i After receiving the challenge information Ω, generate the corresponding evidence σ i and μ i ; After each storage service provider generates the corresponding evidence, it performs two rounds of interaction according to the (v,k+1,1)-configuration to generate the final evidence. The method is:

[0095] If j∈E i , SSP j I will put my part of the evidence (σ i ,μ i )Sent to SSP i , when SSP i After receiving k parts of evidence sent from other storage service providers, the intermediate evidence (P ij ,Γ ij ) is used to complete the final aggregation of evidence;

[0096] If i∈E j , SSP j The intermediate evidence (P ji, Γ ji )Sent to SSP i , will be passed through the intermediate evidence (P ij ,Γ ij ) Calculate the final evidence (P, Γ);

[0097] Step (6.2), the storage service provider obtains the complete evidence and verifies it;

[0098] Step (6.3), the storage service provider sends the verification result to the smart contract, and the smart contract uploads the result and challenge information to the blockchain to form an audit log;

[0099] Step (7), the user implements real-time update of data based on the virtual coordinate structure.

[0100] Furthermore, the detailed method of step (3) is:

[0101] Step (3.1), the user will file m = ({m 1,1 ,...,m 1,s},...,{m n,1 ,...,m n,s}) is divided into n blocks in sequence, and each file block is divided into s sectors;

[0102] Step (3.2), user selects id← R Z P and w← R Z P To generate auxiliary information, the user initializes the virtual coordinate set VI = ({VI 1,1 ,...,VI 1,s},...,{VI n,1 ,...,VI n,s}), where each element is randomly assigned a value and the id will be used as the identifier of the file;

[0103] Step (3.3), for sector m i,j , the user generates the corresponding label σ through formula (1) i,j ;

[0104]

[0105] Step (3.4), for file block m i , the user will generate label verification information Can help storage service providers verify file block m i , i and j represent the index subscripts of the traversal;

[0106] In step (3.5), the user sends the file block and homomorphic label, label verification information, and virtual coordinate set information to the corresponding storage service provider and smart contract; at the same time, the user deletes the local file copy and only retains the virtual coordinate set for file update.

[0107] Furthermore, the specific process of step (4) is as follows:

[0108] Step (4.1), Storage Service Provider SSP i After receiving the file block and homomorphic label, label verification information, and virtual coordinate set information, calculate As auxiliary information for verifying the label, CS stands for SSP i The size of the received file chunk set;

[0109] Step (4.2), based on the information obtained in step (4.1), SSP iVerify the correctness of the received label using formula (2);

[0110]

[0111] Step (4.3), after verification, SSP i The file blocks and homomorphic tags, tag verification information and virtual coordinate sets are stored. If the verification fails, SSP i The data will be reported to the user as correct.

[0112] Furthermore, the specific process of generating the challenge in step (5) is as follows:

[0113] Step (5.1), based on the input challenge parameter c, the smart contract randomly selects c numbers from [1,n] to form a challenge index set I = {idx1,...,idx c}, and select a parameter for each element in I to form a parameter set Q = {q j} j∈I ,q j ← R Z P ;

[0114] Step (5.2), based on the result (I, Q), the smart contract will calculate As audit support information;

[0115] Step (5.3), the smart contract sends a challenge message Ω = {B, I, Q} to each storage service provider.

[0116] Furthermore, the specific process of aggregating and verifying the evidence in step (6) is as follows:

[0117] Storage Service Provider SSP i After receiving the challenge information Ω = {B, I, Q}, the corresponding evidence is generated by formulas (3) and (4);

[0118]

[0119] In the above formula, m iI[j] , Q[j] are intermediate variables used to verify data integrity;

[0120] When SSP i After receiving k parts of evidence sent from other storage service providers, use formulas (5) and (6) to calculate the intermediate evidence (P ij ,Γ ij ) is used to complete the final aggregation of evidence;

[0121]

[0122]

[0123] The formula for calculating the final evidence (P, Γ) is as follows:

[0124]

[0125] When the storage service provider gets the complete evidence, calculate the intermediate variable Finally, the storage service provider will verify the evidence through formula (9);

[0126] e(P,g)=e(A*H(Γ)*H(w) B ,y)(9).

[0127] Furthermore, the specific process of data updating in step (7) is as follows:

[0128] Step (7.1), when the user needs to change m ij Modified to hour;

[0129] First the user calculates the new virtual coordinates Calculate new homomorphic labels using new virtual coordinates Then the user will Sent to the corresponding storage service provider, The storage service provider will verify the data after receiving it. If the verification is successful, the smart contract will receive a confirmation message. After receiving the confirmation message, the smart contract will store the data correctly. And send confirmation information to the user;

[0130] Step (7.2), when the user Insert into m ij and m ij+1 hour;

[0131] First the user calculates the new virtual coordinates Calculate new homomorphic labels using new virtual coordinates If you insert before the first sector Insert after the last sector The user will Sent to the corresponding storage service provider, The smart contract receives the data and the storage service provider verifies it. If the data is verified, the smart contract sends a confirmation message. After receiving the confirmation message, the smart contract stores the data correctly. And send confirmation information to the user;

[0132] Step (7.3), the user wants to delete m ij hour;

[0133] The user will send index information to the storage service provider and the smart contract; when the storage service provider deletes the corresponding files and tags, it will send a confirmation message to the smart contract and the user; after receiving the confirmation message, the smart contract will delete the corresponding virtual index information and send a confirmation message to DO; after the deletion is completed, all subsequent blocks and virtual indexes must move forward.

[0134] This embodiment runs on a virtual machine with a Windows operating system and 16GB RAM, and the host CPU is Core i5-8400. In addition, the number of storage service providers is 7, the number of sectors is 32, and the size of each sector is 32 bytes. Table 3 shows the time required for each operation.

[0135] Table 3

[0136] OP T(ms) <![CDATA[T mul ]]> 2.467 <![CDATA[T exp ]]> 11.56 <![CDATA[T pair ]]> 100.32 <![CDATA[H n ]]> 1.2 <![CDATA[T ap ]]> 1.5 <![CDATA[T mp ]]> 1.64 <![CDATA[T ep ]]> 2.56

[0137] Figure 3 The efficiency comparison between the present invention and other solutions in the label generation stage is shown in FIG. Figure 3 It can be seen that EPM is the most effective, and DASA is significantly less efficient, mainly due to its use of file encoding in data retrieval, but this practice will accelerate the expansion of tag counts. The present invention presents an intermediate efficiency, achieving a balance between the extremes of EPM and DASA.

[0138] In the tag verification phase, this embodiment only compares and analyzes the EPM and the present invention, because DASA does not have a corresponding algorithm. By utilizing the inherent tag aggregation characteristics of the present invention, the efficiency of the present invention exceeds the EPM manifold, showing an advantage of more than ten times. In addition, as the number of tags increases, this advantage is expected to be exponentially amplified. This trend is Figure 4 has been elucidated in .

[0139] In the evidence generation phase, EPM emerges as an efficiency paradigm that surpasses the present invention and DASA, e.g. Figure 5 As shown. However, it is worth noting that the computational overhead in EPM mainly depends on the number of replicas and challenge blocks retained in each storage service provider, while DASA and the present invention are mainly affected by the number of file blocks and challenge blocks contained in each storage service provider. When the number of replicas and file blocks is equal, the speed of the present invention and DASA is better than EPM. DASA requires a greater computational burden in proof generation, making it the least efficient.

[0140] During the verification phase, the present invention becomes the epitome of efficiency, e.g. Figure 6As shown. It is noteworthy that the present invention is characterized by a fast verification speed of only a few milliseconds. This is attributed to the ability of the present invention to aggregate a large amount of information during the verification phase, significantly improving the verification efficiency. In stark contrast, EPM requires tens of milliseconds, while DASA brings a heavier overhead, requiring hundreds of milliseconds for verification due to the lack of information aggregation.

Claims

1. A self-auditing method that can be quickly verified in distributed storage, characterized in that: The following steps are involved: Step (1), initialize relevant public parameters according to the input security parameter λ, and at the same time, the user signs a relevant smart contract with the storage service provider to generate a (v, k+1, 1)-configuration table; In which the user generates two multiplicative cyclic groups of order p (G1, G T ), select g from G1 as the generator, and generate the bilinear map e:G1×G1→G T ; and generating a homomorphic hash function H having homomorphic properties; Step (2), the user first generates a private key α← R Z P and x← R Z p , and then use the private key α to generate the public key y = g α , use the private key x to generate a homomorphic tag, and then broadcast the obtained public and private keys to all storage service providers; Step (3): The user divides the file into n file blocks, each file block m i Each is divided into multiple sectors m i,j , and generate the corresponding homomorphic label σ i,j and audit auxiliary information, and send the file blocks and corresponding homomorphic tags to the corresponding storage service provider; Step (4), the storage service provider verifies the received file blocks and homomorphic tags, and stores them after verification; Step (5), the smart contract generates challenge information Ω based on the number of file blocks and sends it to the storage service provider, and then starts self-audit; Step (6): After receiving the challenge information, the storage service provider generates corresponding evidence and completes the aggregation and rapid verification of evidence with other storage service providers. The specific method is as follows: Step (6.1), Storage Service Provider SSP i After receiving the challenge information Ω, generate the corresponding evidence σ i and μ i ; After each storage service provider generates the corresponding evidence, it performs two rounds of interaction according to the (v,k+1,1)-configuration to generate the final evidence. The method is: If j∈E i , SSP j I will put my part of the evidence (σ i ,μ i )Sent to SSP i , when SSP i After receiving k parts of evidence sent from other storage service providers, the intermediate evidence (P ij ,Γ ij ) is used to complete the final aggregation of evidence; If i∈E j , SSP j The intermediate evidence (P ji, Γ ji )Sent to SSP i , will be passed through the intermediate evidence (P ij ,Γ ij ) Calculate the final evidence (P, Γ); Step (6.2), the storage service provider obtains the complete evidence and verifies it; Step (6.3), the storage service provider sends the verification result to the smart contract, and the smart contract uploads the result and challenge information to the blockchain to form an audit log; Step (7), the user implements real-time update of data based on the virtual coordinate structure.

2. The self-auditing method for distributed storage that can be quickly verified according to claim 1 is characterized in that: The detailed method of step (3) is as follows: Step (3.1), the user sets the file m = ({m 1,1 ,...,m 1,s },...,{m n,1 ,...,m n,s }) is divided into n blocks in sequence, and each file block is divided into s sectors; Step (3.2), user selects id← R Z P and w← R Z P To generate auxiliary information, the user initializes the virtual coordinate set VI = ({VI 1,1 ,...,VI 1,s },...,{VI n,1 ,...,VI n,s }), where each element is randomly assigned a value and the id will be used as the identifier of the file; Step (3.3), for sector m i,j , the user generates the corresponding label σ through formula (1) i,j ; Step (3.4), for file block m i , user-generated tag verification information Help storage service providers verify file chunk m i , i and j represent the index subscripts of the traversal; In step (3.5), the user sends the file block and homomorphic label, label verification information, and virtual coordinate set information to the corresponding storage service provider and smart contract; at the same time, the user deletes the local file copy and only retains the virtual coordinate set for file update.

3. The self-auditing method for distributed storage that can be quickly verified according to claim 1 is characterized in that: The specific process of step (4) is as follows: Step (4.1), Storage Service Provider SSP i After receiving the file block and homomorphic label, label verification information, and virtual coordinate set information, calculate Only as auxiliary information for verifying labels, CS stands for SSP i The size of the received file chunk set; Step (4.2), based on the information obtained in step (4.1), SSP i Verify the correctness of the received label using formula (2); Step (4.3), after verification, SSP i The file blocks and homomorphic tags, tag verification information and virtual coordinate sets are stored. If the verification fails, SSP i The data will be reported to the user as correct.

4. The self-auditing method for distributed storage that can be quickly verified according to claim 1 is characterized in that: The specific process of generating a challenge in step (5) is as follows: Step (5.1), based on the input challenge parameter c, the smart contract randomly selects c numbers from [1,n] to form a challenge index set I = {idx1,...,idx c }, and select a parameter for each element in I to form a parameter set Q = {q j } j∈I ,q j ← R Z P ; Step (5.2), based on the result (I,Q), the smart contract will calculate As audit support information; Step (5.3), the smart contract sends a challenge message Ω = {B, I, Q} to each storage service provider.

5. The self-auditing method for distributed storage that can be quickly verified according to claim 1 is characterized in that: The specific process of aggregating and verifying the evidence in step (6) is as follows: Storage Service Provider SSP i After receiving the challenge information Ω = {B, I, Q}, the corresponding evidence is generated by formulas (3) and (4); In the above formula, m iI[j] , Q[j] are intermediate variables used to verify data integrity; When SSP i After receiving k parts of evidence sent from other storage service providers, use formulas (5) and (6) to calculate the intermediate evidence (P ij ,Γ ij ) is used to complete the final aggregation of evidence; The formula for calculating the final evidence (P, Γ) is as follows: When the storage service provider gets the complete evidence, calculate the intermediate variable Finally, the storage service provider will verify the evidence through formula (9); e(P,g)=e(A*H(Γ)*H(w) B ,y) (9)。 6. The self-auditing method for distributed storage that can be quickly verified according to claim 1 is characterized in that: The specific process of data updating in step (7) is as follows: Step (7.1), when the user needs to change m ij Modified to hour; First the user calculates the new virtual coordinates Calculate new homomorphic labels using new virtual coordinates Then the user will Sent to the corresponding storage service provider, The storage service provider will verify the data after receiving it. If the verification is successful, the smart contract will receive a confirmation message. After receiving the confirmation message, the smart contract will store the data correctly. And send confirmation information to the user; Step (7.2), when the user Insert into m ij and m ij+1 hour; First the user calculates the new virtual coordinates Calculate new homomorphic labels using new virtual coordinates If you insert before the first sector Insert after the last sector The user will Sent to the corresponding storage service provider, The smart contract receives the data and the storage service provider verifies it. If the data is verified, the smart contract sends a confirmation message. After receiving the confirmation message, the smart contract stores the data correctly. And send confirmation information to the user; Step (7.3), the user wants to delete m ij hour; Users will send index information to storage service providers and smart contracts; When the storage service provider deletes the corresponding files and tags, it will send a confirmation message to the smart contract and the user; after receiving the confirmation message, the smart contract will delete the corresponding virtual index information and send a confirmation message to DO; After the deletion is complete, all subsequent blocks and virtual indexes must be moved forward.

Images