Blockchain-based cross-institutional data trustable sharing exchange method

Abstract

The application discloses a cross-institution data trusted sharing exchange method based on a block chain, and relates to the technical field of data sharing exchange.The method comprises the following steps: in response to a cross-institution data sharing request initiated by a first institution node, generating an encrypted data container based on target data identification and a permission policy, and uploading a notarization hash to a block chain network; performing integrity checking and permission verification on the encrypted data container through a verification smart contract, and generating a verification pass signal; calling a consensus node set to perform a hybrid consensus vote, and generating a consensus confirmation result; triggering a data routing smart contract to extract a sharded storage location index, and sending a data exchange permission ticket to a second institution node; and the second institution node acquires encrypted data shards from a distributed storage system according to the data exchange permission ticket, and performs aggregation decryption to obtain target shared data.

Description

Technical Field

[0001] This invention relates to the field of data sharing and exchange technology, specifically to a blockchain-based method for trusted cross-institutional data sharing and exchange. Background Technology

[0002] In cross-organizational data sharing, data faces security risks such as data leakage, tampering, and unauthorized access once it leaves the data control boundary of the primary organization. Existing data sharing methods typically rely on centralized exchange platforms or simple peer-to-peer transmission protocols. Centralized platform solutions store data centrally; if the platform is attacked or internal management is inadequate, large amounts of sensitive data are at risk of overall leakage. Peer-to-peer transmission methods lack reliable recording and multi-party verification mechanisms for the entire data flow process. Data recipients cannot confirm the integrity and tamper-free nature of the received data, while data providers cannot effectively control the secondary dissemination of data after it has been sent.

[0003] Existing technologies for access control mostly employ static access control lists or pre-shared key systems. These mechanisms lag behind updates in dynamically changing multi-organizational collaborative scenarios, and permission changes often require manual intervention, a cumbersome and error-prone process. Regarding data storage, data is typically encrypted as a whole before direct transmission or storage on a single node. This not only concentrates transmission pressure and weakens recovery capabilities, but also results in coarse-grained encryption, allowing a single decryption credential to retrieve all plaintext data, making the security defenses too weak.

[0004] To address the above issues, it is necessary to solve the problem of ensuring the integrity and verifiability of data throughout the entire chain from sharded encrypted storage to convergence and restoration in a distributed environment; and to solve the problem of how to automatically link access control, data routing and distribution, and decentralized multi-party consensus verification to prevent data from being obtained or tampered with without authorization during the exchange process. Summary of the Invention

[0005] The purpose of this invention is to provide a blockchain-based method for trusted cross-institutional data sharing and exchange, which solves the problems of difficulty in verifying data integrity and difficulty in automatically linking permission control and distribution routing when sharing cross-institutional data in a distributed environment, and realizes fine-grained trusted data exchange.

[0006] To achieve the above objectives, this invention provides the following technical solution: This invention provides a blockchain-based method for trusted cross-institutional data sharing and exchange. By combining encrypted data sharding storage with blockchain-based evidence verification, it achieves trusted data transmission and secure sharing between institutions. The method responds to a cross-institutional data sharing request initiated by a first institution node, generates an encrypted data container based on the target data identifier and permission policy carried in the request, and uploads the evidence hash of the encrypted data container to the blockchain network. Through a verification smart contract deployed on the blockchain network, the encrypted data container undergoes integrity and permission verification, generating a verification pass signal. After obtaining the verification pass signal, the consensus node set in the blockchain network is invoked to perform a hybrid consensus vote on the cross-institutional data sharing request, generating a consensus confirmation result. This multi-node collaborative verification and scoring voting mechanism enhances the non-repudiation and reliability of the sharing operation. Based on the consensus confirmation result, a data routing smart contract is triggered to extract the shard storage location index from the encrypted data container and sends a data exchange permission ticket to a second institution node based on the shard storage location index. The second institution node, based on the data exchange permission ticket, obtains encrypted data shards from the distributed storage system, aggregates and decrypts the encrypted data shards, and obtains the target shared data. The entire exchange process uses a ticket-driven, route-oriented approach to achieve precise location and orderly transmission of fragmented data, improving the security and efficiency of data circulation.

[0007] As a technical solution of this invention, when generating an encrypted data container, the original data corresponding to the target data identifier is subjected to binary stream conversion processing to obtain the original data binary stream; the original data binary stream is divided into multiple data fragments according to a preset fragmentation threshold, and a fragmentation sequence number is assigned to each data fragment; for each data fragment, asymmetric encryption is performed using the public key of the first institutional node to generate an encrypted data fragment; all encrypted data fragments are stored separately on different storage nodes of the distributed storage system, and the storage path and fragmentation sequence number of each encrypted data fragment are recorded to form a fragment storage location index; a hash operation is performed on the fragment storage location index to generate a proof hash. Through fragmented distributed storage and hash-based on-chain proof, the data entity is not exposed on the chain, and the authenticity and integrity of the data are anchored only by an immutable digest.

[0008] Preferably, the shard storage location index is stored in the metadata management node of the distributed storage system in the form of key-value pairs, where the key is the shard sequence number and the value is the corresponding storage path, which facilitates fast routing and retrieval.

[0009] As another technical solution of the present invention, the verification and validation process of the smart contract includes: reading the evidence storage hash from the blockchain network and obtaining the shard storage location index from the distributed storage system; performing hash recalculation on the shard storage location index to obtain the verification hash, and comparing the verification hash with the evidence storage hash to generate an integrity verification result; when the integrity verification result is consistent, the smart contract parses the permission policy in the cross-institutional data sharing request and extracts the whitelist of institutions that are allowed to access; determines whether the identity identifier of the second institution node exists in the institution whitelist and generates a permission verification result; when the permission verification result is passed, a verification pass signal is issued. This process integrates data integrity verification and institutional permission verification into on-chain automated execution, eliminating the risk of data tampering or unauthorized access.

[0010] In hybrid consensus voting, each consensus node in the consensus node set, upon receiving a cross-institutional data sharing request, performs data integrity verification and institution identity verification, generating its own verification score. Each consensus node compares its verification score with a locally pre-stored trust threshold, generating either a vote of approval or a vote of disapproval. The number of votes of approval is counted, and the ratio of the number of votes of approval to the total number of consensus nodes is calculated to obtain the consensus achievement ratio. When the consensus achievement ratio is greater than or equal to a preset consensus threshold, a consensus confirmation result is generated; when the consensus achievement ratio is less than the preset consensus threshold, a consensus failure result is generated, and the cross-institutional data sharing request is marked as rejected. Preferably, the trust threshold is dynamically updated based on the historical voting accuracy and response latency of each consensus node and stored in the trust management contract of the blockchain network, ensuring that voting weights are linked to the reliability of node behavior and suppressing interference from malicious or inefficient nodes.

[0011] In the data routing and ticket generation phase, after receiving the consensus confirmation result, the data routing smart contract parses the fragment storage location index in the encrypted data container to obtain the storage path list and fragment sequence number list corresponding to the encrypted data fragments. Based on the storage path list, the data routing smart contract sends fragment locking requests to the corresponding storage nodes in the distributed storage system. These requests include the fragment sequence number list and the lock validity period. Storage nodes receiving the fragment locking requests mark the corresponding encrypted data fragments as pending transmission and return a lock confirmation signal. After collecting the lock confirmation signals returned by all storage nodes, the data routing smart contract encapsulates the fragment storage location index into a transmission routing table. This locking mechanism prevents concurrent modification or conflicting reads of data fragments during the exchange process, ensuring the consistency and atomicity of data transmission.

[0012] Furthermore, when sending a data exchange permission ticket to the second institution node based on the transmission routing table, the data routing smart contract generates a temporary session key and encrypts it using the second institution node's public key to obtain an encrypted session key. The transmission routing table, the encrypted session key, and the timestamp of the cross-institutional data sharing request are packaged together to generate a data exchange permission ticket. This ticket is then sent to the second institution node via the blockchain network's peer-to-peer channel. Upon receiving the data exchange permission ticket, the second institution node decrypts it using its private key to obtain the temporary session key. This ticket carries one-time encrypted channel parameters, ensuring that routing information and keys are transmitted only through a trusted channel, preventing man-in-the-middle attacks or replay attacks.

[0013] The process by which the second institutional node obtains the target data includes: parsing the transmission routing table in the data exchange license ticket to obtain a list of storage paths and a list of fragment sequence numbers; based on the list of storage paths, initiating a fragment acquisition request to the corresponding storage node in the distributed storage system, requesting the fragment sequence number list and the hash verification value of the temporary session key; after the storage node verifies that the hash verification value of the temporary session key matches the locally locked matching record, it transmits the corresponding encrypted data fragment to the second institutional node; after receiving all encrypted data fragments, sorting the received encrypted data fragments according to the fragment sequence number list to obtain an ordered encrypted fragment sequence. Then, the encrypted data fragments are aggregated and decrypted: the first encrypted data fragment is extracted from the ordered encrypted fragment sequence, and a first-level decryption is performed using the temporary session key to obtain a primary decrypted data block; then, a second-level decryption is performed using its own private key to obtain the original data fragment; the above two-level decryption is repeated for the remaining encrypted data fragments to obtain all original data fragments; finally, all original data fragments are concatenated and restored according to the order of the fragment sequence number list to obtain the target shared data. By using layered decryption and orderly concatenation, even if the encrypted fragments are intercepted during transmission, attackers cannot restore the original data without the corresponding private key or session key, greatly improving the security of shared data.

[0014] Preferably, when performing asymmetric encryption on data fragments, the local security module of the first institution node is invoked to generate a random encryption factor, and the random encryption factor is concatenated with the data fragment to obtain the data block to be encrypted; the public key of the first institution node is used to encrypt the data block to be encrypted, generating a primary encrypted data fragment; the digital certificate of the second institution node is obtained from the blockchain network, and the public key hash value in the digital certificate is extracted; the primary encrypted data fragment and the public key hash value are XORed to generate an encrypted data fragment. More specifically, the XOR obfuscation process includes: extracting a fixed-length header byte segment from the primary encrypted data fragment as an obfuscation start segment; repeatedly expanding the public key hash value to the same length as the obfuscation start segment to obtain an extended obfuscation mask; performing a bitwise XOR operation on the obfuscation start segment and the extended obfuscation mask to obtain an obfuscated header segment; and concatenating the obfuscated header segment with the remaining unobfuscated tail byte segment in the primary encrypted data fragment to generate the final encrypted data fragment. This encryption and obfuscation method, which combines the characteristics of the target institution's digital certificate, achieves an implicit binding of encrypted data to the designated receiving institution, further enhancing the data leakage prevention capability.

[0015] Overall, this invention achieves automated verification and consensus decision-making through blockchain smart contracts, and completes the secure flow of data between institutions by using sharded encrypted storage and ticket exchange mechanisms. While ensuring data privacy, it improves the trust foundation and operational efficiency of cross-institutional data sharing, and can be applied to scenarios such as government data exchange and consortium blockchain data collaboration.

[0016] The technical effects and advantages provided by the present invention in the above technical solution are as follows: The original data corresponding to the target data identifier undergoes binary stream conversion, is divided into multiple data fragments according to a preset fragmentation threshold, and assigned fragment sequence numbers. For each data fragment, asymmetric encryption is performed using the public key of the first institution node, and a random encryption factor is introduced to XOR the hash value of the public key in the digital certificate of the second institution node to generate an encrypted data fragment. All encrypted data fragments are distributed and stored on different storage nodes of a distributed storage system. The storage path and fragment sequence number of each fragment are recorded to form a fragment storage location index. Only this index is hashed to generate a notarized hash and uploaded to the blockchain network. This method distributes the original data after fine-grained fragmentation and double obfuscation encryption. Even if an attacker controls a single storage node, they can only obtain scattered and isolated fragments after asymmetric encryption and XOR obfuscation, and cannot restore the complete data. Only the notarized hash is stored on the chain, not the original data or metadata itself, achieving separation of data and notarization. Any tampering with the shard storage location index at any stage will be detected by the verification smart contract during hash recalculation comparison, allowing data integrity verification to be independent of reliance on centralized authority.

