Blockchain-based distributed trusted data space construction method and system

Abstract

The application relates to the technical field of data processing, and discloses a distributed trusted data space construction method and system based on a block chain. The method comprises the following steps: a participant registers under the unique identifier of a data space by means of a digital identity certificate; a sharded block chain of the data space is dynamically created according to the unique identifier; the participant stores structured data in the corresponding sharded block chain after encryption, thereby obtaining a data block of the structured data; when a cross-sharded block chain data interaction request occurs, a cross-chain verification credential of the cross-sharded block chain is generated based on zero-knowledge proof; the data interaction of the sharded block chain is completed through the cross-chain verification credential, and an interaction audit record of the data interaction is generated; the state hash of the sharded block chain is periodically aggregated, and a global state snapshot under the unique identifier is updated; and the application can improve the security of a trusted data space.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and in particular to a distributed trusted data space construction method and system based on a blockchain. BACKGROUND

[0002] In the field of trusted data space construction, the prior art has obvious defects in the management of participant identities, lacks a distributed identity authentication mechanism based on a unified identifier, and thus the authenticity and uniqueness of participant identities are difficult to verify effectively, which may lead to risks of identity forgery or misuse and further impact the basic trustworthiness of the data space. Meanwhile, in the data storage link, the encryption and partition storage strategy for structured data is not perfect, and the data is vulnerable to security threats such as leakage and tampering due to centralized storage or insufficient encryption strength, which makes it difficult to ensure the security of the data itself.

[0003] In cross-regional data interaction and overall state management, the prior art also has limitations. The cross-shard or cross-system data interaction lacks an efficient verification means based on zero-knowledge proof, and the privacy and integrity of the data during the interaction process are difficult to balance, which may lead to data leakage or illegal tampering. In addition, the monitoring and updating mechanism for the overall state of the data space is insufficient, and lacks a periodic state hash aggregation and global snapshot updating strategy, which leads to poor overall consistency and traceability of the data space, and makes it difficult to discover and correct abnormal states in a timely manner, further reducing the security and reliability of the trusted data space. SUMMARY

[0004] The present application provides a distributed trusted data space construction method and system based on a blockchain, which mainly aims to solve the problem of low security of the trusted data space.

[0005] To achieve the above-mentioned purpose, the present application provides a distributed trusted data space construction method based on a blockchain, which comprises:

[0006] S1, a participant completes registration under a unique identifier of a data space through a digital identity certificate;

[0007] S2, a shard blockchain of the data space is dynamically created according to the unique identifier;

[0008] S3, the participant stores the structured data in the corresponding shard blockchain after encryption, and obtains a data block of the structured data;

[0009] S4, when a cross-shard blockchain data interaction request occurs, a cross-chain verification credential of the cross-shard blockchain is generated based on zero-knowledge proof;

[0010] S5, completing the data interaction of the sharded blockchain through the cross-chain verification credential, and generating an interaction audit record of the data interaction;

[0011] S6, periodically aggregating the state hash of the sharded blockchain and the interaction audit record, and updating a global state snapshot under the unique identifier.

[0012] In a preferred embodiment, the participant completes registration under the unique identifier of the data space through a digital identity credential, including:

[0013] defining the boundary of the data space and generating a unique identifier of the data space;

[0014] generating a distributed identity proof file of the participant through the unique identifier.

[0015] In a preferred embodiment, the data space sharded blockchain is dynamically created according to the unique identifier, including:

[0016] dividing the sharded blockchain of the data space based on the hash value of the unique identifier;

[0017] dynamically adjusting the number of nodes of the sharded blockchain according to real-time data load.

[0018] In a preferred embodiment, when a cross-sharded blockchain data interaction request occurs, the cross-chain verification credential of the cross-sharded blockchain is generated based on zero-knowledge proof, including:

[0019] generating an initial commitment value of zero-knowledge proof according to a data attribute set of the requester;

[0020] constructing a proof parameter of the cross-chain verification credential based on the initial commitment value;

[0021] inputting the proof parameter into a non-interactive proof protocol, and generating the cross-chain verification credential of the cross-sharded blockchain through a pre-defined cryptography rule in the non-interactive proof protocol.

[0022] In a preferred embodiment, the proof parameter of the cross-chain verification credential is constructed based on the initial commitment value, including:

[0023] generating a cryptography base parameter according to a pre-set elliptic curve base point and order parameter;

[0024] constructing an attribute binding vector according to the initial commitment value and a target shard identifier;

[0025] performing scalar multiplication operation on the attribute binding vector through a private key of the requester to generate a random number factor;

[0026] calculating an elliptic curve bilinear pair mapping value based on the cryptographic base parameter and the random number factor;

[0027] combining the bilinear pair mapping value and the attribute binding vector to form a proof parameter of the cross-chain verification credential.

[0028] In a preferred embodiment, the combination of the bilinear pair mapping value and the attribute binding vector forms the proof parameter, wherein the calculation formula of the proof parameter is as follows:

[0029]

[0030] In the formula, is the proof parameter, is a bilinear pair mapping function, is the private key, is the cryptographic base parameter, is an elliptic curve hash-to-point function, is the attribute binding vector.

[0031] In a preferred embodiment, the input of the proof parameter into the non-interactive proof protocol generates the cross-chain verification credential of the cross-shard blockchain through the pre-defined cryptographic rule in the non-interactive proof protocol, wherein the calculation formula of the cross-chain verification credential is as follows:

[0032]

[0033] In the formula, is the cross-chain verification credential, is a collision-resistant hash function, is the initial commitment value, is the proof parameter, is a concatenation operator, is a modulo operator, is the elliptic curve base point and order parameter.

[0034] In a preferred embodiment, the periodic aggregation of the state hash of the shard blockchain and the interaction audit record and the updating of the global state snapshot under the unique identifier include:

[0035] collecting the Merkle root hash value of the shard blockchain according to a preset period;

[0036] aggregating the Merkle root hash value into a hierarchical state tree;

[0037] generating a lightweight verification index of the global state snapshot based on the hierarchical state tree;

[0038] The lightweight verification index is updated in the unique identification with the interaction audit record.

[0039] In a preferred embodiment, the aggregation of the Merkle root hash value into a hierarchical state tree comprises:

[0040] When an anomaly is detected in the sharded blockchain, a corresponding branch of the hierarchical state tree is frozen;

[0041] Triggering the consensus nodes in the sharded blockchain to reorganize.

