A distributed sharding integration method and system based on blockchain authorized credentials

Abstract

This invention relates to the fields of blockchain and distributed storage technology, specifically a distributed sharding integration method and system based on blockchain authorization credentials. It includes: a blockchain network issuing a sub-authorization credential bound to a shard number for each shard; subsequent shard sub-authorization credentials using the verification result of the previous shard as the on-chain activation condition, forming a chain-like unlocking structure; an integration node using the activated sub-authorization credential to retrieve shard data from the corresponding distributed storage node; the integration node submitting the hash value of the received shard data to the on-chain verification contract; the distributed storage node directly pushing the hash value independently calculated when issuing the shard data to the independent verification node; the on-chain verification contract and the independent verification node independently comparing the hash with the on-chain notarized hash; and attributing the difference between the two comparison results to storage node anomalies or transmission corruption; after all shards pass verification, the shards are concatenated to generate an integrated credential for on-chain notarization.

Description

Technical Field

[0001] This invention relates to the fields of blockchain and distributed storage technology, specifically to a distributed sharding integration method and system based on blockchain authorization credentials. Background Technology

[0002] With the increasing popularity of distributed storage for large files, the secure integration of file shards has become a core aspect of data management. The immutability of blockchain technology and the automatic execution of smart contracts provide a new technical path for the trusted control of shard integration.

[0003] In existing technologies, sharding consolidation schemes generally employ file-level authorization credentials. A single credential authorizes access to all shards; if this credential is leaked, all shards are at risk, and fine-grained access control for individual shards is impossible. In the shard verification phase, existing schemes typically rely on the consolidation node to perform hash comparisons unilaterally. Verification results lack independence; when anomalies are detected, only a retransmission mechanism is triggered, unable to distinguish whether the anomaly originates from data tampering on storage nodes, transmission corruption, or consolidation errors on the consolidation node. Attribution of responsibility relies entirely on manual post-event analysis, lacking on-chain automated adjudication capabilities. These shortcomings result in significant deficiencies in security, reliability, and liability determination in existing sharding consolidation schemes, failing to meet the sharding consolidation requirements of high-security scenarios. Summary of the Invention

[0004] This invention provides a distributed sharding integration method and system based on blockchain authorization credentials, which realizes fine-grained authorization control at the shard level and automatic attribution and adjudication of anomalies in the integration process.

[0005] To achieve the above objectives, the present invention provides the following technical solution: This invention provides a distributed sharding integration method based on blockchain authorization credentials, comprising: S1: Verify the identity of the requester and the integrity of the on-chain shard evidence. After verification, the blockchain network issues a sub-authorization certificate for each shard, which is bound to its shard number. The sub-authorization certificates of subsequent shards are activated on the chain based on the pull verification result of the previous shard, forming a chain unlocking structure. S2: The consolidation node, holding the activated sub-authorization credential, initiates a retrieval request to the corresponding distributed storage node. After verifying the validity of the sub-authorization credential, the distributed storage node returns the corresponding fragment data. S3: The integration node submits the hash value of the received shard data to the on-chain verification contract. The distributed storage node pushes the hash value calculated independently when sending the shard data directly to the independent verification node. The on-chain verification contract and the independent verification node independently compare the hash with the on-chain evidence storage hash. The anomaly is attributed based on the difference between the two comparison results. The comparison results and attribution conclusions are written to the blockchain. S4: After all shard data passes verification, the data is assembled in shard number order. The total hash of the file is calculated and compared with the total hash of the original file on the chain. If the comparison is successful, an integration completion certificate is generated and stored on the chain. If the comparison fails, it is attributed to an incorrect assembly order. The attribution result is written to the blockchain and triggers a reassembly process.

[0006] As a preferred embodiment of the present invention, in S1, the step of verifying the identity of the requester and the integrity of the on-chain sharded evidence storage includes: Obtain and integrate the task storage records corresponding to the request from the blockchain; The requester's address is compared and verified with the authorized address in the task's evidence record; Verify the continuity of shard numbers and the integrity of shard hashes recorded on the chain one by one; Once the requester's address verification and fragmented evidence integrity verification are both passed, the sub-authorization credential issuance process is triggered.

[0007] As a preferred embodiment of the present invention, in S1, the sub-license certificate includes: Segment numbering; The address of the distributed storage node bound to the shard number; Blockchain network signature; An activation status identifier, which is updated by the smart contract based on the verification results of the previous shard.

[0008] As a preferred embodiment of the present invention, in S1, the chain-like unlocking structure includes: The first shard's sub-authorization credential is activated directly after the requester's identity and the integrity of the on-chain shard evidence are verified. The sub-authorization credentials of subsequent shards are activated by the smart contract after the hash value of the previous shard data is compared by both the on-chain verification contract and the independent verification node and the hash of the on-chain evidence storage. If the previous shard is attributed to transmission corruption, the integration node re-initiates a retrieval request to the distributed storage node bound to the previous shard. After the distributed storage node returns the shard data, the integration node re-submits the hash value of the received shard data to the on-chain verification contract. The distributed storage node then pushes the hash value calculated independently when sending the shard data to the independent verification node. Both parties re-compare the hash value with the on-chain notarized hash independently. If the re-compare result is still attributed to transmission corruption, the activation process of the sub-authorization certificate for the subsequent shard is terminated, and the termination record is written to the blockchain. If the previous shard is attributed to a storage node abnormality, the activation process of the sub-authorization credential for the subsequent shard will be terminated, and the termination record will be written to the blockchain.

[0009] As a preferred embodiment of the present invention, in S2, the step of the distributed storage node verifying the validity of the sub-authorization credential includes: Query the blockchain to confirm the activation status of the sub-authorization credential and verify that it is activated. Verify that the distributed storage node address in the sub-authorization credential matches the distributed storage node address that received the retrieval request; After successful verification, the fragment data bound to the fragment number in the sub-authorization credential is returned; Upon completion, the activation status of the sub-authorization credential will be updated to "used" and written to the blockchain.

[0010] As a preferred technical solution of the present invention, in S3, before the integration node submits the hash value of the received sharded data to the on-chain verification contract, it also includes a step of pre-verifying the sharded data to be submitted based on the sharded Merkle tree pre-stored in the blockchain: The sharded Merkle tree is written to the blockchain during the file upload phase; The integration node calculates the subtree path of the shard data to be submitted in the Merkle tree of the shard and compares it with the corresponding level hash on the chain; After the comparison is successful, the integration node submits the hash value to be submitted to the on-chain verification contract, and the distributed storage node synchronously pushes the independently calculated hash value to the independent verification node. If the comparison fails, the fragment data of the hash value to be submitted is identified as an abnormal fragment and a retransmission is triggered. The retransmission result is written to the blockchain.

[0011] As a preferred embodiment of the present invention, in S3, the step of the distributed storage node directly pushing the hash value calculated independently when issuing fragmented data to the independent verification node includes: Before retrieving sharded data, the smart contract specifies an independent verification node and writes the address of the independent verification node, the hash submission time limit of the integration node, and the hash push time limit of the distributed storage node into the blockchain. Before returning the sharded data, the distributed storage node obtains the address of the independent verification node and the push time limit from the blockchain. While sending fragmented data to the integration node, the distributed storage node independently calculates the hash value of the sent fragmented data and pushes it to the independent verification node via a link that does not go through the integration node. If the distributed storage node fails to complete the hash push within the push time limit, the smart contract records it as a push anomaly and writes it to the blockchain. If an integration node fails to submit the hash value of the sharded data within the hash submission deadline, the smart contract will record it as a submission exception and write it to the blockchain; Independent verification nodes obtain the on-chain evidence hash directly from the blockchain, independently compare the received hash value with the on-chain evidence hash, and write the comparison result directly into the blockchain without going through the integration node.

[0012] As a preferred embodiment of the present invention, in S3, the step of attributing the anomaly based on the difference between the two comparison results includes: If the comparison results from both parties are consistent and both match the on-chain evidence hash, the verification is deemed successful. If the comparison results of the two parties are consistent and neither matches the on-chain evidence hash, the reason is attributed to an abnormal storage node. If the comparison results are inconsistent, it is attributed to transmission corruption, that is, the fragmented data is corrupted during the transmission from the distributed storage node to the integration node.

[0013] As a preferred embodiment of the present invention, in S4, the integration completion certificate includes: Task number; Integration completed timestamp; Total hash comparison result of the file; Integrate node signatures; Summary of all attribution records for each segment; The integration completion certificate is generated by a smart contract and written into the blockchain, and is stored in association with the task evidence record stored in the blockchain.

