WO2023045150A1 - 区块验证方法 - Google Patents
区块验证方法 Download PDFInfo
- Publication number
- WO2023045150A1 WO2023045150A1 PCT/CN2021/140630 CN2021140630W WO2023045150A1 WO 2023045150 A1 WO2023045150 A1 WO 2023045150A1 CN 2021140630 W CN2021140630 W CN 2021140630W WO 2023045150 A1 WO2023045150 A1 WO 2023045150A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- verified
- block
- target
- transaction information
- transaction
- Prior art date
Links
- 238000012795 verification Methods 0.000 title claims abstract description 119
- 238000000034 method Methods 0.000 title claims abstract description 65
- 230000007246 mechanism Effects 0.000 claims abstract description 50
- 238000010586 diagram Methods 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 7
- 230000000694 effects Effects 0.000 description 3
- 238000005065 mining Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000004806 packaging method and process Methods 0.000 description 3
- 230000006978 adaptation Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000009825 accumulation Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000002427 irreversible effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Definitions
- the present application relates to the technical field of financial technology (Fintech), and in particular to a block verification method.
- the blockchain uses the block chain data structure to verify and store data, and generates and updates data based on the distributed node consensus mechanism. It also uses cryptography to ensure the security of data transmission and access, and uses smart contracts composed of automated script codes. Programming and manipulating data. Therefore, the blockchain provides a highly consistent distributed ledger. Among them, based on the consensus mechanism, any participating node independently modifying its own ledger cannot affect the entire distributed network, which makes the blockchain non-tamperable. During the implementation of the consensus mechanism, the nodes participating in the consensus need to verify the block to record the block when the verification is passed.
- lightweight terminal devices such as smart terminals, personal computers, and sensors involved in the public or small and medium-sized Its storage overhead is limited and it is impossible to store all transaction information in full, and thus cannot verify the validity of transactions to complete block verification, resulting in the inability of lightweight terminal devices to participate in the normal operation of the blockchain network.
- the present application provides a block verification method, which is used to provide a lightweight terminal device with a block verification method that can be performed without storing a full amount of transaction information.
- This application provides a block verification method, which is applied to light nodes in a blockchain network; the method includes:
- the target condition is obtained according to the transaction status value, and the transaction status value is used to represent the transaction information that the light node has received ;
- the block to be verified passes verification.
- the present application provides a block verification method, which is applied to light nodes in a blockchain network.
- the light node receives the block to be verified sent by the target full node and determines whether the block to be verified meets the first condition of the preset consensus mechanism. If so, the light node judges whether all the transaction information to be verified included in the block to be verified meets The target condition, the target condition is obtained according to the transaction status value, and the transaction status value is used to represent the transaction information that the light node has received. If the light node determines that all the transaction information to be verified meets the target conditions, it determines that the block to be verified has passed the verification, so that the light node realizes the block verification of the block to be verified based on the transaction status value, without storing the full amount of transaction information. It is possible for chain nodes to run on lightweight terminal devices.
- FIG. 1 is a schematic diagram of an application scenario provided by an embodiment of the present application
- FIG. 2 is a schematic flow diagram of a block verification method provided by an embodiment of the present application.
- FIG. 3 is a schematic flow diagram of another block verification method provided by the embodiment of the present application.
- FIG. 4 is a schematic flow diagram of another block verification method provided by the embodiment of the present application.
- FIG. 5 is a schematic diagram of a transaction status value update process provided by the embodiment of the present application.
- FIG. 6 is a schematic flow diagram of another block verification method provided by the embodiment of the present application.
- FIG. 7 is a schematic flow diagram of another block verification method provided by the embodiment of the present application.
- FIG. 8 is a schematic flowchart of another block verification method provided by the embodiment of the present application.
- any participating node can independently modify its own ledger without affecting the entire distributed network, which makes the blockchain irreversible. Because of this, during the implementation of the consensus mechanism, the nodes participating in the consensus need to verify the block to record the block when the verification is passed. However, in block verification, in addition to verifying the correctness of the transaction signature, it is also necessary to ensure the validity of the transaction, that is, it needs to be verified based on the previous block (that is, the transaction) and the state of the Merkle tree should be updated in real time. It can be seen that the nodes participating in the consensus need to have all the transaction information on the complete path to complete the block verification.
- the nodes participating in the consensus are all full nodes, in other words, the full amount of data of the blockchain network is stored on the full nodes.
- Full nodes are generally consensus and mining nodes.
- the public or small and medium-sized organizations have increasingly strong demands to participate in the blockchain network.
- lightweight terminal devices such as smart terminals, personal computers, and sensors involved in the public or small and medium-sized Its storage overhead is limited and it is impossible to store all transaction information in full, and thus cannot verify the validity of transactions to complete block verification, resulting in the inability of lightweight terminal devices to participate in the normal operation of the blockchain network.
- the present application provides a block verification method, which is applied to light nodes in the block chain network.
- the inventive idea of the blockchain verification method provided by this application is: the light node receives the block to be verified sent by the target full node, first judges whether the block to be verified meets the first condition of the preset consensus mechanism, and when it is satisfied, further judges Whether all the transaction information to be verified included in the block to be verified meets the target condition, wherein the target condition is obtained according to the transaction status value, and the transaction status value can represent the transaction information that the light node has received, so that when all the transactions to be verified When the information meets the target conditions, it is determined that the block to be verified has passed the verification.
- the verification of the block to be verified can be realized based on the transaction status value, which is different from the existing technology. Steps such as Merkle tree proof are carried out, and block verification can be realized without storing a full amount of transaction information, making it possible for blockchain nodes to run on lightweight terminal devices. Moreover, since the transaction status value can be stored in a small space, the storage space will not increase with the number of blocks to be verified, which is more conducive to the application of lightweight terminal equipment in the blockchain network.
- FIG. 1 is a schematic diagram of an application scenario provided by the embodiment of the present application.
- the blockchain network includes multiple blockchain nodes, such as blockchain node 11, blockchain node 12, blockchain node 13 and blockchain nodes 14, wherein blockchain nodes 11 to 14 are all full nodes, full nodes refer to the need to store the full amount of transaction information of the blockchain network, generally consensus nodes and mining nodes.
- the processor configured in the light node 15 can realize the verification of the block to be verified without storing the full amount of transaction information by executing the block verification method provided by the embodiment of the present application, and can participate in the block chain when the verification is passed.
- the normal operation of the blockchain is carried out in the network.
- the light node 15 can be, for example, a mobile terminal, a personal computer, or a sensor with a very limited storage cost, and the mobile terminal can be a wearable device such as a smart phone or a smart watch.
- the number of full nodes in the blockchain network is schematically listed as four, and the number of light nodes is one. In actual working conditions, there is no limit to the number of full nodes and light nodes in the blockchain network, which is determined by the actual situation.
- the light node 15 in FIG. 1 is shown by taking a smart phone as an example.
- FIG. 2 is a schematic flowchart of a block verification method provided by an embodiment of the present application. As shown in Figure 2, the block verification method provided by the embodiment of the present application is applied to light nodes in the blockchain network, and the method includes:
- S101 Receive the block to be verified sent by the target full node, and determine whether the block to be verified meets the first condition of the preset consensus mechanism.
- the target full node is elected among the full nodes of the blockchain network.
- the light node receives the block to be verified sent by the target full node, and the block to be verified is formed by the target full node selecting transaction information from its own transaction pool according to business needs and packaging the selected transaction information. For example, when the target full node packs and forms a new block, it needs to broadcast the new block to other nodes in the blockchain network, and the light node can receive the new block sent by the target full node.
- the block is the block to be verified.
- the target full node is elected from the full nodes of the blockchain network. For example, when a full node in the blockchain network executes transaction information, it needs to elect a full node from all full nodes to broadcast the block based on the preset consensus mechanism.
- the elected full node is defined as the target full node. node.
- the default consensus mechanism takes the Proof of Work (PoW for short) consensus mechanism as an example.
- the method of electing the target full node from the full node can be realized by calculating the hash value. For example, each full node will calculate a hash value that meets the difficulty condition. When a full node calculates the hash value first, the full node will be elected as the target full node.
- the hash value that meets the difficulty condition value can also be referred to as the difficulty value.
- the target full node will pack the difficulty value and the transaction information selected from its own transaction pool according to business needs to form the above new block, that is, the block to be verified, and broadcast the block to be verified to other node.
- the light node After the light node receives the block to be verified, it will determine whether the block to be verified meets the first condition of the preset consensus mechanism.
- Fig. 3 is a schematic flowchart of another block verification method provided by the embodiment of the present application. As shown in Figure 3, the embodiment of the present application includes:
- S1011 Verify whether the difficulty value of the block to be verified is correct.
- the first condition of the PoW consensus mechanism includes the difficulty value.
- the second feedback information is used to instruct the light node to reject the block to be verified.
- the light node After the light node receives the block to be verified, if the default consensus mechanism is the PoW consensus mechanism, the first condition of the default consensus mechanism, that is, the first condition of the PoW consensus mechanism includes the difficulty value. Therefore, the light node determines whether the block to be verified meets the first condition of the preset consensus mechanism, that is, the light node verifies whether the difficulty value of the block to be verified is correct, and if it is correct, it determines that the block to be verified meets the first condition. Conversely, if it is not correct, the block to be verified does not meet the first condition, then it can be determined that the block to be verified has not passed the verification, and the light node can generate the second feedback information, and instruct the light node to reject the block to be verified through the second feedback information piece.
- the first condition of the default consensus mechanism that is, the first condition of the PoW consensus mechanism includes the difficulty value. Therefore, the light node determines whether the block to be verified meets the first condition of the preset consensus mechanism, that is, the light node
- the light node receives the block to be verified sent by the target full node, and determines whether the block to be verified meets the first condition of the preset consensus mechanism. For example, assuming that the preset consensus mechanism is a PoW consensus mechanism, the light node determines whether it meets the first condition of the preset consensus mechanism by verifying whether the difficulty value of the block to be verified is correct. If it is correct, it is determined that the block to be verified meets the first condition of the preset consensus mechanism. On the contrary, if it is incorrect, it indicates that the block to be verified has not passed the verification, and second feedback information is generated to instruct the light node to reject the block to be verified. This provides a precondition for the blocks to be verified to complete block verification.
- the preset consensus mechanism is a PoW consensus mechanism
- the first condition for determining whether the block to be verified meets the preset consensus mechanism can be understood as verifying the correctness of the transaction signature corresponding to the block to be verified.
- the preset consensus mechanism includes but is not limited to the PoW consensus mechanism.
- the default consensus mechanism is other consensus mechanisms
- the correctness of the transaction signature can be verified in specific ways corresponding to other preset consensus mechanisms to determine whether the block to be verified meets the primary conditions of the preset consensus mechanism.
- step S102 it can be known from the above description that when the verification difficulty value is correct, it is determined that the block to be verified meets the first condition of the preset consensus mechanism, and step S102 is further executed. If the verification difficulty value is incorrect, it means that the block to be verified does not meet the first condition of the preset consensus mechanism, and the block to be verified has not passed the verification.
- the target condition is obtained according to the transaction status value, and the transaction status value is used to represent the transaction information that the light node has received.
- the light node can feed back the transaction information it has received through the transaction status value, and obtain the target condition according to the transaction status value it maintains, and then can judge all the transactions included in the block to be verified Whether the transaction information to be verified meets the target conditions, to realize the verification of the validity of all the transaction information to be verified included in the block to be verified.
- the transaction information to be verified refers to the transaction information contained in the block to be verified, that is, the transaction information selected by the target full node when packaging the block to be verified.
- the target full node will m(1 ⁇ m ⁇ n ) to form a block to be verified by packaging the transaction information, assuming that the block to be verified is represented by B 1 , then the transaction information in B 1 , that is, all transaction information to be verified can be represented by the following set:
- the light node judges whether all the transaction information to be verified included in the block B 1 to be verified meets the target condition.
- the target condition is obtained according to the transaction status value maintained by the light node, and the transaction status value maintained by it can be fed back to the received transaction information.
- judging whether all the transaction information to be verified included in the block to be verified meets the target condition in the target condition can be understood as judging whether the m transaction information to be verified included in the block to be verified exists in its maintenance in the transaction status value.
- all m transaction information to be verified exists in the transaction status value maintained by it, it means that all the transaction information to be verified included in the block to be verified meets the target condition.
- any of the m transaction information to be verified does not exist in the transaction status value maintained by it, it means that all the transaction information to be verified included in the block to be verified does not meet the target conditions.
- step S103 After the judgment, if it is judged that all the transaction information to be verified included in the block to be verified meets the target condition, it means that the validity of all the transaction information to be verified included in the block to be verified has passed the verification, that is, step S103 is executed. On the contrary, if it is determined that all the transaction information to be verified does not meet the target condition, step S104 is executed.
- the first feedback information is used to instruct the light node to reject the block to be verified.
- the light node determines that all the transaction information to be verified included in the block to be verified meets the target conditions, it means that the transaction validity verification of all the transaction information to be verified included in the block to be verified by the light node has passed, and combined with the block to be verified before On the premise of satisfying the first condition of the preset consensus mechanism, it can be determined that the block to be verified has passed the verification, and the verification of the block to be verified can be completed.
- first feedback information is also generated, and the light node is instructed to reject the block to be verified through the first feedback information.
- the light node records the block to be verified and sends verification information to the target full node.
- the target full node knows that the light node has passed the verification of the block to be verified.
- the target full node After the target full node receives a certain amount of verification information, it can complete the chaining of the block to be verified.
- the target full node receives a certain amount of verification information, it means that the target full node receives more than the preset amount of verification information. For example, each node that passes the verification of the validity of the transaction information will feed back the verification information to the target full node.
- the target full node When the target full node receives verification information exceeding 51% of the total number of nodes sending blocks to be verified, the target The full node has received more than the preset amount of verification information, and for the target full node, it has completed the uploading of the block to be verified.
- the block verification method provided by the embodiment of this application is applied to light nodes in the blockchain network.
- the light node receives the block to be verified sent by the target full node, and determines whether the block to be verified meets the first condition of the preset consensus mechanism. If so, the light node judges whether all the transaction information to be verified included in the block to be verified meets the target condition.
- the target condition is obtained according to the transaction status value maintained by the light node, and the transaction status value is used to represent Transaction information, light nodes do not need to store the full amount of transaction information.
- the block to be verified passes the verification.
- the light node determines that the block to be verified meets the first condition of the preset consensus mechanism, it judges all the transaction information to be verified included in the block to be verified based on the transaction status value maintained by it Whether all meet the target conditions to achieve the verification of the block to be verified.
- block verification can be achieved without storing the full amount of transaction information, making it possible for blockchain nodes to run on lightweight terminal devices.
- the transaction status value feeds back the transaction information that the light node has received. Specifically, before receiving the block to be verified sent by the target full node, whenever the light node receives the transaction information sent by the target account, it updates the transaction status value according to the preset update strategy and the transaction information received this time, so as to pass the The maintained transaction status value feeds back the transaction information it has received.
- the target account will choose any blockchain node in the blockchain network to send transaction information.
- the full node in the blockchain network receives the transaction information sent by the target account, it will put it into its own transaction pool.
- the light node does not need to save the transaction information, but updates the transaction status value according to the transaction information and the preset update strategy, and replaces the storage of the full amount of transaction information by maintaining the transaction status value.
- Fig. 4 is a schematic flowchart of another block verification method provided by the embodiment of the present application.
- the block verification method provided by the embodiment of the present application includes:
- the current hash value is the hash value of the current received transaction information.
- S202 Generate a target transaction status value according to the current hash value, a preset update algorithm, and the current transaction status value.
- the preset update algorithm includes a target parameter and a target feature function
- the target parameter is a product of a first parameter and a second parameter that are mutually prime numbers.
- S203 Update the transaction state value by using the preset update method and the target transaction state value.
- the preset update strategy includes a preset update algorithm and a preset update method.
- the light node Whenever the light node receives the transaction information sent by the target account, it obtains the hash value of the transaction information received at the current time, that is, obtains the current hash value. Then generate the target transaction status value according to the current hash value, the preset update algorithm and the current transaction status value, and then use the preset update method and the target transaction status value to update the transaction status value. For example, the default update method adopted is to update the current The transaction status value of is updated to the target transaction status value, thus completing the update of the transaction status value.
- FIG. 5 is a schematic diagram of a transaction state value update process provided by the embodiment of the present application.
- T 1 to T n represent that the light node receives the 1st to nth transaction information sent by the target account
- H(T 1 ) to H(T n ) represent the 1st to nth transaction information respectively.
- the hash value of the transaction information that is, the current hash value
- TxState 1 to TxState n represent the transaction status values that the light node maintains for each transaction information received.
- the transaction status value of the light node is represented by TxState 0 , which is the initial value randomly generated by the light node Transaction status value.
- TxState 0 the initial value randomly generated by the light node Transaction status value.
- the light node receives the first transaction information, it updates TxState 0 to TxState 1 .
- TxState 1 the initial value randomly generated by the light node Transaction status value.
- the light node receives the second transaction information it updates TxState 1 to TxState 2 , and so on.
- the light node's transaction status value is updated to TxState n .
- TxState 1 to TxState n are also the transaction status values maintained by the light node for each received transaction information sent by the target account.
- TxState 1 to TxState n represent the target transactions corresponding to the first to nth transaction information respectively status value.
- the target account When the blockchain network initialization is completed, the target account will initiate a transaction, and accordingly, the light node will receive the transaction information sent by the target account. Therefore, before the light node receives the transaction information sent by the target account for the first time, that is, the initialization stage of the blockchain network, the light node will randomly generate the initial transaction status value. In other words, during the initialization phase of the blockchain network, that is, at the 0th block, the light node randomly generates an initial transaction status value, which is the transaction maintained by the light node at the 0th block status value.
- the initial transaction status value is a preset common sense of any prime number, for example represented by g. The embodiment of the present application does not limit the specific value of the arbitrary prime number.
- TxState 0 is the initial transaction state value, which is a preset constant of any prime number, there is the following formula (1):
- the obtained current hash value H(T 1 ) can be expressed by the following formula (2):
- the target transaction state value (ie, the target transaction state value TxState 1 corresponding to the first transaction information) generated according to the current hash value, the preset update algorithm, and the current transaction state value (ie, the initial transaction state value) can be expressed as follows (3) means:
- the preset update algorithm and the current transaction state value that is, the transaction state value corresponding to the transaction information from T i-1
- the target transaction state value TxState i of the i-th transaction information is obtained as follows: 5) As shown:
- TxState i-1 represents the current transaction status value when the i-th transaction information is received
- H(T i ) represents the current hash value of the i-th transaction information
- TxState i represents the corresponding The target transaction state value
- the symbol "mod" represents the modulo operation
- N represents the target parameter.
- the corresponding target transaction state value that is, the transaction state value TxState n currently maintained by the light node, can be shown in the following formula (6) :
- the expression shown in formula (6) is the preset update algorithm, and the power of the initial transaction status value g, that is, H(T 1 )*H(T 2 )*...*H(T n ) can be is defined as the objective feature function.
- N represents the target parameter, wherein the value of N is the product of the first parameter and the second parameter, and the first parameter and the second parameter are prime numbers to each other, for example, the first parameter and the second parameter are respectively two prime number.
- the first parameter and the second parameter are represented by p and q respectively, the following formula (7) exists:
- values of the first parameter and the second parameter may be set according to actual conditions.
- the first parameter and the second parameter can use larger prime numbers.
- Txstate 5 g 10000667*99997867*27648197*81480011*45224017 mod N (13)
- the transaction state value TxState n implicitly includes n transaction information.
- the transaction information received by the light node can be fed back through the transaction status value of the light node, that is, the transaction status value can represent the transaction information that the light node has received. Therefore, light nodes do not need to save transaction information, but only need to update the transaction status value according to the transaction information and the preset update strategy, so as to achieve the purpose of feeding back the transaction information it has received by maintaining the transaction status value.
- the transaction status value can be stored in only a few megabytes of space, and does not require a large storage space.
- the transaction state value TxState n is a value smaller than the target parameter N.
- the target parameter N can be the product of two prime numbers p and q.
- the maximum prime number is 2 57885161 -1 bits. Therefore, the transaction state value TxState n needs a maximum of 57885161 bits to store, so its storage capacity will not exceed 7MB. Therefore, for a light node, it only needs 7MB of storage space to realize block verification through the block verification method provided by the embodiment of this application.
- FIG. 6 is a schematic flowchart of another block verification method provided by the embodiment of the present application. As shown in Figure 6, the block verification provided by the embodiment of the present application is applied to light nodes in the blockchain network, and the method includes:
- step S301 The implementation, principle, and technical effect of step S301 are similar to those in FIG. 4 .
- S302 Receive the block to be verified sent by the target full node, and determine whether the block to be verified meets the first condition of the preset consensus mechanism.
- the target full node is elected among the full nodes of the blockchain network.
- step S302 are similar to the implementation, principle and technical effect of step S101.
- step S101 for details, please refer to the foregoing description, which will not be repeated here.
- judging whether all the target verification transaction information included in the block to be verified meets the target conditions can be equivalent to judging whether all the transaction information to be verified included in the block to be verified exists in the transaction maintained by it status value. Since the transaction state value TxState n involves the modulo operation of the finite field, it is impossible to prove the existence of its factors, but the non-existence of the factors can be proved in reverse. In other words, to determine that all the transaction information to be verified exists in the transaction state value TxState n , it is only necessary to determine that it is not true that any of the transaction information to be verified does not exist in the transaction state value TxState n .
- the following steps S303 to S306 describe in detail how to realize all the transaction information to be verified included in the block to be verified by judging whether any transaction information to be verified in the block to be verified does not exist in the transaction state value TxState n . Judgment on whether all meet the target conditions.
- S304 Determine whether the hash value of any transaction information to be verified has a prime number relationship with the target feature value.
- a light node Every time a light node receives a transaction information to update the transaction status value, it will obtain the hash value of the current transaction information received. In other words, the light node obtains the hash value of each transaction information it receives, That is, the light node has obtained each current hash value. Therefore, the light node can obtain the target feature value according to each current hash value and the target feature function, and the target feature value is represented by W n , then there is the following formula (14):
- H(T 1 ), H(T 2 ), ..., H(T n ) respectively represent the current hash values
- H(T 1 )* H(T 2 )*...*H(T n ) represents the target feature function, which is obtained based on a preset update algorithm
- W n represents the target feature value obtained through each current hash value and the target feature function.
- Hash(T') or Hash(T') represents the hash value of any transaction information to be verified
- W n the values represented by Hash(T') and W n are mutually prime numbers, it means that Hash(T' ) is not divisible by W n .
- Hash(T') cannot be divisible by W n , that is, Hash(T') is not a factor of TxState n power, that is, any transaction information T' to be verified does not exist in In the transaction state value TxState n
- the factor of the power of TxState n is the power of the preset common sense g in formula (6), which is the value represented by the target characteristic function W n . That is to say, if the values represented by Hash(T') and W n are mutually prime numbers, it is equivalent to the fact that any transaction information T' to be verified does not exist in the transaction state value TxState n .
- the hash value of any transaction information to be verified does not have a prime relationship with the target feature value, in other words, if the hash value of any transaction information to be verified can be divisible by the target feature value, then the The hash value is a factor of the power of the transaction status value, that is, any transaction information to be verified exists in the transaction status value, so all transaction information to be verified meets the target conditions.
- FIG. 7 is a schematic flowchart of another block verification method provided by the embodiment of the present application. As shown in Figure 7, the embodiment of this application includes:
- the target condition function is generated by the hash value of any transaction information to be verified and the target feature value.
- the target condition function is generated by the hash value Hash(T′) of any transaction information to be verified and the target feature value.
- the target condition function shown in the following formula (19) can be generated from the hash value Hash(T′) of any transaction information to be verified and the target feature value:
- the target condition function represented by formula (19) has an integer Solve ⁇ x,y>.
- the target conditional function represented by formula (19) does not have an integer solution ⁇ x, y>.
- judging whether the hash value of any transaction information to be verified has a prime relationship with the target feature value can be realized by judging whether the target condition function has an integer solution.
- the light node determines that there is an integer solution to the target condition function generated by the hash value of any transaction information to be verified and the target eigenvalue, it means that the hash value of any transaction information to be verified and the target eigenvalue are both prime numbers relation. Conversely, if the light node determines that there is no integer solution to the target condition function generated by the hash value of any transaction information to be verified and the target eigenvalue, it indicates that the hash value of any transaction information to be verified and the target eigenvalue are not compatible. is a prime number relationship.
- the light node After the light node receives the block to be verified sent by the target full node, it first verifies whether the difficulty value of the block to be verified is correct or not to determine whether the block to be verified meets the requirements of the preset consensus mechanism. primary condition. If the difficulty value is correct, further verify the validity of the block to be verified to complete the block verification. Among them, the light node can verify the validity of the block to be verified based on the transaction status value it maintains. Specifically, the light node determines whether there is an integer solution to the target conditional function generated by the hash value of any transaction information to be verified included in the block to be verified and the target feature value.
- step S307 can be executed after step S305.
- step S308 may be executed after step S306.
- S307 The block to be verified fails verification, and first feedback information is generated.
- the first feedback information is used to instruct the light node to reject the block to be verified.
- the block to be verified passes the verification, records the block to be verified and sends verification information to the target full node.
- the block to be verified has not passed the verification, and the light node can instruct itself to reject the block to be verified by generating the first feedback information.
- the block to be verified has passed the verification, and then the light node will record the block to be verified and send the verification information to the target full node.
- the target full node receives a certain amount of verification information, it means that it has completed the on-chain of the block to be verified.
- the block verification method provided by the embodiment of this application is applied to light nodes in the blockchain network.
- the light node receives the transaction information sent by the target account, it updates the transaction status value according to the preset update strategy and the current received transaction information.
- the light node after receiving the block to be verified sent by the target full node, the light node first determines whether the block to be verified meets the first condition of the preset consensus mechanism, and if so, obtains the target feature value according to each current hash value and the target feature function, And by judging whether the hash value of any transaction information to be verified has a prime relationship with the target characteristic value, it is determined whether all the transaction information to be verified meets the target condition.
- the hash value of any transaction information to be verified has a prime relationship with the target feature value, all transaction information to be verified does not meet the target condition. And if the hash value of any transaction information to be verified and the target characteristic value are not prime numbers, then all the transaction information to be verified meets the target conditions, and the block to be verified passes the verification, and the light node will record the block to be verified and send it to The target full node sends verification information.
- the light node updates the transaction status value every time it receives the transaction information, so as to replace the storage of the full amount of transaction information by maintaining the transaction status value, and further based on the maintained transaction status value, through Judging whether the hash value of any transaction information to be verified has a prime relationship with the target characteristic value, to realize whether all the transaction information to be verified included in the block to be verified meets the target conditions, and to achieve the verification of the block to be verified.
- block verification can be performed without storing a full amount of transaction information, making it possible for blockchain nodes to run on lightweight terminal devices.
- FIG. 8 is a schematic flowchart of another block verification method provided by the embodiment of the present application. As shown in Figure 8, the embodiment of this application includes:
- S401 Generate target data according to all transaction information to be verified and target feature functions.
- S402 Update the current transaction status value according to the target data, the target characteristic value and the preset characteristic function, so as to delete all transaction information to be verified.
- the current transaction status value of the light node needs to be updated to delete the block to be verified that has been verified from the transaction status value maintained by the light node
- the transaction information involved that is, delete all the transaction information to be verified included in the block to be verified.
- the target data W m shown in the following formula (20) can be generated based on the target characteristic function and all transaction information to be verified:
- H(T i ) (the value of i ranges from 1 to m) represents the hash value of all transaction information to be verified starting from m in the block to be verified, and the target data is based on all transaction information to be verified starting from m
- the hash value and the target feature function are obtained.
- the target eigenvalue W n is shown in the aforementioned formula (14).
- the preset characteristic function is shown in the following formula (21):
- the final transaction state value TxRoot nm is generated through the target data, the target characteristic value and the preset characteristic function shown in formula (21), so as to update the current transaction state value TxState n of the light node after block verification is completed as
- the final transaction state value TxRoot nm through which the final transaction state value TxRoot nm indicates that the light node has deleted all m transaction information included in the block to be verified from the transaction state value TxState n , and then can continue Receive new transaction information.
- target data is generated according to all transaction information to be verified and the target feature function, and the target data and target feature value
- the preset feature function generates the final transaction status value to update the current transaction status value to the final transaction status value, and delete all transactions to be verified included in the verified block from the transaction status value of the light node information. It can be seen that based on the transaction status value maintained by it, the problem of duplication of transaction information can be prevented.
- the transaction status value maintained by it is updated and then new transaction information is received again, which can ensure that the storage space of the light node will not be affected by the received transaction information and the area to be verified. It changes with the continuous accumulation of blocks, which is more conducive to the operation of blockchain nodes in lightweight terminal devices.
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Economics (AREA)
- Signal Processing (AREA)
- Development Economics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请提供一种区块验证方法，该区块验证方法应用于区块链网络中的轻节点。首先，轻节点接收目标全节点发送的待验证区块并确定待验证区块是否满足预设共识机制的首要条件，若满足，轻节点判断待验证区块包括的所有待验证交易信息是否都符合目标条件，目标条件根据交易状态值获得，而交易状态值用于表征轻节点已接收到的交易信息。若轻节点确定所有待验证交易信息都符合目标条件，则确定待验证区块通过验证，从而轻节点基于交易状态值实现对待验证区块的区块验证，无需存储全量的交易信息，为区块链节点运行于轻量化终端设备提供了可能。
Description
本申请要求于2021年09月22日提交中国专利局、申请号为202111104734.0、申请名称为“区块验证方法”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
本申请涉及金融科技(Fintech)技术领域，尤其涉及一种区块验证方法。
随着计算机技术以及互联网技术的快速发展，金融科技(Fintech)作为金融与科技深度融合的产物，目前正成为金融行业创新发展的热点，例如，区块链技术在金融行业已被广泛使用。
区块链利用块链式数据结构验证与存储数据，并基于分布式节点共识机制生成和更新数据，还利用密码学的方式保证数据传输及访问的安全，以及利用由自动化脚本代码组成的智能合约进行编程及操作数据。因此，区块链提供了高度一致的分布式账本。其中，基于共识机制，任何参与节点独立修改自身账本都无法对整个分布式网络造成影响，这使得区块链具备不可篡改性。在共识机制的实现过程中，参与共识的节点需要进行区块验证，以当验证通过记录区块。
然而，在区块验证中，除过验证交易签名的正确性，还要确保交易有效性，即需要基于之前的区块(即交易)进行验证并实时更新默克尔树状态，可见，参与共识的节点需拥有完整路径上的所有交易信息才能完成区块验证。目前，参与共识的节点均为全节点，换言之，全节点上保存了区块链网络的全量数据。全节点一般为共识和挖矿节点。但在实际的区块链应用中，大众或者中小机构参与区块链网络的诉求也越来越强，但大众或者中小机构所涉及的例如智能终端、个人电脑以及传感器等轻量化终端设备，由于其存储开销有限而无法全量存储所有交易信息，进而无法对交易有效性进行验证来完成区块验证，从而导致轻量化终端设备无法参与区块链网络的正常运行。
发明内容
本申请提供一种区块验证方法，用于为轻量化终端设备提供一种无需存储全量交易信息也可进行的区块验证方法。
本申请提供一种区块验证方法，应用于区块链网络中的轻节点；所述方法，包括：
接收目标全节点发送的待验证区块，并确定所述待验证区块是否满足预设共识机制的首要条件，所述目标全节点是在所述区块链网络的全节点中选举得到；
若是，判断所述待验证区块包括的所有待验证交易信息是否都符合目标条件，所述目标条件根据交易状态值获得，所述交易状态值用于表征所述轻节点已接收到的交易信息；
若确定所述所有待验证交易信息都符合所述目标条件，则所述待验证区块通过验证。
本申请提供一种区块验证方法，该区块验证方法应用于区块链网络中的轻节点。首先，轻节点接收目标全节点发送的待验证区块并确定待验证区块是否满足预设共识机制的首要条件，若满足，轻节点判断待验证区块包括的所有待验证交易信息是否都符合目标条件，目标条件根据交易状态值获得，而交易状态值用于表征轻节点已接收到的交易信息。若轻节点确定所有待验证交易信息都符合目标条件，则确定待验证区块通过验证，从而轻节点基于交易状态值实现对待验证区块的区块验证，无需存储全量的交易信息，为区块链节点运行于轻量化终端设备提供了可能。
图1为本申请实施例提供的一种应用场景示意图；
图2为本申请实施例提供的一种区块验证方法的流程示意图；
图3为本申请实施例提供的另一种区块验证方法的流程示意图；
图4为本申请实施例提供的再一种区块验证方法的流程示意图；
图5为本申请实施例提供的一种交易状态值更新过程示意图；
图6为本申请实施例提供的又一种区块验证方法的流程示意图；
图7为本申请实施例提供的又一种区块验证方法的流程示意图；
图8为本申请实施例提供的又一种区块验证方法的流程示意图。
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的方法和装置的例子。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
在区块链网络中，基于共识机制，任何参与节点独立修改自身账本都无法对整个分布式网络造成影响，这使得区块链具备不可篡改性。也正因为如此，在共识机制的实现过程中，参与共识的节点需要进行区块验证，以当验证通过时记录区块。然而，在区块验证中，除过验证交易签名的正确性，还要确保交易的有效性，即需要基于之前的区块(即交易)进行验证并实时更新默克尔树状态。可见，参与共识的节点需要拥有完整路径上的所有交易信息才能完成区块验证。目前，参与共识的节点均为全节点，换言之，全节点上保存了区块链网络的全量数据。全节点一般为共识和挖矿节点。但在实际的区块链应用中，大众或者中小机构参与区块链网络的诉求也越来越强，但大众或者中小机构所涉及的例如智能终端、个人电脑以及传感器等轻量化终端设备，由于其存储开销有限而无法全量存储所有交易信息，进而无法对交易有效性进行验证 来完成区块验证，从而导致轻量化终端设备无法参与区块链网络的正常运行。
针对现有技术中存在的上述问题，本申请提供一种区块验证方法，该区块验证方法应用于区块链网络中的轻节点。本申请提供的区块链验证方法的发明构思在于：轻节点接收目标全节点发送的待验证区块，首先判断待验证区块是否满足预设共识机制的首要条件，在当满足时，进一步判断待验证区块包括的所有待验证交易信息是否都符合目标条件，其中，目标条件是根据交易状态值获得，而交易状态值可以表征该轻节点已接收到的交易信息，从而当所有待验证交易信息都符合目标条件时，确定待验证区块通过验证。可见，本申请提供的区块验证方法中，在对待验证区块是否满足预设共识机制的首要条件进行判断之后，基于交易状态值即可实现对待验证区块的验证，不同于现有技术需进行默克尔树证明等步骤，无需存储全量的交易信息即可实现区块验证，为区块链节点运行于轻量化终端设备提供可能。并且，由于交易状态值只需较小空间便可实现存储，存储空间还不会随着待验证区块的增多而增大，因而更加有利于轻量化终端设备在区块链网络中的应用。
以下，对本申请实施例的示例性应用场景进行介绍。
图1为本申请实施例提供的一种应用场景示意图，如图1所示，区块链网络包含多个区块链节点，例如区块链节点11、区块链节点12、区块链节点13以及区块链节点14，其中区块链节点11至区块链节点14均为全节点，全节点是指需存储区块链网络的全量交易信息，一般为共识节点和挖矿节点。其中，轻节点15中所配置的处理器通过执行本申请实施例提供的区块验证方法，无需存储全量的交易信息即可实现对待验证区块的验证，在验证通过时可参与至区块链网络中进行区块链的正常运行。轻节点15可以例如移动终端、个人电脑或者传感器等存储开销十分有限的轻量化终端设备，移动终端可以例如智能手机、智能手表等可穿戴设备。
需要说明的是，图1中示意性列举了区块链网络中全节点的数量为四个，轻节点的数量为一个。在实际工况中，对于区块链网络中全节点和轻节点的数量不作限定，具体由实际情况决定。另外，图1中轻节点15以智能手机为例示出。
需要说明的是，上述应用场景仅仅是示意性的，本申请实施例提供的区块验证方法包括但不仅限于上述应用场景。
图2为本申请实施例提供的一种区块验证方法的流程示意图。如图2所示，本申请实施例提供的区块验证方法应用于区块链网络中的轻节点，该方法包括：
S101：接收目标全节点发送的待验证区块，并确定待验证区块是否满足预设共识机制的首要条件。
其中，目标全节点是在区块链网络的全节点中选举得到。
轻节点接收目标全节点发送的待验证区块，待验证区块由目标全节点根据业务需要从自身交易池中选择交易信息并对选择到的交易信息进行打包形成的。例如，目标全节点打包形成新的区块，需将新的区块广播给区块链网络中的其他节点，轻节点则可以接收到目标全节点发送的该新的区块，该新的区块即为待验证区块。
目标全节点是从区块链网络的全节点中选举得到的。例如，区块链网络中的全节点执行交易信息时，需基于预设共识机制，从所有全节点中选举出一个全节点以对外广播区块，被选举出的全节点即被定义为目标全节点。比如，预设共识机制以工作量证明(Proof of Work，简称PoW)共识机制为例，从全节点选举目标全节点的方式可以通过计算哈希值实现。例如，每个全节点都会计算一个符合难度条件的哈希值，当某一全节点首个计算出该哈希值，则该全节点被选举为目标全节点，其中，符合难度条件的哈希值也可称为困难值。进而该目标全节点会将困难值和其根据业务需求从自身交易池中选择出的交易信息进行打包形成上述新的区块，也即待验证区块，并将该待验证区块广播给其他节点。
轻节点接收到待验证区块后，会确定待验证区块是否满足预设共识机制的首要条件。
例如，假设预设共识机制为PoW共识机制，则本步骤S101中轻节点确定待验证区块是否满足预设共识机制的首要条件可能的实现方式如图3所示。图3为本申请实施例提供的另一种区块验证方法的流程示意图。如图3所示，本申请实施例包括：
S1011：验证待验证区块的困难值是否正确。
其中，PoW共识机制的首要条件包括困难值。
S1012：若是，确定待验证区块满足首要条件。
S1013：若否，确定待验证区块未通过验证，并生成第二反馈信息。
其中，第二反馈信息用于指示轻节点拒绝待验证区块。
轻节点接收到待验证区块后，若预设共识机制为PoW共识机制，预设共识机制的首要条件，也即PoW共识机制的首要条件则包括困难值。因而，轻节点确定待验证区块是否满足预设共识机制的首要条件，也就是轻节点验证待验证区块的困难值是否正确，若正确，则确定待验证区块满足首要条件。反之，若不正确，则待验证区块不满足首要条件，则可确定待验证区块未通过验证，并且，轻节点可以生成第二反馈信息，通过第二反馈信息指示轻节点拒绝待验证区块。
本申请实施例提供的区块验证方法，轻节点接收目标全节点发送的待验证区块，确定待验证区块是否满足预设共识机制的首要条件。例如，假设预设共识机制为PoW共识机制，轻节点通过验证待验证区块的困难值是否正确确定其是否满足预设共识机制的首要条件。若正确，则确定待验证区块满足预设共识机制的首要条件。反之，若不正确，则表明待验证区块未通过验证，并生成第二反馈信息，以指示轻节点拒绝待验证区块。从而为待验证区块完成区块验证提供前提条件。
需要说明的是，确定待验证区块是否满足预设共识机制的首要条件可以理解为验证待验证区块对应交易签名的正确性，显然，预设共识机制包括但不限定于PoW共识机制。当预设共识机制为其他共识机制时，则可以通过其他的预设共识机制所对应的具体方式验证交易签名的正确性以判断待验证区块是否满足预设共识机制的首要条件。
通过上述描述可知，在验证困难值正确时，则确定待验证区块满足预设共识机制的首要条件时，进一步执行步骤S102。而若验证困难值不正确，则表明待验证区块不满足预设共识机制的首要条件，待验证区块未通过验证。
S102：若是，判断待验证区块包括的所有待验证交易信息是否都符合目标条件。
其中，目标条件根据交易状态值获得，交易状态值用于表征轻节点已接收到的交易信息。
在确定待验证区块满足预设共识机制的首要条件后，进一步判断待验证区块包括的所有待验证交易信息是否都符合目标条件，以对待验证区块包括的待验证交易信息的有效性进行验证，以此完成区块验证。
例如，在本申请实施例中，轻节点可以通过交易状态值来反馈其已接收到的交易信息，并根据其维护的交易状态值获得目标条件，进而则可以通过判断待验证区块包括的所有待验证交易信息是否都符合目标条件，来实现对待验证区块所包括的所有待验证交易信息有效性的验证。
其中，待验证交易信息是指待验证区块中所包含的各交易信息，即目标全节点打包形成待验证区块时所选择的交易信息，例如，目标全节点将m(1≤m≤n)起交易信息打包形成了待验证区块，假设待验证区块以B
1表示，那么B
1中的交易信息也即所有待验证交易信息可以通过如下集合表示：
{T
1,T
2,T
3,…,T
m},(1≤m≤n)
轻节点判断待验证区块B
1包括的所有待验证交易信息是否都符合目标条件，其中，目标条件根据轻节点所维护的交易状态值获得，而其维护的交易状态值可以反馈其接收到交易信息。鉴于此，判断待验证区块包括的所有待验证交易信息是否都符合目标条件中的该目标条件，可以理解为，判断待验证区块包括的该m起待验证交易信息是否均存在于其维护的交易状态值中。换言之，若m起待验证交易信息均存在于其所维护的交易状态值中，则表明待验证区块包括的所有待验证交易信息都符合目标条件。反之，若m起待验证交易信息中任意一起都不存在于其维护的交易状态值中，则表明待验证区块包括的所有待验证交易信息都不符合目标条件。
在经过判断后，若判断出待验证区块包括的所有待验证交易信息都符合目标条件，则表明待验证区块包括的所有待验证交易信息的有效性通过验证，即执行步骤S103。反之，若确定所有待验证交易信息都不符合目标条件，即执行步骤S104。
S103：若确定所有待验证交易信息都符合目标条件，则待验证区块通过验证。
S104：若确定所有待验证交易信息都不符合目标条件，则待验证区块未通过验证，并生成第一反馈信息。
其中，第一反馈信息用于指示轻节点拒绝待验证区块。
若轻节点确定出待验证区块包括的所有待验证交易信息都符合目标条件，则表明轻节点对待验证区块包括的所有待验证交易信息的交易有效性验证通过，再结合之前待验证区块满足预设共识机制的首要条件的前提，可以确定待验证区块通过验证，完成对待验证区块的验证。
反之，若确定所有待验证交易信息都不符合目标条件，则表明轻节点对待验证区块包括的所有待验证交易信息的交易有效性验证未通过，则可以确定待验证区块未通过验证。进而还生成第一反馈信息，通过第一反馈信息指示轻节点拒绝待验证区块。
可选地，若确定待验证区块通过验证，则轻节点记录待验证区块并向目标全节点发送验证信息，通过验证信息使得目标全节点获知轻节点对于待验证区块的验证已通过。在当目标全节点接收一定数量的验证信息后即可完成对待验证区块的上链。目标全节点接收到一定数量的验证信息即为目标全节点接收到超过预设数量的验证信息。例如，每个对于交易信息有效性验证通过的节点均会向目标全节点反馈验证信息，当目标全节点接收到超过其发送待验证区块的节点总数的51％数量的验证信息时，即目标全节点接收到超过预设数量的验证信息，对于目标全节点而言，其完成了对待验证区块的上链。
本申请实施例提供的区块验证方法应用于区块链网络中的轻节点。首先，轻节点接收 目标全节点发送的待验证区块，并确定待验证区块是否满足预设共识机制的首要条件。若满足，轻节点判断待验证区块包括的所有待验证交易信息是否都符合目标条件，该目标条件根据轻节点所维护的交易状态值获得，而交易状态值用来表征轻节点已接收到的交易信息，轻节点则无需存储全量的交易信息。经过判断，若确定待验证区块包括的所有待验证交易信息都符合目标条件，则待验证区块通过验证。本申请实施例提供的区块验证方法中，轻节点在确定待验证区块满足预设共识机制的首要条件时，基于其所维护的交易状态值判断待验证区块包括的所有待验证交易信息是否都符合目标条件，以达到对待验证区块的验证。对轻节点而言无需存储全量的交易信息也可以实现区块验证，为区块链节点运行于轻量化终端设备提供可能。
在上述实施例的描述中，交易状态值反馈轻节点已接收到的交易信息。具体地，在接收目标全节点发送的待验证区块之前，每当轻节点接收到目标账户发送的交易信息，根据预设更新策略以及当前次接收到的交易信息更新交易状态值，从而通过所维护的交易状态值反馈其已接收到的交易信息。
例如，当区块链网络初始化完成或，则会有多起交易发起，目标账户会选择区块链网络中的任何一个区块链节点发送交易信息。当区块链网络中的全节点接收到目标账户发送的交易信息后，会将其放入自身交易池。而对于轻节点而言，该轻节点不需保存交易信息，而是根据交易信息以及预设更新策略更新交易状态值，通过维护交易状态值代替存储全量的交易信息。
在一种可能的设计中，轻节点根据预设更新策略以及当前次接收到的交易信息更新交易状态值可能的实现方式如图4所示。图4为本申请实施例提供的再一种区块验证方法的流程示意图。如图4所示，本申请实施例提供的区块验证方法，包括：
S201：获取当前哈希值。
其中，当前哈希值为当前次接收到的交易信息的哈希值。
S202：根据当前哈希值、预设更新算法以及当前的交易状态值生成目标交易状态值。
其中，预设更新算法包括目标参数以及目标特征函数，目标参数为互为质数的第一参数和第二参数的乘积。
S203：利用预设更新方式以及目标交易状态值更新交易状态值。
其中，预设更新策略包括预设更新算法以及预设更新方式。
轻节点每当接收到目标账户发送的交易信息，获取当前次接收到的交易信息的哈希值，即获取当前哈希值。然后根据当前哈希值、预设更新算法以及当前的交易状态值生成目标交易状态值，再利用预设更新方式和目标交易状态值更新交易状态值，例如所采用的预设更新方式为将当前的交易状态值更新为目标交易状态值，从而完成对交易状态值的更新。
图5为本申请实施例提供的一种交易状态值更新过程示意图。如图5所示，假设以T
1至T
n表示轻节点接收到目标账户发送的第1至第n起交易信息，H(T
1)至H(T
n)分别表示第1起至第n起交易信息的哈希值，即各当前哈希值，TxState
1至TxState
n则表示轻节点针对接收到的每起交易信息所对应维护的各交易状态值。
继续参照图5，在区块链网络初始化阶段，也即在轻节点首次接收目标账户发送的交易信息之前，轻节点的交易状态值以TxState
0表示，该TxState
0为轻节点随机生成的初始的交易状态值。轻节点接收到第1起交易信息，则将TxState
0更新为TxState
1。轻节点接收 到第2起交易信息，则将TxState
1更新为TxState
2，依次类推，轻节点接收到第n起交易信息，轻节点的交易状态值则更新为TxState
n。TxState
1至TxState
n也即轻节点针对每次接收到的目标账户发送的交易信息所对应维护的交易状态值，TxState
1至TxState
n分别表示第1起至第n起交易信息各自对应的目标交易状态值。
当区块链网络初始化完成后会有目标账户发起交易，相应地，轻节点会接收目标账户发送的交易信息。因而，在轻节点首次接收目标账户发送的交易信息之前，也即区块链网络的初始化阶段，轻节点会随机生成初始的交易状态值。换言之，在区块链网络的初始化阶段，也即第0个区块时，轻节点随机生成初始的交易状态值，该初始的交易状态值就是第0个区块时轻节点所对应维护的交易状态值。在本申请实施例中，该初始的交易状态值为任意质数的预设常识，例如以g表示，对于该任意质数的具体取值，本申请实施例不作限定。
由于TxState
0为初始的交易状态值，其为任意质数的预设常数，即存在如下公式(1)：
TxState
0＝g (1)
对于第1起交易信息T
1，获取的当前哈希值H(T
1)可以如下公式(2)表示：
H(T
1)＝Hash(T
1) (2)
则根据当前哈希值、预设更新算法以及当前的交易状态值(即初始的交易状态值)生成的目标交易状态值(即第1起交易信息对应的目标交易状态值TxState
1)可以如下公式(3)表示：
以此类推，对于第i(1≤i≤n)起交易信息，获取该T
i起交易信息的哈希值，即当前哈希值如公式(4)所示：
H(T
i)＝Hash(T
i)，(1≤i≤n) (4)
然后，根据H(T
i)、预设更新算法以及当前的交易状态值(即T
i-1起交易信息对应的交易状态值)得到第i起交易信息的目标交易状态值TxState
i如下公式(5)所示：
其中，TxState
i-1表示接收到第i起交易信息时的当前的交易状态值，H(T
i)表示第i起交易信息的当前哈希值，TxState
i表示接收到第i起交易信息对应的目标交易状态值，将当前的交易状态值TxState
i-1更新为目标交易状态值TxState
i完成当前次交易状态值的更新，符号“mod”表示取模运算，N表示目标参数。
在上述描述的基础上，进一步地，若轻节点接收到n起交易，则所对应的目标交易状态值，也就是轻节点当前所维护的交易状态值TxState
n，可以如下公式(6)所示：
其中，如公式(6)所示的表达式即为预设更新算法，初始的交易状态值g的幂次方即H(T
1)*H(T
2)*…*H(T
n)可以被定义为目标特征函数。
另外，上述的N表示目标参数，其中该N的取值为第一参数和第二参数的乘积，并且第一参数和第二参数互为质数，例如第一参数和第二参数分别为两大质数。假设第一参数和第二参数分别采用p和q表示，则存在如下公式(7)：
N＝p*q (7)
其中，第一参数和第二参数的取值可以根据实际情况设置。为了便于轻节点维护交易 状态值，第一参数和第二参数可以采用数值较大的质数。
例如，假设n的取值为5，即轻节点接收到目标账户发送的5起交易信息，并假设每起交易信息的哈希值分别如下公式(8)至(12)所示：
H(T
1)＝Hash(T
1)＝10000667 (8)
H(T
2)＝Hash(T
2)＝99997867 (9)
H(T
3)＝Hash(T
3)＝27648197 (10)
H(T
4)＝Hash(T
4)＝81480011 (11)
H(T
5)＝Hash(T
5)＝45224017 (12)
则轻节点接收到的目标账户发送的5起交易信息后所维护的交易状态值TxState
5如下公式(13)所示：
Txstate
5＝g
10000667*99997867*27648197*81480011*45224017mod N (13)
通过上述实施例描述以及举例说明可知，交易状态值TxState
n隐式的包含了n起交易信息。换言之，通过轻节点的交易状态值可以反馈出轻节点所接收到的交易信息，即交易状态值可以表征轻节点已接收到的交易信息。因而，轻节点无需保存交易信息，只需根据交易信息和预设更新策略更新交易状态值，达到通过维护交易状态值来反馈其已接收到的交易信息的目的。
交易状态值只需几兆空间便可存储，无需较大存储空间。例如，交易状态值TxState
n为一小于目标参数N的数值。而目标参数N可以为两大质数p和q的乘积，目前最大质数为2
57885161-1位，因此交易状态值TxState
n最多需要57885161bit即可存储，可见其存储容量不会超过7MB。因此对于轻节点而言，其只需要7MB的存储空间便可通过本申请实施例提供的区块验证方法实现区块验证。
图6为本申请实施例提供的又一种区块验证方法的流程示意图。如图6所示，本申请实施例提供的区块验证应用于区块链网络中的轻节点，该方法包括：
S301：每当接收到目标账户发送的交易信息，根据预设更新策略以及当前次接收到的交易信息更新交易状态值。
步骤S301的实现方式、原理以及技术效果与图4的实现方式、原理以及技术效果相类似，详细内容可参考前述描述，在此不再赘述。
S302：接收目标全节点发送的待验证区块，并确定待验证区块是否满足预设共识机制的首要条件。
其中，目标全节点是在区块链网络的全节点中选举得到。
步骤S302的实现方式、原理以及技术效果与步骤S101的实现方式、原理以及技术效果相类似，详细内容可参考前述描述，在此不再赘述。
通过前述实施例的描述可知，对于判断待验证区块包括的所有目标验证交易信息是否都符合目标条件，可以等同于判断待验证区块包括的所有待验证交易信息是否均存在于其维护的交易状态值。由于交易状态值TxState
n涉及有限域的取模运算，因而是无法证明其因子的存在性的，但是可以反向证明因子的不存在性。换言之，若要确定待验证交易信息均存在于交易状态值TxState
n中，只需确定待验证交易信息中的任意一起待验证交易信息都不存在于交易状态值TxState
n中是不成立的即可。
以下步骤S303至步骤S306，详细说明如何通过判断待验证区块中的任意一起待验证 交易信息都不存在于交易状态值TxState
n中是否成立，来实现对待验证区块包括的所有待验证交易信息是否都符合目标条件的判断。
S303：若是，根据各当前哈希值以及目标特征函数得到目标特征值。
S304：判断任意待验证交易信息的哈希值是否都与目标特征值互为质数关系。
S305：若是，则确定所有待验证交易信息都不符合目标条件。
S306：若否，则确定所有待验证交易信息都符合目标条件。
轻节点每接收到一起交易信息更新交易状态值时，均会获取到当前次接收到的交易信息的哈希值，换言之，轻节点获取了其所接收到的每起交易信息的哈希值，即轻节点获取了各当前哈希值。因而，轻节点根据各当前哈希值以及目标特征函数可以得到目标特征值，该目标特征值以W
n表示，则存在如下公式(14)：
其中，若轻节点接收到目标账户发送的n起交易信息，则H(T
1)、H(T
2)、…、H(T
n)分别表示各当前哈希值，H(T
1)*H(T
2)*…*H(T
n)表示目标特征函数，该目标特征函数基于预设更新算法得到，W
n则表示通过各当前哈希值以及目标特征函数得到的目标特征值。
进一步，通过判断任意待验证交易信息的哈希值是否与目标特征值互为质数关系来实现对所有待验证交易信息是否都符合目标条件的判断。
例如，假设以H(T')即Hash(T')表示任意待验证交易信息的哈希值，若Hash(T')与W
n各自表示的数值互为质数关系，则表明Hash(T')不能被W
n整除。结合公式(6)的表达式可知，若Hash(T')不能被W
n整除，即Hash(T')不为TxState
n幂次方的因子，也即任意待验证交易信息T'不存在于交易状态值TxState
n中，其中TxState
n幂次方的因子即公式(6)中预设常识g的幂次方，其为目标特征函数W
n所表示的数值。也就是说，若Hash(T')与W
n各自表示的数值互为质数关系成立，则相当于任意待验证交易信息T'不存在于交易状态值TxState
n中是成立的。故而，当判断任意待验证交易信息的哈希值与目标特征值都互为质数关系成立时，任意待验证交易信息T'不存在于交易状态值TxState
n中成立，则表明所有待验证交易信息都不符合目标条件。
反之，若任意待验证交易信息的哈希值都与目标特征值不互为质数关系，换言之，若任意待验证交易信息的哈希值都能被目标特征值整除，则任意待验证交易信息的哈希值是交易状态值的幂次方的因子，也即任意待验证交易信息存在于交易状态值中，故而，所有待验证交易信息都符合目标条件。
而判断任意待验证交易信息的哈希值是否都与目标特征值互为质数关系，可以通过确定目标条件函数是否存在整数解得以实现。在一种可能的设计中，步骤S304可能的实现方式如图7所示。图7为本申请实施例提供的又一种区块验证方法的流程示意图。如图7所示，本申请实施例包括：
S3041：确定目标条件函数是否存在整数解。
其中，目标条件函数由任意待验证交易信息的哈希值和目标特征值生成。
S3042：若是，则任意待验证交易信息的哈希值都与目标特征值均互为质数关系。
S3043：若否，则任意待验证交易信息的哈希值与目标特征值均非互为质数关系。
目标条件函数由任意待验证交易信息的哈希值Hash(T′)和目标特征值生成。
例如，对于任何整数a、b，如果a和b互质，则存在整数解<x,y>使得如下公式(15) 成立：
ax+by＝1 (15)
比如2和3互质，那么2x+3y＝1，显然存在整数解(-1，1)可使得公式(15)成立。
而对于整数a和b，如果a和b不互质，则意味着a和b存在最大公约数，假设最大公约数为c，且c为大于1的整数，并假设|a|＞|b|，则肯定存整数m和n使得如下公式(16)和(17)存在：
a＝m*c (16)
b＝n*c (17)
结合公式(16)和(17)则存在如下公式(18)：
如果ax+by＝1在a和b不互质的情况下还存在整数解，那么mx+ny一定为整数，但是由于c也为整数，所以1/c一定不为整数，所以mx+ny＝1/c一定不成立。故而可以得知，当a和b不互质的情况，ax+by＝1一定不存在整数解。
基于以上描述，则可以由任意待验证交易信息的哈希值Hash(T′)和目标特征值生成如下公式(19)所示的目标条件函数：
x*H(T′)+y*W
n＝1 (19)
其中，若表示任意待验证交易信息的哈希值H(T')即Hash(T')与表示目标特征值的W
n互为质数关系，则如公式(19)表示的目标条件函数存在整数解<x,y>。反之，若表示任意待验证交易信息的哈希值与表示目特征值的非互为质数关系，则如公式(19)表示的目标条件函数不存在整数解<x,y>。
因此，判断任意待验证交易信息的哈希值是否都与目标特征值互为质数关系，可以通过判断目标条件函数是否存在整数解得以实现。
故而，若轻节点确定出由任意待验证交易信息的哈希值和目标特征值所生成的目标条件函数存在整数解，则表明任意待验证交易信息的哈希值与目标特征值均互为质数关系。反之，若轻节点确定出由任意待验证交易信息的哈希值和目标特征值所生成的目标条件函数不存在整数解，则表明任意待验证交易信息的哈希值与目标特征值均不互为质数关系。
通过上述实施例的描述可知，轻节点接收到目标全节点发送的待验证区块后，首先对待验证区块的困难值正确与否进行验证以确定出待验证区块是否满足预设共识机制的首要条件。在困难值正确的情况下，进一步对待验证区块的有效性进行验证来完成区块验证。其中，轻节点在对待验证区块的有效性验证时，可以基于其维护的交易状态值进行。具体地，轻节点确定由待验证区块包括的任意待验证交易信息的哈希值以及目标特征值所生成的目标条件函数是否存在整数解。若存在整数解，则表明任意待验证交易信息的哈希值与目标特征值都互为质数关系，即目标特征值无法整除任意待验证交易信息的哈希值，任意待验证交易信息的哈希值不为交易状态值的幂次方的因子，所有待验证交易信息都不符合目标条件，则可在步骤S305后执行步骤S307。反之，若轻节点确定由待验证区块包括的任意待验证交易信息的哈希值以及目标特征值所生成的目标条件函数不存在整数解，则表明任意待验证交易信息的哈希值与目标特征值都非互为质数关系，即目标特征值可以整除任意待验证交易信息的哈希值，任意待验证交易信息的哈希值为交易状态值的幂次方的因子，则可以确定所有待验证交易信息都符合目标条件，则可以在步骤S306后执行步骤S308。
S307：待验证区块未通过验证，并生成第一反馈信息。
其中，第一反馈信息用于指示轻节点拒绝待验证区块。
S308：待验证区块通过验证，记录待验证区块并向目标全节点发送验证信息。
若所有待验证交易信息都不符合目标条件，则待验证区块未通过验证，轻节点可以通过生成第一反馈信息来指示自身拒绝待验证区块。
而若所有待验证交易信息都符合目标条件，则表明待验证区块通过验证，进而轻节点会记录待验证区块并向目标全节点发送验证信息。当目标全节点接收一定数量的验证信息后即表示其完成对待验证区块的上链。
本申请实施例提供的区块验证方法应用于区块链网络中的轻节点。轻节点每当接收到目标账户发送的交易信息，根据预设更新策略以及当前次接收到的交易信息更新交易状态值。并且，轻节点接收目标全节点发送的待验证区块后首先确定待验证区块是否满足预设共识机制的首要条件，若满足，则根据各当前哈希值以及目标特征函数得到目标特征值，并通过判断任意待验证交易信息的哈希值是否都与目标特征值互为质数关系，来确定所有待验证交易信息是否都符合目标条件。经过判断，若任意待验证交易信息的哈希值都与目标特征值互为质数关系，则所有待验证交易信息都不符合目标条件。而若任意待验证交易信息的哈希值与目标特征值都不互为质数关系，则所有待验证交易信息都符合目标条件，待验证区块通过验证，轻节点会记录待验证区块并向目标全节点发送验证信息。本申请实施例提供的区块验证方法，轻节点每当接收到交易信息时都更新交易状态值，从而通过维护交易状态值代替存储全量的交易信息，并进一步基于所维护的交易状态值，通过判断任意待验证交易信息的哈希值是否都与目标特征值互为质数关系，来实现待验证区块包括的所有待验证交易信息是否都符合目标条件的判断，达到对待验证区块的验证，从而无需存储全量的交易信息即可进行区块验证，为区块链节点运行于轻量化终端设备提供可能。
进一步地，为了避免交易信息发生重复即双花现象，轻节点确定待验证区块通过验证之后，还包括如图8所示步骤。图8为本申请实施例提供的又一种区块验证方法的流程示意图。如图8所示，本申请实施例包括：
S401：根据所有待验证交易信息以及目标特征函数生成目标数据。
S402：根据目标数据、目标特征值以及预设特征函数更新当前的交易状态值，以删除所有待验证交易信息。
在待验证区块通过验证后，为了防止交易信息发生重复现象，则需要对轻节点当前的交易状态值进行更新，以从轻节点所维护的交易状态值中删除已完成验证的待验证区块所涉及的交易信息，即删除待验证区块包括的所有待验证交易信息。
假设待验证区块包括m起待验证交易信息，因而可以基于目标特征函数以及所有待验证交易信息生成如下公式(20)所示的目标数据W
m：
其中，H(T
i)(i的取值从1至m)表示待验证区块中该m起的所有待验证交易信息的哈希值，目标数据则基于该m起的所有待验证交易信息的哈希值和目标特征函数得到。
目标特征值W
n如前述公式(14)所示。预设特征函数如下公式(21)所示：
其中，通过目标数据、目标特征值以及公式(21)所示的预设特征函数生成最终的交 易状态值TxRoot
n-m，以将轻节点在完成区块验证后的当前的交易状态值TxState
n更新为最终的交易状态值TxRoot
n-m，通过该最终的交易状态值TxRoot
n-m表征轻节点已从交易状态值TxState
n中删除了待验证区块所包括的所有m起待验证交易信息，进而则可再继续接收新的交易信息。
本申请实施例提供的区块验证方法，在待验证区块通过验证之后，为了防止交易信息发生重复，根据所有待验证交易信息以及目标特征函数生成目标数据，并根据该目标数据、目标特征值以及预设特征函数生成最终的交易状态值，以将当前的交易状态值更新为最终的交易状态值，从轻节点的交易状态值中删除通过验证的待验证区块所包括的所有待验证交易信息。可见，基于其所维护的交易状态值可以防止交易信息发生重复问题。并且，待验证区块通过验证后，对其所维护的交易状态值进行更新后再重新接收新的交易信息，可以保证轻节点的存储空间不会随着其接收到的交易信息和待验证区块的不断累计而发生变化，从而更加有利于区块链节点运行于轻量化终端设备中。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其他实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由权利要求书指出。
应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。
Claims (10)
- 一种区块验证方法，其特征在于，应用于区块链网络中的轻节点；所述方法，包括：接收目标全节点发送的待验证区块，并确定所述待验证区块是否满足预设共识机制的首要条件，所述目标全节点是在所述区块链网络的全节点中选举得到；若是，判断所述待验证区块包括的所有待验证交易信息是否都符合目标条件，所述目标条件根据交易状态值获得，所述交易状态值用于表征所述轻节点已接收到的交易信息；若确定所述所有待验证交易信息都符合所述目标条件，则所述待验证区块通过验证。
- 根据权利要求1所述的区块验证方法，其特征在于，在所述接收目标全节点发送的待验证区块之前，还包括：每当接收到目标账户发送的所述交易信息，根据预设更新策略以及当前次接收到的交易信息更新所述交易状态值。
- 根据权利要求2所述的区块验证方法，其特征在于，所述根据预设更新策略以及当前次接收到的交易信息更新交易状态值，包括：获取当前哈希值，所述当前哈希值为所述当前次接收到的交易信息的哈希值；根据所述当前哈希值、预设更新算法以及当前的交易状态值生成目标交易状态值，所述预设更新算法包括目标参数和目标特征函数，所述目标参数为互为质数的第一参数和第二参数的乘积；利用预设更新方式以及所述目标交易状态值更新所述交易状态值；其中，所述预设更新策略包括所述预设更新算法和所述预设更新方式。
- 根据权利要求3所述的区块验证方法，其特征在于，在所述轻节点首次接收所述目标账户发送的交易信息之前，还包括：随机生成初始的交易状态值，所述初始的交易状态值为任意质数的预设常数。
- 根据权利要求3或4所述的区块验证方法，其特征在于，所述判断所述待验证区块包括的所有待验证交易信息是否都符合目标条件，包括：根据各当前哈希值以及所述目标特征函数得到目标特征值；判断任意待验证交易信息的哈希值是否都与所述目标特征值互为质数关系；若是，则确定所述所有待验证交易信息都不符合所述目标条件；若否，则确定所述所有待验证交易信息都符合所述目标条件。
- 根据权利要求5所述的区块验证方法，其特征在于，所述判断任意待验证交易信息的哈希值是否都与所述目标特征值互为质数关系，包括：确定目标条件函数是否存在整数解，所述目标条件函数由所述任意待验证交易信息的哈希值和所述目标特征值生成；若是，则确定所述任意待验证交易信息的哈希值都与所述目标特征值均互为所述质数关系；若否，则确定所述任意待验证交易信息的哈希值与所述目标特征值均非互为所述质数关系。
- 根据权利要求1-6任一项所述的区块验证方法，其特征在于，若确定所述所有待验证交易信息都不符合所述目标条件，则所述待验证区块未通过验证，并生成第一反馈信息，所述第一反馈信息用于指示所述轻节点拒绝所述待验证区块。
- 根据权利要求1-7任一项所述的区块验证方法，其特征在于，若所述预设共识机制为PoW共识机制，所述确定所述待验证区块是否满足预设共识机制的首要条件，包括：验证所述待验证区块的困难值是否正确，所述PoW共识机制的首要条件包括所述困难值；若是，确定所述待验证区块满足所述首要条件；若否，确定所述待验证区块未通过验证，并生成第二反馈信息，所述第二反馈信息用于指示所述轻节点拒绝所述待验证区块。
- 根据权利要求6所述的区块验证方法，其特征在于，在确定所述待验证区块通过验证之后，还包括：根据所述所有待验证交易信息以及所述目标特征函数生成目标数据；根据所述目标数据、所述目标特征值以及预设特征函数更新当前的交易状态值，以删除所述所有待验证交易信息。
- 根据权利要求1-9任一项所述的区块验证方法，其特征在于，若确定所述待验证区块通过验证，则记录所述待验证区块并向所述目标全节点发送验证信息。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111104734.0 | 2021-09-22 | ||
| CN202111104734.0A CN113556238B (zh) | 2021-09-22 | 2021-09-22 | 区块验证方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2023045150A1 true WO2023045150A1 (zh) | 2023-03-30 |
Family
ID=78134539
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2021/140630 WO2023045150A1 (zh) | 2021-09-22 | 2021-12-22 | 区块验证方法 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN113556238B (zh) |
| WO (1) | WO2023045150A1 (zh) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113556238B (zh) * | 2021-09-22 | 2022-02-15 | 深圳前海微众银行股份有限公司 | 区块验证方法 |
| CN114244523A (zh) * | 2021-12-09 | 2022-03-25 | 东软集团股份有限公司 | 数据处理方法、装置和适配器 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108921556A (zh) * | 2018-07-02 | 2018-11-30 | 上海达家迎信息科技有限公司 | 一种区块链的验证方法、装置、设备及存储介质 |
| CN108985772A (zh) * | 2018-07-02 | 2018-12-11 | 上海达家迎信息科技有限公司 | 一种区块链的验证方法、装置、设备及存储介质 |
| CN110602116A (zh) * | 2019-09-19 | 2019-12-20 | 腾讯科技（深圳）有限公司 | 基于区块链的数据验证方法、装置和计算机可读存储介质 |
| CN111010284A (zh) * | 2019-12-20 | 2020-04-14 | 深圳市网心科技有限公司 | 一种待共识区块的处理方法、相关装置及区块链*** |
| CN112396423A (zh) * | 2021-01-20 | 2021-02-23 | 腾讯科技（深圳）有限公司 | 一种交易数据处理方法、装置、设备及存储介质 |
| CN113556238A (zh) * | 2021-09-22 | 2021-10-26 | 深圳前海微众银行股份有限公司 | 区块验证方法 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3651112A1 (en) * | 2018-11-06 | 2020-05-13 | Electricité de France | Method for processing data and apparatuses for implementing the same |
| CN110378697B (zh) * | 2019-07-22 | 2023-03-31 | 南京信息工程大学 | 一种基于rsa累加器的区块链轻节点utxo交易验证方法及其装置 |
| CN111640018B (zh) * | 2020-05-06 | 2021-08-03 | 深圳前海微众银行股份有限公司 | 一种区块链交易存在性验证方法及装置 |
| CN112287034B (zh) * | 2020-12-24 | 2021-04-02 | 腾讯科技（深圳）有限公司 | 一种数据同步方法、设备以及计算机可读存储介质 |
-
2021
- 2021-09-22 CN CN202111104734.0A patent/CN113556238B/zh active Active
- 2021-12-22 WO PCT/CN2021/140630 patent/WO2023045150A1/zh unknown
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108921556A (zh) * | 2018-07-02 | 2018-11-30 | 上海达家迎信息科技有限公司 | 一种区块链的验证方法、装置、设备及存储介质 |
| CN108985772A (zh) * | 2018-07-02 | 2018-12-11 | 上海达家迎信息科技有限公司 | 一种区块链的验证方法、装置、设备及存储介质 |
| CN110602116A (zh) * | 2019-09-19 | 2019-12-20 | 腾讯科技（深圳）有限公司 | 基于区块链的数据验证方法、装置和计算机可读存储介质 |
| CN111010284A (zh) * | 2019-12-20 | 2020-04-14 | 深圳市网心科技有限公司 | 一种待共识区块的处理方法、相关装置及区块链*** |
| CN112396423A (zh) * | 2021-01-20 | 2021-02-23 | 腾讯科技（深圳）有限公司 | 一种交易数据处理方法、装置、设备及存储介质 |
| CN113556238A (zh) * | 2021-09-22 | 2021-10-26 | 深圳前海微众银行股份有限公司 | 区块验证方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113556238B (zh) | 2022-02-15 |
| CN113556238A (zh) | 2021-10-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11410168B2 (en) | Method for user management for blockchain-based operations | |
| US11016962B2 (en) | Blockchain data storage based on shared nodes and error correction code | |
| WO2023045150A1 (zh) | 区块验证方法 | |
| CN111656343B (zh) | 可信执行环境中基于纠错编码的共享区块链数据存储 | |
| JP7012879B2 (ja) | 誤り訂正符号に基づく共有されたブロックチェーンデータの記憶のコンセンサス | |
| US11327833B2 (en) | Prioritizing shared blockchain data storage | |
| CN111095210B (zh) | 基于纠错编码存储共享的区块链数据 | |
| JP7004423B2 (ja) | 誤り訂正符号に基づく共有されたブロックチェーンデータの記憶のデータセキュリティ | |
| US11095434B2 (en) | Shared blockchain data storage based on error correction code | |
| CN111033491B (zh) | 基于纠错编码存储共享的区块链数据 | |
| US11030044B2 (en) | Dynamic blockchain data storage based on error correction code |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 21958261 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |