Patent Application
20230162178
Aspects of the present disclosure relate to cryptocurrency transactions, and more particularly to rebroadcast of cryptocurrency transactions.
Blockchain networks are considered “eventually consistent” systems, in that for a given transaction it may take arbitrarily long to be propagated across the network to all nodes. Given the arbitrarily long time period that a transaction may take to be propagated, it can be a challenge to determine if a given transaction was picked up and processed by the network in a timely manner to support cryptocurrency transactions and related commerce. Moreover, some blockchains are slow and unstable, and unable to handle large volumes of transactions at a scale needed for a commercial-grade financial transaction system, causing further delay of a transaction being picked up and/or processed.
As a result, a user may naively rebroadcast unmodified transactions if they do not see that their initial transaction was picked up by a given blockchain. In some cases, a user may attempt to get their transaction to be picked up by paying large transaction fees. However, a transaction may not be picked up at all even with repeated broadcasting due to blockchain network unreliability, leaving a user without having completed the transaction. On the other hand, repeated broadcasting could result in the transaction being picked up multiple time, resulting in double spending. Because of the uncertainties created around cryptocurrency transaction broadcasts, how to mitigate situations where a transaction may not have been picked up for processing, blockchain networks and infrastructure can be challenging technical environments upon which to develop commercial financial transaction rails.
Accordingly, what is needed are systems and methods to mitigate the effects of conventional approaches around cryptocurrency transaction broadcast and rebroadcasting.
Certain embodiments provide a method for broadcasting a cryptocurrency transaction, that includes receiving a sending address of a first wallet operable on a blockchain of a network having a network protocol, a receiving address of a second wallet operable on the blockchain, and a transaction amount of a token, generating replay protection data based on the network protocol, and generating a transaction comprising the sending address, the receiving address, the transaction amount, the replay protection data, and a digital signature comprising a hash based on one of the sending address, the receiving address, the transaction amount, or the replay protection data. The method further includes generating a transaction database record comprising the transaction and a transaction broadcast request, broadcasting the transaction to the network according to the network protocol, and receiving an indication that the blockchain does not include the transaction, responsive to querying the blockchain with the sending address. The method further includes locking the transaction broadcast request in the transaction database record, verifying that the transaction is correctly formatted to be operable on the blockchain, unlocking the transaction broadcast request, and rebroadcasting the transaction to the network.
Other embodiments provide processing systems configured to perform the aforementioned methods as well as those described herein; non-transitory, computer-readable media comprising instructions that, when executed by one or more processors of a processing system, cause the processing system to perform the aforementioned methods as well as those described herein; a computer program product embodied on a computer readable storage medium comprising code for performing the aforementioned methods as well as those further described herein; and a processing system comprising means for performing the aforementioned methods as well as those further described herein.
The following description and the related drawings set forth in detail certain illustrative features of one or more embodiments.
The appended figures depict certain aspects of the one or more embodiments and are therefore not to be considered limiting of the scope of this disclosure.
To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the drawings. It is contemplated that elements and features of one embodiment may be beneficially incorporated in other embodiments without further recitation.
In the following, reference is made to embodiments of the disclosure. However, it should be understood that the disclosure is not limited to specific described embodiments. Instead, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice the disclosure. Furthermore, although embodiments of the disclosure may achieve advantages over other possible solutions and/or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the disclosure. Thus, the following aspects, features, embodiments, and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to “the disclosure” shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).
Aspects of the present disclosure provide apparatuses, methods, processing systems, and computer-readable mediums for reliable cryptocurrency rebroadcasting. According to certain embodiments, after an initial transaction broadcast, disclosed systems listen to, or monitor, a blockchain to determine if the transaction was included in the blockchain. If, after a short time period, the transaction is not included in the blockchain, a transaction database record for the transaction is locked to prevent inadvertent rebroadcast. While the record is locked, the transaction format and replay information are verified to be operable on the blockchain, and depending on the blockchain, the replay information is updated. For blockchains having a transaction fee, the system reviews recent transactions to determine appropriate fees and, if needed, updates the transaction fee accompanying the transaction. Once the replay information is verified/updated, and the transaction fee is sized appropriately, the transaction database record is unlocked and the transaction is rebroadcasted.
According to certain embodiments, systems and methods are disclosed that monitor outgoing cryptocurrency transactions with processes that ensure a transaction is only processed by a blockchain one time. When a transaction is transmitted from a network client, the system first broadcasts the transaction with a low fee, for networks that require a fee. The network client then listens to, or monitors, the blockchain to determine if the transaction was included in the chain. In this context, in listening to, or monitoring, the blockchain, the network client queries the chain with the ID or hash of the transaction to see if the chain returns a value indicating that the transaction has been included in the chain, and if the transaction was successful. According to certain embodiments, the network client may wait a set amount of time, for example from 2-5 minutes in certain embodiments, before querying the chain for inclusion of the transaction. If the transaction was included, and successful, the network client marks the transaction as complete in a record related to the transaction in a transaction database.
If the network client fails to receive an indication that the transaction was included, the network client may then determine how to proceed with rebroadcasting the transaction to the blockchain. According to certain embodiments, depending on the network and blockchain, checks are performed to ensure that the original transaction is no longer valid. These checks may include computing the expiration time of the original transaction, which may be based on clock time or network time (e.g., a timestamp attached to the top block of the blockchain), or measured by waiting for a certain number of blocks to be added to the blockchain, before rebroadcasting. In embodiments where the network utilizes transaction address nonces, a transaction nonce may be used to ensure that the original transaction and a newly broadcasted transaction cannot both be accepted on the blockchain. According to certain embodiments, the network client may additionally use a transaction database having a record of the transaction to lock the transaction record (e.g., by locking a transaction broadcast request of the record) to ensure only one broadcast attempt is being made for a given transaction.
Once the checks have been satisfied, the network client of the system may rebroadcast the transaction. According to certain embodiments, the transaction may be rebroadcast with additional fees, for blockchains that allow for variable transaction fee amounts. When the transaction is rebroadcast, the network client resigns the transaction as necessary, and rebroadcasts the transaction.
System 100 further includes a platform 108 coupled to the wallet 104, for making calls to a cryptocurrency network client, such as network client 112, with a transaction generated by the wallet 104. Platform 108 includes an outbound transaction worker 116 for interacting with the network client 112 in this context.
Network client 112 is one of many network clients, each configured to interact with a particular cryptocurrency network, such as network 120. By way of example, network 120 may be one of ALGORAND™, BITCOIN™, ETHEREUM™, SOLANA™, STELLAR™, TRON™, and other cryptocurrency networks. Network 120 includes a number of network nodes, such as node 122, that may be a wallet such as second wallet 126, a validation anchor, such as a proof of work or proof of stake node, or other node typically found in a cryptocurrency network.
Network client 112 includes a transaction database 124 for storing a transaction received from the wallet 104. When a transaction is being prepared for broadcast, or rebroadcast, to network 120 as described below, the record containing the transaction may be locked to prevent inadvertent broadcast/rebroadcast. By way of example, in a multi-threaded process environment, there may be more than one thread having a valid broadcast command for a transaction, and locking the transaction database 124 record prevents broadcast before all actions for a proper transaction broadcast/rebroadcast, have been taken.
Network client 112 further includes a validator component 128. When a transaction is stored or updated in the transaction database, validator component 128 validates that transaction field values are correct. These transaction field values may include and are not limited to sending address (e.g., sending address of wallet 104 or proxy for such sending address), receiving address of a receiving wallet (or a proxy for such receiving address), transaction amount verification (e.g., verifying that the quantity of cryptocurrency tokens to send is available in the wallet 104), and replay protection (described below). By way of example, the sending address and receiving address may be validated by comparing the relevant transaction data against the sending and receiving address as stored on a blockchain 132 of the network 120.
Replay protection 134 generates appropriate replay protection for a transaction on the network 120 that is dependent on one or more replay protection functionalities provided by the network 120. By way of example and not limitation, some networks such as ETHEREUM and STELLAR provide replay protection in the form of a transaction nonce as part of a transaction. A transaction nonce provides a unique identifier for a transaction from a discrete wallet that is tracked on the blockchain 132. According to certain embodiments, a unique transaction nonce is provided for each transaction, and the network 120 will only accept transaction nonces from a given wallet in a particular order, such as numerical order; that is, a transaction having nonce n is to be processed (or intentionally cancelled or otherwise revoked) before a transaction having a nonce n+1. Nonce-based replay protection provides for reliable replacement of a broadcasted transaction: if a wallet wants to replace a transaction that has been broadcasted but not yet accepted into the blockchain 132, it can broadcast (e.g., rebroadcast) a second transaction with the same transaction nonce, even where other parameters of the transaction have changed, such as the transaction fee, and the blockchain 132 will only accept one transaction having the given transaction nonce from the wallet 104.
Replay protection 134 may be provided in some networks by including reference data as part of a transaction from the wallet 104. Examples of networks that use reference data for transaction validation include SOLANA™ and TRON™. By way of example, such reference data may be a timestamp of a recent block (either a real-time timestamp, a block number, or other indicator of a relative creation time for a block) of the blockchain 132, and in other examples, a hash of a recent block of the blockchain 132 may be used. The timestamp or hash of the recent block provides a relative indicator of creation of that recent block, such that time since creation may be measured relative to that recent block in terms of the passage of real time, or number of blocks created since then. In either embodiments, the passage of time may be measured in real or relative terms. The network 120 will have a transaction protocol that receives the reference data of the transaction and compare to a set of rules that determine if a transaction is valid based on the passage of time since the reference data event occurred. Reference data may be used to determine if a broadcasted transaction remains valid, that in turn can cause the system to wait for the reference data to expire before rebroadcasting the transaction, or rebroadcasting while the initial broadcast transaction remains valid and take additional precautions to prevent a doubled transaction.
For some networks, both transaction nonces and reference data may be generated by replay protection component 134, such as FLOW™. For these networks, a transaction nonce is considered the primary form of replay protection, and the reference data (timestamp and/or block hash) is included as an additional form of replay protection to mitigate the ability for old transactions to be processed.
According to certain embodiments, replay protection may be implemented as unspent transaction output (UTXO), on some networks, such as on BITCOIN™.
Network client 112 further includes a signing service 136 for signing a transaction (e.g., including signing data as part of a transaction), prior to broadcast, to indicate authenticity of the source and contents of the transaction. According to certain embodiments, signing data may include the sending address of the wallet 104, the receiving address of the receiving second wallet 126, the transaction amount (e.g., how many tokens are involved in the transaction), and/or the replay protection data generated by replay protection component 134. Although the second wallet 126 is depicted as being on the network 120, according to certain embodiments the second wallet 126 may be coupled to the platform similar to wallet 104. According to certain embodiments, signing data may be a hashed and/or encrypted version of one or more of the above elements.
Network client 112 further includes a broadcaster component 140 that broadcasts the transaction to the network 120. In one example, the transaction is a data structure having transaction data that includes a sending address of the wallet 104, the receiving address of the receiving wallet, replay protection generated by replay protection component 134, and signing data from the signing service 136. As will be discussed below, the broadcaster component 140 can also rebroadcast a transaction that has not been picked up by the network 120, usually after some time period, and according to some embodiments, having some transaction data that has been changed, such as replay protection data, and signing data.
Network client 112 further includes a listener component 144, configured to listen to, or monitor, the blockchain 132. Based on the query, the network client 112 flags the transaction record in the transaction database as complete if the transaction has been found in a block of the blockchain 132 as a result of the query. If the transaction has not been found in a block of the blockchain 132, the network client 112 follows a process or method as described elsewhere herein.
Network client 112 further includes a fee listener 148, which may be used for networks having a variable transaction fee protocol, such as ETHEREUM. When the listener component 144 indicates that a transaction in the transaction database 124 has not been included in a block of the blockchain 132, fee listener 148 queries the blockchain 132, receiving in return an estimate from node 120 of a transaction fee amount that would be acceptable to include the transaction in the blockchain 132. Different networks that accept variable transaction fees calculate this estimate differently. Once the node 122 has returned the estimated fee, fee listener 148 may adjust the fee estimate.
In one example, the fee listener adjusts the fee based on a linear multiplier. The linear multiplier may vary based on circumstances, for example, enabling network client 112 to use a larger linear multiplier for urgent transactions, or smaller linear multipliers for transactions of a lower priority (e.g., transactions for which additional rebroadcast attempts are acceptable). In the event a transaction is to be rebroadcast, each successive rebroadcast will take the previous linear multiplier as input to determine the transaction fee amount for the subsequent rebroadcast.
In some aspects, the linear multiplier may be set statically for different priority levels assigned to different transactions. Higher values for the linear multiplier may be assigned to higher priority levels, such as priority levels for transactions that are visible to users within a cryptocurrency network. Lower values for the linear multiplier may similarly be assigned to lower priority levels, such as priority levels for transactions that are internal to a cryptocurrency network. The linear multiplier may be set, for example, based on a matrix of tokens, activity, and product for which a transaction is being performed. A linear multiplier may be defined for a base chain or for each type of token committed to a base chain. Activity multipliers may allow for different linear multipliers to be defined for different types of activity within a cryptocurrency network so that higher-priority activity can accept higher transaction fees (and thus be processed more quickly) and that lower priority activity can be processed when transaction fees are lower. Finally, different products may have different multipliers that, for example, may prioritize completion of transactions for one product over another product on the same cryptocurrency network.
In some aspects, the linear multiplier may be set dynamically. For example, a network client 112 can specify a linear multiplier to use in determining an acceptable transaction fee amount for including the transaction in the blockchain 132. Generally, higher values specified for the linear multiplier may allow a transaction to be completed more quickly, in exchange for paying a higher transaction fee for including the transaction in the blockchain. Likewise, lower values for the linear multiplier may delay completion of a transaction, as the transaction may not be committed to the blockchain 132 while the transaction fee amount is higher than an acceptable transaction fee amount.
Note that while a linear multiplier has been described as one example, aspects described herein are not limited to use of a linear multiplier. For example, other mechanisms and algorithms for setting the fee may be used.
At block 204, the platform 108 receives a request from the wallet 104 to broadcast a transaction to network 120. According to certain embodiments, the request includes a sending address of the wallet 104, a receiving address of a receiving wallet, and a transaction amount of a cryptocurrency token. Outbound transaction worker 116 receives the request and transmits the request to the network client 112.
At block 208, after storing the transaction request in a record of the transaction database 124 and locking the record to prevent inadvertent broadcast of the transaction to the network 120, replay protection component 134 generates replay protection in accordance with the replay protection protocols of the network 120, and stores the replay protection in the record.
At block 212, the signing service 136 signs the transaction, with signing data stored in the record, and the record is unlocked. The broadcaster component 140 assembles the transaction data structure and broadcasts the transaction, including sending address, receiving address, replay protection data, and signing data, to the network 120 where a node 122 may pick up the transaction for inclusion in the blockchain 132.
At block 216, the listener component 144 queries the blockchain after a predetermined amount of time, and if the transaction has been included in the blockchain, the process 200 ends at block 220. If the listener component 144 does not receive an indication that the transaction has been included in the blockchain 132, the process 200 proceeds to block 224. In this context, the predetermined amount of time is based on the typical amount of time taken for a transaction to be included in the blockchain 132. According to certain embodiments, this may be determined by replay protection data generated by replay protection component 134 for the network 120 (e.g., a set amount of real time, or a number of blocks since the block hashed as replay protection has been created), and in other embodiments the amount of time may be the average clock time taken on average over the previous number of transactions (e.g., 100 transactions), as detected by listener component 144.
At block 224, as a result of the listener component 144 having not received an indication that the transaction had been included in the blockchain 132, the transaction database 124 record containing the transaction data is locked to prevent inadvertent rebroadcast.
At block 228, the network client 112 verifies the transaction format, including sending and receiving address, transaction amount, replay protection, and signature, are operable on the blockchain 132.
At block 232, replay protection component 134 updates the replay protection in the transaction database 124, depending on the replay protection protocols of the network. According to certain embodiments, a transaction nonce may be updated to reflect the same transaction nonce so as to ensure that only one version of the transaction is included in the blockchain. In some embodiments, reference data is updated if the original reference data has become outdated. As not all networks use replay protection, or in some cases there is no need to change replay protection, block 232 may be optional.
At block 236, the transaction fee of the transaction database is updated (e.g., increased) so that the transaction, once rebroadcasted by the broadcaster component 140, is more likely to be picked up by the blockchain 132. The transaction fee is updated based on a data provided by the fee listener 148 that receives data from the blockchain regarding transaction fee amounts from recent successful transactions, and provides a normalized fee amount for the transaction, to increase the probability that the transaction is picked up.
At block 240, the transaction record in the transaction database 124 is unlocked, and the data from the transaction record is provided to block 212, where the transaction for the network 120 is generated, signed, and rebroadcast to the network 120.
Note that process 200 is described in the context of components of example system 100, and in other embodiments, process 200 may be performed by other systems configured to perform the same steps of process 200.
At block 304, the network client 112 receives a sending address of a first wallet operable on a blockchain of a network having a network protocol, a receiving address of a second wallet operable on the blockchain, and a transaction amount of a token.
At block 308, the replay protection component 134 generates replay protection data based on the network protocol of the network 120.
At block 312 the network client 112 generates a transaction comprising the sending address, the receiving address, the transaction amount, the replay protection data, and a digital signature comprising a hash based on one of the sending address, the receiving address, the transaction amount, or the replay protection data, and stores the transaction in the transaction database 124.
At block 316, the network client 112 generates a transaction database 124 record comprising the transaction and a transaction broadcast request.
At block 320, the network client 112 broadcasts the transaction to the network according to the network protocol.
At block 324, the network client 112 receives an indication that the blockchain does not include the transaction, responsive to querying the blockchain with the sending address.
At block 328, the network client 112 locks the transaction broadcast request in the transaction database record.
At block 332, the network client 112 verifies that the transaction is correctly formatted to be operable on the blockchain 132.
At block 336, the network client 112 unlocks the transaction broadcast request.
At block 340, the broadcaster component 140 rebroadcasts the transaction to the network 120.
The method further comprises determining that the transaction is one or not valid, or will be invalidated by the rebroadcasting, based on the replay protection data.
The method further comprises querying the blockchain with the sending address, responsive to the locking, and determining that the blockchain does not include the transaction. According to certain embodiments, the method further includes verifying that the transaction is not operable.
According to certain embodiments the method further comprises generating a second transaction, comprising the sending address, the receiving address, and the transaction amount, generating new replay protection data, and signing the second transaction with a second digital signature comprising a hash based on one of the sending address, the receiving address, the transaction amount, or the new replay protection data. According to certain embodiments, generating the new replay protection data comprises one of generating updated replay protection data or increasing a transaction fee. According to certain embodiments, the updated replay protection data comprises one of a timestamp, a reference block hash, a transaction hash, a transaction nonce, or an unspent transaction output (UTXO).
Note that
Processing system 400 includes a central processing unit (CPU) 402 connected to a data bus 416. CPU 402 is configured to process computer-executable instructions, e.g., stored in memory 408, and to cause the processing system 400 to perform methods described herein, for example with respect to
Processing system 400 further includes input/output (I/O) device(s) 412 and interfaces 404, which allows processing system 400 to interface with input/output devices 412, such as, for example, keyboards, displays, mouse devices, pen input, and other devices that allow for interaction with processing system 400. Note that processing system 400 may connect with external I/O devices through physical and wireless connections (e.g., an external display device).
Processing system 400 further includes a network interface 406, which provides processing system 400 with access to external network 414 and thereby external computing devices.
Processing system 400 further includes memory 408, which in this example includes a receiving component 418, a generating component 420, a broadcasting component 422, a locking component 424, a verifying component 426, an unlocking component 428, and a rebroadcasting component 430, for performing operations, such as those described with respect to
Note that
The preceding description is provided to enable any person skilled in the art to practice the various embodiments described herein. The examples discussed herein are not limiting of the scope, applicability, or embodiments set forth in the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments. For example, changes may be made in the function and arrangement of elements discussed without departing from the scope of the disclosure. Various examples may omit, substitute, or add various procedures or components as appropriate. For instance, the methods described may be performed in an order different from that described, and various steps may be added, omitted, or combined. Also, features described with respect to some examples may be combined in some other examples. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects set forth herein. In addition, the scope of the disclosure is intended to cover such an apparatus or method that is practiced using other structure, functionality, or structure and functionality in addition to, or other than, the various aspects of the disclosure set forth herein. It should be understood that any aspect of the disclosure disclosed herein may be embodied by one or more elements of a claim.
As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects.
As used herein, a phrase referring to “at least one of” a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiples of the same element (e.g., a-a, a-a-a, a-a-b, a-a-c, a-b-b, a-c-c, b-b, b-b-b, b-b-c, c-c, and c-c-c or any other ordering of a, b, and c).
As used herein, the term “determining” encompasses a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Also, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Also, “determining” may include resolving, selecting, choosing, establishing and the like.
The methods disclosed herein comprise one or more steps or actions for achieving the methods. The method steps and/or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims. Further, the various operations of methods described above may be performed by any suitable means capable of performing the corresponding functions. The means may include various hardware and/or software component(s) and/or module(s), including, but not limited to a circuit, an application specific integrated circuit (ASIC), or processor. Generally, where there are operations illustrated in figures, those operations may have corresponding counterpart means-plus-function components with similar numbering.
The following claims are not intended to be limited to the embodiments shown herein, but are to be accorded the full scope consistent with the language of the claims. Within a claim, reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. No claim element is to be construed under the provisions of 35 U.S.C. § 112(f) unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for.” All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims.