[0017] During the data exchange execution phase, each node in the consensus node set independently performs data integrity verification and institution identity verification. Combined with a dynamically updated trust threshold, they conduct hybrid consensus voting to generate a consensus confirmation result. The data routing smart contract automatically extracts the shard storage location index based on this consensus confirmation result, generates a transmission routing table, and sends a shard locking request carrying a lock validity period to the corresponding distributed storage node. During the lock validity period, the storage node marks the encrypted data shard as exclusively locked, automatically releasing it after the timeout. The data routing smart contract generates a temporary session key and encrypts it using the public key of the second institution node. This key, along with the transmission routing table and timestamp, is packaged into a data exchange permission ticket and sent to the second institution node via the blockchain network's peer-to-peer channel. After parsing the ticket, the second institution node initiates shard acquisition requests to each storage node. Upon receiving the encrypted data shard, it performs a first-level decryption using the temporary session key and a second-level decryption using its own private key to obtain the original data shard. Finally, it reassembles the target shared data according to the shard sequence number. A decentralized hybrid consensus voting mechanism, linked to data routing smart contracts, ensures that the entire process of data locking, transmission, and decryption is triggered only after multi-party verification and consensus, eliminating single-point decision-making power. A two-layer decryption structure consisting of temporary session keys and institutional private keys, combined with sharded exclusive locking and timeout release mechanisms, strictly controls data transmission credentials and operation time limits. Even if an entity outside the second institutional node intercepts the transmission information, it cannot complete decryption, ensuring that access control and integrity verification in cross-institutional data exchange are automatically enforced without a central coordinator. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0019] Figure 1 This is a flowchart of a blockchain-based cross-institutional data trusted sharing and exchange method; Figure 2 This is a flowchart of the encrypted data container generation process; Figure 3 This is a flowchart of the hybrid consensus voting process. Detailed Implementation

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

[0021] See Figure 1 This invention provides a blockchain-based method for trusted cross-institutional data sharing and exchange, comprising: responding to a cross-institutional data sharing request initiated by a first institutional node, generating an encrypted data container based on the target data identifier and permission policy carried in the cross-institutional data sharing request, and uploading the notarized hash of the encrypted data container to the blockchain network; performing integrity verification and permission verification on the encrypted data container through a verification smart contract deployed on the blockchain network, and generating a verification pass signal; responding to the verification pass signal, calling a set of consensus nodes in the blockchain network to perform a hybrid consensus vote on the cross-institutional data sharing request, and generating a consensus confirmation result; triggering a data routing smart contract to extract a shard storage location index from the encrypted data container, and sending a data exchange permission ticket to a second institutional node based on the shard storage location index; and the second institutional node obtaining encrypted data shards from the distributed storage system according to the data exchange permission ticket, and aggregating and decrypting the encrypted data shards to obtain the target shared data.

[0022] In practical implementation, generating encrypted data containers includes: (See below) Figure 2 The process involves performing binary stream conversion on the original data corresponding to the target data identifier to obtain the original data binary stream. The original data is the data content to be shared by the first organization node, stored in the local database of the first organization node, and retrieved and extracted using the target data identifier. Binary stream conversion refers to reading the original data byte-by-byte and converting it into a continuous binary stream, changing only the representation of the data without altering its content.

[0023] The original binary data stream is divided into multiple data fragments according to a preset fragmentation threshold, and a fragmentation sequence number is assigned to each data fragment. The preset fragmentation threshold is a pre-configured value representing the maximum byte length of a single data fragment, and is stored in the configuration file of the first organizational node. During the fragmentation process, the original binary data stream is sequentially extracted from the beginning position, taking binary segments of the preset fragmentation threshold length. If the length of the last data fragment is less than the preset fragmentation threshold, its actual length is retained. The fragmentation sequence numbers are assigned sequentially, starting from the number 1, according to the order in which the data fragments are generated, and each data fragment corresponds to a unique fragmentation sequence number.

[0024] For each data shard, asymmetric encryption is performed using the public key of the first institution node to generate an encrypted data shard. The specific process of asymmetric encryption includes: calling the local security module of the first institution node to generate a random encryption factor. The local security module is a cryptographic operation unit integrated within the first institution node, possessing random number generation, key management, and encryption / decryption functions. The random encryption factor is a binary sequence generated by a cryptographically secure pseudo-random number generator, with a fixed length of 256 bits. The random encryption factor is then concatenated with the data shard to obtain the data block to be encrypted, with the random encryption factor placed at the beginning of the data shard.

[0025] The public key of the first institution node is used to encrypt the data block to be encrypted, generating a primary encrypted data fragment. The public key of the first institution node belongs to the first institution node's asymmetric key pair, which is pre-signed and published by the first institution node through a certificate authority in the blockchain network. The encryption algorithm uses RSA-2048 or elliptic curve cryptography to perform public key encryption operations on the data block to be encrypted, outputting the primary encrypted data fragment.

[0026] The process involves retrieving the digital certificate of the second-institutional node from the blockchain network and extracting the public key hash value from it. The digital certificate of the second-institutional node serves as its identity credential during registration on the blockchain network. It contains the node's identity identifier and public key and is stored in the blockchain network's certificate management smart contract. The digital certificate is obtained by querying the certificate management smart contract and retrieving the corresponding digital certificate based on the node's identity identifier. Extracting the public key hash value involves hashing the second-institutional node's public key using the SHA-256 algorithm, resulting in a fixed-length 256-bit binary string.

[0027] The initial encrypted data fragment is XORed with the public key hash value to generate another encrypted data fragment. The XOR obfuscation steps are as follows: A fixed-length header byte segment is extracted from the initial encrypted data fragment as the obfuscation start segment. The fixed length is 256 bits, or 32 bytes, the same as the length of the public key hash value. The public key hash value is cyclically extended to the same length as the obfuscation start segment to obtain an extended obfuscation mask. Since the length of the public key hash value is the same as the length of the obfuscation start segment, the cyclical extension process directly uses the public key hash value as the extended obfuscation mask.

