Block chain data storage processing method and device and related equipment

Abstract

The invention provides a block chain data storage processing method and device and related equipment, and is applied to a first node, and the method comprises the steps: under the condition that a block chain newly builds a first block, coding non-coding data of a target block based on a unique identifier of the first node, and obtaining a coding block of the target block, the coding block of the target block is a unique data copy of non-coding data of the target block, and the target block comprises a first block; taking the coding block of the target block as private input, taking the non-coding data of the target block as public input, and carrying out non-interactive certification on correct execution of the coding process to obtain a storage certification of the coding block of the target block; and broadcasting a storage proof of the coding block of the target block, the storage proof being used for a second node to perform verification based on the non-coding data of the target block, and the second node being used for performing storage verification on the unique data copy of the block chain data.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a blockchain data storage and processing method, apparatus, and related equipment. Background Technology

[0002] Proof of Storage (PoS) is a distributed storage technology that ensures data is securely and completely stored across multiple nodes in a network. The core principle of PoS is that when a data owner stores data on a node, that node needs to generate and provide a proof that the specific data block has indeed been stored. This proof is typically achieved by calculating the hash value of the data and storing it on a blockchain or other distributed ledger.

[0003] Practical Proof of Storage (PPoS) has been widely used in blockchain. PPoS is a mechanism for verifying whether storage nodes in a distributed storage network actually store data. It aims to solve the problem of data availability and integrity verification in large-scale data storage environments. The core idea is to have storage nodes periodically prove that they still hold specific data, rather than performing a one-time proof only during storage. This periodic verification ensures that even after data storage, nodes will not delete or tamper with the data.

[0004] In related technologies, PPoS is an interactive protocol that requires a peer-to-peer "challenge-response" process between validators and provers. This not only leads to high communication overhead and verification delays, but also leaves room for collusion between validators and provers, undermining the trust foundation of decentralized systems and affecting the reliability of blockchain data storage proofs. Summary of the Invention

[0005] This application provides a blockchain data storage processing method, apparatus, and related equipment, which can solve the technical problem in related technologies that storage proof through interactive protocols undermines the trust foundation of decentralized systems and affects the reliability of blockchain data storage proof.

[0006] In a first aspect, embodiments of this application provide a blockchain data storage and processing method, applied to a first node, wherein the first node is used to store proof of a unique data copy of the blockchain data, the method comprising:

[0007] When a new first block is created in the blockchain, the non-encoded data of the target block is encoded based on the unique identifier of the first node to obtain the encoded block of the target block. The encoded block of the target block is a unique data copy of the non-encoded data of the target block, and the target block includes the first block.

[0008] Using the encoded block of the target block as private input and the non-encoded data of the target block as public input, a non-interactive proof of the correct execution of the encoding process is performed to obtain the storage proof of the encoded block of the target block.

[0009] The storage proof of the encoded block of the target block is broadcast, and the storage proof is used by the second node to verify the non-encoded data of the target block. The second node is used to verify the storage of a unique data copy of the blockchain data.

[0010] Secondly, embodiments of this application provide a blockchain data storage and processing method applied to a second node, the second node being used to store and verify a unique data copy of the blockchain data, the method comprising:

[0011] Upon receiving the storage proof of the encoded block of the target block, the encoded block of the target block is decoded based on the unique identifier of the first node to obtain decoded data. The first node is used to provide storage proof for a unique data copy of the blockchain data.

[0012] Using the decoded data as private input and the non-encoded data of the target block as public input, a non-interactive proof algorithm is executed to verify the storage proof of the encoded block of the target block, and the verification result is obtained.

[0013] The storage proof of the target block's coded block is obtained by using the target block's coded block as private input and the target block's non-coded data as public input, to perform a non-interactive proof of the correct execution of the encoding process. The target block's coded block is obtained by encoding the non-coded data of the target block based on the unique identifier of the first node when the first block is newly created in the blockchain. The target block's coded block is a unique data copy of the target block's non-coded data, and the target block includes the first block.

[0014] Thirdly, embodiments of this application provide a blockchain data storage and processing apparatus applied to a first node, the first node being used to store proof of a unique data copy of the blockchain data, the apparatus comprising:

[0015] An encoding module is used to encode the non-encoded data of a target block based on the unique identifier of the first node when a new first block is created in the blockchain, to obtain an encoded block of the target block. The encoded block of the target block is a unique data copy of the non-encoded data of the target block, and the target block includes the first block.

[0016] The proof module is used to take the encoded block of the target block as private input and the non-encoded data of the target block as public input to perform non-interactive proof of the correct execution of the encoding process, and obtain the storage proof of the encoded block of the target block;

[0017] The broadcast module is used to broadcast the storage proof of the coded block of the target block. The storage proof is used by the second node to verify the storage of the unique data copy of the blockchain data based on the non-coded data of the target block.

[0018] Fourthly, this application provides a blockchain data storage and processing device applied to a second node, the second node being used to store and verify a unique data copy of the blockchain data. The device includes:

[0019] The decoding module is used to decode the encoded block of the target block based on the unique identifier of the first node when a storage proof of the encoded block of the target block is received, so as to obtain decoded data. The first node is used to provide storage proof for a unique data copy of the blockchain data.

[0020] The verification module is used to take the decoded data as private input, take the non-encoded data of the target block as public input, execute a non-interactive proof algorithm to verify the storage proof of the encoded block of the target block, and obtain the verification result.

[0021] The storage proof of the target block's coded block is obtained by using the target block's coded block as private input and the target block's non-coded data as public input, to perform a non-interactive proof of the correct execution of the encoding process. The target block's coded block is obtained by encoding the non-coded data of the target block based on the unique identifier of the first node when the first block is newly created in the blockchain. The target block's coded block is a unique data copy of the target block's non-coded data, and the target block includes the first block.

[0022] Fifthly, embodiments of this application provide a node, including: a processor, a memory, and a program stored in the memory and executable on the processor. When the program is executed by the processor, it implements the steps of the blockchain data storage processing method as described in the first aspect, or implements the steps of the blockchain data storage processing method as described in the second aspect.

[0023] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the blockchain data storage and processing method as described in the first aspect, or implements the steps of the blockchain data storage and processing method as described in the second aspect.

[0024] In a seventh aspect, embodiments of this application provide a computer program product, including computer instructions that, when executed by a processor, implement the steps of the blockchain data storage processing method as described in the first aspect, or implement the steps of the blockchain data storage processing method as described in the second aspect.

[0025] In this embodiment, when a first node creates a new block in the blockchain, it encodes the non-encoded data of the target block based on the unique identifier of the first node to obtain an encoded block of the target block. The encoded block of the target block is a unique data copy of the non-encoded data of the target block, and the target block includes the first block. Using the encoded block of the target block as private input and the non-encoded data of the target block as public input, a non-interactive proof of the correct execution of the encoding process is performed to obtain a storage proof of the encoded block of the target block. The storage proof of the encoded block of the target block is broadcast, and the storage proof is used by a second node to verify the non-encoded data of the target block. The second node is used to verify the storage of the unique data copy of the blockchain data. In this way, when generating a unique data copy that is bound to the node identity based on the unique identifier of the first node, a completely non-interactive, publicly verifiable, and trustless proof system is constructed for this unique data copy through non-interactive proof. This completely eliminates the dependence on the data owner and centralized key, fundamentally solves the collusion risk of interactive protocols, and ensures the long-term security and universality of the system due to its characteristics of not requiring trust settings and being resistant to quantum computing. Attached Figure Description

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

[0027] Figure 1 This is one of the flowcharts of a blockchain data storage and processing method provided in the embodiments of this application;

[0028] Figure 2 This is a schematic diagram illustrating the use of a two-stage data sampling mechanism for non-coded data sampling;

[0029] Figure 3 This is a diagram illustrating the encoding process;

[0030] Figure 4 This is a schematic diagram of the decoding process;

[0031] Figure 5 This is a schematic diagram illustrating the generation of storage proofs using the zk-STARKs protocol;

[0032] Figure 6 This is a second flowchart of a blockchain data storage and processing method provided in the embodiments of this application;

[0033] Figure 7 This is a diagram illustrating the relative time difference recorded by the verifier's local clock;

[0034] Figure 8 This is an architecture diagram of a specific example of a blockchain data storage and processing method provided in an embodiment of this application;

[0035] Figure 9 This is one of the structural schematic diagrams of a blockchain data storage and processing device provided in the embodiments of this application;

[0036] Figure 10 This is a second schematic diagram of the structure of a blockchain data storage and processing device provided in the embodiments of this application;