[0042] To solve the above problems, the application also provides a distributed trusted data space construction system based on a blockchain, which comprises:

[0043] A sharded blockchain creation module is configured to dynamically create a sharded blockchain of the data space according to the unique identification;

[0044] A data block generation module is configured to store the structured data in the corresponding sharded blockchain after encryption by the participants, thereby obtaining a data block of the structured data;

[0045] A cross-chain verification credential generation module is configured to generate a cross-chain verification credential of cross-sharded blockchains based on zero-knowledge proof when a data interaction request across the sharded blockchains occurs;

[0046] A data interaction module is configured to complete data interaction of the sharded blockchains by the cross-chain verification credential and generate an interaction audit record of the data interaction;

[0047] A global state snapshot update module is configured to periodically aggregate the state hash of the sharded blockchains and the interaction audit record and update a global state snapshot under the unique identification.

[0048] Compared with the prior art, the application has the following beneficial effects:

[0049] 1. The application ensures the trustworthiness and uniqueness of the identity of the participants by the registration mechanism of the combination of the digital identity credential and the unique identification, thereby laying a solid foundation of identity trust for the data space. Meanwhile, the sharded blockchains are dynamically created based on the unique identification, and the number of nodes is adjusted according to the data load, which is combined with the method of encrypting the structured data, thereby significantly improving the security and flexibility of data storage and effectively reducing the risk of data leakage and tampering.

[0050] 2.The application generates cross-chain verification credentials through zero-knowledge proof, which not only guarantees the efficiency of data interaction, but also avoids the leakage of sensitive information, and the generation of interaction audit records enhances the traceability of data operation. Periodic aggregation of sharded blockchain state hash and updating of global state snapshot can timely reflect the overall state of the data space, ensuring the consistency and reliability of the data space, and further improving the security and robustness of the distributed trusted data space. BRIEF DESCRIPTION OF DRAWINGS

[0051] Figure 1 A flowchart of a distributed trusted data space construction method based on a blockchain is provided for an embodiment of the application.

[0052] Figure 2 A function module diagram of a distributed trusted data space construction system based on a blockchain is provided for an embodiment of the application.

[0053] The implementation, functional features and advantages of the application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0054] It should be understood that the specific embodiments described herein are only used to explain the application and not to limit the application.

[0055] Embodiments of the present application provide a distributed trusted data space construction method based on a blockchain. The execution subject of the distributed trusted data space construction method based on a blockchain includes but is not limited to at least one of electronic devices such as a server and a terminal that can be configured to execute the method provided by the embodiments of the application. In other words, the distributed trusted data space construction method based on a blockchain can be executed by software or hardware installed in a terminal device or a server device. The server includes but is not limited to a single server, a server cluster, a cloud server, or a cloud server cluster, etc. The server can be a standalone server, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content distribution networks (CDN), and big data and artificial intelligence platforms, etc. Basic cloud computing services.

[0056] Referring to Figure 1 FIG. 1 shows a flowchart of a distributed trusted data space construction method based on a blockchain provided by an embodiment of the application. In this embodiment, the distributed trusted data space construction method based on a blockchain includes:

[0057] S1, the participant completes registration under the unique identifier of the data space through a digital identity credential;

[0058] In the embodiment of the present application, the participant completes registration under the unique identifier of the data space through a digital identity certificate, including:

[0059] defining the boundary of the data space and generating the unique identifier of the data space;

[0060] generating the distributed identity certificate of the participant through the unique identifier.

[0061] Specifically, all data attributes involved in the data space are collected, including the system name of data generation, the time interval covered by data, the business field associated with data, and the type of participant involved in data, the specific range of each attribute is determined, for example, the system name of data generation is limited to "production management system" and "inventory management system", the time interval covered by data is limited to "January 1, 2024 to December 31, 2024", the business field associated with data is limited to "product production" and "inventory scheduling", and the type of participant involved in data is limited to "production enterprise" and "logistics enterprise", and these determined attribute ranges jointly constitute the boundary of the data space.

[0062] Further, the specific range of each attribute constituting the boundary of the data space is spliced into a string in the fixed order of "system name + time interval + business field + participant type", for example, "production management system inventory management system 20240101-20241231 product production inventory scheduling production enterprise logistics enterprise", the string is processed using SHA-1 hash algorithm to obtain a 160-bit binary value, and then the binary value is converted into a 40-bit hexadecimal string, and the hexadecimal string is the unique identifier of the data space.

[0063] Further, the participant submits its basic information, including the legal name, the unified social credit code, the registered address and the specific role in the data space, the system associates these basic information with the unique identifier of the data space, generates a text file in the format of "unique identifier + participant legal name + unified social credit code + registered address + role", and then encrypts the text file using the private key of the participant, the encryption process is to operate the ASCII code value corresponding to each character of the text file with the private key to obtain the encrypted character, and the file composed of all encrypted characters is the distributed identity certificate of the participant.

[0064] In general, by defining the boundary of the data space and generating the unique identifier, the scope and subject of the data space are clarified, providing a unified benchmark for identity management of the participant, and ensuring the standardization and consistency of the identity system within the data space.

[0065] In summary, the distributed identity certificate of the participant is generated based on the unique identifier, the distributed verification of the identity of the participant is realized, the authenticity and uniqueness of the identity information are guaranteed, the risk of single point failure or data leakage caused by centralized identity management is avoided, the trusted foundation of the data space is built from the identity access link, and the premise guarantee for the subsequent data interaction and storage security is provided.

[0066] S2, dynamically creating a sharded blockchain of the data space according to the unique identifier;

[0067] In the embodiment of the application, the dynamic creation of the sharded blockchain of the data space according to the unique identifier comprises:

[0068] dividing the sharded blockchain of the data space based on the hash value of the unique identifier;

[0069] dynamically adjusting the number of nodes of the sharded blockchain according to real-time data load.

[0070] Specifically, the unique identifier of the data space is obtained, which is a 40-bit hexadecimal string, and is regarded as a hash value. The fixed number of sharded blockchains is set to 8, each sharded blockchain corresponds to a number from 0 to 7, the hexadecimal hash value is converted into a decimal number, and the remainder obtained by dividing the decimal number by 8 is the sharded blockchain number to which the data space belongs. The data space is allocated to the corresponding sharded blockchain according to the number, and the sharded blockchain of the data space is divided based on the hash value of the unique identifier.