[0014] This invention also proposes a distributed sharding integration system based on blockchain authorization credentials, comprising: The shard-level chain-based certificate issuance module is used to verify the identity of the requester and the integrity of the on-chain shard evidence. After verification, the blockchain network issues a sub-authorization certificate for each shard, which is bound to its shard number. Subsequent shard sub-authorization certificates use the pull verification result of the previous shard as the on-chain activation condition, forming a chain-based unlocking structure. The credential-driven shard retrieval module is used to integrate nodes that hold activated sub-authorization credentials to initiate retrieval requests to the corresponding distributed storage nodes. After verifying the validity of the sub-authorization credentials, the distributed storage nodes return the corresponding shard data. The dual-track attribution verification module is used to integrate the hash values ​​of the received shard data submitted by the nodes to the on-chain verification contract, and the hash values ​​calculated independently by the distributed storage nodes when sending shard data are directly pushed to the independent verification nodes. The on-chain verification contract and the independent verification nodes are independently compared with the on-chain evidence hash, and the anomalies are attributed based on the differences between the two comparison results. The comparison results and attribution conclusions are written to the blockchain. The sharding and evidence storage module is used to assemble all sharded data in shard number order after all sharded data has passed verification. It calculates the total hash of the file and compares it with the total hash of the original file on the chain. If the comparison is successful, it generates an integration completion certificate and stores it on the chain. If the comparison fails, it is attributed to an incorrect sharding order. The attribution result is written to the blockchain and triggers a re-sharding process.

[0015] The beneficial effects of this invention are: 1. This invention refines the granularity of credentials from the file level to the fragment level by issuing a sub-authorization credential bound to the fragment number for each fragment and forming a chain unlocking structure. At any given time, at most one credential is in an activated state, and the leakage of a single fragment credential does not affect the security of other fragments, thus fundamentally eliminating the security risk of the entire credential being exposed in existing file-level authorization schemes.

[0016] 2. This invention introduces an attribution mechanism that allows for independent comparison and cross-judgment between on-chain verification contracts and independent verification nodes. This transforms the attribution of responsibility for anomalies during the sharding and integration process from post-event manual analysis to automatic on-chain adjudication. The attribution results are tamper-proof, achieving accurate differentiation between storage node anomalies and transmission damage, and solidifying responsibility on-chain.

[0017] 3. This invention introduces a pre-verification step based on a fragmented Merkle tree before dual-track verification. This completes the initial integrity screening before fragmented data enters the dual-track verification process. Abnormal fragments can be located and retransmitted during the pre-verification stage, avoiding the introduction of damaged data into the dual-track verification process, thus improving the verification efficiency and the accuracy of anomaly handling in the integration process. Attached Figure Description

[0018] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a schematic diagram of a distributed sharding integration method based on blockchain authorization credentials according to the present invention; Figure 2 This is a schematic diagram of the structure of a distributed sharding integration system based on blockchain authorization credentials according to the present invention. Detailed Implementation

[0019] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0020] Example 1: As Figure 1 As shown, the present invention provides a distributed sharding integration method based on blockchain authorization credentials, comprising: S1: Verify the identity of the requester and the integrity of the on-chain shard evidence. After verification, the blockchain network issues a sub-authorization certificate for each shard, which is bound to its shard number. The sub-authorization certificates of subsequent shards are activated on the chain based on the pull verification result of the previous shard, forming a chain unlocking structure. Specifically, the integration node initiates an integration request to the blockchain network, carrying the task ID and the requester's address.

[0021] Furthermore, in S1, the steps of verifying the identity of the requester and the integrity of the on-chain sharded evidence storage include: Obtain and integrate the task storage records corresponding to the request from the blockchain; The requester's address is compared and verified with the authorized address in the task's evidence record; Verify the continuity of shard numbers and the integrity of shard hashes recorded on the chain one by one; Once the requester's address verification and fragmented evidence integrity verification are both passed, the sub-authorization credential issuance process is triggered.

[0022] Specifically, the blockchain network retrieves the corresponding task storage record from the blockchain based on the task ID, compares the requester's address with the authorized address in the task storage record, and if they match, the identity verification is successful; otherwise, the request is rejected. After successful identity verification, the blockchain network retrieves the shard number and shard hash of all shards from the task storage record, and verifies one by one whether the shard number is consecutively increasing from the starting number of the upload stage record without any omissions. At the same time, it verifies that the shard hash corresponding to each shard number exists and is not empty. If all verifications pass, the shard storage integrity verification is successful; otherwise, the request is rejected.

[0023] Further, in S1, the sub-authorization credential includes: Segment numbering; The address of the distributed storage node bound to the shard number; Blockchain network signature; An activation status identifier, which is updated by the smart contract based on the verification results of the previous shard.