[0037] Figure 11 This is a schematic diagram of the structure of a node provided in an embodiment of this application. Detailed Implementation

[0038] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0039] Proof of Storage (PoS) is a distributed storage technology that ensures data is securely and completely stored across multiple nodes in a network. The core principle of PoS is that when a data owner stores data on a node, that node needs to generate and provide a proof that the specific data block has indeed been stored. This proof is typically achieved by calculating the hash value of the data and storing it on a blockchain or other distributed ledger. The following sections introduce the mainstream PoS technologies currently in use:

[0040] 1. Proof of Data Possession (PDP)

[0041] PDP is a remote storage auditing mechanism where verifiers confirm that the storage provider "actually stores" the original data by challenging a small number of random blocks and verifying homomorphic authentication tags or hash commitments, without downloading the entire file. Its advantages include lightweight nature, bandwidth friendliness, small proof size, and fast verification. It can achieve public (third-party verifiable) or private verifiable verification and can be extended to support dynamic PDP (DPDP) that supports addition, deletion, and modification. However, PDP only directly guarantees possession and integrity, not "retrievability," and requires maintaining tags for each block, incurring a small storage overhead. The dynamic version has higher complexity in terms of index structure and consistency maintenance.

[0042] 2. Proof of Replication (POR)

[0043] Proof-of-Retrievability (POR) further enhances the "retrievability" guarantee on top of Proof-of-Retrievability (PDP). This is often achieved by first encoding the data with erasure coding (such as Reed-Solomon, RS) or embedding hidden "sentinel" blocks, making it possible to recover the complete file in an information theory sense through long-term sampling audits. Its advantages include stronger security guarantees while maintaining relatively low proof and verification overhead, and the availability of publicly verifiable versions facilitates continuous third-party auditing. Its disadvantages include increased preprocessing costs and storage redundancy due to encoding and tag generation before uploading, and higher requirements for the design and dynamic updating of parameters (such as bitrate and sampling strength). Otherwise, a balance between security and performance becomes difficult to achieve.

[0044] 3. Proof of Replication (PoRep)

[0045] PoRep is an improved proof-of-replication mechanism designed to enhance the efficiency and security of data storage. Similar to traditional proof-of-replication mechanisms, PoRep requires storage nodes to prove they actually hold copies of the data. However, PoRep introduces an innovative technique called "Replication Proof," enabling nodes to prove they hold multiple copies of the data with a smaller proof size. This mechanism not only improves storage efficiency but also enhances data security and reliability because it allows the network to verify whether nodes do indeed hold multiple copies of the data without actually transmitting those copies.

[0046] 4. Proof of Space-Time (PoSt)

[0047] PoSt is a proof mechanism that combines spatial and temporal aspects, primarily used for proof of storage and proof of data availability. Unlike the mechanisms mentioned above, PoSt requires nodes to prove that they not only hold copies of the data but also maintain its availability for a specific time period. This mechanism requires nodes to provide proof, while storing data, that they have not altered or deleted it within the specified timeframe. PoSt is commonly used in applications requiring long-term data storage and proof of data availability, such as distributed storage networks and decentralized file systems.

[0048] POR, PoRep, and PoSt can impact system performance due to the time-consuming decoding process. Since most existing PoStorage solutions are based on a client-and-storage-provider model that handles confidential information or performs trust setup processes requiring specific permissions, they are unsuitable for all nodes in a blockchain.

[0049] 5. PPPoS

[0050] PPoS is a mechanism for verifying whether storage nodes in a distributed storage network actually store data. It's a practical application of PDP, designed to solve the problem of data availability and integrity verification in large-scale data storage environments. The core idea is to have storage nodes periodically prove they still hold specific data, rather than performing a one-time proof during storage. This periodic verification ensures that even after data storage, nodes will not delete or tamper with the data.

[0051] The advantages of PPoS lie in its strong guarantee of data integrity, preventing data loss or tampering. It also offers good scalability when handling large-scale data storage, adapting to the needs of large-scale distributed storage networks. Furthermore, it eliminates the need to retrieve the entire dataset for verification, saving network bandwidth and computing resources. It also enhances system security through encryption and hashing techniques and can serve as an economic incentive for nodes to store data in some systems. The disadvantages are that generating proofs requires significant computing resources, increasing the operating costs of storage nodes, potentially introducing data access latency, the implementation of complex algorithms and protocols, the energy consumption of the verification process, and the need for storage nodes to reserve substantial storage space for proof history.

[0052] While existing solutions such as PPoS have solved the problem of verifying remote data storage to some extent, they still face fundamental design flaws and multiple technical challenges when applied to verifying whether a blockchain full node has completely and honestly stored the entire ledger.

[0053] First, traditional PPoS is an interactive protocol that requires a peer-to-peer challenge-response between validators and provers. This not only leads to high communication overhead and verification latency, but also leaves room for collusion between validators and provers, undermining the trust foundation of decentralized systems.

[0054] Secondly, the generated proofs in these technologies are quite large, which can place a significant burden on the blockchain's network bandwidth and the computing resources of nodes in scenarios requiring network-wide broadcasting and verification. A deeper problem lies in the fact that most of these solutions are based on a "client-server" or "data owner-storage provider" architecture, which suffers from the following three core incompatibilities with the operating environment of a full blockchain node:

[0055] 1. The problem of centralized assumptions in identity and key management.

[0056] Traditional PoStorage schemes assume a single "data owner" who manages the core cryptographic keys (such as private keys) needed to generate data copies or proofs. This model is impractical in a blockchain full-node environment because each block's data is generated collaboratively by numerous participants across the network; there is no single owner, and it's impossible to securely distribute sensitive global keys to all nodes requiring verification. Therefore, designing a trustless storage proof mechanism that completely eliminates dependence on a specific data owner or centralized key management, allowing any node to publicly and independently verify the validity of proofs without holding any private information, becomes a key challenge.

[0057] 2. The problem of proving the uniqueness of isomorphic data and copies.

[0058] In traditional models, each client stores distinct data. However, in blockchain, all full nodes store identical (homogeneous) ledger data. This introduces new security risks: malicious nodes could deceive the network by sharing a single physical storage or storing only partial data, claiming to be multiple independent, complete nodes. Existing solutions lack effective mechanisms to prove that a node stores a unique, physically independent copy strongly bound to its own identity. Designing a mechanism that mandates each full node to generate a unique, unforgeable, and non-transferable copy of its stored homogeneous ledger data, and that can verify the uniqueness and integrity of this copy through proofs, is therefore crucial.

[0059] 3. Comprehensive issues of performance, scalability, and network governance

[0060] The continuous growth of blockchain data demands that storage proof schemes possess high scalability. Existing schemes often face bottlenecks when handling large-scale data, such as excessively long proof generation times and large proof sizes. Furthermore, they typically focus only on the "right / wrong" nature of proofs, lacking dynamic evaluation of node behavior (such as response latency). This makes it difficult to effectively identify and incentivize high-performance, honest nodes in a decentralized environment with complex network conditions and heterogeneous nodes, and also fails to punish or isolate nodes exhibiting abnormal behavior. Therefore, it is necessary to design a comprehensive solution that combines efficiency, scalability, and dynamic governance capabilities. This solution should not only be able to handle ever-increasing data but also introduce a dynamic, performance-based reputation mechanism to incentivize honest behavior, optimize network communication, and provide reliable node evaluation criteria for upper-layer consensus mechanisms.

[0061] To systematically address the three core issues mentioned above, this application proposes a novel non-interactive proof-based blockchain data storage and processing method, which can be called the Non-Interactive Practical Storage Proof (nPPoS) scheme, based on PPoS. This method fundamentally improves upon related technologies in the following three aspects:

[0062] To address the first technical problem, a non-interactive zero-knowledge proof scheme is proposed: using the zk-STARKs protocol, a completely non-interactive, publicly verifiable proof system that does not require trusted settings is constructed, which completely eliminates the dependence on data owners and centralized keys, and fundamentally solves the collusion risk of interactive protocols.

[0063] To address the second technical problem, asymmetric encoding / decoding and chained random sampling are proposed: an asymmetric encoding / decoding algorithm that is "slow in encoding but fast in decoding" is designed, forcing each node to generate a unique data copy of the block data that is bound to its identity. Simultaneously, a two-stage chained random sampling mechanism enables efficient and manipulator-resistant probabilistic verification of the integrity of this copy.

[0064] To address the third technical problem, a time-weighted trust model is proposed: a time-weighted reputation system based on the verifier's local clock is introduced to dynamically evaluate the verifier's response performance and reliability. This model not only achieves adaptive load balancing of the network but also provides a solid foundation for the dynamic governance and incentive mechanisms of the entire system.

[0065] Through the above three aspects, the nPPoS solution of this application embodiment can provide a complete solution for blockchain data storage and processing that is secure, efficient, scalable, and has good governance capabilities.

[0066] It should be noted that the blockchain data storage processing method in this application embodiment is applied to a blockchain data storage processing system, and relates to the technical fields of blockchain, data storage, etc. The blockchain data storage processing system may include a first node and a second node. Both the first node and the second node are nodes in the blockchain and can implement the blockchain data storage processing method in this application embodiment.

[0067] See Figure 1 , Figure 1 This is one of the flowcharts of a blockchain data storage and processing method provided in this application embodiment, applied to a first node, which is used to store proof of a unique data copy of the blockchain data, such as... Figure 1 As shown, the method includes the following steps:

[0068] Step 101: When a new first block is created in the blockchain, the non-encoded data of the target block is encoded based on the unique identifier of the first node to obtain the encoded block of the target block. The encoded block of the target block is a unique data copy of the non-encoded data of the target block. The target block includes the first block.

[0069] Step 102: Using the encoded block of the target block as private input and the non-encoded data of the target block as public input, a non-interactive proof of the correct execution of the encoding process is performed to obtain the storage proof of the encoded block of the target block.

[0070] Step 103: Broadcast the storage proof of the coded block of the target block. The storage proof is used by the second node to verify the non-coded data of the target block. The second node is used to verify the storage of a unique data copy of the blockchain data.

[0071] The first node can be any full node in the blockchain, and the unique identifier of the first node can be the unique node address of the first node.

[0072] In some embodiments, when a new first block is created on the blockchain, any full node in the blockchain can be randomly selected as the first node. Randomness is the cornerstone of ensuring the security of this non-interactive proof, and it runs through the two key stages of prover selection and data sampling. Its randomness mechanism aims to achieve the goals of being publicly verifiable, resistant to manipulation, and efficient.

[0073] In some embodiments, step 101 specifically includes:

[0074] If the hash result is greater than or equal to a preset probability threshold, the non-encoded data of the target block is encoded based on the unique identifier of the first node to obtain the encoded block of the target block; wherein,

[0075] The hash result is obtained by concatenating the hash value of the first block with the unique identifier of the first node, and then performing a hash operation on the concatenated value.

[0076] Its randomness mainly comes from the public data that is generated by the blockchain and is recognized by the entire network, namely the hash value of the newly generated first block. This hash value has good pseudo-randomness and unpredictability, and can be used as a unified cryptographic seed for the entire network. Therefore, the prover selection, i.e. the selection of the first node, can be based on the hash value of the first block.

[0077] To decentralize the selection of provers for the current round, each full node, upon receiving a new block (the first block), executes a deterministic algorithm based on a publicly available on-chain random source to determine its selection. In some embodiments, the hash value of the first block can be concatenated with a node's unique identifier, such as a unique node address, and the resulting hash is then hashed. If the hash result is greater than or equal to a preset probability threshold, the node automatically becomes a prover, storing the proof as the unique data copy of the first node's block data. This automatic selection mechanism requires no centralized coordinator. The preset probability threshold can be designed as an adjustable parameter to strike a balance between security (high-frequency proofs provide more timely security guarantees) and system overhead (frequent proof generation and broadcasting consume computational and network resources). A node only receives an increased trust score after being selected and successfully generating a valid proof, thus incentivizing its honest participation.

[0078] In some embodiments, when a new first block is created in the blockchain, a unique data copy of the non-coded data of the first block needs to be generated by the first node to obtain the coded block of the first block.

[0079] In some embodiments, in addition to triggering the prover selection, the hash value of the first block is also used as a random seed to randomly select one or more historical blocks from the entire blockchain history as the target for this storage proof. That is, the method further includes:

[0080] Based on the hash value of the first block, a third block is selected from the blockchain. The third block is a block generated historically in the blockchain relative to the first block, and the target block also includes the third block.

[0081] In other words, while generating the storage proof of the coded block of the first block, the first node can also generate the storage proof of the coded block of the third block, so as to ensure the unpredictability of the audit, making it impossible for attackers to predict which historical data will be audited, thus requiring the complete storage of the entire ledger.

[0082] The storage proof of the encoded block of the first block is generated in the same way as the storage proof of the encoded block of the third block. The following explanation uses the first block as an example.

[0083] In some embodiments, the full uncoded data of the first block can be encoded to generate a coded block of the first block, and a full proof of the coded block of the first block can be generated.

[0084] In some embodiments, prior to step 101, the method further includes:

[0085] The non-coded data of the target block is divided into M data subsets;

[0086] Select one data point from each subset of data as the anchor point location;

[0087] Based on the data points at each anchor point, a Merkle tree is constructed, and the root hash of the Merkle tree is calculated.

[0088] Based on the root hash of the Merkle tree, the starting sampling position of the non-coded data of the target block is determined;

[0089] Starting from the initial sampling position, data of a preset size is read from the non-coded data of the target block to obtain a target data subset, the data size of the data subset being the preset value;

[0090] Step 101 specifically includes:

[0091] Based on the unique identifier of the first node, the target data subset in the non-coded data of the target block is encoded to obtain the coded block of the target block.

[0092] Because the computational cost of non-interactive proofs such as zk-STARKs proofs is closely related to the size of the dataset being proved (i.e., the highest degree of the polynomial), directly generating a full proof for megabyte (MB) level block data is not feasible on ordinary nodes. Therefore, data can be extracted from the uncoded data of the first block to generate a stored proof of the coded block of the first block based on a subset of the target data.

[0093] In some embodiments, an efficient and secure two-stage data sampling mechanism can be designed to select a fixed size (determined by parameters) from the non-coded data of the first block. A subset of the target data (defined) is used to generate the storage proof. This mechanism aims to ensure the randomness of sampling and resistance to premeditated attacks; its implementation principle is as follows: Figure 2 As shown.

[0094] Specifically, the first stage can involve selecting anchor points within a segment, logically dividing the data in the first block into multiple segments of varying sizes. We obtain M data subsets from consecutive paragraphs. A combined random seed is used to deterministically generate a random anchor point position for each paragraph. This means that within each paragraph, there will be a randomly selected data point.

[0095] The second stage can establish a starting sampling position to collect a subset of the target data. Data from all anchor points selected in the first stage across all paragraphs can be used to construct a Merkle Tree, and its unique root hash (Merkle Root) can be calculated. This Merkle root is used as a new, random seed for the second stage to ultimately determine a global starting sampling position. Starting from this position, data is continuously read... The data in bytes serves as the final target data subset used to generate zk-STARKs proofs.

[0096] This design significantly enhances security. If an attacker wants to pass the verification using pre-constructed fake data, they must ensure that the fake data generates a specific Merkle root, which in turn must generate a starting point that points precisely to the location of their fake data. Because the Merkle root is extremely sensitive to any tiny change in the input (avalanche effect), attackers cannot pre-construct fake data that can pass the second-stage verification without knowing the randomness of the first stage, thus effectively preventing attacks targeting the sampling process.

[0097] In some embodiments, the non-coded data of the first block can be encoded using a relevant encoding algorithm based on the unique identifier of the first node to obtain the encoded block of the first block.

[0098] In some embodiments, step 101 specifically includes:

[0099] Based on the unique identifier of the first node, the non-coded data of the target block is bound to the identity of the first node to obtain the first data of the target block;

[0100] Using the encoded block of the second block as a key, the first data is encoded to obtain the encoded block of the target block, where the second block is the preceding block of the target block in the blockchain.

[0101] To effectively counter Sybil attacks, outsourcing attacks, and generation attacks, the encoding process can possess two key characteristics: first, it can generate a unique data copy for each prover that is bound to their identity; second, it is computationally time-consuming to increase the attacker's operational costs.

[0102] Based on the unique identifier of the first node, the non-coded data of the first block can be bound to the identity of the first node to obtain the first data of the target block, so as to generate a unique data copy bound to the identity of each prover.

[0103] The encoded block of the second block can be used as a key to encode the first data, thus obtaining the encoded block of the first block. This chain-like dependency enhances the immutability of historical data.

[0104] In some embodiments, the first data includes n first data units, and the step of encoding the first data using the encoded block of the second block as a key to obtain the encoded block of the target block includes:

[0105] The i-th second data unit in the encoding block of the second block is used as the key to encode the i-th first data unit, where n is a positive integer greater than 1 and i is a positive integer less than or equal to n.

