CN110738472B - Block chain storage method and node of block chain - Google Patents
Block chain storage method and node of block chain Download PDFInfo
- Publication number
- CN110738472B CN110738472B CN201810804118.8A CN201810804118A CN110738472B CN 110738472 B CN110738472 B CN 110738472B CN 201810804118 A CN201810804118 A CN 201810804118A CN 110738472 B CN110738472 B CN 110738472B
- Authority
- CN
- China
- Prior art keywords
- block
- transaction
- node
- reserved
- reserved set
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
- G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3827—Use of message hashing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Economics (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- Development Economics (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application provides a storage method of a block chain and a node of the block chain. The storage method comprises the following steps: storing a block header of the complete block chain; and storing the block body obtained by downsampling the block body of the complete block chain according to the rule. According to the application, the limitation of the prior art on the knowledge of the block chain architecture is overcome, and a block chain storage method and a novel node are provided, so that not only can the storage redundancy of all nodes be reduced, but also verification and broadcasting capabilities are provided.
Description
Technical Field
The application relates to a storage method of a blockchain and a node of the blockchain.
Background
With the wide application of the distributed system, the blockchain technology has the remarkable characteristics of distributed high-redundancy storage, time series data, non-falsification and forging, decentralization credit, intelligent contract, security, privacy protection and the like, so that the application in the fields of economic, financial and social systems is rapidly developed, wherein digital currency, data storage, data authentication, financial transaction, asset management, voting and the like are represented.
With advances and developments in blockchain technology, the problem of blockexpansion has become one of the major issues that limit blockchain efficiency and range of applications. Blockchains require that each full node back up a complete piece of blockchain data, however with the widespread use of blockchains and the high growth of transactions, it is extremely difficult for each node to store ever-increasing amounts of data.
Especially for mobile terminals, mass data is continuously generated along with the increase of intelligent devices, and a large amount of bandwidth, time and energy are consumed for the transmission of important data, so that a large number of devices need to be managed through a distributed self-organizing mode. The characteristics of self-distribution and attack resistance of the blockchain can be well used in the scene. And reducing the blockchain data that a single node needs to store is of great significance to the free use of blockchains on smart devices.
Disclosure of Invention
The application aims to provide a storage method of a block chain and a node of the block chain.
According to one aspect of the application, a method of storing a blockchain is disclosed, comprising: storing a block header of the complete block chain; and storing the block body obtained by downsampling the block body of the complete block chain according to the rule.
According to one aspect of the application, a node of a blockchain is disclosed, comprising a blockhead and a blockvolume, the blockhead comprising a blockhead of a complete blockchain, and the blockvolume comprising a blockvolume obtained by downsampling a blockvolume of the complete blockchain according to a rule.
According to the application, the limitation of the prior art on the knowledge of the block chain architecture is overcome, and a block chain storage method and a novel node are provided, so that not only can the storage redundancy of all nodes be reduced, but also verification and broadcasting capabilities are provided.
Drawings
Fig. 1 shows a block chain architecture of a distributed accounting system.
Fig. 2 shows a schematic view of a zone block.
Fig. 3 shows a schematic of a transaction stored in a zone block.
FIG. 4 illustrates a schematic diagram of a method of storing a blockchain in accordance with an embodiment of the present application.
FIG. 5 illustrates a schematic diagram of a node of a blockchain in accordance with an embodiment of the present application.
FIG. 6 illustrates one embodiment of determining a reserved set according to a rules rule.
Fig. 7 shows a schematic representation of probability density functions of a living block according to one embodiment of the application.
Fig. 8 shows a schematic diagram of probability distribution of each tile being used by a new transaction according to one embodiment of the application.
FIG. 9 illustrates a schematic diagram of a node of a blockchain in accordance with an embodiment of the present application.
Detailed Description
The method for storing a blockchain and nodes of the blockchain disclosed by the application are described in detail below with reference to the accompanying drawings. For simplicity, the same or similar devices are given the same or similar reference numerals in the description of the embodiments of the application.
The blockchain is a non-tamperable and non-counterfeitable decentralized shared general ledger (Decentralized shared ledger) which combines data blocks into a specific data structure in a chain manner according to a time sequence and is ensured in a cryptographic manner, and can safely store simple, orderly-related and verification-capable data in a system. The generalized blockchain technology is a brand new decentralised infrastructure and distributed computing paradigm that uses encryption chained blockstructures to validate and store data, distributed node consensus algorithms to generate and update data, automated script code (smart contracts) to program and manipulate data.
Because the blockchain uses the encrypted chain type block structure to verify and store data, the blockchain storage has a high degree of redundancy, and each full node must independently store a complete piece of blockchain data.
For example, the distributed accounting system provides a publicly visible accounting book through the blockchain network that records historical transaction status that has occurred. FIG. 1 shows a block chain architecture for a distributed accounting system. As shown in fig. 1, a complete blockchain consists of N blocks stored sequentially from block 1 to block N. Each block comprises a block body and a block head. The block of each block contains transactions and merkle trees generated from those transactions. The block header of each block stores the hash value of the block header of the previous block of the block and the Merkle root of the Merkle tree in the block body of the block. Different block sequences are linked together by storing the hash value of the previous block header in the block header of the block. The block and the block header are closely linked together by storing the Merkle root in the block header. Thereby forming a complete blockchain.
The generation mode of the merkle tree is to generate hash identifiers of transactions, the hash identifiers are paired and hashed to obtain hash values of paired data, and the pairing and hashing processes are repeated until only one hash value remains, wherein the hash value is a merkle root of the merkle tree.
Fig. 2 shows a schematic view of a zone block. Four transactions (T1, T2, T3, T4) and a merkle tree generated from the transactions are included. When the zone block is generated, hash operations are respectively carried out on T1, T2, T3 and T4 to obtain hash identifications Fu Haxi-0, hash 0-1, hash 1-0 and hash 1-1 of the zone block. And carrying out hash operation on the transaction identifiers in pairs. Wherein hash identifier Fu Haxi-0 and hash 0-1 together perform hash operation to obtain hash 0, and hash 1-1 and hash 1-0 together perform hash operation to obtain hash 1. And repeating the pairing hash process, pairing hash 0 and hash 1 to obtain merkle root, and packaging hash values and transaction data except for the merkle root to form a zone block.
Fig. 3 shows a schematic of a transaction stored in a zone block. The transaction includes an input and an output. The output of the transaction includes the output of the transaction that has been used and the output of the transaction that has not been used (Unspent Transaction Outputs, UTXOs). A legal new transaction, UTXOs, references some existing transactions, is used as input to the transaction and generates new output. Fig. 3 shows the generation and use of 7 transactions (transactions 0-6), transaction 0 referencing UTXOs of a transaction prior to transaction 0 as input 0, transaction 0 generating both output 0 and output 1, the difference between the input and output being the billing fee paid for the transaction. Transaction 1 references output 0 generated by transaction 0 as its own input 0 and generates its own output 0, transaction 1 including output 0 and the billing fee. Transactions 2-6 each reference the output of the previous transaction as their own input and generate their own output. In the present illustration, output 0 of transaction 3 and output 0 of transaction 6 are not referenced as inputs by other transactions, so transaction 3 and transaction 6 each have UTXOs, which may be referenced as inputs by later generated transactions. It can be seen that UTXOS exists as a balance that can be used.
When a user sends a new transaction to the network, nodes in the network check whether the new transaction is legal after receiving the new transaction information. Specifically, it is checked whether the input of the transaction reference is UTXOs, i.e., the latest transaction state. In addition, it is also possible to check whether the address is legal, the originating transactor is the legal owner of the input address, etc. It will also check if the transaction has been processed and if the sum of the inputs is greater than the sum of the outputs. If the new transaction check passes, the new transaction is marked as a legal unconfirmed new transaction and broadcast within the network.
After the nodes in the network verify and broadcast the new transaction, a transaction logger is required to write the new transaction into the blockchain, i.e., make the new transaction a part of the new blockchain. The transaction recorders generate a merkle tree by using new transactions, add corresponding parameters of block heads, pack the new transactions into blocks, enable the newly packed blocks to meet a consensus mechanism through operations such as calculation and the like, and broadcast the new blocks.
After receiving the new block (block n+1), the nodes in the network check the validity of the contents of the block, i.e. the new transaction in the block. In addition, the node may check the format of the chunk including data structure syntax, consensus mechanism, time, chunk size, and whether the coinage transaction is the first transaction, etc.
If the new block check passes, the new block n+1 is marked as a valid new block and an attempt is made to connect the new block n+1 to the existing blockchain. If the connection is successful, block n+1 is taken as part of the current blockchain and broadcast within the network.
Under the blockchain architecture, the prior art recognizes that to support verification and broadcasting of all new transactions, a node must store all historical transaction states of the blockchain, i.e., a full node. Because the full node downloads and validates blocks from the created block to the most recently discovered block, the blocks can be strictly organized into a complete blockchain by the hash value of the previous block header and merkle root in each block, ensuring the effectiveness of the blockchain. All the historical transaction states of a real blockchain are stored in the full node, so that the validity of all new transactions can be verified, and the security is high.
But also brings about high redundancy of storage while ensuring high security. The data are not only downloaded and stored, but also need to consume a large amount of resources to carry out verification, index and state update, thereby increasing the storage overhead of the nodes and reducing the efficiency of transaction processing.
There is also a light node in which only the block header is stored. However, the light node is not capable of conducting transactions and block broadcasting, and the light node can only verify the validity and security of a certain transaction under the support of a reliable full node. The light node reduces the storage capacity, but the working capacity of the light node depends on the whole node, the working load of the whole node is increased, the occupation of bandwidth resources is caused, and meanwhile, the safety of intelligent equipment using the light node is reduced.
According to the application, the limitation of the prior art on the knowledge of the block chain architecture is overcome, and a block chain storage method and a novel block chain node are provided, so that the full node storage redundancy can be reduced, and the verification and broadcasting capability is realized.
According to one embodiment of the application, a method of storing a blockchain is disclosed. As shown in fig. 4, in S100, the block header of the complete blockchain is stored. In S200, a block obtained by downsampling a block of the complete blockchain according to a rule is stored.
According to another embodiment of the present application, a method of storing a blockchain is disclosed, comprising storing a blockhead of a complete blockchain; and storing the block of the reserved set, wherein the reserved set of the block obtained by downsampling the block of the complete blockchain is determined according to the probability distribution of each block in the blockchain used by the new transaction. Here, the rules of law may include a probability distribution that each tile in the blockchain is used by a new transaction.
According to one embodiment of the application, a node of a blockchain is also disclosed. The node includes a block header and a block body. The block header of the node includes a block header of a complete blockchain. The block body of the node comprises a block body obtained by downsampling the block body of the complete block chain according to a rule.
According to another embodiment of the present application, a node of a blockchain is also disclosed. As shown in fig. 5, the node includes a block head and a block body. The block header of the node includes a block header of a complete blockchain. The block body of the node comprises a block body of a reserved set, wherein the reserved set is obtained by downsampling the block body of the complete block chain according to probability distribution of each block in the block chain used by new transactions.
In the blockchain, all historical transaction states are stored in the blockvolume, with the latest transaction state (most recent state) being part of the historical transaction state. The block with the latest transaction status is the block that is used in the future for transaction verification and broadcasting. The latest transaction state may be, for example, the output UTXOs of the unused transactions, or an account balance. The probability distribution of each block in the blockchain being used by a new transaction is determined by the distribution rules of the latest transaction state.
To represent the distribution law of new transaction states (i.e., the probability that each chunk is used by a new transaction), in the present application, a "living chunk" is defined that represents the number of chunks that a certain transaction state in the blockchain experiences from the latest transaction state at the time of generation to the time of being changed by the transaction later (i.e., to become a non-latest transaction state). The living block of the transaction state reflects the inherent rule of the transaction state. For a certain deterministic network, although the distribution of the latest transaction state changes with the increase of the block height, the distribution of the transaction state survival blocks does not change, which means that the transaction state survival blocks have a more general meaning. Thus, the probability of each tile being used by a new transaction may be obtained by a probability density function of the tiles of the transaction state.
FIG. 6 illustrates one embodiment of determining a reserved set according to a rules rule.
As shown, in S210, a probability density function f (x) of the survival block of the transaction state is obtained according to the statistical distribution probability of the survival block x of the transaction state. The survival blocks x for each transaction state can be counted to obtain the statistical distribution probability of the survival blocks of the transaction state.
In S220, the probability distribution u (d) of each block including the latest transaction state is calculated from the probability density function f (x) of the survival block x of the transaction state.
In S230, a reserved set is determined according to the probability distribution u (d) that each block contains the latest transaction state and a preset downsampling threshold.
The statistical distribution probability of the survival block x of the transaction state obtains a probability density function f (x) of the survival block of the transaction state, and the probability distribution u (d) of each block containing the latest transaction state is calculated according to the probability density function f (x) of the survival block x of the transaction state. For example, when the number of transactions in each block is uniform, u (d):
where d represents the block depth, as shown in fig. 5, where a block is located from the latest block, where the latest block depth is 1.
According to one embodiment of the application, the preset downsampling threshold may be a preset information entropy threshold H t . Obtaining an information entropy function of each block based on the depth of the block according to the probability distribution u (d) of each block containing the latest transaction state; according to the information entropy function and the preset information entropy threshold H t A range of reserved block depths is calculated to determine the reserved set.
To reflect how much information is provided in each block for verifying and broadcasting a new transaction, information entropy may be used, defined as H (a) =e [ -log P (a) ], a being the probability that an uncertain event block is used by the new transaction, P (a) being a. The higher the probability of containing the latest transaction state in the block, the higher the probability of A, and the greater the information entropy.
And observing each block independently, wherein the information entropy of the block with the current time block depth d is as follows:
H(A)＝E[-log P(A)]＝E[-log u(d)]＝-u(d)log u(d)＝H(d)。
according to one embodiment of the application, the reserved set may be obtained by: obtaining an information entropy function H (d) of the blocks based on the block depth d according to the probability distribution of each block used by the new transaction; according to the information entropy function H (d) and the preset information entropy threshold H t Calculating the range of reserved block depths to determine the reserved set, i.e. all satisfying H (d) > H t Determining a reserved set D according to the range of reserved block depths; the entire block header of the complete blockchain and the block of the reserved set D are stored. In this way, a novel downsampling node (DS node) according to the application can be obtained.
According to one embodiment of the application, the DS node generates the latest transaction state pool according to the stored block body of the reserved set. The DS node can conduct verification and broadcast of new transactions and new blocks according to the generated latest transaction state pool.
When the DS node is operational, for example when the DS node receives a new transaction, the DS node checks whether the input is in the latest transaction state pool generated by the DS node. It will be appreciated that the DS node may also check whether the transaction address is valid, the sender is the legitimate owner of the input address, etc. The DS node may also check whether the transaction is processed, whether the input of the transaction is greater than the sum of the outputs, etc. If the check passes, the DS node marks the new transaction as an unprocessed legal transaction for broadcasting.
The verification and broadcasting is also similar for the new block. When the DS node receives a newly generated block, it will check the validity of all transactions within the verification block. If the check passes, the DS node marks the new block as a legal block for broadcasting.
On the basis of enabling the DS nodes provided by the application to have independent verification and broadcasting capabilities, in order to improve the storage efficiency of the nodes and adapt to changeable application environments, the data stored by each DS node can be downsampled according to the requirements of the application environments. On the basis of meeting the performance and safety of the block chain, the storage overhead is reduced, and the resource utilization rate of the system is improved.
To illustrate the performance of the present application, assume N t Is the number of historical transaction states of the complete blockchain, N u Is the number of last transaction states of the complete blockchain, N st And N su Is the number of historical transaction states and the number of latest transaction states of the DS node. Then the DS node verifies and broadcasts the new transaction with a correctness of N su /N u . If the number of historical transaction states in each tile is the same, then,
wherein the method comprises the steps ofIs the DS node reserved set, and δ is the number of reserved area blocks, i.e., the cardinality of the reserved set.
According to one embodiment of the application, the storage efficiency of a node can be characterized by a ratio R of broadcast correctness to storage:
wherein the method comprises the steps ofIs the reserved set and delta is the number of reserved zone blocks.
The selection of blocks in the downsampled block chain storage method is a one-time operation because the reserved set D is stable despite the varying depth of the blocks. Thus, the complexity of the downsampling block chain storage method depends on the number of download area blocks. With appropriate H t Only the complete node needs to download delta in the zone block.
UTXOs represent the latest transaction state, and nodes verify new transactions using the UTXOs pool. Through research on UTXOS, it can be found that the distribution of UTXOS accords with a certain rule, the survival block x of each UTXOS can be counted to obtain the statistical distribution probability of the survival block of UTXOS, and the probability density function f (x) of the survival block of UTXOS is obtained according to the statistical distribution probability of the survival block x of UTXOS:
(f (x) =0 when x < 0)
Where x is the living block.
If the number of transactions output in each block is considered to be uniform, a probability distribution u (d) for each block containing UTXOS is calculated from the probability density function f (x) for the block of survival x of UTXOS:
and observing each block independently, wherein the information entropy of the block with the current time block depth d is as follows:
H(d)＝E[-log u(d)]＝-u(d)log u(d)
here we can downsample the blockchain with the following steps:
the reserved set of region blocks to be downsampled and stored is obtained by: obtaining an information entropy function H (d) of the blocks based on the block depth according to the probability distribution of each block used by the new transaction; according to the information entropy function H (d) and a preset information entropy threshold H t Calculating the range of reserved block depths to determine the reserved set, i.e., solution H (d) > H t Obtaining a depth D range, wherein a set formed by the depth D range is a reserved set D; the entire block header of the complete blockchain and the block of the reserved set D are stored. In this way, a downsampling node (DS node) according to the application can be obtained.
When the DS node receives a new transaction, the DS node checks whether the input is in the latest transaction state pool generated by the DS node, whether the transaction is legal, including whether the address is valid, and whether the sender is a legal owner of the input address. In addition, the DS node checks whether the transaction is processed, and whether the input of the transaction is larger than the sum of the outputs. If the check passes, the DS node marks the new transaction as an unprocessed legal transaction for broadcasting.
The working steps are also similar for the newly generated blocks. When a DS node receives a newly generated chunk, it will check the validity of transactions within the verification chunk, data structure, consensus mechanism, chunk time, and coinage transactions. If the check passes, the DS node marks the new block as a legal block for broadcasting.
To illustrate the performance of the downsampled blockchain storage method, in Table 1, full node, H, is shown t Broadcast accuracy and R for DS node=0.23 e-27.
TABLE 1 full nodes, H t Broadcast accuracy and R for DS node=0.23 e-27
| Broadcast accuracy | R | |
| DS node | 1.000 | 0.006 |
| Full node | 1 | 6.049e-6 |
It can be seen that when the downsampling rate is less than 1024, the DS node has a similar broadcast accuracy rate as the full node, with a higher R than the full node.
In table 2, the average download block numbers of the full node and the DS node are shown.
Table 2 average download block number for full node and Ds node
| H t | 0 | 0.23e-27 | 0.22e-06 |
| DS node | 519893 | 508 | 127 |
| Full node | 519893 | - | - |
It can be seen that DS nodes with appropriate downsampling rates require only a small fraction of the number of download blocks for a complete node.
The probability distribution of each block in the blockchain being used by a new transaction may be different depending on the type of blockchain. For example, the probability density function of the living block x of the transaction state of the blockchain network may be changed to obtain a corresponding probability distribution u (d) for each block used by the new transaction. However, it will be appreciated that the downsampled blockchain storage method and node operation are the same as the blockchain storage method described above.
For example, for some exemplary blockchain networks, the survival blocks x for each transaction state may be counted to obtain a statistical distribution probability for the survival blocks for the transaction state, and the probability density function f (x) for the survival blocks for the transaction state is obtained from the statistical distribution probability for the survival blocks x for the transaction state:
f(x)＝e -x
(f (x) =0 when x < 0)
Where x is the living block.
Calculating probability distribution u (d) of each block including the latest transaction state according to probability density function f (x) of survival block x of transaction state:
and observing each block independently, wherein the information entropy of the block with the current time block depth d is as follows:
H(d)＝E[-log u(d)]＝-u(d)log u(d)＝de -d log e
here we can downsample the blockchain with the following steps:
the reserved set of region blocks to be downsampled and stored is obtained by: obtaining an information entropy function H (d) of the blocks based on the block depth according to the probability distribution of each block used by the new transaction; according to the information entropy function H (d) and a preset information entropy threshold H t Calculating the range of reserved block depths to determine the reserved set, i.e., solution H (d) > H t Obtaining a depth D range, wherein a set formed by the depth D range is a reserved set D; the entire block header of the complete blockchain and the block of the reserved set D are stored. In this way, a downsampling node (DS node) according to the application can be obtained.
According to another embodiment of the application, the preset downsampling threshold value is a preset downsampling rate. The radix of the reserved set may be calculated from the downsampling rate and the total number of blocks; and calculating the range of the depth of the reserved block according to the cardinality of the reserved set and the probability distribution of each block containing the latest transaction state so as to determine the reserved set.
For example, the downsampling rate may be preset to M. The radix δ of the reserved set is calculated from the downsampling rate M and the total number of blocks. The range of reserved block depths is calculated from the cardinality delta of the reserved set and the probability distribution u (D) that each block is used by the new transaction to determine the reserved set D. The entire block header of the complete blockchain and the block of the reserved set D are stored. In this way, a downsampling node (DS node) according to the application can be obtained.
According to another embodiment of the application, UTXOS represents the latest transaction status, and nodes verify new transactions using the UTXOS pool. The probability density function f (x) of the survival block of UTXOs can be obtained from the statistical distribution probability of the survival block x of UTXOs by counting the survival block x of each UTXOs to obtain the statistical distribution probability of the survival block of UTXOs, as shown in fig. 7:
(f (x) =0 when x < 0)
Where x is the living block.
If the number of transactions output in each tile is considered to be uniform, then the probability u (d) that a tile of tile depth d contains all UTXOS (i.e., the probability distribution that each tile is used by a new transaction) is as shown in FIG. 8:
here we can downsample the blockchain with the following steps: determining a downsampling rate M; according to the downsampling rate M and the total block number d max Calculating the cardinality δ, δ=d of the reserved set max Calculating a range of reserved block depths from a radix delta of the reserved set and a probability distribution u (D) of each block being used by the new transaction to determine a reserved set D, D being a set of delta block volumes where u (D) is greatest, D being the first delta block volumes of complete blockchain block depths since u (D) is a monotonically decreasing function,and storing all block heads of the complete blockchain and the block of the reserved set D. In this way, a downsampling node (DS node) according to the application can be obtained.
When the DS node receives a new transaction, the DS node checks whether the input is in the latest transaction state pool generated by the DS node, whether the transaction is legal, including whether the address is valid, and whether the sender is a legal owner of the input address. In addition, the DS node checks whether the transaction is processed, and whether the input of the transaction is larger than the sum of the outputs. If the check passes, the DS node marks the new transaction as an unprocessed legal transaction for broadcasting.
The working steps are also similar for the newly generated blocks. When a DS node receives a newly generated chunk, it will check the validity of transactions within the verification chunk, data structure, consensus mechanism, chunk time, and coinage transactions. If the check passes, the DS node marks the new block as a legal block for broadcasting.
To illustrate the performance of the downsampled blockchain storage method, in table 3, the broadcast accuracy and R of a full node, DS node of downsampling rate m=1024 are shown.
Table 3 broadcast correct rate and R of Ds node of full node, downsampling rate m=1024
| Broadcast accuracy | R | |
| DS node | 1.000 | 0.006 |
| Full node | 1 | 6.049e-6 |
It can be seen that when the downsampling rate is less than 1024, the DS node has a similar broadcast accuracy rate as the full node, with a higher R than the full node.
In table 4, the average download block numbers of the full node and the DS node are shown.
Table 4 average download block number for full node and Ds node
| M | 1 | 16 | 256 | 1024 | 4096 |
| DS node | 519893 | 32494 | 2031 | 508 | 127 |
| Full node | 519893 | - | - | - | - |
It can be seen that a DS node with a suitable downsampling rate is only 1/M of the average number of download blocks of the complete node.
Furthermore, in the downsampling blockchain storage method of each blockchain, random sampling can be introduced, namely, on the basis of the downsampling blockchain storage method, the blocks of L unreserved sets are randomly stored to resist the guessing of an attacker. Wherein the unreserved set is a set of blocks of the complete blockchain except for the reserved set. According to one embodiment of the application, a method for storing a blockchain is disclosed, comprising: storing a block header of the complete block chain; and storing the block of the reserved set and the block of the unreserved set selected according to a random rule.
According to one embodiment of the application, a node of a blockchain is disclosed. Wherein the node comprises a block head and a block body. The block header of the node includes a block header of a complete blockchain. The block body of the node comprises a block body obtained by downsampling the block body of the complete block chain according to a rule and a block body of an unreserved set selected according to a random rule. As shown in FIG. 9, a mutually non-repeating random sequence j of length L can be randomly generated in the unreserved set 1 、j 2 、...j L ，(j 1 Shown schematically in fig. 9) DS node stores not only the region blocks of the reserved set, but also the region blocks of depth j 1 、j 2 、...j L Is a non-reserved aggregate block. By introducing random sampling, the region blocks stored by the DS node cannot be fully predicted even if the attacker knows the downsampling storage method and the downsampled starting block depth. Thus effectively preventing the possibility of a successful attack.
According to one embodiment of the application, the latest transaction state pool can be generated according to the stored reserved set of blocks and the stored unreserved set of blocks selected by random rules. The legitimacy of the new transaction can be verified, and the new transaction has independent verification and broadcasting capabilities. Meanwhile, as the block body with L random storage unreserved sets is provided, the guessing attack of an attacker can be effectively resisted.
Exemplary embodiments of the present application are described above with reference to the accompanying drawings. It will be appreciated by persons skilled in the art that the foregoing embodiments have been provided by way of example only and not by way of limitation, and that any modifications, equivalents, etc. which fall within the teachings of the present application and the scope of the appended claims are intended to be included therein.
Claims (11)
1. A method of storing a blockchain, comprising: storing a block header of the complete block chain; and storing a reserved set of block volumes obtained by downsampling the block volumes of the complete blockchain according to a rule,
wherein the complete blockchain includes a plurality of blocks, each of the plurality of blocks including the block header and the reserved set, the reserved set including a transaction and a merkle tree generated by the transaction; and
the rule comprises probability distribution of each block in the complete block chain used by new transaction, wherein a probability density function of a survival block in a transaction state is obtained according to the statistical distribution probability of the survival block in the transaction state, and the probability distribution of each block containing the latest transaction state is calculated according to the probability density function of the survival block in the transaction state; and determining the reserved set according to the probability distribution of each block containing the latest transaction state and a preset downsampling threshold value.
2. The storage method of claim 1, wherein the preset downsampling threshold is a preset entropy threshold, wherein a block depth-based entropy function is obtained from a probability distribution of each block containing a latest transaction state; and calculating the range of the reserved block depth according to the information entropy function and a preset information entropy threshold value to determine the reserved set.
3. The storage method of claim 2, further comprising: generating a latest transaction state pool according to the stored block body of the reserved set.
4. The storage method of claim 1, wherein the preset downsampling threshold is a preset downsampling rate, wherein a radix of the reserved set is calculated from the downsampling rate and a total number of blocks; and calculating the range of the depth of the reserved block according to the cardinality of the reserved set and the probability distribution of each block containing the latest transaction state so as to determine the reserved set.
5. The storage method of claim 4, further comprising: generating a latest transaction state pool according to the stored block body of the reserved set.
6. The storage method of any one of claims 1-5, further comprising: a block of the unreserved set selected according to a random rule is stored.
7. The storage method of claim 6, further comprising: generating the latest transaction state pool according to the stored block bodies of the reserved set and the stored block bodies of the non-reserved set selected by random rules.
8. A node of a blockchain includes a plurality of blocks, each of the plurality of blocks including a block header of a complete blockchain, and a reserved set of downsampling a block body of the complete blockchain according to a rules rule,
wherein the reserved set comprises a transaction and a merkle tree generated by the transaction; and
the rules of law include a probability distribution of each block in the complete blockchain being used by a new transaction, wherein the reserved set is obtained by: obtaining a probability density function of the survival block of the transaction state according to the statistical distribution probability of the survival block of the transaction state; calculating probability distribution of each block containing the latest transaction state according to probability density functions of the survival blocks of the transaction states; and determining the reserved set according to the probability distribution of each block containing the latest transaction state and a preset downsampling threshold value.
9. The node of claim 8, wherein the preset downsampling threshold is a preset entropy threshold, wherein a block depth-based entropy function is obtained from a probability distribution that each block contains the latest transaction state; and calculating the range of the reserved block depth according to the information entropy function and a preset information entropy threshold value to determine the reserved set.
10. The node of claim 8, wherein the preset downsampling threshold is a preset downsampling rate, wherein the cardinality of the reserved set is calculated from the downsampling rate and a total number of blocks; and calculating the range of the depth of the reserved block according to the cardinality of the reserved set and the probability distribution of each block containing the latest transaction state so as to determine the reserved set.
11. The node of any of claims 8-10, wherein the chunk further comprises a chunk of the unreserved set selected according to a random rule.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810804118.8A CN110738472B (en) | 2018-07-20 | 2018-07-20 | Block chain storage method and node of block chain |
| PCT/CN2019/096316 WO2020015668A1 (en) | 2018-07-20 | 2019-07-17 | Block chain storage method and node of block chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810804118.8A CN110738472B (en) | 2018-07-20 | 2018-07-20 | Block chain storage method and node of block chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110738472A CN110738472A (en) | 2020-01-31 |
| CN110738472B true CN110738472B (en) | 2023-10-03 |
Family
ID=69164281
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810804118.8A Active CN110738472B (en) | 2018-07-20 | 2018-07-20 | Block chain storage method and node of block chain |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN110738472B (en) |
| WO (1) | WO2020015668A1 (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2587541A (en) * | 2018-10-05 | 2021-03-31 | Dragon Infosec Ltd | A consensus method and framework for a blockchain system |
| CN111614721B (en) * | 2020-04-14 | 2022-11-22 | 梁伟 | Multi-dimensional block chain network, and method and device for generating multi-dimensional block chain network |
| CN111651525A (en) * | 2020-06-24 | 2020-09-11 | 北京米弘科技有限公司 | Block chain data storage method and device |
| CN111858751A (en) * | 2020-06-29 | 2020-10-30 | 深圳壹账通智能科技有限公司 | Data storage method and device based on block chain |
| CN112988893B (en) * | 2021-03-15 | 2023-05-12 | 中国联合网络通信集团有限公司 | Information management method, system, block chain node and medium based on block chain |
| CN112947868B (en) * | 2021-04-08 | 2024-05-03 | 辽宁大学 | Four-branch chain type structure financial block chain storage method |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106656798A (en) * | 2016-12-30 | 2017-05-10 | 先锋支付有限公司 | Method for computing decision path and distributed nodes |
| CN107079059A (en) * | 2016-12-21 | 2017-08-18 | 深圳前海达闼云端智能科技有限公司 | Block chain storage method and device and node equipment |
| CN107657438A (en) * | 2017-09-18 | 2018-02-02 | 联动优势科技有限公司 | A kind of block chain generation method, data verification method, node and system |
| CN107683489A (en) * | 2015-06-26 | 2018-02-09 | 英特尔公司 | For performing the systems, devices and methods of cryptographic operation in trust performing environment |
| CN107766540A (en) * | 2017-10-31 | 2018-03-06 | 上海分布信息科技有限公司 | A kind of block chain network of subregion and its method for realizing partitioned storage |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3095044B1 (en) * | 2013-11-19 | 2020-09-23 | Top Galore Limited | Block mining methods and apparatus |
| US10304143B2 (en) * | 2016-05-05 | 2019-05-28 | Lance Timothy Kasper | Consensus system for manipulation resistant digital record keeping |
| CN106406896B (en) * | 2016-09-27 | 2020-03-17 | 北京天德科技有限公司 | Block chain block building method based on parallel Pipeline technology |
| CN107122477A (en) * | 2017-05-02 | 2017-09-01 | 成都中远信电子科技有限公司 | A kind of block chain storage system |
| CN107276762B (en) * | 2017-05-08 | 2019-08-30 | 飞天诚信科技股份有限公司 | A kind of working method and device of multi-protocols block chain |
| CN107729471A (en) * | 2017-10-13 | 2018-02-23 | 上海策赢网络科技有限公司 | A kind of block chain and its generation method and equipment |
-
2018
- 2018-07-20 CN CN201810804118.8A patent/CN110738472B/en active Active
-
2019
- 2019-07-17 WO PCT/CN2019/096316 patent/WO2020015668A1/en active Application Filing
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107683489A (en) * | 2015-06-26 | 2018-02-09 | 英特尔公司 | For performing the systems, devices and methods of cryptographic operation in trust performing environment |
| CN107079059A (en) * | 2016-12-21 | 2017-08-18 | 深圳前海达闼云端智能科技有限公司 | Block chain storage method and device and node equipment |
| CN106656798A (en) * | 2016-12-30 | 2017-05-10 | 先锋支付有限公司 | Method for computing decision path and distributed nodes |
| CN107657438A (en) * | 2017-09-18 | 2018-02-02 | 联动优势科技有限公司 | A kind of block chain generation method, data verification method, node and system |
| CN107766540A (en) * | 2017-10-31 | 2018-03-06 | 上海分布信息科技有限公司 | A kind of block chain network of subregion and its method for realizing partitioned storage |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2020015668A1 (en) | 2020-01-23 |
| CN110738472A (en) | 2020-01-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110738472B (en) | Block chain storage method and node of block chain | |
| CN110245956B (en) | Asynchronous multi-chain based block chain transaction confirmation method and system | |
| CN110033243B (en) | Main chain evidence storing method, system and storage medium based on block chain intelligent contract | |
| JP7211977B2 (en) | Method and system for mining blockchain transactions provided by validator nodes | |
| CN109391645B (en) | Block chain lightweight processing method, block chain node and storage medium | |
| CN111047439B (en) | Transaction processing method based on blockchain | |
| CN109766389B (en) | Block chain light client verification query method based on bitmap index | |
| CN110945831B (en) | Generation of anti-Sybil attack identities | |
| Asfia et al. | Energy trading of electric vehicles using blockchain and smart contracts | |
| WO2016131473A1 (en) | Method and system for verifying information of a data item in a plurality of different data items | |
| CN110213038B (en) | Method and system for forming consensus of block chain | |
| Fan et al. | Blockchain based dynamic spectrum access of non-real-time data in cyber-physical-social systems | |
| CN113407977B (en) | Cross-chain extension method and system based on aggregated signature | |
| Shi et al. | Pooling is not favorable: Decentralize mining power of PoW blockchain using age-of-work | |
| CN111639080B (en) | Data processing method and device, node equipment and storage medium | |
| US20220407728A1 (en) | Systems and methods for processing blockchain transactions | |
| Lee et al. | Poster: A proof-of-stake (PoS) blockchain protocol using fair and dynamic sharding management | |
| US12007972B2 (en) | Systems and methods for processing blockchain transactions | |
| CN113886501A (en) | Block chain service module extension method based on multi-chain architecture | |
| Bugday et al. | Securing blockchain shards by using learning based reputation and verifiable random functions | |
| Mizrahi et al. | Optimizing Merkle proof size for blockchain transactions | |
| CN115941206A (en) | Carbon emission data uplink method based on block chain technology | |
| CN109391643B (en) | Block chain lightweight processing method, block chain node and storage medium | |
| CN110278091B (en) | Internet of things block chain consensus method | |
| Blum et al. | Superlight–A permissionless, light-client only blockchain with self-contained proofs and BLS signatures |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |