Distributed trusted data space construction method and system based on block chain

Abstract

The invention relates to the technical field of data processing, and discloses a distributed trusted data space construction method and system based on a block chain, and the method comprises the steps: enabling a participant to complete registration under a unique identifier of a data space through a digital identity certificate; dynamically creating a fragment block chain of the data space according to the unique identifier; the participant encrypts structured data and stores the encrypted structured data to the corresponding fragmented block chain to obtain a data block of the structured data; when a data interaction request of the cross-fragment block chain appears, generating a cross-chain verification certificate of the cross-fragment block chain based on zero-knowledge proof; data interaction of the fragmented block chain is completed through the cross-chain verification certificate, and an interaction audit record of the data interaction is generated; periodically aggregating the state hash of the fragmented block chain, and updating the global state snapshot under the unique identifier; according to the invention, the security of the trusted data space can be improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and system for constructing a distributed trusted data space based on blockchain. Background Technology

[0002] In the field of building a trusted data space, existing technologies have significant shortcomings in managing participant identities. The lack of a distributed identity authentication mechanism based on a unified identifier makes it difficult to effectively verify the authenticity and uniqueness of participant identities, increasing the risk of identity forgery or impersonation and thus impacting the fundamental trustworthiness of the data space. Simultaneously, in the data storage stage, the encryption and partitioned storage strategies for structured data are inadequate. Data is vulnerable to security threats such as leakage and tampering due to centralized storage or insufficient encryption strength, making it difficult to guarantee the security of the data itself.

[0003] Existing technologies also have limitations in cross-regional data interaction and overall state management. Data interaction across shards or systems lacks efficient verification methods based on zero-knowledge proofs, making it difficult to balance data privacy and integrity during the interaction process, and increasing the risk of data leakage or unauthorized tampering. Furthermore, the monitoring and updating mechanisms for the overall state of the data space are insufficient, lacking periodic state hash aggregation and global snapshot update strategies. This results in poor overall consistency and traceability of the data space, making it impossible to promptly detect and correct abnormal states, further reducing the security and reliability of the trusted data space. Summary of the Invention

[0004] This invention provides a method and system for constructing a distributed trusted data space based on blockchain, the main purpose of which is to solve the problem of low security in trusted data spaces.

[0005] To achieve the above objectives, this invention provides a method for constructing a distributed trusted data space based on blockchain, comprising:

[0006] S1. Participants complete registration using digital identity credentials under a unique identifier in the data space;

[0007] S2. Dynamically create a sharded blockchain for the data space based on the unique identifier;

[0008] S3. The participating parties encrypt the structured data and store it in the corresponding sharded blockchain to obtain the data block of the structured data;

[0009] 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.

[0010] S5. Complete the data interaction of the sharded blockchain through the cross-chain verification credential, and generate the interaction audit record of the data interaction;

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

[0012] In a preferred embodiment, the participants complete registration using digital identity credentials under a unique identifier in the data space, including:

[0013] Define the boundaries of the data space and generate a unique identifier for the data space;

[0014] The unique identifier is used to generate a distributed identity verification file for the participating party.

[0015] In a preferred embodiment, dynamically creating the data space sharding blockchain based on the unique identifier includes:

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

[0017] The number of nodes in the sharded blockchain is dynamically adjusted based on real-time data load.

[0018] In a preferred embodiment, generating a cross-chain verification credential based on zero-knowledge proof when a cross-shard blockchain data interaction request occurs includes:

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

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

[0021] 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.

[0022] In a preferred embodiment, the proof parameters for constructing the cross-chain verification credential based on the initial commitment value include:

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

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

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

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

[0027] The bilinear pair mapping value is combined with the attribute binding vector to form the proof parameters 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 parameters, wherein the proof parameters are calculated using the following formula:

[0029]

[0030] In the formula, For the proof parameters, It is a bilinear pair mapping function. The private key, For the aforementioned cryptographic fundamental parameters, For elliptic curve hashing to point functions, Bind a vector to the attribute.

[0031] In a preferred embodiment, 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. The calculation formula for the cross-chain verification credential is as follows:

[0032]

[0033] In the formula, The cross-chain verification credential, For collision-resistant hash functions, For the initial commitment value, For the proof parameters, For the concatenation operator, The modulo operator, These are the base points and order parameters of the elliptic curve.

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

[0035] The Merkle root hash values ​​of the sharded blockchain are collected at preset intervals;

[0036] The Merkle root hash values ​​are aggregated into a hierarchical state tree;

[0037] A lightweight verification index for generating a global state snapshot is generated based on the hierarchical state tree;

[0038] The lightweight verification index and the interaction audit record are updated in the unique identifier.

[0039] In a preferred embodiment, the step of aggregating the Merkle root hash values ​​into a hierarchical state tree includes:

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

[0041] This triggers the reorganization of consensus nodes in the sharded blockchain.

[0042] To address the aforementioned problems, this invention also provides a blockchain-based distributed trusted data space construction system, the system comprising:

[0043] The sharded blockchain creation module is used to dynamically create a sharded blockchain for the data space based on the unique identifier.

[0044] The data block generation module is used by the participants to encrypt structured data and store it in the corresponding sharded blockchain to obtain data blocks of the structured data.

[0045] The cross-chain verification credential generation module is used to generate cross-chain verification credentials for the cross-shard blockchain based on zero-knowledge proofs when a data interaction request for the cross-shard blockchain occurs.

[0046] The data interaction module is used by the cross-chain verification credential to complete the data interaction of the sharded blockchain and generate the interaction audit record of the data interaction;

[0047] The global state snapshot update module is used to periodically aggregate the state hash of the sharded blockchain with the interaction audit record, and update the global state snapshot under the unique identifier.

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

[0049] 1. This invention, through a registration mechanism combining digital identity credentials and unique identifiers, ensures the credibility and uniqueness of participants' identities, thus building a solid foundation of identity trust for the data space. Simultaneously, by dynamically creating sharded blockchains based on unique identifiers and adjusting the number of nodes according to data load, coupled with encrypted storage of structured data, it significantly improves the security and flexibility of data storage, effectively reducing the risk of data leakage and tampering.

[0050] 2. This invention generates cross-chain verification credentials through zero-knowledge proofs, ensuring efficient data interaction while preventing the leakage of sensitive information. Simultaneously, the generation of interaction audit records enhances the traceability of data operations. Periodically aggregating the hashes of sharded blockchain states and updating the global state snapshot reflects the overall state of the data space in a timely manner, ensuring the consistency and reliability of the data space and further improving the security and robustness of the distributed trusted data space. Attached Figure Description

[0051] Figure 1 A flowchart illustrating a blockchain-based distributed trusted data space construction method according to an embodiment of the present invention;

[0052] Figure 2 A functional block diagram of a blockchain-based distributed trusted data space construction system provided in an embodiment of the present invention;

[0053] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0054] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0055] This application provides a method for constructing a distributed trusted data space based on blockchain. The execution entity of this method includes, but is not limited to, at least one of the following: a server, a terminal, or other electronic devices configured to execute the method provided in this application. In other words, the method can be executed by software or hardware installed on 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 cluster of cloud servers. The server can be an independent server or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0056] Reference Figure 1 The diagram shown is a flowchart illustrating a blockchain-based distributed trusted data space construction method according to an embodiment of the present invention. In this embodiment, the blockchain-based distributed trusted data space construction method includes:

[0057] S1. Participants complete registration using digital identity credentials under a unique identifier in the data space;

[0058] In this embodiment of the invention, the participating party completes registration under a unique identifier in the data space using digital identity credentials, including:

[0059] Define the boundaries of the data space and generate a unique identifier for the data space;

[0060] The unique identifier is used to generate a distributed identity verification file for the participating party.

[0061] Specifically, all data attributes involved in the data space are collected, including the system name that generated the data, the time interval covered by the data, the business domain associated with the data, and the types of participants involved in the data. The specific scope of each attribute is determined. For example, the system name that generated the data is limited to "production management system" and "inventory management system", the time interval covered by the data is limited to "January 1, 2024 to December 31, 2024", the business domain associated with the data is limited to "product production" and "inventory scheduling", and the types of participants involved in the data are limited to "manufacturing enterprises" and "logistics enterprises". These determined attribute scopes together constitute the boundary of the data space.

[0062] Furthermore, the specific ranges of each attribute constituting the boundary of the data space are concatenated into a string in a fixed order of "system name + time interval + business domain + participant type", such as "production management system inventory management system 20240101-20241231 product production inventory scheduling production enterprise logistics enterprise". The string is processed using the SHA-1 hash algorithm to obtain a 160-bit binary value, and then the binary value is converted into a 40-bit hexadecimal string. This hexadecimal string is the unique identifier of the data space.

[0063] Furthermore, participants submit their basic information, including their legal name, unified social credit code, registered address, and specific role in the data space. The system associates this basic information with the unique identifier of the data space and generates a text file in the format of "unique identifier + legal name of participant + unified social credit code + registered address + role". Then, the system encrypts the text file using the participant's private key. The encryption process involves using the private key to calculate the ASCII code value corresponding to each character in the text file to obtain the encrypted characters. The file composed of all the encrypted characters is the participant's distributed identity verification file.

[0064] In summary, by defining the boundaries of the data space and generating unique identifiers, the scope and subjects of the data space are clarified, providing a unified benchmark for the identity management of participating parties and ensuring the standardization and consistency of the identity system within the data space.

[0065] In summary, generating distributed identity verification files for participants based on unique identifiers enables distributed verification of participant identities. This ensures the authenticity and uniqueness of identity information while avoiding the single point of failure or data leakage risks that centralized identity management may bring. It strengthens the trustworthy foundation of the data space from the identity access stage and provides a prerequisite guarantee for the security of subsequent data interaction and storage.

[0066] S2. Dynamically create a sharded blockchain for the data space based on the unique identifier;

[0067] In this embodiment of the invention, the step of dynamically creating the data space sharded blockchain based on the unique identifier includes:

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

[0069] The number of nodes in the sharded blockchain is dynamically adjusted based on real-time data load.

[0070] Specifically, a unique identifier for the data space is obtained. This identifier is a 40-digit hexadecimal string and is treated as a hash value. The fixed number of sharded blockchains is set to 8, and each sharded blockchain corresponds to a number from 0 to 7. The hexadecimal hash value is converted into a decimal number, and this decimal number is divided by 8. The remainder is the sharded blockchain number to which the data space should belong. The data space is then allocated to the corresponding sharded blockchain according to this number, thus completing the sharded blockchain partitioning of the data space based on the hash value of the unique identifier.