[0028] A bitwise XOR operation is performed between the obfuscation start segment and the extended obfuscation mask to obtain the obfuscated header segment. The bitwise XOR operation is a logical operation that performs an XOR operation bit by bit; each bit in the obfuscation start segment is XORed with the corresponding bit in the extended obfuscation mask to obtain the obfuscated header segment. The obfuscated header segment is then concatenated with the remaining unobfuscated tail bytes from the primary encrypted data fragment to generate an encrypted data fragment. The tail bytes are all the remaining bytes from the primary encrypted data fragment after removing the obfuscation start segment. The concatenation order is obfuscated header segment first, followed by tail bytes, resulting in an encrypted data fragment of the same length as the primary encrypted data fragment.

[0029] After all data fragments have been processed and corresponding encrypted data fragments have been generated, all encrypted data fragments are stored separately on different storage nodes of the distributed storage system. The storage path and fragment sequence number of each encrypted data fragment are recorded, forming a fragment storage location index. The distributed storage system consists of multiple physically distributed storage nodes. Each storage node runs a storage service process responsible for receiving and storing encrypted data fragments. The method for distributing encrypted data fragments across different storage nodes is as follows: a storage node is selected sequentially for each encrypted data fragment. The selection strategy can be round-robin or a load-balanced allocation strategy based on storage node load. After each encrypted data fragment is stored, the storage node returns the storage path of that encrypted data fragment in the storage node's local file system. The storage path is a string. A correspondence is established between the fragment sequence number of each encrypted data fragment and its storage path, and all correspondences are aggregated to form a fragment storage location index.

[0030] A hash operation is performed on the shard storage location index to generate a notarization hash. The hash operation uses the SHA-256 algorithm, serializing the shard storage location index into a byte string as input to the hash function to calculate the notarization hash, which is a 256-bit hash value. The notarization hash is then uploaded to the blockchain network by calling a notarization smart contract on the blockchain network. The notarization smart contract records the notarization hash, the corresponding cross-institutional data sharing request identifier, and a timestamp, completing the on-chain notarization.

[0031] The shard storage location index is stored as key-value pairs in the metadata management node of the distributed storage system. The metadata management node is a dedicated node in the distributed storage system responsible for maintaining metadata, and it runs a key-value database. Each shard sequence number in the shard storage location index serves as the key, and the corresponding storage path is used as the value, forming a key-value pair. Multiple key-value pairs form a key-value mapping table, which is stored in the key-value database of the metadata management node. When subsequently reading the shard storage location index, the metadata management node queries the key-value database based on the shard sequence number to return the corresponding storage path.

[0032] In practical implementation, the process of verifying the integrity and permissions of encrypted data containers through verification smart contracts deployed on the blockchain network includes the following implementation methods. The verification smart contract is executable code pre-compiled and deployed on each node of the blockchain network. The verification smart contract internally encapsulates the logic for reading the evidence hash, the logic for accessing the distributed storage system, the logic for hash recalculation, the logic for parsing the permission policy, and the logic for signal generation.

[0033] The verification smart contract reads the evidence hash from the blockchain network. The blockchain network stores evidence-based smart contracts, which maintain an evidence hash mapping table. The key of the mapping table is the cross-institutional data sharing request identifier, and the value is the evidence hash of the corresponding encrypted data container. When the verification smart contract is triggered, it receives the cross-institutional data sharing request as an input parameter, extracts the cross-institutional data sharing request identifier, and then calls the query interface of the evidence-based smart contract. Using the cross-institutional data sharing request identifier as the query key, it reads the evidence hash from the evidence hash mapping table. The read evidence hash is returned as a 64-character hexadecimal string, generated by performing a SHA-256 hash operation on the shard storage location index when the encrypted data container was generated.

[0034] The verification smart contract retrieves shard storage location indexes from the distributed storage system. The smart contract sends an index retrieval request to the metadata management node through the distributed storage system's metadata query interface. This request includes the encrypted data container identifier. The metadata management node runs a key-value database that stores the mapping between encrypted data container identifiers and shard storage location indexes. The metadata management node retrieves the corresponding set of shard storage location indexes from the key-value database based on the encrypted data container identifier. This set consists of multiple key-value pairs, where the key is the shard sequence number and the value is the storage path on the storage node. The metadata management node returns the set of shard storage location indexes to the verification smart contract in a structured data format.

[0035] The verification smart contract recalculates the hash of the shard storage location index to obtain the verification hash. The specific steps of hash recalculation are as follows: The verification smart contract sorts the obtained set of shard storage location indices in ascending order of shard sequence number. It concatenates the shard sequence number and storage path in each key-value pair into a string, connecting the concatenated strings with the separator "|" to form a complete string to be hashed. This string is then used as input to the SHA-256 hash algorithm, which calculates and outputs a 256-bit hash value. This hash value is then converted into a 64-character hexadecimal string, which is the verification hash.

[0036] The smart contract verification compares the verification hash with the evidence-stored hash to generate an integrity verification result. The comparison process involves comparing the verification hash string and the evidence-stored hash string character by character to determine if they are completely equal. The integrity verification result is generated according to the following formula: in, Indicates the integrity verification result. A value of 1 indicates that the fragment storage location index has not been tampered with and is complete and error-free. A value of 0 indicates that the fragment storage location index has been tampered with or is missing; The verification hash is obtained by the verification smart contract through hash recalculation of the obtained shard storage location index; This represents the evidence storage hash, which is obtained by the verification smart contract from the evidence storage smart contract on the blockchain network. When When the integrity verification result is consistent, the smart contract continues to execute the subsequent permission verification process; when If the integrity verification result is inconsistent, the verification smart contract terminates the current verification process and generates an integrity verification failure signal.

[0037] When the integrity verification result is consistent, the verification smart contract parses the permission policy in the cross-institutional data sharing request and extracts the whitelist of authorized institutions. The cross-institutional data sharing request contains a permission policy field, organized as a JSON object containing an array with the key "whitelist," where each element is an identifier string representing an authorized institution. The verification smart contract calls the JSON parser to parse the permission policy field, reads the value corresponding to the "whitelist" key, and obtains the institution whitelist, which is a list of identifier strings.

[0038] The system determines whether the identity identifier of the second institution node exists in the institution whitelist and generates an authorization verification result. The identity identifier of the second institution node is its registered identity string in the blockchain network, issued by a certificate authority and contained in its digital certificate. The cross-institutional data sharing request also includes the identity identifier field of the second institution node. The verification smart contract extracts the identity identifier of the second institution node from the cross-institutional data sharing request, then iterates through the institution whitelist, performing an exact match between the second institution node's identity identifier and each identity identifier string in the list. If an identity identifier string in the institution whitelist is found to be exactly the same as the second institution node's identity identifier, the authorization verification result is passed; otherwise, if no match is found after iterating through the list, the authorization verification result is failed.

[0039] When the permission verification result is successful, the verification smart contract issues a verification pass signal. The verification pass signal is issued as follows: the verification smart contract calls the log event interface provided by the blockchain platform, triggering an event named "ValidationPassed". The payload data of this event includes the cross-institutional data sharing request identifier, the identity identifier of the second institution node, and the current block timestamp. This event is listened to by the consensus node set in the blockchain network and used to drive the subsequent hybrid consensus voting process. When the permission verification result is unsuccessful, the verification smart contract triggers an event named "ValidationFailed". The payload includes the rejection reason code and the cross-institutional data sharing request identifier, and marks the cross-institutional data sharing request as a verification rejection status.

[0040] In specific implementation, please refer to Figure 3 The process of invoking a set of consensus nodes in a blockchain network to execute a hybrid consensus vote on a cross-institutional data sharing request involves multiple processing steps. The consensus node set consists of a group of nodes in the blockchain network with consensus permissions. Each consensus node maintains the same copy of the blockchain ledger and runs the hybrid consensus voting protocol. The cross-institutional data sharing request is broadcast to the consensus node set after a verification pass signal is issued by the verification smart contract, and each consensus node independently performs subsequent processing.

[0041] Each consensus node in the consensus node set, upon receiving a cross-institutional data sharing request, performs data integrity verification and institutional identity verification, generating its own verification score. The data integrity verification process is as follows: The consensus node reads the evidence hash from the blockchain network. The evidence hash can be obtained from the evidence smart contract through the cross-institutional data sharing request identifier. The consensus node obtains the shard storage location index from the distributed storage system by sending an index retrieval request to the metadata management node. The metadata management node returns a set of key-value pairs consisting of shard sequence numbers and storage paths. The consensus node sorts the obtained shard storage location indexes in ascending order of shard sequence numbers, concatenates each shard sequence number with a storage path, and connects the concatenation results with a delimiter to form a string to be hashed. Then, it uses the SHA-256 algorithm to recalculate the hash of the string to be hashed to obtain the verification hash. The consensus node compares the verification hash with the evidence hash. If they are identical, the data integrity verification result is passed; if they differ, the data integrity verification result is failed.

[0042] The institutional authentication process is as follows: consensus nodes parse the permission policy field in the cross-institutional data sharing request. The permission policy field is organized in JSON format and contains an array with the key "whitelist". The array elements are strings representing the institutional identity identifiers allowed to access the system. Consensus nodes extract the institutional whitelist from the permission policy field. Consensus nodes extract the identity identifiers of the second institutional nodes from the cross-institutional data sharing request and then check each identity identifier in the institutional whitelist to see if it is completely consistent with the identity identifier of the second institutional node. If a match is found, the institutional authentication result is successful; otherwise, the institutional authentication result is unsuccessful.

[0043] The verification score is generated as follows: consensus nodes assign an integer value as the verification score based on the data integrity verification result and the institution authentication result. In one scoring rule, the verification score is set to 100 when both data integrity verification and institution authentication pass; the verification score is set to 50 when data integrity verification passes but institution authentication fails; and the verification score is set to 0 regardless of the institution authentication result when data integrity verification fails.

[0044] Each consensus node compares its verification score with a locally pre-stored trust threshold to generate a vote. The locally pre-stored trust threshold is a value read from the blockchain network's trust management contract and cached locally on the consensus node. The trust threshold is set independently for each consensus node, and different consensus nodes may have different trust thresholds. During the comparison, if the verification score is greater than or equal to the trust threshold, the consensus node generates a "yes" vote; if the verification score is less than the trust threshold, the consensus node generates a "no" vote.

[0045] The consensus achievement rate is determined by counting the number of affirmative votes in the consensus node set and calculating the ratio of these votes to the total number of consensus nodes. The master node or any designated counting node in the consensus node set collects the voting results submitted by all consensus nodes, counts the affirmative votes, and obtains the total number of affirmative votes. Total number of consensus nodes The number of consensus nodes participating in this round of hybrid consensus voting is defined in the blockchain network configuration and determined by the consensus node set through negotiation each time voting begins. The consensus achievement rate is expressed by the following formula: in, Indicates the percentage of consensus reached. Let be a real number, and its range is 1. ; This indicates the number of affirmative votes received. It is an integer, and its value range is 1. ; This represents the total number of consensus nodes participating in this round of hybrid consensus voting. It is a fixed positive integer.

[0046] A consensus confirmation result is generated when the consensus achievement rate is greater than or equal to a preset consensus threshold. The preset consensus threshold is set to... This value is determined based on the security conditions of Byzantine fault-tolerant consensus: in the presence of malicious nodes, to ensure the eventual consistency and security of the consensus result, more than two-thirds of honest nodes need to reach a consensus. Therefore, the preset consensus threshold is set to [value missing]. .when When a sufficient number of votes have been received, a consensus confirmation result is generated, which will serve as the input for triggering the data routing smart contract.

[0047] When the consensus rate is less than a preset consensus threshold, a consensus failure result is generated, and the cross-institutional data sharing request is marked as rejected. Specifically, the statistics node generates a rejection status identifier, associates this identifier with the cross-institutional data sharing request identifier, writes it into the blockchain's transaction receipt, and notifies the first institution node that the sharing request has been rejected.

[0048] The trust threshold is dynamically updated based on the historical voting accuracy and response latency of each consensus node and stored in the trust management contract of the blockchain network. The trust management contract is a smart contract deployed on the blockchain network. Internally, it maintains a trust record table. Each record in the trust record table corresponds to the identity of a consensus node, and the record content includes the node's historical voting accuracy parameter, average response latency parameter, and current trust threshold. The historical voting accuracy parameter refers to the proportion of times a consensus node's voting results match the final consensus confirmation result or consensus failure result in all rounds of hybrid consensus voting it has participated in. The historical voting accuracy parameter is obtained by dividing the number of accurate votes by the total number of votes. The average response latency parameter is the arithmetic mean of the time difference between the moment a consensus node receives a cross-institutional data sharing request and the moment it submits its vote. The unit of the average response latency parameter is milliseconds.

[0049] The trust management contract performs a trust threshold update calculation for each consensus node at the end of each preset update cycle. The preset update cycle can be set to occur once every 100 new blocks generated. The update calculation process is as follows: the trust management contract reads the historical voting accuracy parameters of the consensus nodes. and average response delay parameter Then, a maximum response delay constant is introduced. , Setting it to 10000 milliseconds represents the maximum response latency allowed by the consensus node in the blockchain network. This is achieved using the first weighting factor. and Multiply, using the second weighting factor and Multiply the two parts and add them together to obtain the updated trust threshold. First weighting factor. Set to 0.6, the second weighting factor The threshold is set to 0.4, based on the principle that historical voting accuracy is more important than response latency in measuring the honesty of node behavior; therefore, a greater weight is given to the historical voting accuracy parameter. The updated trust threshold is written back to the trust record table of the trust management contract, so that each consensus node can read and pre-store it locally before the next round of voting.

[0050] In practice, the process of triggering the data routing smart contract to extract the shard storage location index from the encrypted data container is as follows: The data routing smart contract is deployed on the blockchain network. It listens for the output event of the consensus confirmation result. Upon receiving the consensus confirmation result, the data routing smart contract parses the data within the encrypted data container. The encrypted data container has already encapsulated the shard storage location index during the generation phase. The data routing smart contract reads the corresponding field from the encrypted data container and extracts the shard sequence number list and the storage path list. The shard sequence number list consists of all shard sequence numbers arranged in ascending numerical order. Each storage path in the storage path list corresponds one-to-one with a shard sequence number; the storage path is the file location path of the encrypted data shard on the storage node of the distributed storage system.

[0051] The data routing smart contract sends a shard lock request to the corresponding storage node in the distributed storage system based on the storage path list. For each storage path in the list, the data routing smart contract parses the network address of the storage node and generates a shard lock request message. The shard lock request message contains a list of shard sequence numbers and a lock expiration timestamp. The lock expiration timestamp is calculated by the data routing smart contract based on the current block timestamp and the preset lock duration, using the following formula: in, This indicates that the deadline timestamp is locked. Expressed using Unix timestamps, in seconds; This represents the timestamp of the current block obtained by the data routing smart contract, in seconds. Indicates the preset lock duration. The preset lock duration is set to 1800 seconds. This setting is based on the fact that the typical time for cross-organizational data fragmentation transmission and aggregation decryption does not exceed a few minutes. Taking into account network jitter and possible data retransmission overhead, the preset lock duration is configured to 1800 seconds to cover the entire transmission window.

[0052] Upon receiving a fragment locking request, the storage node parses the lock expiration timestamp and fragment sequence number list from the request. The storage node retrieves the encrypted data fragment corresponding to each fragment sequence number in the local file system, changes the storage status of the encrypted data fragment from readable to exclusive locked, and records the lock expiration timestamp as the basis for lock expiration. After completing the status marking, the storage node generates a lock confirmation signal, which contains the storage node's identity and the list of locked fragment sequence numbers. The storage node returns the lock confirmation signal to the data routing smart contract. For the entire period before the lock expiration timestamp arrives, the storage node maintains the encrypted data fragments in an exclusive locked state, blocking read requests. Once the system time exceeds the lock expiration timestamp and the storage node has not received a release instruction from the data routing smart contract, the storage node automatically restores the encrypted data fragments to a readable state, releasing the exclusive lock.

[0053] The data routing smart contract collects lock confirmation signals returned by all storage nodes. Once every storage node in the storage path list has returned a lock confirmation signal, the data routing smart contract encapsulates the shard storage location index to form a transmission routing table. The transmission routing table is a structured data object that records the shard sequence number list, the storage path list, and the lock confirmation status identifier of each storage node.

[0054] In practice, the process of sending a data exchange permit to the second institution node based on the shard storage location index is as follows: The data routing smart contract generates a temporary session key based on the transmission routing table. The data routing smart contract calls its own cryptographic module to generate a 256-bit random byte sequence as the temporary session key, which is used for subsequent symmetric encryption protection of the encrypted data shards. The data routing smart contract obtains the digital certificate of the second institution node from the certificate management smart contract of the blockchain network and extracts the public key of the second institution node from the digital certificate. The data routing smart contract uses the public key of the second institution node to perform asymmetric encryption on the temporary session key. The encryption algorithm used is the same RSA-2048 algorithm used when generating the encrypted data shards, and the output is the encrypted session key.

[0055] The data routing smart contract packages the transport routing table, the encrypted session key, and the timestamp of the cross-organization data sharing request into a data exchange license ticket. The timestamp of the cross-organization data sharing request comes from the request timestamp field filled in by the first organization node when initiating the request. The packaging method involves constructing a JSON data object containing three key-value pairs: the key "routingtable" corresponds to the transport routing table, the key "encryptedsessionkey" corresponds to the Base64 encoded string of the encrypted session key, and the key "requesttimestamp" corresponds to the timestamp of the cross-organization data sharing request. The JSON data object is then serialized into a UTF-8 byte string to obtain the data exchange license ticket.

[0056] The data routing smart contract sends the data exchange permission ticket to the second institution node through the peer-to-peer channel of the blockchain network. The peer-to-peer channel of the blockchain network is an encrypted transmission link established between the consensus node and each institution node. The data routing smart contract queries the peer-to-peer channel list based on the identity of the second institution node, locates the connection with the second institution node, and sends the data exchange permission ticket to the second institution node along the connection.

