An index-free sharding storage method for alliance chain transaction data

Abstract

The application discloses a kind of indexless quick slice transaction coding storage methods for alliance chain transaction data.The application realizes the indexless quick reading of transaction and the storage slice of transaction data by decoupling the verification function and data index function of transaction tree, improves the reading efficiency of transaction.For transaction verification function, the application proposes a verifiable data structure suitable for transaction data storage slice-indexless transaction tree, reduces the size of verification information, reduces the number of node interactions required for transaction data reading in data slice scenario.For transaction index function, the application proposes a new transaction data content coding method, realizes the indexless reading of transaction, improves the access efficiency of transaction, reduces the storage overhead of index.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of blockchains and relates to a transaction data index-free sharding storage method, in particular to an index-free fast read-write sharding storage method for alliance chain transaction data. BACKGROUND

[0002] A blockchain is a distributed digital ledger with characteristics such as decentralization, traceability and non-tamperability. In order to ensure the traceability and non-tamperability, each node in the blockchain needs to record all transaction data and its transaction verification MPT tree. In the alliance chain environment, the system has a larger throughput, and a larger amount of transactions are generated per second. The large amount of transactions and the full replication storage of transaction data result in a very large total amount of transaction data, which also limits the storage scalability of the entire system.

[0003] Sharding storage of transaction data is an effective way to solve the problem of high transaction data storage overhead. At the same time, the blockchain system usually queries transactions through transaction hashes. Currently, the method of querying transactions through transaction hashes mainly includes the following two methods: (1) querying transactions in a block in descending order of block number, and setting a Bloom filter for each block to speed up the search; (2) setting an additional mapping table of <transaction hash, block number> to quickly locate the block number where the transaction hash corresponds to the transaction. The above two solutions have defects. Using the first method, the read delay is high when searching for transactions in blocks with smaller numbers, because the node needs to traverse all blocks in descending order of block number until the block storing the transaction is found, and if there is a false positive in the Bloom filter, the read delay will be higher. Using the second method, the mapping of each transaction hash to the block number where it is stored needs to be stored, and the index storage overhead increases linearly with the number of transactions. After obtaining the block number corresponding to the transaction, the actual reading of transaction data requires reading the nodes of the transaction MPT tree to generate the verification information of the transaction data, which will also bring additional disk reading overhead. SUMMARY

[0004] In order to solve the problems existing in the prior art, the application provides an index-free fast read-write sharding storage method for alliance chain transaction data, which can relieve the storage pressure of nodes in the alliance chain and improve the efficiency of reading transaction data. By decoupling the verification function of the transaction tree and the data index function, the index-free fast reading of transactions and the storage sharding of transaction data are realized, and the reading efficiency of transactions is improved. Among them, a verifiable data structure suitable for transaction data storage sharding is provided, which reduces the storage overhead of transaction data and transaction index and the size of verification information.

[0005] The present application aims to reduce the storage overhead of alliance chain transaction data and transaction index and improve the transaction query speed, and proposes a transaction data indexless fast read-write sharding storage method for alliance chain aiming at the defects of the prior art. The verified data structure suitable for transaction data storage sharding, the indexless transaction tree (ITT), is proposed. The ITT is a vector commitment (VC) and hash hybrid verifiable transaction tree, which includes the following four kinds of nodes.

[0006] VC node: the VC node is logically a VC array of a specific size. When the VC node is the root node of the ITT, the VC array size is consistent with the number of nodes storing the encoded data block. When the VC node is an intermediate node of the ITT, the VC array size is specified by the construction parameter of the ITT. In the entire ITT data structure, there is at least one VC node, that is, the root node of the ITT. Each position of the VC node array can be mapped to a data node or an empty node or a Merkle node. VC is a cryptographic primitive similar to an accumulator, which provides similar functions to an accumulator. In addition to being able to prove that an element is in a set, VC provides a position binding function, that is, it can prove that an element exists in an ordered set and exists in a certain position in the ordered set. The operations of VC, such as generating commitment, generating position proof, updating proof, etc., can be completed in polynomial time complexity.

[0007] Merkle node: a node in a child Merkle tree, which can contain m data, and the size of m can be dynamically adjusted according to the actual allocation of the transaction size of the disk. Each data of the Merkle node can be mapped to a VC node or a Merkle node or a data node or an empty node.

