Method and node for storing blocks in block chain system

Abstract

A method for storing a block in a block chain system and a block chain node, the block chain system comprises n nodes, the n nodes comprise at least m valid nodes, the method is executed by any node, and the method comprises the steps of: according to an erasure code algorithm, determining an erasure code; based on at least part of data in a block body of a target block, a target fragment corresponding to the target fragment is obtained from n fragments, the n fragments comprise t data fragments and s verification fragments, the n fragments correspond to the n nodes respectively, and t is smaller than or equal to m; and storing the target fragment.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of blockchain technology, and more particularly to a method and node for storing blocks in a blockchain system. Background Art

[0002] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. In the blockchain system, data blocks are combined into a chain data structure in a sequential manner according to time sequence, and a distributed ledger that cannot be tampered with or forged is guaranteed by cryptography. Due to the characteristics of blockchain such as decentralization, information cannot be tampered with, and autonomy, blockchain has also received more and more attention and application.

[0003] In the blockchain system, the block data on the chain takes up a lot of storage space, especially for evidence storage scenarios, where a large number of entries are stored in block transactions. As the blockchain system runs for a long time, the block data accumulates more and more, and for the needs of supervision and historical query, it is impossible to clean up this part of the data.

[0004] By optimizing the underlying blockchain storage engine system and using cheap media, the storage cost of each blockchain node has been reduced to a certain extent. However, since each participant stores a complete copy of the block data on the chain, the data stored by each participant is exactly the same. Although this simple copy method can easily meet the requirements of Byzantine fault tolerance, the storage cost increases linearly with the increase in the number of cluster participants. Summary of the invention

[0005] The object of the present invention is to provide a method for storing blocks in a blockchain system to reduce the demand for storage resources in the blockchain system.

[0006] In a first aspect, the present specification provides a method for storing blocks in a blockchain system, wherein the blockchain system includes n nodes, wherein the n nodes include at least m valid nodes, and the method is executed by any node, including:

[0007] According to the erasure code algorithm, based on at least part of the data in the block body of the target block, obtain a target shard corresponding to itself from among the n shards, wherein the n shards include t data shards and s check shards, the n shards correspond to the n nodes respectively, and t is less than or equal to m;

[0008] The target shard is stored.

[0009] In one implementation, m valid nodes among the n nodes satisfy the Byzantine fault tolerance distribution.

[0010] In one implementation, the method further includes: storing a block header of the target block.

[0011] The second aspect of the present specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method described in the first aspect.

[0012] The third aspect of this specification provides a blockchain node, including a memory and a processor, wherein the memory stores an executable code, and when the processor executes the executable code, the method described in the first aspect is implemented.

[0013] In the solution provided in the embodiments of this specification, multiple shards of the stripe are obtained based on the data in the block, and each node stores one shard. This method greatly saves the storage resources required in the blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0015] Figure 1 is an architecture diagram of a blockchain system in one embodiment;

[0016] Figure 2 This is a flow chart of a method for storing blocks in a blockchain system in an embodiment of this specification;

[0017] Figure 3 A schematic diagram of a process of storing blocks in an embodiment of this specification;

[0018] Figure 4 A schematic diagram of dividing a block body in an embodiment of this specification;

[0019] Figure 5 A schematic diagram of a process of storing blocks in an embodiment of this specification;

[0020] Figure 6 This is a flow chart of a method for reading data in a blockchain system in an embodiment of this specification. DETAILED DESCRIPTION

[0021] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0022] Figure 1 FIG. 1 shows an architecture diagram of a blockchain system in an embodiment. Figure 1 As shown, the blockchain system includes N nodes. Figure 1 Nodes 1 to 8 are schematically shown in FIG. The lines between the nodes schematically represent the connection between the nodes, which is used to transmit data between the nodes. Each node in the blockchain system can generate the same state in the blockchain system by executing the same transaction, and each node in the blockchain system can store the same state database.

[0023] Transactions in the blockchain field can refer to task units executed and recorded in the blockchain system. Transactions usually include a send field (From), a receive field (To), and a data field (Data). Among them, in the case of a transfer transaction, the From field indicates the account address that initiates the transaction (i.e., initiates a transfer task to another account), the To field indicates the account address that receives the transaction (i.e., receives the transfer), and the Data field includes the transfer amount.

