Multi-hop payment method and system with privacy protection and variable amount for resource scheduling of autonomous Internet of Things

Abstract

The invention relates to the field of Internet of Things security, block chains and privacy computing, and discloses a privacy protection and amount variable multi-hop payment method and system for autonomous Internet of Things resource scheduling. According to the method, network topology and weight are hidden through multi-party security calculation to select an optimal payment path; the sender generates a Pedersen commitment and a zero-knowledge proof to hide and verify the transaction amount; the relay node performs homomorphic updating on the channel balance commitment after verification and certification, and generates a blind signature bound with a channel state for confirmation; the receiver verifies all signatures and certificates and ensures the conservation of the total amount of funds in the multi-hop payment process through a balance consistency verification function; and finally, settlement or arbitration is completed by the on-chain smart contract. According to the invention, dual privacy protection of payment amount and path is realized, variable amount is supported, and the method is suitable for crowdsourcing logistics, resource transaction and other Internet of Things scenes.

Description

Technical Field

[0001] This invention relates to the fields of Internet of Things (IoT) security, blockchain technology, and privacy computing, and particularly to a privacy-preserving, variable-amount multi-hop payment method and system for autonomous IoT resource scheduling. This invention can be widely applied to scenarios such as crowdsourced logistics and delivery, decentralized computing resource trading, supply chain finance settlement, and smart city services. Background Technology

[0002] With the widespread deployment of Internet of Things (IoT) technology and the rapid rise of on-demand and sharing economy models, crowdsourced resource collaboration systems, represented by drone delivery, shared energy facilities, and mobile edge devices, are gradually becoming mainstream application forms. In such systems, senders, relays, and receivers typically need to engage in cross-node, multi-hop dynamic collaboration and payment settlement, involving high-frequency, low-volume, and real-time value transfer. However, existing payment systems still have significant shortcomings in terms of privacy protection, scalability, regulatory compatibility, and resource constraint adaptation, making it difficult to meet the actual needs of large-scale IoT environments.

[0003] Current payment privacy protection technologies can be broadly categorized into the following three types:

[0004] The first type is the centralized platform-led account system, which achieves basic privacy protection through platform encryption and access control. However, this model has the risk of a single point of failure. Once the platform is attacked or data is leaked, sensitive information such as users' transaction amounts, geographical locations, and routes will be completely exposed, posing an extremely high privacy risk.

[0005] The second type is on-chain anonymous payment mechanism based on blockchain. Although it can provide high credibility and immutability, the high frequency of micro-payments executed on the chain will lead to network congestion and high transaction fees, which cannot meet the needs of massive, high-concurrency, and low-value transactions in the Internet of Things scenario.

[0006] The third category is Payment Channel Network (PCN) technology, which achieves scaling through off-chain ledger updates. However, current privacy-enhanced PCN solutions still have inherent shortcomings in terms of amount flexibility, relay node anonymity, and global fund consistency verification. Especially in resource-constrained terminal device scenarios, their cryptographic overhead and computational complexity are difficult to meet practical deployment requirements.

[0007] Patent document CN202410261111.1 discloses a "payment privacy protection method, device, and payment supervision method, device". This method encrypts the transaction amount and details using a read-only key to generate ciphertext transaction data. Subsequently, a supervisory node verifies the ciphertext based on the corresponding key. After successful verification, the ciphertext transaction is recorded on the blockchain to form a traceable encrypted ledger. Finally, the auditability of the payment process is achieved by combining a public key system with the supervisory process. While this method can achieve a certain degree of transaction data concealment, its technical solution still has significant limitations: First, the method uses a static ciphertext structure, which does not support the dynamic variability of payment amounts and cannot adapt to the payment needs that are common in IoT applications, which vary in real time based on distance, duration, or service costs. Second, the solution does not conceal relay nodes in off-chain multi-hop paths, allowing relays to infer transaction size through channel state changes or ciphertext features, making it difficult to achieve path privacy and "relay-oblivious." Third, the solution only focuses on verifying the authenticity of the ciphertext of a single transaction and does not address the conservation of overall fund flows in multi-hop payments, making it difficult to prevent double-spending or hidden issuance risks caused by malicious tampering of off-chain states. Fourth, the solution relies on a large number of encryption / decryption and regulatory verification operations, making it unsuitable for deployment in IoT terminals with limited computing power, such as drones and sensors.

[0008] Patent document CN202111618947.5 discloses a "Regulatory Online Payment Privacy Protection Method, Apparatus, and Electronic Device". This method generates first and second ciphertexts for updating the account balances of the payer and payee, keeping the account balances encrypted throughout their lifecycle. Simultaneously, it utilizes non-interactive zero-knowledge proofs to verify the legality of transactions. Before the transaction is recorded on the blockchain, the regulator parses the ciphertexts to ensure payment compliance. Finally, the regulator decrypts and audits the ciphertexts using a key generated from the public keys of all parties. While this method can balance privacy protection and regulatory requirements, it still has several shortcomings: First, the scheme is mainly designed for on-chain transaction verification processes and is not designed for off-chain multi-hop payment structures, thus failing to support cross-node and cross-domain payment paths commonly found in IoT environments. Second, the scheme uses encrypted balances to express account status and does not utilize a commitment structure with homomorphic additivity, therefore it cannot achieve off-chain hop-by-hop balance updates, nor does it support flexible variability of amounts. Third, relay nodes are not hidden and can still infer transaction sizes through side channels such as encrypted format and state changes, making it difficult to achieve path-level privacy protection. Fourth, the scheme does not provide a mathematical verification mechanism for the conservation of funds in multi-hop paths, failing to prevent implicit fund shifts at the system level.

[0009] In summary, existing technologies have varying degrees of shortcomings in areas such as off-chain payment scalability, variable amount, relay node privacy protection, and global fund consistency verification, making it difficult to meet the practical application needs of IoT scenarios. Therefore, there is an urgent need for a multi-hop payment method that can support dynamic amount adjustment, completely hide relay and path information, possess off-chain global balance consistency verification capabilities, and operate efficiently on resource-constrained terminal devices. Summary of the Invention

[0010] The purpose of this invention is to overcome the shortcomings of existing IoT micro-payment technologies that are small, efficient, and privacy-preserving, and to propose a privacy-preserving, variable-amount multi-hop payment method and system for autonomous IoT resource scheduling.

[0011] To achieve the above objectives, the present invention provides the following technical solution:

[0012] 1. A privacy-preserving, variable-amount multi-hop payment method for autonomous IoT resource scheduling, comprising the following steps:

[0013] (1) Construct the topology of the payment channel network and perform privacy path selection: Calculate the optimal multi-hop path from the sender to the receiver without exposing the weights of each edge and the details of the network structure using multi-party secure computation (MPC); this process includes obfuscating the network topology, unifying the number of adjacent edges of each node to a predetermined maximum degree, and using secretly shared weights to perform a secure shortest path algorithm, outputting only the optimal path sequence and its cumulative weights.

[0014] (2) The sender generates a commitment and proof: The sender generates a corresponding Pedersen commitment and zero-knowledge proof based on the target transaction amount, hides the transaction amount in the commitment, and proves the validity of the commitment through the zero-knowledge proof without revealing the actual amount.

[0015] The specific method by which the sender generates the commitment is as follows: select the transaction amount. and random mask ,calculate And construct non-interactive zero-knowledge proofs (Using Bulletproofs scope proof), proof Within legal limits and with the sender's knowledge. and .

[0016] (3) Off-chain payment relay and blind signature confirmation: Off-chain payment relay is performed hop-by-hop according to the optimal path. After receiving the commitment and proof sent by the previous node, each relay node verifies the zero-knowledge proof; if the verification is successful, it updates the payment channel balance commitment value between itself and the previous node using the homomorphic property of the Pedersen commitment, and introduces a random factor for re-randomization; subsequently, the relay node generates a blind signature bound to the channel identifier for the updated channel state to confirm the channel update.

[0017] (4) Receiver verification and consistency check: The receiver verifies the blind signatures of all relay nodes on the path, as well as the sender's commitment and zero-knowledge proof. After confirming that the signatures and proofs are valid, a balance consistency check (VerifyCoins) is performed. This ensures the total balance is kept constant during multi-hop payments by calculating the product of the changes in the commitment values ​​of each channel on the path, and generates a receipt confirmation to complete the off-chain payment.

[0018] The specific method for balance consistency verification is as follows: The verification function checks whether the quotient of the product of the changes in the commitment values ​​of each channel belongs to the generator. Subgroups. If the product contains only The index part and no The factor determines whether no additional value was created or lost along the entire path.

[0019] (5) On-chain settlement and dispute resolution: The final result of off-chain payment is submitted to the blockchain for settlement. The smart contract on the blockchain calls the pre-defined verification function to verify the submitted channel update status. If the verification passes, the balance change is confirmed and recorded on the blockchain; if the verification fails, the on-chain dispute arbitration process is triggered. The smart contract decides whether to update or roll back the channel balance based on the verification result.

[0020] 2. This invention also provides a privacy-preserving, variable-amount multi-hop payment system for autonomous IoT resource scheduling, comprising:

[0021] (1) Path selection module: Executes privacy-preserving shortest path algorithm based on multi-party secure computation;

[0022] (2) Commitment generation module: used to generate Pedersen commitments and zero-knowledge proofs for hidden amounts;

[0023] (3) Channel update module: used for relay nodes to perform homomorphic commitment updates and rerandomization;

[0024] (4) Blind signature confirmation module: used to generate blind signatures for the binding channel status;

[0025] (5) Consistency verification module: used by the receiver and smart contract to perform global balance conservation verification;

[0026] (6) On-chain settlement module: used to handle final settlement and arbitration on the blockchain.

[0027] The beneficial effects of this invention are as follows:

[0028] Firstly, it combines monetary privacy with flexibility: it leverages the homomorphic properties of Pedersen commitments to support payments of any amount, breaking the limitation of fixed denominations, while also using zero-knowledge proofs to ensure that the amount is completely invisible to relay nodes and the outside world.

[0029] Secondly, Relay-Oblivious: By combining blind signature technology, relay nodes can verify and sign the status without knowing the transaction amount or the complete identities of upstream and downstream parties, thus achieving true dual privacy protection for both the path and the content.

[0030] Third, global fund security is verifiable: The innovative balance consistency verification function (VerifyCoins) ensures that the total amount of funds is mathematically rigorously proven in a fully encrypted state, effectively preventing double-spending or malicious issuance.

[0031] Fourth, lightweight adaptation to the Internet of Things: The optimized combination of cryptographic primitives enables the solution to run efficiently on resource-constrained devices such as Raspberry Pi, and has good engineering practicality. Attached Figure Description

[0032] Figure 1 This is a flowchart illustrating the overall process of an embodiment of the present invention.

[0033] Figure 2 This is a logical schematic diagram of privacy path selection in an embodiment of the present invention.

[0034] Figure 3 This is an interaction timing diagram of a three-party transaction (sender-relay-receiver) in an embodiment of the present invention.

[0035] Figure 4 This is a system module structure block diagram of an embodiment of the present invention. Detailed Implementation

[0036] The embodiments of the present invention will be further described in detail below with reference to the accompanying drawings:

[0037] Example 1: A privacy-preserving multi-hop payment method based on blockchain (core process)

[0038] This embodiment uses drone crowdsourcing delivery as a scenario to describe the complete process of the sender (user A) paying the recipient (user C) through a relay node (drone B).

[0039] Step 1: System initialization and channel establishment.

[0040] (1) The system is set to the order of large prime numbers. Cyclic group and generator , ,in unknown.

[0041] (2) Network nodes establish payment channels with each other, deposit initial deposits, and calculate the initial balance using Pedersen commitments (e.g., ...). , These initial commitments are registered in blockchain smart contracts to form an off-chain ledger.

[0042] Step 2: Choosing the shortest path for privacy protection.

[0043] To find the optimal path without revealing the network topology and node quotations, the system executes a weighted shortest path algorithm based on MPC:

[0044] (1) Secret sharing: Each node shares its own routing weight (such as delivery fee). To conduct secret sharing, that is No single node can know the complete weight.

[0045] (2) Topology obfuscation: The network graph is preprocessed by filling the degree of all nodes to a uniform maximum degree by adding dummy edges. Virtual edges are assigned extremely high random weights to ensure they are not selected in the shortest path, thus hiding the true connection relationships between nodes.

[0046] (3) Secure computation (Dijkstra's algorithm): Using an Oblivious PriorityQueue (OPQ) to perform the SecureExtractMin operation, the node with the smallest current distance is selected in the encrypted state. To avoid revealing access patterns. For nodes. Neighbors Relaxation operations are performed using safe addition and safe comparison protocols: .like Then the distance is updated, and the specific value is not revealed during the entire comparison process.

[0047] (4) Output of results: The MPC protocol ultimately outputs the optimal path sequence only to the sender and receiver. The total cost and intermediate calculation status are kept confidential from all participants.

[0048] Step 3: Payment preparation and commitment generation.

[0049] Sender A determines the transaction amount Perform the following operations:

[0050] (1) Select a random mask Calculate the amount commitment .

[0051] (2) Generate non-interactive zero-knowledge proofs (Including range proof), proof The value is greater than 0 and does not exceed the channel balance, while also proving that the sender was aware of this. and .

[0052] (3) Send it to the next-hop relay node B.

[0053] Step 4: Update channel by channel and confirm blind signature.

[0054] (1) Verification: Verification The validity of the commitment legitimate.

[0055] (2) Update: Update the channel balance using commitment homomorphism.

[0056] Sender-side balance update: (Deduction).

[0057] Relay-side balance update: (Payment received).

[0058] A new random factor is introduced here. Perform rerandomization to prevent the commitment value from being tracked.

[0059] (3) Blind signature: Relay node B calculates the message digest of the updated state. And generate a signature using the RSA blind signature algorithm. Blind signatures ensure that B confirms the state update, but cannot deduce the specific amount. .

[0060] Step 5: Receiver verification and consistency check (VerifyCoins).

[0061] (1) Verify the original commitment and proof .

[0062] (2) Verify the validity of the blind signatures of all relay nodes.

[0063] (3) Balance conservation verification: Call the VerifyCons function. Calculate the product of the changes in the balance commitments of all channels along the path. If the system does not maliciously increase the number of tokens, then The total change should be 0 (one decrease and one increase), therefore It should contain only random factors The index, that is If the verification passes, it indicates that the flow of funds is conserved, and C generates a receipt confirmation.

[0064] Step Six: On-chain Settlement.

[0065] If a dispute arises or the channel needs to be closed, the final state is submitted to the blockchain. The smart contract executes the same logic as in step five. If verification passes, the on-chain state is updated; if a balance discrepancy or invalid signature is found, arbitration is triggered to punish the malicious party.

[0066] Example 2: Internet of Things Device Computing Resource Trading System

[0067] This embodiment demonstrates the application of the present invention in a micro-payment scenario, corresponding to the appendix to the specification. Figure 4 The system architecture.

[0068] Scenario Description: In edge computing scenarios, cloud service providers (senders) need to call upon a large number of distributed IoT devices (such as sensors and cameras) for data processing and need to pay a small fee to these devices.

[0069] System operation process:

[0070] (1) Resource matching and path planning: Cloud service providers use the path selection module to plan the data backhaul and fund payment path while protecting the location privacy of each edge device.

[0071] (2) Batch micro-payment commitment: The cloud service provider generates a total amount commitment. (For example, 10 yuan) is used to pay all devices involved in the calculation and transmission along the payment path. Thanks to the use of Pedersen commitments, the specific amount of a single micropayment (such as 0.01 yuan) is hidden, preventing business competitors from estimating the size of their business.

[0072] (3) Relay device processing: When data is transmitted in multiple hops between devices, each intermediate device acts as a relay node. They verify the payment commitment of the preceding node through the channel update module, update the local balance, and sign the update through the blind signature confirmation module. The device only confirms "I have received a valid payment" without knowing the total budget of the cloud service provider or the specific revenue of other devices.

[0073] (4) Final settlement: The cloud service provider periodically submits the accumulated blind signatures and commitments to the on-chain settlement module. The blockchain smart contract verifies the balance conservation of hundreds or thousands of micro-transactions at once, which greatly reduces gas fees and makes IoT micro-payments economically feasible.

[0074] Example 3: Privacy-preserving supply chain finance clearing.

[0075] This embodiment demonstrates the application of the present invention in multi-level supply chain fund transfers.

[0076] Scenario Description: The core enterprise (sender) needs to pay multiple levels of suppliers. In the traditional model, the markups or profit sharing at each level of suppliers are easily exposed, leading to business competition.

[0077] System operation process:

[0078] (1) Construction of multi-level payment links: The core enterprise and first-level, second-level and third-level suppliers constitute a payment network. The payment path is constructed using the method of this invention.

[0079] (2) Hidden fund flows:

[0080] 1) The core enterprise generates a payment commitment and initiates payment to the Tier 1 supplier.