[0057] After receiving the data exchange license ticket, the second agency node parses it and extracts the encrypted session key field. The second agency node then invokes its local security module to decrypt the encrypted session key using its private key. The decryption algorithm corresponds to the public key encryption algorithm used to generate the encrypted session key. The second agency node's private key is stored in its local security module and is prohibited from being exported. The decryption operation is completed internally within the local security module, yielding a temporary session key plaintext. The second agency node temporarily stores this temporary session key plaintext in a secure memory area for subsequent decryption of encrypted data fragments retrieved from the distributed storage system.

[0058] In practice, the process by which the second agency node retrieves encrypted data fragments from the distributed storage system based on the data exchange license ticket is as follows: The second agency node parses the data exchange license ticket, which is a JSON format data object. The second agency node extracts the transport routing table corresponding to the key "routingtable," and obtains a list of storage paths and a list of fragment sequence numbers from the transport routing table. The list of storage paths is an ordered set of multiple storage paths, each pointing to an encrypted data fragment on a storage node in the distributed storage system; the list of fragment sequence numbers is an ordered set of multiple fragment sequence numbers, and the order of the fragment sequence numbers corresponds one-to-one with the order of the storage path list.

[0059] The second-level node initiates a shard acquisition request to the corresponding storage node in the distributed storage system based on the storage path list. For each storage path in the list, the second-level node resolves the network address of the corresponding storage node and generates a shard acquisition request message. This message carries a list of shard sequence numbers and the hash verification value of the temporary session key. The hash verification value of the temporary session key is generated as follows: the second-level node inputs the decrypted temporary session key into the SHA-256 hash algorithm to calculate a 256-bit hash value, which serves as the hash verification value of the temporary session key.

[0060] Upon receiving a shard acquisition request, the storage node extracts the hash verification value of the temporary session key and a list of shard sequence numbers from the request. The storage node maintains a lock matching record locally, generated when performing a shard locking operation. This record contains the correspondence between the shard sequence number of the locked shard and the requester's verification hash value, which is the hash value of the temporary session key attached to the shard locking request by the data routing smart contract. The storage node verifies whether the hash verification value of the temporary session key matches the requester's verification hash value in its local lock matching record by comparing the two hash values ​​bit by bit. If they match, the storage node transmits the encrypted data shard corresponding to each shard sequence number in the shard sequence number list to the second-level node via an encrypted link. If they do not match, the storage node refuses to transmit the encrypted data shard and returns a shard acquisition failure signal.

[0061] After receiving all encrypted data fragments, the second node establishes a correspondence between each received fragment and its corresponding fragment sequence number. The second node then sorts the received encrypted data fragments according to the fragment sequence number list, with the sequence numbers arranged in ascending order and the corresponding encrypted data fragments arranged in the same order, forming an ordered encrypted fragment sequence. The order of the encrypted data fragments in the ordered sequence is consistent with the order in which the original data fragments were split.

[0062] In practice, the process of aggregating and decrypting encrypted data fragments is as follows: The second agency node extracts the first encrypted data fragment from the ordered encrypted fragment sequence. The first encrypted data fragment corresponds to the encrypted data fragment with the smallest fragment sequence number. The second agency node uses a temporary session key to perform the first layer of decryption on the first encrypted data fragment. The first layer of decryption uses the AES-256 symmetric decryption algorithm, and the decryption key is the temporary session key. After decryption, a primary decrypted data block is obtained. The primary decrypted data block is the intermediate data form that has undergone two layers of encryption during the generation of encrypted data fragments.

[0063] The second node uses its private key to perform a second layer of decryption on the initially decrypted data block. This second layer uses an asymmetric decryption algorithm corresponding to the public-key encryption algorithm of the first node, and the decryption key is the second node's private key. The second node's private key is stored in its local security module. This local security module performs the private key decryption operation and outputs the original data fragments. The original data fragments are binary data blocks that are completely identical to the initially obtained original data fragments.

[0064] The second-level node traverses the remaining encrypted data fragments in the ordered encrypted fragment sequence. The remaining encrypted data fragments are all the encrypted data fragments in the ordered sequence excluding the first encrypted data fragment. For each remaining encrypted data fragment, the second-level node repeatedly performs the first and second layer decryption processes: first, it uses the temporary session key to perform symmetric decryption to obtain a primary decrypted data block; then, it uses the second-level node's private key to perform asymmetric decryption on the primary decrypted data block to obtain the original data fragment. The second-level node temporarily stores all the decrypted original data fragments in a secure memory area, maintaining the correspondence between each original data fragment and its fragment sequence number.

[0065] The second institutional node concatenates and restores all original data fragments according to the fragment sequence number list to obtain the target shared data. The concatenation and restoration operation is as follows: the second institutional node starts with the original data fragment with the smallest fragment sequence number, concatenates the binary data of the original data fragments sequentially, appending the binary data of the next fragment sequence number to the end of the concatenated data each time, until all original data fragments are concatenated. The resulting binary data is the original data binary stream. This binary stream is then converted back to the original data format to obtain the target shared data. The content of the target shared data is consistent with the original data content when the first institutional node initiated the cross-institutional data sharing request.

[0066] After all the original data fragments are concatenated, the complete length of the target shared data is calculated using the byte length of all the original data fragments. Determined by the following formula: in, Indicates the complete length of the target shared data, in bytes; This indicates the total number of original data fragments. The value of is equal to the maximum value of the fragment sequence number in the fragment sequence number list; Indicates the first The length in bytes of each raw data fragment. By reading the first The number of bytes in memory for each original data slice is obtained. This is the fragment sequence number. The range of values ​​is All integers within the interval. The second node verifies the consistency between the concatenated and restored target shared data and the complete length of the target shared data. The verification method is to compare the actual number of bytes in the concatenated binary data with... If they are equal, it indicates that the aggregated decryption is complete and error-free, and the target shared data can be used for subsequent business processing by the second agency node.

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

Claims

1. A blockchain-based method for trusted cross-institutional data sharing and exchange, characterized in that: The method includes: In response to the cross-institutional data sharing request initiated by the first institutional node, an encrypted data container is generated based on the target data identifier and permission policy carried in the cross-institutional data sharing request, and the evidence hash of the encrypted data container is uploaded to the blockchain network. The encrypted data container is subjected to integrity and permission verification by a verification smart contract deployed on the blockchain network, and a verification pass signal is generated. In response to the verification pass signal, the consensus node set in the blockchain network is invoked to perform a hybrid consensus vote on the cross-institutional data sharing request, generating a consensus confirmation result; Based on the consensus confirmation result, the data routing smart contract is triggered to extract the shard storage location index from the encrypted data container, and send a data exchange permission ticket to the second institution node based on the shard storage location index; The second agency node obtains encrypted data fragments from the distributed storage system based on the data exchange license ticket, and aggregates and decrypts the encrypted data fragments to obtain the target shared data.

2. The blockchain-based cross-institutional data trusted sharing and exchange method according to claim 1, characterized in that, The container for generating encrypted data includes: Perform binary stream conversion processing on the original data corresponding to the target data identifier to obtain the original data binary stream; The original binary data stream is divided into multiple data fragments according to a preset fragmentation threshold, and a fragmentation sequence number is assigned to each data fragment. For each data shard, asymmetric encryption is performed using the public key of the first institutional node to generate an encrypted data shard. All encrypted data fragments are stored separately on different storage nodes of the distributed storage system, and the storage path and fragment sequence number of each encrypted data fragment are recorded to form a fragment storage location index; A hash operation is performed on the fragment storage location index to generate the evidence hash.

3. The blockchain-based cross-institutional data trusted sharing and exchange method according to claim 2, characterized in that, The shard storage location index is stored in the metadata management node of the distributed storage system in the form of key-value pairs, where the key is the shard sequence number and the value is the corresponding storage path.

4. The blockchain-based cross-institutional data trusted sharing and exchange method according to claim 1, characterized in that, The process of performing integrity and permission verification on the encrypted data container through a verification smart contract deployed on the blockchain network includes: The verification smart contract reads the evidence storage hash from the blockchain network and obtains the shard storage location index from the distributed storage system; The hash of the fragment storage location index is recalculated to obtain the verification hash, and the verification hash is compared with the evidence storage hash to generate an integrity verification result; When the integrity verification result is consistent, the verification smart contract parses the permission policy in the cross-organization data sharing request and extracts the whitelist of allowed organizations. Determine whether the identity identifier of the second institution node exists in the institution whitelist, and generate an authorization verification result; When the permission verification result is passed, the verification smart contract sends a verification pass signal.

5. The blockchain-based cross-institutional data trusted sharing and exchange method according to claim 1, characterized in that, Invoking the set of consensus nodes in the blockchain network to perform hybrid consensus voting on the cross-institutional data sharing request includes: After receiving the cross-organizational data sharing request, each consensus node in the consensus node set performs data integrity verification and organization identity verification respectively, and generates its own verification score. Each consensus node compares the verification score with a locally pre-stored trust threshold to generate a voting result, which is either a vote in favor or a vote against. The number of affirmative votes in the consensus node set is counted, and the ratio of the number of affirmative votes to the total number of consensus nodes is calculated to obtain the consensus achievement ratio. When the consensus achievement rate is greater than or equal to the preset consensus threshold, the consensus confirmation result is generated; When the consensus achievement rate is less than a preset consensus threshold, a consensus failure result is generated, and the cross-organizational data sharing request is marked as rejected.

6. The blockchain-based cross-institutional data trusted sharing and exchange method according to claim 5, characterized in that, The trust threshold is dynamically updated based on the accuracy of historical voting and response latency of each consensus node, and stored in the trust management contract of the blockchain network.

7. The blockchain-based cross-institutional data trusted sharing and exchange method according to claim 1, characterized in that, The trigger data routing smart contract extracts the shard storage location index from the encrypted data container, including: After receiving the consensus confirmation result, the data routing smart contract parses the shard storage location index in the encrypted data container to obtain the storage path list and shard sequence number list corresponding to the encrypted data shards. The data routing smart contract sends a shard locking request to the corresponding storage node in the distributed storage system according to the storage path list, and the shard locking request includes the shard sequence number list; Upon receiving the fragment locking request, the storage node marks the corresponding encrypted data fragment as pending transmission and returns a locking confirmation signal; After collecting the lock confirmation signals returned by all storage nodes, the data routing smart contract encapsulates the shard storage location index into a transmission routing table.

8. The blockchain-based cross-institutional data trusted sharing and exchange method according to claim 7, characterized in that, The fragment locking request carries a lock validity period. During the lock validity period, the storage node marks the corresponding encrypted data fragment as an exclusive lock state. After the timeout, it automatically releases the lock and restores the storage node to a readable state.

9. The blockchain-based cross-institutional data trusted sharing and exchange method according to claim 7, characterized in that, Sending a data exchange permission ticket to the second agency node based on the fragmented storage location index includes: The data routing smart contract generates a temporary session key based on the transmission routing table, and encrypts the temporary session key using the public key of the second institution node to obtain an encrypted session key; The data routing smart contract packages the transmission routing table, the encrypted session key, and the timestamp of the cross-agency data sharing request to generate the data exchange license ticket; The data routing smart contract sends the data exchange permission ticket to the second institution node through the peer-to-peer channel of the blockchain network; After receiving the data exchange license ticket, the second agency node decrypts the encrypted session key using its own private key to obtain the temporary session key.

10. The blockchain-based cross-institutional data trusted sharing and exchange method according to claim 9, characterized in that, The second agency node obtains encrypted data fragments from the distributed storage system based on the data exchange license ticket, including: The second agency node parses the transport routing table in the data exchange license ticket to obtain the storage path list and the fragment sequence number list; The second institutional node initiates a shard acquisition request to the corresponding storage node in the distributed storage system based on the storage path list. The shard acquisition request carries the shard sequence number list and the hash verification value of the temporary session key. After the storage node verifies that the hash verification value of the temporary session key matches the locally locked matching record, it transmits the corresponding encrypted data fragments to the second institution node. After receiving all encrypted data fragments, the second institutional node sorts the received encrypted data fragments according to the fragment sequence number list to obtain an ordered encrypted fragment sequence.

Images