[0024] The blockchain system can provide the function of smart contracts. Smart contracts on the blockchain system are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract in the blockchain system is to initiate a transaction pointing to the smart contract address, so that each node in the blockchain system can run the smart contract code in a distributed manner.

[0025] One of the decentralized features that distinguishes blockchain technology from traditional technologies is that it records accounts on each node, or distributed accounting, rather than traditional centralized accounting. In order for a blockchain system to become a decentralized, honest and trustworthy system that is difficult to break, public, and cannot be tampered with, it is necessary to make distributed data records secure, clear, and irreversible in the shortest possible time. In different types of blockchain networks, in order to maintain the consistency of the ledger in each node that records the ledger, a consensus algorithm is usually used to ensure it, that is, a consensus mechanism. For example, a consensus mechanism with block granularity can be implemented between blockchain nodes. For example, after a node (such as a unique node) generates a block, if the generated block is recognized by other nodes, it means that other nodes have recorded the same block. The consensus mechanism is a mechanism for blockchain nodes to reach a consensus on block information (or block data) across the entire network, which can ensure that the latest block is accurately added to the blockchain. The current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, etc. Among them, in various consensus algorithms, usually after a preset number of nodes reach an agreement on the consensus data (i.e., consensus proposal), the consensus on the consensus proposal is determined to be successful. Specifically, in the PBFT algorithm, assuming that when there are at most f nodes that fail, if there are a total of at least 3f+1 nodes, that is, at least 2f+1 valid nodes, it can ensure security and activity in the system.

[0026] In view of the problem that the block data on the chain takes up a lot of storage space, considering that it is not necessary for each node to store a complete copy of the block in the above-mentioned consensus algorithms, the erasure coding algorithm (EC) can be used to store block data. Among them, in the EC (Erasure Coding) algorithm, n shards can be generated based on the target data to be stored, and the n shards include t data shards obtained by evenly dividing the target data, and s check shards generated based on the t data shards. The n shards can be stored in different geographical locations. In the case of partial damage to the shards, the target data can be restored by any t shards of the n shards. Among them, the data shards and check shards of a group of EC shards constitute an EC stripe. That is to say, in the EC algorithm, the larger the s is, the greater the fault tolerance of the system is, and the higher the redundancy of the system storage data is.

[0027] In combination with the consensus algorithm in the blockchain system, multiple shards of the target data can be distributed to each blockchain node, and n and t meet the restrictions of the consensus algorithm. For example, for the PBFT algorithm, n=3f+1, t is equal to or less than 2f+1, so that when there are at most f failed nodes in the PBFT algorithm, the correct recovery of the target data can be guaranteed. It can be understood that the scheme in the embodiments of this specification is not limited to the PBFT algorithm, but can be used for other consensus algorithms, as long as t is equal to or less than the number of valid nodes m in the consensus algorithm.

[0028] In one scheme, each block is a separate EC shard, and multiple blocks form a stripe. In this scheme, after a block is generated, the block is first cached in memory, and when the data blocks of the stripe length are accumulated, the background EC rewrite is started. During fault recovery, if the node does not reach the full stripe length, the block data is not persistently stored in the block database. At this time, it is necessary to restore the original transaction set from the consensus proposal and reconstruct the block. When the cluster size of blockchain nodes is large, the synchronization data bandwidth increases linearly, such as 4 nodes can restore up to 3 blocks, and 100 nodes can restore up to 66 blocks. In addition, under block-granular EC, EC calculation and recovery need to be aligned to the block. When the recovery read occurs, even if a transaction data is restored, 2F+1 blocks need to be pulled, and a large amount of block data needs to be calculated. When the cluster size is large, the amount of data for the restored shard increases linearly, and there is a lot of redundant data. Moreover, under EC at block granularity, the shard width is equal to the longest block length, and all blocks are padded to the longest block length, resulting in higher redundancy of shards.

[0029] To this end, in the scheme for storing blocks provided in the embodiments of this specification, multiple shards of the stripe are obtained based on the data in the block, and each node stores a shard. In this way, after a block is generated in the blockchain system, multiple shards can be obtained based on the block, and the multiple shards can be written into the block database in real time, so that there is no problem that the block is not persistently stored and needs to be reconstructed. In addition, in this scheme, the block data is sharded within the block, and the recovery cost is relatively low, and by dividing the block data into t equal parts, the shard redundancy can be low.