[0106] The encoding result of the i-th first data unit is mixed with the (i-1)-th intermediate result to obtain the i-th third data unit. The encoding block of the target block includes n third data units. The (i-1)-th intermediate result is obtained by mixing the encoding result of the (i-1)-th first data unit with the (i-2)-th intermediate result.

[0107] In blockchain, data reading and verification occur far more frequently than writing and encoding. A time-consuming decoding process can severely impact the performance of full nodes and the efficiency of the entire network. Therefore, the core of this embodiment lies in designing an encoding and decoding scheme with asymmetric computational complexity. Specifically, this scheme ensures that the encoding process is slow and difficult to parallelize, while the decoding process is fast and highly parallelizable, thereby minimizing the impact on blockchain performance while ensuring security.

[0108] First, define the following key terms:

[0109] B: The uncoded data block to be processed, i.e. the original block data, can be the full uncoded data of the first block, or a subset of the target data in the uncoded data of the first block.

[0110] The prover address is the unique identifier of the first node, and is a unique identity credential assigned to each prover node, such as its public key hash or the unique node address of the first node.

[0111] K: Key block, which refers to the encoding block of the previous block, i.e. the encoding block of the second block, and is used as the key in the current block encoding process. This chain dependency relationship enhances the immutability of historical data.

[0112] E: Intermediate feedback data, a set of internal variables used to transmit state during encoding and decoding.

[0113] Y: The final generated coded block, which is the coded block of the first block, is the output of the encoding process and the input of the decoding process.

[0114] : Represents data blocks respectively The Middle Data unit.

[0115] : B's Data unit Address of the witness The result of the XOR operation is used to bind the data to the identity of the prover.

[0116] This embodiment can be based on the Galois field defined by the prime number P. The calculations are performed. Its asymmetry is primarily achieved through the use of cube operations. Rather than This is achieved through modular inverse operations. Specifically, encoding the i-th first data unit using the i-th second data unit as the key in the encoded block of the second block includes:

[0117] Perform the first modular inverse cube root operation on the i-th first data unit;

[0118] The result of the first modular inverse cube root operation is mixed with the i-th second data unit in the coding block of the second block to obtain the mixed result;

[0119] Based on the mixed result, a second modular inverse cube root operation is performed to obtain the encoding result of the i-th first data unit.

[0120] In some embodiments, the step of mixing the encoding result of the i-th first data unit with the (i-1)-th intermediate result to obtain the i-th third data unit includes:

[0121] The encoding result of the i-th first data unit is mixed with the (i-1)-th intermediate result to obtain the i-th intermediate result;

[0122] The i-th intermediate result is XORed with the i-th second data unit in the encoding block of the second block to obtain the i-th third data unit.

[0123] It should be noted that mixing operations can include division operations between data to achieve the mixing of two data.

[0124] The coding process can be designed to execute serially to prevent parallelization attacks. For example... Figure 3 As shown, for each data unit in non-coded block B That is, the encoding process of data units in the non-coded data of the first block. The calculation is as follows:

[0125] 1. Identity binding: Calculation Because each full node has a unique... This ensures the uniqueness of pᵢ, thus making the subsequently generated encoded blocks also unique.

[0126] 2. Serialization and Increased Complexity: The core of the encoding is a feedback loop. Intermediate variables That is, the calculation of the encoding result of the i-th first data unit depends on the previous state. The encoding result of the (i-1)th first data unit.

[0127] First of all, Perform the first modular inverse cube root operation, and combine the result with the key unit. That is, the i-th second data unit in the coding block of the second block undergoes a mixing operation, and then a second modular inverse cube root operation is performed. The result, i.e., the coding result of the i-th first data unit, is then combined with the feedback value. Perform a mixing operation to obtain the current result. That is, the i-th intermediate result. This design forces the computation to be serialized, while the two costly modular inverse cube root operations significantly increase the time complexity of the encoding.

[0128] 3. Data Protection: To prevent attackers from generating valid encoded blocks without the key block K, a mechanism similar to the one used in the calculation process is introduced. Hybrid operations improve data security.

[0129] 4. Non-zeroing processing: Before performing operations such as division, the input is non-zeroed to avoid abnormal situations such as division by zero and to ensure the robustness of the algorithm.

[0130] 5. Final Output: Final Encoding Unit It is by passing intermediate results With key unit This is obtained by performing an XOR operation. The purpose of this step is to prevent attackers from deducing and forging the key block K by decoding Y. This is based on Fermat's Little Theorem. middle Modular inverse operation It is defined as shown in equation (1).

[0131] (1)

[0132] The computational cost of this operation is much higher than that of a regular exponentiation operation, thus significantly increasing the time complexity of the code.

[0133] The above details the encoding process, while the decoding process is used to verify the stored proof, and its decoding process corresponds to the encoding process.

[0134] In some embodiments, the decoding process is the reverse of the encoding process, and the decoding process is designed to be highly parallelizable and computationally inexpensive. For example... Figure 4 As shown, for each data unit in the coded block Y Its decoding process The calculation is as follows:

[0135] 1. Inverse mixing operation: via Recover intermediate data .

[0136] 2. Fast Decoding: The decoding process uses two computationally inexpensive cube operations. By combining addition and multiplication operations, one can obtain from , and Recovery .

[0137] 3. Identity Unbinding: Through The original data unit can then be reconstructed. .

