Method, apparatus, and non-transitory machine-readable storage medium for blockchain transactions

Abstract

The present disclosure relates to a method for secure blockchain transactions using a decentralized multi-hop proxy network (DMHPN). The method comprises obtaining an encrypted message containing original transaction information, which is routed through a plurality of proxy nodes. Each proxy node decrypts its respective segment using a unique Elliptic Curve Diffie-Hellman (ECDH) shared encryption key to determine the next hop. The final proxy node decrypts the complete transaction data and submits it to the blockchain. The encrypted message excludes identifiers of the transaction initiator and destination blockchain node, enhancing privacy. This method improves security and decentralization by making only the intended proxy node access its segment of the data, maintaining anonymity throughout the transaction while preventing unauthorized access and ensuring privacy in blockchain interactions.

Description

[0001] METHOD, APPARATUS, AND NON -TRAN SI TORY MACHINE-READABLE STORAGE MEDIUM FOR BLOCKCHAIN TRANSACTIONS

[0002] Field

[0003] The present disclosure relates to blockchain transactions.

[0004] Background

[0005] Blockchains like Ethereum are designed to distribute control across a decentralized network of participants while safeguarding user privacy. However, practical challenges, such as the substantial resource demands and technical complexities of running a full node, often drive users to depend on centralized service providers, including node operators and infrastructure platforms. As a result, centralization can emerge within blockchain systems that are inherently intended to function without centralized control.

[0006] Summary

[0007] In a first example, a method for making a blockchain transaction may comprise obtaining an encrypted message destined for a blockchain node along a route including a plurality of proxy nodes in a proxy network, wherein the message includes original transaction information; and sending the encrypted message to a starting proxy node of the route. The method may improve privacy and decentralization by routing encrypted blockchain transactions through a multi-hop proxy network.

[0008] In an implementation of the first example, the encrypted message may include a plurality of pieces of funding transaction information respectively associated with the plurality of proxy nodes, wherein each of the plurality of pieces of funding transaction information may be for reward verification, and wherein the reward verification may be on a qualification for applying for a reward for forwarding the encrypted message. It may improve secure and verifiable reward distribution with encrypted funding transaction information for each proxy node.

[0009] In an implementation of the first example, the encrypted message may include payout information indicating a plurality of reward values that the plurality of proxy nodes are qualified to apply for respectively. It may protect reward confidentiality by including encrypted payout information accessible only by the respective proxy nodes.In an implementation of the first example, the encrypted message may include a plurality of sequenced and respectively encrypted identifications of the plurality of proxy nodes. It may enhance route anonymity with sequenced and encrypted identifications for each proxy node in the network.

[0010] In an implementation of the first example, the encrypted message may be without information indicating the blockchain node as a destination of the message and / or information indicating an entity as an entity initializing the original transaction. It may increase transaction privacy by excluding origin and destination identifiers in the encrypted message.

[0011] In an implementation of the first example, the reward verification is based on a hash tree. It may enable scalable and efficient reward verification using cryptographic hash trees like Merkle trees.

[0012] In an implementation of the first example, the method may further comprise obtaining, based on a No-Explicit-Distribution communication mechanism with the plurality of proxy nodes, a plurality of encryption keys for obtaining the encrypted message. It may enhance security by generating ECDH encryption keys without explicit distribution over the network.

[0013] In a second example, a method for making a blockchain transaction implemented by a proxy node, may comprise receiving an encrypted message destined for a blockchain node along a route including a plurality of proxy nodes in a proxy network, wherein the message includes original transaction information. It may further comprise determining, based on decryption of the encrypted message, a next hop for the message; and forwarding the encrypted message to the next hop. The method may support secure message forwarding by allowing each proxy node to decrypt only its relevant data segment.

[0014] In an implementation of the second example, the encrypted message includes a plurality of pieces of funding transaction information respectively associated with the plurality of proxy nodes. The method may further include determining, based on decryption of the encrypted message, a piece of funding transaction information for the proxy node, and performing, based on the determined funding transaction information, reward verification for the proxy node. It may facilitate reward verification with decryption of funding transaction information specific to each proxy node.In an implementation of the second example, the encrypted message may include payout information indicating a plurality of reward values that the plurality of proxy nodes are qualified to apply for respectively. The method may further comprise determining, based on decryption of the encrypted message, a reward value for the proxy node. The reward verification may be performed based on the determined funding transaction information and the reward value. It may help ensure accurate reward validation by combining funding transaction information with payout details.

[0015] In an implementation of the second example, the encrypted message may include a plurality of sequenced and respectively encrypted identifications of the plurality of proxy nodes. Consequently, determining, based on decryption of the encrypted message, a next hop for the message may comprise decrypting, based on an encryption key of the proxy node, the plurality of respectively encrypted identifications of the plurality of proxy nodes, and determining, based on the decryption, the next hop, wherein the next hop is indicated by a successfully decrypted identification. It may maintain routing security by encrypting and decrypting nexthop details at each proxy node.

[0016] In an implementation of the second example, the method may further comprise reporting the determined reward value to a blockchain associated with the encrypted message as a successfully claimed value after the proxy nodes receives a notification indicating a successful claim from a payout system. It may track rewards transparently by reporting claims to the blockchain upon notification from a payout system.

[0017] In a third example, an apparatus may comprise a processor; and a memory storing computer-readable instructions, which perform, when implemented by the processor, operations of any one of the first example and all the implementations of the first example. It may improve privacy and decentralization by routing encrypted blockchain transactions through a multihop proxy network.

[0018] In a fourth example, a proxy node may comprise a processor; and a memory storing computer-readable instructions, which perform, when implemented by the processor, operations of any one of the second example and all the implementations of the second example. It may support secure message forwarding by allowing each proxy node to decrypt only its relevant data segment.

[0019] In a fifth example, a system may comprise an apparatus of the third example and a proxy node of the fourth example. It may improve privacy and decentralization by routing encryptedblockchain transactions through a multi-hop proxy network and support secure message forwarding by allowing each proxy node to decrypt only its relevant data segment.

[0020] Brief description of the Figures

[0021] Some examples of apparatuses and / or methods will be described in the following by way of example only, and with reference to the accompanying figures, in which

[0022] Fig.1 illustrates system 100 of an example of the application;

[0023] Fig. 2 illustrates process 200 for making a blockchain transaction of an example of the application;

[0024] Fig. 3 illustrates method 300 for making a blockchain transaction of an example of the application;

[0025] Fig. 4A illustrates method 400 for making a blockchain transaction of an example of the application;

[0026] Fig. 4B illustrates method 401 for making a blockchain transaction of an example of the application;

[0027] Fig. 5 illustrates user device 500 of an example of the application; and

[0028] Fig.6 illustrates proxy node 600 of an example of the application.

[0029] Detailed Description

[0030] Some examples are now described in more detail with reference to the enclosed figures. However, other possible examples are not limited to the features of these embodiments described in detail. Other examples may include modifications of the features as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe certain examples should not be restrictive of further possible examples.

[0031] Throughout the description of the figures identical or similar reference numerals refer to identical or similar elements and / or features, which may be identical or implemented in a modifiedform while providing the identical or a similar function. The thickness of lines, layers and / or areas in the figures may also be exaggerated for clarification.

[0032] When two elements A and B are combined using an “or”, this is to be understood as disclosing all possible combinations, i.e., only A, only B as well as A and B, unless expressly defined otherwise in the individual case. As an alternative wording for the identical combinations, "at least one of A and B" or "A and / or B" may be used. This applies equivalently to combinations of more than two elements.

[0033] If a singular form, such as “a”, “an” and “the” is used and the use of only a single element is not defined as mandatory either explicitly or implicitly, further examples may also use several elements to implement the identical function. If a function is described below as implemented using multiple elements, further examples may implement the identical function using a single element or a single processing entity. It is further understood that the terms "include", "including", "comprise" and / or "comprising", when used, describe the presence of the specified features, integers, steps, operations, processes, elements, components and / or a group thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and / or a group thereof.

[0034] In the following description, specific details are set forth, but examples of the technologies described herein may be practiced without these specific details. Well-known circuits, structures, and techniques have not been shown in detail to avoid obscuring an understanding of this description. “An example,” “various examples,” “some examples,” and the like may include features, structures, or characteristics, but not every example necessarily includes the particular features, structures, or characteristics.

[0035] Some examples may have some, all, or none of the features described for other examples. “First,” “second,” “third,” and the like describe a common element and indicate different instances of like elements being referred to. Such adjectives do not imply element item so described must be in a given sequence, either temporally or spatially, in ranking, or any other manner. “Connected” may indicate elements are in direct physical or electrical contact with each other and “coupled” may indicate elements co-operate or interact with each other, but they may or may not be in direct physical or electrical contact.

[0036] As used herein, the terms “operating”, “executing”, or “running” as they pertain to software or firmware in relation to a system, device, platform, or resource are used interchangeably and can refer to software or firmware stored in one or more computer-readable storage mediumaccessible by the system, device, platform, or resource, even though the instructions contained in the software or firmware are not actively being executed by the system, device, platform, or resource.

[0037] The description may use the phrases “in an example / example,” “in examples / examples,” “in some examples / examples,” and / or “in various examples / examples,” each of which may refer to one or more of the identical or different examples. Furthermore, the terms “comprising,” “including,” “having,” and the like, as used with respect to examples of the present disclosure, are synonymous.

[0038] In some examples associated with the application, some technologies like Elliptic Curve Diffie-Hellman Key Exchange (ECDH Key Exchange), Distributed Hash Table (DHT) and Blockchain Node Provider may be used in technical schemes based on blockchain.

[0039] ECDH Key Exchange may be an anonymous key agreement scheme that enables two parties, each possessing an elliptic-curve public-private key pair, to establish a shared secret over an insecure channel. This shared secret may then be used alongside a symmetric encryption algorithm, such as Advanced Encryption Standard (AES), to securely encrypt and decrypt messages. Some further information about ECDH Key Exchange is available at htps: / / crvDtobook.nakov.com / asvmmetric-kev-ciphers / ecdh-kev-exchanQe

[0040] DHT may be a decentralized system designed to provide a lookup service similar to a hash table. In a DHT, key-value pairs are stored, and any participating node can efficiently retrieve the value associated with a given key. One of the primary advantages of a DHT may be its ability to seamlessly accommodate changes in the network; nodes may be added or removed with minimal effort required to redistribute the keys. Each key serves as a unique identifier that maps to a specific value, which may represent various types of data, such as addresses, documents, or other arbitrary information. Some further information about DHT is available at https: / / en.wikipedia.org / wiki / Distributed hash table

[0041] Blockchain Node Provider may be a service that offers access to blockchain networks by running and maintaining blockchain nodes on behalf of developers and users. Infura, as a specific Blockchain Node Provider, may provide the infrastructure and tools for developers to connect their applications to blockchain networks like Ethereum and IPFS without the need to manage their own nodes. Some further information about Infura and / or Blockchain Node Provider is available at https: / / www.infura.io / faq / qeneralIn some examples associated with the application, the majority of Ethereum transactions are routed through centralized node providers like Infura. These centralized node providers may potentially capture transaction data and enrich it with correlated information about users. The enriched data may be sold to 3rd parties, thereby compromising user privacy and potentially de-anonymizing blockchain users. When the transaction data is combined with other information, such as IP addresses or transaction patterns, the identity of users might be detected. The privacy problem may extend beyond specific platforms or techniques, such as Ethereum and Infura, and affect a plurality of blockchain networks that heavily rely on centralized node providers. Although running a full Ethereum node might mitigate this privacy issue for the user, it is too resource intensive to be widely practical.

[0042] Fig.1 illustrates system 100 of an example of the application. As shown in Fig. 1, system 100 includes a user 120, a Decentralized Multi-Hop Proxy Network (DMHPN) 140 and a blockchain network 160, where the user 120 is coupled with the DMHPN 140 and the DMHPN 140 is coupled with the blockchain network 160. In some examples, the system 100 may comprise more users coupled with the DMHPN 140.

[0043] In some examples of the application, the DMHPN 140 may include a plurality of proxy nodes. As shown in Fig. 1, the DMHPN 140 at least includes proxy nodes 142, 144 and 146. The blockchain network 160 may include one or more blockchain nodes. As shown in Fig. 1, the blockchain network 160 at least includes the blockchain node 162. The blockchain network 160 may include other blockchain nodes. In some examples, the user 120 may refer to a user device used by a person. For example, it may be a personal computer (PC), a smart phone, a tablet, a laptop, or any other smart device. In some examples, a proxy node is an intermediary in the DMHPN that may facilitate secure, anonymous routing of blockchain transactions. Devices that may serve as the proxy nodes, such as nodes 142 to 146, may be networking devices, mobile devices, PCs and so on. In some examples, the proxy nodes may be community-hosted nodes that are hosted by volunteers or incentivized participants in the network, provided the nodes meet the requirements for connectivity, security, and processing capacity. In some examples, a blockchain node, such as node 162, may be a device or system participating in the blockchain network to process, validate, or store transactions and data. Devices that could serve as blockchain nodes may include dedicated servers, virtual private servers, edge computing devices, Internet of Things (loT) devices, personal smart devices, data centers and so on.

[0044] As shown in Fig. 1, user 120 is not directly connected to blockchain network 160, but is coupled with blockchain network 160 via DMHPN 140. The DMHPN 140 may be a peer-to-peernetwork based on the proxy nodes like nodes 142 to 146. Each of the proxy nodes may maintain multiple connections to a plurality of blockchain nodes like node 162. When user 120 initiates a message for a blockchain transaction, the message may be encrypted by the user 120 and then be sent through the multiple proxy nodes, such as nodes 142 to 146, in DMHPN 140. In some examples, each proxy node may determine the previous hop and the next hop of the message it receives and cannot determine the origin and / or destination of the message. The origin may be the device generating the message and the destination may be a blockchain node that is supposed to process the blockchain transaction. The final proxy node on the route of transmitting the message may submit the transaction to blockchain node selected by the final proxy node. The selection of the blockchain node may be implemented by the final proxy node randomly to avoid predictable patterns.

[0045] In some examples of the application, the submission of the transaction may include message decryption and transaction transmission. For example, the final proxy node may obtain the transaction information intended for the blockchain by decrypting the message received from the previous proxy node. Furthermore, the final proxy node may select a blockchain node based on a selection policy. The selection may include querying a decentralized mechanism like DHT to improve randomness and avoid predictable patterns. Moreover, the final proxy node may submit the transaction information to the selected blockchain node. The submission may be based on standard blockchain communication protocols, such as JavaScript Object Notation- Remote Procedure Call (JSON-RPC) for Ethereum.

[0046] Because the message for the blockchain transaction is sent to the blockchain network 160 via the DMHPN 140, which comprises a plurality of proxy nodes, this technical solution achieves a higher degree of decentralization compared to directly sending the message to the blockchain network 160. Consequently, it becomes more difficult to correlate users with transactions, thereby enhancing user privacy protection."

[0047] Fig. 2 illustrates process 200 for making a blockchain transaction of an example of the application.

[0048] At operation 201, a user, such as user 120 in Fig. 1, may generate a plurality of pieces of information for the blockchain transaction. The plurality of pieces of information may include a route, ECDH shared encryption keys, seeds, identifiers, encrypted data, a Merkle tree root, and Merkle proofs.

[0049] Detailed operations for generating the above information in some examples of the application are presented as follows. In some examples, the following generation is implemented by asoftware application, such as a wallet application, running on the user, where the user refers to a user device.

[0050] Generating Route

[0051] The user may select a sequence of proxy nodes in the Decentralized Multi-Hop Proxy Network (DMHPN). The sequenced proxy nodes, such as sequenced nodes 142 to 146, may present the route for communication between the user 120 and the blockchain node 162. The selection may be based on network metrics such as availability, latency, and trust level. The selected route may specify the order in which the proxy nodes will process and forward the encrypted message, ensuring anonymity.

[0052] Generating ECDH Shared Encryption Keys

[0053] Each proxy node in DMHPN 140 may have a public-private key pair based on the Elliptic Curve Diffie-Hellman (ECDH) protocol. User 120 may retrieve the public keys of all selected proxy nodes, such as nodes 142 to 146, from a network like DMHPN 140 or a distributed registry like DHT. User 120 may compute a shared encryption key with each proxy node using the node’s public key and the user’s private key. The private key may be a key of the application. The generated keys are unique to each user-proxy node pair and are for enabling secure, encrypted communication

[0054] Generating Seeds

[0055] In some examples, seeds are unique random values associated with each proxy node to help generate Merkle tree leaves and for reward verification. User 120 may generate a random seed for each proxy node in the route, such as nodes 142 to 146 in the route shown in Fig.

[0056] 1. In some examples, each generated seed is encrypted using the respective proxy node's ECDH shared key to improve confidentiality.

[0057] Generating Identifiers

[0058] In some examples, each identifier may uniquely represent a proxy node and may map the proxy node to a seed. An identifier of a proxy node may be the proxy node’s public key, a nonce, or another unique value agreed upon during the initial ECDH key exchange. The identifiers may also be encrypted using the respective ECDH shared keys.

[0059] Generating Encrypted Data

[0060] In some examples, user 120 may prepare and encrypt specific information intended for each proxy node in a multi-hop proxy network. The encrypted_data may be encrypted using the Elliptic Curve Diffie-Hellman (ECDH) shared encryption key unique to the user and therespective proxy node. This encryption help ensure that only the intended proxy node can decrypt and access its respective portion of the data.

[0061] In some examples, the encrypted data for intermediate proxy nodes may include next-hop details, seed and / or identifier. The next-hop details may refer to information about the next proxy node in the route to ensure proper message forwarding. Seed may refer to a unique random value generated for the proxy node, often used for reward verification and Merkle tree generation. The identifier may refer to a unique value, such as the proxy node’s public key or a nonce, mapping the proxy node to its assigned data or role in the transaction.

[0062] Generating Merkle Tree Root and Proofs

[0063] The generation of Merkle Tree root and proofs is for enabling a compact and verifiable structure for payout claims.

[0064] In some examples, user 120 may hash each proxy node’s seed and crypto address using a cryptographic hash function to create Merkle tree leaves. As a result, user 120 may generate a leaf for each proxy node. The crypto address may be a blockchain address where the proxy node can receive its payment or reward for participating in the transaction routing.

[0065] Based on the generated leaves, a Merkle Tree root may be further generated. Each leaf in the Merkle tree corresponds to a hashed value, e.g., H(seed||crypto_address). These leaves represent the unique entries associated with each proxy node. Neighboring leaves are paired and hashed together to form the next level of the tree. An example for two leaves L1 and L2 may be: H(L1, L2)=H(hash of L1 +hash of L2). If there is an odd number of leaves, the last leaf is usually duplicated to create a pair. The process of pairing and hashing continues iteratively until only one hash remains, where the only one hash is the generated Merkle root. The Merkle root is a single hash that represents all the leaves, which are data entries, in the tree. It may allow efficient verification without storing or processing all the underlying data. In some examples, user 120 may generate Merkle proofs for proxy nodes, such as nodes 142, 144 and 146, on the selected route respectively. A Merkle proof may be generated by traversing the Merkle tree and collecting the sibling hashes along the path from a specific leaf, such as a leaf corresponding to node 142, 144 or 146, to the root. A proof for a proxy node may allow a verifier to reconstruct the Merkle root from the leaf corresponding to the proxy node, which may be referred to as the leaf for the proxy node, and the proof.

[0066] In order to generate a proof for a proxy node, the user may determine the proxy node and then move up the tree, from the leaf for determined proxy node, level by level. At each level, the sibling hash, which is the hash of the leaf or intermediate node paired with the current node, is recorded. The user may continue collecting sibling hashed until reaching the Merkleroot. The collection of sibling hashes along this path constitutes the Merkle proof for the determined proxy node.

[0067] At operation 202, the user may send the Merkle root to a verifier. The verifier may be a smart contract in some examples. In some examples, the verifier, such as the smart contract, may be a piece of software code deployed and executed on a blockchain network. More specifically, the verifier may be deployed on a blockchain node. In some examples, it is a decentralized program that resides in the blockchain’s infrastructure and operates autonomously based on pre-defined rules.

[0068] At operation 203, the user may prepare a data set including a plurality of entries, where each entry corresponds to an exclusive proxy node. In some examples, each entry may include encrypted_data, leaf_position_in_MerkleTree, Merkle Proof for its corresponding proxy node.

[0069] At operation 204, the user may prepare transaction information, which may also be called information associated with transaction. The transaction information may include at least one piece of the original transaction information, funding transaction information or payout information. For example, it may include any one or two pieces of information, or all three pieces of transaction information.

[0070] At operation 205, the user may encrypt the transaction information using an ECDH shared encryption key of the last-hop proxy node. As presented above, each selected proxy node corresponds to an ECDH shared encryption key. The transaction information is to be sent to the blockchain network like network 160 by the last hop proxy node like node 146. Therefore, the transaction information needs to be obtained by the last-hop proxy node. The encryption using the ECDH shared encryption key of the last-hop proxy node may enable the last-hop proxy node to obtain the transaction information by decryption.

[0071] At operation 206, the message is sent from the user to proxy node 1 , which may be proxy node 142 in Fig. 1. The message includes information 1 for proxy node 1, information 2 for proxy node 2 and information 3 for proxy node 3, where information is encrypted using an ECDH shared encryption key of proxy node 1, information 2 is encrypted using an ECDH shared encryption key of proxy node 2, and information 3 is encrypted using an ECDH shared encryption key of proxy node 3. Proxy node 1 may obtain information 1 by decryption. Because proxy node 1 did not participate in the generation of the encryption keys for proxy nodes 2 and 3, it cannot obtain information 2 and information 3 respectively encrypted using two other different keys. In some examples, information 1 may include the identifier of theuser, the next-hop proxy node of proxy node 1 , which is proxy node 2. Proxy node 1 cannot obtain the transaction information and cannot obtain the next hop, such as proxy node 3, after the next-hop proxy node, such as proxy node 2.

[0072] At operation 207, the message is sent from proxy node 1 to proxy node 2 based on the nexthop proxy node, such as proxy node 2, of proxy node 1. Proxy node 2 may obtain information 2 by decryption, where information 2 may include the next hop, such as proxy node 3, of proxy node 2, which is proxy node 3. In some examples, information 2 does not include an identifier of the user and does not include an identifier of a blockchain node to protect privacy or security.

[0073] At operation 208, the message is sent from proxy node 2 to proxy node 3 based on the nexthop proxy node, such as proxy node 3, of proxy node 2.

[0074] At operation 209, proxy node 3 may obtain information 3 by decryption, where information 3 may include the transaction information.

[0075] At operation 210, proxy node 3 may send the original transaction information included in the transaction information to a blockchain node.

[0076] Proxy node 3 cannot obtain an identifier of a blockchain node serving as a next hop of the message. Instead, proxy node 3 may select a blockchain node as an entity receiving the original transaction information based on its own policy. For example, proxy node 3 may randomly select a blockchain node, such as node 162, and send the original transaction information to the selected node.

[0077] At operation 211, proxy node 3 may send the funding transaction information included in the transaction information to the verifier, such as the smart contract. In some examples, proxy node 3 may establish a connection with the verifier before or after the funding transaction information is obtained by proxy node 3. Based on the connection between the proxy node 3 and the verifier, the funding transaction information may be sent to the verifier.

[0078] At operation 212, proxy node 3 may send the payout information included in the transaction information to a blockchain node. In some examples, the blockchain node receiving the payout information may be the same to the blockchain node receiving the original transaction information. In some other examples, the blockchain node receiving the payout information may be different from the blockchain node receiving the original transaction information. Proxy node 3 may select the blockchain node receiving the payout information based on apolicy of proxy node 3. For example, proxy node 3 may randomly select a blockchain node to receive the payout information.

[0079] At operation 213, each proxy node on the route, such as proxy node 1, proxy node 2 or proxy node 3, may obtain information associated with reward based on the payout information stored in the blockchain node.

[0080] In some examples, some or all of the information associated with reward may be obtained by decryption of the encrypted information obtained from the payout information stored in the blockchain node.

[0081] After the payout information is sent by proxy node 3 to the blockchain node, each proxy node may retrieve the payout information, which includes a plurality of pieces of encrypted information respectively corresponding to a plurality of proxy nodes. For example, the payout information may include 3 pieces of encrypted information respectively corresponding to proxy node 1, proxy node 2 and proxy node 3. Because each piece of encrypted information is encrypted using a key corresponding to a proxy node, one proxy node can only decrypt the piece of information corresponding to it.

[0082] In some examples, the information associated with reward of a proxy node may include crypto address, seed, Merkle proof and leaf position in the Merkle Tree.

[0083] At operation 214, each proxy node may send its information associated with reward to the verifier, such as the smart contract.

[0084] At operation 215, the verifier may make payments for each proxy based on the information associated with reward of each proxy. For example, the verifier may verify proxy node 1 based on the information associated with reward of proxy node 1 , which may include a crypto address of proxy node 1, a seed of proxy node 1, a Merkle proof of proxy nodel and a leaf position in the Merkle Tree of proxy node 1. If the verification on proxy node 1 succeeds, the verifier makes a payment to proxy node 1; if the verification on proxy node fails, the verifier does not make a payment to proxy node 1.

