Blockchain-based transaction verification method for light nodes

Abstract

The present disclosure provides a kind of light node-oriented transaction verification method based on blockchain.The method does not depend on super node, through the process of transaction graph publishing-transaction propagation-transaction verification-transaction packaging chain, light node synchronizes DAG transaction graph, when light node carries out transaction verification judgment, first find the transaction that reaches verification condition, form the block to be verified with transaction digest, and publish to network;Light node received to the block to be verified carries out the judgment whether to pass according to the number of local matching consistency verification.The present application first filters the transaction that reaches verification condition by each light node local, then publishes the abstract to each light node for verification judgment, avoids the problem of large amount of calculation and network information interaction caused by each light node according to transaction content for verification judgment, both meets the demand of mobile device light weight storage, reduces the computing cost, and realizes data verification.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer blockchain technology, and particularly relates to a transaction verification method for light nodes based on a blockchain. BACKGROUND

[0002] With the increasing popularity of mobile devices, users' demand for data privacy and security is growing, and blockchain technology is gradually regarded as an effective means to enhance data security due to its decentralization and tamper-proof characteristics. However, the application of traditional blockchain technology on mobile devices faces major challenges.

[0003] Currently, blockchain technology mainly relies on various consensus algorithms to ensure data consistency and security, including typical algorithms such as Proof of Work (PoW), Proof of Stake (PoS), and Byzantine Fault Tolerance (BFT). However, the PoW consensus algorithm has a huge computational overhead, requiring a large amount of computing resources to complete complex hash calculations, while consuming a large amount of power. It is not suitable for mobile devices and other scenarios with limited computing resources and battery capacity. Although PoS reduces the requirement for computing power, it still has high demands for device online duration and storage space. BFT consensus algorithms have lower energy consumption and computing resource requirements, but when the number of nodes is large, their communication complexity increases significantly, causing device load to exceed the capacity of mobile devices. In summary, mobile devices have limited computing power, storage space, and battery capacity. These limitations make it impossible for standard blockchain protocols to be implemented on mobile devices.

[0004] To address these issues, the industry has begun to explore lightweight consensus algorithms and light node architectures suitable for light nodes. A light node is a type of node that does not need to download and store complete blockchain data, and it verifies transactions and queries data through interaction with full nodes or super nodes. In recent years, lightweight consensus algorithms such as improved BFT algorithms and aggregated signature consensus have reduced the storage and computing burden on devices, making it possible to implement blockchain on mobile devices.

[0005] Despite these advances, there are still challenges in deploying lightweight blockchain applications on mobile devices. Light nodes still need to interact frequently with full nodes in actual operation, increasing communication burden and data synchronization delay. In addition, existing lightweight consensus algorithms still cannot ensure sufficient security and efficiency in environments with strong network dynamics.

[0006] Therefore, further research is needed to develop more flexible and efficient data consistency strategies that can adapt to mobile device environments to ensure reliable blockchain services under resource-constrained conditions. SUMMARY

[0007] Therefore, the application provides a transaction verification method for light nodes based on a block chain.

[0008] To solve the above technical problems, the application is implemented as follows.

[0009] A transaction verification method for light nodes based on a block chain, comprising a transaction writing stage and a transaction verification stage.

[0010] The transaction writing stage comprises the following steps.

[0011] S11, a master node publishes an initial DAG transaction graph and a transaction update plan ρ for a light node; wherein a point in the DAG transaction graph represents a transaction, and an edge represents an association relationship of the transaction; the transaction update plan ρ records a number and a position in the DAG transaction graph of a publishable transaction allocated for the light node.

[0012] S12, the light node p synchronizes the initial DAG transaction graph and the transaction update plan ρ to a local node.

[0013] S13, when the light node p generates a new transaction T according to the transaction update plan ρ, the local DAG transaction graph is updated.

[0014] S14, the light node p publishes a state S i of the new transaction T in the network according to a message propagation protocol.

[0015] S15, other light nodes q receive the state S i of the new transaction T, and synchronize the local DAG transaction graph according to the DAG transaction graph and the transaction update plan ρ.

[0016] The transaction verification stage comprises the following steps.

[0017] S21, the light node q judges whether a transaction reaches a verification condition based on the synchronized DAG transaction graph.

[0018] S22, the light node q packs a transaction state S i of the transaction reaching the verification condition into a block body of a block δ.

[0019] S23, the light node q calculates a transaction digest σ of all transactions reaching the verification condition in the block δ according to a Merkle tree.

[0020] S24, the light node q constructs block header information using the transaction digest alpha, stores the block header into the block header, and forms a complete block delta with the block body, and sets the block delta to a to-be-verified state; meanwhile, the block delta is published to the network and synchronized to other light nodes p;

[0021] S25, the light node p verifies the block delta published by the other light node q: judges whether the block header information of the block delta published by the other light node q is consistent with the block header information of the to-be-verified block delta' in the local light node p, if more than two-thirds of the other light nodes send the consistent block, then the block delta' is considered to pass the verification; the block delta' is set to a verified state and stored on the chain.

[0022] Preferably, in the step S21, the judgment of whether the transaction reaches the verification condition is that the weight of the transaction is calculated according to the DAG transaction graph, and whether the transaction reaches the verification condition is judged according to the weight.

[0023] Preferably, the calculation of the weight of the transaction according to the DAG transaction graph is that the points in the DAG transaction graph include unverified transactions, to-be-verified transactions and verified transactions; the weight of the unverified transaction is 0; and the weight of the to-be-verified transaction is the sum of the weights of all child transactions connected with the to-be-verified transaction plus the number of the child transactions.

[0024] Preferably, the judgment of whether the transaction reaches the verification condition according to the weight is that the number of the to-be-verified transactions in the DAG transaction graph is v; when the weight value of a transaction T i is greater than 2v, the transaction T i is approved by more than half of the child transactions, and the transaction T i reaches the verification condition.

[0025] Preferably, in the step S24, the light node p constructs the block header information using the transaction digest alpha.

[0026] The transaction digest is the hash value r2 of the block; the light node p constructs the block header information using the parent block hash value r1, the time stamp and the hash value r2 of the block.

[0027] Beneficial effects:

[0028] (1) The application first screens the transactions reaching the verification condition by each local light node, and then publishes the digest to each light node for verification and judgment, thereby avoiding the problems of large data verification overhead and large network information interaction of each light node in the prior art, and effectively improving the feasibility and efficiency of the blockchain application on the mobile device. The method does not depend on the super node, but directly obtains the block header information and the Merkle tree structure from the blockchain network, so as to quickly verify the transaction authenticity, thereby reducing the storage and computing burden.

[0029] (2) At the same time, this transaction verification method reduces the computing power requirements of devices by optimizing the interaction process of light nodes, avoiding the high resource consumption of mobile devices by traditional consensus algorithms. This method not only ensures data security and consistency, but also operates in resource-constrained environments, making it possible to implement lightweight blockchain applications on mobile devices.

[0030] (3) Each light node stores the same DAG transaction graph. Therefore, when writing and verifying transactions, all light nodes achieve the same results. When publishing a new transaction, light node p only needs to publish the transaction state S. The content m is only stored locally. When other light nodes q receive it, m is invisible due to the one-way nature of the hash algorithm, ensuring data privacy. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 is the initial DAG transaction graph;

[0032] Figure 2 It is a DAG transaction graph;

[0033] Figure 3 This is a diagram of DAG node weight calculation;

[0034] Figure 4 This is a diagram of the Merkle tree;

[0035] Figure 5 Schematic diagram of an embodiment of the present invention. DETAILED DESCRIPTION

[0036] The present invention is described in detail below with reference to the accompanying drawings and embodiments.

[0037] The present invention provides a light node-oriented transaction verification method based on blockchain, which includes a transaction writing phase and a transaction verification phase.

[0038] The transaction write phase includes:

[0039] S11. The master node publishes the initial DAG transaction graph and the light node's transaction update plan ρ.

[0040] In the present invention, the transaction update plan ρ assigns the updateable transaction number and position in the DAG transaction graph to the light node;

[0041] like Figure 1 As shown, let the DAG transaction graph be G = (V, E), which contains edge E and vertex V. The DAG transaction graph is a data structure for transaction storage, which can express the topological relationship between transactions. In the present invention, the vertex represents the transaction and the edge represents the relationship between the transactions. The DAG transaction graph can be generated by giving the number of nodes. In the initial DAG transaction graph, there is no specific transaction in the node, such as Figure 5The left side of the figure shows. The edge between the transactions represents the relationship between the parent transaction and the child transaction. When the child node of a certain parent transaction is filled with transaction information, the edge between the parent transaction and the child transaction is given a weight of 1.

[0042] The transaction V in the DAG transaction graph contains the transaction state S and the content m. The state includes the verification state, the parent transaction number T i , the transaction number T j , and the content digest a. The content digest is a = SHA256(m). SHA represents a hash calculation, and 256 represents that the hash calculation outputs a 256-bit hash value.

[0043] If each light node saves the same DAG transaction graph, the results of all light nodes are the same when writing and verifying transactions. When the light node p publishes a new transaction, it only needs to publish the transaction state S. The content m is only saved locally. When other light nodes q receive it, since the hash algorithm has a one-way nature, m is invisible, ensuring data privacy. Moreover, not distributing the content m can also save the amount of data transmission between nodes.

[0044] As shown in Figure 1 , the DAG transaction graph is generated by the master node. The master node sets the transaction graph state parameter β = (width, num, node) according to the historical transaction submission quantity of the light nodes in the network. width represents the maximum width of the DAG transaction graph (related to the maximum concurrency number of transactions), num represents the number of transactions in the graph, and node represents the light node application information (including the number of transactions applied and the light node ID).

[0045] The transaction update plan ρ allocates the number of publishable transactions and the position in the DAG transaction graph to the light node p. The light node p will write and verify transactions according to the transaction update plan ρ and the DAG transaction graph. As shown in Figure 5 , the transaction update plan ρ is a transaction graph with numbers and a transaction and node table. All nodes hold the same transaction graph and node table. In the table, the transaction number and the node establish a mapping relationship, and the transaction will be planned to be published by the specified node.

[0046] S12, the light node p synchronizes the DAG transaction graph and the transaction execution plan ρ to the local. The light node p here is actually all the received light nodes, and p is marked here to distinguish from the light node that receives and distributes new transactions later.

[0047] S13, according to the transaction update plan ρ, when the light node p generates a new transaction T, the local DAG transaction graph is updated.

[0048] For example, in Figure 5In the example, transaction number 1 belongs to node a. Node a has the right to publish and update transaction 1. Other nodes do not have the right to publish transactions numbered 1. In this invention, considering the limited storage resources and data privacy of light nodes, only the transaction status is published on the network, not the complete transaction. When node b receives the status S1 of transaction number 1 on the network, it synchronizes S1 to the specified location in the transaction graph.

[0049] S14. Light node p publishes the status S of the new transaction T in the P2P network according to the message propagation protocol i .

[0050] In this step, the Gossip protocol can be used to publish the transaction status, and the transaction status is gradually spread to other light nodes.

[0051] S15. Other light nodes q receive the status S of the new transaction T i , update the local DAG transaction graph according to the DAG transaction graph and transaction update plan ρ.

[0052] The transaction verification phase includes:

[0053] S21. Light node q determines whether the transaction meets the verification conditions based on the updated DAG transaction graph.

[0054] The core idea of ​​transaction verification is to verify the validity of the parent transaction through the submission of the sub-transaction. i Subtransaction T exists j , then the subtransaction approves transaction T i The existence of a sub-transaction here means that the sub-transaction node has transaction information, rather than an empty node. i Get more than half of the sub-transactions T j If T i The present invention designs a calculation scheme for transaction weights to determine the transaction T i Whether it is more than half of the sub-transactions T j Recognition.