[0138] Because the decoding process does not include a feedback loop (each The calculations can be performed independently, and the core operations... The computation speed is much faster than its modular inverse operation, so the decoding process is much faster than the encoding process, and it can be accelerated on a large scale by using multi-core processors or GPUs.

[0139] In step 102, the encoded block of the target block is used as private input, and the non-encoded data of the target block is used as public input to perform a non-interactive proof of the correct execution of the encoding process, thereby obtaining a storage proof of the encoded block of the target block. The non-interactive proof can be a non-interactive zero-knowledge proof (zk-STARKs) protocol.

[0140] In some embodiments, when the non-encoded data of the first block is encoded using the encoded block of the second block as a key, step 102 specifically includes:

[0141] Using the encoded blocks of the target block and the second block as private inputs, and the first data of the target block as public inputs, a non-interactive zero-knowledge proof protocol is used to perform a non-interactive proof of the correct execution of the encoding process, thereby obtaining a storage proof of the encoded blocks of the target block.

[0142] This embodiment employs the zk-STARKs protocol to generate a concise, non-interactive proof of computational integrity for the correct execution of the encoding process. The core of this process is to transform the encoding computation into an algebraic problem, and then efficiently verify the solution to this problem through polynomial commitments and low-degree tests. Figure 5 The input generated in the proof is defined as follows:

[0143] (1) As a private input, it is obtained through... Perform an XOR operation on the polynomial generated from the coded block Y. For each prover, They are all unique.

[0144] (2) The private input is a polynomial generated from the previously encoded block data K. This is also unique to each prover.

[0145] (3) As public input, it comes from B and The XOR operation outputs a polynomial. Due to B and It is public data, and any verifier can calculate it.

[0146] To generate proofs for zk-STARKs, a high-dimensional polynomial needs to be constructed. The Lagrange algorithm can construct the polynomial, but its computational time complexity is quadratic, i.e., ... Therefore, Discrete Time Fourier Transform (DTFT) / Inverse Discrete Time Fourier Transform (IDTFT) can be used, with a time complexity of O(n). The polynomial needs to be extended to... This is used for zk-STARKs proofs. Therefore, the Nth root of unity of two sets is used, where To calculate The high-dimensional polynomials in [the context]. The sets of the roots of unity are respectively [details]. and ,in . It is the low-degree expansion factor in polynomial interpolation.

[0147] Figure 5 A flowchart illustrating the proof generation process is provided. First, the proof is generated from the input data B, K, and Y... generate , and Polynomials. Then, compute from these polynomials... , and The intermediate polynomials. These polynomials are used to compute the Merkle roots, which are then used to randomly generate partial trees and... .

[0148] Definition from The input polynomial set obtained The polynomial is shown in equation (2) below.

[0149] (2)

[0150] From the perspective of encoding and decoding methods, for all , All values ​​are zero. Verify on all coordinates. This is inefficient, even less efficient than validating the original data. Therefore, a new polynomial is defined here. And it is verified using a probabilistic approach. As a multiple of the minimal polynomial, then the polynomial The definition is shown in equation (3).

[0151] (3)

[0152] Verification was performed not only at several randomly selected coordinates but also using Fast Reed-Solomon Interactive Oracle Proofs of Proximity (FRI). To improve verification performance, boundary constraints were further verified. The first and last coordinates are respectively and It is possible to calculate the unique first-degree polynomial passing through these two points. Then define As shown in equation (4) below.

[0153] (4)

[0154] polynomial The definition is shown in equation (5).

[0155] (5)

[0156] From the perspective of computational cost and proof size, directly verifying every polynomial across all coordinates is inefficient. Therefore, instead of directly verifying these polynomials, we can construct... , it is , and Linear combination polynomials. Polynomials are derived from the Merkle roots of these polynomials. Random coordinates are chosen as random seeds, and subtrees of these coordinate sets are included in the proof. Then, [the following is selected]... At random coordinates, the verification node will verify the polynomial at these coordinates. , , , and Finally, using FRI, a proof is made for the linear combination polynomial. Perform additional validation. Use a bivariate polynomial as a reduction measure. The dimension method is shown in equation (6) below.

[0157] (6)

[0158] If using Merkle root random fixation Then we can get A low-dimensional polynomial with dimension . One-quarter of it. Its dimensionality can also be reduced in the same way. Each dimension... They will all use the previous one The Merkle root is randomly selected at a KFRI location for verification. When the dimensionality is reduced to a sufficiently low level, a low-dimensional proof is generated. The FRI proof includes a subtree of randomly selected coordinates during the dimensionality reduction process, as well as a proof of the low-dimensionality.

[0159] In the case of generating a storage proof for the coded block of the first block based on the zk-STARKs protocol, in step 103, the storage proof for the coded block of the first block can be broadcast for verification by the second node.

[0160] See Figure 6 , Figure 6 This is a second flowchart of a blockchain data storage and processing method provided in this application embodiment, applied to a second node. The second node is used to store and verify a unique data copy of the blockchain data, such as... Figure 6 As shown, the method includes the following steps:

[0161] Step 601: Upon receiving the storage proof of the encoded block of the target block, decode the encoded block of the target block based on the unique identifier of the first node to obtain decoded data;

[0162] Step 602: Using the decoded data as private input and the non-encoded data of the target block as public input, execute a non-interactive proof algorithm to verify the storage proof of the encoded block of the target block and obtain the verification result.

[0163] The storage proof of the target block's coded block is obtained by using the target block's coded block as private input and the target block's non-coded data as public input, to perform a non-interactive proof of the correct execution of the encoding process. The target block's coded block is obtained by encoding the non-coded data of the target block based on the unique identifier of the first node when the first block is newly created in the blockchain. The target block's coded block is a unique data copy of the target block's non-coded data, and the target block includes the first block.

[0164] In step 601, the decoding process corresponds to the encoding process and has been described in detail in the above embodiments, so it will not be repeated here. The second node, the verifier, can be any node in the blockchain network; both full nodes and light nodes can serve as verifiers. After receiving the storage proof, the verifier can verify the validity of the storage proof using public input (i.e., the non-encoded data of the first block) without needing to access the verifier's private information.

[0165] In some embodiments, step 601 specifically includes:

[0166] Based on the n third data units in the coding block of the target block and the n second data units in the coding block of the second block, an inverse mixing operation is performed to obtain n intermediate results. The second block is the preceding block of the target block in the blockchain.

[0167] Based on n intermediate results and n second data units in the coding block of the second block, the n intermediate results are decoded in parallel to obtain the second data.

[0168] Based on the unique identifier of the first node, the second data is debound from the identity of the first node to obtain decoded data.

[0169] In some embodiments, when the second node is a light node of the blockchain, step 602 specifically includes:

[0170] If the comparison result indicates that the hash value of the target block matches the hash value in the block header of the target block stored by the second node, the decoded data is used as private input, and the non-encoded data of the target block is used as public input. A non-interactive proof algorithm is then executed to verify the storage proof of the encoded block of the target block, and a verification result is obtained.

[0171] The non-coded data of the target block is obtained by the second node from the full node of the blockchain.

[0172] In some embodiments, any validator in the blockchain network upon receiving a proof of storage Then, the verification process can be executed:

[0173] (1) Full node verifier: It directly uses its locally stored non-encoded data as public input to execute the zk-STARKs verification algorithm.

[0174] (2) Light Node Verifier: Since it only stores the block header, it can first obtain the non-encoded data (or its Merkle proof) required for verification from any full node. The light node can ensure the authenticity and integrity of the data by comparing the hash value of the obtained data with the cryptographic commitment (i.e., hash value) stored in the block header. Subsequently, it executes the same zk-STARKs verification algorithm as the full node.

[0175] Through this design, the nPPoS scheme achieves trustless public verification of the storage behavior of all nodes across the entire network, thereby effectively promoting the health and decentralization of the blockchain network.

[0176] In some embodiments, after step 602, the method further includes:

[0177] Obtain the relative time difference, which is the time difference between the creation or receipt of the first block recorded by the second node and the storage proof of the coded block received by the target block;

[0178] Based on the relative time difference and the verification result, the trust level of the first node is determined. The trust level is used to indicate the integrity of the first node in storing a unique data copy of the blockchain data. The trust level is used to control the communication between the nodes in the blockchain and the first node.

[0179] Theoretically, the time it takes for an honest node to generate a stored proof should be within a predictable range. However, in a decentralized asynchronous network environment, the total latency observed by the verifier is affected by various uncontrollable factors, such as network congestion, geographical differences, and the instantaneous computational load of the verifier node. Therefore, simply judging whether a verifier is "honest" or "malicious" based on a fixed time threshold is unreliable. To address this issue, this embodiment introduces a time-weighted trust model. This model does not rely on a globally synchronized clock but dynamically evaluates the verifier's response efficiency and reliability based on the relative time difference recorded by the verifier's local clock.

[0180] like Figure 7 The figure shows the relative time difference recorded by the verifier's local clock. It is the time difference between the creation time of the new block (the first block) and the time when the validator receives the block. It is the time difference between the time when the validator receives the newly created block and the time when the validator receives the stored proof. It is the time difference between the time a new block is created and the time the validator receives the storage proof.

[0181] The proof scheme is theoretically time-constrained. For example, the time to generate a valid storage proof must be less than the time it would take a malicious attacker to generate a proof after encoding a block. However, factors such as network latency or differences in computing power make it difficult for verifiers to determine the cause of the latency. Instead, a trust level for an honest proof can be introduced. This is a time-weighted scheme for identifying honest provers, defined as shown in equation (7).

[0182] (7)

[0183] If the proof is valid, then It is 1 if it is true, otherwise it is 0. and These are time delay weights and a scaling factor, respectively. That is, time delay, which can be measured in two ways, using... Figure 7 shown You can also use Figure 7 shown When the proof verification fails, The value is zero. Validators can manage a blacklist of nodes that provide false proofs, instead of deleting them when verification fails. Set to 0. Otherwise, when When smaller, This will be relatively large. Each node calculates for each prover upon receiving the stored proof. And accumulate them. Each node's The management plan can be customized according to the network environment. This includes how values ​​are accumulated and the management duration. If The low latency could indicate a malicious attacker or significant network latency. Therefore, it is recommended to... Higher-level nodes communicate to ensure reliability and assess network quality.

[0184] Through a scoring mechanism and application, each node (verifier) ​​can independently maintain a cumulative trust score table for all provers locally. Each time a prover is successfully verified, the verifier calculates the current trust score according to formula (7) above. This score is then added to the total score of the corresponding prover. Nodes can customize the accumulation strategy, such as using a moving average or setting the half-life of the score, to adapt to different network environments.

[0185] This reputation-based peer selection system, based on a scoring table, constitutes a dynamic reputation system. Nodes are incentivized to prioritize communicating with peers of higher scores (e.g., requesting data, broadcasting transactions, etc.). The benefits of this are twofold: first, it improves network quality by automatically filtering out nodes with fast responses and good network connectivity; second, it enhances security by naturally isolating nodes that may be malicious attackers (e.g., intentionally delaying responses) or poorly performing nodes through the scoring mechanism.

[0186] This reputation system also naturally creates a decentralized load balancing mechanism. If a large number of nodes concentrate on communicating with the few nodes with the highest scores, it will cause the load on these top-level nodes to increase, thus delaying their response. Increase, which in turn leads to its newly acquired The score decreases. This negative feedback effect automatically redistributes communication traffic to other nodes with the next highest scores, achieving a dynamic and adaptive balance of network load.

[0187] The following is a detailed explanation of the blockchain data storage and processing method provided in the embodiments of this application, using a specific example.

[0188] Figure 8 This is an architecture diagram of a specific example of a blockchain data storage and processing method provided in an embodiment of this application, such as... Figure 8 As shown, system components and roles can be defined as follows:

[0189] (1) Data object

[0190] Non-coded blocks, or non-coded data, refer to the raw block data generated by the consensus of the blockchain network, which is public information that can be obtained by all nodes.

[0191] Encoded block: refers to a unique copy of data generated by each full node using an encoding scheme, which combines a non-encoded block with its own unique identifier.

[0192] (2) Network Roles

[0193] Prover: This role is filled by a full node that stores the complete blockchain ledger. When a new block is generated, the full node decides whether to become the prover for the current block through a probabilistic selection mechanism (e.g., a deterministic calculation based on the new block's hash and its own address). The selected prover is responsible for generating and broadcasting its stored proof to the entire network.

[0194] Verifier: Any node in the network (including full nodes and light nodes) can serve as a verifier. After receiving a proof, the verifier verifies the validity of the proof using public input (i.e., non-coded blocks) without needing to access the prover's private information.

[0195] (3) Governance mechanism:

[0196] Trust Score: Each node maintains a list of full node trust scores locally. When a proof is successfully verified, the verifier updates the corresponding prover's trust score according to a time-weighted trust scheme. This scoring system encourages nodes to prioritize communicating with high-scoring nodes, thereby naturally isolating slow-responding or potentially malicious nodes at the network layer.

[0197] The prover process is as follows: After a new block is broadcast on the network, each full node independently determines whether it has been selected as a prover for that block. The selected prover performs the following operations:

[0198] (1) Use its private, previous block's encoded block as a key to encode the non-encoded data of the new block and generate a new encoded block.

[0199] (2) Use the new encoded block as the private input of the zk-STARKs proof system, and use the non-encoded data and its own address of the new block as the public input.

[0200] (3) Execute the zk-STARKs proof generation algorithm to produce a concise, non-interactive proof. .

[0201] (4) Store the proof Broadcast the necessary metadata to the entire network.

[0202] Any validator in the network receives the stored proof Then, the verification process is executed as follows:

[0203] (1) Full node verifier: directly uses its locally stored non-coded blocks as common input to execute the zk-STARKs verification algorithm.

[0204] (2) Light Node Verifier: Since it only stores the block header, it first obtains the non-coded block (or its Merkle proof) required for verification from any full node. The light node can ensure the authenticity and integrity of the data by comparing the hash value of the obtained data with the cryptographic commitment (hash value) stored in the block header. Subsequently, it executes the same zk-STARKs verification algorithm as the full node.

[0205] Through this design, the nPPoS scheme achieves trustless public verification of the storage behavior of all nodes across the entire network, thereby effectively promoting the health and decentralization of the blockchain network.

[0206] This application proposes a non-interactive utility proof-of-storage (nPPoS) scheme based on zero-knowledge scalable transparent knowledge proofs (zk-STARKs), aiming to provide blockchain full nodes with an efficient, secure, and trustless data storage verification mechanism. Its core technical features are: First, it employs an asymmetric encoding and decoding design, generating a unique data copy (encoded block) strongly bound to the identity of each full node's ledger data. This design introduces computationally intensive and serially dependent operations during the encoding phase, significantly increasing the cost of forging or outsourcing storage proofs; while the decoding phase employs parallelizable and efficient operations, ensuring that the verification process does not become a system performance bottleneck. Second, it constructs a non-interactive proof system based on the zk-STARKs protocol. The prover (full node) uses its unique encoded block as private input and the original block data of the network consensus as public input to generate a concise computational integrity proof that "I have correctly executed the encoding and stored a unique data copy." This storage proof eliminates the need for multiple rounds of interaction between the prover and verifier. Once generated, it can be publicly verified by any node on the network, fundamentally resolving the collusion risk inherent in traditional interactive proofs and significantly reducing the proof size and verification time. Finally, a full node health and trust governance model can be established, aiming to maintain the number of honest full nodes in the network through cryptographic proofs, thereby improving the decentralization, data availability, and attack resistance of the entire blockchain system.

[0207] The non-interactive storage proof scheme, nPPoS, provided in this application embodiment is designed to enhance the security and decentralization of blockchain full nodes. First, an asymmetric encoding / decoding strategy is designed: through a chain-like design that is "slow in encoding, fast in decoding," it effectively resists outsourcing and generation attacks without sacrificing verification performance. Then, the zk-STARKs protocol is adopted to achieve storage proofs that require no trusted setup, are resistant to quantum attacks, have small proof size, and are fast in verification, fundamentally eliminating the risk of collusion in interactive protocols. Through a two-stage data sampling technique based on a publicly available on-chain random source, the unpredictability and manipulation resistance of audits are ensured, making the scheme both efficient and secure when processing large-scale data. Finally, a time-weighted trust model is designed to achieve reliable evaluation of node performance, optimization of network quality, and adaptive load balancing in an asynchronous network that does not require a global clock.

[0208] The aforementioned key technologies collectively constitute a complete, efficient, secure, and decentralized blockchain full-node storage verification system. In summary, the nPPoS solution achieves the goal of efficient, scalable, and secure verification of full-node storage behavior in a decentralized, trustless blockchain environment.

[0209] Compared with the prior art, the embodiments of this application exhibit significant technical advantages.

[0210] First, by employing zk-STARKs to construct a completely non-interactive proof system, the risk of collusion inherent in traditional interactive protocols is fundamentally eliminated. Its lack of the need for trusted setup and resistance to quantum computing ensures the system's long-term security and universality. Second, the innovative asymmetric encoding and decoding design achieves a balance between slow encoding to prevent attacks and fast decoding to ensure performance. The two-stage chained random sampling mechanism, through a "commitment-disclosure" approach, effectively prevents premeditated attacks targeting data sampling, achieving a unity of security and performance. Finally, the introduced time-weighted trust model is a dynamic, relative-latency-based reputation assessment and governance mechanism. It not only effectively identifies and isolates nodes with abnormal behavior but also optimizes network communication efficiency through adaptive load balancing, significantly improving the robustness and decentralized governance of the entire blockchain network—a comprehensive advantage not possessed by traditional storage proof schemes.

[0211] This application provides a quantifiable and auditable high-security storage proof for various blockchain platforms, particularly suitable for highly compliant scenarios such as finance, evidence preservation, and the judiciary, significantly enhancing platform credibility. Through efficient non-interactive proofs and adaptive reputation governance mechanisms, it significantly reduces the operation, maintenance, and trust costs of decentralized networks. Furthermore, by empowering lightweight nodes to perform secure and independent verification, it greatly lowers the participation threshold for mobile and IoT devices, thereby fostering a broader decentralized application ecosystem. Additionally, the provided dynamic trust score can serve as a core component of next-generation consensus mechanisms, enabling fairer and more efficient incentives and governance, making it a key technology with core competitiveness and huge market potential in the blockchain infrastructure field. Therefore, this application has significant commercial value.

[0212] See Figure 9 , Figure 9 This is one of the structural schematic diagrams of a blockchain data storage and processing device provided in this application embodiment, applied to a first node. The first node is used to store proof of a unique data copy of the blockchain data, such as... Figure 9 As shown, the blockchain data storage and processing device 900 includes:

[0213] Encoding module 901 is used to encode the non-encoded data of the target block based on the unique identifier of the first node when a new first block is created in the blockchain, to obtain the encoded block of the target block. The encoded block of the target block is a unique data copy of the non-encoded data of the target block, and the target block includes the first block.

[0214] The proof module 902 is used to take the encoded block of the target block as private input and the non-encoded data of the target block as public input to perform non-interactive proof of the correct execution of the encoding process and obtain the storage proof of the encoded block of the target block.

[0215] The broadcast module 903 is used to broadcast the storage proof of the coded block of the target block. The storage proof is used by the second node to verify the storage of the unique data copy of the blockchain data based on the non-coded data of the target block.

[0216] Optionally, the encoding module 901 includes:

[0217] A binding unit is used to bind the non-coded data of the target block to the identity of the first node based on the unique identifier of the first node, so as to obtain the first data of the target block;

[0218] An encoding unit is used to encode the first data using the encoding block of the second block as a key to obtain the encoding block of the target block, wherein the second block is the preceding block of the target block in the blockchain.

[0219] Optionally, the first data includes n first data units, and the encoding unit is specifically used for:

[0220] The i-th second data unit in the encoding block of the second block is used as the key to encode the i-th first data unit, where n is a positive integer greater than 1 and i is a positive integer less than or equal to n.

[0221] The encoding result of the i-th first data unit is mixed with the (i-1)-th intermediate result to obtain the i-th third data unit. The encoding block of the target block includes n third data units. The (i-1)-th intermediate result is obtained by mixing the encoding result of the (i-1)-th first data unit with the (i-2)-th intermediate result.

[0222] Optionally, the encoding unit is specifically used for:

[0223] The encoding result of the i-th first data unit is mixed with the (i-1)-th intermediate result to obtain the i-th intermediate result;

[0224] The i-th intermediate result is XORed with the i-th second data unit in the encoding block of the second block to obtain the i-th third data unit.

[0225] Optionally, the encoding unit is specifically used for:

[0226] Perform the first modular inverse cube root operation on the i-th first data unit;

[0227] The result of the first modular inverse cube root operation is mixed with the i-th second data unit in the coding block of the second block to obtain the mixed result;

[0228] Based on the mixed result, a second modular inverse cube root operation is performed to obtain the encoding result of the i-th first data unit.

[0229] Optionally, the proof module is specifically used for:

[0230] Using the encoded blocks of the target block and the second block as private inputs, and the first data of the target block as public inputs, a non-interactive zero-knowledge proof protocol is used to perform a non-interactive proof of the correct execution of the encoding process, thereby obtaining a storage proof of the encoded blocks of the target block.

[0231] Optionally, the encoding module is specifically used for:

[0232] If the hash result is greater than or equal to a preset probability threshold, the non-encoded data of the target block is encoded based on the unique identifier of the first node to obtain the encoded block of the target block; wherein,

[0233] The hash result is obtained by concatenating the hash value of the first block with the unique identifier of the first node, and then performing a hash operation on the concatenated value.

[0234] Optionally, the device further includes:

[0235] A block selection module is used to select a third block from the blockchain based on the hash value of the first block, wherein the third block is a historically generated block of the blockchain relative to the first block, and the target block also includes the third block.

[0236] Optionally, the device further includes:

[0237] The data partitioning module is used to partition the non-coded data of the target block into M data subsets;

[0238] Anchor point selection module, used to select a data point from each data subset as the anchor point position;

[0239] A construction module is used to construct a Merkle tree based on data points at each anchor point location and to calculate the root hash of the Merkle tree;

[0240] The first determining module is used to determine the starting sampling position of the non-coded data of the target block based on the root hash of the Merkle tree;

[0241] The reading module is used to read data of a preset size from the non-encoded data of the target block, starting from the initial sampling position, to obtain a target data subset, wherein the data size of the data subset is the preset value;

[0242] The encoding module is specifically used for:

[0243] Based on the unique identifier of the first node, the target data subset in the non-coded data of the target block is encoded to obtain the coded block of the target block.

[0244] The blockchain data storage and processing device 900 can implement all the processes implemented in the above-mentioned first node-side blockchain data storage and processing method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0245] See Figure 10 , Figure 10This is a second schematic diagram of a blockchain data storage and processing device provided in this application embodiment. It is applied to a second node, which is used to store and verify a unique copy of the blockchain data. Figure 10 As shown, the blockchain data storage and processing device 1000 includes:

[0246] The decoding module 1001 is used to decode the encoded block of the target block based on the unique identifier of the first node when a storage proof of the encoded block of the target block is received, so as to obtain decoded data.

[0247] The verification module 1002 is used to take the decoded data as private input, take the non-encoded data of the target block as public input, execute a non-interactive proof algorithm, verify the storage proof of the encoded block of the target block, and obtain the verification result.

[0248] The storage proof of the target block's coded block is obtained by using the target block's coded block as private input and the target block's non-coded data as public input, to perform a non-interactive proof of the correct execution of the encoding process. The target block's coded block is obtained by encoding the non-coded data of the target block based on the unique identifier of the first node when the first block is newly created in the blockchain. The target block's coded block is a unique data copy of the target block's non-coded data, and the target block includes the first block.

[0249] Optionally, when the second node is a light node in the blockchain, the verification module is specifically used for:

[0250] If the comparison result indicates that the hash value of the target block matches the hash value in the block header of the target block stored by the second node, the decoded data is used as private input, and the non-encoded data of the target block is used as public input. A non-interactive proof algorithm is then executed to verify the storage proof of the encoded block of the target block, and a verification result is obtained.

[0251] The non-coded data of the target block is obtained by the second node from the full node of the blockchain.

[0252] Optionally, the device further includes:

[0253] The acquisition module is used to acquire a relative time difference, which is the time difference between the creation or receipt of the first block recorded by the second node and the storage proof of the coded block received from the target block;

[0254] The second determining module is used to determine the trust level of the first node based on the relative time difference and the verification result. The trust level is used to indicate the integrity of the first node in storing a unique data copy of the blockchain data. The trust level is used to control the communication between the nodes in the blockchain and the first node.

[0255] Optionally, the decoding module is specifically used for:

[0256] Based on the n third data units in the coding block of the target block and the n second data units in the coding block of the second block, an inverse mixing operation is performed to obtain n intermediate results. The second block is the preceding block of the target block in the blockchain.

[0257] Based on n intermediate results and n second data units in the coding block of the second block, the n intermediate results are decoded in parallel to obtain the second data.

[0258] Based on the unique identifier of the first node, the second data is debound from the identity of the first node to obtain decoded data.

[0259] The blockchain data storage and processing device 1000 can implement all the processes implemented in the above-described second-node side blockchain data storage and processing method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0260] See Figure 11 The figure shows a schematic diagram of the node structure provided in an embodiment of the present invention. Figure 11 As shown, node 1100 includes: processor 1101, memory 1102, user interface 1103 and bus interface 1104.

[0261] The processor 1101 is used to read the program in the memory 1102 and execute the various steps of the first node-side blockchain data storage processing method or the various steps of the second node-side blockchain data storage processing method.

[0262] exist Figure 11 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 1101 and memory represented by memory 1102 together. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 1104 provides an interface. For different user devices, user interface 1103 can also be an interface capable of connecting external or internal devices, including but not limited to keypads, displays, speakers, microphones, joysticks, etc.

[0263] The processor 1101 is responsible for managing the bus architecture and general processing, while the memory 1102 can store the data used by the processor 1101 when performing operations.

[0264] Preferably, this embodiment of the invention also provides a node 1100, including a processor 1101, a memory 1102, and a computer program stored in the memory 1102 and executable on the processor 1101. When the computer program is executed by the processor 1101, it implements the various processes of the first node-side blockchain data storage processing method embodiment described above, or implements the various processes of the second node-side blockchain data storage processing method embodiment described above, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0265] This invention also provides a readable storage medium storing a computer program. When executed by a processor, this computer program implements the various processes of the first node-side blockchain data storage processing method embodiment or the various processes of the second node-side blockchain data storage processing method embodiment, achieving the same technical effect. To avoid repetition, further details are omitted here. The readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0266] This application also provides a computer program product, including computer instructions. When executed by a processor, the computer instructions implement the various processes of the above-described first node-side blockchain data storage processing method embodiment, or implement the various processes of the above-described second node-side blockchain data storage processing method embodiment, and can achieve the same technical effect. To avoid repetition, further details are omitted here.