[0085] At operation 216, proxy node 3 may receive a transaction result of the transaction requested by the user and encrypted the transaction result using ECDH encryption key 3, which is a key of proxy node 3, and obtained based on the communication between the user and proxy node3. In some examples, the transaction result may include confirmation information indicating that the original transaction has been successfully executed.

[0086] At operation 217, proxy node 3 may send the encrypted result to proxy node 2. Although proxy node 3 does not the user, it knows that the message for the transaction is from proxy node 2. Therefore, proxy node 3 may send the transaction result to proxy node 2.

[0087] At operation 218, proxy node 2 may send the encrypted result to proxy node 1. Proxy node 2 did not participate in the substantial generation of the ECDH encryption key 3, therefore proxy node 2 cannot decrypt the encrypted result, which improves the security of the transaction. Furthermore, although proxy node 2 does not know the user, it knows that the message for the transaction is from proxy node 1.

[0088] At operation 219, proxy node 1 may send the encrypted result to the user. Similar to proxy node 2, proxy node 1 cannot decrypt the encrypted result too. With respect to the forwarding of the encrypted result, proxy node 1 knows that the message for transaction is from the user. Therefore, it may send the encrypted result to the user.

[0089] At operation 220, the user may obtain the transaction result based on decryption of the encrypted result using a corresponding key.

[0090] Operations of Setup

[0091] In some examples, setup to proxy nodes may be implemented. The setup may include setting up a Decentralized Multi-Hop Proxy Network and / or a Distributed Hash Table (DHT). The DHT may serve as a decentralized storage system in which each proxy node maintains an entry that contains its relevant information. DHT may be stored across the proxy nodes in the decentralized network, with each node holding a small, dynamically assigned portion of the overall data. Each proxy node may have an entry of DHT containing at least one of a public key for Elliptic Curve Diffie-Hellman (ECDH), a crypto address for reward payouts, current node status or performance metrics. The current node status may be an online / offline state. The performance metrics may include at least one of throughput, success rate, latency or uptime, where throughout may refer to a number of transactions or data packets the node can process per second, success rate may refer to a percentage of successfully processed or forwarded transactions relative to the total transactions attempted, latency may refer to average time it takes for a transaction or request to travel through the node, and uptime may refer to a percentage of time the node has been active and available for use in the network.Operations of Initial Process of Application

[0092] In some examples, the software application, such as a wallet application, running on the user may include some or all the following initial operations:

[0093] The application may select a route through proxy modes. In particular, the application queries the Distributed Hash Table (DHT) to retrieve information about available proxy nodes. Based on the retrieved information about available proxy nodes, such as the status and performance metrics, the application may select a sequence of proxy nodes to form a route. For example, the route may be proxy node 1 — > proxy node 2 — > proxy node 3, or proxy node 142 —> proxy node 144 —> proxy node 146.

[0094] The application may use ECDH to create a plurality of shared encryption keys for the plurality of selected proxy nodes. For example, the application may create shared encryption key 1 for proxy node 1 or proxy node 142, shared encryption key 2 for proxy node 2 or proxy node 144, and shared encryption key 3 for proxy node 3 or proxy node 146.

[0095] The application may prepare at least one of original transaction information, funding transaction information, and payout information. The original transaction information may describe the blockchain transaction the application wants to make, such as transferring cryptocurrency. The funding transaction information provides funds to the smart contract, while the payout information helps ensure proxy nodes have the data needed to claim those funds. The information needed for the funding transaction may include the amount of cryptocurrency being transferred to the smart contract and the Merkle root of the payout information structure for verification during claims. The payout information may include the encrypted payout details, Merkle proofs, and leaf positions for all proxy nodes to the blockchain.

[0096] The structure of an entry for a proxy node on the route may be presented as: (encrypted_data, leaf_position_in_MerkleTree, Merkle Proof). The application may encrypt all the entries of all selected proxy nodes using the shared ECDH encryption key of the last proxy node on the route. Because of the encryption, the encrypted entries can only be decrypted by the last proxy node.

[0097] Operations of Payout Mechanism

[0098] The application may generate a unique random seed and a corresponding unique identifier, such as a public key or a nonce established during the initial ECDH key exchange, for each proxy node. For every proxy node, the application may encrypt the concatenation of the seedand the identifier (seed || identifier) using the respective ECDH shared key, resulting in an encrypted data payload. Additionally, the application may compute a cryptographic hash, H(seed || proxy_node_crypto_address), for each proxy node and may organize these hashes as the leaves of a Merkle tree. A Merkle proof may then be generated for each proxy node, and the Merkle root of the tree may be included in the funding transaction information submitted to the smart contract, ensuring verifiability and integrity of the proxy node data.

[0099] Operations of Smart Contract

[0100] The smart contract may include a mapping that associates each Merkle root with its corresponding total funding amount, ensuring that the total funds allocated for each set of proxy nodes are tracked. Additionally, it may maintain a secondary mapping that links proxy crypto addresses to their claimed amounts, preventing double claims and ensuring accurate fund distribution. The contract may implement functions to support key operations: a funding function to allow users to deposit funds and associate them with a specific Merkle root, a claiming function to enable proxy nodes to withdraw their allocated amounts by providing a valid Merkle proof, and a withdrawal function to allow funders to retrieve unused funds after all claims have been settled or the funding period has ended. These operations collectively improve secure and transparent management of funds within the smart contract.

[0101] Operations of Transaction Flow

[0102] The transaction flow may involve a series of operations designed to ensure secure and verifiable execution of payments to proxy nodes. The last proxy node may execute the original transaction initiated by the user. Upon completing this, it may submit a funding transaction to the smart contract, associating the Merkle root and total funding amount. Additionally, the last proxy node may submit a payout transaction to the blockchain, containing a decrypted structure that becomes publicly available. This structure may include entries for all proxy nodes involved in the transaction.

[0103] Any proxy node may then access the structure from the blockchain to identify its corresponding entry. Since the entries are anonymous, a proxy node may decrypt each encrypted_data in the structure using the shared key established with the user via ECDH during the initial setup. Decryption may succeed only for the entry containing the correct identifier, enabling the proxy node to recognize its own data. After identifying its entry, the proxy node may retrieve its information, which may include the encrypted_data, the leaf_position_in_Merkle-Tree, and the Merkle proof. The proxy node may use the Merkle proof and the leaf positionto submit a claim to the smart contract and may retrieve its allocated payment. This process may ensure privacy for proxy nodes, while maintaining transparency and integrity in the distribution of funds.

[0104] Operations of Payout Claim Process

[0105] The payout claim process involves a series of operations to ensure secure and verifiable payment distribution to proxy nodes. Each proxy node may decrypt its encrypted_data using the shared key established with the user during the initial setup. To claim a payout, a proxy node may submit a claim including the following data to the smart contract: its crypto address, the decrypted seed, the Merkle proof, and the leaf position in the Merkle Tree.

[0106] Operations of Verification by Smart Contract

[0107] Upon receiving the claim, the smart contract may verify its validity through a multi-step process. It may reconstruct the Merkle Tree leaf by hashing the submitted decrypted seed and the proxy node's crypto address using the formula H(submitted_decrypted_seed || proxy_node_crypto_address). The contract then may validate the submitted Merkle proof against the stored Merkle root to ensure the claim's authenticity. If the proof is valid, the smart contract may release the corresponding payment to the proxy node and may mark the payment as claimed to prevent double claims. This process ensures that payouts are securely distributed while maintaining verifiability and accountability through cryptographic proof.

[0108] Operations of Delayed Activations

[0109] The delayed activation process introduces a time lock mechanism in the smart contract to prevent premature claims by proxy nodes. The smart contract may include a time lock that becomes active when the transaction containing the encrypted payout information is mined on the blockchain. Proxy nodes may only be allowed to submit claims after the time lock has expired, ensuring that all transactions in the process are completed before claims can begin. Based on the above mechanism, the user's identity may remain concealed throughout the payout process, as the delayed activation prevents any immediate association with their transactions. Each proxy node may only claim its own payment, as the claim process requires decryption of individual entries and submission of a valid Merkle proof. Furthermore, payments may not be claimed until all proxy nodes have had time to complete their required transactions and the payout structure is fully published. Moreover, the smart contract may verify claims using the submitted Merkle proof and reconstructed data without requiringknowledge of the full routing path or any additional identifying information. This process balances security, privacy, and transparency while ensuring proper sequencing of claims.

[0110] In some examples, Operations of Setup, Initial Process of Application, Payout Mechanism, Smart Contract, Transaction Flow, Payout Claim Process, Verification by Smart Contract and Delayed Activations may be some portions or some supplementary information of examples according to each figure of this application.

[0111] Fig. 3 illustrates method 300 for making a blockchain transaction of an example of the application.

[0112] In some examples, method 300 may present a method for conducting a blockchain transaction that ensures privacy, security, and efficient communication by leveraging a decentralized multi-hop proxy network (DMHPN). Method 300 may include operations 320 and 340. Operation 320 may include obtaining an encrypted message destined for a blockchain node along a route including a plurality of proxy nodes in a proxy network, wherein the message includes original transaction information. Operation 340 may include sending the encrypted message to a starting proxy node of the route.

[0113] In some examples, a user application, such as a wallet application running on a user device, may obtain an encrypted message by preparing it with the original transaction information. The user application may be called a user, such as user 120 in Fig. 1 in some examples. The route may include a sequence of proxy nodes, such as proxy nodes 142, 144 and 146 in Fig.

[0114] 1, selected based on network metrics like latency, availability, and trustworthiness. Each proxy node in the route may be assigned a unique ECDH shared encryption key, ensuring secure communication.

[0115] The encrypted message may include details of the original transaction, such as a cryptocurrency transfer, and is designed to traverse the network securely. The user application may send this message to the starting proxy node, such as proxy node 1 in Fig 1 and / or Fig. 2. Each proxy node may decrypt its respective segment and forward the message to the next hop until it reaches the blockchain node.

[0116] In some examples, the encrypted message includes a plurality of pieces of funding transaction information respectively associated with the plurality of proxy nodes, wherein each of the plurality of pieces of funding transaction information is for reward verification, and wherein thereward verification is on a qualification for applying for a reward for forwarding the encrypted message.

[0117] In some examples, the encrypted message may include funding transaction information associated with each proxy node, allowing each node to verify its eligibility for rewards. The funding transaction information may comprise data encrypted using the ECDH shared encryption key of each respective proxy node. By decrypting this data, a proxy node may determine its role and qualification for rewards.

[0118] In some examples, reward verification may rely on a mechanism such as a Merkle tree, where each proxy node's seed and crypto address are hashed to create leaves. This compact cryptographic structure may enable efficient and tamper-proof verification. Other hash trees may also be used for the verification as alternative techniques in some other examples.

[0119] In some examples, the encrypted message may include payout information indicating a plurality of reward values that the plurality of proxy nodes are qualified to apply for respectively. As presented, the encrypted message may include payout information in some examples. The payout information may indicate the reward values allocated to each proxy node. This information may be encrypted using the ECDH shared key of the respective proxy node to improve confidentiality. Proxy nodes may retrieve this data after the payout information transaction is published on the blockchain. By decrypting their respective portions, proxy nodes may learn their specific reward amounts and the data required to claim these rewards.

[0120] In some examples, the encrypted message may include a plurality of sequenced and respectively encrypted identifications of the plurality of proxy nodes.

[0121] To preserve anonymity and achieve accurate routing, the encrypted message may include a sequence of encrypted proxy node identifications. Each identification may represent a proxy node and may be encrypted using its ECDH shared key. As the message travels through the route, each proxy node may decrypt its respective segment to identify itself and determine the next hop. This mechanism may prevent unauthorized nodes from accessing routing information beyond their scope.

[0122] In some examples, the encrypted message is without information indicating the blockchain node as a destination of the message and / or information indicating an entity as an entity initializing the original transaction. In such a situation, the message omits explicit details about the blockchain node destination and the entity initiating the transaction. This omissionmay enhance privacy by concealing the user’s identity and the final recipient of the transaction. Instead, the last proxy node may select a blockchain node randomly or based on its own policy to send the original transaction. This design may ensure that no single proxy node has complete knowledge of the transaction’s origin and destination. In some examples, one of the destination and the source is omitted and the other is not omitted.

[0123] In some examples, the reward verification is based on a hash tree. For example, the hash tree may be a Merkle tree, a cryptographic structure that may enable compact and efficient validation of claims. Each proxy node may contribute a hashed leaf, representing its seed and crypto address. The leaves may be combined to generate a hash tree root, such as a Merkle root, which may be stored in a funding transaction submitted to verifier, such as a smart contract. During claim submission, each proxy node may present its leaf, seed, and Merkle proof. The verifier, such as the smart contract, may reconstruct the Merkle tree and may verify the proof against the stored Merkle root to ensure the claim’s validity

[0124] In some examples, method 300 may further comprise obtaining, based on a No-Explicit-Dis-tribution communication mechanism with the plurality of proxy nodes, a plurality of encryption keys for obtaining the encrypted message. The user application in some examples may implement the No-Explicit-Distribution mechanism to securely generate and share encryption keys. Each ECDH shared key may be derived from the user’s private key and the public key of the corresponding proxy node, retrieved from a decentralized registry or distributed hash table (DHT).

[0125] The No-Explicit-Distribution communication mechanism may refer to generating and sharing encryption keys without directly transmitting or explicitly distributing them between the involved parties. It may rely on cryptographic techniques like the Elliptic Curve Diffie-Hellman (ECDH) protocol to establish shared keys between parties. According to the No-Explicit-Distribution communication mechanism, the shared encryption keys are not transmitted over the network. Instead, they may be computed locally by both parties. Public keys are stored in a decentralized system like a DHT, which is resilient to single points of failure and tampering. The decentralized nature enhances robustness and scalability. Each shared key is unique to a specific communication pair and context, such as between the user and a particular proxy node for a specific transaction. This limits the usefulness of any compromised key to a single interaction, reducing the scope of potential damage.Fig. 4A illustrates method 400 for making a blockchain transaction of an example of the application.

[0126] In some examples, method 400 may include operations 420, 440 and 460. Operation 420 may include receiving an encrypted message destined for a blockchain node along a route including a plurality of proxy nodes in a proxy network, wherein the message includes original transaction information. Operation 440 may include determining, based on decryption of the encrypted message, a next hop for the message. Operation 460 may include forwarding the encrypted message to the next hop.

[0127] In some examples, each proxy node in the DMHPN may receive the encrypted message and decrypt the portion intended for it using its ECDH shared key. This process may reveal the proxy node's specific information and the identifier of the next hop. The proxy node may forward the message to the next hop while preserving the privacy of the original transaction, the route structure and other information. Each hop in the route only decrypts its assigned portion, helping ensure that no single proxy node has full visibility into the entire route or the original transaction's destination. This segmentation of knowledge may enhance the system’s security and privacy.

[0128] At operation 420 of some examples, a proxy node may receive an encrypted message destined for a blockchain node. The message travels along a route that includes multiple proxy nodes in the network. This route may be selected by the sender, such as a user or a wallet application, based on factors like network latency, availability, and trustworthiness.

[0129] The encrypted message contains original transaction information that the blockchain node will process upon receipt. To enhance privacy and security, the message also omits explicit identifiers of the blockchain node as the destination and the user as the sender, where the sender may be the initiator of the message. In this way, the proxy nodes have limited knowledge of the transaction's origin and destination, reducing the risk of tracing or unauthorized interference.

[0130] At operation 440 of some examples, a proxy node may determine the next hop in the route by decrypting its portion of the encrypted message. Each proxy node is assigned a specific segment of the message, encrypted using its unique Elliptic Curve Diffie-Hellman (ECDH) shared encryption key. Upon decryption, the proxy node may access the information required to identify the next hop in the route.Operation 440 may help ensure that no single proxy node has full visibility of the route or the message’s complete contents, preserving privacy for both the sender and the overall transaction. By limiting access to only the necessary information, the system minimizes the risk of data exposure or tampering during message transmission.

[0131] At operation 460, the proxy node forwards the encrypted message to the identified proxy node after determining the next hop. It makes the message continue along the predefined route until it reaches the final destination, typically a blockchain node.

[0132] Fig. 4B illustrates method 401 for making a blockchain transaction of an example of the application. Method 401 may include all contents of method 400 and further other operations.

[0133] In some examples, to support reward verification and distribution, the encrypted message may include a plurality of pieces of funding transaction information respectively associated with the plurality of proxy nodes. Consequently, method 401 may further include operations 481 and 482. Operation 481 may include determining, based on decryption of the encrypted message, a piece of funding transaction information for the proxy node. Operation 482 may include performing, based on the determined funding transaction information, reward verification for the proxy node.

[0134] In some examples, the encrypted message may further contain multiple pieces of funding transaction information, with each piece specifically associated with a proxy node in a multihop network. These pieces may enable reward verification, ensuring that each proxy node can verify and claim its entitlement for participating in the transaction routing process.

[0135] The encrypted message may include funding transaction information for each proxy node. Each piece of funding transaction information may be encrypted using the respective proxy node’s ECDH shared encryption key. This encryption ensures that only the intended proxy node can decrypt and access its specific piece of funding transaction information. The decrypted information may contain essential details such as the proxy node’s seed being a unique random value generated for the node, its crypto address used for receiving rewards, and other data that may be used for reward verification, such as a Merkle proof and the leaf position in the Merkle tree.When a proxy node receives the encrypted message, it may decrypt its assigned portion using its ECDH shared encryption key. This decryption may reveal the funding transaction information specific to the proxy node. For example, the decrypted data may indicate that the node is part of a funding transaction for a blockchain network and provide information verifying its role in the transaction.

[0136] Based on the decrypted funding transaction information, the proxy node may perform reward verification. This process often involves using a cryptographic structure such as a Merkle tree. The funding transaction information may include the proxy node’s seed, which was hashed and included as part of the Merkle tree, along with a cryptographic proof, or Merkle proof, that connects the proxy node’s leaf, which is based hashed seed and crypto address, to the Merkle root stored on the blockchain. The proxy node may use this proof to demonstrate its inclusion in the Merkle tree. The Merkle root, stored in the smart contract as part of the funding transaction, allows efficient and tamper-proof verification of the proxy node’s participation.

[0137] The funding transaction information may also indicate the reward value or conditions associated with the proxy node. The proxy node may verify this data against the details stored in the encrypted message or on the blockchain. If the funding transaction information confirms that the proxy node successfully forwarded the encrypted message to the next hop, the proxy node may determine its eligibility to claim the reward. This eligibility may later be verified by the smart contract, which may validate the Merkle proof and other relevant data.

[0138] This process may achieve several functionalities. For example, it may improve data confidentiality because each proxy node’s funding transaction information is encrypted with its specific ECDH shared key, preventing other nodes from accessing or manipulating this data. The use of Merkle trees allows for compact representation and efficient verification of rewards, ensuring scalability and efficiency even with numerous proxy nodes. Furthermore, the funding transaction information provides a verifiable link between the proxy node’s activities and its reward eligibility, promoting transparency and accountability throughout the system. Moreover, it may maintain privacy, as the funding transaction information excludes unnecessary details about other proxy nodes.

[0139] In some examples, the encrypted message may include payout information indicating a plurality of reward values that the plurality of proxy nodes are qualified to apply for respectively.In such a situation, method 401 may further include operation 483, which includes determining, based on decryption of the encrypted message, a reward value for the proxy node. The reward verification at operation 482 may be performed based on the determined funding transaction information and the reward value. In some other examples, the reward verification at operation 482 is not based on operation 483.

[0140] In some examples, the payout information may specify multiple reward values corresponding to a plurality of proxy nodes. Each proxy node’s reward value may be uniquely tied to its role in the transaction routing process. The claim may also include how the method enables each proxy node to determine its specific reward value through decryption and to perform reward verification using the decrypted reward value and other associated data.

[0141] In some examples, the encrypted message may include a segment of payout information, where each reward value corresponds to a specific proxy node in the route. To maintain confidentiality and privacy, each segment of the payout information is encrypted using the ECDH shared encryption key of the respective proxy node. Only the intended proxy node can decrypt its portion of the payout information, ensuring that no node can access or modify the reward details of others.

[0142] Upon receiving the encrypted message, a proxy node may decrypt its assigned portion using its ECDH shared encryption key. This decryption may reveal the reward value specifically allocated to the proxy node, along with other relevant information such as the conditions or criteria required for claiming the reward. The decryption process may make each proxy node access only its payout details, preserving the privacy and security of the multi-hop network. It may further specify that reward verification is performed based on the determined reward value and associated funding transaction information. Each proxy node may verify its eligibility for the reward by cross-referencing the decrypted reward value with details provided in the funding transaction information. For instance, the funding transaction information may include the proxy node’s seed, crypto address, and Merkle proof connecting the node to a Merkle tree stored on the blockchain. The proxy node may use these elements to demonstrate its inclusion in the Merkle tree and validate its participation in forwarding the message.

[0143] This verification process may serve two purposes in some examples. First, it promotes that only eligible proxy nodes can claim rewards, preventing fraudulent claims. Second, it provides a mechanism for efficient and transparent verification, as the Merkle proof allows the verifier,such as smart contract, to validate each claim without requiring the full dataset. The smart contract may reconstruct the relevant Merkle tree leaf using the proxy node’s seed and crypto address, validate the Merkle proof against the stored root, and confirm the reward value. In a scenario where the encrypted message contains payout information for three proxy nodes, each segment of the payout information may specify the reward value for a particular node and may be encrypted using the respective node’s ECDH shared key. When Proxy Node 1 decrypts its segment, it retrieves its reward value and additional information required for verification. Proxy Node 1 then verifies its reward eligibility by using the funding transaction information and submits its claim to the smart contract for payment. This process is repeated independently for Proxy Node 2 and Proxy Node 3, ensuring that each node’s rewards are processed securely and efficiently.

[0144] In some examples, the encrypted message includes a plurality of sequenced and respectively encrypted identifications of the plurality of proxy nodes. In such a situation, operation 440, determining the next hope for the message, may comprise operations 442 and 444. Operation 442 may include decrypting, based on an encryption key of the proxy node, the plurality of respectively encrypted identifications of the plurality of proxy nodes. Operation 444 may include determining, based on the decryption, the next hop, wherein the next hop is indicated by a successfully decrypted identification. In these examples, each proxy node may identify the next hop by decrypting its assigned portion of the message, which may include the identifier of the next proxy node. This step may promote that the message is routed correctly while preserving the anonymity of the route and the entities involved. The use of sequenced and encrypted identifications may prevent unauthorized nodes from interfering with or analyzing the routing process.

[0145] In some examples, method 401 may further comprise operation 484, which includes reporting the determined reward value to a blockchain associated with the encrypted message as a successfully claimed value after the proxy nodes receives a notification indicating a successful claim from a payout system.

[0146] In some examples, when a proxy node decrypts its portion of the encrypted message, it may retrieve its specific reward value and verify its eligibility for the reward. This verification may involve cross-referencing the decrypted information, such as the seed and crypto address, with the Merkle proof and funding transaction information stored on the blockchain. Once the verification is complete, the proxy node may be eligible to claim its reward.Before reporting the reward value to the blockchain as a successfully claimed value, the proxy node may wait for a notification from the payout system. The payout system is a component responsible for managing and coordinating the reward distribution process. It may help ensure that claims are processed in a secure and orderly manner, avoiding issues such as duplicate claims or misallocated rewards. Once the payout system confirms that the claim has been successfully processed, it may send a notification to the proxy node.

[0147] Upon receiving the notification, the proxy node may report its reward value to the blockchain. This reporting may include marking the reward as successfully claimed, updating the blockchain’s record of distributed rewards. The blockchain’s verifier, such as the smart contract, may validate the proxy node’s submission by verifying the associated data, such as the Merkle proof and the reward value, against the stored Merkle root. If the data is valid, the reward is marked as claimed, preventing further claims by the same proxy node.

[0148] Fig. 5 illustrates a user device 500 of an example of the application.

[0149] In some examples, user device 500 may be the user or user device 120 in Fig. 1 , or user or user device in examples corresponding to any of Figs. 2 to 4b.

[0150] In some examples, user device may include interfaces 520, and processing circuitry 540. User device 500 may be configured to implement, based on the cooperations between one or more tangible computer-readable (“machine-readable”) non-transitory storage media 550 and one or more processors 560 of the processing circuitry 540, operations and / or functionalities described with reference to the Figs. 1, 2, 3, 4a, and / or 4b, and / or one or more operations described herein, which are associated with user 120.

[0151] In some examples, user device 500 may perform the above implementations when the computer-executable instructions, such as the logic or computer program 570, are executed by one or more processors 560. In some examples, the interfaces 520 are interface means 520 and the processing circuitry 540 is processing means 540. In some examples, user device 500, which is also apparatus 500, may be in a computer system 500A which may include other apparatuses. In some examples, the logic or computer program 570 may include one or more software applications, such as a wallet application.

