Block chain data verification method and device, equipment, medium and program product

Abstract

The invention discloses a block chain data verification method and device, equipment, a medium and a program product, and relates to the technical field of block chains. A first authentication node of the method receives a data storage request sent by client equipment, wherein the data storage request comprises storage data and a data identifier; generating a storage block including storage data and a data identifier, signing the storage block according to a preset private key to obtain a target block, and sending the target block including the storage data, the data identifier, a preset public key and signature information to all second authentication nodes; the second authentication node receives the target block, verifies the signature information according to the preset public key, and stores the target block when the verification is passed; and the non-authentication node sends a data synchronization request including the data identifier to the authentication node, obtains the corresponding target block, and verifies the signature information according to the preset public key to obtain a verification result. According to the embodiment of the invention, the collaboration and reliability of the block chain data verification method are improved.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, and in particular relates to methods, apparatus, equipment, media and program products for blockchain data verification. Background Technology

[0002] Evidence preservation refers to the preservation of evidence or data, especially electronic data, to prevent potential disputes and to ensure its integrity and authenticity through specific technical means. For evidence preservation, blockchain-based data preservation schemes are often used.

[0003] Existing technologies typically process electronic data to be stored using encryption logic, then compress and record the encrypted data into a new block via a block generation interface and perform on-chain operations to achieve immutable data storage. However, such solutions often employ a deployment architecture with a single node or a limited number of nodes within a local area network, making it difficult for multiple stakeholders, such as parties involved in the case and other regulatory departments, to conveniently and efficiently participate in the data storage process, thus reducing the openness and collaborative efficiency of the storage process. Furthermore, storage services concentrated on a single or a few nodes often rely on fixed servers or single verification programs in subsequent data verification stages, compromising the reliability and trustworthiness of the entire storage system. Therefore, existing blockchain data verification methods suffer from poor collaboration and reliability. Summary of the Invention

[0004] This application provides a method, apparatus, device, medium, and program product for blockchain data verification to address the problems of poor coordination and reliability in existing blockchain data verification methods.

[0005] In a first aspect, embodiments of this application provide a method for blockchain data verification, applied to a first authentication node in a blockchain network, wherein the first authentication node is a preset authentication node, and the method includes: Receive a data storage request sent by a client device. The data storage request includes the stored data and the data identifier. A storage block containing stored data and a data identifier is generated, and the storage block is signed according to the preset private key of the first authentication node to obtain the target block. The target block includes stored data, a data identifier, a preset public key, and signature information. The target block is sent to all secondary authentication nodes in the blockchain network so that the secondary authentication nodes can verify the signature information of the target block according to the preset public key, and store the target block if the verification is successful. Upon receiving a data synchronization request containing a data identifier from an unauthenticated node, the system sends the target block corresponding to the data identifier to the unauthenticated node. This allows the unauthenticated node to verify the signature information of the target block using a preset public key and obtain the verification result.

[0006] Secondly, embodiments of this application provide a method for blockchain data verification, applied to a second authentication node in a blockchain network. The second authentication node is an authentication node other than the first authentication node, and the first authentication node is a preset authentication node. The method includes: Receive the target block sent by the first authentication node. The target block includes stored data, data identifier, preset public key and signature information. The signature of the target block is verified using a preset public key, and the target block is stored if the verification is successful. Upon receiving a data synchronization request containing a data identifier from an uncertified node, the system sends the target block corresponding to the data identifier to the uncertified node. The uncertified node then receives the target block and verifies its signature information using a preset public key to obtain the verification result.

[0007] Thirdly, embodiments of this application provide a method for blockchain data verification, applied to non-authenticated nodes in a blockchain network, the method comprising: Send a data synchronization request to at least one first authentication node or a second authentication node. The data synchronization request includes a data identifier, which is used by the authentication node that receives the data synchronization request to send the target block corresponding to the data identifier to the non-authentication node. The target block includes stored data, a data identifier, a preset public key, and signature information. Receive the target block sent by the authentication node, and verify the signature information of the target block according to the preset public key to obtain the verification result.

[0008] Fourthly, embodiments of this application provide a blockchain data verification device applied to a first authentication node in a blockchain network. The first authentication node is a preset authentication node. The device includes: The receiving module is used to receive data storage requests sent by the client device. The data storage requests include stored data and data identifiers. The signature module is used to generate a storage block that includes stored data and a data identifier, and to sign the storage block according to the preset private key of the first authentication node to obtain the target block. The target block includes stored data, a data identifier, a preset public key, and signature information. The sending module is used to send the target block to all second-authentication nodes in the blockchain network, so that the second-authentication nodes can verify the signature information of the target block according to the preset public key, and store the target block if the verification is successful. The sending module is also used to send the target block corresponding to the data identifier to the non-authenticated node when it receives a data synchronization request including a data identifier from the non-authenticated node, so that the non-authenticated node can verify the signature information of the target block according to the preset public key and obtain the verification result.

[0009] Fifthly, embodiments of this application provide a blockchain data verification device, applied to a second authentication node in a blockchain network. The second authentication node is an authentication node other than the first authentication node, and the first authentication node is a preset authentication node. The device includes: The receiving module is used to receive the target block sent by the first authentication node. The target block includes stored data, data identifier, preset public key and signature information. The verification module is used to verify the signature of the target block according to the preset public key, and store the target block if the verification is successful. The sending module is used to send the target block corresponding to the data identifier to the unauthenticated node when it receives a data synchronization request including a data identifier. The unauthenticated node can then receive the target block and verify the signature information of the target block according to the preset public key to obtain the verification result.

[0010] Sixthly, embodiments of this application provide a blockchain data verification apparatus applied to a non-authentication node in a blockchain network, the apparatus comprising: The sending module is used to send a data synchronization request to at least one first authentication node or a second authentication node. The data synchronization request includes a data identifier, which is used by the authentication node that receives the data synchronization request to send the target block corresponding to the data identifier to the non-authentication node. The target block includes stored data, a data identifier, a preset public key, and signature information. The receiving module is used to receive the target block sent by the authentication node, and verify the signature information of the target block according to the preset public key to obtain the verification result.

[0011] In a seventh aspect, embodiments of this application provide a terminal device, the device comprising: a processor and a memory storing computer program instructions; the processor executing the computer program instructions to implement a method for blockchain data verification as described in the first aspect, the second aspect, or the third aspect.

[0012] Eighthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions that, when executed by a processor, implement a blockchain data verification method as described in the first, second, or third aspects.

[0013] Ninthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a blockchain data verification method as described in the first, second, or third aspects of the first aspect.

[0014] This application provides a method, apparatus, device, medium, and program product for blockchain data verification. The method involves a first authentication node receiving a data storage request from a client device, the request including stored data and a data identifier; generating a storage block including the stored data and the data identifier; signing the storage block using the first authentication node's preset private key to obtain a target block; and sending the target block to all second authentication nodes in the blockchain network. The target block includes stored data, a data identifier, a preset public key, and signature information. The second authentication nodes receive the target block and verify its signature information using the preset public key. If verification is successful, the target block is stored. The first authentication node immediately sends the block to multiple second authentication nodes after generation, achieving multi-node collaborative storage, enabling different departments or institutions to simultaneously participate in the storage process, thus improving collaboration. Unauthenticated nodes send a data synchronization request, including a data identifier, to the first and second authenticated nodes to obtain the target block corresponding to the data identifier. They then verify the signature information of the target block using a preset public key to obtain the verification result. This allows unauthenticated nodes to request data at any time using the data identifier and to verify the signature themselves using the public key embedded in the block, achieving multi-party public verification of stored data and improving data reliability. Therefore, this embodiment of the application improves the coordination and reliability of the blockchain data verification method. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of the structure of the blockchain data verification system provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the blockchain data verification method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the target block provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of the internal data of the block provided in the embodiments of this application; Figure 5 This is a schematic diagram illustrating the relationship between authentication nodes and non-authentication nodes provided in the embodiments of this application; Figure 6 This is a schematic diagram of the process for updating the first authentication node provided in an embodiment of this application; Figure 7 This is a schematic diagram of a device for blockchain data verification applied to the first authentication node of a blockchain network, as provided in an embodiment of this application. Figure 8 This is a schematic diagram of a device for blockchain data verification applied to a second authentication node in a blockchain network, as provided in an embodiment of this application. Figure 9 This is a schematic diagram of the structure of a device for verifying blockchain data of a non-certified node in a blockchain network provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application. Detailed Implementation

[0017] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0018] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0019] Evidence preservation refers to the storage of evidence or data, especially electronic data, to prevent potential disputes and to ensure its integrity and authenticity through specific technical means. Evidence preservation technologies include digital certificates, timestamps, and blockchain, which can ensure the integrity and authenticity of data, reduce the difficulty of evidence preservation and retrieval, and improve the efficiency of evidence presentation. Blockchain technology, with its decentralized and tamper-proof characteristics, further enhances the security and credibility of electronic evidence preservation.

[0020] Existing technical solutions are all based on blockchain technology. They encrypt the electronic data to be stored using software encryption logic code. The encrypted electronic data is then compressed and recorded into a designated new block through the blockchain's block generation logic interface. Finally, the newly generated block data is uploaded to the blockchain, achieving the chain-like data storage effect of blockchain. However, existing technologies have the following drawbacks: 1. Typical electronic data storage methods deploy the system using a single node within a local area network. This deployment architecture makes it difficult for parties involved in the case, other regulatory departments, and other relevant personnel and units to participate efficiently in the data storage process. Electronic data storage generally preserves documents and video data from cases or law enforcement processes. This type of data is crucial evidence in various stages of case processing. Allowing the public, parties involved, and other stakeholders to participate efficiently in the data storage process is essential for ensuring the authenticity and fairness of electronic data storage. 2. Typical electronic data storage systems are deployed on a single machine. Single-machine deployments are more prone to server availability issues with the encryption logic. When the service responsible for electronic data storage experiences downtime or fails to output results correctly, discrepancies will arise in the service capabilities and the data being stored. 3. In the verification phase of electronic data storage, if only a single verification service with a fixed server or program is used, the verification logic will lose its basic security and credibility if the verification service program malfunctions or is modified. Furthermore, having only a single verifier undermines the credibility of the verification process.

[0021] To address the problems of existing technologies, embodiments of this application provide a method, apparatus, device, medium, and program product for blockchain data verification. The method involves a first authentication node receiving a data storage request from a client device, the request including stored data and a data identifier; generating a storage block including the stored data and the data identifier; signing the storage block using a preset private key of the first authentication node to obtain a target block; and sending the target block to all second authentication nodes in the blockchain network. The target block includes stored data, a data identifier, a preset public key, and signature information. The second authentication nodes receive the target block and verify its signature information using the preset public key; if verification is successful, the target block is stored. The first authentication node immediately sends the block to multiple second authentication nodes after generation, achieving multi-node collaborative storage, enabling different departments or institutions to simultaneously participate in the storage process, thus improving collaboration. Unauthenticated nodes send a data synchronization request, including a data identifier, to the first and second authenticated nodes to obtain the target block corresponding to the data identifier. They then verify the signature information of the target block using a preset public key to obtain the verification result. This allows unauthenticated nodes to request data at any time using the data identifier and to verify the signature themselves using the public key embedded in the block, achieving multi-party public verification of stored data and improving data reliability. Therefore, this embodiment of the application improves the coordination and reliability of the blockchain data verification method.

[0022] The following section first introduces the system for blockchain data verification, which is applied to the method for blockchain data verification, as provided in the embodiments of this application.

[0023] Figure 1 A schematic diagram of the structure of a blockchain data verification system 100 provided in an embodiment of this application is shown. Figure 1 As shown, the system may include a reward layer 101, a consensus layer 102, a network layer 103, and a data layer 104. The reward layer 101 includes a block encapsulation reward module 1011 and a block verification and establishment module 1012. The consensus layer 102 includes an authenticated node consensus module 1021, an unauthenticated node consensus module 1022, and an authentication-based consensus mechanism module 1023. The network layer 103 includes a synchronization manager module 1031, a node manager module 1032, a TCP / IP module 1033, and a P2P protocol module 1034. The data layer 104 includes a hash function module 1041, a Merkle tree model 1042, a public / private key account module 1043, a data block module 1044, a chain structure module 1045, and a timestamp module 1046.

[0024] The following describes the blockchain data verification method provided in the embodiments of this application.

[0025] Figure 2A flowchart illustrating a blockchain data verification method provided in an embodiment of this application is shown. Figure 2 As shown, the method may include the following steps: S201 to S208.

[0026] S201, the first authentication node receives a data storage request sent by the client device. The data storage request includes stored data and data identifier; the first authentication node is a preset authentication node.

[0027] The first authentication node is a core node with block generation and signing permissions. The client device is the terminal device that initiates the data storage request. The data storage request is a storage request containing the data to be stored and its identifier. The stored data is the electronic data that needs to be preserved. The data identifier is a string that uniquely identifies the stored data. The preset authentication node is a preset node with block generation and signing permissions.

[0028] In some embodiments, after the client device collects the data that needs to be stored, it generates a data storage request containing the stored data and a unique data identifier, and sends it to a preset first authentication node. The first authentication node receives and parses the request.

[0029] This application embodiment ensures the traceability of the source of stored data through data identification, avoids data confusion, and ensures the legitimacy of the evidence storage entry point through preset authentication nodes.

[0030] In some embodiments, the data storage request may also include verification information such as timestamps, client geolocation information, and client digital signatures.

[0031] In this embodiment, timestamps solidify the evidence storage time, geolocation supplements the data scenario context, and client signatures prevent requests from being forged, further enhancing the traceability and authenticity of the evidence storage data and adapting to the high requirements for the integrity of the evidence chain in government affairs, judicial and other scenarios.

[0032] S202, the first authentication node generates a storage block including the stored data and the data identifier, and signs the storage block according to the preset private key of the first authentication node to obtain the target block. The target block includes the stored data, the data identifier, the preset public key and the signature information.

[0033] The storage block is the basic unit of the blockchain, containing stored data and a data identifier. The preset private key is a unique encryption key held only by the first authentication node. The target block is the complete, signed block, including stored data, a data identifier, a preset public key, and signature information. The preset public key is a verification key paired with the preset private key and is publicly available across the network. The signature information is the result of signing the storage block using the private key.

[0034] In some embodiments, after receiving a certificate storage request, the first authentication node extracts the storage data and data identifier to construct a storage block; calculates the hash value of the storage data in the block, encrypts the hash value with its own preset private key, and generates signature information; finally, it encapsulates the storage data, data identifier, preset public key, and signature information into a target block.

[0035] This application embodiment binds the target block to the first authentication node through signature information, ensuring that the block can only be generated by the legitimate first authentication node, and that others cannot forge or tamper with the block content; the public key is issued along with the target block, providing a basis for subsequent verification, thus solving the problems of easy data tampering and difficulty in tracing responsibility in traditional evidence storage methods.

[0036] S203, the first authentication node sends the target block to all second authentication nodes in the blockchain network.

[0037] The second authentication node is a core node with block storage and verification permissions.

[0038] In some embodiments, after the first authentication node generates the target block, it broadcasts the target block to all registered second authentication nodes through the P2P protocol of the blockchain network, ensuring that each second authentication node can receive the complete target block data.

[0039] This application embodiment implements distributed storage of the target block. By constructing a multi-replica data cluster, it avoids single point of failure. If the first authentication node fails, the second authentication node still holds the data, improving data availability. Furthermore, the distributed deployment supports cross-departmental collaboration, solving the problems of low availability of traditional single-machine evidence storage and cross-departmental data incompatibility.

[0040] S204, the second authentication node receives the target block and verifies the signature information of the target block according to the preset public key. If the verification is successful, the target block is stored.

[0041] The signature verification process involves decrypting the signature information using a preset public key to verify the integrity and legitimacy of the block.

[0042] In some embodiments, after receiving the target block, the second authentication node extracts the preset public key and signature information from the block; decrypts the signature information using the public key to obtain the original block hash value; at the same time, it recalculates the hash value of the received target block, compares whether the two hash values ​​are consistent, and if they are consistent, the verification is successful, and the target block is stored in the blockchain database of the local node.

[0043] This application's embodiments ensure the authenticity of data in distributed storage by confirming that the target block has not been tampered with and originates from a legitimate first-authentication node. Simultaneously, multi-node storage further enhances data security, resolving the problem of difficulty in guaranteeing data authenticity in traditional distributed storage.

[0044] In some embodiments, cross-validation is initiated between multiple second authentication nodes. Each second authentication node synchronizes its own validation result to other second authentication nodes. Storage operation is only performed when the validation of nodes exceeding a set threshold is passed.

[0045] The embodiments of this application enhance the credibility of verification through cross-validation, avoid misjudgments caused by faults or malicious behavior of a single node, and are suitable for scenarios with high requirements for verification compliance, such as judicial and government affairs.

[0046] S205, the non-authenticated node sends a data synchronization request to at least one first or second authentication node, the data synchronization request including a data identifier.

[0047] Non-authenticated nodes are nodes that do not have block generation permissions but can participate in data verification and synchronization. A data synchronization request is a request initiated by a non-authenticated node to an authenticated node to obtain the target block.

[0048] In some embodiments, when a non-certified node needs to obtain specific evidence storage data due to business requirements, it generates a data synchronization request, which includes the data identifier of the target block, and sends the request to at least one certified node.

[0049] This application's embodiments ensure the impartiality of the evidence preservation process by allowing non-certification participants to access and participate in the data verification. This breaks the data monopoly of certification nodes, enabling relevant parties such as parties involved in the case and third-party institutions to access the data for oversight, thereby enhancing the credibility of the evidence preservation data and addressing the problems of limited participation and low transparency in traditional evidence preservation verification.

[0050] S206, when the first certified node receives a data synchronization request including a data identifier from a non-certified node, it sends the target block corresponding to the data identifier to the non-certified node.

[0051] In some embodiments, after receiving a synchronization request from a non-authenticated node, the first authenticated node first parses the data identifier in the request and retrieves the target block corresponding to the identifier in the local blockchain database; if the block is found and the non-authenticated node's authentication is successful, the target block is sent to the non-authenticated node.

[0052] In this embodiment of the application, the first authentication node serves as the initial block generation node, and the stored blocks are original. Its response can ensure that non-authentication nodes obtain complete and tamper-proof initial data, thereby improving the reliability of data acquisition.

[0053] S207, when the second authentication node receives a data synchronization request including a data identifier from a non-authentication node, it sends the target block corresponding to the data identifier to the non-authentication node.

[0054] In some embodiments, after receiving a synchronization request from a non-authenticated node, the second authenticated node parses the data identifier and retrieves the target block from its local storage; if the block is found and authenticated, the target block is sent to the non-authenticated node.

[0055] The second authentication node in this embodiment can share the response pressure of the first authentication node, improve the processing efficiency of synchronization requests, and ensure high availability of data access.

[0056] In some embodiments, the data synchronization request may also include the identity credentials of the non-authenticated node and a description of the purpose of the request. After receiving the request, the authenticated node first verifies the legality of the identity credentials and then determines whether to allow data synchronization based on the purpose.

[0057] The authentication node in this application prevents unauthorized nodes from obtaining sensitive data through identity verification, ensures compliant data use through usage review, balances data transparency and security, and avoids data misuse.

[0058] S208, the non-authenticated node receives the target block sent by the authenticated node, and verifies the signature information of the target block according to the preset public key to obtain the verification result.

[0059] In some embodiments, after receiving the target block sent by the certified node, the non-certified node extracts the preset public key and signature information from the block; decrypts the signature information with the public key to obtain the original block hash value; recalculates the hash value of the received block, compares whether the two are consistent, and obtains the result of verification success or verification failure.

[0060] In this application embodiment, the non-certified node acts as an independent third party, and its verification results are objective and can serve as supplementary proof of the legality of the stored data. The verification by multiple certified nodes forms a closed loop, further strengthening the immutability of the data and solving the problem of the lack of credibility of the single verification party in traditional evidence storage.

[0061] In this embodiment, the first authentication node immediately sends the block to multiple second authentication nodes after generation, achieving multi-node collaborative evidence storage. This allows different departments or institutions to simultaneously participate in the evidence storage process, improving collaboration. Non-authenticated nodes are allowed to request data at any time using data identifiers and verify their signatures using the public key embedded in the block, achieving multi-party public verification of stored data and improving data reliability. Therefore, this embodiment improves the collaboration and reliability of blockchain data verification methods.

[0062] In some embodiments, such as Figure 3As shown, the target block includes a source block layer and a logical block layer. The main function of the source block layer is to categorize the genesis block using different tags. In traditional blockchain applications, there is only one genesis block, which is used as the first block generated for chain generation and storage. However, using the traditional genesis block method in evidence storage logic leads to a significant reduction in later retrieval efficiency and makes block synchronization difficult. This application embodiment uses a custom tag method to partition the source block. The main function of the logical block layer is to record the processing of a specific source block under different logics. In each block extracted from the logical block layer, the hash value of the source block in the source block layer is used as the hash value of the previous block, thereby establishing a relationship with the data in the source block layer, realizing a logical relationship similar to parent-child data, thus ensuring that a single source information can be stored in multiple different blockchain data in different logical processing layers.

[0063] This application's embodiments use a source block layer to categorize incidents and cases by tagging them, meeting the requirements of rapid classification and efficient querying given the diverse categories and broad scope of urban incidents and cases. Using a logical block layer to divide the data storage of incidents and cases into independent blocks satisfies the practical needs of multiple departments simultaneously handling incidents and cases in the division of urban management responsibilities.

[0064] In some embodiments, the internal data structure of a single block in the logical block layer is as follows: Figure 4As shown, the block consists of a block header and a block body. The block header includes the hash value of the previous block, version number, Merkle root tree, timestamp, authentication node identifier, public key information, and the public key signature information of the block body. The block body contains n stored data items. The crucial "public key information" is the public key information of the authentication node, which is generated along with the block header. The "public key signature information of the block body" is the signature information obtained by the authentication node using the public key generated by the node to sign the business data in the block body. The data stored in the block body can be processed according to the actual business system logic. The processing methods are as follows: The data to be processed can be fully encrypted and decrypted, preserving the original information of the original data file, and stored directly on the block body. Alternatively, the file can be stored on another distributed storage server, and the URL of the stored data can be processed to generate a 256-bit (32-byte) hash value using the SHA-256 hash algorithm. The hash value (File_Hash), file identification information (File_Identity), and file storage address information (File_Saveurl) of the file data are concatenated, and the concatenated information is written into the corresponding block for storage. Using File_Hash as the unique identifier of the file ensures that data already confirmed in the business system is uploaded to the blockchain, guaranteeing the reliability and authenticity of the evidence if the file content has not been modified. If the file in question is modified, the SHA-256 hash value of the modified file will change accordingly. When the hash value on the block (File_Hash_A) is compared with the hash value of the actual file in the file's physical path (File_Hash_B), a difference indicates that the evidence file has been tampered with.

[0065] In some embodiments, the first authentication node signing the storage block according to its preset public key may include: The first authentication node performs a hash calculation on the stored data to obtain a hash value. The hash calculation is a process of performing a one-way encryption operation on the stored data to generate a unique string of fixed length. The hash value is the result of the hash calculation and is used to uniquely identify the stored data.

[0066] The first authentication node determines the signature information of the storage block based on its preset private key and hash value. The preset private key is a unique encryption key generated by the first authentication node. The signature information is the result of encrypting the hash value with the private key, which is used to verify the legitimacy of the block in subsequent verification.

[0067] This application's embodiment compresses data volume using hash values ​​and then binds the block to the first authentication node using a private key signature, ensuring that the data has not been tampered with and its source is legitimate. Hash calculation is highly efficient; the private key signature provides non-repudiation, solving the problems of low efficiency and difficulty in detecting tampering in traditional large file signing.

[0068] In some embodiments, the signature information includes temporary point data and a signature value. The first authentication node determines the signature information of the storage block based on the first authentication node's preset private key and hash value, which may include: The first authentication node determines temporary point data and the coordinates of temporary points based on random numbers and a preset elliptic curve. The temporary point data consists of points on an elliptic curve calculated based on random numbers and the preset elliptic curve. The preset elliptic curve is a pre-agreed mathematical curve used in the ECDSA algorithm. The coordinates of the temporary points are the x and y coordinates of the temporary point data on the elliptic curve. The first authentication node determines the signature value based on the preset private key, hash value, coordinates of the ephemeral point, and random number; among them, the signature value is the core signature parameter calculated by combining the preset private key, hash value, coordinates of the ephemeral point, and random number.

[0069] This application's embodiments determine the signature value by pre-setting a private key, hash value, ephemeral point coordinates, and random number, ensuring high security and verifiability of the signature, and adapting to the efficient verification needs of distributed nodes. The combination of ephemeral point data and signature value ensures both security and facilitates rapid verification by unauthenticated nodes, solving the problems of long keys and slow computation in traditional signature algorithms.

[0070] In some embodiments, the signature information includes temporary point data and a signature value. Uncertified nodes verify the signature information of the target block using a preset public key to obtain a verification result, including: Perform a hash calculation on the stored data to obtain a hash value; The target temporary point data is determined based on the hash value, the preset public key, and the signature value; the target temporary point data is a point on an elliptic curve calculated by the non-authenticated node based on the hash value, the preset public key, and the signature value, which is used to compare with the temporary point data in the signature information. If the temporary point data is the same as the target temporary point data, a verification pass result is obtained; where the verification pass result is the determination result that the target temporary point data is completely consistent with the temporary point data in the signature information.

[0071] In this embodiment, the signature verification is completed independently by the non-authentication node, without relying on any authentication node, ensuring the objectivity and impartiality of the verification result and providing independent evidence for the legality of the stored data. The verification process only requires hash calculation and elliptic curve point operation, which is highly efficient; it allows parties involved in the case, third-party institutions, etc., to participate in the verification, solving the problem of the lack of credibility of a single verification party in traditional evidence storage.

[0072] In some embodiments, multiple nodes also exist within the non-certified node group, and there is no role distinction among the machines within the non-certified node group. Servers within the non-certified node group exist as external participating nodes, referred to here as "participants." Participant nodes are non-certified nodes; they do not have the right to generate blocks, but they can register with the certified node for already generated blocks, initiate block data synchronization requests independently, and verify the block data on the certified node. The presence of participant nodes in the system ensures the fairness of on-chain data.

[0073] The block verification by participants used elliptic curve cryptography in practice. In actual use, RSA is less efficient. For the same security strength, elliptic curve cryptography has a shorter key length and higher operating efficiency. A 1024-bit key in RSA is equivalent to a 160-bit key in elliptic curve cryptography in terms of security strength. The Elliptic Curve Digital Signature Algorithm (ECDSA) is used, which is based on elliptic curve cryptography and consists of the following three steps: 1. System Establishment. A public / private key pair is generated based on elliptic curves. The private key is a randomly selected integer k, and the public key is K=kG, where G is a point on the selected elliptic curve. The value of k can also be seen as the number of "point operations" in the elliptic curve algorithm. kG is the point data obtained on the elliptic curve after point G has undergone k point operations.

[0074] 2. Signature. Select a random number r. Calculate a point rG on the elliptic curve, with coordinates (x, y). Calculate the hash value of the stored data m as h = H(m), and further calculate s = (h + kx)r-1; the signer sends the message m and the signature (rG, s) to the receiver.

[0075] 3. Signature Verification. After receiving the message m and the signature (rG,s), the receiver first calculates the hash value h = H(m) of message m, and then calculates whether hGs-1 + xKs-1 equals rG. If the equation holds, the signature is correct and passes the signature verification logic. The proof is as follows: hGs-1+xKs-1 = hGs-1+x(kG)s-1 =(h+xk)Gs-1 =(h+xk)Gr(h+xk)-1 =rG Where h is the hash value of the stored data, G is the base point of the preset elliptic curve, s-1 is the modular inverse of the signature value s, x is the x-coordinate of the temporary point rG, K is the preset public key of the first authentication node, k is the preset private key of the first authentication node, r is the secure random number generated during the signature stage, and (h+xk) 1 is the modular inverse of the expression (h + xk), and rG is the temporary point data.

[0076] In some embodiments, the relationship between certified nodes and non-certified nodes is as follows: Figure 5 As shown, certified nodes have the right to sign a block, corresponding to miner nodes in the PoW consensus mechanism. Non-certified nodes do not have the right to sign, but they have the right to assist in verification. Both types of nodes have the ability to synchronize data in the blockchain network. There are multiple certified nodes, including master nodes and follower nodes. There is only one master node, the Leader node, which has the right to generate and save blocks. Specifically, when the Leader node receives a block generation request from a client, it is responsible for organizing data to generate and save the block. After the Leader node successfully saves the block, it sends a synchronization message to other follower nodes. Follower nodes, upon receiving the synchronization message, independently store the data. All followers independently send a confirmation message to the leader node that initiated the synchronization request, informing it that they have received the synchronization data and are ready to save it. After receiving messages from each follower, the leader node confirms the block saving status of the followers. Once confirmed, it sends a confirmation commit message to each follower. Each follower then performs the block data confirmation and commit operation.

[0077] In some embodiments, such as Figure 6 As shown, the method may further include: S601 to S604.

[0078] S601, if the second authentication node does not receive a message from the first authentication node for a period of time exceeding a set threshold, it sends a node reset request to the first authentication node and the other second authentication nodes that do not receive a message from the first authentication node for a period of time exceeding the set threshold. The node reset request includes a target term number, which is the total number of times all authentication nodes have initiated the election of the first authentication node.

[0079] The threshold is a preset timeout period for determining whether the first authentication node is faulty. A node reset request is a request instruction initiated by a second authentication node to trigger a new term election. The target term number is the total number of times all authentication nodes have historically initiated elections for the first authentication node, used to identify the election cycle; for example, if two elections have already been initiated, the current target term number is 3. The remaining second authentication nodes are those that have not timed out or have not initiated a node reset request.

[0080] In some examples, suppose there are three authentication nodes in the blockchain network: authentication node A is the first authentication node, and authentication nodes B and C are the second authentication nodes. Authentication node B has a set threshold of 60 seconds. If authentication node B does not receive a message from authentication node A for 60 consecutive seconds, it determines that it may be down and then generates a node reset request, with the target term number being 2 (there has been 1 election in the past), and sends it to authentication nodes A and C.

[0081] This application's embodiments achieve automatic fault detection through a timeout trigger mechanism, requiring no manual intervention; the target term number uniquely identifies the election cycle, avoiding conflicts in election requests from different terms and ensuring the orderly conduct of the election. This avoids system paralysis and election chaos caused by the failure of the first authentication node.

[0082] S602, when the first authentication node receives a node reset request sent by the target second authentication node, the first authentication node sets itself as the second authentication node of the target term number. The target second authentication node is the second authentication node that has not received a message from the first authentication node for a period of time exceeding a set threshold.

[0083] The second authentication node for the target term number is an authentication node that, during the term of the target term number, has no block generation authority and is only responsible for synchronizing and verifying blocks.

[0084] In some embodiments, after the original first authentication node A fails, it receives a node reset request (term number "2") sent by the target second authentication node B; it switches its role from the first authentication node to the second authentication node with term 2, relinquishes the block generation permission, and waits only for the synchronization instruction of the new first authentication node.

[0085] In this embodiment, the first authentication node automatically switches roles without manual configuration, improving fault recovery efficiency; the term number verification ensures the legality of role switching, resolving the conflict between the original first authentication node and the new first authentication node in traditional distributed system fault recovery.

[0086] In some embodiments, when the first authentication node receives a node recharge request, it verifies whether the target term number is greater than the current term number recorded locally, and only processes requests whose term number is greater than the current term number recorded locally.

[0087] In one example, node A verifies that the target term number "2" is greater than the current term number "1" recorded locally, thus confirming the election as legitimate.

[0088] This application's embodiments avoid interference from expired election requests by verifying the validity of term limits, prevent system consistency issues caused by term rollback, and adapt to the high requirements of government systems for node stability.

[0089] S603, the second authentication node receives the votes sent by the other second authentication nodes and counts the number of votes received by the second authentication node.

[0090] In this context, a vote serves as the authentication node's credential of support for a candidate second authentication node. The number of votes represents the total number of valid votes received by the candidate node.

[0091] In some embodiments, the B node that initiates the node reset request automatically becomes a candidate node. After confirming the validity of the target term number, other second-authentication nodes send votes to the candidate nodes. After receiving each vote, the B node verifies the legitimacy of the voting node's identity and the consistency of its term. If the verification is successful, the votes are counted in the total number of valid votes and tallied in real time.

[0092] This application's embodiments use multi-node voting to select a legitimate new first authentication node, ensuring the fairness and legitimacy of the first authentication node election. A vote verification mechanism prevents unauthorized nodes from interfering with the election, and term consistency verification avoids invalidating cross-term votes.

[0093] S604: If the number of votes cast by the second authentication node exceeds a set threshold, the second authentication node will be set as the first authentication node for the target term number.

[0094] The threshold is set as the minimum number of valid votes required to be elected as the first certified node.

[0095] In one example, assume there are a total of 3 certified nodes and a threshold of 2 votes. Candidate node B counts 2 valid votes, exceeding the threshold. Node B automatically switches to the role of the first certified node for term 2, sends an election notification to all certified nodes, including its own identifier, target term number, and block generation permission declaration, and then starts the block generation and synchronization service.

[0096] In some embodiments, if the number of votes for the second authentication node does not exceed a set threshold, the second authentication node remains the second authentication node until other second authentication nodes send a node reset request to the first authentication node and the remaining second authentication nodes other than the first authentication node and the second authentication node that has not received a message from the first authentication node for a period of time exceeding a set threshold.

[0097] This application's embodiments avoid node disagreements caused by minority votes by using a majority vote election rule, ensuring the legitimacy and authority of the new first authentication node; automatic role switching quickly restores the core functions of the system, reduces service interruption time, and solves the problems of long election time and inconsistent consensus in traditional distributed systems for the first authentication node.

[0098] In one example, this application embodiment uses the Raft algorithm to switch the identity of authentication nodes. Specifically, the Raft algorithm divides time into terms. When a follower initiates an election, it becomes a candidate and increments its current term number. If it receives a majority of votes from followers, it becomes the leader of the current term. Each server needs to maintain a variable to record the current term number. Raft uses a timeout mechanism to control elections. Each server is given a random timeout period. If a follower hasn't received a message from the leader after a timeout, it assumes the leader has crashed and initiates a new election. A leader crash or network connectivity issues between the leader and followers will cause this timeout. The server initiating the election (follower) needs to do three things: 1. First, it switches to a candidate state and votes for itself. 2. Then, it increments its saved term number and sends the new term number to all other servers. 3. If it receives a majority of votes, it switches to the leader state; if it doesn't receive a majority of votes within a certain time, it resets the timeout and switches back to the follower state to wait for the next election.

[0099] In summary, this application's embodiment, by using both certified and non-certified nodes—a dual-distributed node approach—allows different participants, such as parties involved in a case and other government regulatory departments, to participate in the data preservation process. This improves the convenience of obtaining preserved data, ensures cross-departmental data acquisition and verification, and plays a crucial role in guaranteeing the authenticity and impartiality of electronic data preservation. During the data preservation stage, a custom-developed consensus layer logic program determines the mechanism for acquiring the blockchain's accounting rights (the right to link blocks on the main chain). The adoption of a custom extended Raft logic algorithm for electing a leader for block accounting rights ensures the randomness and fairness of blockchain accounting rights. During the electronic evidence verification stage, by having one or more participant nodes verify the authenticity of the block data, all participants acting as verification nodes can perform tamper-proof and forgery-proof verification of all block data. This increases the difficulty of tampering and forgery of blockchain storage node data, further enhancing the tamper-proof characteristics of block data in the blockchain.

[0100] Figure 7This application illustrates a blockchain data verification device 700, which is applied to a first authentication node in a blockchain network. The first authentication node is a preset authentication node. The device may include: The receiving module 701 is used to receive a data storage request sent by the client device. The data storage request includes stored data and data identifier. The signature module 702 is used to generate a storage block including stored data and a data identifier, and to sign the storage block according to the preset private key of the first authentication node to obtain a target block. The target block includes stored data, a data identifier, a preset public key, and signature information. The sending module 703 is used to send the target block to all second authentication nodes in the blockchain network, so that the second authentication nodes can verify the signature information of the target block according to the preset public key, and store the target block if the verification is successful. The sending module 703 is also used to send the target block corresponding to the data identifier to the non-authenticated node when it receives a data synchronization request including a data identifier from the non-authenticated node, so that the non-authenticated node can verify the signature information of the target block according to the preset public key and obtain the verification result.

[0101] In some embodiments, the blockchain data verification device 700 may further include: The calculation module is used to perform hash calculations on the stored data to obtain hash values; The determination module is used to determine the signature information of the storage block based on the preset private key and hash value of the first authentication node.

[0102] In some embodiments, the determining module is further configured to determine temporary point data and the coordinates of temporary points based on random numbers and a preset elliptic curve; The determination module is also used to determine the signature value based on the preset private key, hash value, coordinates of the temporary point, and random number.

[0103] In some embodiments, the blockchain data verification device 700 may further include: The setting module is used to set the first authentication node as the second authentication node with a target term number when a node reset request is received from the target second authentication node. The target second authentication node is the second authentication node that has not received a message from the first authentication node for a period of time exceeding a set threshold. The node reset request includes the target term number, which is the total number of times all authentication nodes have initiated the election of the first authentication node.

[0104] Figure 7 The various modules in the device shown can achieve Figure 2 The various steps involved, and the corresponding technical effects achieved, will not be elaborated upon here for the sake of brevity.

[0105] Figure 8 This application illustrates a blockchain data verification device 800, which is applied to a second authentication node in a blockchain network. The second authentication node is an authentication node other than the first authentication node, and the first authentication node is a preset authentication node. The device may include: The receiving module 801 is used to receive the target block sent by the first authentication node. The target block includes stored data, data identifier, preset public key and signature information. The verification module 802 is used to verify the signature of the target block according to the preset public key, and store the target block if the verification is successful. The sending module 803 is used to send the target block corresponding to the data identifier to the non-authenticated node when it receives a data synchronization request including a data identifier from the non-authenticated node, so that the non-authenticated node can receive the target block and verify the signature information of the target block according to the preset public key to obtain the verification result.

[0106] In some embodiments, the blockchain data verification device 800 may further include: The sending module 803 is also used to send a node reset request to the first authentication node and other second authentication nodes other than the first authentication node and the second authentication node that has not received a message from the first authentication node for a period of time exceeding a set threshold. The node reset request includes a target term number, which is the total number of times all authentication nodes have initiated the election of the first authentication node. The receiving module 801 is also used to receive the ballots sent by the other second authentication nodes and count the number of ballots received by the second authentication nodes; The setting module is used to set the second authentication node as the first authentication node for the target term number when the number of votes cast by the second authentication node exceeds a set threshold.

[0107] Figure 8 The various modules in the device shown can achieve Figure 2 The various steps involved, and the corresponding technical effects achieved, will not be elaborated upon here for the sake of brevity.

[0108] Figure 9 This application illustrates a blockchain data verification device 900, applied to a non-authentication node in a blockchain network. The device may include: The sending module 901 is used to send a data synchronization request to at least one first authentication node or a second authentication node. The data synchronization request includes a data identifier, which is used by the authentication node that receives the data synchronization request to send the target block corresponding to the data identifier to the non-authentication node. The target block includes stored data, a data identifier, a preset public key, and signature information. The receiving module 902 is used to receive the target block sent by the authentication node, and verify the signature information of the target block according to the preset public key to obtain the verification result.

[0109] In some embodiments, the blockchain data verification device 900 may further include: The calculation module is used to perform hash calculations on the stored data to obtain hash values; The determination module is used to determine the target temporary point data based on the hash value, the preset public key, and the signature value; The verification module is used to obtain a verification pass result when the temporary point data is the same as the target temporary point data.

[0110] Figure 9 The various modules in the device shown can achieve Figure 2 The various steps involved, and the corresponding technical effects achieved, will not be elaborated upon here for the sake of brevity.

[0111] Figure 10 A schematic diagram of the hardware structure of the terminal device provided in an embodiment of this application is shown.

[0112] The terminal device may include a processor 1001 and a memory 1002 storing computer program instructions.

[0113] Specifically, the processor 1001 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0114] Memory 1002 may include mass storage for data or instructions. For example, and not limitingly, memory 1002 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 1002 may include removable or non-removable (or fixed) media, or memory 1002 may be non-volatile solid-state memory. Memory 1002 may be internal or external to the integrated gateway disaster recovery device.

[0115] In one instance, memory 1002 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method for blockchain data verification according to this disclosure.

[0116] The processor 1001 reads and executes computer program instructions stored in the memory 1002 to achieve... Figure 1 The method for blockchain data verification in the illustrated embodiment.

[0117] In one example, the terminal device may further include a communication interface 1003 and a bus 1004. Wherein, for example... Figure 10 As shown, the processor 1001, memory 1002, and communication interface 1003 are connected through bus 1004 and complete communication with each other.

[0118] The communication interface 1003 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0119] Bus 1004 includes hardware, software, or both, that couples components of an end device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 1004 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0120] Furthermore, in conjunction with the blockchain data verification methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the blockchain data verification methods in the above embodiments.

[0121] This application also provides a computer program product, including a computer program that, when executed, implements any of the blockchain data verification methods described in the above embodiments.