[0081] 2) After deducting its own profit (service fee), the Tier 1 supplier forwards the commitment of the remaining amount to the Tier 2 supplier.

[0082] 3) In this process, homomorphic addition and subtraction of commitments are utilized. Calculate the remaining amount, but all amounts are in encrypted form.

[0083] (3) Privacy protection: Tier 2 suppliers can only verify that the received commitments are valid, but they cannot know the total payment amount of the core enterprise, nor can they know how much profit the Tier 1 supplier has withheld. This effectively protects the trade secrets of suppliers at all levels.

[0084] (4) Trustworthy audit: Although the amount is not visible, the recipient (end supplier) and the auditing agency can verify through the VerifyCoins function that the funds in the entire chain have not disappeared or increased out of thin air, ensuring the authenticity and trustworthiness of the supply chain finance accounts.

Claims

1. A privacy-preserving, variable-amount multi-hop payment method for autonomous IoT resource scheduling, characterized in that, include: (1) Construct the topology of the payment channel network and perform privacy path selection. Utilize multi-party secure computation to calculate the optimal multi-hop path from the sender to the receiver without exposing the weights of each side and the details of the network structure. (2) The sender generates a corresponding Pedersen commitment and zero-knowledge proof based on the target transaction amount, hides the transaction amount in the commitment, and proves the validity of the commitment through the zero-knowledge proof without revealing the actual amount; (3) Perform off-chain payment relay hop by hop according to the optimal path. After receiving the commitment and proof sent by the previous node, each relay node verifies the zero-knowledge proof. If the verification is successful, it updates the payment channel balance commitment value between itself and the previous node, and generates a blind signature bound to the channel identifier for the updated channel status to confirm the channel update. (4) The receiver verifies the blind signatures of all relay nodes on the path and the commitments and zero-knowledge proofs of the sender. After confirming that the signatures and proofs are valid, the receiver performs a balance consistency check to ensure that the total balance is conserved during the multi-hop payment process and generates a receipt confirmation to complete the off-chain payment. (5) Submit the final result of the off-chain payment to the blockchain for settlement. The smart contract on the blockchain calls the pre-defined verification function to verify the submitted channel update status. If the verification is successful, the channel balance change corresponding to the payment is confirmed and recorded on the blockchain. If the verification fails, the on-chain dispute arbitration process is triggered.

2. The method according to claim 1, characterized in that: Before step (1), there is also a channel initialization step, in which each node participating in the payment channel network establishes a bilateral payment channel in advance and deposits an initial deposit. Each node calculates the Pedersen commitment of the initial balance and registers the initial commitment to the blockchain, thereby forming a channel ledger that can be used for off-chain payments.

3. The method according to claim 1, characterized in that: Step (1) involves selecting the privacy path through a weighted shortest path algorithm calculated by multiple parties, including the following: 1a) Each participating node will secretly share the routing cost associated with itself, and the routing cost will remain encrypted during the calculation process; 1b) Obfuscate the topology information of the payment channel network, unify the number of adjacent edges of each node to a predetermined maximum degree, add virtual edges to nodes with insufficient degree and assign them high random weights to hide the real topology. 1c) Using secretly shared weights and obfuscated topology, all participating nodes jointly execute the Dijkstra shortest path algorithm, during which hidden node selection and distance updates are achieved through a security protocol; 1d) Output the path sequence of the shortest path and its cumulative weight. Information about the intermediate calculation process, except for the final result, is not disclosed to any single node.

4. The method according to claim 1, characterized in that: In step (2), the sender generates the commitment and proof in the following manner: 2a) Select transaction amount and random mask Calculate Pedersen commitments The transaction amount Implicit in the promise middle; 2b) Based on the aforementioned commitment Constructing non-interactive zero-knowledge proofs This proves that the sender knew the stated and Make Established, and the stated It conforms to the pre-agreed value range.

5. The method according to claim 1, characterized in that: In step (3), the process of the relay node updating and confirming the channel status includes: 3a) Relay nodes verify the zero-knowledge proof. The validity of the commitment package generated by the sender is verified to confirm the compliance of the transaction amount. 3b) The relay node uses the homomorphic property of the Pedersen commitment to adjust the balance commitment value of the channel it is connected to, deducts the corresponding transaction amount from the commitment of the previous node and adds it to its own balance commitment, and introduces a new random factor to re-randomize the updated commitment. 3c) The relay node calculates the message digest and generates a blind signature for the updated channel state. It is confirmed that the blind signature binds the channel identifier and status update sequence number in the signature content to prove that the relay node has agreed to the channel balance change and to prevent the signature from being replayed.

6. The method according to claim 1, characterized in that: In step (4), the receiver performs the balance consistency verification, which includes: collecting the commitment values ​​of each channel on the optimal path before and after the update, calling the pre-deployed verification function to perform calculation and verification on the commitment values, and confirming that the total balance remains constant when it is determined that the amount deducted and increased by each channel is equal.

7. The method according to claim 1, characterized in that: In step (5), when the off-chain verification fails, the smart contract enters the arbitration process, receives the channel status evidence submitted by the relevant parties, and executes the verification function and digital signature verification to determine whether the off-chain payment process has been tampered with or fraudulent, and decides on the settlement update or rollback of the channel balance based on the verification result.

8. The method according to claim 7, characterized in that: The verification function VerifyCons checks whether the quotient of the products of the commitment values ​​of each relevant channel belongs to the generator. The consistency of the total balance is determined by the subgroups of the product; if the quotient of the product contains only... The index part and no Factors that determine whether no additional value has been created or lost will be considered.

9. The method according to claim 5, characterized in that: The blind signature is generated by combining the RSA blind signature algorithm with the blinding algorithm. The relay node signs the message digest containing the channel ID and update count without revealing the channel update details. The blind signature also satisfies the security against forgery, thereby ensuring that no unauthorized party can forge a valid signature or deny a signed channel update.

10. The method according to claim 4, characterized in that: The zero-knowledge proof uses range proof to prove that the transaction amount does not exceed a predetermined limit. The range proof is constructed based on the elliptic curve discrete logarithm problem and has a short proof length, thereby reducing computation and communication overhead and making it suitable for execution by IoT devices.

11. A privacy-preserving, variable-amount multi-hop payment system for autonomous IoT resource scheduling, characterized in that... include: The path selection module is used to obtain the payment channel network topology and perform privacy shortest path calculation to determine the optimal payment path between the sender and the receiver. The path selection module hides the weights of each edge and the relationships between nodes based on multi-party secure computation and only outputs the optimal path and its cost. The commitment generation module is used by the sender to generate a Pedersen commitment and a zero-knowledge proof corresponding to the transaction amount, hiding the transaction amount value and proving its validity. The channel update module is used to update the status of the off-chain payment channel sequentially according to the optimal path order. Based on the sender's commitment and zero-knowledge proof, each relay node verifies and deducts or increases its channel balance commitment value to obtain the updated new commitment. The blind signature confirmation module is used by the relay node to generate blind signature confirmation information for each channel status update. The blind signature is associated with the channel identifier and the status sequence number to prove that the channel update has been recognized by the relay node and to avoid replay. The consistency verification module is used by the recipient to verify the commitment changes and relay node signatures throughout the payment path, call the preset verification function to check the overall balance of the channel commitment, and generate a payment completion confirmation when the verification passes. The on-chain settlement module is used to submit the payment result to the blockchain smart contract for processing. The smart contract performs balance consistency verification and signature verification. If they pass, the on-chain channel status is updated. If they fail, a dispute arbitration process is triggered to protect the funds of both parties to the payment.

12. The system according to claim 11, characterized in that: The commitment generation module uses the Pedersen commitment scheme to encrypt the transaction amount. The Pedersen commitment selects an independent generator from a cyclic group of large prime numbers. and ,by The commitment value is generated in a formal manner; the blind signature confirmation module uses the RSA blind signature algorithm combined with a blind factor to sign the channel update, ensuring that the relay node cannot know the specific transaction amount corresponding to the signature.

Images