[0071] Further, the load condition of each sharded blockchain is monitored in real time, the monitoring content includes the data transaction volume processed per second and the total amount of data currently stored, the upper limit of the load of each node is set to 100 transactions per second and the total amount of stored data is not more than 500GB, when the real-time data transaction volume of a sharded blockchain exceeds 100 transactions per node for 30 seconds continuously or the total amount of stored data exceeds 500GB per node, a node with normal state is selected from the backup node pool to join the sharded blockchain, and the number of added nodes is the result of the ratio of the part exceeding the upper limit of the current load to the upper limit of the load of a single node rounded up. When the real-time data transaction volume of a sharded blockchain is less than 50 transactions per node for 5 minutes continuously, and the total amount of stored data is less than 200GB per node, the node with the least transaction volume processed in the last 30 minutes is selected from the sharded blockchain, and is removed from the sharded blockchain and included in the backup node pool, and the number of reduced nodes is the result of the ratio of the part below the lower limit of the current load to the upper limit of the load of a single node rounded down, so as to dynamically adjust the number of nodes of the sharded blockchain according to the real-time data load.

[0072] In general, the sharding blockchain based on the hash value of the unique identifier can orderly allocate the resources of the data space and the data according to the identification characteristics, ensure the balance between the independence and correlation of each sharding blockchain, provide a reasonable structural basis for the distributed storage of data, and improve the orderliness and pertinence of data management.

[0073] In general, the number of nodes of the sharding blockchain is dynamically adjusted according to the real-time data load, so that the change of the data processing demand can be flexibly adapted. When the load increases, the processing capacity is enhanced by increasing the nodes; when the load decreases, the nodes are reduced to avoid resource waste, which not only guarantees the efficiency of data processing, but also optimizes the resource utilization rate. At the same time, the dynamic adjustment mechanism also enhances the resilience of the entire data space to sudden data fluctuations, further consolidates the stability and reliability of the distributed system.

[0074] S3, the participant stores the structured data after encryption to the corresponding sharding blockchain to obtain a data block of the structured data;

[0075] In the embodiment of the application, the participant first standardizes the structured data to be stored, which is presented in a table with a fixed format, and the table contains at least 5 core fields, such as "data number" (text type, composed of 8 digits), "data content" (string type, length not more than 200 characters), "data source" (text type, fill in the specific department name that produces the data), "data creator" (text type, fill in the operator's name), and "data state" (enumeration type, containing only three options of "valid", "to be audited" and "invalid"), each field must be filled in completely and meet the format requirements, and no empty value or format error content is allowed.

[0076] Specifically, the participant extracts a private key from the distributed identity certificate file of itself, the private key is a 64-bit hexadecimal string, which is converted into a 32-byte binary sequence, and each byte is converted into a corresponding decimal value to form a key list containing 32 decimal numbers; then each field value in the structured data is encrypted character by character, the first character in the field value is converted into a decimal ASCII code, the first value in the key list is summed with the ASCII code, if the result is greater than 127, the result is subtracted by 128 to obtain a new ASCII code, and the new ASCII code is converted into a corresponding character as the encryption result of the character, the second value in the key list is used to process the second character in the field value in the same way, and the same is true for the subsequent characters, if the length of the field value exceeds 32 characters, the values in the key list are recycled until the encryption of all characters is completed, and finally the encrypted structured data is formed, which has the same field structure as the original data, but the field values are all encrypted characters.

[0077] Further, the participant queries the corresponding shard blockchain through the built-in shard blockchain mapping service of the system, which stores the correspondence table of data space unique identifier and shard blockchain number. After the participant inputs the unique identifier of the data space (40-bit hexadecimal string), the mapping service will immediately return the corresponding shard blockchain number (integer between 0 and 7). The participant determines the network address of the target shard blockchain according to the number. The address is in the URL format containing "shard number. blockchain cluster domain name", such as "3.shardblockchain.example.com".

[0078] Further, the participant splices the encrypted structured data, the current timestamp accurate to the millisecond (format "YYYYMMDDHHMMSSmmm"), the public information in the distributed identity certificate file (including the participant's legal name and the hash value of the unified social credit code), and the hash value of the last data block in the target shard blockchain (obtained by querying the latest block information of the shard blockchain) into a complete data packet in the order of "timestamp + public information + encrypted data + previous block hash". The data packet is packaged in JSON format, and each part exists as an independent key-value pair, with the key names "timestamp", "publicInfo", "encryptedData", and "previousHash".

[0079] Further, the participant sends the above data packet to the receiving port (port number fixed at 8080) of any node of the target shard blockchain through the HTTPS protocol. After receiving the data packet, the node first verifies whether the format of the data packet conforms to the JSON specification. If not, it is discarded directly. After the format verification is passed, the node extracts the public information in the data packet and compares it with the public information of the participant's distributed identity certificate file stored in the system to ensure that the legal name and the hash value of the unified social credit code are completely consistent. Then, it verifies whether the previous block hash is the same as the hash value of the last block of the current blockchain. If not, it rejects the reception. After all the verifications are passed, the node marks the data packet as a to-be-confirmed state and synchronizes the data packet to other three nodes in the shard blockchain. After the other nodes complete the same verification and return the confirmation information, the node adds the data packet to the end of the blockchain to form a new data block, which contains all the contents in the data packet. At the same time, it generates its own hash value (obtained by processing the entire data packet content with SHA-256) and updates the end block identifier of the shard blockchain to the new data block. Thus, the data block of the structured data is formally generated.

[0080] In summary, encrypting structured data can establish a security barrier at the data storage stage, effectively preventing unauthorized access, theft, or tampering during storage, ensuring the confidentiality and integrity of the data itself, and reducing the risk of data leakage from the source.

[0081] In summary, storing encrypted structured data in corresponding sharded blockchains achieves precise matching between data and sharded blockchains, making data storage more targeted and orderly. This corresponding storage method not only facilitates rapid data location and management but also avoids the single point of failure risk associated with centralized data storage by leveraging the distributed nature of sharded blockchains. Furthermore, the formation of data blocks provides a reliable unit carrier for subsequent data traceability and verification, further strengthening the trustworthy architecture of the data space.

[0082] S4. When a cross-shard blockchain data interaction request occurs, a cross-chain verification credential for the cross-shard blockchain is generated based on zero-knowledge proof.

[0083] In this embodiment of the invention, the step of generating a cross-chain verification credential based on zero-knowledge proof when a cross-shard blockchain data interaction request occurs includes:

[0084] Generate an initial commitment value for the zero-knowledge proof based on the requester's set of data attributes;

[0085] The proof parameters for constructing the cross-chain verification credential are based on the initial commitment value;

[0086] The proof parameters are input into a non-interactive proof protocol, and the cross-chain verification credential across the sharded blockchain is generated using predefined cryptographic rules in the non-interactive proof protocol.

[0087] The proof parameters for constructing the cross-chain verification credential based on the initial commitment value include:

[0088] Generate basic cryptographic parameters based on the preset elliptic curve base points and order parameters;

[0089] Based on the initial commitment value and the target fragment identifier, construct the attribute binding vector;

[0090] The requester's private key is used to perform a scalar multiplication operation on the attribute binding vector to generate a random number factor;

[0091] Based on the cryptographic fundamental parameters and the random number factor, calculate the elliptic curve bilinear pair mapping value;

[0092] The bilinear pair mapping value is combined with the attribute binding vector to form the proof parameters of the cross-chain verification credential.

[0093] The combination of the bilinear pair mapping value and the attribute binding vector forms the proof parameter, wherein the calculation formula of the proof parameter is as follows:

[0094]

[0095] In the formula, The proof parameter is The bilinear pair mapping function is The private key is The cryptographic base parameter is The elliptic curve hash-to-point function is The attribute binding vector is

[0096] The proof parameter is input into a non-interactive proof protocol, and the cross-chain verification credential of the cross-shard blockchain is generated through a pre-defined cryptographic rule in the non-interactive proof protocol, wherein the calculation formula of the cross-chain verification credential is as follows:

[0097]

[0098] In the formula, The cross-chain verification credential is The anti-collision hash function is The initial commitment value is The proof parameter is The connection operator is The modulo operator is The elliptic curve base point and the order parameter are

[0099] Specifically, the requester organizes its own data attribute set, which contains five specific attributes: data type (fixed as "product inventory data"), data range (fixed as "July 1, 2024 to July 15, 2024"), data owner (fixed as "XX Company Production Department"), data sensitivity (fixed as "internal disclosure"), and data integrity check value (fixed as "7A3F9C2D"). Each attribute exists in text form and has a standardized format. The requester arranges these attributes in the fixed order of "data type, data range, data owner, data sensitivity, and data integrity check value" to generate a list containing all attributes. Then, the requester obtains a pre-generated random number seed from the system, which is a 64-bit string. The random number seed is concatenated with each attribute in the list to form new string combinations, such as "ABC123DEF456GHI789JKL012MNO345PQR678STU901VWX234YZA567 product inventory data" for the attribute "product inventory data". Each newly generated string combination is subjected to hashing, which involves converting the string to binary data and performing multiple iterations of the binary data using a specific hashing function. In each iteration, the result of the previous iteration is XORed with the binary value of the current character to generate a 256-bit hash value. The hash values corresponding to all attributes are concatenated into a new string, which is subjected to a second hashing process identical to the first. The final 256-bit hash value obtained is the initial commitment value for the zero-knowledge proof.

[0100] Further, the system obtains the initial commitment value, which is a 256-bit hash string, converts it into binary format, divides it into 32 byte groups according to every 8 bits, obtains the base point information of the elliptic curve from the pre-configured cryptography parameter library, which includes the X and Y coordinates of the base point, both of which are large integers, converts each byte group of the initial commitment value into the corresponding decimal value, and performs point-by-point multiplication operation on the base point of the elliptic curve using these decimal values. The operation process is to perform multiple operations on the base point coordinates according to the point multiplication rules on a specific elliptic curve, using the decimal value corresponding to each byte group as the multiplier each time. For example, if the decimal value corresponding to the first byte group is 156, the base point coordinates are subjected to 156 times of specific point addition operation to obtain a new point coordinate. All 32 byte groups are processed in the same way to obtain 32 new point coordinates. These new point coordinates are combined in the order obtained to form a coordinate sequence. Each coordinate in the coordinate sequence is hashed to generate a corresponding 256-bit hash value. All hash values are concatenated into a new string, which is encoded to obtain the proof parameter of the cross-chain verification credential.

[0101] Further, the proof parameter is input into the processing module of the non-interactive proof protocol. The module first verifies the format of the proof parameter to check whether it conforms to the Base58 encoding rule. After verification, the module obtains a pre-set verification key from the cryptography rule library of the protocol. The key is a structure containing multiple parameters, including elliptic curve parameters, generators, public verification points, etc. The module parses the proof parameter according to specific rules and decomposes it into 32 sub-parameters. Each sub-parameter is subjected to specific cryptography transformation, which includes converting the sub-parameter into a point on a specific elliptic curve, performing a series of point addition and point multiplication operations on the point, and using the parameters in the verification key to perform verification operations on the transformed sub-parameters. The verification operations include comparing and calculating the sub-parameters with the corresponding parameters in the verification key to check whether they satisfy the predefined equation relationship. The verification results of all sub-parameters are summarized. If all sub-parameters pass the verification, a credential data containing the verification result, a timestamp "20250712153045678" accurate to milliseconds, a protocol identifier "ZK-ICV-2025", etc. is generated. The credential data is digitally signed. The signature process is to encrypt the credential data using a specific private key to generate a 64-byte signature value. The credential data and the signature value are combined into a complete data packet, which is the cross-chain verification credential of the cross-shard blockchain.

[0102] Specifically, the preset elliptic curve base point is coordinate (X0, Y0), the order parameter is a 128-bit decimal integer, the X0 and Y0 of the base point are converted into binary form, each coordinate is converted into a 256-bit binary string, the binary representation of the order parameter (also converted into a 128-bit binary string) is added in front of the binary string to form a combined binary string, the combined binary string is subjected to hash processing, the hash process is that the binary string is grouped every 64 bits, each group is subjected to an exclusive or operation and then spliced, the operation is repeated three times to obtain three 256-bit hash values, the three hash values are combined with the base point coordinates and the order parameter respectively to form a set containing "base point P (X0, Y0), order n, derived point Q (X1, Y1), and derived point R (X2, Y2)", wherein the coordinates of the derived point Q are converted from the first hash value, the coordinates of the derived point R are converted from the second hash value, and the third hash value is used as a check value. The set is the basic parameter of cryptography.

[0103] Further, the initial commitment value is a 256-bit hash string, and the target shard identifier is the number "3" (a decimal integer) of the shard blockchain. The initial commitment value is divided into 8 segments every 32 bits, each segment is converted into a decimal integer to obtain 8 integer elements e1 to e8, the target shard identifier "3" is converted into a decimal integer e9, and the 9 integers are arranged in the order of "e1, e2, e3, e4, e5, e6, e7, e8, e9" to form an array containing 9 elements. Each element in the array is adjusted in range to ensure that the value of each element is between 1 and half of the order parameter. If an element exceeds the range, a new value is obtained by subtracting the element from the order parameter. The adjusted array is the attribute binding vector.

[0104] Further, the private key of the requestor is a 64-bit hexadecimal string, which is converted into a decimal integer s, and the attribute binding vector is an array [v1, v2, v3, v4, v5, v6, v7, v8, v9] containing 9 integers. Each element in the vector is subjected to a scalar multiplication operation. The operation process is that the integer s is multiplied by each element vi respectively to obtain the product s*vi. Each product is divided by the order parameter, and the remainder is taken as the operation result to obtain 9 new integers [r1, r2, r3, r4, r5, r6, r7, r8, r9]. The 9 integers are spliced into a string in order, and the string is subjected to hash processing to generate a 256-bit hash value. The hash value is the random number factor.

[0105] Further, the cryptographic base parameter includes a base point P, an order n, a derived point Q, a derived point R, the random number factor is a decimal integer r converted from a 256-bit hash value, the base point P (X0, Y0) and the derived point Q (X1, Y1) are extracted from the cryptographic base parameter, the scalar multiplication result of the point P and the random number factor r is calculated to obtain the point P', the calculation method is to perform multiple elliptic curve point addition operations on the point P according to the value of r; similarly, the scalar multiplication result of the derived point Q and the random number factor r is calculated to obtain the point Q'; using the elliptic curve bilinear pair mapping rule, the point P' and the point Q' are mapped, the mapping process is to substitute the coordinates of the two points into a preset mapping formula, and a mapping result value is obtained by combining the coordinate values and performing specific mathematical transformations; the base point P and the derived point R are processed in the same way to obtain a second mapping result value; the two mapping result values are spliced to form a 512-bit string, which is the elliptic curve bilinear pair mapping value.

[0106] Further, the bilinear pair mapping value is a 512-bit string, the attribute binding vector is an array [v1, v2, v3, v4, v5, v6, v7, v8, v9] containing 9 integers, each integer in the attribute binding vector is converted into a 32-bit hexadecimal string, and a 288-bit string is spliced in order, the string is spliced with the bilinear pair mapping value in the order of "bilinear pair mapping value + attribute binding vector string", and a 800-bit combined string is formed, the combined string is processed by Base64 encoding, the encoding process is to convert each 6-bit group of the string into corresponding Base64 characters, and the part less than 6 bits is filled with padding characters, and the encoding result obtained is the proof parameter of the cross-chain verification credential.

[0107] Specifically, in the calculation formula of the proof parameter, the source of the parameters in the formula is as follows, That is, the private key is a private key contained in the distributed identity proof file of the request party, which is a decimal integer converted from a 64-bit hexadecimal string; That is, the cryptographic base parameter is a base point in the cryptographic base parameter generated by a preset elliptic curve base point and order parameter, the coordinates of which are determined by a preset X0 and Y0; H is an elliptic curve hash-to-point function, which is a predefined cryptographic function, and the function is to convert the attribute binding vector into a point on the elliptic curve, the specific process is to receive the array of the attribute binding vector, convert the array elements into a string, and then perform hash processing, and then convert the hash value into the point coordinates on the elliptic curve; That is, the attribute binding vector is an array containing 9 integers constructed from an initial commitment value and a target shard identifier, the initial commitment value is the initial commitment value of the zero-knowledge proof, and the target shard identifier is the number of the shard blockchain; The bilinear pairing function is a predefined cryptographic function that receives two points on an elliptic curve, combines the coordinates of the points, and performs specific mathematical transformations to calculate a bilinear pairing value.

[0108] Further, the significance of the formula is that through the bilinear pairing function , the private key is mapped with the scalar multiplication result of the cryptographic base parameter and the result of the attribute binding vector converted by the hash-to-point function H to generate the proof parameter . This process not only verifies the validity of the requestor's private key, but also associates the data attribute information contained in the attribute binding vector with the cryptographic base parameter, making the generated proof parameter unique to the requestor's identity and the data attributes they need to verify, providing a core basis for subsequent generation of cross-chain verification credentials, ensuring accurate identification of the requestor's legitimacy and corresponding authority range during cross-shard blockchain verification.

[0109] Further, the trend of the formula is that when the private key changes, the scalar multiplication result of will change, and the first parameter input into the bilinear pairing function will change, resulting in a change in the proof parameter ; when the attribute binding vector changes, the result converted by the hash-to-point function H will change, and the second parameter input into the bilinear pairing function will change, also resulting in a change in the proof parameter ; while the cryptographic base parameter is a fixed value, the hash-to-point function H and the bilinear pairing function are predefined fixed functions, so the change in the proof parameter is only determined by the change in the private key and the attribute binding vector , and each different combination of private key and attribute binding vector will correspond to a unique proof parameter , ensuring the uniqueness of the proof parameter and its strong association with the requestor and data attributes.

[0110] Specifically, the sources of the parameters in the formula are as follows, i.e., the cross-chain verification credential is the final result calculated by the formula; Collision-resistant hash functions are predefined cryptographic functions that receive concatenated strings, convert them into binary data, process each binary bit through multiple iterations, and generate a hash value of fixed length. In the process, they ensure that the probability of different inputs corresponding to different outputs is extremely high. The initial commitment value is the initial commitment value of the zero-knowledge proof generated from the requester's data attribute set, and it is a 256-bit hash value. The proof parameters are the proof parameters of the cross-chain verification credential formed by combining bilinear pair mapping values ​​and attribute binding vectors; the "‖" operator is used to connect the initial commitment value... and proof parameters according to" in front, The strings are concatenated in the order of "after" to form a continuous string; The modulo operator, used in calculations, employs a hash function. The output result divided by The remainder obtained is the final result. The base points and order parameters of the elliptic curve are preset 128-bit decimal integers, which are used as divisors in the modulo operation.

[0111] Furthermore, the significance of the formula lies in using a collision-resistant hash function. Initial commitment value and proof parameters The concatenated string is converted into a fixed-length hash value, which is then used to determine the elliptic curve's base points and order parameters. Perform modulo operations to generate cross-chain verification credentials. This process closely links the data attribute information contained in the initial commitment value with the cryptographic verification information contained in the proof parameters. It ensures the uniqueness and tamper-proof nature of the data through a hash function, and limits the result to a preset order parameter range through modulo operations, thus ensuring the generated cross-chain verification credential is secure. It can serve as the core credential for cross-shard blockchain verification, accurately reflecting the identity, data attributes, and verification basis of the requester, ensuring the security and effectiveness of the cross-chain process.

[0112] Furthermore, the trend of the formula is that when the initial commitment value When changes occur, the concatenated string changes accordingly, and is processed by a collision-resistant hash function. The processed data outputs different hash values, which are then used to perform a modulo operation to obtain the cross-chain verification credential. They must be different; when proving parameters When changes occur, the concatenated string also changes, after passing through a hash function and modulo operation. They will also be different; while collision-resistant hash functions , the elliptic curve base point and the order parameter P are fixed values, the connection operator ‖ has a fixed mode of action, therefore the change of the cross-chain verification voucher is only determined by the change of the initial commitment value and the proof parameter , and each different combination of and corresponds to a unique , ensuring the unique association of the cross-chain verification voucher with the data attribute of the requester and the proof parameter.

[0113] In general, through the zero-knowledge proof technology, in the process of generating the cross-chain verification voucher, the specific data content of the requester can be verified without being exposed, which not only ensures the legality of data interaction, but also maximizes the protection of data privacy information, avoids the risk of leakage of sensitive data in the cross-chain process, and builds a privacy protection barrier for cross-fragment data interaction.

[0114] In general, based on the initial commitment value, the proof parameter is constructed and the cross-chain verification voucher is generated through the non-interactive proof protocol, and with the aid of elliptic curve cryptography, bilinear pair mapping and other technical means, the unforgeability and verifiability of the verification voucher are ensured. This process not only meets the data interaction needs between cross-fragment blockchains, but also guarantees the security and credibility of the interaction process through strict cryptographic rules, and provides reliable verification basis for subsequent interaction audit, further enhancing the standardization and security of cross-chain operation in distributed data space.

[0115] S5, completing the data interaction of the fragment blockchain through the cross-chain verification voucher, and generating an interaction audit record of the data interaction;

[0116] In the embodiment of the application, the requester sends the cross-chain verification voucher to the verification node of the target fragment blockchain, the verification node first checks whether the format of the voucher conforms to the predefined Base64 encoding rule, if the format is correct, the initial commitment value and the proof parameter part in the voucher are extracted, the pre-stored elliptic curve base point and order parameter are used to verify the proof parameter, the verification process is to recalculate the relationship between the initial commitment value and the proof parameter through the bilinear pair mapping function, check whether the calculation result is consistent with the proof parameter in the voucher, and verify whether the initial commitment value matches the data attribute set of the requester, if all verifications are passed, the node confirms that the cross-chain verification voucher is valid, and allows the requester to access the data in the target fragment blockchain.

[0117] Further, after verification, the requester will send the data operation request to the interface of the target shard blockchain, which contains the operation type (such as query, write), the identification of the target data, and the specific content of the operation. After receiving the request, the interface calls the corresponding processing module according to the operation type. For query operation, the processing module extracts the corresponding data block from the blockchain, decrypts the encrypted data in the data block using the public key of the requester, and compares the decrypted data with the data attribute set of the requester to ensure that the requester has the right to access the data. After the comparison is passed, the data is returned to the requester; for write operation, the processing module encrypts the data in the request according to the preset encryption rule, generates a new data block, adds the block to the target shard blockchain, and updates the state of the blockchain.

[0118] Further, in the data interaction process, the audit module of the target shard blockchain records each operation step in real time. First, it records the verification process of the cross-chain verification credential, including verification time, verification result, elliptic curve base point and order parameter information, etc. Then it records the detailed content of the data operation request, such as operation type, target data identification, operation content, etc. For query operation, it records the data extraction time, decryption process, comparison result, etc. For write operation, it records the data encryption process, new block generation time, block addition to the chain specific location, etc. All recorded information is arranged in chronological order to form a complete operation sequence.

[0119] Further, the audit module organizes the recorded operation sequence to generate a data packet containing all interaction information, which includes the start time, end time, node identification, cross-chain verification credential hash value, operation type, data identification, operation result, etc. The data packet is digitally signed, and the signing process is to encrypt the data packet using the private key of the audit module to generate a signature value. The data packet and signature value are combined into a complete interaction audit record, which is stored in a specific block of the target shard blockchain. This block is specifically used to store all data interaction audit records, ensuring the non-tamperability and traceability of the records.

[0120] In summary, the cross-chain verification credential, as a trusted credential generated based on zero-knowledge proof, can ensure the legality of the identity and data of the cross-shard interaction, providing a reliable verification basis for secure data transmission between different shard blockchains, ensuring the standardization and security of cross-chain operations, and effectively avoiding the risks brought by illegal data interaction.

[0121] Overall, the generation of the interaction audit record completely records the key information of cross-chain data interaction, including the interaction subject, content, and time, etc. Relying on the tamper-proofing feature of the blockchain, each cross-chain operation can be traced and audited. This not only provides a basis for subsequent problem troubleshooting and responsibility definition, but also restricts the operation behavior of the participants through the whole process of leaving traces, further enhancing the credibility and transparency of cross-chain interaction in the distributed data space.

[0122] S6、Periodically aggregate the state hash of the sharded blockchain and the interaction audit record, and update the global state snapshot under the unique identifier.

[0123] In the embodiments of the present application, the periodically aggregated state hash of the sharded blockchain and the global state snapshot under the unique identifier are updated, comprising:

[0124] Collecting the Merkle root hash value of the sharded blockchain at a preset period;

[0125] Aggregating the Merkle root hash value into a hierarchical state tree;

[0126] Generating a lightweight verification index of the global state snapshot based on the hierarchical state tree;

[0127] Updating the lightweight verification index and the interaction audit record in the unique identifier.

[0128] The Merkle root hash value is aggregated into a hierarchical state tree, comprising:

[0129] When detecting that the sharded blockchain has an exception, freezing the corresponding branch of the hierarchical state tree;

[0130] Triggering the consensus nodes in the sharded blockchain to reorganize.

[0131] Specifically, the system automatically triggers the collection operation of the Merkle root hash value at a preset period (fixed as every hour at the hour mark). First, the latest block height of the sharded blockchain is queried to obtain the end block of the current blockchain. The Merkle root hash value is extracted from the header information of the block. The hash value is a 64-bit hexadecimal string. The extracted Merkle root hash value and the collection timestamp (format YYYYMMDDHHMMSS) are combined into a data entry. The data entry format is "timestamp | Merkle root hash value", for example, "20250712150000 | ABC123DEF456GHI789". The data entry is stored in a temporary buffer. Repeat the process until all Merkle root hash values of the sharded blockchain in the period are collected.

[0132] Further, the system obtains all collected Merkle root hash value data entries from the temporary buffer, sorts them in chronological order, groups the sorted entries into groups of 10, with any group of less than 10 being a separate group, performs hash aggregation on the Merkle root hash values in each group, the aggregation process being to concatenate the 10 hash values in the group into a long string, hash the string to generate a new hash value, which is the parent node hash value of the group, and group the parent node hash values of all groups into groups of 10, repeat the hash aggregation process to generate higher-level parent node hash values, and so on, until a root hash value is generated, which is the root node of the hierarchical state tree, and all levels of hash values and node relationships constitute a complete hierarchical state tree.

[0133] Further, based on the generated hierarchical state tree, the system starts from the root node and sequentially accesses each node in depth-first order, records the hash value of each node and its position information in the tree, the position information including the level number and the serial number of the node in the current level, combines the hash value of each node and the position information into an index entry, the index entry format being "level number | serial number | hash value", for example, "3 | 5 | ABC123DEF456GHI789", arranges all generated index entries in ascending order of level number and serial number to form an ordered index list, and compresses the index list, the compression process being to merge adjacent index entries with the same prefix and retain only the different suffix part, the compressed index list being the lightweight verification index of the global state snapshot.

[0134] Further, the system obtains the lightweight verification index and the interaction audit record, first reads the current index and record data from the storage area corresponding to the unique identifier of the data space, compares the lightweight verification index with the currently stored index data, calculates the difference between the two, adds the difference to the index data, and updates the version number and timestamp of the index, similarly compares the interaction audit record with the currently stored record data, adds the new audit record to the end of the record data, and updates the total number and latest timestamp of the record, combines the updated lightweight verification index and the interaction audit record in the format "lightweight verification index | interaction audit record", encrypts the combined data using the unique identifier of the data space as the key, and stores the encrypted data back into the storage area corresponding to the unique identifier, completing the update operation of the lightweight verification index and the interaction audit record in the unique identifier.

[0135] Specifically, the system monitors the running state of each shard blockchain in real time, and the monitoring content includes the consistency of transaction verification results between nodes, the matching degree of block hash values, and data transmission delay. When it is found that more than one-third of the nodes in a certain shard blockchain have inconsistent transaction verification results or the block hash value does not match the hash value of the corresponding node in the hierarchical state tree within two consecutive block generation periods, it is determined that the shard blockchain has an anomaly. Through the block number and shard identifier of the anomaly occurrence, the corresponding branch of the shard blockchain is located in the hierarchical state tree, which is the complete path from the root node to the latest Merkle root hash value node of the shard. The system sends a freezing instruction to the management module of the hierarchical state tree, and the management module marks all nodes on the branch as "frozen" state and sets the state identifier as "unmodifiable". At the same time, the freezing time, anomaly type and branch path information are recorded to ensure that the branch cannot perform any data writing or updating operation before the reorganization is completed.

[0136] Further, after freezing the corresponding branch of the hierarchical state tree, the system immediately sends a reorganization trigger signal to all consensus nodes in the shard blockchain, which contains the block height of anomaly occurrence, the frozen hierarchical state tree branch information and the reorganization start time. After receiving the signal, the consensus node automatically suspends the current transaction processing flow, and traces back from the anomaly occurrence block height to the nearest anomaly-free block (i.e. the hash value of the block is consistent in all nodes and matches the record in the hierarchical state tree), taking the anomaly-free block as the reorganization starting point. The consensus node re-reads all transaction data from the starting point to the anomaly occurrence, re-verifies the validity of each transaction according to the preset consensus algorithm, and the verification process includes comparing the digital signature of the transaction with the distributed identity proof file of the sender, checking the matching of the transaction content and the data space boundary, and repackaging the verified transactions into new blocks. After each consensus node independently completes the packaging, it broadcasts the newly generated block hash value to other consensus nodes. When the block hash values generated by more than two-thirds of the consensus nodes are consistent, the block corresponding to the hash value is taken as the valid block, and the reorganization of the subsequent blocks is completed in turn until the anomaly block is covered. After the reorganization is completed, the consensus node synchronizes the new block chain sequence to the entire shard network, updates the hash value of the corresponding branch in the hierarchical state tree, and releases the frozen state of the branch.

[0137] In summary, the Merkle root hash values of the shard blockchains are collected and aggregated into a hierarchical state tree at a preset period, and combined with the interaction audit record, the running state and operation trajectory of the data space can be fully integrated. This aggregation method not only preserves the integrity of each shard data, but also realizes the ordered organization of state information through the hierarchical structure, providing a structured basis for efficient verification of the global state and improving the control ability of the overall state of the data space.

[0138] In general, the lightweight verification index of the global state snapshot based on the hierarchical state tree is generated and updated under the unique identification, which can reflect the latest state of the data space in real time. When detecting the abnormality of the sharded blockchain, the corresponding branch is frozen and the consensus node is reorganized, which can timely contain the spread of the abnormality and ensure the stability of the system. At the same time, the update of the global state snapshot ensures the consistency and traceability of the data space state, provides a trusted global view for the participants, and further enhances the reliability and security of the distributed data space.

[0139] As Figure 2 shown in the figure is a functional module diagram of a distributed trusted data space construction system based on a blockchain according to an embodiment of the present application.

[0140] The distributed trusted data space construction system based on a blockchain 100 can be installed in an electronic device. According to the functions implemented, the distributed trusted data space construction system based on a blockchain 100 can include a registration module 101, a sharded blockchain creation module 102, a data block generation module 103, a cross-chain verification credential generation module 104, a data interaction module 105, and a global state snapshot update module 106. The modules of the present application can also be referred to as units, which refer to a series of computer program segments that can be executed by an electronic device processor and can complete a fixed function, which are stored in the memory of the electronic device.

[0141] In this embodiment, the functions of each module / unit are as follows:

[0142] The registration module 101 is used for participants to complete registration under the unique identification of the data space through digital identity credentials;

[0143] The sharded blockchain creation module 102 is used for dynamically creating a sharded blockchain of the data space according to the unique identification;

[0144] The data block generation module 103 is used for the participants to store structured data to the corresponding sharded blockchain after encryption, to obtain data blocks of the structured data;

[0145] The cross-chain verification credential generation module 104 is used for generating cross-chain verification credentials of cross-sharded blockchains based on zero-knowledge proof when there is a cross-sharded blockchain data interaction request;

[0146] The data interaction module 105 is used for the cross-chain verification credentials to complete data interaction of the sharded blockchains and generate interaction audit records of the data interaction;

[0147] The global state snapshot updating module 106 is configured to periodically aggregate the state hash of the sharded blockchains and the interaction audit record, and update the global state snapshot under the unique identifier.

[0148] In several embodiments provided by the present application, it should be understood that the disclosed method and system can be implemented in other ways. For example, the system embodiments described above are only illustrative, for example, the division of the modules is only a logical functional division, and actual implementation can have another division manner.

[0149] The modules described as separate components can or can not be physically separated, and the components displayed as modules can or can not be physical units, that is, they can be located in one place or distributed to multiple network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiment.

[0150] In addition, the functional modules in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of hardware plus software functional modules.

[0151] It is obvious for those skilled in the art that the present application is not limited to the details of the above exemplary embodiments, and the present application can be implemented in other specific forms without departing from the spirit or essential characteristics of the present application.

[0152] The embodiments of the present application can acquire and process related data based on artificial intelligence technology. Among them, artificial intelligence is to use digital computers or machine controlled by digital computers to simulate, extend and expand human intelligence, perceive environment, acquire knowledge and use knowledge to obtain the best results.

[0153] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and not to limit it. Although the present application has been described in detail with reference to the preferred embodiments, it should be understood by those skilled in the art that the technical solutions of the present application can be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present application.

Claims

1. A blockchain-based distributed trusted data space construction method, characterized in that, The method comprises: S1, a participant completes registration under a unique identifier of a data space through a digital identity certificate; S2, a shard blockchain of the data space is dynamically created according to the unique identifier; S3, the participant stores structured data to the corresponding shard blockchain after encryption, to obtain a data block of the structured data; S4, when a cross-shard blockchain data interaction request occurs, a cross-chain verification certificate of the cross-shard blockchain is generated based on zero-knowledge proof, comprising: generating an initial commitment value of the zero-knowledge proof according to a data attribute set of a requester; constructing a proof parameter of the cross-chain verification certificate based on the initial commitment value, comprising: generating a cryptographic base parameter according to a preset elliptic curve base point and order parameter; constructing an attribute binding vector according to the initial commitment value and a target shard identifier; performing scalar multiplication operation on the attribute binding vector through a private key of the requester to generate a random number factor; calculating an elliptic curve bilinear pair mapping value based on the cryptographic base parameter and the random number factor; combining the bilinear pair mapping value and the attribute binding vector to form the proof parameter of the cross-chain verification certificate; inputting the proof parameter into a non-interactive proof protocol, and generating the cross-chain verification certificate of the cross-shard blockchain through a pre-defined cryptographic rule in the non-interactive proof protocol; S5, completing data interaction of the shard blockchain through the cross-chain verification certificate, and generating an interaction audit record of the data interaction; S6, periodically aggregating a state hash of the shard blockchain and the interaction audit record, and updating a global state snapshot under the unique identifier.

2. The blockchain-based distributed trusted data space construction method of claim 1, wherein, The participant completes registration under a unique identifier of a data space through a digital identity certificate, comprising: defining a boundary of the data space, and generating a unique identifier of the data space; generating a distributed identity certificate file of the participant through the unique identifier. 3.The blockchain-based distributed trusted data space construction method of claim 1, wherein, The shard blockchain of the data space is dynamically created according to the unique identifier, comprising: dividing the shard blockchain of the data space based on a hash value of the unique identifier; dynamically adjusting a node number of the shard blockchain according to real-time data load. 4.The blockchain-based distributed trusted data space construction method of claim 1, wherein, The bilinear pair mapping value and the attribute binding vector are combined to form the proof parameter, wherein a calculation formula of the proof parameter is as follows: wherein, is the proof parameter, is a bilinear pair mapping function, is the private key, is the cryptographic base parameter, is an elliptic curve hash-to-point function, is the attribute binding vector. 5.The blockchain-based distributed trusted data space construction method of claim 4, wherein, The proof parameter is inputted into a non-interactive proof protocol, and the cross-chain verification certificate of the cross-shard blockchain is generated through a pre-defined cryptographic rule in the non-interactive proof protocol, wherein a calculation formula of the cross-chain verification certificate is as follows: wherein is the cross-chain verification credential, is an anti-collision hash function, is the initial commitment value, is the proof parameter, is a concatenation operator, is a modulo operator, is the elliptic curve base point and order parameter. 6.The blockchain-based distributed trusted data space construction method of claim 1, wherein, The state hash of the shard blockchain and the interaction audit record are periodically aggregated, and a global state snapshot under the unique identifier is updated, comprising: collecting a Merkle root hash value of the shard blockchain according to a preset period; aggregating the Merkle root hash value into a hierarchical state tree; generating a lightweight verification index of the global state snapshot based on the hierarchical state tree; updating the lightweight verification index and the interaction audit record in the unique identifier.

7. The blockchain-based distributed trusted data space construction method of claim 6, wherein, The Merkle root hash value is aggregated into a hierarchical state tree, comprising: freezing a corresponding branch of the hierarchical state tree when an anomaly is detected in the sharded blockchain; triggering reorganization of consensus nodes in the sharded blockchain.

8. A blockchain-based distributed trusted data space construction system, characterized in that, The system is used for implementing the blockchain-based distributed trusted data space construction method of claim 1, and the system comprises: a registration module, configured to complete registration of a participant under a unique identifier of a data space through a digital identity credential; a sharded blockchain creation module, configured to dynamically create a sharded blockchain of the data space according to the unique identifier; a data block generation module, configured to store structured data of the participant to the corresponding sharded blockchain after encryption to obtain a data block of the structured data; a cross-chain verification credential generation module, configured to generate a cross-chain verification credential of cross-sharded blockchains based on zero-knowledge proof when a cross-sharded blockchain data interaction request occurs; a data interaction module, configured to complete data interaction of the sharded blockchains through the cross-chain verification credential and generate an interaction audit record of the data interaction; a global state snapshot update module, configured to periodically aggregate a state hash of the sharded blockchains and the interaction audit record and update a global state snapshot under the unique identifier.

Images