[0008] Data node: saves the transaction hash and the data content corresponding to the transaction, wherein the data content is encoded as h|d, h is the height of the block where the transaction is located, and d is the actual data of the transaction.

[0009] Empty node: a node without storing any data, which is defaulted to point to an empty node when there is no corresponding mapping data in a position of the VC array or the Merkle node.

[0010] The structure of the ITT in the present application is shown in the following figure: Figure 1 The root node of the ITT is a VC node, and the size of the VC root node array depends on the number of nodes participating in the transaction data sharding in the current block. Each position of the VC root node array is mapped to a child Merkle tree, as shown in the following figure: Figure 1The Merkel node 1 and its child nodes (for example, the Merkel node 4 and the Merkel node 5) form a sub-Merkel tree. The commitment C constructed by the VC root node array is written into the transaction root of the block header as the verification commitment of all transactions in the current block. Each sub-Merkel tree mapped by the VC root node array contains a set of transaction data stored in the same node after sharding. The sub-Merkel tree contains four kinds of nodes, Merkel nodes, VC nodes, data nodes and empty nodes, wherein the VC nodes and the Merkel nodes are logically used to verify the correctness of the data nodes, and the Merkel nodes can be replaced by the VC nodes according to the actual transaction size in the block. When the size of the transactions in a block is too large, the number of transactions allocated to each sub-Merkel tree will also increase, and if all Merkel nodes are used as nodes of the sub-Merkel tree, the height of the sub-Merkel tree will be too high, and the transaction verification information will be too large. At this time, multiple Merkel nodes can be combined into a VC node to reduce the size of the transaction verification information.

[0011] The present application provides an index-free sharding storage method for alliance chain transaction data, which can be divided into a transaction encoding storage method and a transaction reading and verification method. The transaction encoding storage method specifically includes the following steps:

[0012] In order to ensure the availability of the data after sharding storage, each Merkel sub-tree in the ITT needs to be encoded and stored by an erasure code. The current mainstream encoding structures of the erasure code include Reed-Solomon (RS) encoding, local recoverable coding (LRC) and regenerating code (RC). The present application uses Reed-Solomon encoding to encode and store the transaction data in the Merkel sub-tree. The encoding mode used is RS(n, k), wherein k is the number of data blocks, which is also the number of Merkel sub-trees in the ITT, and n is the number of encoded blocks, wherein (n-k) is the number of redundant blocks generated by encoding. Any (n-k) blocks lost in the encoded blocks can be recovered by the surviving k blocks. The k data blocks composed of the transaction data of the k Merkel sub-trees are used as the input of RS encoding, and the (n-k) redundant blocks are generated by linear calculation of the Galois finite field. After encoding, the n encoded blocks are stored on n nodes, so that the availability of the data will not be affected when no more than (n-k) nodes in the system fail.

[0013] Step 1: Set the size of the VC root node RootNode to k, and k nodes in the n nodes participating in the consensus of the current block will store the encoded data blocks, and the remaining n-k nodes will store the check blocks generated by encoding;

[0014] Step 2: After the block consensus, the transactions are divided into different transaction sets s according to certain division rules (the division rules can be selected and set according to actual conditions, such as the first four bits of the transaction hash) i (i = 1, …, k) ;

[0015] Step 3: For each transaction set divided, a sub-Merkle tree set T is constructed in parallel i (i = 1, …, k)

[0016] Step 4: The root hash of the sub-Merkle tree is combined into RootNode;

[0017] Step 5: Calculate the VC proof of the whole transaction tree with RootNode as the root, and take it as the transaction root in the block header;

[0018] Step 6: Perform erasure code encoding on the sub-Merkle tree set T i to generate the encoding block C i (i = 1, …, n), calculate the blocks that need to be stored by the nodes, and actually store them.

[0019] The process of constructing the sub-Merkle tree in step 3 further includes the following steps:

[0020] Step 3-1: According to the amount of data that each Merkle node can accommodate, the sub-transaction set, calculate the height of the sub-Merkle tree composed entirely of Merkle nodes;

[0021] Step 3-2: Calculate the size of the conversion threshold H according to the size of the VC commitment and proof;

[0022] Step 3-3: If the height of the sub-Merkle tree is less than the conversion threshold, use the Merkle node as the parent node of the ITT leaf node, otherwise use the VC node as the parent node of the ITT leaf node;

[0023] Step 3-4: According to the intermediate nodes obtained in the above steps, create Merkle nodes from bottom to top according to the amount of data that the Merkle node can accommodate, and build the sub-Merkle tree.