[0024] Specifically, after identity verification and fragmented evidence integrity verification are both passed, the blockchain network uses the same private key as when the task evidence record was created to sign the fragment number and distributed storage node address using the ECDSA algorithm, generating a sub-authorization credential for each fragment number. Each sub-authorization credential contains the fragment number, the distributed storage node address bound to the fragment number, the aforementioned signature, and an activation status identifier. The activation status identifier can be one of four states: inactive, activated, used, or terminated, with an initial value of inactive. All sub-authorization credentials are stored on the blockchain indexed by the task ID and are uniformly maintained by the chain-unlocked smart contract. Both the integration node and the distributed storage node can verify the signature using the on-chain public key.

[0025] Furthermore, in S1, in the chain-like unlocking structure: The first shard's sub-authorization credential is activated directly after the requester's identity and the integrity of the on-chain shard evidence are verified. The sub-authorization credentials of subsequent shards are activated by the smart contract after the hash value of the previous shard data is compared by both the on-chain verification contract and the independent verification node and the hash of the on-chain evidence storage. If the previous shard is attributed to transmission corruption, the integration node re-initiates a retrieval request to the distributed storage node bound to the previous shard. After the distributed storage node returns the shard data, the integration node resubmits the hash value of the received shard data to the on-chain verification contract. The distributed storage node then pushes the hash value, which was independently calculated when sending the shard data, to the independent verification node. Both parties then independently compare the hash value with the on-chain notarized hash. If the re-comparison result still indicates transmission corruption, the activation process of the sub-authorization credential for the subsequent shard is terminated, and the termination record is written to the blockchain. If the previous shard is attributed to a storage node abnormality, the activation process of the sub-authorization credential for the subsequent shard will be terminated, and the termination record will be written to the blockchain.

[0026] Specifically, after the sub-authorization certificate is issued, the chain-unlocking smart contract directly sets the activation status flag of the sub-authorization certificate corresponding to shard number 1 to "activated" and writes the status change to the blockchain. For shard number N (N greater than 1), the chain-unlocking smart contract maintains a verification completion flag on the blockchain for shard number N-1, with an initial value of "incomplete". The chain-unlocking smart contract triggers activation judgment by listening to the write event of the comparison result between the on-chain verification contract and the independent verification node. When the comparison results of shard number N-1 have been written by both parties and match the on-chain notarization hash, the chain-unlocking smart contract sets the verification completion flag to "completed" and simultaneously sets the activation status flag of the sub-authorization certificate corresponding to shard number N to "activated" and writes it to the blockchain. When the shard numbered N-1 is attributed to a storage node anomaly, the chain unlock smart contract sets the activation status identifier of the sub-authorization credentials corresponding to shard numbered N and all subsequent shards to terminate in batches, writes the termination record to the blockchain with the task ID as the index, and terminates the chain unlock process; when the attribution is due to transmission corruption and the result of re-verification after retransmission is still attributed to transmission corruption, the chain unlock smart contract also sets the activation status identifier of the sub-authorization credentials corresponding to shard numbered N and all subsequent shards to terminate in batches, writes the termination record to the blockchain, and terminates the chain unlock process.

[0027] S2: The consolidation node, holding the activated sub-authorization credential, initiates a retrieval request to the corresponding distributed storage node. After verifying the validity of the sub-authorization credential, the distributed storage node returns the corresponding fragment data. Specifically, the integration node obtains a sub-authorization credential with an activation status of "activated" from the blockchain, and sends a retrieval request to the distributed storage node pointed to by the distributed storage node address field in the credential, carrying the sub-authorization credential.

[0028] Furthermore, in S2, the step of the distributed storage node verifying the validity of the sub-authorization credential includes: Query the blockchain to confirm the activation status of the sub-authorization credential and verify that it is activated. Verify that the distributed storage node address in the sub-authorization credential matches the distributed storage node address that received the retrieval request; After successful verification, the fragment data bound to the fragment number in the sub-authorization credential is returned; Upon completion, the activation status of the sub-authorization credential will be updated to "used" and written to the blockchain.

[0029] Specifically, upon receiving a retrieval request, the distributed storage node first verifies the blockchain network signature in the sub-authorization credential using its on-chain public key. If the signature verification passes, it queries the blockchain for the current activation status identifier of the sub-authorization credential to confirm it is activated. Next, it verifies that the distributed storage node address field in the sub-authorization credential matches its own address to prevent the credential from being forwarded to unbound nodes. Once all verifications pass, the distributed storage node returns the shard data bound to the shard number in the sub-authorization credential, updates the activation status identifier of the sub-authorization credential to "used," and writes it to the blockchain. Sub-authorization credentials in the "used" state will no longer accept any retrieval requests. If any verification step fails, the node refuses to return shard data and writes the rejection record to the blockchain.