[0071] Furthermore, the load of each shard blockchain is monitored in real time. The monitoring includes the number of data transactions processed per second and the total amount of data currently stored. The load limit for each node is set at 100 transactions per second and a total data storage of no more than 500GB. When the real-time data transaction volume of a shard blockchain exceeds 100 transactions per node for 30 consecutive seconds, or the total data storage exceeds 500GB per node, a node in normal condition is selected from the standby node pool and added to that shard blockchain. The number of nodes added is the rounded-up result of the ratio of the current load exceeding the upper limit to the single node load limit. When the real-time data transaction volume of a shard blockchain is lower than 50 transactions per node for 5 consecutive minutes, and the total data storage is lower than 200GB per node, the node with the fewest transactions processed in the last 30 minutes is selected from that shard blockchain, removed from the shard blockchain, and added to the standby node pool. The number of nodes reduced is the rounded-down result of the ratio of the current load below the lower limit to the single node load limit. This achieves dynamic adjustment of the number of nodes in the shard blockchain based on the real-time data load.

[0072] In summary, dividing blockchains into shards based on unique identifier hash values ​​can allocate data and resources in the data space in an orderly manner according to the identifier characteristics, ensuring a balance between the independence and relevance of each shard blockchain. This provides a reasonable structural foundation for distributed data storage and improves the orderliness and targeting of data management.

[0073] In summary, dynamically adjusting the number of nodes in the sharded blockchain based on real-time data load allows for flexible adaptation to changing data processing needs. When the load increases, adding nodes enhances processing capacity; when the load decreases, reducing nodes avoids resource waste. This ensures efficient data processing while optimizing resource utilization. Furthermore, the dynamic adjustment mechanism strengthens the resilience of the entire data space to sudden data fluctuations, further solidifying the stability and reliability of the distributed system.

[0074] S3. The participating parties encrypt the structured data and store it in the corresponding sharded blockchain to obtain the data block of the structured data;

[0075] In this embodiment of the invention, the participants first standardize and organize the structured data to be stored. This data is presented in a fixed-format table, which contains at least 5 core fields, such as "Data Number" (text type, consisting of 8 digits), "Data Content" (string type, no more than 200 characters in length), "Data Source" (text type, filling in the name of the specific department that generated the data), "Data Creator" (text type, filling in the name of the operator), and "Data Status" (enumeration type, containing only three options: "Valid", "Pending Review", and "Invalid"). Each field must be filled in completely and in accordance with the format requirements, and empty values ​​or incorrectly formatted content are not allowed.

[0076] Specifically, each participant extracts a private key from its distributed identity verification file. This private key is a 64-bit hexadecimal string, which is converted into a 32-byte binary sequence. Each byte is then converted into a corresponding decimal value, forming a key list containing 32 decimal numbers. Subsequently, each field value in the structured data is encrypted character by character. The first character of the field value is taken, converted into a decimal ASCII code, and summed with the first value in the key list. If the result is greater than 127, 128 is subtracted from the result to obtain a new ASCII code. This new ASCII code is then converted into the corresponding character, which serves as the encryption result for that character. The second character of the field value is processed using the second value in the key list in the same way, and so on. If the length of a field value exceeds 32 characters, the values ​​in the key list are used cyclically until all characters are encrypted. Finally, encrypted structured data is formed, whose field structure is consistent with the original data, but the field values ​​are all encrypted characters.

[0077] Furthermore, participants can query the corresponding shard blockchain through the system's built-in shard blockchain mapping service. This service stores a table that maps unique identifiers of data spaces to shard blockchain numbers. After a participant inputs the unique identifier of the data space (a 40-digit hexadecimal string), the mapping service will immediately return the corresponding shard blockchain number (an integer between 0 and 7). The participant then determines the network address of the target shard blockchain based on this number. This address is a URL format containing "shard number.blockchain cluster domain name", such as "3.shardblockchain.example.com".

[0078] Furthermore, the participants concatenate the encrypted structured data, the current timestamp accurate to milliseconds (in the format "YYYYMMDDHHMMSSmmm"), the public information in the distributed identity verification 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 value". The data packet is encapsulated in JSON format, where each part exists as an independent key-value pair with the key names "timestamp", "publicInfo", "encryptedData", and "previousHash" respectively.

[0079] Furthermore, the participating party sends the aforementioned data packet to the receiving port (port number is fixed at 8080) of any node in the target sharded blockchain via the HTTPS protocol. After receiving the data packet, the node first verifies whether the data packet format 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 participating party's distributed identity certificate file stored in the system to ensure that the hash values ​​of the legal name and unified social credit code are completely consistent. Next, it verifies whether the hash value of the previous block is the same as the hash value of the current blockchain's end block; if they are different, it refuses to receive it. After all verifications are passed, the node marks the data packet as pending confirmation and synchronizes the data packet with the other 3 nodes in the sharded blockchain. After the other nodes complete the same verification and return confirmation information, the node adds the data packet to the end of the blockchain, forming a new data block. This data block contains all the contents of the data packet and generates its own hash value (obtained by SHA-256 processing of the entire data packet content). It also updates the end block identifier of the sharded blockchain to this new data block. At this point, the data block of the structured data is officially 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 parameters, wherein the calculation formula for the proof parameters is as follows:

[0094]

[0095] In the formula, For the proof parameters, It is a bilinear pair mapping function. The private key, For the aforementioned cryptographic fundamental parameters, For elliptic curve hashing to point functions, Bind a vector to the attribute.

[0096] The proof parameters are input into a non-interactive proof protocol, and a cross-chain verification credential across the sharded blockchain is generated using predefined cryptographic rules in the non-interactive proof protocol. The calculation formula for the cross-chain verification credential is as follows:

[0097]

[0098] In the formula, The cross-chain verification credential, For collision-resistant hash functions, For the initial commitment value, For the proof parameters, For the concatenation operator, The modulo operator, These are the base points and order parameters of the elliptic curve.

[0099] Specifically, the requesting party compiles its own set of data attributes, which includes five specific attributes: data type (fixed to "product inventory data"), data range (fixed to "July 1, 2024 to July 15, 2024"), data owner (fixed to "XX Company Production Department"), data sensitivity (fixed to "internal public"), and data integrity check value (fixed to "7A3F9C2D"). Each attribute exists in text form and is formatted according to specifications. The requesting party arranges these attributes in a fixed order of "data type, data range, data owner, data sensitivity, and data integrity check value" to generate a list containing all attributes. Then, it obtains a pre-generated random number seed from the system. This seed is a 64-bit string, and the random number seed is concatenated with each attribute in the list. Next, new string combinations are formed. For example, the random number seed is concatenated with the attribute "product inventory data" to form "ABC123DEF456GHI789JKL012MNO345PQR678STU901VWX234YZA567 product inventory data". Each newly generated string combination is hashed. The hashing process is to convert the string into binary data and then iterate through the binary data multiple times using a specific hash 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 then concatenated into a new string. This new string is hashed a second time in the same way as the first time. The final 256-bit hash value is the initial commitment value of the zero-knowledge proof.

[0100] Further, the system obtains the initial commitment value, which is a 256-bit hash string. This value is converted to binary format and divided into 32 byte groups of 8 bits each. The system retrieves the base point information of the elliptic curve from a pre-configured cryptographic parameter library. This base point information includes the X and Y coordinates of the base points, both large integers. Each byte group of the initial commitment value is converted to its corresponding decimal value. These decimal values ​​are then used to perform point-by-point multiplication operations on the base points of the elliptic curve. The operation involves performing multiple calculations on the base point coordinates according to specific point multiplication rules on the elliptic curve. Each calculation uses the decimal value corresponding to one byte group as the multiplier. For example, the first byte group corresponds to a decimal value... If the base value is 156, the base point coordinates are subjected to 156 specific point addition operations 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 they were 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. This new string is encoded by converting each character in the string to its corresponding ASCII code, and then converting the ASCII code to a Base58 encoded character. The final encoded result is the proof parameter of the cross-chain verification credential.

[0101] Further, the proof parameters are input into the processing module of the non-interactive proof protocol. This module first performs format verification on the proof parameters, checking whether they conform to the Base58 encoding rules. After successful verification, the module obtains a preset verification key from the protocol's cryptographic rule base. This key is a structure containing multiple parameters, including elliptic curve parameters, generators, and common verification points. The module parses the proof parameters according to specific rules, decomposing them into 32 sub-parameters. A specific cryptographic transformation is performed on each sub-parameter. The transformation process includes converting the sub-parameter into a point on a specific elliptic curve, performing a series of point addition and point multiplication operations on that point, and using the parameters in the verification key to transform the sub-parameters. The verification process involves comparing and calculating the sub-parameters with their corresponding parameters in the verification key, checking whether they satisfy predefined equations, summarizing the verification results of all sub-parameters, and generating credential data containing the verification result, a millisecond-accurate timestamp "20250712153045678", and the protocol identifier "ZK-ICV-2025". This credential data is then digitally signed using a specific private key to encrypt the credential data, generating a 64-byte signature value. The credential data and the signature value are combined into a complete data packet, which serves as the cross-chain verification credential across sharded blockchains.

[0102] Specifically, the preset elliptic curve base point is coordinates (X0, Y0), and the order parameter is a 128-bit decimal integer. The base point X0 and Y0 are converted into binary form, and 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 before the binary string to form a combined binary string. This combined binary string is then hashed. The hashing process involves grouping the binary string into 64-bit groups, performing an XOR operation on each group, and then concatenating them. This operation is repeated three times to obtain three 256-bit hash values. These 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), derived point R (X2, Y2)". The coordinates of derived point Q are derived from the first hash value, the coordinates of derived point R are derived from the second hash value, and the third hash value is used as a check value. This set is the basic cryptographic parameter.

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

[0104] Furthermore, the private key of the requester is a 64-bit hexadecimal string. This private key is converted into a decimal integer s. The attribute binding vector is an array containing 9 integers [v1, v2, v3, v4, v5, v6, v7, v8, v9]. Scalar multiplication is performed on each element in the vector. The operation process is to multiply the integer s by each element vi to obtain the product s*vi. Each product is divided by the order parameter, and the remainder is taken as the operation result, resulting in 9 new integers [r1, r2, r3, r4, r5, r6, r7, r8, r9]. These 9 integers are concatenated into a string in order, and the string is hashed to generate a 256-bit hash value, which is the random number factor.

[0105] Furthermore, the cryptographic fundamental parameters include a base point P, an order n, a derived point Q, and 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 fundamental parameters. The scalar multiplication result of point P and the random number factor r is calculated to obtain point P'. The calculation method involves performing multiple elliptic curve point addition operations on point P based on the value of r. Similarly, the scalar multiplication result of the derived point Q and the random number factor r is calculated to obtain point Q'. Using the elliptic curve bilinear pairing mapping rule, points P' and Q' are mapped. The mapping process involves substituting the coordinates of the two points into a preset mapping formula, combining the coordinate values, and performing specific mathematical transformations to obtain a mapping result value. The same method is then used to process the base point P and the derived point R to obtain a second mapping result value. The two mapping result values ​​are concatenated to form a 512-bit string, which is the elliptic curve bilinear pairing mapping value.

[0106] Further, the bilinear pairing mapping value is a 512-bit string, and the attribute binding vector is an array containing 9 integers [v1,v2,v3,v4,v5,v6,v7,v8,v9]. Each integer in the attribute binding vector is converted into a 32-bit hexadecimal string, and they are concatenated in order to form a 288-bit string. This string is then concatenated with the bilinear pairing mapping value in the order of "bilinear pairing mapping value + attribute binding vector string" to form an 800-bit combined string. This combined string is then Base64 encoded. The encoding process involves converting the string into corresponding Base64 characters in groups of 6, with any part less than 6 characters padded with padding characters. The resulting encoded string is the proof parameter of the cross-chain verification credential.

[0107] Specifically, in the formula for calculating the proof parameters, the sources of the parameters in the formula are as follows: The private key, also known as the private key, is the private key contained in the requester's distributed identity verification file. It is a decimal integer converted from a 64-bit hexadecimal string. The cryptographic fundamental parameters are the basic points in the cryptographic fundamental parameters generated by the preset elliptic curve base points and order parameters, and their coordinates are determined by the preset X0 and Y0; H is the elliptic curve hash to point function, which is a predefined cryptographic function that converts attribute binding vectors into points on the elliptic curve. The specific process is to receive an array of attribute binding vectors, convert the array elements into strings, perform hash processing, and then convert the hash values ​​into point coordinates on the elliptic curve. The attribute binding vector is an array of nine integers constructed from the initial commitment value and the 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 mapping function is a predefined cryptographic function used to take points on two elliptic curves, combine the coordinates of the points and perform specific mathematical transformations to calculate the bilinear pairing mapping value.

[0108] Furthermore, the significance of the formula lies in mapping the function through bilinear pairing. , private key With cryptographic fundamental parameters The scalar multiplication result, and the attribute-bound vector. The result after hashing to point function H is mapped and used to generate proof parameters. This process verifies the validity of the requester's private key and associates the data attribute information contained in the attribute binding vector with the basic cryptographic parameters, thus enabling the generated proof parameters to... It can uniquely identify the identity of the requester and the data attributes that need to be verified, providing a core basis for the subsequent generation of cross-chain verification credentials, and ensuring that the legitimacy of the requester and the corresponding scope of permissions can be accurately identified when verifying across sharded blockchains.

[0109] Furthermore, the trend of the formula is that when the private key... When changes occur, and The result of scalar multiplication will change accordingly, as it is input into the bilinear pairing mapping function. The change in the first parameter leads to the proof parameter Changes occur; when the attribute is bound to a vector. When changes occur, the result after the hash-to-point function H will change, and the input to the bilinear pairing mapping function will also change. The change in the second parameter also leads to the proof parameter Changes have occurred; while the fundamental parameters of cryptography have changed. For fixed values, the hash-to-point function H and the bilinear pairing mapping function Since it is a predefined fixed function, the parameters are proven. Changes are made only by the private key and property binding vector The changes determine the unique proof parameters for each different combination of private key and attribute binding vector. This ensures the uniqueness of the proof parameters and their strong correlation with the requester and data attributes.

[0110] Specifically, the sources of the parameters in the formula are as follows: In other words, the cross-chain verification credential is the final result obtained through formula calculation; 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 order parameter P are both fixed values, and the operation of the concatenation operator "‖" is also fixed. Therefore, cross-chain verification credentials... The change is solely due to the initial commitment value and proof parameters The changes determine, and each different and Each combination corresponds to a unique This ensures the unique association between cross-chain verification credentials and the requester's data attributes and proof parameters.

[0113] In summary, zero-knowledge proof technology enables validity verification without exposing the requester's specific data content during the generation of cross-chain verification credentials. This ensures the legality of data interaction while maximizing the protection of data privacy, avoiding the risk of sensitive data leakage during cross-chain processes, and building a privacy protection barrier for cross-shard data interaction.

[0114] In summary, proof parameters are constructed based on the initial commitment value, and cross-chain verification credentials are generated through a non-interactive proof protocol. Elliptic curve cryptography and bilinear pairing mapping techniques ensure the unforgeability and verifiability of the verification credentials. This process not only satisfies the data interaction needs between cross-shard blockchains but also guarantees the security and trustworthiness of the interaction process through strict cryptographic rules. Furthermore, it provides reliable verification evidence for subsequent interaction audits, further enhancing the standardization and security of cross-chain operations in the distributed data space.

[0115] S5. Complete the data interaction of the sharded blockchain through the cross-chain verification credential, and generate the interaction audit record of the data interaction;

[0116] In this embodiment of the invention, the requesting party sends the cross-chain verification credential to the verification node of the target shard blockchain. The verification node first checks whether the format of the credential conforms to the predefined Base64 encoding rules. If the format is correct, it extracts the initial commitment value and proof parameter part from the credential and uses the pre-stored elliptic curve base point and order parameter to verify the proof parameter. The verification process involves recalculating the relationship between the initial commitment value and the proof parameter through a bilinear pair mapping function and checking whether the calculation result is consistent with the proof parameter in the credential. At the same time, it verifies whether the initial commitment value matches the data attribute set of the requesting party. If all verifications pass, the node confirms that the cross-chain verification credential is valid and allows the requesting party to access the data in the target shard blockchain.

[0117] Furthermore, after successful verification, the requester sends the data operation request to the target shard blockchain's interface. This request includes the operation type (e.g., query, write), the identifier of the target data, and the specific content of the operation. Upon receiving the request, the interface calls the corresponding processing module based on the operation type. For query operations, the processing module extracts the corresponding data block from the blockchain, decrypts the encrypted data in the data block using the requester's public key, compares the decrypted data with the requester's data attribute set to ensure that the requester has permission to access the data, and returns the data to the requester after successful comparison. For write operations, the processing module encrypts the data in the request according to preset encryption rules, generates a new data block, adds the block to the target shard blockchain, and updates the blockchain's state.

[0118] Furthermore, during the data interaction process, the audit module of the target shard blockchain records every 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 points and order parameters used, etc. Then, it records the detailed content of the data operation request, such as operation type, target data identifier, operation content, etc. For query operations, it records the data extraction time, decryption process, comparison result, etc. For write operations, it records the data encryption process, new block generation time, block addition location on the chain, etc. All recorded information is arranged in chronological order to form a complete operation sequence.

[0119] Furthermore, the audit module organizes the recorded operation sequence to generate a data packet containing all interaction information. This data packet includes the start time, end time, participating node identifiers, hash value of cross-chain verification credentials, operation type, data identifier, operation result, and other information. The data packet is then digitally signed. The signing process involves encrypting the data packet using the audit module's private key to generate a signature value. The data packet and signature value are combined into a complete interaction audit record, which is then stored in a specific block of the target shard blockchain. This block is specifically used to store all data interaction audit records, ensuring the immutability and traceability of the records.

[0120] In summary, cross-chain verification credentials, as trusted credentials generated based on zero-knowledge proofs, can ensure the legitimacy of the identities and data of both parties in cross-shard interactions, provide a reliable verification basis for secure data transmission between different blockchain shards, guarantee the standardization and security of cross-chain operations, and effectively avoid the risks brought about by illegal data interactions.

[0121] In summary, the generation of interaction audit logs fully records key information about cross-chain data interactions, including the interacting parties, content, and time. Leveraging the immutability of blockchain, every cross-chain operation is traceable and auditable. This not only provides a basis for subsequent problem investigation and responsibility determination but also constrains the operational behavior of participating parties through full-process traceability, further strengthening the credibility and transparency of cross-chain interactions in the distributed data space.

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

[0123] In this embodiment of the invention, the periodic aggregation of the state hashes of the sharded blockchain and the updating of the global state snapshot under the unique identifier includes:

[0124] The Merkle root hash values ​​of the sharded blockchain are collected at preset intervals;

[0125] The Merkle root hash values ​​are aggregated into a hierarchical state tree;

[0126] A lightweight verification index for generating a global state snapshot is generated based on the hierarchical state tree;

[0127] The lightweight verification index and the interaction audit record are updated in the unique identifier.

[0128] The aggregation of the Merkle root hash values ​​into a hierarchical state tree includes:

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

[0130] This triggers the reorganization of consensus nodes in the sharded blockchain.

[0131] Specifically, the system automatically triggers the Merkle root hash value collection operation according to a preset period (fixed at the top of every hour). First, it queries the latest block height of the sharded blockchain to obtain the last block of the current blockchain. The Merkle root hash value is extracted from the header information of this block. This hash value is a 64-bit hexadecimal string. The extracted Merkle root hash value is combined with the collection timestamp (in the format YYYYMMDDHHMMSS) to form a data entry. The data entry format is "timestamp|Merkle root hash value", for example, "20250712150000|ABC123DEF456GHI789". This data entry is stored in a temporary buffer. This process is repeated until the Merkle root hash values ​​of all sharded blockchains within the period are collected.

[0132] Furthermore, the system retrieves all collected Merkle root hash value data entries from the temporary buffer, sorts them according to their timestamps, and groups the sorted entries into groups of 10 (those with fewer than 10 entries are grouped separately). For each group, the Merkle root hash values ​​are hashed together. The aggregation process involves concatenating the 10 hash values ​​in the group into a long string, hashing this string to generate a new hash value, which becomes the parent hash value of that group. The parent hash values ​​of all groups are then grouped again into groups of 10, and the hash aggregation process is repeated to generate higher-level parent hash values. This aggregation continues upwards layer by layer until a root hash value is generated. This root hash value is the root node of the hierarchical state tree, and the hash values ​​and node relationships at all levels constitute the complete hierarchical state tree.

[0133] Furthermore, based on the generated hierarchical state tree, the system visits each node sequentially from the root node in a depth-first traversal order, recording the hash value of each node and its position information in the tree. The position information includes the level number and the node's sequence number in the current level. The hash value and position information of each node are combined into an index entry, with the index entry format being "level number | sequence number | hash value", for example, "3|5|ABC123DEF456GHI789". All generated index entries are arranged in ascending order of level number and sequence number to form an ordered index list. This index list is then compressed by merging adjacent index entries with the same prefix, retaining the common prefix part, and only recording the different suffix parts. The compressed index list is the lightweight verification index for the global state snapshot.

[0134] Further, the system obtains the lightweight verification index and the interaction audit record. First, it reads the current index and record data from the storage area corresponding to the unique identifier in the data space. It 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 index version number and timestamp. Similarly, it 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 of records and the latest timestamp. The updated lightweight verification index and interaction audit record are combined in the format "Lightweight Verification Index | Interaction Audit Record". Using the unique identifier in the data space as the key, the combined data is encrypted. The encrypted data is stored back in the storage area corresponding to the unique identifier, completing the update operation of the lightweight verification index and interaction audit record in the unique identifier.

[0135] Specifically, the system monitors the operational status of each shard blockchain in real time. The monitoring includes the consistency of transaction verification results between nodes, the matching degree of block hash values, and the data transmission latency. When it is found that more than one-third of the nodes in a shard blockchain have inconsistent transaction verification results in two consecutive block generation cycles, or that the block hash value does not match the hash value of the corresponding node in the hierarchical state tree, it is determined that there is an anomaly in the shard blockchain. By using the block number and shard identifier of the anomaly, the system locates the branch corresponding to the shard blockchain in the hierarchical state tree. This branch is the complete path from the root node to the node with the latest Merkle root hash value of the shard. The system sends a freeze command to the hierarchical state tree management module. The management module marks all nodes on the branch as "frozen" and sets the status identifier to "unmodifiable". At the same time, it records the freeze time, anomaly type, and branch path information to ensure that no data writing or update operations can be performed on the branch before the reorganization is completed.

[0136] Furthermore, after freezing the corresponding branch of the hierarchical state tree, the system immediately sends a reorganization trigger signal to all consensus nodes in the sharded blockchain. The signal includes the height of the block where the anomaly occurred, the information of the frozen hierarchical state tree branch, and the reorganization start time. Upon receiving the signal, the consensus nodes automatically pause their current transaction processing flow and backtrack from the height of the block where the anomaly occurred to the nearest block without anomalies (i.e., the hash value of this block is consistent across all nodes and matches the record in the hierarchical state tree). Using this block without anomalies as the reorganization starting point, the consensus nodes reread all transaction data from the starting point to before the anomaly occurred and re-verify the validity of each transaction according to the preset consensus algorithm. The validity verification process involves comparing the digital signature of the transaction with the sender's distributed identity verification file, checking the matching of the transaction content with 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 more than two-thirds of the consensus nodes generate the same block hash value, the block corresponding to that hash value is taken as the valid block. The subsequent blocks are reassembled in sequence until the abnormal block is covered. After the reassembly is completed, the consensus node synchronizes the new blockchain sequence to the entire sharded network, updates the hash value of the corresponding branch in the hierarchical state tree, and unfreezes the frozen state of that branch.

[0137] In summary, by collecting Merkle root hash values ​​from sharded blockchains at preset intervals and aggregating them into a hierarchical state tree, combined with interactive audit logs, the operational status and operation trajectory of the data space can be comprehensively integrated. This aggregation method not only preserves the integrity characteristics of each shard's data but also achieves orderly organization of state information through a hierarchical structure, providing a structured foundation for efficient verification of the global state and enhancing the ability to control the overall state of the data space.

[0138] In summary, a lightweight verification index based on a hierarchical state tree, generating a global state snapshot and updating it under a unique identifier, can reflect the latest state of the data space in real time. When an anomaly is detected in a sharded blockchain, the corresponding branch is frozen and consensus node reorganization is triggered, which can promptly curb the spread of the anomaly and ensure system stability. Simultaneously, the updating of the global state snapshot ensures the consistency and traceability of the data space state, providing participants with a trusted global view and further enhancing the reliability and security of the distributed data space.

[0139] like Figure 2 The diagram shown is a functional block diagram of a blockchain-based distributed trusted data space construction system provided in an embodiment of the present invention.

[0140] The blockchain-based distributed trusted data space construction system 100 described in this invention can be installed in an electronic device. Depending on the functions implemented, the blockchain-based distributed trusted data space construction system 100 may 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 described in this invention can also be referred to as units, which are a series of computer program segments that can be executed by the processor of an electronic device and perform a fixed function, 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 a unique identifier in the data space using digital identity credentials.

[0143] The sharded blockchain creation module 102 is used to dynamically create a sharded blockchain for the data space based on the unique identifier;

[0144] The data block generation module 103 is used for the participants to encrypt the structured data and store it in the corresponding sharded blockchain to obtain the data block of the structured data;

[0145] The cross-chain verification credential generation module 104 is used to generate cross-chain verification credentials for the cross-shard blockchain based on zero-knowledge proof when a data interaction request for the cross-shard blockchain occurs.