[0055] The weight of a transaction is calculated as follows: Figure 3 As shown in (a), white blocks are unverified transactions, gray blocks are pending transactions, and striped blocks are verified transactions. When calculating weights, the weight of unverified transactions is 0, and the weight of pending transactions is the sum of the weights of all sub-transactions connected to it plus the number of sub-transactions (i.e., connecting edges). The weight is calculated layer by layer from the leaf node to the root node. As shown in the figure, the white block is a leaf node with no sub-transactions, so the weight is 0. If Figure 3As shown in (b), there are two white blocks pointing to the gray block, each edge or each sub-transaction is recorded as 1, and the gray block is connected to two edges, so the gray block is recorded as 2. Figure 3 In (a), the transactions connected to the red block are 4, the weight values of the 4 transactions are 6 / 3 / 1 / 7 respectively, and the weight value of the 4 edges is 4, so the weight value of the red block is 21. Considering the network lag, equipment failure and other reasons, the node does not publish new transactions as planned. As shown in (b), the weight value of the red block is 21, and the weight value of the gray block is 2, so the weight value of the red block is 23. Figure 3 In (c), the grid block has no transaction, so the edge connected to the gray block is recorded as 0. Although the grid block is empty, the association relationship between the transactions still exists. The weight value of the node is still the sum of the weight values of the sub-transactions plus the number of sub-transactions, so that the parent transaction can inherit these weight values.

[0056] Suppose the number of transactions to be verified in the DAG transaction graph is v. When a sub-transaction T j has a weight exceeding 2v, it is considered that the sub-transaction is verified. As shown in (b), suppose the number of nodes is v, and since the out-degree of each node is 2, the number of edges in the graph is 2v. Due to the characteristics of the DAG transaction graph structure, the weight of T Figure 1 is calculated as the sum of the weight values of the sub-transactions plus the number of sub-transactions, so that the parent transaction can inherit these weight values. i The weight of T i is calculated as the sum of the weight values of the sub-transactions plus the number of sub-transactions, so that the parent transaction can inherit these weight values. j When a transaction T i is verified, it is considered that the transaction is verified. When the weight of a transaction T i exceeds 2v, it is considered that the transaction is verified. i When the weight of a transaction T j exceeds 2v, it is considered that the transaction is verified. i

[0057] S22, the light node q packs the transaction state S i of the transaction reaching the verification condition into a block body of a block δ.

[0058] The block has a block header and a block body, the block header includes brief information of the block, and in the application, the block header information includes a hash value r1 of a parent block, a hash value r2 of the block and a timestamp. The block body includes specific transactions. First, the light node p synchronizes the transaction state S i of the transaction reaching the verification condition published by other light nodes q in a period.

[0059] The packing includes storage of the block body (step S22), calculation of part of the information in the block header (step S23), and construction and storage of the block header information (step S24).

[0060] ​S23, the light node q calculates the transaction digest σ of all transactions in the block δ that meet the verification condition according to the Merkel tree.

[0061] In this step, the light node p sorts and numbers all transactions according to the update plan published by the main node, S=(S1, S2, S3, … S i ). Then the transaction digest of S is calculated using the Merkel tree. As shown in Figure 3 , the Merkel tree is a binary tree. First, the hash value of the leaf node is calculated using the hash algorithm, and the hash value of (S1, S2, S3, … S i ) is obtained. The hash algorithm can output a fixed-length hash value, and after layer-by-layer calculation, the root is finally calculated, which is the hash value r2 of the block; the transaction digest is the hash value r2 of the block.

[0062] S24, the light node q constructs the block header information using the transaction digest α, stores it in the block header, and forms a complete block δ together with the block body, and sets it to a to-be-verified state. At the same time, the block δ containing the block header information is published to the P2P network and synchronized to other light nodes p.

[0063] S25, the light node p verifies the block δ published by the other light node q. The light node can only read the block header information, and the main node reads the entire block information. The light node p judges whether the information published by the other light node q matches the block header information of the to-be-verified block δ' in the local light node p, if more than two-thirds of the other light nodes send matching blocks, then the block δ' is considered to pass the verification; the block δ' is set to a verified state and stored on the chain.

[0064] The following is an example, which includes four entities: a data center DC, a mobile device A, a mobile device B, and a mobile device C. The transaction verification method includes the following steps:

[0065] The transaction writing stage includes:

[0066] S11, the DC publishes the initial DAG transaction graph and the transaction update plan ρ of the light node.

[0067] S12, A, B, and C synchronize the DAG transaction graph and the transaction update plan ρ to the local.

[0068] S13, A generates a new transaction T and updates the local DAG transaction graph according to the transaction update plan ρ.

[0069] S14, A publishes the state S i of the new transaction T in the P2P network according to the message propagation protocol.

[0070] S15, B and C receive the state S iAccording to the DAG transaction graph and the transaction update plan ρ, the local DAG transaction graph is updated.