[0030] Figure 2 The flowchart of a method for storing blocks in a blockchain system in an embodiment of this specification is as follows. Assume that the blockchain system includes n nodes, wherein the n nodes include at least m valid nodes. The method is executed by any node and includes:

[0031] In step S201, according to an erasure code algorithm, a shard corresponding to itself is obtained from n shards based on at least part of the block, wherein the n shards include t data shards and s check shards, the n shards correspond to the n nodes respectively, and t is less than or equal to m;

[0032] In step S203, the obtained fragment corresponding to itself is stored.

[0033] Reference below Figure 3 and Figure 5 The process diagram of the storage block in the embodiment of this specification shown in FIG. Figure 2 The method shown.

[0034] In one embodiment, Figure 3 As shown, it is assumed that the blockchain system includes 4 nodes: node 1 to node 4. According to the PBFT algorithm, when the consensus is successful, it can be determined that there is at most 1 malicious node or faulty node in node 1 to node 4, that is, there are at least 3 valid nodes in node 1 to node 4. Therefore, by dividing at least part of the data in the block into 3 or 2 data fragments and storing them in different nodes, the recovery of at least part of the data can be guaranteed. Among them, when the at least part of the data is divided into 3 data fragments, for the stripe, a check fragment can be generated based on the 3 data fragments; when the at least part of the data is divided into 2 data fragments, for the stripe, 2 check fragments can be generated based on the 2 data fragments.

[0035] Specifically, Figure 3 As shown in , after each node completes the generation of block B1, for example, nodes 1 to 4 store the block header of block B1 respectively, and obtain a shard of the block body based on the EC algorithm and store the shard. In other words, in this process, a stripe is obtained based on the block body, and the stripe includes 3 data shards D1 to D3 and 1 check shard C1.

[0036] In one embodiment, each node may be Figure 4 The block is divided as shown. Figure 4 As shown, a block body may include multiple transaction bodies arranged in a preset transaction order ( Figure 4 TX1 to TX10 are schematically shown in the figure), and a plurality of transaction receipts ( Figure 4RC1 to RC10 are schematically shown in the figure). The order of each transaction in the block is determined based on preset transaction attributes, such as transaction timestamps, transaction execution fees (gas), etc. In one embodiment, the data in the block body can be segmented according to a fixed length in the order of the data in the block body from front to back, and data shards D1 to D3 are obtained in sequence. For example, Figure 4 As shown, the first half of transaction body TX1 to transaction body TX5 is divided into data shard D1, the second half of transaction body TX5 to the first half of transaction body TX9 is divided into data shard D2, and the second half of transaction body TX9 to transaction receipt RC10 is divided into data shard D3. When the amount of data in the second half of transaction body TX9 to transaction receipt RC10 does not reach the above-mentioned fixed length, padding data (Padding) can be added after transaction receipt RC10 to make up to the above-mentioned fixed length.

[0037] Each node can be preset to have a corresponding relationship with a shard, or can have a corresponding relationship with a shard after negotiation. For example, node 1 corresponds to shard D1, node 2 corresponds to shard D2, node 3 corresponds to shard D3, and node 4 corresponds to shard C. Based on this corresponding relationship, when node 1 executes step S201, it can Figure 4 As shown, the block body is divided into data slices D1 to D3, and a correspondence table between each node and the transaction data in the corresponding data slice is stored to facilitate the subsequent reading of the transaction data in the block; and the data slice D1 is stored in step S203, wherein node 1 can store the data slice D1 in association with the identifier of block B1 for the subsequent reading of the data in the slice D1.

[0038] In one implementation, node 1 may record Table 1 and Table 2 as shown below:

[0039] data Overall offset length TX1 0 80 TX2 80 100 TX3 180 70 TX4 250 90 TX5 340 60 … … …

[0040] Table 1

[0041] node Location 1 TX1,0 2 TX5,40 … …

[0042] Table 2

[0043] Table 1 records the overall offset value of each transaction data in the block body, which indicates the arrangement position of each transaction data in the block body. The identifier in the "Data" column is the identifier of the transaction data. For example, when the transaction data is TX1, its identifier can be the hash value of the transaction corresponding to TX1 (transaction TX1) and the identifier indicating the transaction body. When the transaction data is RC1, its identifier can be the hash value of the transaction corresponding to RC1 (transaction TX1) and the identifier indicating the transaction receipt.