[0030] S3: The integration node submits the hash value of the received shard data to the on-chain verification contract. The distributed storage node pushes the hash value calculated independently when sending the shard data directly to the independent verification node. The on-chain verification contract and the independent verification node independently compare the hash with the on-chain evidence storage hash. The anomaly is attributed based on the difference between the two comparison results. The comparison results and attribution conclusions are written to the blockchain. Specifically, after receiving the sharded data, the integration node performs a Merkle tree pre-verification on the sharded data before submitting the hash value. Once the pre-verification passes, the dual-track verification process is triggered.

[0031] Furthermore, in S3, before the integration node submits the hash value of the received shard data to the on-chain verification contract, it also includes a step of pre-verifying the shard data to be submitted based on the shard Merkle tree pre-stored in the blockchain: The sharded Merkle tree is written to the blockchain during the file upload phase; The integration node calculates the subtree path of the shard data to be submitted in the Merkle tree of the shard and compares it with the corresponding level hash on the chain; After the comparison is successful, the integration node submits the hash value to be submitted to the on-chain verification contract, and the distributed storage node synchronously pushes the independently calculated hash value to the independent verification node. If the comparison fails, the fragment data of the hash value to be submitted is identified as an abnormal fragment and a retransmission is triggered. The retransmission result is written to the blockchain.

[0032] Specifically, the integration node retrieves the sharded Merkle tree stored during the file upload phase from the blockchain. Using the received sharded data, it calculates its SHA-256 hash value as a leaf node and calculates it layer by layer along the Merkle tree to the root node, comparing the hash of each level along the path with the corresponding level hash in the on-chain Merkle tree. If all levels pass the comparison, the pre-verification passes, and the integration node synchronously submits the hash value of the sharded data to the on-chain verification contract. Simultaneously, the distributed storage node pushes its independently calculated hash value to the independent verification node, initiating a dual-track verification process. If any level fails the comparison, the shard is determined to be abnormal. The integration node re-initiates a request to the distributed storage node to retrieve the shard, and the retransmission and re-pre-verification results are written to the blockchain. When a retransmission is triggered due to a failed pre-verification, the hash push record of the corresponding independent verification node for this shard retrieval is marked as invalid by the smart contract and is not included in the attribution judgment.

[0033] Furthermore, in S3, the step of the distributed storage node directly pushing the hash value calculated independently when issuing fragmented data to the independent verification node includes: Before retrieving sharded data, the smart contract specifies an independent verification node and writes the address of the independent verification node, the hash submission time limit of the integration node, and the hash push time limit of the distributed storage node into the blockchain. Before returning the sharded data, the distributed storage node obtains the address of the independent verification node and the push time limit from the blockchain. While sending fragmented data to the integration node, the distributed storage node independently calculates the hash value of the sent fragmented data and pushes it to the independent verification node via a link that does not go through the integration node. If the distributed storage node fails to complete the hash push within the push time limit, the smart contract records it as a push anomaly and writes it to the blockchain. If an integration node fails to submit the hash value of the sharded data within the hash submission deadline, the smart contract will record it as a submission exception and write it to the blockchain; Independent verification nodes obtain the on-chain evidence hash directly from the blockchain, independently compare the received hash value with the on-chain evidence hash, and write the comparison result directly into the blockchain without going through the integration node.

[0034] Specifically, before retrieving sharded data, the smart contract randomly selects an independent verification node from the registered verification node pool. Its address, the hash submission deadline for the integration node, and the hash push deadline for the distributed storage node are written to the blockchain using the task ID and shard number as indexes. Simultaneously, the distributed storage node sends sharded data to the integration node, independently calculating the SHA-256 hash value for the sent sharded data. This hash value is then directly pushed to the independent verification node via a network link independent of the sharded data transmission link, bypassing the integration node to prevent tampering with the hash value. The smart contract monitors the push and submission deadlines; if the task is not completed within the timeout period, a corresponding exception is recorded and written to the blockchain. Upon receiving the hash value, the independent verification node directly reads the on-chain notarized hash corresponding to the shard number from the blockchain for comparison, and the comparison result is directly written to the blockchain.

[0035] Furthermore, in S3, the step of attributing the anomaly based on the difference between the two comparison results includes: If the comparison results from both parties are consistent and both match the on-chain evidence hash, the verification is deemed successful. If the comparison results of the two parties are consistent and neither matches the on-chain evidence hash, the reason is attributed to an abnormal storage node. If the comparison results are inconsistent, it is attributed to transmission corruption, that is, the fragmented data is corrupted during the transmission from the distributed storage node to the integration node.