[0071] It can be seen that A, B and C all save the same DAG transaction graph, and the results executed by A, B and C are the same when the transaction is written and verified. A publishes the transaction state S in the P2P network. B and C synchronize the transaction state S published by A. According to the preset update plan ρ, B and C perform the same operation and keep consistent with A.

[0072] The transaction verification stage includes:

[0073] S21, after A updates the DAG transaction graph, the transaction weight is calculated, and whether the transaction meets the verification condition is judged according to the weight;

[0074] S22, the transaction state meeting the verification condition is packaged into a block body of a block b.

[0075] S23, according to the Merkle tree, the transaction digest σ of all transactions meeting the verification condition is calculated.

[0076] S24, A calculates the block header information constructed by the transaction digest α, stores it into the block header, and forms a complete block δ with the block body, and sets it as a to-be-verified state. At the same time, the block δ is published to the P2P network and synchronized to other B and C.

[0077] S25, A verifies the block information published by B and C. If the information published by B and C is consistent with the to-be-verified block information in A locally, it is to-be-verified. When more than 2 / 3 of the blocks are set as verified, they are stored on the chain.

[0078] The above specific embodiments only describe the design principles of the present application, and the shapes and names of the components in the description can be different and are not limited. Therefore, the person skilled in the art of the present application can modify or replace the technical solutions described in the foregoing embodiments; and these modifications and replacements do not deviate from the purpose and technical solutions of the present application, and should all belong to the protection scope of the present application.

Claims

1. A transaction verification method for light nodes based on blockchain, characterized in that: Includes transaction writing phase and transaction verification phase; The transaction writing phase includes: S11. The master node publishes the initial DAG transaction graph and the transaction update plan ρ for the light node. In the DAG transaction graph, nodes represent transactions, and edges represent relationships between transactions. The transaction update plan ρ records the numbers of the publishable transactions assigned to the light node and their positions in the DAG transaction graph. S12. Light node p synchronizes the initial DAG transaction graph and transaction update plan ρ to the local computer. S13. When the light node p generates a new transaction T according to the transaction update plan ρ, it updates the local DAG transaction graph; S14. Light node p publishes the status S of the new transaction T in the network according to the message propagation protocol i ; S15. Other light nodes q receive the status S of the new transaction T i , synchronized to the local DAG transaction graph according to the DAG transaction graph and transaction update plan ρ; The transaction verification phase includes: S21. Light node q determines whether the transaction meets the verification conditions based on the synchronized DAG transaction graph; S22, light node q will reach the transaction status S of the verification condition transaction i The block body packed into a block δ; S23. Light node q calculates the transaction summary σ of all transactions that meet the verification conditions in block δ based on the Merkle tree; S24. Light node q constructs block header information using transaction summary α, stores it in the block header, and forms a complete block δ with the block body, and sets it to the pending verification state. At the same time, block δ is published to the network and synchronized to other light nodes p. S25. Light node p verifies block δ published by other light node q: Determine whether the block header information of block δ published by other light node q matches the block δ′ to be verified locally by light node p. If more than two-thirds of the other light nodes send matching blocks, then block δ′ is considered to have passed verification; set block δ′ to a verified state and store it on the chain.

2. The method according to claim 1, wherein In step S21, determining whether the transaction meets the verification condition is as follows: calculating the weight of the transaction according to the DAG transaction graph, and determining whether the transaction meets the verification condition according to the weight.

3. The method according to claim 2, wherein The weight of a transaction is calculated based on the DAG transaction graph as follows: points in the DAG transaction graph include unverified transactions, pending transactions, and verified transactions; the weight of an unverified transaction is 0; the weight of a pending transaction is the sum of the weights of all its connected sub-transactions plus the number of sub-transactions.

4. The method according to claim 2, wherein The method of judging whether a transaction meets the verification condition based on the weight is as follows: the number of transactions to be verified in the DAG transaction graph is v; when a transaction T i When the weight value is greater than 2v, transaction T i Transaction T is approved by more than half of the sub-transactions. i By meeting the verification conditions.

5. The method according to claim 1, wherein In step S24, the light node p constructs the block header information using the transaction summary α: The transaction summary is the hash value r2 of the block; the light node p constructs the block header information from the parent block hash value r1, timestamp and the block hash value r2.

Images