[0044] Table 2 records the identifier of the starting transaction data in the data slice stored by each node, and the offset value of the starting position of the slice in the starting transaction data. By recording Table 1 and Table 2, when node 1 subsequently queries transaction data, it can determine in which node the transaction data is stored and the specific storage location of the transaction data in the node by combining Table 1 and Table 2, which facilitates the query of the transaction data. It can be understood that the correspondence table in the embodiments of this specification is not limited to that shown in Table 1 and Table 2, as long as the correspondence table can indicate the transaction data in the data slice corresponding to each node.

[0045] Node 2 and Node 3 can shard the block body similarly to Node 1, record the corresponding relationship table, and store a corresponding shard, which will not be repeated here.

[0046] After node 4 divides the block body into data shards D1 to D3 and stores the above correspondence table, it calculates the check shard C based on the data shards D1 to D3 according to the EC algorithm, and stores the check shard C in association with the identifier of block B1.

[0047] In another embodiment, each node may send Figure 3 The block body in is divided into 3 data shards. Specifically, assuming that the fixed number of transactions is 4, TX1~TX4 and RC1~RC4 can be divided into data shard D1, TX5~TX8 and RC5~RC8 can be divided into data shard D2, and TX9~TX10 and RC9~RC10 can be divided into data shard D3. After the division, the other two parts of data can be filled according to the maximum data volume of the three parts of data divided above, so that the data volume of the three data shards is equal. Under this division method, when each node queries the transaction data, it can infer which node the transaction data to be queried is stored in according to the division method.

[0048] In one embodiment, under this splitting method, node 1 can obtain TX1~TX4 and RC1~RC4 from the block body, and store TX1~TX4 and RC1~RC4 as data shard D1. Node 2 and node 3 can obtain their corresponding transaction data from the block body similar to node 1 and store the transaction data as data shards. The stored data shards may have unequal data volumes. In this case, when the data needs to be restored through the EC algorithm, the data shards can be filled first based on the data volume of the verification shards, and then the data can be restored based on the filled data shards and the verification shards. In addition, node 4 can split the block body in the above manner. After the splitting, the other two parts of the data can be filled according to the maximum data volume of the three parts of the split data, so that the data volume of the three data shards is equal, and the verification shard C is calculated based on the three filled data shards, and the verification shard C is stored.

[0049] Refer to the following Figure 5 Description of the process shown Figure 2 The method shown.

[0050] like Figure 5 As shown, when executing step S201, each node may first cut the block body to obtain 6 data fragments D11~D31 and D12~D32, and generate a check fragment C1 based on the data fragments D11~D31, wherein the data fragments D11~D31 and the check fragment C1 constitute a stripe s1, and generate a check fragment C2 based on the data fragments D12~D32, wherein the data fragments D12~D32 and the check fragment C2 constitute a stripe s2.

[0051] Specifically, the block body can be divided according to a fixed amount of data to obtain the above-mentioned 6 data shards, or the block body can be divided according to a fixed number of transactions as described above, and there is no limitation on this. In one embodiment, TX1~TX4 and RC1~RC4 can be first divided into node 1, TX5~TX8 and RC5~RC8 can be divided into nodes, and TX9~TX10 and RC9~RC10 can be divided into node 3 as described above, and then the data divided into each node can be further divided according to the fixed amount of data. For example, according to the fixed amount of data, TX1~TX4 and RC1~RC4 are divided into two data shards, wherein, when the amount of data in the latter data shard is not enough for the fixed amount of data, the latter data shard can be filled with data, so that 6 data shards can be obtained.

[0052] Each node can obtain the shards of the two stripes corresponding to itself according to the above division of the block body. For example, node 1 obtains data shard D11 of stripe s1 and data shard D12 of stripe s2, node 2 obtains data shard D21 of stripe s1 and data shard D22 of stripe s2, node 3 obtains data shard D31 of stripe s1 and data shard D32 of stripe s2, and node 4 can calculate the parity shard C1 of stripe s1 based on data shards D11, D21 and D31, and calculate the parity shard C2 of stripe s2 based on data shards D12, D22 and D32.

