A cross-shard peer-to-peer energy trading optimization method based on DAG

Abstract

The present invention discloses a cross-shard point-to-point energy transaction optimization method based on DAG, which belongs to the technical field of cross-shard transaction processing; including: defining cross-shard transactions; describing the dependency relationship between multiple sub-transactions based on the directed graph DAG structure; constructing a coordination layer based on the DAG account book, selecting the node with the highest reputation value to serve as a member of the DAG committee; performing transaction verification, forwarding of cross-shard transactions and verification during forwarding for the nodes serving as members of the DAG committee. The present invention adopts an optimistic strategy to process cross-shard transactions in parallel, and decomposes cross-shard transactions into multiple sub-transactions in combination with the DAG structure to ensure the atomicity and consistency of transactions; in high-frequency transaction scenarios, the throughput and processing rate of the system are significantly improved, and transaction delays are effectively reduced; a DAG committee is formed in the internal nodes of the cross-shards, and the DAG account book is maintained to realize efficient cross-shard transaction processing, eliminate dependence on trusted third parties, and significantly reduce communication and verification costs.

Description

Technical Field

[0001] The present invention belongs to the technical field of cross-shard transaction processing, and specifically relates to a DAG-based cross-shard point-to-point energy transaction optimization method. Background Art

[0002] In recent years, with the popularization of distributed power generation, residential consumers can sell their surplus energy to the outside world, which has promoted the development of peer-to-peer energy trading models. Although blockchain effectively solves problems such as market structure, information security, data sharing, price control, and power quality management in distributed peer-to-peer energy trading, the scalability of traditional blocks is insufficient and it is difficult to directly apply them to peer-to-peer energy trading. Sharding technology can effectively improve the scalability of blockchain systems by dividing the blockchain network into several independent networks to process transactions in parallel. However, the introduction of sharding has led to the emergence of a large number of cross-shard transactions. Since cross-shard transactions involve information interaction among multiple shards, consensus must be reached in multiple shards before transactions can be submitted, which brings more complex communication and verification costs.

[0003] Current research mainly uses transaction relationship graphs or machine learning technology to shard blockchains to reduce the number of cross-shard transactions in the system. Although optimizing sharding technology can effectively reduce the number of cross-shard transactions, it cannot eliminate the impact of cross-shard transactions, and the system will still have a large number of cross-shard transactions. In addition, most current cross-shard transaction processing uses two-phase locks and two-phase commits to maintain system consistency. These methods handle cross-shard transactions in a pessimistic way, requiring a shard to wait for other related shards to be ready before cross-shard transaction verification can be performed, which significantly increases the delay in transaction processing. Therefore, there is an urgent need for more efficient methods to ensure consistency and atomicity under cross-shard transactions.

[0004] The Chinese patent discloses (application number: 202310036171.9) a blockchain transaction method, device and system based on intermediary account incentives, including: the blockchain is composed of a main chain and a side chain based on a sharding mechanism, the side chain is bridged to the main chain through a smart contract, and the nodes in each shard on the side chain only store the account status information in the shard; when it is necessary to transfer tokens from a first account to a second account and the two accounts belong to different shards, the corresponding cross-shard transaction is executed through the target intermediary account, and the target intermediary account obtains the corresponding transaction transfer service income when the cross-shard transaction is completed; the target intermediary account belongs to the first shard and the second shard, and is an account on the side chain for providing transaction transfer services verified by the target smart contract, and the number of tokens transferred to the target smart contract meets the preset token number condition; cross-shard transactions on the side chain are realized, which can effectively improve the scalability of the blockchain.

[0005] The Chinese patent discloses (application number: 202310257610.9) a blockchain cross-shard transaction method based on virtual accounts, including: accounts in the blockchain are evenly distributed to each shard according to the account address, and corresponding virtual accounts are established in the shards to which they are not allocated. In the present invention, all accounts are evenly distributed to each shard, and virtual accounts are created for each main account in other shards. All transaction processes can be processed in one round of consensus and one shard without being decomposed into multiple sub-transactions, reducing the workload of storage and communication of each node.

[0006] A patent application for a blockchain transaction method, device and system based on intermediary account incentives has the following deficiencies:

[0007] 1. Relying on intermediary accounts in multiple shards to process cross-shard transactions. When a large number of transactions need to be processed across shards, there may be a situation where the intermediary accounts are in short supply, resulting in a decrease in transaction speed;

[0008] 2. This patent application can only process cross-shard transactions one by one in sequence, and cannot process cross-shard transactions with multiple inputs and multiple outputs.

[0009] A patent application for a blockchain cross-shard transaction method based on virtual accounts has the following shortcomings: Although the virtual account method simplifies cross-shard transaction processing, it may increase the complexity of virtual account management. In particular, when accounts frequently trade across shards, the synchronization of virtual accounts may cause delays.

[0010] To sum up, how to solve the problem of transaction delay and transaction speed reduction when transactions need to be processed across shards. Summary of the invention

[0011] The purpose of the present invention is to provide a DAG-based cross-shard point-to-point energy transaction optimization method to solve the problems raised in the above background technology.

[0012] The object of the present invention is achieved by: a DAG-based cross-shard point-to-point energy transaction optimization method, characterized in that the method comprises the following steps:

[0013] Step S1: Define cross-shard transactions;

[0014] Step S2: Describe the dependency relationship between multiple sub-transactions based on the directed graph DAG structure;

[0015] Step S3: Build a coordination layer based on the DAG ledger and select the node with the highest reputation as a member of the DAG committee;

[0016] Step S4: Perform transaction verification, forwarding of cross-shard transactions, and verification during forwarding for nodes that serve as members of the DAG committee.

[0017] Preferably, the cross-shard transaction is defined in step S1, specifically:

[0018] For a cross-shard transaction , including the input account address, output account address and transaction timestamp information. The input account address and output account address are located in different shards, which are specifically reflected as follows:

[0019] Cross-shard transactions Included Input account address and Output account address, input account indicates the transaction is made by this Initiated by an account, and enter the account , ,..., Located in the output shards , ,..., Output account , ,..., Located in the output shards , ,..., Internal, cross-shard transactions Defined as:

[0020] ;

[0021] in, For the Output accounts; For the Output accounts; For the Input account.

[0022] Preferably, in step S2, the dependency relationship between multiple sub-transactions is described based on a directed graph DAG structure, and the specific operations are:

[0023] Step S2-1: Establish the association between the child transaction and the parent transaction;

[0024] Cross-shard transactions For the parent transaction, cross-shard transaction Split into the following j sub-transactions:

[0025] ;

[0026] ;

[0027] ;

[0028] in, For the Output accounts; For the Output accounts; For the Input accounts;

[0029] Step S2-2: Use the directed graph DAG structure to describe the dependencies between multiple sub-transactions. The dependencies are as follows:

[0030] Cross-shard transactions Verification depends on sub-transactions The verification result of the sub-transaction After successful verification, the cross-shard transaction T can be successfully submitted;

[0031] Sub-transactions Depends on the input shard account Atomic operations and output sharding Atomic operations, only when all atomic operations are successfully verified and executed, the sub-transaction to be successfully verified.

[0032] Preferably, in step S3, a coordination layer based on the DAG ledger is constructed, and nodes with the highest reputation are selected as members of the DAG committee. The specific operations are:

[0033] Step S3-1: Introduce a reputation evaluation mechanism to accurately reflect the performance and historical behavior of the node;

[0034] Behavioral reputation through reputation evaluation mechanism and performance reputation Comprehensive measurement of nodes, behavioral reputation The credibility of the node's historical behavior is reflected by the ratio of the number of verified valid transactions of the node to the total number of transactions in the system, which is defined as follows:

[0035] ;

[0036] in, Representation Node Verified valid transactions, Represents the sum of the number of verified point transactions of all nodes in the blockchain system;

[0037] Reputation through performance To measure the hardware performance of the node, it is defined as follows:

[0038] ;

[0039] in, , , Respectively represent nodes Computing, transmission and storage capabilities; , and Respectively represent nodes The maximum computing capacity, transmission capacity and storage capacity of , and are the weight factors of the node’s computing power, transmission power, and storage power, respectively;

[0040] Step S3-2: Calculate the reputation value of all nodes in each shard;

[0041] The total reputation of a node is calculated as:

[0042] ;

[0043] in, and are the behavioral reputation and performance reputation weight factors respectively, satisfying ;

[0044] Step S3-3: Each shard selects the node with the highest reputation as a member of the DAG committee based on the reputation of the node at a fixed time interval.

[0045] When the total reputation value of node i in the shard When it is the maximum reputation value of all nodes in the shard to which the node belongs, the node is elected as a member of the DAG committee in the coordination layer.

[0046] Preferably, in step S4, the nodes serving as DAG committee members are subjected to transaction verification, cross-shard transaction forwarding, and forwarding verification, and the specific operations are as follows:

[0047] Step S4-1: Cross-shard transactions Perform local verification on the input shard. If the local verification on the input shard passes, the transaction information is packaged into a block and forwarded to the coordination layer committee for verification. Specifically:

[0048] Step S4-1-1: Translate cross-shard transactions On input shard Local verification, input fragment The verification nodes will verify cross-shard transactions The legitimacy of the transaction includes signature verification and transaction format verification; signature verification ensures that the signature of the transaction is valid; transaction format verification confirms the transaction The format complies with the requirements of the blockchain protocol;

[0049] Step S4-1-2: Sharding Verifying nodes for cross-shard transactions Input shard accounts involved The atomic operation is checked, including account legitimacy check, balance verification and operation uniqueness verification; the account legitimacy check mainly verifies the input shard account Check whether it is a valid account, whether the account status is normal, and whether the account's public key and signature match; balance verification mainly checks the shard account The balance of the shard account is sufficient to ensure that the amount required for the transaction does not exceed the current account balance, and reserve fees and other expenses; the operation uniqueness verification mainly ensures that the input shard account The transaction operation is unique in the current ledger, preventing double spending problems caused by repeated broadcasts or other reasons;

[0050] Step S4-1-3: When the verifications from step S4-1-1 to step S4-1-2 are all passed, the transaction information is recorded in the shard In the local ledger;

[0051] Including first, updating the input shard account The balance of the account, minus the amount involved in this transaction;

[0052] Then, add a transaction record entry, including the transaction hash, timestamp, and associated output account information;

[0053] Finally, add a verification mark to the transaction to avoid subsequent repeated verification or processing;

[0054] If in fragmentation If the local verification is passed, the transaction information will be packaged into blocks and forwarded to the coordination level committee for verification;

[0055] Step S4-1-4: If in the shard The local verification is passed, sharding The verification node packages the transaction information into blocks according to the format of the blockchain protocol. , and forwarded to the coordination layer committee for verification;

[0056] Step S4-2: Introduce an optimistic strategy. When the output shard is locally verified on the input shard, the local verification of the output shard is also performed. If the local verification of the output shard passes, the transaction information is packaged into a block and forwarded to the coordination layer committee for verification;

[0057] Step S4-3: The coordination layer committee members verify the received blocks and check whether the blockchain has forked by calculating the block height;

[0058] Step S4-4: When updating the DAG ledger of the coordination layer, it is necessary to select a suitable tip and let the new block reference the tip;

[0059] Step S4-5: Coordination layer DAG ledger update;

[0060] The DAG committee needs to check all operations of a complete cross-shard transaction to ensure that they comply with the cross-shard transaction dependencies based on the DAG graph decomposition; the coordination layer will traverse the cross-shard transaction dependency graph to check whether the execution of the transaction meets the specified dependencies. If the verification is correct, it will reference the tip determined in step S4-4 to complete the DAG ledger update of the coordination layer; when a conflict occurs, it will trace the reference relationship in reverse, clear the corresponding references and roll back the local ledgers of all corresponding shards to achieve the rollback of the transaction.

[0061] Preferably, an optimistic strategy is introduced in step S4-2. When the output shard is locally verified on the input shard, the local verification of the output shard is also performed. If the local verification of the output shard is passed, the transaction information is packaged into a block and forwarded to the coordination layer committee for verification. Specifically,

[0062] The DAG committee finds the output shard account of the transaction in the block according to the cross-shard transaction dependency graph decomposed by the DAG graph. and , packaging transactions into blocks and blocks , and forwarded to the output shard and DAG committee members within

[0063] Set the time to wait for the transaction verification result: If within the time, the DAG committee members of the coordination layer can receive the local verification success feedback of the input shard and the output shard, the DAG committee members of the coordination layer will perform subsequent verification operations; otherwise, the transaction status will be rolled back.

[0064] Preferably, in step S4-3, the coordination layer committee members verify the received blocks and check whether the blockchain has forked by calculating the block height, specifically:

[0065] Sharding DAG committee members find out the blocks The block with the highest height that is directly approved by the ancestor of and the block with the highest height for that shard ;

[0066] Check Block and blocks Check blocks to see if they are equal in height on the chain and blocks Are they on the same chain? If they are equal, then they are on the same chain. is valid, and the result is propagated within the coordination layer; otherwise, it means that the shard has been attacked by a malicious node, resulting in a fork and the discarding of the transaction; if the coordination layer committee member verifies the block, the corresponding edge or node of the DAG transaction dependency graph is set to true, indicating that the verification has been completed.

[0067] Preferably, when updating the DAG ledger of the coordination layer in step S4-4, it is necessary to select a suitable tip and let the new block reference the tip, specifically:

[0068] By calculating the cumulative weight of the block When selecting a tip, the block with a larger cumulative weight is more likely to be selected; the MCMC random walk algorithm is combined to maintain a certain degree of randomness in the tip selection process; the cumulative weight The calculation method is as follows:

[0069] ;

[0070] in, is the starting weight, Indicates all direct or indirect references transaction.

[0071] Compared with the prior art, the present invention has the following improvements and advantages:

[0072] 1. By forming a DAG committee among internal nodes across shards and maintaining the DAG ledger, efficient cross-shard transaction processing is achieved, eliminating the reliance on trusted third parties, thus better conforming to the decentralized nature of the blockchain system and significantly reducing communication and verification costs.

[0073] 2. By adopting an optimistic strategy to process cross-shard transactions in parallel, and combining the DAG structure to decompose cross-shard transactions into multiple sub-transactions, the atomicity and consistency of transactions are ensured; in high-frequency trading scenarios, the system throughput and processing rate are significantly improved, and transaction delays are effectively reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0074] Figure 1 Flow chart of the method of the present invention.

[0075] Figure 2 This is a cross-shard transaction dependency structure diagram based on DAG graph decomposition.

[0076] Figure 3 Diagram of the logical structure of local verification on the input shard for cross-shard transactions.

[0077] Figure 4This is a diagram showing the throughput comparison results of cross-shard transaction processing between the DAG-OM solution and the TPL-TPC solution. DETAILED DESCRIPTION

[0078] The present invention is further summarized below with reference to the accompanying drawings.

[0079] like Figure 1 As shown, a DAG-based cross-shard peer-to-peer energy transaction optimization method includes the following steps:

[0080] Step S1: Define cross-shard transactions;

[0081] Cross-shard transactions involve the coordination of multiple shards. For a cross-shard transaction containing m input accounts, it is split into m sub-transactions;

[0082] For a cross-shard transaction , including the input account address, output account address and transaction timestamp information. The input account address and output account address are located in different shards, which are specifically reflected as follows:

[0083] Cross-shard transactions Included Input account address and Output account address, input account indicates the transaction is made by this Initiated by an account, and enter the account , ,..., Located in the output shards , ,..., Output account , ,..., Located in the output shards , ,..., Internal, cross-shard transactions Defined as:

[0084] ;

[0085] in, For the Output accounts; For the Output accounts; For the Input account.

[0086] Step S2: Describe the dependency relationship between multiple sub-transactions based on the directed graph DAG structure;

[0087] Step S2-1: Establish the association between the child transaction and the parent transaction;

[0088] The cross-shard transaction T is split into the following j sub-transactions. A unique transaction ID is generated for each cross-shard transaction T and attached to each sub-transaction to establish the association between the sub-transaction and the parent transaction.

[0089] Cross-shard transactions For the parent transaction, cross-shard transaction Split into the following j sub-transactions:

[0090] ;

[0091] ;

[0092] ;

[0093] in, For the Output accounts; For the Output accounts; For the Input accounts;

[0094] Splitting cross-shard transactions into sub-transactions within multiple shards can reduce transaction complexity and communication latency between shards, but it cannot guarantee the atomicity of transactions; the dependency relationship between multiple sub-transactions is described based on a directed graph DAG structure.

[0095] Step S2-2: Use the directed graph DAG structure to describe the dependencies between multiple sub-transactions. The dependencies are as follows:

[0096] Cross-shard transactions Verification depends on sub-transactions The verification result of the sub-transaction After successful verification, the cross-shard transaction T can be successfully submitted;

[0097] Sub-transactions Depends on the input shard account Atomic operations and output sharding Atomic operations, only when all atomic operations are successfully verified and executed, the sub-transaction to be successfully verified.

[0098] The specific manifestations are:

[0099] Cross-shard transactions Divided into sub-transactions and sub-transactions :

[0100] ;

[0101] ;

[0102] like Figure 2 As shown, the DAG diagram shows the above transaction relationship, the original cross-shard transaction Verification depends on sub-transactions and The verification result is only and After all are successfully verified, cross-shard transactions To be successfully submitted; sub-transaction Depends on the input shard account Atomic operations and output sharding and Atomic operations, only when all atomic operations are successfully verified and executed, the sub-transaction to be successfully verified.

[0103] In order to improve the scalability of cross-shard transactions, a DAG-based coordination layer is designed to support the verification and forwarding operations of cross-shard transactions, specifically:

[0104] Step S3: Build a coordination layer based on the DAG ledger and select the node with the highest reputation as a member of the DAG committee;

[0105] Step S3-1: Introduce a reputation evaluation mechanism to accurately reflect the performance and historical behavior of the node;

[0106] Behavioral reputation through reputation evaluation mechanism and performance reputation Comprehensive measurement of nodes, behavioral reputation The credibility of the node's historical behavior is reflected by the ratio of the number of verified valid transactions of the node to the total number of transactions in the system, which is defined as follows:

[0107] ;

[0108] in, Representation Node Verified valid transactions, Represents the sum of the number of verified point transactions of all nodes in the blockchain system;

[0109] Reputation through performance To measure the hardware performance of the node, it is defined as follows:

[0110] ;

[0111] in, , , Respectively represent nodes Computing, transmission and storage capabilities; , and Respectively represent nodes The maximum computing capacity, transmission capacity and storage capacity of , and are the weight factors of the node’s computing power, transmission power, and storage power, respectively;

[0112] Step S3-2: Calculate the reputation value of all nodes in each shard;

[0113] The total reputation of a node is calculated as:

[0114] ;

[0115] in, and are the behavioral reputation and performance reputation weight factors respectively, satisfying ;

[0116] Step S3-3: Each shard selects the node with the highest reputation as a member of the DAG committee based on the reputation of the node at a fixed time interval.

[0117] When the total reputation value of node i in the shard When it is the maximum reputation value of all nodes in the shard to which the node belongs, the node is elected as a member of the DAG committee in the coordination layer.

[0118] Step S4: Transaction verification, forwarding of cross-shard transactions, and verification during forwarding are performed on nodes that serve as members of the DAG committee. Specifically:

[0119] like Figure 3 As shown, step S4-1: cross-shard transactions Perform local verification on the input shard. If the local verification on the input shard passes, the transaction information is packaged into a block and forwarded to the coordination layer committee for verification. Specifically:

[0120] Step S4-1-1: Translate cross-shard transactions On input shard Local verification, input fragment The verification nodes will verify cross-shard transactions The legitimacy of the transaction includes signature verification and transaction format verification; signature verification ensures that the signature of the transaction is valid; transaction format verification confirms the transaction The format complies with the requirements of the blockchain protocol;

[0121] Step S4-1-2: Sharding Verifying nodes for cross-shard transactions Input shard accounts involved The atomic operation is checked, including account legitimacy check, balance verification and operation uniqueness verification; the account legitimacy check mainly verifies the input shard account Check whether it is a valid account, whether the account status is normal, and whether the account's public key and signature match; balance verification mainly checks the shard account The balance of the shard account is sufficient to ensure that the amount required for the transaction does not exceed the current account balance, and reserve fees and other expenses; the operation uniqueness verification mainly ensures that the input shard account The transaction operation is unique in the current ledger, preventing double spending problems caused by repeated broadcasts or other reasons;

[0122] Step S4-1-3: When the verifications from step S4-1-1 to step S4-1-2 are all passed, the transaction information is recorded in the shard In the local ledger;

[0123] Including first, updating the input shard account The balance of the account, minus the amount involved in this transaction;

[0124] Then, add a transaction record entry, including the transaction hash, timestamp, and associated output account information;

[0125] Finally, add a verification mark to the transaction to avoid subsequent repeated verification or processing;

[0126] If in fragmentation If the local verification is passed, the transaction information will be packaged into blocks and forwarded to the coordination level committee for verification;

[0127] Step S4-1-4: If in the shard The local verification is passed, sharding The verification node packages the transaction information into blocks according to the format of the blockchain protocol. , and forwarded to the coordination layer committee for verification;

[0128] Step S4-2: Introduce an optimistic strategy. When the output shard is locally verified on the input shard, the local verification of the output shard is also performed. If the local verification of the output shard passes, the transaction information is packaged into a block and forwarded to the coordination layer committee for verification;

[0129] The DAG committee finds the output shard account of the transaction in the block according to the cross-shard transaction dependency graph decomposed by the DAG graph. and , packaging transactions into blocks and blocks , and forwarded to the output shard and DAG committee members within

[0130] Set the time to wait for the transaction verification result: If within the time, the DAG committee members of the coordination layer can receive the local verification success feedback of the input shard and the output shard, the DAG committee members of the coordination layer will perform subsequent verification operations; otherwise, the transaction status will be rolled back.

[0131] Step S4-3: The coordination layer committee members verify the received blocks and check whether the blockchain has forked by calculating the block height;

[0132] Sharding DAG committee members find out the blocks The block with the highest height that is directly approved by the ancestor of and the block with the highest height for that shard ;

[0133] Check Block and blocks Check blocks to see if they are equal in height on the chain and blocks Are they on the same chain? If they are equal, then they are on the same chain. is valid, and the result is propagated within the coordination layer; otherwise, it means that the shard has been attacked by a malicious node, resulting in a fork and the discarding of the transaction; if the coordination layer committee member verifies the block, the corresponding edge or node of the DAG transaction dependency graph is set to true, indicating that the verification has been completed.

[0134] Step S4-4: When updating the DAG ledger of the coordination layer, it is necessary to select a suitable tip and let the new block reference the tip;

[0135] By calculating the cumulative weight of the block When selecting a tip, the block with a larger cumulative weight is more likely to be selected; the MCMC random walk algorithm is combined to maintain a certain degree of randomness in the tip selection process; the cumulative weight The calculation method is as follows:

[0136] ;

[0137] in, is the starting weight, Indicates all direct or indirect references transaction.

[0138] Step S4-5: Coordination layer DAG ledger update;

[0139] The DAG committee needs to check all operations of a complete cross-shard transaction to ensure that they comply with the cross-shard transaction dependencies based on the DAG graph decomposition; the coordination layer will traverse the cross-shard transaction dependency graph to check whether the execution of the transaction meets the specified dependencies. If the verification is correct, it will reference the tip determined in step S4-4 to complete the DAG ledger update of the coordination layer; when a conflict occurs, it will trace the reference relationship in reverse, clear the corresponding references and roll back the local ledgers of all corresponding shards to achieve the rollback of the transaction.

[0140] In order to verify the feasibility and effectiveness of the method of the present invention, the experimental results are presented through the evaluation of the throughput performance of cross-shard transaction processing and the use effect:

[0141] The experimental setup is as follows:

[0142] This experiment is based on the Windows system, Golang v1.19 simulation implementation, and the mingchain system is used to simulate the sharded blockchain environment; the system parameters of the experimental settings are as follows:

[0143] The total number of nodes is 640, the computing cycle required to generate / verify signatures is 2Mhz, the block size is set to 2MB, the weight factor of node computing power is α=0.4, the weight factor of storage capacity is β=0.3, and the weight factor of storage capacity is γ=0.3; the weight factor of behavioral reputation is , the weight factor of performance reputation , For Node The computing power of ; For Node The transmission capacity, ; For Node storage capacity, ; is the proportion of malicious nodes, set to 3%, MCMC random walk step length , set to 10, MCMC initial selection probability , set to 0.5.

[0144] like Figure 4 As shown, the throughput performance of cross-shard transaction processing under the DAG-OM cross-shard transaction processing solution and the TPL-TPC solution based on two-phase lock and two-phase commit is shown;

[0145] The DAG-OM solution proposed in the present invention application has a higher throughput in cross-shard transaction processing than the TPL-TPC solution based on two-phase lock and two-phase commit. This is because the TPL-TPC solution based on two-phase lock and two-phase commit processes cross-shard transactions in a pessimistic way, requiring a shard to wait for other related shards to be ready before cross-shard transaction verification can be performed, which significantly increases the delay of transaction processing. The proposed DAG-OM cross-shard transaction processing solution processes transactions with an optimistic strategy and improves the processing efficiency of cross-shard transactions through the DAG committee.

[0146] The above description is only an embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent substitution, improvement, etc. made within the spirit and principle of the present invention should be included in the scope of the claims of the present invention.

Claims

1. A DAG-based cross-shard peer-to-peer energy trading optimization method, characterized by: The method comprises the following steps: Step S1: Define cross-shard transactions; Step S2: Describe the dependency relationship between multiple sub-transactions based on the directed graph DAG structure; Step S3: Build a coordination layer based on the DAG ledger and select the node with the highest reputation as a member of the DAG committee; Step S4: Transaction verification, forwarding of cross-shard transactions, and verification during forwarding are performed on nodes that serve as members of the DAG committee; Transaction verification, forwarding of cross-shard transactions, and verification during forwarding are performed on nodes that serve as members of the DAG committee. The specific operations are as follows: Step S4-1: Cross-shard transactions Perform local verification on the input shard. If the local verification on the input shard passes, the transaction information is packaged into a block and forwarded to the coordination layer committee for verification. Specifically: Step S4-1-1: Translate cross-shard transactions On input shard Local verification, input fragment The verification nodes will verify cross-shard transactions The legitimacy of the transaction includes signature verification and transaction format verification; signature verification ensures that the signature of the transaction is valid; transaction format verification confirms the transaction The format complies with the requirements of the blockchain protocol; Step S4-1-2: Sharding Verifying nodes for cross-shard transactions Input shard accounts involved The atomic operation is checked, including account legitimacy check, balance verification and operation uniqueness verification; the account legitimacy check mainly verifies the input shard account Check whether it is a valid account, whether the account status is normal, and whether the account's public key and signature match; balance verification mainly checks the shard account The balance of the account is sufficient to ensure that the amount required for the transaction does not exceed the current account balance, and reserve the cost of the handling fee; the operation uniqueness verification mainly ensures that the input shard account The transaction operation is unique in the current ledger, preventing double spending problems caused by repeated broadcasts or other reasons; Step S4-1-3: When the verifications from step S4-1-1 to step S4-1-2 are all passed, the transaction information is recorded in the shard In the local ledger; Including first, updating the input shard account The balance of the account, minus the amount involved in this transaction; Then, add a transaction record entry, including the transaction hash, timestamp, and associated output account information; Finally, add a verification mark to the transaction to avoid subsequent repeated verification or processing; If in fragmentation If the local verification is passed, the transaction information will be packaged into blocks and forwarded to the coordination level committee for verification; Step S4-1-4: If in the fragment The local verification is passed, sharding The verification node packages the transaction information into blocks according to the format of the blockchain protocol. , and forwarded to the coordination layer committee for verification; Step S4-2: Introduce an optimistic strategy. When the output shard is locally verified on the input shard, the local verification of the output shard is also performed. If the local verification of the output shard passes, the transaction information is packaged into a block and forwarded to the coordination layer committee for verification; Step S4-3: The coordination layer committee members verify the received blocks and check whether the blockchain has forked by calculating the block height; Step S4-4: When updating the DAG ledger of the coordination layer, it is necessary to select a suitable tip and let the new block reference the tip; Step S4-5: Coordination layer DAG ledger update; The DAG committee needs to check all operations of a complete cross-shard transaction to ensure that they comply with the cross-shard transaction dependency based on the DAG graph decomposition; the coordination layer will traverse the cross-shard transaction dependency graph to check whether the execution of the transaction meets the specified dependency. If the verification is correct, it will reference the tip determined in step S4-4 to complete the DAG ledger update of the coordination layer; when a conflict occurs, it will trace back the reference relationship, clear the corresponding reference and roll back the local ledgers of all corresponding shards to achieve the rollback of the transaction; An optimistic strategy is introduced. When the output shard is verified locally on the input shard, the local verification of the output shard is also performed. If the local verification of the output shard passes, the transaction information is packaged into a block and forwarded to the coordination layer committee for verification. Specifically: The DAG committee finds the output shard account of the transaction in the block according to the cross-shard transaction dependency graph decomposed by the DAG graph. and , packaging transactions into blocks and blocks , and forwarded to the output shard and DAG committee members within Set the time to wait for the transaction verification result: If within the time, the DAG committee members of the coordination layer can receive the local verification success feedback of the input shard and the output shard, the DAG committee members of the coordination layer will perform subsequent verification operations; otherwise, the transaction status will be rolled back.

2. According to claim 1, a DAG-based cross-shard peer-to-peer energy transaction optimization method is characterized by: The cross-shard transaction is defined in step S1, specifically: For a cross-shard transaction , including the input account address, output account address and transaction timestamp information. The input account address and output account address are located in different shards, which are specifically reflected as follows: Cross-shard transactions Included Input account address and Output account address, input account indicates the transaction is made by this Initiated by an account, and enter the account , ,..., Located in the output shards , ,..., Output account , ,..., Located in the output shards , ,..., Internal, cross-shard transactions Defined as: ； in, For the Output accounts; For the Output accounts; For the Input account.

3. According to claim 1, a DAG-based cross-shard peer-to-peer energy transaction optimization method is characterized by: In step S2, the dependency relationship between multiple sub-transactions is described based on the directed graph DAG structure, and the specific operations are as follows: Step S2-1: Establish the association between the child transaction and the parent transaction; Cross-shard transactions For the parent transaction, cross-shard transaction Split into the following j sub-transactions: ； ； ； in, For the Output accounts; For the Output accounts; For the Input accounts; Step S2-2: Use the directed graph DAG structure to describe the dependencies between multiple sub-transactions. The dependencies are as follows: Cross-shard transactions Verification depends on sub-transactions The verification result of the sub-transaction After successful verification, the cross-shard transaction T can be successfully submitted; Sub-transactions Depends on the input shard account Atomic operations and output sharding Atomic operations, only when all atomic operations are successfully verified and executed, the sub-transaction to be successfully verified.

4. According to claim 1, a DAG-based cross-shard peer-to-peer energy transaction optimization method is characterized by: In step S3, a coordination layer based on the DAG ledger is constructed, and the node with the highest reputation is selected as a member of the DAG committee. The specific operations are as follows: Step S3-1: Introduce a reputation evaluation mechanism to accurately reflect the performance and historical behavior of the node; Behavioral reputation through reputation evaluation mechanism and performance reputation Comprehensive measurement of nodes, behavioral reputation The credibility of the node's historical behavior is reflected by the ratio of the number of verified valid transactions of the node to the total number of transactions in the system, which is defined as follows: ； in, Representation Node Verified valid transactions, Represents the sum of the number of verified point transactions of all nodes in the blockchain system; Reputation through performance To measure the hardware performance of the node, it is defined as follows: ； in, , , Respectively represent nodes Computing, transmission and storage capabilities; , and Respectively represent nodes The maximum computing capacity, transmission capacity and storage capacity of , and are the weight factors of the node’s computing power, transmission power, and storage power, respectively; Step S3-2: Calculate the reputation value of all nodes in each shard; The total reputation of a node is calculated as: ； in, and are the behavioral reputation and performance reputation weight factors respectively, satisfying ; Step S3-3: Each shard selects the node with the highest reputation as a member of the DAG committee based on the reputation of the node at a fixed time interval; When the total reputation value of node i in the shard When it is the maximum reputation value of all nodes in the shard to which the node belongs, the node is elected as a member of the DAG committee in the coordination layer.

5. According to claim 1, a DAG-based cross-shard peer-to-peer energy transaction optimization method is characterized by: In step S4-3, the coordination layer committee members verify the received blocks and check whether the blockchain has forked by calculating the block height, specifically: Sharding DAG committee members find out the blocks The block with the highest height that is directly approved by the ancestor of and the block with the highest height for that shard ; Check Block and blocks Check blocks to see if they are equal in height on the chain and blocks Are they on the same chain? If they are equal, then they are on the same chain. is valid, and the result is propagated within the coordination layer; otherwise, it means that the shard has been attacked by a malicious node, resulting in a fork and the discarding of the transaction; if the coordination layer committee member verifies the block, the corresponding edge or node of the DAG transaction dependency graph is set to true, indicating that the verification has been completed.

6. According to claim 1, a DAG-based cross-shard peer-to-peer energy transaction optimization method is characterized by: When updating the DAG ledger of the coordination layer in step S4-4, it is necessary to select a suitable tip and let the new block reference the tip, specifically: By calculating the cumulative weight of the block When selecting a tip, the block with a larger cumulative weight is more likely to be selected; the MCMC random walk algorithm is combined to maintain a certain degree of randomness in the tip selection process; the cumulative weight The calculation method is as follows: ； in, is the starting weight, Indicates all direct or indirect references transaction.

Images