A blockchain anonymous transaction method based on cross-node multi-hop payment

Abstract

The present invention discloses a blockchain anonymous transaction method based on cross-node multi-hop payment, and the steps are as follows: 1. User connection: before the user node participates in the transaction, it enters the encrypted session state through the encryption module to encrypt and authenticate the messages between nodes. 2. Channel establishment: after the user node enters the encrypted session state, the two nodes negotiate to establish a payment channel. Before the channel balance is cleared, the two nodes can apply to close the payment channel in advance. 3. Anonymous payment: the user node can select nodes that already have channels, and these nodes forward the user node transaction information for a fee. The user node determines the payment path with the best cost through the local network view to complete the cross-node anonymous payment. The present invention ensures the communication security of the two parties to the transaction by establishing a secure session before the transaction; by establishing a payment channel, the node can select a node with a high cost-effectiveness of the channel to generate an anonymous payment path. The present invention can achieve the effect of fast and anonymous transactions while ensuring the optimal transaction cost.

Description

Technical Field

[0001] The present invention belongs to blockchain technology, and in particular relates to a blockchain anonymous transaction method based on cross-node multi-hop payment. Background Art

[0002] Like any emerging technology, digital currency also needs to solve a series of problems and adjust measures. The main shortcomings of digital currency include the following aspects:

[0003] 1) The transaction processing speed is relatively slow. The current speed is 7 transactions per second, and users have to wait for transaction confirmation for about an hour. In the case of large transaction volume demand, such a speed will lead to low system throughput, which is not friendly to customers who have real-time transaction processing needs.

[0004] 2) It puts a lot of pressure on the storage capacity of node devices. In the early days, the full node of digital currency needed to synchronize the blocks of the entire network before it could perform packaging verification and other tasks. Then the node needed to store more than 100GB of blocks locally, which would undoubtedly occupy a large amount of storage space on the device.

[0005] 3) Each block has a small storage capacity. The digital currency system only stores 1MB of transaction data for each block, which will limit the efficiency of the system in the face of massive transaction data.

[0006] 4) The transaction fees for small amounts are relatively high. When using digital currency for transactions, many users will make a large number of small payments. For example, when buying daily necessities, you need to pay a fee to the miners, which is obviously not cost-effective.

[0007] There are some solutions to the above problems. To solve problem 2), the digital currency system uses light nodes, which do not require nodes to store all blocks, only block headers, so as to ensure that nodes can operate normally while reducing the storage pressure of the device; for the other three problems, some scholars have proposed the use of hard forks. Among them, Gavin advocates that the block capacity needs to be determined based on market behavior, but because it involves modifying the existing blockchain, it may affect the previous block data. There are many debates on this and it is difficult to reach a consensus; another targeted method is to use the lightning network. This technology is to establish a payment channel between digital currency network nodes for transactions. When conducting a large number of small transactions, there is no need to repeatedly confirm transactions and reduce handling fees. This is very friendly to small transactions. However, the previous design of the lightning network was not perfect, the identity privacy of the nodes was not perfect, and the payment channel path fee was not reasonable. Therefore, based on the lightning network, it is necessary to design an anonymous blockchain transaction system with cross-node payment channel fee optimization and node privacy protection. Summary of the invention

[0008] The purpose of the present invention is to improve the deficiencies in the prior art and provide a blockchain anonymous transaction method based on cross-node multi-hop payment, which solves the problems of node communication security and anonymous payment path optimization through the design of encryption, channel, and cross-node anonymous payment. The present invention can not only be applied to digital currency blockchains, but also can be applied to other electronic currency systems based on blockchain technology after certain improvements, making its transactions more efficient and ensuring the security of privacy information.

[0009] Technical solution: A blockchain anonymous transaction method based on cross-node multi-hop payment, including the following steps:

[0010] Step 1: Before a node requests a transaction, it needs to establish an encrypted session state, which is used to encrypt and authenticate messages sent between nodes. Before the node enters the identity authentication and encrypted communication state, a three-step communication handshake is required to ensure the anonymity and security of the communication.

[0011] Step 2: After the node enters the secure session state of the encryption module, it can communicate transaction information with other nodes to perform channel-related operations. Among them, the node needs to negotiate channel information with other nodes, and when both parties confirm the negotiation, the channel is established.

[0012] Step 3: When the inter-node channel is successfully established and running normally, the payment channel can be closed freely. When the channel funds are 0 or insufficient, the payment channel will be directly liquidated and closed. When both parties initiate a request to close the channel, the channel will be liquidated and closed according to the negotiated rules.

[0013] Step 4: The node can select other nodes to build a payment channel to complete cross-node anonymous payment. The selected node needs to use onion routing to hide the forwarding identity, and the node needs to consider the service fee of the selected node in the anonymous payment path to ensure anonymity.

[0014] Furthermore, the specific content of step 1 is as follows:

[0015] Step 1.1 Both nodes initialize the session state and use the SHA256 algorithm to process the handshake hash h. The sender accumulates the receiver's static public key rs into the handshake hash to obtain a new handshake hash h1, and the receiver accumulates the local static public key ls into the handshake hash to obtain a new handshake hash h2.

[0016] Step 1.2 The sender uses the elliptic curve Diffie-Hollman algorithm to obtain the shared key, and uses the HKDF algorithm to derive the new lk and temporary key tempk1, and then uses the associated data identity authentication encryption algorithm to generate plain text and send the message m. The receiver verifies the version of the message m, and uses the elliptic curve Diffie-Hollman algorithm, HKDF algorithm and associated data identity authentication encryption algorithm to obtain the shared key and other identity authentication information to determine the sender's identity.

[0017] Step 1.3 The receiver replies to the handshake request, uses the elliptic curve Diffie-Hollman algorithm to obtain the shared key, and uses the HKDF algorithm to derive the new lk and temporary key tempk2, then uses the associated data identity authentication encryption algorithm to generate plain text and send the message m. The sender verifies the version of the message, parses the receiver's message, and determines the receiver's identity.

[0018] Step 1.4 The sender sends a handshake message to the receiver, and the receiver confirms the handshake message. Both parties obtain the final decryption key and session encryption. To ensure anonymity and security, the elliptic curve Diffie-Hollman key exchange algorithm is required to negotiate the shared key. During this period, the sender does not expose his public key. Only after the three-way handshake can the receiver successfully recover the sender's public key.

[0019] Furthermore, the specific contents of step 2 are:

[0020] Step 2.1 The sender first needs to send an OPEN message to the receiver to apply for opening the channel. The OPEN message includes the hash blockhash of the block where the applied channel is located, the channel tempID, the fund used by the sender to establish the channel, and the relevant transaction amount upper limit, threshold and other protocol contents.

[0021] Step 2.2 After receiving the OPEN message, the receiving node first judges the content of the protocol. If satisfied, the receiving node sends an ACCEPT message of the receiving channel to the sender, indicating that it agrees to the sender's request to establish a channel. Otherwise, the receiving node can reject the establishment application.

[0022] In step 2.3, after the sender receives the ACCEPT message, it receives the channel creation content. The sender sends a CFUND message to the receiver to create the channel fund transaction. The receiver sends a SFUND message to the sender. After the sender confirms, the two parties send LFUND messages to each other, indicating that the channel fund transaction has been accepted by the blockchain network, and the channel is successfully established and can operate normally.

[0023] Furthermore, the specific contents of step 3 are:

[0024] Step 3.1 When the channel funds are 0, they will be directly cleared. If the channel funds cannot meet normal transactions, the funds will be distributed to the party that receives the funds based on the last transaction and settlement negotiation, and then the channel will be automatically cleared.

[0025] Step 3.2 When both parties in the channel want to close the transaction channel in advance, the initiator sends a SHUTDOWN message to the receiver to indicate that it wants to apply to close the channel. The receiver approves the message and returns the SHUTDOWN message to the initiator. At this time, the HTLC on the channel is cleaned up to ensure that the remaining HTLC can be processed.

[0026] After step 3.3 is completed, the two parties will enter the channel closing settlement negotiation stage. The initiator will send a SCLOSING message, which contains the channel closing information. If both parties agree to the agreement, the channel will be closed.

[0027] Furthermore, the specific contents of step 4 are:

[0028] Step 4.1 The node discovers other nodes through the gossip protocol. Among them, the node maintains the local network view through three gossip messages.

[0029] Step 4.2 After the sender determines the receiver, a relatively optimal path is selected from the local network view based on the routing selection combined with the path channel cost and the forwarding anonymous message cost algorithm.

[0030] After determining the cross-node anonymous payment path in step 4.3, the sender obtains the public keys of all nodes on the path to encrypt the data packet, starts constructing the data packet in the reverse direction of the path, and generates a shared key for encryption and decryption through the elliptic curve Diffie-Hollman key exchange algorithm.

[0031] Beneficial effects: The present invention introduces an anonymous payment layer based on the digital currency network, which can enhance the security of node communication involved in the transaction and provide secure session protection for both parties of the transaction. In an anonymous environment, a payment channel between nodes is established to speed up the transaction. At the same time, the most cost-effective anonymous payment path is found for each node, which enhances anonymity while reducing service consumption costs.

[0032] Beneficial effects of the present invention:

[0033] (1) Realize communication security between nodes

[0034] Before a node conducts a lightning transaction, it needs to establish a secure session, which uses the Elliptic Curve Diffie-Hollman Key Exchange Algorithm and the Associated Data Authentication Algorithm to encrypt data to ensure data security and secure session establishment.

[0035] (2) Ensure that nodes can quickly pay for transactions

[0036] It has the channel establishment function. After the two nodes negotiate the terms such as channel funds and transaction fees and both parties agree, the channel can be successfully established and managed. At the same time, the channel can be revoked and the funds can be returned when the funds are exhausted or one party applies for termination.

[0037] (3) Meeting the needs of cross-node anonymous payment

[0038] Provide cross-node anonymous payment. The node determines a cross-node anonymous payment path based on the routing selection algorithm and makes anonymous payments on this path, ensuring user privacy and security while ensuring that the cost required for the cross-node payment path is optimal. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 Schematic diagram of the logic architecture of the present invention

[0040] Figure 2 This is the first step flow chart of the handshake of the encryption module of the present invention

[0041] Figure 3 The second step flow chart of the handshake of the encryption module of the present invention

[0042] Figure 4 The third step flow chart of the handshake of the encryption module of the present invention

[0043] Figure 5 Establishing a channel flow chart for the present invention

[0044] Figure 6 Flow chart of closing channel for the present invention

[0045] Figure 7 This is a diagram of the cross-node payment process of the present invention DETAILED DESCRIPTION

[0046] The present invention proposes a blockchain anonymous transaction method for cross-node multi-hop payment, which is used for small-amount fast transactions on blockchain, hereinafter referred to as the cross-node anonymous transaction method. The steps are as follows: 1. User connection: Before the user node participates in the transaction, the nodes participating in the transaction enter the encrypted session state through the encryption module to encrypt and authenticate the messages between the nodes. 2. Channel establishment: After the user node enters the encrypted session state, the two nodes negotiate to establish a payment channel. Before the channel balance is cleared, the two nodes can apply to close the payment channel in advance. 3. Anonymous payment: The user node can select nodes that already have channels, which forward the user node transaction information for a fee. The user node determines the payment path with the best cost through the local network view to complete the cross-node anonymous payment. Cross-node anonymous transactions ensure the communication security of the two parties to the transaction by establishing a secure session before the transaction; by establishing a payment channel, the node can select a node with a high cost-effective channel to generate an anonymous payment path. Cross-node anonymous transactions can achieve the effect of fast and anonymous transactions while ensuring the optimal transaction cost.

[0047] The following describes the embodiments of the present invention in detail with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for explaining the present invention, but the protection scope of the present invention is not limited to the embodiments.

[0048] The method of the present invention can be applied not only to digital currency blockchain, but also to other electronic currency systems based on blockchain technology through improvement. The following is a detailed description with reference to the accompanying drawings.

[0049] like Figure 1 As shown in the diagram of the system logic architecture, the bottom layer of this system is the digital currency layer, and the anonymous payment layer consists of three parts: distributed ledger, P2P network and consensus mechanism. The distributed ledger of the digital currency layer is the underlying data storage structure, which is used to store block data from the genesis block to the present, as well as data permanently stored in the distributed ledger after the transaction between nodes is published and authenticated by the whole network. In addition to historical transaction data, it also includes channel data and node transaction data in the anonymous payment layer; the anonymous payment layer, as the second layer, is mainly composed of three modules: encryption, channel and anonymous payment. The encryption module is responsible for the encryption and identity authentication of the information sent by the node before establishing the channel, so that the nodes can communicate safely and avoid attacks such as middlemen, data tampering, and data eavesdropping; the channel module handles the channel discovery, establishment, maintenance and management between the nodes of the lightning network, so that the nodes can use the channel to quickly participate in small transactions, and act as the role of the intermediate node; the anonymous payment module mainly handles cross-node multi-hop anonymous payment between nodes. The payment requires the node to calculate a relatively optimal path from the local view according to the path selection algorithm. After that, the node performs anonymous payment operations.

[0050] A blockchain anonymous transaction method based on cross-node multi-hop payment in this embodiment is as follows:

[0051] Each node of the present invention has its own long-term wallet identification information, which is the address public key of the digital currency wallet. The public key is used to establish an encrypted and authenticated connection with the peer node and serves as the source authentication of any information in the anonymous payment layer.

[0052] Step 1: Before a node requests a transaction, it needs to establish an encrypted session state with other nodes, which is used to encrypt and authenticate messages sent between nodes. Before the node enters the identity authentication and encrypted communication state, a three-step communication handshake is required to ensure the anonymity and security of the communication. Specifically, it includes:

[0053] Step 1.1 Both nodes initialize the session state and use the SHA256 algorithm to process the handshake hash h, which contains the link key lk. The sender accumulates the receiver's static public key rs into the handshake hash to obtain a new handshake hash h1, and the receiver accumulates the local static public key ls into the handshake hash to obtain a new handshake hash h2. Among them, the key will be serialized when it is accumulated into h.

[0054] Step 1.2 Figure 2 As shown in the first step of the encryption module handshake flowchart, the sender first generates its own temporary key pair tk1, accumulates the public key into h1, and then uses the private key of tk1 and rs to perform the elliptic curve Diffie-Hollman algorithm to obtain the shared key tks, and then uses the HKDF algorithm to derive the key from tks and lk to obtain the new lk and temporary key tempk1. Among them, the HKDF algorithm obtains a part of the key material and derives one or more keys with higher security from it. Finally, the authentication encryption algorithm for tempk1 and h1 using the associated data generates the plaintext c, accumulates c into h1, and then sends c and the public key of tk1 as the message m to the receiver.

[0055] Step 1.3 After the receiver receives m, it first performs a version check. If the check fails, it stops responding. Then it extracts the public keys of c and tk1 from m, with the public key of tk1 being used as the value of rtk1. rtk1 is accumulated into h2. The elliptic curve Diffie-Hollman algorithm is used with rtk1 and the private key of its own static key s to obtain the result shared key tks. Similarly, the HKDF algorithm is used to derive the key from tks and lk to obtain the new lk and tempk1. Then, tempk1, h2 and c are used to perform the authentication encryption algorithm decryption operation using the associated data to obtain the result p for MAC verification. If the verification fails, the receiver stops responding. Then c is accumulated and calculated to obtain h2.

[0056] Step 1.4 Figure 3As shown in the flowchart of the second step of the encryption module handshake, the receiver generates its own temporary key pair tk2, accumulates its public key into h2, and uses the public key of tk2 and rtk1 in the first step to perform the elliptic curve Diffie-Hollman algorithm to obtain the shared key tkk. Similarly, the HKDF algorithm is used to derive the keys lk and tempk2 through lk and tkk. Finally, the authentication encryption algorithm is used with tempk2 and h2 using the associated data to obtain the plaintext c and accumulate it into h2. Finally, the public key of tk2 and c are sent to the sender as the message m.

[0057] Step 1.5 Upon receiving the message m, the sender first performs a version check, then extracts the public keys of c and tk2, uses the public key of tk2 as the value of rtk2 and accumulates it into h1, then performs the elliptic curve Diffie-Hollman algorithm on lk and rtk2 to obtain the shared key tkk, and similarly uses the HKDF algorithm to derive the keys lk and tempk2 from lk and tkk, uses tempk2, h1 and c to perform the authentication encryption algorithm decryption operation using associated data to obtain p for MAC verification, and finally accumulates c into h1.

[0058] Step 1.6 Figure 4 As shown in the flowchart of the third step of the encryption module handshake, the sender obtains c by encrypting tempk2, h1 and the serialized public key of its own static key s using the associated data authentication encryption algorithm and accumulates it into h1. Then, the private key of s and rtk2 are used through the elliptic curve Diffie-Hollman algorithm to obtain the shared key srk. The HKDF algorithm is used to derive the keys of lk and srk to obtain lk and tempk3. The value of the plaintext t is the result of tempk3 and h1 using the associated data authentication encryption algorithm. Finally, the HKDF algorithm is used to derive the key of lk to obtain fsk and frk, where fsk is the key used by the sender to encrypt the information, and frk is the key used by the sender to decrypt the information. Then c and t are sent to the receiver as message m.

[0059] Step 1.7 After receiving the message m, the receiver performs version verification, extracts c and t, and then uses tempk2, h2 and c to perform the decryption operation using the associated data authentication encryption algorithm to obtain the public key of the sender's static key s, accumulates c into h2, and then performs the elliptic curve Diffie-Hollman algorithm on the private key of tk2 and the public key of s to obtain the shared key srk, and then uses the HKDF algorithm to derive the keys lk and tempk3 on lk, and finally uses the associated data authentication encryption algorithm to decrypt t for MAC verification, and then uses lk to perform HKDF key derivation fsk and frk, and the handshake ends.

[0060] Step 1.8 Both parties finally obtain the decryption key and session encryption. To ensure anonymity and security, the elliptic curve Diffie-Hollman algorithm is required to negotiate the shared key. During this process, the sender does not expose his public key. Only after the three-way handshake can the receiver successfully recover the sender's public key.

[0061] Step 2: After the node enters the secure session state of the encryption module, it can communicate transaction information with other nodes to perform channel-related operations. The node needs to negotiate channel information with other nodes, and when both parties confirm the negotiation, the channel is established. Specifically, it includes:

[0062] Step 2.1 Figure 5 As shown in the flow chart of establishing a channel, the sender first needs to send an OPEN message to the receiver to apply for opening the channel. The OPEN message includes the block hash blockhash where the channel is applied, the channel tempID, the fund of the sender to establish the channel, and the relevant transaction amount upper limit, threshold and other protocol contents.

[0063] Step 2.2 After receiving the OPEN message, the receiver first judges the content of the agreement. After the receiver agrees to the agreement, the receiver sends an ACCEPT message of the acceptance channel to the sender, indicating that it agrees to the sender's request to establish a channel. Otherwise, the receiver can reject the establishment application. The ACCEPT message includes tempID and the content of the transaction agreement.

[0064] Step 2.3 After receiving the ACCEPT message, the sender determines the transaction agreement content in the message. After accepting the agreement content, the sender sends a CFUND message to the receiver to create a channel funding transaction. Otherwise, the sender refuses to establish the channel.

[0065] Step 2.4: The CFUND message includes the actual channel ID of the channel, the ID of this transaction, and its own signature. After receiving the CFUND message, the receiver first verifies whether the signature belongs to the sender. Otherwise, the message is discarded. If the verification is successful, the receiver sends a SFUND message to the sender. The SFUND message includes the signature and channel ID of this transaction, indicating that the transaction is approved.

[0066] Step 2.5 After the sender receives the SFUND message, it also performs signature verification first. After passing the verification, the channel fund transaction can be broadcast to the blockchain network. After waiting for the node on the blockchain network to authenticate the transaction information block, the two parties send each other LFUND messages containing the channel chain confirmation information. After this message is sent to each other, it means that the fund transaction channel has been officially accepted by the blockchain network and both parties can participate in the transaction.

[0067] After the channel is successfully established in step 2.6, the nodes of both parties can directly conduct transactions not exceeding the channel funding limit through the channel. After each small transaction is completed, the remaining funds in the channel will be updated without the need to broadcast each transaction to the entire blockchain network.

[0068] Step 3: If the inter-node channel is successfully established and running normally, the payment channel can be closed freely. When the funds are insufficient, the payment channel will be directly liquidated and closed. When the transaction parties initiate a request to close the channel, the channel will be liquidated and closed according to the negotiated rules. Specifically:

[0069] Step 3.1 When the channel funds are 0, liquidation will be carried out directly, or when the channel funds cannot meet the transaction, the system will automatically clear the channel according to the agreement.

[0070] Step 3.2 Figure 6 As shown in the channel closing flow chart, when both parties of the channel close the transaction channel in advance, the initiator sends a SHUTDOWN message to the receiver to indicate that it wants to apply to close the channel. The SHUTDOWN message includes the channel ID and the public key of the digital currency script. After the receiver approves it, a SHUTDOWN message is returned to the initiator. At this time, the hash time lock contract (HTLC) on the channel is cleared to ensure that the remaining HTLC can be processed.

[0071] Step 3.3 After the HTLC is cleared, it means that the channel closing settlement negotiation phase has begun. The initiator sends a SCLOSING message to indicate that it is negotiating the settlement with the receiver. The SCLOSING information includes the channel ID, settlement fee, and its own signature. After receiving the SCLOSING message, the receiver first performs signature verification. After the verification passes, it determines the settlement content. If it agrees with the settlement content, it sends a SCLOSING message to the initiator. The message includes the channel ID, the same settlement fee, and its own signature. After receiving the SCLOSING message, the initiator can broadcast the final transaction to the entire network, and after waiting for the main chain certification, it can end the transaction and close the channel.

[0072] Step 3.4 If the two parties disagree on the settlement information, the receiver can send a SCLOSING message with the settlement fee that it approves to the initiator. If the initiator is not satisfied with the settlement fee, the two parties will continue to send SCLOSING messages for negotiation. When the negotiation times threshold is reached, the initiator will be punished and the channel will be closed.

[0073] Step 4: The node can select other nodes to build a payment channel to complete cross-node anonymous payment. The selected node needs to use onion routing to hide the forwarding identity, and the node needs to consider the service fee of the selected node in the anonymous payment path to ensure anonymity. Specifically:

[0074] Step 4.1 The node discovers nodes and obtains information through the gossip protocol. Among them, the node maintains the local network view through three gossip messages.

[0075] In step 4.2, a gossip message is used to broadcast the BroadcastChannel message of an existing channel. The BroadcastChannel message is used to identify the only existing channel, including all messages about the channel, such as the channel connection node, the cost of the node forwarding anonymous messages, and the channel transaction fee.

[0076] The two gossip messages in step 4.3 are UpdateChannel messages, which are used to update the latest information about the channel. When a node receives a new BroadcastChannel or UpdateChannel message, it will update the content of the message to its local network view. If a channel is revoked due to exhaustion of funds, the local view will delete the information about the channel in its local view based on the message, and then add the message to the list of sent messages.

[0077] In step 4.4, to determine a cross-node anonymous payment path, the node needs to select a relatively optimal path based on the path selection algorithm on its local view.

[0078] When calculating the path in step 4.5, the channel forwarding fee and the anonymous message forwarding fee need to be considered comprehensively. Because there is a possibility that the forwarding fee of each channel in the network and the anonymous message forwarding fee of the node connected to it may be inconsistent, we will define a path cost ratio PErate, the value of which is the ratio of the channel forwarding fee on the path to the node anonymous message forwarding fee.

[0079] For an anonymous network, the more nodes there are for forwarding anonymous messages, the safer it is. However, since more nodes mean more channels are required, the overhead will also be greater. Therefore, considering all factors, the closer the value is to 1, the higher the cost-effectiveness of the path. While ensuring security, it also ensures that the channel overhead is reasonable. To select the optimal path, it is necessary to calculate the PErate value of the path to be closer to 1 than other paths.

[0080] Step 4.6 The path algorithm is shown in Algorithm 1 below: In this algorithm, the sender needs to select a path from its local view G that can connect to the receiver. i Add it to the path list Pathlist. After the addition is completed, the algorithm starts to calculate the channel forwarding fee tmpPathfee of the path from Pathlist in sequence iAnd the node anonymous message forwarding fee tmpPeerfee i , the tmpPathfee i Equal to the HTLC basic fee basefee and other fees such as forwarding tfee i Then calculate the PErate of the path i =tmpPathfee i / tmpPeerfee i If the PErate i If it is less than the current best fee bestPErate, then record the path and update bestPErate i and the value of the best path bestpath until all paths in Pathlist are calculated, and the best path bestpath and the best cost bestPErate are returned.

[0081]

[0082]

[0083] Step 4.7 Figure 7 The cross-node payment process is shown in the figure: After determining the cross-node anonymous payment path, the sender obtains the public keys of all nodes on the path to encrypt the data packet. Then the sender starts to construct the data packet in the reverse direction of the path. The innermost layer is the original data content, version number and payload to be sent. The payload can be used for HMAC verification and final node verification. After packaging is completed, the data packet is encrypted with the public key of the recipient, and then the data packet is encrypted with the public keys of the nodes in the reverse direction of the path.

[0084] Step 4.8 To ensure the secure transmission of anonymous data packets, the data packets sent between nodes are encrypted and decrypted by generating a shared key through the elliptic curve Diffie-Hollman key exchange algorithm. The sender uses its temporary private key Temprivkey and the receiver's public key Publickey as input to perform the elliptic curve Diffie-Hollman algorithm to obtain the shared key SKey. The receiver uses its temporary public key Tempubkey and its private key Privatekey as input to perform the elliptic curve Diffie-Hollman algorithm to obtain the same shared key SKey. The SKey is used as the security key for transmission between nodes to ensure the security of data packets sent between nodes.

[0085] Step 4.9 Each node in the anonymous payment path continuously transmits the transaction data packet to the final node. After receiving the anonymous data packet, the receiving node performs HMAC verification and determines whether it is the final receiving node.

[0086] Step 4.10 The final node will check the payload value of the data packet and return an error message if an error occurs. It will compare the value in the data packet with the HTLC value it received. If the result does not match, the final node can directly discard the data packet.

[0087] The series of detailed descriptions listed above are only specific descriptions of feasible implementation methods of the present invention. They are not intended to limit the scope of protection of the present invention. All equivalent methods or changes that do not deviate from the technical creation of the present invention should be included in the scope of protection of the present invention.

Claims

1. A blockchain anonymous transaction method based on cross-node multi-hop payment, characterized in that: The steps include: Step 1: Before a node requests a transaction, it needs to establish an encrypted session state, which is used to encrypt and authenticate messages sent between nodes. Before the node enters the identity authentication and encrypted communication state, a three-step communication handshake is required to ensure the anonymity and security of the communication. Step 2: After the node enters the secure session state of the encryption module, it can communicate transaction information with other nodes to perform channel-related operations; the node needs to negotiate channel information with other nodes, and when both parties negotiate and confirm, the system establishes a channel; the specific process includes: Step 2.1 The sender first needs to send an OPEN message to the receiver to apply for opening the channel. The OPEN message includes the block hash blockhash where the channel is applied, the channel tempID, the fund used by the sender to establish the channel, and the relevant transaction amount limit and threshold protocol content; Step 2.2 After receiving the OPEN message, the receiver first determines the content of the agreement. After agreeing to the agreement, the receiver sends an ACCEPT message of the acceptance channel to the sender, indicating that it agrees to the sender's request to establish a channel. Otherwise, the receiver rejects the request to establish a channel. The ACCEPT message includes tempID and the content of the transaction agreement. Step 2.3 After receiving the ACCEPT message, the sender determines the transaction agreement content in the message. After accepting the agreement content, the sender sends a CFUND message to the receiver to create a channel funding transaction. Otherwise, the sender refuses to establish the channel. Step 2.4 After receiving the CFUND message, the receiver first verifies whether the signature belongs to the sender. If not, the message is discarded. If the verification is successful, the receiver sends a SFUND message to the sender. Step 2.5 After the sender receives the SFUND message, it also performs signature verification first. After passing the signature verification, the channel fund transaction can be broadcast to the blockchain network. After waiting for the block certification, both parties send LFUND messages to each other, indicating that the fund transaction channel has been accepted by the blockchain network and can participate in the transaction; Step 2.6 After the channel is successfully established, the nodes of both parties can directly conduct transactions not exceeding the channel fund limit through the channel. After each small transaction is completed, the remaining funds in the channel will be updated, and there is no need to broadcast each transaction to the entire blockchain network; Step 3: When the inter-node channel is successfully established and running normally, the payment channel can be closed freely. When the channel funds are 0 or insufficient, the system directly clears and closes the payment channel. When both parties initiate a request to close the channel, the system clears and closes the channel according to the negotiated rules. Step 4: The node can select other nodes to build a payment channel to complete cross-node anonymous payment; the selected node needs to use onion routing to hide the forwarding identity, and the node needs to consider the service fee of the selected node in the anonymous payment path to ensure anonymity; The specific process includes: Step 4.1 The node discovers nodes and obtains information through the gossip protocol; the node maintains the local network view through three gossip messages; Step 4.2: To determine a cross-node anonymous payment path, the node selects a relatively optimal path based on its local view according to the path selection algorithm; Step 4.3: When calculating the optimal path, the channel forwarding fee and the anonymous message forwarding fee need to be considered comprehensively. Since the forwarding fee of each channel in the network and the anonymous message forwarding fee of the node connected to it may be inconsistent, a path cost ratio PErate is defined. The value of PErate is the ratio of the channel forwarding fee and the node anonymous message forwarding fee on the path. Step 4.4 The optimal path algorithm is: the sender needs to select a path from its local view G that can connect to the receiver. i Add to the path list Pathlist, and after adding, start calculating the channel forwarding fee tmpPathfee of the path from Pathlist in sequence i And the node anonymous message forwarding fee tmpPeerfee i , the tmpPathfee i Equal to the HTLC basic fee basefee and the forwarding other fees tfee i Then calculate the PErate of the path i =tmpPathfee i / tmpPeerfee i If the PErate i If it is less than the current best cost bestPErate, then record the path and update bestPErate i and the value of the best path bestpath, until all the paths of Pathlist are calculated, and bestpath and bestPErate are returned; Step 4.5 Cross-node payment: After determining the cross-node anonymous payment path, the sender obtains the public keys of all nodes on the path to encrypt the data packet. Then the sender starts to construct the data packet in the reverse direction of the path. The innermost layer is the original data content, version number and payload to be sent. The payload can be used for HMAC verification and final node verification. After packaging, the data packet is encrypted with the public key of the recipient, and then the data packets are encrypted with the public keys of the nodes in the reverse direction of the path in turn. Step 4.6 To ensure the secure transmission of anonymous data packets, the data packets sent between nodes are encrypted and decrypted by generating a shared key through the elliptic curve Diffie-Hollman key exchange algorithm. The sender uses its own temporary private key Temprivkey and the receiver's public key Publickey as input to perform the elliptic curve Diffie-Hollman algorithm to obtain the shared key SKey. The receiver uses its own temporary public key Tempubkey and its own private key Privatekey as input to perform the elliptic curve Diffie-Hollman algorithm to obtain the same shared key SKey. The SKey is used as the security key for transmission between nodes to ensure the security of data packets sent between nodes. Step 4.7 Each node in the anonymous payment path continuously transmits the transaction data packet to the final node; after receiving the anonymous data packet, the receiving node performs HMAC verification and determines whether it is the final receiving node; Step 4.8 The final node will check the payload value of the data packet and return an error message if an error occurs. It will compare the value in the data packet with the HTLC value it received. If the results do not match, the final node can directly discard the data packet.

2. A blockchain anonymous transaction method based on cross-node multi-hop payment according to claim 1, characterized in that: The specific process of step 1 includes the following: Step 1.1, both nodes initialize the session state and use the SHA256 algorithm to process the handshake hash h, which contains the link key lk; the sender accumulates the receiver's static public key rs into the handshake hash to obtain a new handshake hash h1, and the receiver accumulates the local static public key ls into the handshake hash to obtain a new handshake hash h2; when the key is accumulated into h, the key will be serialized; Step 1.2, the first step of the encryption module handshake: the sender first generates its own temporary key pair tk1, accumulates the public key into h1, and then uses the private key of tk1 and rs to perform the elliptic curve Diffie-Hollman algorithm to obtain the shared key tks, and then uses the HKDF algorithm to derive the key from tks and lk to obtain the new lk and the temporary key tempk1; the HKDF algorithm obtains a part of the key material and derives one or more keys with higher security from it, and finally starts to use the associated data to perform the authentication encryption algorithm on tempk1 and h1 to generate the plaintext c, accumulate c into h1, and then send c and the public key of tk1 as the message m to the receiver; Step 1.3 After receiving m, the receiver first performs a version check. If the check fails, the receiver stops responding. Then, the receiver extracts the public keys of c and tk1 from m as the value of rtk1, accumulates rtk1 into h2, and uses rtk1 and the private key of its own static key s to perform the elliptic curve Diffie-Hollman algorithm to obtain the result shared key tks. Similarly, the HKDF algorithm is used to derive the key from tks and lk to obtain the new lk and tempk1. Then, tempk1, h2, and c are used to perform the authentication encryption algorithm decryption operation using the associated data to obtain the result p for MAC verification. If the verification fails, the receiver stops responding, and then accumulates c for calculation to obtain h2. Step 1.4 Encryption module handshake step 2: The receiver generates its own temporary key pair tk2, accumulates its public key into h2, uses the public key of tk2 and rtk1 in the first step to perform the elliptic curve Diffie-Hollman algorithm to obtain the shared key tkk, and similarly uses lk and tkk to derive the keys lk and tempk2 using the HKDF algorithm. Finally, use tempk2 and h2 to perform the authentication encryption algorithm using the associated data to obtain the plaintext c and accumulate it into h2. Finally, use tk2's public key and c as the message m to send to the sender. Step 1.5 Upon receiving the message m, the sender first performs version verification, then extracts c, the public key of tk2 as the value of rtk2 and accumulates it into h1, then performs the elliptic curve Diffie-Hollman algorithm on lk and rtk2 to obtain the shared key tkk, and similarly uses the HKDF algorithm to derive the keys lk and tempk2 from lk and tkk, uses tempk2, h1 and c to perform the authentication encryption algorithm decryption operation using the associated data to obtain p for MAC verification, and finally accumulates c into h1; Step 1.6 Encryption module handshake step 3: The sender obtains c by encrypting tempk2, h1 and the serialized public key of its own static key s using the associated data authentication encryption algorithm and accumulates it into h1. Then, the private key of s and rtk2 are encrypted using the elliptic curve Diffie-Hollman algorithm to obtain the shared key srk. The HKDF algorithm is used to derive the key from lk and srk to obtain lk and tempk3. The value of the plaintext t is the result of tempk3 and h1 using the associated data authentication encryption algorithm. Finally, the HKDF algorithm is used to derive the key from lk to obtain fsk and frk, where fsk is the key used by the sender to encrypt the information, and frk is the key used by the sender to decrypt the information. Then c and t are sent to the receiver as the message m. Step 1.7 After receiving the message m, the receiver performs version verification, extracts c and t, and then uses tempk2, h2 and c to perform the encryption algorithm for authentication using associated data to decrypt and run to obtain the public key of the sender's static key s, accumulates c into h2, and then performs the elliptic curve Diffie-Hollman algorithm on the private key of tk2 and the public key of s to obtain the shared key srk, and then uses the HKDF algorithm to derive the keys lk and tempk3 from lk, and finally uses the encryption algorithm for authentication using associated data to decrypt t for MAC verification, and then uses lk to perform HKDF key derivation fsk and frk, and the handshake ends; In step 1.8, both parties finally obtain the decryption key and session encryption. To ensure anonymity and security, the elliptic curve Diffie-Hollman algorithm is required to negotiate the shared key. During this process, the sender does not expose his public key. Only after the three-way handshake can the receiver successfully recover the sender's public key.

3. A blockchain anonymous transaction method based on cross-node multi-hop payment according to claim 1, characterized in that: The CFUND message includes the actual channel ID of the channel, the ID of this transaction and its own signature; the SFUND message includes the signature of this transaction and the channel ID, indicating approval of the transaction.

4. A blockchain anonymous transaction method based on cross-node multi-hop payment according to claim 1, characterized in that: The specific process of step 3 includes: Step 3.1 When the channel funds are 0, liquidation will be carried out directly, or when the channel funds cannot meet the transaction, the system will automatically clear the channel according to the agreement; Step 3.2: When both parties of the channel close the transaction channel in advance, the initiator sends a SHUTDOWN message to the receiver to indicate that it wants to apply to close the channel. The SHUTDOWN message includes the channel ID and the script public key. After the receiver approves it, it returns a SHUTDOWN message to the initiator. At this time, the system starts to clean up the HTLC on the channel to ensure that the remaining HTLC is processed. Step 3.3 After the HTLC is cleared, it means that the channel closing settlement negotiation phase has begun. The initiator sends a SCLOSING message to indicate that it is negotiating the settlement with the receiver. The SCLOSING message includes the channel ID, settlement fee, and its own signature. After receiving the SCLOSING message, the receiver first performs signature verification. After the verification passes, it determines the settlement content. If it agrees with the settlement content, it sends a SCLOSING message to the initiator. The message includes the channel ID, the same settlement fee, and its own signature. After receiving the SCLOSING message, the initiator broadcasts the final transaction to the entire network, and after waiting for the main chain certification, it can end the transaction and close the channel. Step 3.4 If the two parties disagree on the settlement information, the receiver can send a SCLOSING message with the settlement fee that it approves to the initiator. If the initiator is not satisfied with the settlement fee, the two parties will continue to send SCLOSING messages for negotiation. When the system negotiation times threshold is reached, the system will punish the initiator and close the channel.

5. A blockchain anonymous transaction method based on cross-node multi-hop payment according to claim 1, characterized in that: The three gossip messages in step 4.1 are: A BroadcastChannel message for broadcasting an existing channel. This message identifies the only existing channel, including the node connected to the channel, the cost of the node forwarding anonymous messages, the channel transaction fee, and all other information about the channel; Two UpdateChannel messages, which are used to update the latest information about the channel. When a node receives a new BroadcastChannel or UpdateChannel message, it will update the content of the message to its local network view. If a channel is revoked, the local view will delete the information about the channel in its local view based on the message, and then add the message to the list of sent messages.

6. A blockchain anonymous transaction method based on cross-node multi-hop payment according to claim 1, characterized in that: The closer the path cost to PErate value in step 4.3 is to 1, the higher the cost performance of the path is. While ensuring security, the channel cost is also reasonable. To select the optimal path, it is necessary to calculate the PErate value of the path closer to 1 relative to other paths.

Images