[0053] Each node is Figure 5 After the block body is divided as shown, the above Table 1 and the following Table 3 can be stored:

[0054] node Strip Location 1 1 TX1,0 1 2 TX3,50 2 1 TX5,80 2 2 TX7,20 3 1 TX9,40 3 2 RC6,10

[0055] Table 3

[0056] In step S203, each node stores the obtained slices. Specifically, each node may store the obtained slices in association with the identifier of block B1 and the stripe identifier. For example, node 1 stores data shard D11 in association with the identifier of block B1 and the identifier of stripe s1, and stores data shard D12 in association with the identifier of block B1 and the identifier of stripe s2. Node 2 stores data shard D21 in association with the identifier of block B1 and the identifier of stripe s1, and stores data shard D22 in association with the identifier of block B1 and the identifier of stripe s2. Node 3 stores data shard D31 in association with the identifier of block B1 and the identifier of stripe s1, and stores data shard D32 in association with the identifier of block B1 and the identifier of stripe s2. Node 4 stores check shard C1 in association with the identifier of block B1 and the identifier of stripe s1, and stores check shard C2 in association with the identifier of block B1 and the identifier of stripe s2.

[0057] Compared with generating one stripe for storage based on the block body, by generating multiple stripes for storage based on the block body, the amount of calculation and communication is smaller during data recovery, and the recovery cost is lower.

[0058] Figure 6 This is a flow chart of a method for reading data in a blockchain system in an embodiment of this specification. The method can be executed by any node in the blockchain system.

[0059] like Figure 6 As shown, in step S601, a request to read transaction data is received.

[0060] The client can send a transaction data query request to any node of the blockchain system. The query request may include the transaction hash value of the target transaction to be queried and indicate the transaction body and / or transaction receipt of the target transaction to be queried. Figure 3 or Figure 5 As shown, four nodes are included, and node 1 receives a read request, which is used as an example for description below.

[0061] In step S603, the first node corresponding to the transaction data is determined.

[0062] In one embodiment, when the block body is divided by a fixed number of transactions as described above, node 1 can perform calculations based on the fixed number of transactions to determine the first node corresponding to the transaction data. For example, node 1 can first determine the order of the target transactions based on the hash value of the target transaction corresponding to the transaction data according to Table 1. For example, when it is determined that the transaction data TX5 to be queried is arranged in the fifth transaction, it can be determined that the transaction data corresponds to node 2 according to the fixed number of transactions (4). In this case, node 2 is the first node corresponding to the transaction data.

[0063] In another embodiment, when the block body is divided by a fixed amount of data as described above, node 1 can determine the node corresponding to the transaction data to be queried according to Table 1 and Table 2, or Table 1 and Table 3. Specifically, refer to Figure 5 , Table 1 and Table 3, node 1 can first retrieve the position of the target transaction data in the block based on the hash value of the transaction corresponding to the target transaction data according to Table 1. For example, according to Table 1, the offset position of the transaction data TX6 to be queried in the block is determined, and then according to Table 3, it can be determined that the transaction data TX6 corresponds to node 2. In this case, node 2 is the first node corresponding to the transaction data.

[0064] In one embodiment, node 1 may determine that the transaction data to be read is stored in itself (i.e., node 1), for example, referring to Figure 5 , when the transaction data to be read is TX3, node 1 can determine that TX3 is stored in itself according to Table 1 and Table 3. In this case, node 1 is the first node corresponding to the transaction data.

[0065] In one embodiment, node 1 may determine that the transaction data to be read is stored in multiple nodes, for example, referring to Figure 3 and Figure 4 , when the transaction data to be read is TX5, node 1 can determine that TX5 is stored in node 1 and node 2 according to Table 1 and Table 2. In this case, node 1 and node 2 are the two first nodes corresponding to the transaction data TX5.

[0066] In step S605, transaction data is read from the first node.