[0122] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0123] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or text segments used to perform the required tasks. Programs or text segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Text segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0124] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0125] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0126] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for blockchain data verification, characterized in that, The method includes: A first authentication node applied to a blockchain network, wherein the first authentication node is a preset authentication node; Receive a data storage request sent by a client device, wherein the data storage request includes stored data and a data identifier; A storage block including the stored data and data identifier is generated, and the storage block is signed according to the preset private key of the first authentication node to obtain a target block. The target block includes the stored data, data identifier, preset public key and signature information. The target block is sent to all second authentication nodes in the blockchain network so that the second authentication nodes can verify the signature information of the target block according to the preset public key, and store the target block if the verification is successful. Upon receiving a data synchronization request containing a data identifier from an unauthenticated node, the system sends the target block corresponding to the data identifier to the unauthenticated node. The unauthenticated node then verifies the signature information of the target block using a preset public key to obtain a verification result.

2. The method for blockchain data verification according to claim 1, characterized in that, Signing the storage block according to the preset public key of the first authentication node includes: Perform a hash calculation on the stored data to obtain a hash value; The signature information of the storage block is determined based on the preset private key and hash value of the first authentication node.

3. The method for blockchain data verification according to claim 2, characterized in that, The signature information includes temporary point data and a signature value. The step of determining the signature information of the storage block based on the preset private key and hash value of the first authentication node includes: The temporary point data and coordinates of the temporary points are determined based on random numbers and a preset elliptic curve. The signature value is determined based on the preset private key, hash value, coordinates of the temporary point, and random number.

4. The method for blockchain data verification according to claim 1, characterized in that, The method further includes: Upon receiving a node reset request from the target second authentication node, the first authentication node is set as the second authentication node with the target term number. The target second authentication node is the second authentication node that has not received a message from the first authentication node for a period exceeding a set threshold. The node reset request includes the target term number, which is the total number of times all authentication nodes have initiated the election of the first authentication node.

5. A method for blockchain data verification, characterized in that, A second authentication node applied to a blockchain network, wherein the second authentication node is an authentication node other than the first authentication node, and the first authentication node is a preset authentication node, the method includes: Receive the target block sent by the first authentication node, wherein the target block includes stored data, data identifier, preset public key and signature information; The signature of the target block is verified using the preset public key, and the target block is stored if the verification is successful. Upon receiving a data synchronization request containing a data identifier from an unauthenticated node, the system sends a target block corresponding to the data identifier to the unauthenticated node. The unauthenticated node then receives the target block and verifies its signature information using a preset public key to obtain a verification result.

6. The method for blockchain data verification according to claim 5, characterized in that, The method further includes: If the time without receiving a message from the first authentication node exceeds a set threshold, a node reset request is sent to the remaining second authentication nodes other than the first authentication node and the second authentication node that has not received a message from the first authentication node for a longer period than the set threshold. The node reset request includes a target term number, which is the total number of times all authentication nodes have initiated the election of the first authentication node. Receive the votes sent by the other second authentication nodes and count the number of votes received by the second authentication nodes; If the number of votes cast by the second authentication node exceeds a set threshold, the second authentication node will be set as the first authentication node for the target term number.

7. A method for blockchain data verification, characterized in that, The method, applied to non-authenticated nodes in a blockchain network, includes: Send a data synchronization request to at least one first authentication node or a second authentication node. The data synchronization request includes a data identifier, so that the authentication node receiving the data synchronization request can send the target block corresponding to the data identifier to the non-authentication node. The target block includes stored data, a data identifier, a preset public key, and signature information. The system receives the target block sent by the authentication node and verifies the signature information of the target block according to the preset public key to obtain the verification result.

8. The method for blockchain data verification according to claim 7, characterized in that, The signature information includes temporary dot data and a signature value. A preset public key is used to verify the signature information of the target block to obtain a verification result, including: Perform a hash calculation on the stored data to obtain a hash value; The target temporary point data is determined based on the hash value, the preset public key, and the signature value. If the temporary point data is the same as the target temporary point data, the verification result is obtained.

9. A device for blockchain data verification, characterized in that, A first authentication node applied to a blockchain network, wherein the first authentication node is a preset authentication node, the device comprising: The receiving module is used to receive a data storage request sent by a client device, wherein the data storage request includes stored data and a data identifier; The signature module is used to generate a storage block including the stored data and the data identifier, and to sign the storage block according to the preset private key of the first authentication node to obtain a target block. The target block includes the stored data, the data identifier, the preset public key, and the signature information. The sending module is used to send the target block to all second authentication nodes in the blockchain network, so that the second authentication nodes can verify the signature information of the target block according to the preset public key, and store the target block if the verification is successful. The sending module is further configured to, upon receiving a data synchronization request including a data identifier sent by an unauthenticated node, send a target block corresponding to the data identifier to the unauthenticated node, so that the unauthenticated node can verify the signature information of the target block according to a preset public key and obtain a verification result.

10. A device for blockchain data verification, characterized in that, A second authentication node applied to a blockchain network, wherein the second authentication node is an authentication node other than the first authentication node, and the first authentication node is a preset authentication node, the device comprising: The receiving module is used to receive the target block sent by the first authentication node. The target block includes stored data, data identifier, preset public key and signature information. The verification module is used to verify the signature of the target block according to the preset public key, and store the target block if the verification is successful. The sending module is used to send a target block corresponding to the data identifier to the non-authenticated node when it receives a data synchronization request including a data identifier from the non-authenticated node. The non-authenticated node can then receive the target block and verify the signature information of the target block according to a preset public key to obtain a verification result.

11. A device for blockchain data verification, characterized in that, The device, used for non-authenticated nodes in a blockchain network, includes: The sending module is used to send a data synchronization request to at least one first authentication node or a second authentication node. The data synchronization request includes a data identifier, which is used by the authentication node that receives the data synchronization request to send the target block corresponding to the data identifier to the non-authentication node. The target block includes stored data, a data identifier, a preset public key, and signature information. The receiving module is used to receive the target block sent by the authentication node, and verify the signature information of the target block according to the preset public key to obtain the verification result.

12. A terminal device, characterized in that, The device includes: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements the blockchain data verification method as described in any one of claims 1-8.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the blockchain data verification method as described in any one of claims 1-8.

14. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the blockchain data verification method as described in any one of claims 1-8.

Images