[0024] The calculation method of the conversion threshold H in step 3-2 is as follows:

[0025] For a Merkle node with a capacity of m and a VC node with a commitment size of z p , a proof size of z c , the hash function used is SHA256, and the tree height threshold of the VC node converted from the Merkle tree is where the hash size generated by the SHA256 hash function is 32 bytes, 32(m-1) is the size of the verification information brought by a layer of Merkle node, and z p +zc The size of the verification information brought by a VC node. When the intermediate nodes of the sub-Merkle tree are completely m-ary Merkle nodes, the size of the verification information brought by a k-layer Merkle node is 32k(m-1), wherein 32 is the hash size generated by the SHA256 hash function, and 32k(m-1)=z p +z c That is, the number of layers The size of the verification information generated by a VC node is equal to the size of the verification information generated by a k-layer Merkle node. In order to reduce the size of the verification information, when The Merkle node is used as the parent node of the ITT leaf node, otherwise the VC node is used as the parent node of the ITT leaf node, and thus the tree height conversion threshold is

[0026] The transaction reading and verification method of the application specifically comprises the following steps:

[0027] Step a: any node receives a request for a transaction, obtains the blockchain node address storing the transaction according to the hash of the transaction, and requests the corresponding node for the transaction;

[0028] Step b: the node storing the transaction reads the corresponding stored data content from the database by taking the transaction hash as the key;

[0029] Step c: according to the block number where the transaction is located, read the hashes of all transactions under the corresponding sub-Merkle tree of the block;

[0030] Step d: iteratively calculate from bottom to top to obtain the proof path of the target transaction, and send the complete transaction verification information to the requester;

[0031] Step e: after the requester obtains the transaction data and the verification information thereof, the transaction data and the verification information thereof are iteratively calculated from bottom to top according to the proof path of the transaction, and the transaction root in the local stored block header is used to perform VC verification on the calculated sub-Merkle tree root, if successful, the transaction content is returned, otherwise, an empty value is returned.

[0032] Because the hierarchical structure of <RootNode node-sub-Merkle tree> is designed, when the transaction data is stored and fragmented, the transactions belonging to a sub-Merkle tree are divided into a blockchain node, so that the blockchain node can locally generate the verification information required for transaction verification in the sub-Merkle tree, compared with the random transaction division method in which the transactions divided in the same node may not be in the same Merkle sub-tree, the number of network communications can be reduced, thereby reducing the time for constructing transaction information and reducing the delay of transaction reading.

[0033] The beneficial effects of the present application include: the present application reduces the size of the verification information by establishing an index-free transaction tree, the size of the MPT index returned by one query is 1.5-1.8 times the size of the ITT index, reduces the number of node interactions required for transaction data reading in the data sharding scenario, realizes index-free reading of transactions by encoding the transaction data content, improves the access efficiency of transactions, reduces the storage overhead of indexes, and ITT reduces the storage overhead by 10%-20% compared with MPT. BRIEF DESCRIPTION OF DRAWINGS

[0034] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0035] Figure 1 The structure diagram of the index-free transaction tree of the present application.

[0036] Figure 2 The transaction set in the block of embodiment 1 of the present application.

[0037] Figure 3 The process diagram of transaction encoding storage of embodiment 1 of the present application

[0038] Figure 4 The reading and verification process diagram of the transaction of embodiment 2 of the present application

[0039] Figure 5 The detailed process diagram of transaction verification of embodiment 2 of the present application Specific implementation method

[0040] The present application will be further described in combination with the following specific embodiments and drawings. The process, conditions, experimental methods, etc. for implementing the present application are the general knowledge and common sense in the art, and the present application does not have special limitations.

[0041] The application discloses a transaction data index-free fast read-write sharding storage method for a consortium chain. The application realizes index-free fast reading of transactions and storage sharding of transaction data by decoupling the verification function and the data index function of a transaction tree, and improves the reading efficiency of transactions. For the transaction verification function, the application proposes a verifiable data structure, the index-free transaction tree, which is suitable for transaction data storage sharding, reduces the size of verification information, and reduces the number of node interactions required for transaction data reading in the data sharding scenario. For the transaction index function, the application proposes a new transaction data content encoding method, realizes index-free reading of transactions, improves the access efficiency of transactions, and reduces the storage cost of indexes.

[0042] The transaction encoding storage method in the transaction data index-free fast read-write sharding storage method for the consortium chain is shown in the following algorithm 1.

[0043]

[0044] The method comprises the following specific steps.

[0045] Step 1: set the size of the VC root node RootNode to k, and k nodes in |N| nodes participating in the current block consensus will store the encoded data block, and the remaining |N|-k nodes will store the check block generated by encoding (algorithm 1, line 1);

[0046] Step 2: divide the transaction set T after a block consensus into different sub-transaction sets s i (i=1,…,k) according to certain division rules (such as the first four bits of the transaction hash) (algorithm 1, line 2);

[0047] Step 3: for each transaction set s i , a sub-Merkle tree set subMT i (i=1,…,k) is constructed in parallel (algorithm 1, lines 4-6);

[0048] Step 4: combine the root hashes of the sub-Merkle trees into RootNode (algorithm 1, line 7);

[0049] Step 5: calculate the VC proof of the whole transaction tree with RootNode as the root (algorithm 1, line 8);

[0050] Step 6: encode the sub-Merkle tree set subMT i to generate the encoding block c i (i=1,…,n), calculate the block to be stored by the node, and actually store (algorithm 1, lines 10-13);

[0051] Step 7: Return the VC proof of the transaction tree as the transaction root in the block header (Algorithm 1, line 14).

[0052] In step 3, the method for constructing the sub-Merkel tree is as shown in Algorithm 2 below:

[0053]

[0054] The specific steps include the following:

[0055] Step 3-1: Based on the amount of data m that each Merkel node can hold and the sub-transaction set s, calculate the height of the sub-Merkel tree composed entirely of Merkel nodes. (Line 1 of Algorithm 2);

[0056] Step 3-2: Based on the commitment size z p Prove the size of z c Calculate the conversion threshold The size (line 2 of Algorithm 2);

[0057] Step 3-3: If h t If H ≥ 1, then the sub-transaction set s is divided into n sets T. n Where n is the amount of data that a VC node can hold, and n is the number of transactions per set. For each transaction in the sub-Merkel tree, a new VC node is constructed and placed into the MerkleNodeSet set, serving as the bottom-level node excluding data nodes (lines 6-10 of Algorithm 2). Otherwise, the sub-transaction set s is divided into m sets T. m For each transaction set The transaction in the algorithm constructs a Merkle node and puts it into the merkleNodeSet set, which serves as the bottom-level node of the sub-Merkle tree excluding the data node (lines 13-17 of Algorithm 2);

[0058] Steps 3-4: Using the nodes in the merkleNodeSet as the bottom-level nodes, construct an upper-level Merkle node for every m nodes in the merkleNodeSet and put it into a newmerkleNodeSet. Continue until the merkleNodeSet at that level is empty. Then, use the newmerkleNodeSet as the new merkleNodeSet and continue to construct upper-level nodes for it until there is only one node left in the merkleNodeSet (lines 20-28 of Algorithm 2).

[0059] Steps 3-5: The last remaining node in the merkleNodeSet is the root of the sub-Merkel tree (line 29 of Algorithm 2).

[0060] The transaction reading and verification method in the alliance chain-oriented transaction data index-free fast read-write sharding storage method comprises interactions of multiple nodes, and the following code omits the interaction between nodes and only considers the calculation process, as shown in the following algorithm 3.

[0061]

[0062] The method comprises the following specific steps:

[0063] Step 1: The node receives a request hash of a transaction, obtains a blockchain node address addr storing the transaction according to the hash of the transaction (algorithm 3, line 1), and requests the transaction from the corresponding node;

[0064] Step 2: The node storing the transaction reads the corresponding stored data content h|c from the database with the transaction hash as the key, wherein c is the transaction content and h is the block number where the transaction is located (algorithm 3, line 2);

[0065] Step 3: According to the read transaction block number h, read the hash set of all transactions under the corresponding sub-Merkle tree (algorithm 3, line 3);

[0066] Step 4: Iteratively calculate from bottom to top to obtain the proof path proofPath of the target transaction (algorithm 3, lines 5-10), and construct complete transaction verification information and send it to the requester;

[0067] Step 5: After the requester obtains the transaction data and its verification information, according to the proof path of the transaction, iteratively calculate from bottom to top, and use the locally stored transaction root txRoot in the block header to perform VC verification on the calculated sub-Merkle tree root r, if successful, return the transaction content c, otherwise return a null value NULL (algorithm 3, lines 12-17).

[0068] Embodiment 1

[0069] This embodiment is a method for encoding and storing transactions.

[0070] Given the current block height h = 64, the transaction set T = {t1, t2, …, t6}, the node list N = {n1, n2, n3, n4} participating in the current block consensus, the number of encoded data blocks k = 2, the data amount m = 2 that each Merkle node can accommodate, and the size z = 64 of the VC node proof and commitment.

[0071] As shown in the following figure, Figure 2 is the transaction set T.

[0072] As shown in the following figure, Figure 3As shown. ① Create a VC node RootNode of size k; ② Divide the transaction list into k=2 parts according to a certain partitioning rule; ③ For the partitioned transaction set, construct a set of sub-Merkel trees in parallel from bottom to top; ④ Merge the root hashes of the sub-Merkel trees into the RootNode; ⑤ Encode the set of sub-Merkel trees with erasure coding and store it; ⑥ Calculate the proof of the RootNode, which serves as the transaction root in the block header.

[0073] Example 2

[0074] This embodiment describes a method for reading and verifying transactions.

[0075] like Figure 4 As shown in the diagram: ① Node 1 receives a request req:a92445 for the transaction with transaction hash a92445; ② Node 1 obtains the blockchain node address addr storing the transaction based on the transaction hash a92445, which corresponds to Node 0; ③ Node 1 forwards the transaction read request req:a92445 to Node 0; ④ Node 0 obtains the blockchain node address addr storing the transaction based on the transaction hash a92445 and finds that addr corresponds to its own address; ⑤ Node 0 reads the data content 64|b82c… corresponding to the transaction hash a92445 from its local database, where 64 is the height of the block containing the transaction, and b82c… is the transaction content; ⑥ Node 0 obtains the hashes of all transactions at height 64 and calculates the proof path from bottom to top; ⑦ Node 0 sends the proof path and transaction content to Node 1; ⑧ Node 1 calculates the root r of the sub-Merkel tree according to the proof path and verifies r using the locally stored transaction root; ⑨ Node 1 returns the transaction content to the requesting user.

[0076] The specific steps for verifying the proof path at node 1 in step ⑧ above are as follows: Figure 5 As shown. ① Node 1 calculates the parent node hash h1 of these transaction leaf nodes in ITT based on the transaction hash a92445 returned by Node 0 and the related leaf node transaction hash h0; ② Calculate the parent node hash h3 using the intermediate node hash h2 at the same level as h1 in the proof path returned by Node 0; ③ Utilize the VC feature of RootNode to verify that the root hash h3 of the sub-Merkel tree calculated by the proof path returned by Node 0 matches the corresponding Merkel root hash stored locally.

[0077] The scope of protection of this invention is not limited to the above embodiments. Any variations and advantages that can be conceived by those skilled in the art without departing from the spirit and scope of the inventive concept are included in this invention and are protected by the appended claims.

Claims

1. A method for index-free sharding transaction encoding storage of consortium chain transaction data, characterized in that, The method comprises the following steps: Step 1: set the size of the VC root node RootNode as k, k nodes of n nodes participating in the current block consensus will store the encoded data block, and the remaining n-k nodes will store the check block generated by encoding; Step 2: Dividing the transactions after a block consensus into different transaction sets according to the division rule (i = 1, …, k) Step 3: For each transaction set divided, construct a set of sub-Merkle trees in parallel (i = 1,..., k); In step 3, the following steps are further included: Step 3-1: according to the amount of data that each Merkel node can accommodate, the height of the sub-Merkel tree composed of Merkel nodes is calculated; Step 3-2: according to the size of the VC commitment and proof, the size of the conversion threshold H is calculated; Step 3-3: if the height of the sub-Merkel tree is less than the conversion threshold, the Merkel node is used as the parent node of the ITT leaf node, otherwise the VC node is used as the parent node of the ITT leaf node; Step 3-4: according to the intermediate nodes obtained in the above steps, the Merkel node is created from bottom to top according to the amount of data that the Merkel node can accommodate, and the sub-Merkel tree is constructed; Step 4: combine the root hash of the sub-Merkel tree into RootNode; Step 5: calculate the VC proof of the whole transaction tree with RootNode as the root, and take it as the transaction root in the block header; Step 6: To the child Merkle tree set Performing erasure code encoding to generate an encoded block (i = 1, …, n), the node calculates the blocks to be stored and actually stores them.

2. The method of claim 1, wherein, According to the dynamic adjustment of the height of the child Merkel tree in the index-free transaction tree, the calculation method of the node type conversion threshold H is as follows: for a Merkel node with a capacity of m and a commitment size of , a VC node with a proof size of , the hash function used is SHA256, and the tree height threshold for converting the Merkel tree into a VC node is ; wherein the hash size generated by the SHA256 hash function is 32 bytes, the size of the verification information brought by a layer of Merkle nodes, the size of the verification information brought by a VC node; when the intermediate nodes of the child Merkle tree are completely m-ary Merkle nodes, the size of the verification information brought by a layer of k-ary Merkle nodes is wherein 32 is the hash size generated by the SHA256 hash function, and k is the number of layers of the Merkle tree, that is, the number of layers when a VC node generates the same size of verification information as a layer of k-ary Merkle nodes; in order to reduce the size of the verification information, when a Merkle node is used as the parent node of the ITT leaf node, otherwise a VC node is used as the parent node of the ITT leaf node, and thus the tree height conversion threshold is .

3. The method of claim 1, wherein, The root node of the ITT is a VC node, and the size of the VC root node array depends on the number of nodes participating in the transaction data slicing in the current block, and each position of the VC root node array is mapped to a sub-Merkel tree; The commitment C constructed by the VC root node array is written into the transaction root of the block header as the verification commitment of all transactions in the current block; each sub-Merkel tree mapped by the VC root node array contains a set of transaction data stored on the same node after slicing; the sub-Merkel tree contains: Merkel node, VC node, data node and empty node; wherein, the VC node and the Merkel node are used to verify the correctness of the data node in logic, and the Merkel node is replaced by the VC node according to the actual transaction size in the block; when the size of a transaction in a block is too large, multiple Merkel nodes are combined into a VC node.

4. The method of claim 1, wherein, In order to ensure the availability of the data after slicing, each Merkel sub-tree in the ITT is encoded and stored by erasure code; after encoding, the n encoded blocks are stored on n nodes respectively, so that the availability of the data will not be affected when no more than (n-k) nodes in the system fail.

5. A verification function and data indexing method for consortium chain transaction data stored for a method according to any one of claims 1 to 4, characterized in that, The method comprises the following steps: Step a: any node receives a request for a transaction, obtains the blockchain node address storing the transaction according to the hash of the transaction, and requests the corresponding node for the transaction; Step b: the node storing the transaction reads the corresponding stored data content from the database by taking the transaction hash as the key; Step c: according to the block number where the transaction is located, read the hashes of all transactions under the sub-Merkel tree of the corresponding block; Step d: iteratively calculate from bottom to top to obtain the proof path of the target transaction, and construct complete transaction verification information to send to the requester; Step e: After the requester gets the transaction data and its verification information, it iteratively calculates from bottom to top according to the proof path of the transaction, and uses the transaction root in the locally stored block header to verify the calculated sub-Merkle tree root. If successful, the transaction content is returned, otherwise, an empty value is returned.

6. A verifiable data structure suitable for use in a non-indexed sharded transaction encoding storage method as claimed in any one of claims 1-4, characterized in that, The verifiable data structure is an ITT, which is an indexless transaction tree, a vector commitment and hash mixed verifiable transaction tree, containing the following nodes: VC node: a VC node is logically a VC array of a specific size. When the VC node is the root node of the ITT, the size of the VC array is consistent with the number of nodes storing the encoded data blocks. When the VC node is an intermediate node of the ITT, the size of the VC array is specified by the construction parameters of the ITT. There is at least one VC node in the entire ITT data structure, which is the root node of the ITT. Each position of the VC node array is mapped to a data node or an empty node or a Merkle node. VC is a cryptographic primitive similar to an accumulator, providing similar functions to an accumulator. The operation of VC is completed in polynomial time complexity; Merkle node: a node in a sub-Merkle tree, which can contain m data, and the size of m is dynamically adjusted by the actual allocation of the transaction size of the large disk. Each data of the Merkle node is mapped to a VC node or a Merkle node or a data node or an empty node; Data node: stores the transaction hash and the data content corresponding to the transaction, wherein the data content is encoded as h|d, h is the height of the block where the transaction is located, and d is the actual data of the transaction; Empty node: a node without storing any data. When a position of the VC array or the Merkle node does not have corresponding mapping data, it is defaulted to point to an empty node.

Images