[0036] Specifically, the on-chain attribution contract reads the comparison results written by the integration node and the comparison results directly written to the blockchain by the independent verification node from the on-chain verification contract. It then determines the attribution conclusion according to the aforementioned rules, and writes the attribution conclusion to the blockchain using the task ID and shard number as indexes. If neither party completes the writing of the comparison results within the specified time limit, the attribution contract records a timeout exception and writes it to the blockchain.

[0037] S4: After all shard data passes verification, the data is assembled in shard number order. The total hash of the file is calculated and compared with the total hash of the original file on the chain. If the comparison is successful, an integration completion certificate is generated and stored on the chain. If the comparison fails, it is attributed to an incorrect assembly order. The attribution result is written to the blockchain and triggers a reassembly process.

[0038] Specifically, after the attribution conclusions of all shards are verified, the integration node concatenates the data of each shard in ascending order of shard number, calculates the SHA-256 hash value of the concatenated file as the total hash of the file, and compares it with the total hash of the original file stored on the blockchain.

[0039] Furthermore, in S4, the integration completion certificate includes: Task number; Integration completed timestamp; Total hash comparison result of the file; Integrate node signatures; Summary of all attribution records for each segment; The integration completion certificate is generated by a smart contract and written into the blockchain, and is stored in association with the task evidence record stored in the blockchain.

[0040] Specifically, after the file total hash comparison passes, the smart contract generates an integration completion certificate, which includes the task number, integration completion timestamp, file total hash comparison result, ECDSA signature of the integration node for the above information, and a summary of all shard attribution conclusions read from the blockchain using the task ID as the index. The integration completion certificate is written to the blockchain using the task ID as the index and stored in association with the corresponding task notarization record. If the file total hash comparison fails, the smart contract records the attribution conclusion as an incorrect splicing order and writes it to the blockchain. At the same time, it clears the current splicing result, triggers the re-splicing process, and the integration node rereads the data of each shard in shard number order, splices it, and resubmits the file total hash comparison. The re-comparison result is then written to the blockchain.

[0041] In summary, this embodiment achieves fine-grained authorization control at the shard level through a chain-like unlocking structure, accurately distinguishes between transmission damage and storage node anomalies through a dual-track attribution verification mechanism, and writes all process operation records and attribution conclusions into the blockchain, ensuring the verifiability and traceability of the distributed sharding integration process.

[0042] Example 2: A video cloud storage platform undertakes the storage and distribution of high-definition film and television materials. The material files are distributed across multiple nodes using a segmented upload method. During the upload phase, the hashes of each segment, the total hash of the file, and the Merkle tree are stored on the blockchain. Because material retrieval involves copyright authorization control and the distributed storage across multiple nodes makes it difficult to attribute data anomalies, a method is adopted as follows... Figure 2 The present invention illustrates a distributed sharding integration system based on blockchain authorization credentials.

[0043] In a particular retrieval request, a 4K footage file approximately 2 hours long was divided into 100 fragments, distributed and stored across 5 distributed storage nodes. The consolidation node, carrying the task ID and the requester's address, initiated a consolidation request to the blockchain network. After verifying the requester's identity and the integrity of the fragment storage, the system issued sub-authorization certificates for each of the 100 fragments, forming a chain-like unlocking structure. The fragment certificate numbered 1 was directly activated, while the remaining 99 fragment certificates were initially inactive.

[0044] The integration node sequentially retrieves each shard using the activated credentials. Each shard, after being received, undergoes a Merkle tree pre-verification before entering a dual-track verification process. When retrieving the 37th shard, the hash value submitted by the integration node does not match the on-chain notarized hash, while the hash value received by the independent verification node matches the on-chain notarized hash. The inconsistency is attributed by the attribution contract to transmission corruption. The integration node then initiates a directed retransmission of the 37th shard. After the retransmission, both comparisons match the on-chain notarized hash, and the 37th shard passes verification. The chain-unlocking smart contract activates the sub-authorization credential for the 38th shard, and integration continues. When retrieving the 64th shard, both the integration node's and the independent verification node's comparisons do not match the on-chain notarized hash. The attribution contract attributes this to a storage node anomaly. The chain-unlocking smart contract then terminates the activation process for the 65th and all subsequent shards, writing the termination record to the blockchain. The platform then accurately locates the corresponding storage node for investigation and repair.

[0045] If the existing batch authorization integration scheme is adopted, 100 fragmented credentials are exposed simultaneously after the integration request is approved, posing a security risk of unauthorized replay of credentials. The transmission corruption of the 37th fragment and the storage node anomaly of the 64th fragment cannot be distinguished in terms of their origins. The platform needs to initiate a traversal retransmission investigation of all remaining fragments, generating a large number of invalid retrieval requests and failing to accurately locate the responsible node. This invention ensures that at most one credential is activated at any given time through a chain-like unlocking structure, effectively controlling the scope of authorization exposure. A dual-track attribution verification mechanism accurately attributes the 37th fragment to transmission corruption and triggers a targeted retransmission, and accurately attributes the 64th fragment to a storage node anomaly and immediately terminates the subsequent process, avoiding invalid retrieval of the remaining 36 fragments. All attribution records of abnormal events are written to the blockchain, providing a traceable on-chain basis for the platform's copyright preservation and liability determination.

[0046] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. 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 distributed sharding and integration method based on blockchain authorization credentials, characterized in that, include: S1: Verify the identity of the requester and the integrity of the on-chain shard evidence. After verification, the blockchain network issues a sub-authorization certificate for each shard, which is bound to its shard number. The sub-authorization certificates of subsequent shards are activated on the chain based on the pull verification result of the previous shard, forming a chain unlocking structure. S2: The consolidation node, holding the activated sub-authorization credential, initiates a retrieval request to the corresponding distributed storage node. After verifying the validity of the sub-authorization credential, the distributed storage node returns the corresponding fragment data. S3: The integration node submits the hash value of the received shard data to the on-chain verification contract. The distributed storage node pushes the hash value calculated independently when sending the shard data directly to the independent verification node. The on-chain verification contract and the independent verification node independently compare the hash with the on-chain evidence storage hash. The anomaly is attributed based on the difference between the two comparison results. The comparison results and attribution conclusions are written to the blockchain. S4: After all shard data passes verification, the data is assembled in shard number order. The total hash of the file is calculated and compared with the total hash of the original file on the chain. If the comparison is successful, an integration completion certificate is generated and stored on the chain. If the comparison fails, it is attributed to an incorrect assembly order. The attribution result is written to the blockchain and triggers a reassembly process.

2. The distributed sharding and integration method based on blockchain authorization credentials according to claim 1, characterized in that, In S1, the steps of verifying the identity of the requester and the integrity of the on-chain sharded evidence storage include: Obtain and integrate the task storage records corresponding to the request from the blockchain; The requester's address is compared and verified with the authorized address in the task's evidence record; Verify the continuity of shard numbers and the integrity of shard hashes recorded on the chain one by one; Once the requester's address verification and fragmented evidence integrity verification are both passed, the sub-authorization credential issuance process is triggered.

3. The distributed sharding and integration method based on blockchain authorization credentials according to claim 1, characterized in that, In S1, the sub-authorization credential includes: Segment numbering; The address of the distributed storage node bound to the shard number; Blockchain network signature; An activation status identifier, which is updated by the smart contract based on the verification results of the previous shard.

4. The distributed sharding and integration method based on blockchain authorization credentials according to claim 1, characterized in that, In S1, the chain-like unlocking structure includes: The first shard's sub-authorization credential is activated directly after the requester's identity and the integrity of the on-chain shard evidence are verified. The sub-authorization credentials of subsequent shards are activated by the smart contract after the hash value of the previous shard data is compared by both the on-chain verification contract and the independent verification node and the hash of the on-chain evidence storage. If the previous shard is attributed to transmission corruption, the integration node re-initiates a retrieval request to the distributed storage node bound to the previous shard. After the distributed storage node returns the shard data, the integration node re-submits the hash value of the received shard data to the on-chain verification contract. The distributed storage node then pushes the hash value calculated independently when sending the shard data to the independent verification node. Both parties re-compare the hash value with the on-chain notarized hash independently. If the re-compare result is still attributed to transmission corruption, the activation process of the sub-authorization certificate for the subsequent shard is terminated, and the termination record is written to the blockchain. If the previous shard is attributed to a storage node abnormality, the activation process of the sub-authorization credential for the subsequent shard will be terminated, and the termination record will be written to the blockchain.

5. The distributed sharding and integration method based on blockchain authorization credentials according to claim 1, characterized in that, In S2, the step of the distributed storage node verifying the validity of the sub-authorization credential includes: Query the blockchain to confirm the activation status of the sub-authorization credential and verify that it is activated. Verify that the distributed storage node address in the sub-authorization credential matches the distributed storage node address that received the retrieval request; After successful verification, the fragment data bound to the fragment number in the sub-authorization credential is returned; Upon completion, the activation status of the sub-authorization credential will be updated to "used" and written to the blockchain.

