Light node-oriented transaction verification method based on block chain

Abstract

The invention provides a light node-oriented transaction verification method based on a block chain. The method does not depend on a super node, a light node is synchronized with a DAG transaction graph through a flow of transaction graph release, transaction propagation, transaction verification and transaction packaging and chaining, when the light node performs transaction verification judgment, a transaction meeting a verification condition is found firstly, a transaction abstract forms a to-be-verified block, and the to-be-verified block is released into a network; and the light nodes receiving the to-be-verified block judge whether verification is passed or not according to the number consistent with the number matched with the local. According to the method, the transactions meeting the verification condition are locally screened by each light node, and then the abstract is issued to each light node for verification and judgment, so that the problem of relatively large calculation amount and network information interaction amount caused by verification and judgment of each light node according to the transaction content is avoided, the requirement of lightweight storage of the mobile equipment is met, and the service life of the mobile equipment is prolonged. The calculation overhead is reduced, and data verification is realized.

Description

Technical Field

[0001] The present invention relates to the field of computer blockchain technology, and in particular to a transaction verification method for light nodes based on blockchain. Background Art

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

[0003] At present, blockchain technology mainly relies on a variety of consensus algorithms to ensure data consistency and security, among which typical algorithms include proof of work (PoW), proof of stake (PoS) and Byzantine fault tolerance (BFT). However, the computational overhead of the PoW consensus algorithm is extremely large, requiring a large amount of computing resources to complete complex hash calculations, and consuming a lot of power. It is not suitable for scenarios with limited computing resources and battery power, such as mobile devices. Although PoS reduces the computing power requirements, it still has high requirements for the online time and storage space of the device. Although the BFT consensus algorithm has low requirements for energy consumption and computing resources, when the number of nodes is large, its communication complexity increases significantly, causing the device load to exceed the tolerance of the mobile device. In summary, mobile devices are resource-constrained and have many restrictions such as limited computing power and storage space, and limited battery capacity. These restrictions make standard blockchain protocols not feasible 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. It verifies transactions and queries data by interacting with full nodes or super nodes. Lightweight consensus algorithms that have emerged in recent years, such as the improved BFT algorithm and aggregate signature consensus, have reduced the storage and computing burden of devices, making it possible to implement blockchain on mobile devices.

[0005] Although these technologies have made some progress, there are still challenges in deploying lightweight blockchain applications on mobile devices. In actual operation, light nodes still need to frequently interact with full nodes, which increases the communication burden and data synchronization delay. In addition, the existing lightweight consensus algorithm still cannot ensure sufficient security and efficiency in an environment 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 of the invention

[0007] In view of this, the present invention provides a transaction verification method for light nodes based on blockchain, which realizes data lightweight evidence storage by utilizing the characteristics of blockchain anti-tampering, decentralization, and traceability, combined with Merkle tree, hash algorithm and other methods, through the process of transaction graph publishing-transaction propagation-transaction verification-transaction packaging and chaining. It not only meets the demand for lightweight storage of mobile devices, reduces computing overhead, but also realizes data verification.

[0008] In order to solve the above technical problems, the present invention is implemented as follows.

[0009] A transaction verification method for light nodes based on blockchain, including a transaction writing phase and a transaction verification phase;

[0010] The transaction writing phase includes:

[0011] S11, the master node publishes the initial DAG transaction graph and the transaction update plan ρ of the light node; wherein, the points in the DAG transaction graph represent transactions, and the edges represent the associations of transactions; the transaction update plan ρ records the numbers of the publishable transactions allocated to the light node and their positions in the DAG transaction graph;

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

[0013] S13, when the light node p generates a new transaction T according to the transaction update plan ρ, it updates the local DAG transaction graph;

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

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

[0016] The transaction verification phase includes:

[0017] S21. The light node q determines whether the transaction meets the verification conditions based on the synchronized DAG transaction graph;

[0018] S22, light node q will reach the transaction status S of the verification condition transaction i The block body packed into a block δ;

[0019] S23. Light node q calculates the transaction summary σ of all transactions that meet the verification conditions in block δ according to the Merkle tree;

[0020] 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 a pending verification state; at the same time, block δ is published to the network and synchronized to other light nodes p;

[0021] S25. Light node p verifies block δ published by other light node q: Determine whether the block δ published by other light node q matches the block header information of the local block δ′ to be verified by light node p. If more than two-thirds of the other light nodes send matching blocks, then block δ′ is considered to have passed the verification; set block δ′ to the verified state and store it on the chain.

[0022] Preferably, in step S21, judging whether the transaction meets the verification condition is as follows: calculating the weight of the transaction according to the DAG transaction graph, and judging whether the transaction meets the verification condition according to the weight.

[0023] Preferably, the weight of the transaction is calculated according to the DAG transaction graph as follows: the 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 sub-transactions connected to it plus the number of sub-transactions.

[0024] Preferably, judging whether a transaction meets the verification condition according to 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 of 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.

[0025] Preferably, in step S24, the light node p constructs the block header information using the transaction summary α as follows:

[0026] The transaction summary is the hash value r2 of the block; the light node p constructs the parent block hash value r1, timestamp and the hash value r2 of the block into the block header information.

[0027] Beneficial effects:

[0028] (1) The present invention firstly screens transactions that meet the verification conditions locally by each light node, and then publishes the summary to each light node for verification and judgment, thereby avoiding the problems of excessive data verification overhead and large amount of network information interaction of each light node in the prior art, and can effectively improve the feasibility and efficiency of blockchain applications on mobile devices. This method does not rely on super nodes, but directly obtains block header information and Merkle tree structure from the blockchain network through light nodes to quickly verify the authenticity of transactions, thereby reducing storage and computing burdens.

[0029] (2) At the same time, this transaction verification method reduces the computing power requirements of the device by optimizing the interaction process of light nodes, avoiding the high consumption of mobile device resources by traditional consensus algorithms. This method not only ensures data security and consistency, but also runs 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, so when writing and verifying transactions, the results of all light nodes are the same. When a light node p publishes a new transaction, it 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 schematic diagram of DAG node weight calculation;

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

[0035] Figure 5 It is a 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, including 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 transaction update plan ρ of the light node.

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

[0041] like Figure 1 As shown, let the DAG transaction graph be G = (V, E), including 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, a vertex represents a transaction, and an edge represents the relationship between transactions. The DAG transaction graph can be generated by giving a given number of nodes. In the initial DAG transaction graph, there is no specific transaction in the node, such as Figure 5As shown in the figure on the left, when the edge between transactions represents the relationship between the parent transaction and the child transaction, when the child node of a 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 status S and content m. The status includes the verification status, the parent transaction number T i , Transaction Number T j , content summary α. The content summary is α=SHA256(m). SHA represents a hash calculation, and 256 represents a 256-bit hash value output by the hash calculation.

[0043] Each light node stores the same DAG transaction graph, so when writing and verifying transactions, the results of all light nodes are the same. When publishing a new transaction, light node p only needs to publish the transaction state S. The content m is only saved locally. When other light nodes q receive it, m is invisible due to the one-way nature of the hash algorithm, ensuring data privacy. In addition, not distributing content m can also save the amount of data transmitted between nodes.

[0044] like Figure 1 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) based on the number of historical transaction submissions of light nodes in the network. Width represents the maximum width of the DAG transaction graph (related to the maximum number of concurrent 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 ρ assigns the number of the publishable transaction and the position in the DAG transaction graph to the light node p. The light node p will write and verify the transaction according to the transaction update plan ρ and the DAG transaction graph. Figure 5 As shown in Figure 1, the transaction update plan ρ consists of a numbered transaction graph and a transaction and node comparison table. All nodes hold the same transaction graph and node comparison table. In the comparison table, a mapping relationship is established between transaction numbers and nodes, and transactions will be planned to be published on designated nodes.

[0046] S12, light node p synchronizes the DAG transaction graph and transaction execution plan ρ to the local. The light node p here is actually all the received light nodes, and is marked as p here to distinguish it from the light nodes that receive and distribute 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, Figure 5In the example, the transaction numbered 1 belongs to node a, and node a has the right to publish and update transaction 1. Other nodes do not have the right to publish transactions numbered 1. In the present invention, considering the limited storage resources and data privacy of light nodes, only the status of transactions is published in the network, not the complete transaction. When node b receives the status S1 of transaction numbered 1 in the network, it will synchronize S1 to the specified position 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 , according to the DAG transaction graph and transaction update plan ρ, update the local DAG transaction graph.

[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 recognition, then it is believed that T i The present invention designs a transaction weight calculation scheme 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, and each edge or each sub-transaction is recorded as 1. Then the gray block has two edges connected to it, so the gray block is recorded as 2. Figure 3 In (a), there are 4 transactions connected to the red block, the weights of the 4 transactions are 6 / 3 / 1 / 7 respectively, and the weights of the 4 edges are 4, so the weight of the red block is 21. Considering other reasons such as network lag and equipment failure, the node did not publish new transactions as planned. Figure 3 In (c), if there is no transaction in the grid block, the edge connecting the grid block to the gray block is recorded as 0. Although the grid block is empty, the association between the transactions still exists. The weight of the node is still the sum of the weights of its sub-transactions plus the number of sub-transactions, so that its parent transaction can inherit these weights.

[0056] Assume that the number of transactions to be verified in the DAG transaction graph is v. When a sub-transaction T j When the weight of exceeds 2v, the subtransaction is considered to be verified. Figure 1 As shown, assuming that the number of nodes is v, 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, T i In the weight calculation of , each edge is counted at most once, so the weight statistics range is (0, 4v). i Get more than half of the sub-transactions T j If the transaction is recognized, then it is considered that i is in the verified state. Then when transaction T i When the weight value is greater than 2v, transaction T i Must be more than half of the sub-transactions T j Approved, then judge T i The verification conditions are met.

[0057] S22, light node q will reach the transaction status S of the verification condition transaction i The block body packed into a block δ.

[0058] The block consists of two parts: the block header and the block body. The block header contains the brief information of the block. The block header information designed in this invention includes the hash value r1 of the parent block, the hash value r2 of the block and the timestamp. The block body contains specific transactions. First, the light node p synchronizes the transaction status S published by other light nodes q within the cycle. i The light node p packages all transactions that meet the verification conditions within the cycle into a block.

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

[0060] S23. Light node q calculates the transaction summary σ of all transactions that meet the verification conditions in block δ based on the Merkle tree.

[0061] In this step, the light node p sorts and numbers all transactions according to the update plan released by the master node, S = (S1, S2, S3, ... S i ). Then use the Merkle tree to calculate the transaction summary of S. Figure 3 As shown, the Merkle tree is a binary tree. First, the hash value of the leaf node is calculated using the hash algorithm to obtain (S1, S2, S3, ... S i ). The hash algorithm can output a hash value of fixed length, and after layers of calculations, the root is finally calculated. The root is the hash value r2 of the block; the transaction summary is the hash value r2 of the block.

[0062] 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 a pending verification state. At the same time, block δ containing block header information is published to the P2P network and synchronized to other light nodes p.

[0063] S25. Light node p verifies block δ published by other light nodes q. Light nodes can only read block header information, while master nodes read the entire block information. Light node p determines whether the information published by other light nodes q matches the block header information of the local block δ′ to be verified 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; block δ′ is set to a verified state and stored on the chain.

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

[0065] The transaction write phase includes:

[0066] S11. 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 transaction update plan ρ to local computers.

[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 status S of the new transaction T in the P2P network according to the message propagation protocol i .

[0070] S15, B and C receive the status S of the new transaction i, according to the DAG transaction graph and transaction update plan ρ, update the local DAG transaction graph.

[0071] It can be seen that A, B, and C all save the same DAG transaction graph. When writing and verifying transactions, the results of A, B, and C are the same. 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 operations and remain consistent with A.

[0072] The transaction verification phase includes:

[0073] S21. After A updates the DAG transaction graph, it calculates the transaction weight and determines whether the transaction meets the verification conditions based on the weight.

[0074] S22, packing the transaction status that meets the verification condition into a block body of block b;

[0075] S23. According to the Merkle tree, calculate the transaction summary σ of all transactions that meet the verification condition.

[0076] S24. A calculates and constructs the block header information using the transaction summary α, stores it in the block header, and forms a complete block δ with the block body, and sets it to a pending verification state. At the same time, 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 local block information to be verified by A, then it is to be verified. When more than 2 / 3 of the blocks are received, the block is set to the verified state and stored on the chain.

[0078] The above specific embodiments only describe the design principle of the present invention. The shapes and names of the components in the description may be different and are not limited. Therefore, those skilled in the art in the field of the present invention may modify or replace the technical solutions recorded in the above embodiments; and these modifications and replacements do not deviate from the creative purpose and technical solutions of the present invention and should all fall within the protection scope of the present invention.

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 ρ of the light node; wherein, the points in the DAG transaction graph represent transactions, and the edges represent the associations of transactions; the transaction update plan ρ records the numbers of the publishable transactions allocated 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; 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 , according to the DAG transaction graph and transaction update plan ρ, synchronize to the local DAG transaction graph; The transaction verification phase includes: S21. The 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 δ according to 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 a 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 δ published by other light node q matches the block header information of the local block δ′ to be verified by light node p. If more than two-thirds of the other light nodes send matching blocks, then block δ′ is considered to have passed the verification; set block δ′ to the verified state and store it on the chain.

2. The method according to claim 1, characterized in that In the step S21, whether the transaction meets the verification condition is determined by 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, characterized in that The weight of a transaction is calculated based on the DAG transaction graph: 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 sub-transactions connected to it plus the number of sub-transactions.

4. The method according to claim 2, characterized in that 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 of 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, characterized in that In step S24, the light node p constructs the block header information using the transaction summary α as follows: The transaction summary is the hash value r2 of the block; the light node p constructs the parent block hash value r1, timestamp and the hash value r2 of the block into the block header information.

Images