[0267] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0268] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0269] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0270] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention, depending on actual needs.

[0271] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0272] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0273] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for processing blockchain data storage, characterized in that, The method is applied to a first node configured to store a unique data copy of blockchain data, and the method comprises: In a case where a first block is newly created in a blockchain, encoding non- encoded data of a target block based on a unique identifier of the first node to obtain an encoded block of the target block, the encoded block of the target block being a unique data copy of the non-encoded data of the target block, the target block comprising the first block; Taking the encoded block of the target block as a private input and taking the non-encoded data of the target block as a public input, performing non-interactive proof for correctness of the encoding process to obtain storage proof of the encoded block of the target block; Broadcasting the storage proof of the encoded block of the target block, the storage proof being used by a second node to verify based on the non-encoded data of the target block, the second node being configured to store a unique data copy of blockchain data.

2. The method of claim 1, wherein, The encoding of the non-encoded data of the target block based on the unique identifier of the first node to obtain the encoded block of the target block comprises: Binding the non-encoded data of the target block to the identity of the first node based on the unique identifier of the first node to obtain first data of the target block; Encoding the first data by taking the encoded block of a second block as a key to obtain the encoded block of the target block, the second block being a predecessor block of the target block in the blockchain.

3. The method of claim 2, wherein, The first data comprises n first data units, and the encoding of the first data by taking the encoded block of the second block as a key to obtain the encoded block of the target block comprises: Taking an i-th second data unit in the encoded block of the second block as a key to encode an i-th first data unit, n being a positive integer greater than 1 and i being a positive integer less than or equal to n; Performing a mixing operation on an encoding result of the i-th first data unit and an i-1-th intermediate result to obtain an i-th third data unit, the encoded block of the target block comprising n third data units, the i-1-th intermediate result being obtained by performing a mixing operation on an encoding result of an i-2-th first data unit and an i-3-th intermediate result.

4. The method of claim 3, wherein, The mixing operation on the encoding result of the i-th first data unit and the i-1-th intermediate result to obtain the i-th third data unit comprises: Performing a mixing operation on the encoding result of the i-th first data unit and the i-1-th intermediate result to obtain an i-th intermediate result; Performing an exclusive-OR operation on the i-th intermediate result and the i-th second data unit in the encoded block of the second block to obtain the i-th third data unit.

5. The method of claim 3, wherein, The taking of the i-th second data unit in the encoded block of the second block as a key to encode the i-th first data unit comprises: Performing a first inverse cubic root operation on the i-th first data unit; Performing a mixing operation on a result of the first inverse cubic root operation and the i-th second data unit in the encoded block of the second block to obtain a mixing result; and Performing a second inverse cubic root operation on the mixing result. Performing a second modular inverse cubic root operation based on the mixing result to obtain an encoding result of the i-th first data unit.

6. The method of claim 2, wherein, The encoding block of the target block is taken as a private input, and the non-encoding data of the target block is taken as a public input to perform non-interactive proof for the correct execution of the encoding process, and a storage proof of the encoding block of the target block is obtained, including: The encoding block of the target block and the encoding block of the second block are taken as private inputs, and the first data of the target block is taken as a public input to perform non-interactive proof for the correct execution of the encoding process by using a non-interactive zero-knowledge proof protocol, and a storage proof of the encoding block of the target block is obtained.

7. The method of claim 1, wherein, The non-encoding data of the target block is encoded based on the unique identifier of the first node to obtain the encoding block of the target block, including: In the case that the hash result is greater than or equal to the preset probability threshold, the non-encoding data of the target block is encoded based on the unique identifier of the first node to obtain the encoding block of the target block; wherein, The hash result is obtained by concatenating the hash value of the first block with the unique identifier of the first node and performing hash operation on the concatenated value.

8. The method of claim 1, wherein, The method further includes: Based on the hash value of the first block, a third block is selected from the blockchain, the third block being a block generated in the history of the blockchain relative to the first block, and the target block further including the third block.

9. The method of claim 1, wherein, Before the non-encoding data of the target block is encoded based on the unique identifier of the first node to obtain the encoding block of the target block, the method further includes: The non-encoding data of the target block is divided into M data subsets; A data point in each data subset is selected as an anchor point position; Based on the data points of each anchor point position, a Merkle tree is constructed, and a root hash of the Merkle tree is calculated; Based on the root hash of the Merkle tree, a starting sampling position of the non-encoding data of the target block is determined; Starting from the starting sampling position, data with a preset value in the non-encoding data of the target block is read to obtain a target data subset, and the data size of the data subset is the preset value; The non-encoding data of the target block is encoded based on the unique identifier of the first node to obtain the encoding block of the target block, including: The target data subset in the non-encoding data of the target block is encoded based on the unique identifier of the first node to obtain the encoding block of the target block. 10.A method for processing blockchain data storage, characterized in that, The second node is applied to store and verify a unique data copy of blockchain data, and the method includes: In the case that the storage proof of the encoding block of the target block is received, the encoding block of the target block is decoded based on the unique identifier of the first node to obtain decoded data, and the first node is used to store and prove a unique data copy of blockchain data. In the case that the storage proof of the encoding block of the target block is received, the encoding block of the target block is decoded based on the unique identifier of the first node to obtain decoded data, and the first node is used to store and prove a unique data copy of blockchain data. The decoding data is taken as private input, and the non-encoding data of the target block is taken as public input to execute a non-interactive proof algorithm to verify the storage proof of the encoding block of the target block, and a verification result is obtained. The storage proof of the encoding block of the target block is obtained by taking the encoding block of the target block as private input and the non-encoding data of the target block as public input to perform non-interactive proof for the correct execution of the encoding process. The encoding block of the target block is obtained by encoding the non-encoding data of the target block based on the unique identifier of the first node in the case of creating a first block in the blockchain. The encoding block of the target block is the unique data copy of the non-encoding data of the target block. The target block includes the first block.

11. The method of claim 10, wherein, In the case that the second node is a light node of the blockchain, the method of taking the decoding data as private input and the non-encoding data of the target block as public input to execute a non-interactive proof algorithm to verify the storage proof of the encoding block of the target block and obtain a verification result includes: In the case that the comparison result indicates that the hash value of the target block is consistent with the hash value in the block header of the target block stored by the second node, the decoding data is taken as private input, and the non-encoding data of the target block is taken as public input to execute a non-interactive proof algorithm to verify the storage proof of the encoding block of the target block, and a verification result is obtained. Wherein, The non-encoding data of the target block is obtained by the second node from a full node of the blockchain.

12. The method of claim 10, wherein, After the method of taking the decoding data as private input and the non-encoding data of the target block as public input to execute a non-interactive proof algorithm to verify the storage proof of the encoding block of the target block and obtain a verification result, the method further includes: Obtain the relative time difference between the time difference recorded by the second node between creating or receiving the first block and receiving the storage proof of the encoding block of the target block; Based on the relative time difference and the verification result, determine the trust degree of the first node, which is used to indicate the honesty of the first node in storing the unique data copy of the blockchain data, and the trust degree is used to control the communication between the nodes in the blockchain and the first node.

13. The method of claim 10, wherein, The decoding data is obtained by decoding the encoding block of the target block based on the unique identifier of the first node, including: Based on the n third data units in the encoding block of the target block and the n second data units in the encoding block of the second block, an inverse mixing operation is performed to obtain n intermediate results, and the second block is a previous block of the target block in the blockchain; Based on the n intermediate results and the n second data units in the encoding block of the second block, the n intermediate results are decoded in parallel to obtain second data; Based on the unique identifier of the first node, the second data is unbound with the identity of the first node to obtain decoding data. 14.A blockchain data storage processing apparatus characterized by comprising: The application is applied to a first node for storing a unique data copy of blockchain data, and the device comprises: An encoding module is configured to, in a case where a first block is newly created in a blockchain, encode non-encoded data of a target block based on a unique identifier of the first node to obtain an encoded block of the target block, the encoded block of the target block being a unique data copy of the non-encoded data of the target block, and the target block comprising the first block; A proof module is configured to, as a private input, take the encoded block of the target block, as a public input, take the non-encoded data of the target block, and non-interactively prove correctness of an encoding process to obtain a storage proof of the encoded block of the target block; A broadcasting module is configured to broadcast the storage proof of the encoded block of the target block, the storage proof being used by a second node to verify the non-encoded data of the target block, and the second node being configured to store a unique data copy of blockchain data. 15.A blockchain data storage processing apparatus, characterized by, The application is applied to a second node for storing a unique data copy of blockchain data, and the device comprises: A decoding module is configured to, in a case where a storage proof of an encoded block of a target block is received, decode the encoded block of the target block based on a unique identifier of a first node to obtain decoded data, the first node being configured to store a unique data copy of blockchain data; A verification module is configured to, as a private input, take the decoded data, as a public input, take non-encoded data of the target block, and execute a non-interactively proving algorithm to verify the storage proof of the encoded block of the target block to obtain a verification result; The storage proof of the encoded block of the target block is obtained by, as a private input, taking the encoded block of the target block, as a public input, taking the non-encoded data of the target block, and non-interactively proving correctness of an encoding process, the encoded block of the target block being obtained by, in a case where a first block is newly created in a blockchain, encoding non-encoded data of a target block based on a unique identifier of the first node, the encoded block of the target block being a unique data copy of the non-encoded data of the target block, and the target block comprising the first block.

16. A node, characterized by The application comprises: A processor, a memory, and a program stored on the memory and executable on the processor, the program being executed by the processor to implement steps of the blockchain data storage processing method according to any one of claims 1 to 13.

17. A computer-readable storage medium, characterized in that, A computer program is stored on the computer readable storage medium, and the computer program is executed by the processor to implement steps of the blockchain data storage processing method according to any one of claims 1 to 13.

18. A computer program product, characterised in that, Computer instructions are included, and the computer instructions are executed by the processor to implement steps of the blockchain data storage processing method according to any one of claims 1 to 13.

Images