6. The distributed sharding and integration method based on blockchain authorization credentials according to claim 1, characterized in that, In S3, before the integration node submits the hash value of the received shard data to the on-chain verification contract, it also includes a step of pre-verifying the shard data to be submitted based on the shard Merkle tree pre-stored in the blockchain: The sharded Merkle tree is written to the blockchain during the file upload phase; The integration node calculates the subtree path of the shard data to be submitted in the Merkle tree of the shard and compares it with the corresponding level hash on the chain; After the comparison is successful, the integration node submits the hash value to be submitted to the on-chain verification contract, and the distributed storage node synchronously pushes the independently calculated hash value to the independent verification node. If the comparison fails, the fragment data of the hash value to be submitted is identified as an abnormal fragment and a retransmission is triggered. The retransmission result is written to the blockchain.

7. The distributed sharding and integration method based on blockchain authorization credentials according to claim 1, characterized in that, In S3, the step of the distributed storage node directly pushing the hash value calculated independently when issuing fragmented data to the independent verification node includes: Before retrieving sharded data, the smart contract specifies an independent verification node and writes the address of the independent verification node, the hash submission time limit of the integration node, and the hash push time limit of the distributed storage node into the blockchain. Before returning the sharded data, the distributed storage node obtains the address of the independent verification node and the push time limit from the blockchain. While sending fragmented data to the integration node, the distributed storage node independently calculates the hash value of the sent fragmented data and pushes it to the independent verification node via a link that does not go through the integration node. If the distributed storage node fails to complete the hash push within the push time limit, the smart contract records it as a push anomaly and writes it to the blockchain. If an integration node fails to submit the hash value of the sharded data within the hash submission deadline, the smart contract will record it as a submission exception and write it to the blockchain; Independent verification nodes obtain the on-chain evidence hash directly from the blockchain, independently compare the received hash value with the on-chain evidence hash, and write the comparison result directly into the blockchain without going through the integration node.

8. The distributed sharding and integration method based on blockchain authorization credentials according to claim 1, characterized in that, In S3, the step of attributing the anomaly based on the difference between the two comparison results includes: If the comparison results from both parties are consistent and both match the on-chain evidence hash, the verification is deemed successful. If the comparison results of the two parties are consistent and neither matches the on-chain evidence hash, the reason is attributed to an abnormal storage node. If the comparison results are inconsistent, it is attributed to transmission corruption, that is, the fragmented data is corrupted during the transmission from the distributed storage node to the integration node.

9. A distributed sharding and integration method based on blockchain authorization credentials according to claim 1, characterized in that, In S4, the integration completion certificate includes: Task number; Integration completed timestamp; Total hash comparison result of the file; Integrate node signatures; Summary of all attribution records for each segment; The integration completion certificate is generated by a smart contract and written into the blockchain, and is stored in association with the task evidence record stored in the blockchain.

10. A distributed sharding integration system based on blockchain authorization credentials, characterized in that, include: The shard-level chain-based certificate issuance module is used to verify the identity of the requester and the integrity of the on-chain shard evidence. After verification, the blockchain network issues a sub-authorization certificate for each shard, which is bound to its shard number. Subsequent shard sub-authorization certificates use the pull verification result of the previous shard as the on-chain activation condition, forming a chain-based unlocking structure. The credential-driven shard retrieval module is used to integrate nodes that hold activated sub-authorization credentials to initiate retrieval requests to the corresponding distributed storage nodes. After verifying the validity of the sub-authorization credentials, the distributed storage nodes return the corresponding shard data. The dual-track attribution verification module is used to integrate the hash values ​​of the received shard data submitted by the nodes to the on-chain verification contract, and the hash values ​​calculated independently by the distributed storage nodes when sending shard data are directly pushed to the independent verification nodes. The on-chain verification contract and the independent verification nodes are independently compared with the on-chain evidence hash, and the anomalies are attributed based on the differences between the two comparison results. The comparison results and attribution conclusions are written to the blockchain. The sharding and evidence storage module is used to assemble all sharded data in shard number order after all sharded data has passed verification. It calculates the total hash of the file and compares it with the total hash of the original file on the chain. If the comparison is successful, it generates an integration completion certificate and stores it on the chain. If the comparison fails, it is attributed to an incorrect sharding order. The attribution result is written to the blockchain and triggers a re-sharding process.

Images