[0146] The data interaction module 105 is used to complete the data interaction of the sharded blockchain using the cross-chain verification credential, and to generate an interaction audit record of the data interaction.

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

[0148] In the several embodiments provided by this invention, it should be understood that the disclosed methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0149] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0150] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

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

[0152] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0153] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for constructing a distributed trusted data space based on blockchain, characterized in that, The method includes: S1. Participants complete registration using digital identity credentials under a unique identifier in the data space; S2. Dynamically create a sharded blockchain for the data space based on the unique identifier; S3. The participating parties encrypt the structured data and store it in the corresponding sharded blockchain to obtain the data block of the structured data; 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. S5. Complete the data interaction of the sharded blockchain through the cross-chain verification credential, and generate the interaction audit record of the data interaction; S6. Periodically aggregate the state hash of the sharded blockchain with the interaction audit record, and update the global state snapshot under the unique identifier.

2. The method for constructing a distributed trusted data space based on blockchain as described in claim 1, characterized in that, The participating parties complete registration using digital identity credentials under a unique identifier in the data space, including: Define the boundaries of the data space and generate a unique identifier for the data space; The unique identifier is used to generate a distributed identity verification file for the participating party.

3. The method for constructing a distributed trusted data space based on blockchain as described in claim 1, characterized in that, The step of dynamically creating the data space sharded blockchain based on the unique identifier includes: A sharded blockchain that divides the data space based on the hash value of the unique identifier; The number of nodes in the sharded blockchain is dynamically adjusted based on real-time data load.

4. The method for constructing a distributed trusted data space based on blockchain as described in claim 1, characterized in that, When a cross-shard blockchain data interaction request occurs, generating a cross-chain verification credential based on zero-knowledge proof includes: Generate an initial commitment value for the zero-knowledge proof based on the requester's set of data attributes; The proof parameters for constructing the cross-chain verification credential are based on the initial commitment value; 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.

5. The method for constructing a distributed trusted data space based on blockchain as described in claim 4, characterized in that, The proof parameters for constructing the cross-chain verification credential based on the initial commitment value include: Generate basic cryptographic parameters based on the preset elliptic curve base points and order parameters; Based on the initial commitment value and the target fragment identifier, construct the attribute binding vector; The requester's private key is used to perform a scalar multiplication operation on the attribute binding vector to generate a random number factor; Based on the cryptographic fundamental parameters and the random number factor, calculate the elliptic curve bilinear pair mapping value; The bilinear pair mapping value is combined with the attribute binding vector to form the proof parameters of the cross-chain verification credential.

6. The method for constructing a distributed trusted data space based on blockchain as described in claim 5, characterized in that, The combination of the bilinear pair mapping value and the attribute binding vector forms the proof parameters, wherein the calculation formula for the proof parameters is as follows: In the formula, For the proof parameters, It is a bilinear pair mapping function. The private key, For the aforementioned cryptographic fundamental parameters, For elliptic curve hashing to point functions, Bind a vector to the attribute.

7. The method for constructing a distributed trusted data space based on blockchain as described in claim 5, characterized in that, The proof parameters are input into a non-interactive proof protocol, and a cross-chain verification credential across the sharded blockchain is generated using predefined cryptographic rules in the non-interactive proof protocol. The calculation formula for the cross-chain verification credential is as follows: In the formula, The cross-chain verification credential, For collision-resistant hash functions, For the initial commitment value, For the proof parameters, For the concatenation operator, The modulo operator, These are the base points and order parameters of the elliptic curve.

8. The method for constructing a distributed trusted data space based on blockchain as described in claim 1, characterized in that, The periodic aggregation of the state hash of the sharded blockchain and the interaction audit records, and the updating of the global state snapshot under the unique identifier, includes: The Merkle root hash values ​​of the sharded blockchain are collected at preset intervals; The Merkle root hash values ​​are aggregated into a hierarchical state tree; A lightweight verification index for generating a global state snapshot is generated based on the hierarchical state tree; The lightweight verification index and the interaction audit record are updated in the unique identifier.

9. The method for constructing a distributed trusted data space based on blockchain as described in claim 8, characterized in that, The aggregation of the Merkle root hash values ​​into a hierarchical state tree includes: When an anomaly is detected in the sharded blockchain, the corresponding branch of the hierarchical state tree is frozen; This triggers the reorganization of consensus nodes in the sharded blockchain.

10. A distributed trusted data space construction system based on blockchain, characterized in that, The system includes: The registration module is used by participants to complete registration using digital identity credentials under a unique identifier in the data space. The sharded blockchain creation module is used to dynamically create a sharded blockchain for the data space based on the unique identifier. The data block generation module is used by the participants to encrypt structured data and store it in the corresponding sharded blockchain to obtain data blocks of the structured data. The cross-chain verification credential generation module is used to generate cross-chain verification credentials for the cross-shard blockchain based on zero-knowledge proofs when a data interaction request for the cross-shard blockchain occurs. The data interaction module is used by the cross-chain verification credential to complete the data interaction of the sharded blockchain and generate the interaction audit record of the data interaction; The global state snapshot update module is used to periodically aggregate the state hash of the sharded blockchain with the interaction audit record, and update the global state snapshot under the unique identifier.

Images