[0152] In some examples, interfaces 520 may be configured to communicate with other entities. For example, the entities may be proxy nodes in Figs. 1 and / or 2. In some examples, interfaces 520 may include one or more wireless interfaces including antennas, such as MIMO antennas,and / or wired interfaces, such as USB serial interfaces and / or RJ45 interfaces. The wireless interfaces may be configured to transmit and / or receive Wi-Fi signals, 3GPP signals and / or other wireless signals. The wired interfaces may be configured to receive signals transmitted via fiber, coaxial cables and other media.

[0153] In some examples, one or more processors 560 may be General Purpose CPUs, Mobile Processors, Server and Data Center Processors, Embedded Processors, Graphics Processing Units (GPUs), Specialized Processors, Microcontrollers, Field-Programmable Gate Arrays (FPGAs), Digital Signal Processors (DSPs), application-specific integrated circuits (ASICs), integrated circuits (ICs) and / or other circuitries having the capability of performing the operations of the controller in each and every example of this disclosure.

[0154] In some examples, the phrase “computer-readable non-transitory storage media” may be directed to include all machine and / or computer readable media, with the sole exception being a transitory propagating signal.

[0155] In some examples, the storage media 550 may include one or more types of computer-read-able storage media capable of storing data, including volatile memory, non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or rewriteable memory, and the like. For example, storage media 550 may include, RAM, DRAM, Double-Data-Rate DRAM (DDR-DRAM), SDRAM, static RAM (SRAM), ROM, programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), Compact Disk ROM (CD-ROM), Compact Disk Recordable (CD-R), Compact Disk Rewriteable (CD-RW), flash memory (e.g., NOR or NAND flash memory), content addressable memory (CAM), polymer memory, phase-change memory, ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, a disk, a floppy disk, a hard drive, an optical disk, a magnetic disk, a card, a magnetic card, an optical card, a tape, a cassette, and the like. The computer-readable storage media may include any suitable media involved with downloading or transferring a computer program from a remote computer to a requesting computer carried by data signals embodied in a carrier wave or other propagation medium through a communication link, e.g., a modem, radio or network connection.

[0156] Fig. 6 illustrates a proxy 600 of an example of the application.

[0157] In some examples, proxy node 600 may be any one of the proxy nodes 142 to 146 in Fig. 1, or any proxy node in examples corresponding to any of Figs. 2 to 4b.In some examples, proxy node 600 may include interfaces 620 like interfaces 620A and 620B, and processing circuitry 640. proxy node 600 may be configured to implement, based on the cooperations between one or more tangible computer-readable (“machine-readable”) non-transitory storage media 650 and one or more processors 660 of the processing circuitry 640, operations and / or functionalities described with reference to the Figs. 1, 2, 3, 4a, and / or 4b, and / or one or more operations described herein, which are associated with proxy nodes.

[0158] In some examples, proxy node 600 may perform the above implementations when the computer-executable instructions, such as the logic or computer program 670, are executed by one or more processors 660. In some examples, the interfaces 620 are interface means 620 and the processing circuitry 640 is processing means 640. In some examples, proxy node 600 may be in a computer system 600A which may include other apparatuses. In some examples, the logic or computer program 670 may include one or more software applications.

[0159] In some examples, the interfaces 620 may configured to communicate with other entities. For example, the entities may be proxy nodes in Figs. 1 and / or 2. In some examples, interfaces 620 may include one or more wireless interfaces including antennas, such as MIMO antennas, and / or wired interfaces, such as USB serial interfaces and / or RJ45 interfaces. The wireless interfaces may be configured to transmit and / or receive Wi-Fi signals, 3GPP signals and / or other wireless signals. The wired interfaces may be configured to receive signals transmitted via fiber, coaxial cables and other media.

[0160] In some examples, one or more processors 660 may be General Purpose CPUs, Mobile Processors, Server and Data Center Processors, Embedded Processors, Graphics Processing Units (GPUs), Specialized Processors, Microcontrollers, Field-Programmable Gate Arrays (FPGAs), Digital Signal Processors (DSPs), application-specific integrated circuits (ASICs), integrated circuits (ICs) and / or other circuitries having the capability of performing the operations of the controller in each and every example of this disclosure.

[0161] In some examples, the phrase “computer-readable non-transitory storage media” may be directed to include all machine and / or computer readable media, with the sole exception being a transitory propagating signal.

[0162] In some examples, the storage media 650 may include one or more types of computer-read-able storage media capable of storing data, including volatile memory, non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or rewriteable memory, and the like. For example, storage media 650 may include, RAM, DRAM,Double-Data-Rate DRAM (DDR-DRAM), SDRAM, static RAM (SRAM), ROM, programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), Compact Disk ROM (CD-ROM), Compact Disk Recordable (CD-R), Compact Disk Rewriteable (CD-RW), flash memory (e.g., NOR or NAND flash memory), content addressable memory (CAM), polymer memory, phase-change memory, ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, a disk, a floppy disk, a hard drive, an optical disk, a magnetic disk, a card, a magnetic card, an optical card, a tape, a cassette, and the like. The computer-readable storage media may include any suitable media involved with downloading or transferring a computer program from a remote computer to a requesting computer carried by data signals embodied in a carrier wave or other propagation medium through a communication link, e.g., a modem, radio or network connection.

[0163] In the following, some examples of a proposed concept are presented.

[0164] An example (e.g., example 1) relates to a method for making a blockchain transaction. The method may comprise obtaining an encrypted message destined for a blockchain node along a route including a plurality of proxy nodes in a proxy network, wherein the message includes original transaction information. The method may further comprise sending the encrypted message to a starting proxy node of the route.

[0165] An example (e.g., example 2) relates to a previously described example (e.g., example 1) or to any of the examples described herein, wherein the encrypted message includes a plurality of pieces of funding transaction information respectively associated with the plurality of proxy nodes, wherein each of the plurality of pieces of funding transaction information is for reward verification, and wherein the reward verification is on a qualification for applying for a reward for forwarding the encrypted message.

[0166] An example (e.g., example 3) relates to a previously described example (e.g., examples 1 or 2) or to any of the examples described herein, wherein the encrypted message includes payout information indicating a plurality of reward values that the plurality of proxy nodes are qualified to apply for respectively.

[0167] An example (e.g., example 4) relates to a previously described example (e.g., one of examples 1 to 3) or to any of the examples described herein, wherein the encrypted message includes a plurality of sequenced and respectively encrypted identifications of the plurality of proxy nodes.An example (e.g., example 5) relates to a previously described example (e.g., one of examples 1 to 4) or to any of the examples described herein, wherein the encrypted message is without information indicating the blockchain node as a destination of the message and / or information indicating an entity as an entity initializing the original transaction.

[0168] An example (e.g., example 6) relates to a previously described example (e.g., examples 2 or 3) or to any of the examples described herein, wherein the reward verification is based on a hash tree.

[0169] An example (e.g., example 7) relates to a previously described example (e.g., one of examples 1 to 6) or to any of the examples described herein, wherein the method further comprises obtaining, based on a No-Explicit-Distribution communication mechanism with the plurality of proxy nodes, a plurality of encryption keys for obtaining the encrypted message.

[0170] An example related relates to any previously described example (e.g., one of examples 1 to 7), the operations may be implemented or performed by a user device, such as a smart phone, or a circuitry.

[0171] An example (e.g., example 8) relates to a method for making a blockchain transaction implemented by a proxy node. The method may comprise receiving an encrypted message destined for a blockchain node along a route including a plurality of proxy nodes in a proxy network, wherein the message includes original transaction information. The method may further comprise determining, based on decryption of the encrypted message, a next hop for the message, and forwarding the encrypted message to the next hop.

[0172] An example (e.g., example 9) relates to a previously described example (e.g., example 8) or to any of the examples described herein, wherein the encrypted message includes a plurality of pieces of funding transaction information respectively associated with the plurality of proxy nodes, and wherein the method further includes determining, based on decryption of the encrypted message, a piece of funding transaction information for the proxy node, and performing, based on the determined funding transaction information, reward verification for the proxy node.

[0173] An example (e.g., example 10) relates to a previously described example (e.g., example 9) or to any of the examples described herein, wherein the encrypted message includes payout information indicating a plurality of reward values that the plurality of proxy nodes are qualified to apply for respectively. The method may further comprise determining, based on decryptionof the encrypted message, a reward value for the proxy node, and wherein the reward verification is performed based on the determined funding transaction information and the reward value.

[0174] An example (e.g., example 11) relates to a previously described example (e.g., one of examples 8 to 10) or to any of the examples described herein, wherein the encrypted message includes a plurality of sequenced and respectively encrypted identifications of the plurality of proxy nodes, and wherein determining, based on decryption of the encrypted message, a next hop for the message comprises decrypting, based on an encryption key of the proxy node, the plurality of respectively encrypted identifications of the plurality of proxy nodes, and determining, based on the decryption, the next hop, wherein the next hop is indicated by a successfully decrypted identification.

[0175] An example (e.g., example 12) relates to a previously described example (e.g., example 10) or to any of the examples described herein, wherein the method further comprises reporting the determined reward value to a blockchain associated with the encrypted message as a successfully claimed value after the proxy node receives a notification indicating a successful claim from a payout system.

[0176] An example (e.g., example 13) relates to an apparatus comprising a processor and a memory storing computer-readable instructions, which perform, when implemented by the processor, operations of any one of examples 1 to 7.

[0177] An example (e.g., example 14) relates to a proxy node comprising a processor and a memory storing computer-readable instructions, which perform, when implemented by the processor, operations of any one of examples 8 to 12.

[0178] An example (e.g., example 15) relates to a system comprising an apparatus of example 13 and a proxy node of example 14.

[0179] The aspects and features described in relation to a particular one of the previous examples may also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the features into the further example.Examples may further be or relate to a (computer) program including a program code to execute one or more of the above methods when the program is executed on a computer, processor or other programmable hardware component. Thus, steps, operations or processes of different ones of the methods described above may also be executed by programmed computers, processors or other programmable hardware components. Examples may also cover program storage devices, such as digital data storage media, which are machine-, processor- or computer-readable and encode and / or contain machine-executable, processorexecutable or computer-executable programs and instructions. Program storage devices may include or be digital storage devices, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media, for example. Other examples may also include computers, processors, control units, (field) programmable logic arrays ((F)PLAs), (field) programmable gate arrays ((F)PGAs), graphics processor units (GPU), application-specific integrated circuits (ASICs), integrated circuits (ICs) or system-on-a-chip (SoCs) systems programmed to execute the steps of the methods described above.

[0180] It is further understood that the disclosure of several steps, processes, operations or functions disclosed in the description or claims shall not be construed to imply that these operations are necessarily dependent on the order described, unless explicitly stated in the individual case or necessary for technical reasons. Therefore, the previous description does not limit the execution of several steps or functions to a certain order. Furthermore, in further examples, a single step, function, process or operation may include and / or be broken up into several sub-steps, -functions, -processes or -operations.

[0181] If some aspects have been described in relation to a device or system, these aspects should also be understood as a description of the corresponding method. For example, a block, device or functional aspect of the device or system may correspond to a feature, such as a method step, of the corresponding method. Accordingly, aspects described in relation to a method shall also be understood as a description of a corresponding block, a corresponding element, a property or a functional feature of a corresponding device or a corresponding system.

[0182] As used herein, the term “module” refers to logic that may be implemented in a hardware component or device, software or firmware running on a processing unit, or a combination thereof, to perform one or more operations consistent with the present disclosure. Software and firmware may be embodied as instructions and / or data stored on non-transitory computer-readable storage media. As used herein, the term “circuitry” can comprise, singly or inany combination, non-programmable (hardwired) circuitry, programmable circuitry such as processing units, state machine circuitry, and / or firmware that stores instructions executable by programmable circuitry. Modules described herein may, collectively or individually, be embodied as circuitry that forms a part of a computing system. Thus, any of the modules can be implemented as circuitry. A computing system referred to as being programmed to perform a method can be programmed to perform the method via software, hardware, firmware, or combinations thereof.

[0183] Any of the disclosed methods (or a portion thereof) can be implemented as computer-executable instructions or a computer program product. Such instructions can cause a computing system or one or more processing units capable of executing computer-executable instructions to perform any of the disclosed methods. As used herein, the term “computer” refers to any computing system or device described or mentioned herein. Thus, the term “computerexecutable instruction” refers to instructions that can be executed by any computing system or device described or mentioned herein.

[0184] The computer-executable instructions can be part of, for example, an operating system of the computing system, an application stored locally to the computing system, or a remote application accessible to the computing system (e.g., via a web browser). Any of the methods described herein can be performed by computer-executable instructions performed by a single computing system or by one or more networked computing systems operating in a network environment. Computer-executable instructions and updates to the computer-executable instructions can be downloaded to a computing system from a remote server.

[0185] Further, it is to be understood that implementation of the disclosed technologies is not limited to any specific computer language or program. For instance, the disclosed technologies can be implemented by software written in C++, C#, Java, Perl, Python, JavaScript, Adobe Flash, C#, assembly language, or any other programming language. Likewise, the disclosed technologies are not limited to any computer system or type of hardware.

[0186] Furthermore, any of the software-based examples (comprising, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, ultrasonic, and infrared communications), electronic communications, or other such communication means.The disclosed methods, apparatuses, and systems are not to be construed as limiting in any way. Instead, the present disclosure is directed toward all novel and nonobvious features and aspects of the various disclosed examples, alone and in various combinations and sub-com-binations with one another. The disclosed methods, apparatuses, and systems are not limited to any specific aspect or feature or combination thereof, nor do the disclosed examples require that any one or more specific advantages be present, or problems be solved.

[0187] Theories of operation, scientific principles, or other theoretical descriptions presented herein in reference to the apparatuses or methods of this disclosure have been provided for the purposes of better understanding and are not intended to be limiting in scope. The apparatuses and methods in the appended claims are not limited to those apparatuses and methods that function in the manner described by such theories of operation.

Claims

ClaimsWhat is claimed is:

1. A method for making a blockchain transaction, comprising:obtaining an encrypted message destined for a blockchain node along a route including a plurality of proxy nodes in a proxy network, wherein the message includes original transaction information; andsending the encrypted message to a starting proxy node of the route.

2. The method of claim 1, wherein the encrypted message includes a plurality of pieces of funding transaction information respectively associated with the plurality of proxy nodes, wherein each of the plurality of pieces of funding transaction information is for reward verification, and wherein the reward verification is on a qualification for applying for a reward for forwarding the encrypted message.

3. The method of claim 2, wherein the encrypted message includes payout information indicating a plurality of reward values that the plurality of proxy nodes are qualified to apply for respectively.

4. The method of claim 1 , wherein the encrypted message includes a plurality of sequenced and respectively encrypted identifications of the plurality of proxy nodes.

5. The method of claim 1, wherein the encrypted message is without information indicating the blockchain node as a destination of the message and / or information indicating an entity as an entity initializing the original transaction.

6. The method of claim 1, wherein the reward verification is based on a hash tree.

7. The method of claim 1, the method further comprising:obtaining, based on a No-Explicit-Distribution communication mechanism with the plurality of proxy nodes, a plurality of encryption keys for obtaining the encrypted message.

8. A method for making a blockchain transaction implemented by a proxy node, comprising: receiving an encrypted message destined for a blockchain node along a route including a plurality of proxy nodes in a proxy network, wherein the message includes original transaction information;determining, based on decryption of the encrypted message, a next hop for the message; andforwarding the encrypted message to the next hop.

9. The method of claim 8,wherein the encrypted message includes a plurality of pieces of funding transaction information respectively associated with the plurality of proxy nodes; andwherein the method further includes:determining, based on decryption of the encrypted message, a piece of funding transaction information for the proxy node, andperforming, based on the determined funding transaction information, reward verification for the proxy node.

10. The method of claim 9,wherein the encrypted message includes payout information indicating a plurality of reward values that the plurality of proxy nodes are qualified to apply for respectively;wherein the method further comprises:determining, based on decryption of the encrypted message, a reward value for the proxy node; andwherein the reward verification is performed based on the determined funding transaction information and the reward value.

11. The method of claim 8,wherein the encrypted message includes a plurality of sequenced and respectively encrypted identifications of the plurality of proxy nodes, andwherein determining, based on decryption of the encrypted message, a next hop for the message comprises:decrypting, based on an encryption key of the proxy node, the plurality of respectively encrypted identifications of the plurality of proxy nodes, anddetermining, based on the decryption, the next hop, wherein the next hop is indicated by a successfully decrypted identification.

12. The method of claim 10, the method further comprising:reporting the determined reward value to a blockchain associated with the encrypted message as a successfully claimed value after the proxy nodes receives a notification indicating a successful claim from a payout system.

13. An apparatus, comprising:a processor; anda memory storing computer-readable instructions, which perform, when implemented by the processor, operations of any one of claims 1 to 7.

14. A proxy node, comprising:a processor; anda memory storing computer-readable instructions, which perform, when implemented by the processor, operations of any one of claims 8 to 12.

15. A system, comprising an apparatus of claim 13 and a proxy node of claim 14.

Images