[0067] After node 1 determines the first node corresponding to the transaction data, if the first node is itself, node 1 can directly read the transaction data from its own storage. Figure 5 As shown, when the transaction data to be read is TX3, node 1 can obtain the reading position in shard D11 and the reading position in shard D12 corresponding to TX3 according to Table 1 and Table 3, and read TX3 based on the reading position. Specifically, it can be determined in combination with Table 1 and Table 3 that shard D11 includes data with offsets of 0 to 229 in block B1, and the first half of TX3 data (i.e., offsets 0 to 49 in TX3) from offset 180 to 229 in shard D11, and the second half of TX3 data (i.e., offsets 50 to 69 in TX3) from offset 0 to 19 in shard D12. Therefore, node 1 can read the first half of TX3 data from the position of offset 180 to 229 of the shard corresponding to stripe s1 of block B1 (i.e., shard D11), and read the second half of TX3 data from the position of offset 0 to 19 of the shard corresponding to stripe s2 of block B1 (i.e., shard D12).

[0068] In the case where the first node includes other nodes, node 1 may request to read transaction data from other nodes. Figure 4 In the strip shown, when the transaction data to be read is TX5, node 1 can determine that the first half of TX5 is in node 1, the second half of TX5 is in node 2, and the offset 0 to 19 in shard D2 according to Table 1 and Table 2. Node 1 can read the first half of TX5 from node 1, and the reading process can refer to the above description, which will not be repeated here. Node 1 also requests node 2 to read the offset 0 to 19 of shard D2. After node 2 successfully reads the second half of TX5 and returns it to node 1, node 1 thus reads the second half of TX5.

[0069] In step S607, the transaction data is returned.

[0070] After reading the transaction data from the first node as described above, node 1 returns the transaction data to the client.

[0071] In step S609, reading transaction data from the first node fails.

[0072] In the case where the first node is not Node 1 itself, when the first node fails, or is a malicious node, or the shards stored in the first node are damaged, the first node cannot return transaction data to Node 1, and Node 1 fails to read transaction data from the first node.

[0073] In the event that reading the transaction data from the first node fails, step S611 is executed to read at least t shards other than the shard of the first node, and the transaction data is restored based on the at least t shards.

[0074] refer to Figure 3 and Figure 4 In the example described above where node 1 requests to read the second half of TX5 from node 2, if node 2 does not return transaction data to node 1, according to the EC algorithm, node 1 reads the shard of block B1 (i.e. data shard D1) from itself, requests node 3 to read the shard of block B1 (i.e. data shard D3), and requests node 4 to read the shard of block B1 (i.e. check shard C), and performs calculations based on shard data D1, data shard D3, and check shard C to obtain the restored data shard D2. Afterwards, node 1 can read the second half of TX5 from the offset 0 to 19 of data shard D2, and then execute step S607 to return transaction data TX5 to the client.

[0075] Refer to Figure 5 In the example described above where Node 1 requests to read TX6 from Node 2, and Node 2 does not return transaction data to Node 1, since TX6 is located in stripe s1, according to the EC algorithm, Node 1 reads the shard of stripe s1 of block B1 from itself (i.e., data shard D11), requests Node 3 to read the shard of stripe s1 of block B1 (i.e., data shard D31), and requests Node 4 to read the shard of stripe s1 of block B1 (i.e., check shard C1), and restores the shard of stripe s1 corresponding to Node 2 (i.e., data shard D21) based on the three shards of stripe s1 (i.e., data shard D11, data shard D31, and check shard C1). Afterwards, Node 1 can read TX6 from the offset position of data shard D21 corresponding to TX6, and execute step S607 to return TX6 to the client.

[0076] In the case where the client initiates a transaction data read request to node 1 and node 1 fails, the client can re-initiate a transaction data read request to any other node in the blockchain system (e.g., node 2) and indicate that node 1 has failed. Node 2 can perform similar operations as node 1. Figure 6 In the method flow shown, when it is determined that the transaction data is stored in node 1, step S611 is executed to restore the transaction data and return it to the client.

[0077] In addition, node 1 can generate SPV proof data for simple payment verification (SPV) of the transaction data returned to the client. Wherein, in the case where the transaction data is the transaction body of the target transaction, the SPV proof data may include: the block header of block B1, and the hash values ​​of other nodes in the tree path from the node corresponding to the target transaction to the root node in the transaction tree corresponding to block B1. Node 1 can first determine the identifiers of multiple second transactions corresponding to the SPV proof data of the target transaction, and read the transaction bodies of each second transaction through the method described above, thereby obtaining the hash values ​​of the transaction bodies of each second transaction based on the transaction bodies of each second transaction, and returning the hash values ​​of the transaction bodies of each second transaction and the block header of block B1 to the client. Wherein, in the case where the second transaction is in other nodes, node 1 can also directly request the hash value of the second transaction from other nodes.

[0078] In addition, if node 1 fails to read the transaction body of the second transaction from other nodes, it can obtain the transaction body of the second transaction by restoring the shards based on the EC algorithm similarly to the above. The specific process will not be repeated here.

[0079] The client can thus calculate the hash value of the transaction root based on the hash value of the transaction body of the target transaction and the hash value of the transaction body of each second transaction, and compare the calculated hash value of the transaction root with the hash value of the transaction root in the received block header. If the two are consistent, the hash value of the received block header is calculated, and the calculated hash value of the block header is compared with the hash value of the block header of the pre-stored block B1. If they are consistent, it is determined that the SPV verification is passed.

[0080] In the case where the transaction data is a transaction receipt of the target transaction, the SPV proof data may include: the block header of block B1, and the hash values ​​of other nodes in the tree path from the node corresponding to the receipt of the target transaction to the root node in the receipt tree corresponding to block B1. Node 1 may obtain the SPV proof data of the transaction receipt similarly to the above, and the client may perform SPV verification similarly to the above, which will not be repeated here.

[0081] The embodiment of the present specification also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the following Figure 2 or Figure 6 The method shown.

[0082] The embodiment of this specification also provides a blockchain node, including a memory and a processor, wherein the memory stores an executable code, and when the processor executes the executable code, the following is implemented: Figure 2 or Figure 6 The method shown.

[0083] In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0084] The controller can be implemented in any appropriate manner, for example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) that can be executed by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, the controller can be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and structures within the hardware component.

[0085] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not exclude that with the development of computer technology in the future, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0086] Although one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps, and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such a process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any specific order.

[0087] For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing one or more of the present specification, the functions of each module can be implemented in the same or more software and / or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0088] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0089] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0090] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0091] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0092] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0093] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0094] It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0095] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0096] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.

[0097] The above description is only an example of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the scope of the claims.

Claims

1. A method for storing blocks in a blockchain system, wherein the blockchain system includes n nodes, wherein the n nodes include at least m valid nodes, and the method is executed by any node, comprising: According to the erasure code algorithm, based on at least part of the data in the block body of the target block, obtain a target shard corresponding to itself from among the n shards, wherein the n shards include t data shards and s check shards, the n shards correspond to the n nodes respectively, and t is less than or equal to m; The target shard is stored.

2. The method according to claim 1, further comprising: A corresponding relationship table is recorded, where the corresponding relationship table is used to indicate information about transaction data in the shards stored in each node.

3. According to the method of claim 2, the t data shards are obtained by sequentially splitting the block body, and the correspondence table includes a first table and a second table, the first table includes the offset position of each transaction data in the block in the target block, and the second table includes the identifier of the transaction data corresponding to the starting position of the shard stored by each node, and the offset position of the starting position in the corresponding transaction data.

4. According to the method of claim 3, the block is divided into multiple stripes, and the at least part of the data belongs to the first stripe of the multiple stripes, and the second table also includes the identification of the stripe corresponding to the shards stored in each node.

5. According to the method of claim 4, storing the target shard comprises storing the target shard in association with a block identifier of a target block and an identifier of the first stripe.

6. The method according to claim 5, further comprising: receiving a read request for first transaction data from a client; Determining one or more first nodes corresponding to the first transaction data; reading the first transaction data from the one or more first nodes; The first transaction data is returned to the client.

7. The method according to claim 6, wherein the reading the first transaction data from the one or more first nodes comprises: Determine a first stripe corresponding to the first transaction data in the first node, and read the first transaction data from a shard stored in the first node in association with a block identifier of the target block and an identifier of the first stripe.

8. The method according to claim 6, further comprising: Determining one or more second nodes corresponding to the second transaction data; Reading the second transaction data or a hash value of the second transaction data at the one or more second nodes; Generate SPV proof data of the first transaction data based on the second transaction data or the hash value of the second transaction data; The SPV certification data is sent to the client.

9. The method according to claim 6, further comprising: In the case that the one or more first nodes are faulty nodes, at least t shards are read from the remaining at least t nodes among the n nodes, and the first transaction data is obtained based on the at least t shards.

10. A blockchain node, comprising a memory and a processor, wherein the memory stores an executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 9 is implemented.

Images