Payment path hard constraint forwarding method based on topology locking

Abstract

The invention discloses a payment path hard constraint forwarding method based on topology locking, and relates to the technical field of block chain payment channel networks, computer network routing control and encrypted communication. The method comprises the following steps: a payment initiator linearly couples a global identifier, a node identity identifier and a node sequence number of a preset payment path through a hash function according to a node sequence of the preset payment path to generate a control key; constructing a self-routing data packet according to the control key, wherein the self-routing data packet comprises a path topology anchor point, a path up-down field and a path control field; the relay node carries out blind decryption and topology verification on the self-routing data packet, and forwards the self-routing data packet according to a preset path after verification is passed; and the receiver decrypts the data packet and triggers the settlement logic after confirming that the path is compliant. According to the method, the calculation overhead of the relay node is remarkably reduced while path enforcement is guaranteed, and the method is suitable for a high-frequency and large-amount multi-path payment scene.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of blockchain payment channel network, computer network routing control and encrypted communication technology, in particular to a payment path hard constraint forwarding method based on topology locking. BACKGROUND

[0002] The blockchain payment channel network (PCN, such as lightning network) realizes extremely high transaction speed through off-chain point-to-point channels. In order to solve the problem of single channel liquidity exhaustion, multi-path payment (MPP) technology is widely used, that is, a large payment is split into multiple sub-payment fragments, which are transmitted in parallel through different paths in the network. At present, the security and privacy of these paths mainly rely on onion routing technology, which hides the sender, receiver and intermediate path information through multi-layer nested encryption. Although the existing onion routing scheme performs well in privacy protection, in the large-scale, high-frequency complex network environment, there are still the following technical blind spots to be solved: (1) "soft isolation" problem of path topology constraint: in the traditional onion routing, the relay node's perception of the path is limited to "previous hop" and "next hop". Due to the lack of a mandatory topology binding mechanism, malicious relay nodes may use route redirection or path shortening attacks to maliciously direct data packets to high-cost channels or areas controlled by malicious nodes. The existing verification mechanism is mostly based on "after-the-fact discovery" of signatures, which cannot achieve "physical-level" path deviation blocking; (2) "computational load bottleneck" in high-frequency payment scenarios: in order to ensure security, existing technologies often introduce complex digital signature verification or multi-layer key tree retrieval. In the micro-payment and high-frequency transaction scenario, each relay node needs to perform asymmetric encryption operations, which results in huge computational overhead and processing delay. When the payment request reaches ten thousand per second (TPS), the traditional strong verification mode will cause the relay node to become a bottleneck of network congestion; (3) contradiction between stateless forwarding and deterministic execution: payment networks pursue "stateless" forwarding of nodes to improve scalability, but statelessness means that nodes cannot perceive the whole picture of the path. How to enable nodes to automatically identify and reject data packets that do not follow the preset topology order without increasing the storage burden of nodes is a "hard constraint" capability that is currently lacking in multi-path payment protocols.

[0003] In summary, the existing multi-path payment initiation scheme lacks an effective balance between "enforcement of path execution" and "efficiency of forwarding". Therefore, there is an urgent need for a new forwarding mechanism that can directly inject network topology into encryption logic, enabling data packets to have "path self-deconstruction" capability without complex signature verification. SUMMARY

[0004] The purpose of this invention is to provide a payment path hard constraint forwarding method based on topology locking, which aims to solve or improve at least one of the above-mentioned technical problems.

[0005] To achieve the above objectives, the present invention provides the following solution: A payment path hard-constraint forwarding method based on topology locking includes the following steps: The payment initiator generates a control key by linearly coupling the global identifier, node identity identifier, and node sequence number of the preset payment path using a hash function, based on the node sequence of the preset payment path. A self-routing data packet is constructed based on the control key, and the self-routing data packet includes a path topology anchor point, a path context field, and a path control field. The relay node performs blind decryption and topology verification on the self-routing data packets, and forwards them according to the preset path after passing the verification. The settlement logic is triggered after the recipient decrypts the data packet and confirms that the path is compliant.

[0006] Furthermore, the formula for generating the control key is: in, It is a one-way hash function. The path root seed is randomly generated by the payment initiator. For global identification, For node sequence number, Used as a node identity identifier.

[0007] Furthermore, the path topology anchor point is encrypted by the control key of the corresponding node and contains topology index information pointing to the next node. The node at the correct path position can decrypt the information to obtain the next instruction.

[0008] Furthermore, the path context field is used to encode the path identifier and hop count counter.

[0009] Furthermore, the path control field contains instructions related to the current path forwarding.

[0010] Furthermore, the blind decryption and topology verification steps of the relay node are specifically as follows: After receiving the data packet, the relay node calculates the control key using the locally stored global identifier, its own node identity identifier, and the current sequence number, and decrypts the topology anchor point. If the decrypted plaintext does not conform to the preset protocol format, the data packet is determined to have deviated from the preset path and is discarded directly.

[0011] Furthermore, after the relay node successfully decrypts the topology anchor, it compares the consistency between the hop count counter in the data packet and the encoded path identifier. After confirming that its forwarding behavior is legitimate, it decrypts the current encryption layer and forwards the remaining data packets to the next node.

[0012] Furthermore, the recipient decrypts the data packet using the final control key and triggers the settlement logic after confirming that the payment fully follows the preset path.

[0013] The present invention discloses the following technical effects: This invention simplifies the complexity of key derivation by deeply coupling the unique path identifier with the node topology position, while eliminating the risk of key misappropriation or illegal extraction across paths. This invention achieves a "hard constraint" security effect by explicitly encoding the path sequence logic in the data layer. This effect ensures that if the path deviates from the preset trajectory, the data packet logic will fail and cannot be decrypted, thus fundamentally preventing path hijacking and malicious redirection. This invention utilizes a lightweight hash check instead of a heavy asymmetric digital signature verification, which greatly reduces the computational load of relay nodes, effectively solves the computational load bottleneck problem in high-frequency payment scenarios, and improves the system's concurrent processing capability. This invention encapsulates complete routing execution instructions within a packet, eliminating the need for relay nodes to maintain any intermediate path states. This significantly enhances the horizontal scalability of the payment channel network and meets the deployment requirements of large-scale payment networks. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is a diagram of the overall architecture of the present invention; Figure 2 This is a schematic diagram of the self-destructing nested encryption packet of the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0018] As shown in Figure 1, the overall architecture of this invention includes a payer, an intermediary node, and a payee. The payer generates a key chain by generating information such as path root seed and path identifier, and sends a self-routing data packet containing topology anchor point, path context, and path control field to the intermediary node. The intermediary node achieves stateless forwarding of data packets through blind decryption and topology verification. Finally, the payee completes decryption and triggers the settlement logic.

[0019] As shown in Figure 2, the self-destructing nested encryption packet adopts a multi-layer nested structure. Each layer contains a TA (Topology Anchor) path topology anchor, a PC (Path Context) path context field, and a (Control Payload) path control field. Through layer-by-layer encryption, hard constraint control of the path is achieved. Only nodes in the preset path order can be decrypted in sequence and the next hop node information can be obtained.

[0020] The specific implementation steps are as follows: The payment initiator (sender) selects a payment path containing n relay nodes based on the current network topology: .

[0021] Step 1-1: The sender assigns a globally unique path identifier to this payment task. .

[0022] Step 1-2: Determine the absolute sequence number of each node in the path. (e.g., the first jump is 1, the second jump is 2).

[0023] Steps 1-3: Obtain the public identity information of each relay node .

[0024] Generation of linear topological hash chains: The sender generates a linearly coupled key chain in the order of the paths: Step 2-1: The sender randomly generates a path root seed. .

[0025] Step 2-2: Using a hash function Perform linear derivation: the Jump topology session key .

[0026] Construct a self-routing packet with a "topology anchor": Step 3-1: Encapsulate the forwarding command in a container with... In encrypted payload.

[0027] Step 3-2: Design a TA field in the header of each layer of encryption packet to encapsulate the path anchor, and set the content to... This field describes the route index for the next hop.

[0028] Step 3-3: Through multiple iterations of encryption, a complete self-routing data packet is formed.

[0029] "Blind decryption" and topology verification of relay nodes: As a relay node Upon receiving a data packet, it will execute the following stateless processing logic: Step 4-1: The node utilizes locally known... , one’s own and the current Real-time calculation .

[0030] Step 4-2: If the decrypted result is... Consistent with the packet header declaration, this indicates that the packet arrived at this node strictly following the preset path, and the node retrieved the next-hop instruction. If path hijacking causes an incorrect node order, decryption will produce garbled characters, the node will be unable to obtain the next-hop address, and the data packet will logically become invalid and be discarded.

[0031] Step 4-3: The node decrypts the current encryption layer and forwards the remaining part to the next hop. The whole process does not involve complex signature verification.

[0032] Deterministic feedback of path execution results Step 5-1: When the data packet finally arrives at the receiver, the receiver uses the final layer topology key. Decryption complete. Since each hop passed the hard constraint check of the topology, the receiver can be certain that the payment fully followed the specific path planned by the sender, thus triggering the settlement logic.

[0033] This invention is based on a key derivation mechanism using a linear topological hash chain: Key Derivation Design 1-1: Linear Hash Chain Construction. The sender, based on the node sequence of the preset payment path, uses a one-way hash function to linearly couple the path global identifier (Path ID), node identity identifier (Node ID), and node sequence number (Pos) to generate a set of strongly ordered forwarding control keys. .

[0034] Key Derivation Design 1-2: Topology Attribute Binding. Unlike traditional tree-structured key spaces, the subkeys derived in this scheme are deeply bound to the "absolute position" of the node in the network topology. If a node is not a member of the preset path, or does not receive data packets in the preset order, its locally generated temporary key will not be able to match the encryption layer in the data packet.

[0035] Path-bound self-routing packet format design: Packet format design 1-1: Introducing the Topology Anchor (TA). This field consists of the forwarding control key of the corresponding node. The anchor is encrypted and contains a topology index pointing to the next hop. Only nodes located on the correct path can successfully decrypt the anchor and obtain subsequent routing instructions.

[0036] Packet Format Design 1-2: Design the Path Context (PC) field. This field is used to explicitly encode the path identifier and hop count counter. Relay nodes can quickly retrieve the local topology, enabling "blind verification" of packet validity without parsing the packet payload.

[0037] Packet format design 1-3: Design the path control field (Control Payload, CP). This field only contains instructions related to the current path forwarding and does not contain the data to be sent, thereby achieving logical decoupling between the routing layer and the data layer.

[0038] Path hard constraint mechanism based on decryption alignment: Forwarding Constraint 1-1: Automatic blocking based on decryption failure. After receiving a data packet, the relay node attempts to decrypt the "path anchor" using a key generated from local topology parameters. If the decrypted plaintext does not conform to the preset protocol format, the packet is determined to have deviated from the path, and the node will discard such a data packet directly.

[0039] Forwarding Constraint 1-2: Stateless forwarding based on path topology. By comparing the hop count counter in the data packet with the code path identifier, a node can confirm the legitimacy of its forwarding behavior without maintaining any local path state. This "match-or-forward, mismatch-or-fail" mode eliminates the dependence on complex digital signatures and achieves extremely lightweight path control.

[0040] This invention proposes a path locking and self-routing forwarding control scheme suitable for payment channel networks. Its core innovation lies in combining a linear topology hash chain with a path hard constraint mechanism: on the one hand, it utilizes a linear hash derivation algorithm based on path sequences to achieve strong binding management of the topology location keys of relay nodes; on the other hand, it designs a novel self-routing data packet with topology anchors, enabling the forced execution of preset paths in multi-path concurrent scenarios and achieving stateless fast forwarding through blind decryption matching. The scope of this invention covers the proposed nested data packet format with topology anchors, the linear key derivation mechanism based on path identifiers and node sequences, and the self-routing forwarding control method based on topology alignment.

[0041] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0042] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A payment path hard-constraint forwarding method based on topology locking, characterized in that, Includes the following steps: The payment initiator generates a control key by linearly coupling the global identifier, node identity identifier, and node sequence number of the preset payment path using a hash function, based on the node sequence of the preset payment path. A self-routing data packet is constructed based on the control key, and the self-routing data packet includes a path topology anchor point, a path context field, and a path control field. The relay node performs blind decryption and topology verification on the self-routing data packets, and forwards them according to the preset path after passing the verification. The settlement logic is triggered after the recipient decrypts the data packet and confirms that the path is compliant.

2. The payment path hard constraint forwarding method based on topology locking according to claim 1, characterized in that, The formula for generating the control key is: in, It is a one-way hash function. The path root seed is randomly generated by the payment initiator. For global identification, For node sequence number, Used as a node identity identifier.

3. The payment path hard constraint forwarding method based on topology locking according to claim 1, characterized in that, The path topology anchor is encrypted with the control key of the corresponding node and contains topology index information pointing to the next node.

4. The payment path hard constraint forwarding method based on topology locking according to claim 1, characterized in that, The path context field is used to encode the path identifier and hop count counter.

5. The payment path hard constraint forwarding method based on topology locking according to claim 1, characterized in that, The path control field contains the current path forwarding instructions.

6. The payment path hard constraint forwarding method based on topology locking according to claim 1, characterized in that, The blind decryption and topology verification steps of the relay node are as follows: After receiving the data packet, the relay node calculates the control key using the locally stored global identifier, its own node identity identifier, and the current sequence number, and decrypts the topology anchor point. If the decrypted plaintext does not conform to the preset protocol format, the data packet is determined to have deviated from the preset path and is discarded directly.

7. The payment path hard constraint forwarding method based on topology locking according to claim 6, characterized in that, After successfully decrypting the topology anchor, the relay node compares the hop count counter in the data packet with the coded path identifier to confirm the legitimacy of its forwarding behavior. Then, it decrypts the current encryption layer and forwards the remaining data packets to the next node.

8. The payment path hard-constraint forwarding method based on topology locking according to claim 1, characterized in that, The recipient decrypts the data packet using the final control key and triggers the settlement logic after confirming that the payment follows the preset path.

Images