WO2024033806A1

WO2024033806A1 - Systems and methods for transaction timing optimization

Info

Publication number: WO2024033806A1
Application number: PCT/IB2023/058006
Authority: WO
Inventors: Johannes Valentin PFEFFER; Daniel Thomas Max PFEFFER; Malte KEIL; Alex PLUTTA
Original assignee: Corpus.Ventures Gmbh
Priority date: 2022-08-08
Filing date: 2023-08-08
Publication date: 2024-02-15

Abstract

Systems and methods for optimizing timing of distributed ledger transactions. In some embodiments, an optimization engine may receive a query for optimal timing for submitting a transaction to a distributed ledger. The query may indicate a deadline by which the transaction is to be submitted to the distributed ledger. The optimization engine may determine a predicted minimum transaction demand value between a current time and the deadline, and whether a current transaction demand value is above the predicted minimum transaction demand value. In response to determining that the current transaction demand value is above the predicted minimum transaction demand value, the optimization engine may provide a negative response to the query.

Description

SYSTEMS AND METHODS FOR TRANSACTION TIMING OPTIMIZATION

BACKGROUND

Distributed ledgers have been used to provide tamper-resistant records of transactions such as transfers of cryptocurrency, non-fungible tokens (NFTs), etc. Such a ledger may include a data structure that is replicated across a network of nodes. The network nodes may carry out a suitable consensus protocol to ensure that the different replicas of the data structure are consistent with each other. The consensus protocol may be chosen such that an attacker may modify the data structure only by gaining control of at least a threshold percentage of consensus weight within the network (e.g., a majority of network hash rate).

Distributed ledgers may be public, private, or permissioned. Any user may submit a transaction to a public distributed ledger. If the transaction is valid, the transaction may be added to the distributed ledger through an inclusion mechanism, thereby causing a state change on the distributed ledger.

SUMMARY

In accordance with some embodiments, a computer-implemented method is provided for optimizing timing of distributed ledger transactions, the method comprising acts of: receiving a query for optimal timing for submitting a transaction to a distributed ledger, the query indicating a deadline by which the transaction is to be submitted to the distributed ledger; determining a predicted minimum transaction demand value between a current time and the deadline; determining whether a current transaction demand value is above the predicted minimum transaction demand value; and in response to determining that the current transaction demand value is above the predicted minimum transaction demand value, providing a negative response to the query.

In accordance with some embodiments, a system is provided, comprising at least one processor and at least one computer-readable storage medium having stored thereon instructions which, when executed, program the at least one processor to perform any of the methods described herein.

In accordance with some embodiments, at least one computer-readable storage medium is provided, having stored thereon instructions which, when executed, program at least one processor to perform any of the methods described herein. BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 shows an illustrative transaction timing optimization engine 100, in accordance with some embodiments.

FIG. 2 shows an illustrative managed transaction record 200, in accordance with some embodiments.

FIG. 3 shows illustrative managed transaction states 300, in accordance with some embodiments.

FIG. 4 shows an illustrative plot 400 of transaction fee fluctuations, in accordance with some embodiments.

FIG. 5A shows an illustrative process 500 for predicting transaction demand, in accordance with some embodiments.

FIG. 5B shows an illustrative process 550 for determining an optimal timing for submitting a transaction, in accordance with some embodiments.

FIG. 6 shows an illustrative plot 600 of historical and predicted transaction demand, in accordance with some embodiments.

FIG. 7 shows an illustrative plot 700 of historical and predicted transaction demand, in accordance with some embodiments.

FIG. 8 shows, schematically, an illustrative computer 1000 on which any aspect of the present disclosure may be implemented.

DETAILED DESCRIPTION

Aspects of the present disclosure relate to systems and methods for optimizing timing of distributed ledger transactions.

Like all distributed systems, distributed ledgers face scalability challenges. It is generally accepted that, to maintain a high level of security and decentralization, scalability must be sacrificed to some extent. For instance, a network of nodes managing a distributed ledger may expend a significant amount of computation and/or other resources to achieve consensus. Moreover, it may be resource intensive to synchronize the distributed ledger’s state in a timely manner (e.g., over the Internet), so that every network node participating in the consensus protocol has an up-to-date copy of the state.

As a result, for a given distributed ledger system, there may be an intrinsic limit on a number of transactions that may be processed per unit time.¹ Accordingly, a priority mechanism may be

¹ At present, Bitcoin processes about 7 transactions per second (tps), whereas Ethereum processes about 15 tps. provided such that, when transactions are submitted faster than can be processed by the system, higher priority transactions may be processed before lower priority ones.

The inventors have recognized and appreciated that, while a priority mechanism may facilitate orderly processing when there is a spike of transactions, the priority mechanism does not prevent the spike from occurring in the first place.

The inventors have further recognized and appreciated that not all transactions submitted for processing are time sensitive, and that some spikes of transactions are merely happenstance, and are therefore preventable. Accordingly, in some embodiments, techniques are provided for optimizing timing of distributed ledger transactions. For instance, when a transaction is ready for processing by a distributed ledger, the transaction may be held in a temporary storage, instead of being submitted to the distributed ledger right away. While the transaction is in the temporary storage, one or more prediction techniques may be applied to determine an optimal timing for submitting the transaction to the distributed ledger.

In this manner, when transaction demand is high, transactions that are not time sensitive may be postponed until transaction demand has fallen, which may prevent or at least alleviate spikes. Moreover, user experience may be improved, as users no longer need to rely on guesswork to decide when to submit transactions.

In some embodiments, a transaction may be labeled with a deadline by which the transaction is to be submitted to the distributed ledger for processing. Accordingly, the optimal timing for submitting the transaction may be determined based on the deadline.

Additionally, or alternatively, the optimal timing for submitting the transaction may be determined based on predicted transaction demand over a prediction horizon. For instance, a current time may be determined to be the optimal timing if transaction demand is predicted to rise over the prediction horizon.

The prediction horizon may be selected in any suitable manner. As an example, the prediction horizon may be a window between a current time and a deadline for submitting the transaction. As another example, the prediction horizon may be a window having a default length (e.g., 15 min, 30 min, 1 hour, 12 hours, 24 hours, etc.), starting at the current time.

In some embodiments, transaction demand may be predicted based on one or more patterns observed from historical transaction data. For instance, past transaction demand may be recorded as a time domain signal. A Fourier transform may be applied to the time domain signal to obtain one or more frequency domain components, which may be analyzed to detect one or more patterns. It should be appreciated that the techniques introduced above and/or described in greater detail below may be implemented in any of numerous ways, as these techniques are not limited to any particular manner of implementation. Examples of implementation details are provided herein solely for purposes of illustration. Furthermore, the techniques described herein may be used individually or in any suitable combination, as aspects of the present disclosure are not limited to any particular technique or combination of techniques.

FIG. 1 shows an illustrative transaction timing optimization engine 100, in accordance with some embodiments. For instance, the optimization engine 100 may be queried by a transaction management system 1 10 to determine an optimal timing for submitting a transaction to a distributed ledger 120.

In this example, the transaction management system 1 10 may provide a staging area for transactions to be submitted to the distributed ledger 120. For instance, a wallet application (not shown) may prepare a transaction data structure for a proposed transfer of one or more digital assets. The transaction data structure may include any suitable information, such as a FROM address identifying an account in which the one or more digital assets are currently held, a TO address identifying an account to which the one or more digital assets are to be transferred, a description of the one or more digital assets, etc. Additionally, or alternatively, the wallet application may use a private key associated with the FROM address to generate a cryptographic signature over the transaction data structure.

In some embodiments, instead of submitting the signed transaction directly to the distributed ledger 120 for processing, the wallet application may send the signed transaction to the transaction management system 1 10. In response, the transaction management system 100 may store the signed transaction in a managed transaction record in a temporary storage 1 15.

FIG. 2 shows an illustrative managed transaction record 200, in accordance with some embodiments. The managed transaction record 200 may include any suitable information, such as a transaction identifier (TxID), the signed transaction (SignedTx) received from the wallet application, a deadline by which the signed transaction is to be submitted to the distributed ledger 120, a state of the signed transaction within the transaction management system 1 10, etc.

The deadline by which the signed transaction is to be submitted may be determined in any suitable manner. As an example, the wallet application may be configured to prompt a user to set the deadline. As another example, the deadline may be set as the expiry of a waiting period, which may start when the signed transaction is received by the transaction management system 1 10, and may have a default length, such as 1 hour, 2 hours, 12 hours, 24 hours, 2 days, 1 week, 2 weeks, 1 month, etc. In some embodiments, a transaction managed by the transaction management system 1 10 may be in one of several states. FIG. 3 shows illustrative managed transaction states 300, in accordance with some embodiments.

In this example, the transaction management system 1 10 assigns a Pending state to an incoming transaction. In some embodiments, prior to assigning the Pending state, the transaction management system 1 10 may use a public key associated with the FROM address indicated in the transaction to verify an alleged signature over the transaction. Additionally, or alternatively, the transaction management system 1 10 may prompt a user to authorize the transaction management system 110 to submit the transaction to the distributed ledger 120 at an optimal timing determined by the transaction management system 1 10. If the signature is successfully verified, and/or the user authorizes the transaction management system 1 10, the Pending state may be assigned to the transaction. Otherwise, a Dismissed state may be assigned (not shown).

It should be appreciated that aspects of the present disclosure are not limited to the transaction management system 1 10 verifying the alleged signature over the transaction. In some embodiments, the transaction management system 1 10 may assign the Pending state to every incoming transaction, without attempting to verify a corresponding signature.

In some embodiments, while the transaction is in the Pending state, a user who submitted the transaction may instruct the transaction management system 110 (e.g., via a wallet application) to discard the transaction. In response, the transaction management system 1 10 may assign a Discarded state to the transaction.

Additionally, or alternatively, while the transaction is in the Pending state, the transaction management system 1 10 may query the optimization engine 100 to determine an optimal timing for submitting the transaction to the distributed ledger 120. For instance, the query may be of the form, should this transaction be submitted now? A response received from the optimization engine 100 may be positive (e.g., indicating the transaction should be submitted now) or negative (e.g., indicating the transaction management system 1 10 should continue to hold the transaction in the temporary storage 1 15).

In some embodiments, the query may include the deadline by which the transaction is to be submitted. The optimization engine 100 may determine an optimal timing based on the deadline, one or more patterns observed from historical transaction data, and/or recent transaction data. The historical and/or recent transaction data may be accessed from a transaction data store 105, which may be kept up to date by monitoring transaction activities on the distributed ledger 120.

If the optimization engine 100 answers the query in the negative, the transaction may stay in the Pending state, and the transaction management system 1 10 may send another query at a later point in time. For instance, as long as the transaction remains in the Pending state, queries may be repeated at a suitable frequency, for example, whenever a selected number of new blocks have been added to the distributed ledger 120 (e.g., 1 new block, 5 new blocks, 10 new blocks, etc.).

If the optimization engine 100 answers the query in the affirmative, or if the deadline has been reached, the transaction management system 1 10 may submit the signed transaction to the distributed ledger 120, which may place the signed transaction in a transaction pool 125. Additionally, or alternatively, the transaction management system 1 10 may update a corresponding managed transaction record (e.g., the managed transaction record 200 in the example of FIG. 2) to indicate the transaction is in a Submitted state.

If the transaction is successfully processed, the distributed ledger 120 may send a positive confirmation to the transaction management system 1 10. In response, the transaction management system 1 10 may update the corresponding managed transaction record (e.g., the managed transaction record 200) to indicate the transaction is in a Processed state.

If the transaction is not successfully processed, the distributed ledger 120 may send a negative confirmation to the transaction management system 110. In response, the transaction management system 1 10 may update the corresponding managed transaction record (e.g., the managed transaction record 200) to indicate the transaction is in a Failed state.

The inventors have recognized and appreciated that, on rare occasions, a processed transaction may be reverted subsequently. This may happen, for example, when there is a tie between two miners, and a suitable tie breaker mechanism is used to accept the block proposed by one of the miners and reject the block proposed by the other miner.

Accordingly, in some embodiments, the transaction management system 1 10 may wait a selected amount of time after receiving the positive confirmation for the transaction. If the transaction is not reverted, then a Finalized state may be assigned. Otherwise, a Reverted state may be assigned.

The wait time may be selected to provide a sufficient level of confidence that, if there has been a tie, the tie would have been discovered. For instance, with respect to Ethereum Mainnet, the transaction management system 1 10 may wait until three new blocks have been added after the block containing the transaction in question.

While certain implementation details are described above in connection with FIGs. 1 -3, it should be appreciated that such details are provided solely for purposes of illustration. For example, aspects of the present disclosure are not limited to implementing the optimization engine 100 and the transaction management system 1 10 as separate systems. In some embodiments, some or all of the illustrative functionalities of the optimization engine 100 and the transaction management system 1 10 may be performed by a single system.

Moreover, it should be appreciated that aspects of the present disclosure are not limited to implementing both the optimization engine 100 and the transaction management system 1 10. In some embodiments, an application programming interface (API) may be provided for the optimization engine 100, so that the wallet application may query the optimization engine 100 directly, and may submit a transaction to the distributed ledger 120 directly when an affirmative response is received from the optimization engine 100.

The inventors have recognized and appreciated that transaction demand may fluctuate due to different types of events, which may exhibit different patterns. As an example, transactions triggered by software programs (e.g., bots) may exhibit patterns that repeat regularly (e.g., every hour, half hour, quarter hour, 10 min, 5 min, 1 min, etc.). As another example, transactions triggered by humans may spike at the beginning of a business day, and may taper off at the end of the business day and into the evening. In some instances, one or more intraday patterns may also be observable. These human-related patterns may occur for each time zone associated with a population center, such as Europe, US east coast, US west coast, east Asia, etc.

Accordingly, in some embodiments, a model for transaction demand may be provided that includes one or more oscillating terms. Each oscillating term may have one or more parameters relating to the term’s amplitude, frequency, and/or phase. Such parameter(s) may be estimated by fitting the model to historical transaction data.

By contrast, certain events (e.g., popular NFT drops) may happen sporadically, with no discernible pattern. Fluctuations due to such events may be considered noise.

In some distributed ledger systems, transaction fees may be set based on transaction demand. For instance, in Ethereum Mainnet, transactions are packaged into blocks to be processed, and a base fee is adjusted based on block space usage according to Ethereum Improvement Proposal (EIP) 1559. ² Thus, when transaction demand is high, many consecutive blocks may be relatively full, and the base fee may rise quickly (e.g., exponentially) from block to block. By contrast, when transaction demand is low, many consecutive blocks may be relatively empty, and the base fee may fall quickly (e.g., exponentially) from block to block.

² In Ethereum parlance, “gas” represents computation performed by an Ethereum virtual machine (e.g., to process transactions). Each transaction consumes a certain amount of gas depending on a type of the transaction. Each block may have an associated limit on total gas consumption across all transactions in the block.

Under EIP 1559, a total fee paid for each unit of gas includes a base fee and a priority fee. The base fee is set according to EIP 1559 based on block space usage, whereas the priority fee is set by an entity initiating a transaction to incentivize a miner to include the transaction in a proposed next block. Thus, the inventors have recognized and appreciated that EIP 1559 base fee may be monitored as a proxy for transaction demand. FIG. 4 shows an illustrative plot 400 of transaction fee fluctuations, in accordance with some embodiments. In this example, the plot 400 is generated by performing a Fourier analysis on a time series of Ethereum Mainnet base fee. Peaks may be seen at certain frequencies, such as weekly, daily, hourly, half hourly, quarter hourly, etc.

The inventors have recognized and appreciated that, because EIP 1559 base fee data is readily available, it may be advantageous to measure transaction demand based on EIP 1559 base fee. However, aspects of the present disclosure are not so limited. In various embodiments, transaction demand may be measured in other ways, for example, based on block space usage, block gas usage, transaction pool size, etc.

FIG. 5A shows an illustrative process 500 for predicting transaction demand, in accordance with some embodiments. For instance, the process 500 may be performed by the illustrative transaction timing optimization engine 100 in the example of FIG. 1.

At act 505, the optimization engine 100 may generate an initial prediction for transaction demand. This may be done in any suitable manner. For instance, the optimization engine 100 may fit one or more models to historical time series data for transaction demand (e.g., as measured by EIP 1559 base fee).

Any suitable amount of historical data may be collected and analyzed. For example, if daily patterns are of interest, then several days’ worth of historical data may be used, and likewise for other frequencies (e.g., monthly, weekly, hourly, half hourly, quarter hourly, etc.)

Any suitable model may be used, such as a parametric function with a baseline component, a trend component, and/or one or more oscillating components. An illustrative example is provided below.

In this example, T_o is a parameter for a baseline component, 1 is a parameter for a slope of a trend component, A_± and A₂ are parameters for amplitudes of respective oscillating components, < >! and 2 are parameters for phases of the respective oscillating components, and f is a parameter for frequencies of the respective oscillating components.

The inventors have recognized and appreciated that it may be beneficial to combine an oscillating component with one or more of its harmonics. For instance, in the above example, the component A₂ sin(47r/t + ₂) is a second harmonic of the component A_± sin(2nft + cp^). However, it should be appreciated that aspects of the present disclosure are not limited to using any particular harmonic, or any harmonic at all. In some embodiments, one or more suitable optimization techniques (e.g., exact, approximate, and/or heuristic techniques) may be used to fit the function y(t) to the historical data. For instance, a suitable technique (e.g., Levenberg-Marquardt, Gauss-Newton, gradient descent, etc.) may be used to identify a combination of parameter values that minimize a sum of squared residuals between y(t) and the historical data. The function y(t) with estimated values for T₀,T₁,A₁,A₂,(/)₁, (l)₂,f may then be used to predict future transaction demand for any given prediction horizon (e.g., next 24 hours, 12 hours, 6 hours, 1 hour, 30 min, etc.).

In some embodiments, several days’ worth of historical data (e.g., past 96 hours) may be used for model fitting. The historical data may be pre-processed (e.g., filtered, downsampled, etc.) prior to model fitting. For instance, fluctuations with very high frequencies (e.g., periods shorter than 15 min) may be considered noise, and a low-pass filter may be applied to remove such fluctuations.

Additionally, or alternatively, a percentile filter may be applied to remove extreme spikes caused by sporadic events such as a popular NFT drop. For instance, a higher percentile filter (e.g., 85^th to 95^th percentile) may be used with a relatively large rolling window (e.g., 72 to 120 hours). As an example, a 90^th-percentile filter with a rolling 96-hour window may be applied, so that any data point higher than a 90^th-percentile value 96 hours into the past may be replaced by that 90^th-percentile value.

Additionally, or alternatively, a percentile filter may be applied to reduce short term volatility. For instance, a 25^th-percentile filter with a relatively small rolling window may be applied, so that any data point higher than a 25^th-percentile value of a corresponding past window may be replaced by that 25^th-percentile value.

The rolling window for the 25^th-percentile filter may have any suitable size. For example, with respect to Ethereum Mainnet, a rolling window of 100 blocks may be used. However, it should be appreciated that aspects of the present disclosure are not limited to sizing a rolling window based on a number of blocks processed. In some embodiments, a rolling window of, for example, 20 min may be used.

The inventors have recognized and appreciated that, while a lower percentile filter (e.g., 20^th to 30^th percentile) may result in a higher percentage of data points being modified (e.g., 80% to 70%), such a filter, in combination with a relatively small rolling window (e.g., 50 to 150 blocks, or 15 to 25 min), may effectively dampen short term fluctuations without distorting long term trends. However, it should be appreciated that aspects of the present disclosure are not limited to using any particular combination of percentile threshold and rolling window size, or any percentile filter at all. In some embodiments, historical data points used for model fitting may be weighted, and a weighted sum of squared residuals between y(t) and the historical data points may be minimized. The weights may be adjusted based on short-term volatility. For instance, data points within a period of relatively high volatility may receive lower weights compared to data points within a period of relatively low volatility. Volatility may be measured in any suitable manner, and any suitable threshold(s) may be used to determine high and/or low volatility.

In some embodiments, a fitted model (e.g., the function y(t) with estimated values for

may be post-processed in a suitable manner. For instance, it may be observed over a long period of time (e.g., weeks, months, or years) that transaction demand rarely falls below a selected floor value d₀. Accordingly, a clipped function, y'(t) = max(y(t), do), may instead be used to predict future transaction demand.

FIG. 6 shows an illustrative plot 600 of historical and predicted transaction demand, in accordance with some embodiments. In this example, a 25th-percentile filter with a 100-block rolling window is used to pre-process 4 days’ worth of historical transaction demand data from Ethereum Mainnet (measured by EIP 1559 base fee), and a fitted model is used to predict transaction demand over the next 24 hours. The predicted transaction demand is clipped at 5 Gwei.

The original data is shown as a curve 605, whereas the pre-processed data is shown as a curve 610. The fitted model is shown as a curve 615 (dashed), whereas the predicted transaction demand is shown as a curve 620 (solid).

In some embodiments, a fitted model may be updated based on newly available data. For instance, a suitable data service may be used to update the illustrative transaction data store 105 in the example of FIG. 1 . The data service may poll the illustrative distributed ledger 120 at any suitable frequency, such as every 5 min, 3 min, 2 min, 1 min, 30 sec, 15 sec, 10 sec, etc., or whenever a selected number of new blocks have been added to the distributed ledger 120 (e.g., 1 new block, 5 new blocks, 10 new blocks, etc.).

Any suitable data may be polled from the distributed ledger 120. For example, with reference to Ethereum Mainnet, one or more data elements may be obtained for each newly recorded block, such as EIP 1559 base fee, gas used, gas limit, transaction count, etc.

As discussed above, EIP 1559 base fee may be used as a proxy for transaction demand. The inventors have recognized and appreciated that a difference between gas limit and gas used may indicate unused space in a block, which may in turn also indicate transaction demand. Moreover, an average gas usage may be determined as gas used divided by transaction count. This may indicate average complexity of a block (e.g., whether the block includes just a few complex transactions or many simple transactions).

At act 510, the optimization engine 100 may access, from the transaction data store 105, recent transaction demand data (e.g., data added since the last access by the optimization engine 100). At act 515, the optimization engine 100 may determine an updated prediction for transaction demand, for example, by updating parameters values for the function y(t). This may be done in a similar manner as described above in connection with act 505, albeit with updated transaction demand data (e.g., a rolling window of a selected size, such as 4 days).

In some embodiments, acts 510 and 515 may be repeated at a suitable frequency, which may be the same as, or lower than, the frequency at which the transaction data store 105 is updated. For instance, acts 510 and 515 may be repeated every hour, 15 min, 10 min, 5 min, 1 min, 30 sec, etc.

Additionally, or alternatively, acts 510 and 515 may be repeated in response to a trigger event, such as receipt of a prediction query from the illustrative transaction management system 110 in the example of FIG. 1 .

FIG. 5B shows an illustrative process 550 for determining an optimal timing for submitting a transaction, in accordance with some embodiments. For instance, the process 550 may be performed by the optimization engine 100 in response to a prediction query from the transaction management system 1 10.

At act 555, the optimization engine 100 may receive a prediction query relating to a transaction that is ready to be submitted to the distributed ledger 120. As described above in connection with the example of FIG. 1 , the query may be of the form, should this transaction be submitted now? However, it should be appreciated that aspects of the present disclosure are not limited to prediction queries of any particular form. For instance, in some embodiments, the transaction management system 1 10 may send a query of the form, what is a good time to submit this transaction in the next hour (or 2 hours, 6 hours, 12 hours, 24 hours, week, etc.)?

The query from the transaction management system 1 10 may include any suitable information, such as a deadline by which a transaction is to be submitted. Additionally, or alternatively, the query may include information about the transaction, such as transaction type, transaction value, transaction payload, gas limit, maximum fee (per unit of gas), priority fee (per unit of gas), etc.

In some embodiments, the optimization engine 100 may check one or more limits indicated in the query against one or more current conditions of the distributed ledger 120. As an example, the query may indicate a maximum base fee under EIP 1559, and the optimization engine 100 may check the maximum base fee against a current base fee in Ethereum Mainnet.

The inventors have recognized and appreciated that, if the transaction is submitted to the distributed ledger when a current base fee is above the maximum base fee of the transaction, then no miner may choose to process the transaction. Accordingly, if the current base fee is above the maximum base fee, the optimization engine 100 may provide a negative response to the transaction management system 1 10. This may prevent the transaction from being stuck in the transaction pool 125, thereby reducing waste of computation and/or other resources.

Additionally, or alternatively, the optimization engine 100 may perform a simulation for a transaction received in a query, for example, to determine whether the transaction may fail when submitted to the distributed ledger 120, or what state change may occur on the distributed ledger 120 if the transaction is successfully processed. For instance, the optimization engine 100 may identify a smart contract called by the transaction, and may run code of the smart contract based on the transaction and/or one or more current conditions of the distributed ledger 120. If this simulation results in a failure, the optimization engine 100 may provide a negative response to the transaction management system 1 10. This may prevent the transaction from being processed and reverted by the distributed ledger 120, thereby reducing waste of computation and/or other resources.

At act 560, the optimization engine 100 may determine a predicted minimum transaction demand value within the submission deadline. This may be done in any suitable manner. For instance, the optimization engine 100 may obtain a current transaction demand prediction for a suitable prediction horizon (e.g., as described above in connection with act 515 in the example of FIG. 5A). The prediction horizon may extend beyond the submission deadline. Thus, a predicted minimum transaction demand value may be identified between a current time and the submission deadline.

As discussed above, transaction demand may be measured based on EIP 1559 base fee. Accordingly, in some embodiments, the predicted minimum transaction demand value may be a predicted minimum EIP 1559 base fee between the current time and the submission deadline.

In some embodiments, if an actual current transaction demand value is above the predicted minimum transaction demand value, the optimization engine 100 may inform the transaction management system 1 10 that it is not yet a good time to submit the transaction. Otherwise, the optimization engine may proceed to act 565 to check transaction demand fluctuations in the near past. The inventors have recognized and appreciated that, in some instances, a noise floor in the historical transaction demand data may be high, which may indicate there is considerable short term volatility. A noise floor envelope is shown as a dotted curve 405 in the example of FIG. 4.

Thus, it may be desirable to submit the transaction only when transaction demand is low relative to what has been observed in the near past. Accordingly, the optimization engine 100 may check, at act 565, whether a current transaction demand value is lower than a selected percentile (e.g., 25^th percentile) of all transaction demand values observed within a selected past window. If so, the optimization engine may inform the transaction management system 1 10 that it is a good time to submit the transaction.

The past window used at act 565 may be selected in any suitable manner. As an example, the past window may be based on time elapsed (e.g., past 30 min, 20 min, 15 min, 10 min, 5 min, etc.). As another example, the past window may be based on transactions processed (e.g., past 1000 blocks, 500 blocks, 200 blocks, 100 blocks, 50 blocks, etc. in Ethereum Mainnet).

The inventors have further recognized and appreciated that, in some instances, predicted minimum transaction demand values may not materialize. Accordingly, in some embodiments, act 560 may be omitted once the submission deadline is near (e.g., less than a threshold amount of time away). Additionally, or alternatively, a percentile used at act 565 may be increased with successive queries for the transaction as the submission deadline approaches, thereby increasing a likelihood of an affirmative query response.

Additionally, or alternatively, when the deadline is imminent, both act 560 and 565 may be omitted, and the query may be answered in the affirmative.

The inventors have recognized and appreciated that more complex transactions (e.g., those with higher gas limits) may use more block space. Therefore, submission of such transactions may contribute to transaction demand to a greater extent than submission of simpler transactions (e.g., those with lower gas limits). Accordingly, in some embodiments, a lower percentile (e.g., 15^th, 10^th, etc.) may be used at act 565 for complex transactions (e.g., those with gas limits higher than a selected threshold.

While certain implementation details are described above in connection with FIGs. 4-6, it should be appreciated that such details are provided solely for purposes of illustration. For example, aspects of the present disclosure are not limited to any particular distributed ledger system or protocol. Moreover, the optimization engine 100 may be configurable by a user to use different prediction models, optimization techniques, decision criteria, etc.

It should also be appreciated that aspects of the present disclosure are not limited to predicting transaction demand in any particular manner. In some embodiments, one or more machine learning techniques may be applied to build models based on historical transaction demand and/or other data, and to use such models to predict future transaction demand.

In some embodiments, a machine learning model may map one or more independent variables to one or more dependent variables. Any suitable independent variable or combination of independent variables may be used. As an example, an independent variable may be a feature derived from historical transaction demand data, such as a selected statistic of time series transaction demand data over a selected past window (e.g., past M minutes or blocks for some suitable M). The selected statistic may be minimum, maximum, mean, median, mode, variance, standard deviation, or any other suitable statistic.

Additionally, or alternatively, a feature derived from historical transaction demand data may be a frequency-domain feature, such as a vector of amplitudes at selected frequencies (e.g., monthly, weekly, hourly, half hourly, quarter hourly, etc.).

As discussed above, transaction demand data may include data relating to any suitable indicator of transaction demand, such as EIP 1559 base fee, block space usage, block gas usage, transaction pool size, etc. In some embodiments, a machine learning model may have independent variables corresponding, respectively, to multiple such indicators. For instance, a machine learning model may have, as independent variables, base fee minimum, base fee maximum, block gas usage mean, and block gas usage maximum.

As another example, an independent variable may be a feature relating to a transaction to be submitted to the illustrative distributed ledger 120 in the example of FIG. 1 . Examples of such a feature include, but are not limited to, submission deadline, transaction type, transaction amount, etc. Such information may be received in a prediction query, for instance, from the illustrative transaction management system 1 10.

As another example, an independent variable may be a feature relating to one or more activities on the distributed ledger 120 that may lead to a spike in transaction demand. Examples of such activities include, but are not limited to, protocol upgrades, votes, auctions, etc.

As another example, an independent variable may be a feature relating to events external to the distributed ledger 120, such as time of day, user sentiment, etc. Such data may be obtained in any suitable manner. As an example, user sentiment data may be obtained by applying one or more natural language processing (NLP) techniques to analyze social media posts over a selected time window.

In some embodiments, a value of an independent variable may itself be a vector. For instance, a value of an independent variable may be a vector of N computed values of a certain statistic, where each value is computed from transaction demand data over a respective M-minute window in the past N ■ M minutes, for some suitable N and M.

A machine learning model may have any suitable dependent variable or combination of dependent variables. As an example, a dependent variable may be predicted transaction demand over a suitable prediction horizon. Thus, a machine learning model may map an input vector to a time series of predicted transaction demand values. Such a machine learning model may be trained at act 505 (and re-trained at act 515) in the example of FIG. 5A, and/or used at act 560 in the example of FIG. 5B to predict transaction demand.

As another example, a dependent variable may be a selected statistic of time series transaction demand data over a selected future window (e.g., next M minutes or blocks for some suitable M). The selected statistic may be minimum, maximum, mean, median, mode, variance, standard deviation, or any other suitable statistic.

In some embodiments, a value of a dependent variable may itself be a vector. For instance, a value of a dependent variable may be a vector of N predicted values of a certain statistic, where each value is predicted for a respective M-minute window in the next N ■ M minutes, for some suitable N and M.

As another example, a dependent variable may be an optimal time for submitting a transaction to the distributed ledger 120. For instance, a machine learning model may map an input vector to a value x, indicating that the transaction should be submitted x minutes after a current time.

As another example, a dependent variable may be a target transaction demand for submitting a transaction to the distributed ledger 120. For instance, a machine learning model may map an input vector to a value y, indicating that the transaction should be submitted when a current transaction demand value is at or below y.

As another example, a dependent variable may be a binary variable indicating whether a transaction should be submitted to the distributed ledger 120 at a current time.

The inventors have recognized and appreciated that training and application of random forest models tend to be efficient, and performance tend to be acceptable even if data availability is limited (e.g., not enough data to have separate datasets for training vs. testing). Moreover, random forest models may be suitable for handling data in various formats. Therefore, it may be advantageous to use random forest models for predicting transaction demand.

However, it should be appreciated that aspects of the present disclosure are not limited to using any particular type of machine learning models. In some embodiments, neural network models, linear regression models, decision tree models, and/or /c-nearest neighbors models may be used in addition to, or instead of, random forest models.

FIG. 7 shows an illustrative plot 700 of historical and predicted transaction demand, in accordance with some embodiments. In this example, historical transaction demand data up to time T is used to train random forest models, which are in turn used to predict, respectively, maximum, mean, and minimum transaction demand after time T. These predictions are shown as curves 710, 715, and 720, respectively, whereas actual transaction demand is shown as a curve 705.

Illustrative configurations of various aspects of the present disclosure are provided below.

1 . A computer-implemented method for optimizing timing of distributed ledger transactions, the method comprising acts of: receiving a query for optimal timing for submitting a transaction to a distributed ledger, the query indicating a deadline by which the transaction is to be submitted to the distributed ledger; determining a predicted minimum transaction demand value between a current time and the deadline; determining whether a current transaction demand value is above the predicted minimum transaction demand value; and in response to determining that the current transaction demand value is above the predicted minimum transaction demand value, providing a negative response to the query.

2. The method of configuration 1 , further comprising acts of: in response to determining that the current transaction demand value is not above the predicted minimum transaction demand value: determining whether the current transaction demand value is above a selected percentile value over a selected past window; and in response to determining that the current transaction demand value is not above the selected percentile value over the selected past window, providing a positive response to the query.

3. The method of configuration 2, wherein: the selected percentile value comprises a P-th percentile value, P being between 20 and 30; and the selected past window comprises an M- block window, M being between 75 and 125.

4. The method of configuration 2, wherein: the percentile value is selected based on a complexity of the transaction.

5. The method of configuration 2, wherein: respective current transaction demand values determined at successive queries for the transaction are compared against increasing percentile values, thereby increasing a likelihood of a positive response.

6. The method of configuration 1 , wherein: transaction demand is measured based on EIP-1559 base fee. 7. The method of configuration 1 , wherein: transaction demand is measured based on at least one item of information selected from a group consisting of: block space usage, block gas usage, and transaction pool size.

8. The method of configuration 1 , wherein: the act of determining a predicted minimum transaction demand value comprises an act of: applying at least one model to predict transaction demand over a prediction horizon that includes the deadline; and the at least one model is obtained based on historical transaction demand data.

9 The method of configuration 8, wherein: the historical transaction demand data is obtained, at least in part, by applying at least one filter selected from a group consisting of: a low- pass filter and a percentile filter.

10. The method of configuration 8, wherein: data points in the historical transaction demand data are weighted based on volatility.

1 1 . The method of configuration 8, wherein: the at least one model comprises a parametric function that is fitted based on the historical transaction demand data.

12. The method of configuration 1 1 , wherein: the parametric function comprises at least one component selected from a group consisting of: a baseline component, a trend component, and an oscillating component.

13. The method of configuration 1 1 , wherein: the parametric function comprises first and second oscillating components; and the second oscillating component is a harmonic of the first oscillating component.

14. The method of configuration 8, wherein: the at least one model comprises a random forest model that is trained based on the historical transaction demand data.

15. The method of configuration 1 , further comprising acts of: identifying one or more limits associated with the transaction; comparing the one or more limits against one or more current conditions of the distributed ledger; and in response to determining that the one or more current conditions of the distributed ledger do not comply with the one or more limits, providing a negative response to the query.

16. The method of configuration 1 , further comprising acts of: performing a simulation based on the transaction and/or one or more current conditions of the distributed ledger; and in response to detecting a failure from the simulation, providing a negative response to the query.

17. A system comprising: at least one processor; and at least one computer-readable storage medium having stored thereon instructions which, when executed, program the at least one processor to perform the method according to any of configurations 1 -16. 18. At least one computer-readable storage medium having stored thereon instructions which, when executed, program at least one processor to perform the method according to any of configurations 1 -16.

In the example of FIG. 8, the computer 1000 includes a processing unit 1001 having one or more computer hardware processors and one or more articles of manufacture that comprise at least one non-transitory computer-readable medium (e.g., a memory 1002) that may include, for example, volatile and/or non-volatile memory. The memory 1002 may store one or more instructions to program the processing unit 1001 to perform any of the functions described herein. The computer 1000 may also include other types of non-transitory computer-readable media, such as a storage 1005 (e.g., one or more disk drives) in addition to the memory 1002. The storage 1005 may also store one or more application programs and/or resources used by application programs (e.g., software libraries), which may be loaded into the memory 1002. To perform any of the illustrative functionalities described herein, processing unit 1001 may execute one or more processor-executable instructions stored in the one or more non-transitory computer-readable media (e.g., the memory 1002, the storage 1005, etc.), which may serve as non-transitory computer-readable media storing processor-executable instructions for execution by the processing unit 1001.

The computer 1000 may have one or more input devices and/or output devices, such as devices 1006 and 1007 illustrated in FIG. 8. These devices may be used, for instance, to present a user interface. Examples of output devices that may be used to provide a user interface include printers, display screens, and other devices for visual output, speakers and other devices for audible output, braille displays and other devices for haptic output, etc. Examples of input devices that may be used for a user interface include keyboards, pointing devices (e.g., mice, touch pads, and digitizing tablets), microphones, etc. For instance, the input devices 1007 may include a microphone for capturing audio signals, and the output devices 1006 may include a display screen for visually rendering, and/or a speaker for audibly rendering, recognized text.

In the example of FIG. 8, the computer 1000 also includes one or more network interfaces (e.g., a network interface 1010) to enable communication via various networks (e.g., a network 1020). Examples of networks include local area networks (e.g., an enterprise network), wide area networks (e.g., the Internet), etc. Such networks may be based on any suitable technology operating according to any suitable protocol, and may include wireless networks and/or wired networks (e.g., fiber optic networks). Having thus described several aspects of at least one embodiment, it is to be appreciated that various alterations, modifications, and improvements will readily occur to those skilled in the art. Such alterations, modifications, and improvements are intended to be within the spirit and scope of the present disclosure. Accordingly, the foregoing descriptions and drawings are by way of example only.

The above-described embodiments of the present disclosure can be implemented in any of numerous ways. For example, the embodiments may be implemented using hardware, software, or a combination thereof. When implemented in software, the software code may be executed on any suitable processor or collection of processors, whether provided in a single computer or distributed among multiple computers.

Also, the various methods or processes outlined herein may be coded as software that is executable on one or more processors running any one of a variety of operating systems or platforms. Such software may be written using any of a number of suitable programming languages and/or programming tools, including scripting languages and/or scripting tools. In some instances, such software may be compiled as executable machine language code or intermediate code that is executed on a framework or virtual machine. Additionally, or alternatively, such software may be interpreted.

The techniques disclosed herein may be embodied as a non-transitory computer-readable medium (or multiple non-transitory computer-readable media) (e.g., a computer memory, one or more floppy discs, compact discs, optical discs, magnetic tapes, flash memories, circuit configurations in Field Programmable Gate Arrays or other semiconductor devices, or other non- transitory, tangible computer-readable media) encoded with one or more programs that, when executed on one or more processors, perform methods that implement the various embodiments of the present disclosure described above. The computer-readable medium or media may be portable, such that the program or programs stored thereon may be loaded onto one or more different computers or other processors to implement various aspects of the present disclosure as described above.

The terms “program” or “software” are used herein to refer to any type of computer code or set of computer-executable instructions that may be employed to program one or more processors to implement various aspects of the present disclosure as described above. Moreover, it should be appreciated that according to one aspect of this embodiment, one or more computer programs that, when executed, perform methods of the present disclosure need not reside on a single computer or processor, but may be distributed in a modular fashion amongst a number of different computers or processors to implement various aspects of the present disclosure. Computer-executable instructions may be in many forms, such as program modules, executed by one or more computers or other devices. Program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Functionalities of the program modules may be combined or distributed as desired in various embodiments.

Also, data structures may be stored in computer-readable media in any suitable form. For simplicity of illustration, data structures may be shown to have fields that are related through location in the data structure. Such relationships may likewise be achieved by assigning storage for the fields to locations in a computer-readable medium so that the locations convey how the fields are related. However, any suitable mechanism may be used to relate information in fields of a data structure, including through the use of pointers, tags, or other mechanisms that establish how the data elements are related.

Various features and aspects of the present disclosure may be used alone, in any combination of two or more, or in a variety of arrangements not specifically described in the foregoing, and are therefore not limited to the details and arrangement of components set forth in the foregoing description or illustrated in the drawings. For example, aspects described in one embodiment may be combined in any manner with aspects described in other embodiments.

Also, the techniques disclosed herein may be embodied as methods, of which examples have been provided. The acts performed as part of a method may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different from illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.

Use of ordinal terms such as “first,” “second,” “third,” etc. in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed, but are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term) to distinguish the claim elements.

Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” “having,” “containing,” “involving,” “based on,” “according to,” “encoding,” and variations thereof herein, is meant to encompass the items listed thereafter and equivalents thereof as well as additional items.

What is claimed is:

Claims

2. The method of claim 1 , further comprising acts of: in response to determining that the current transaction demand value is not above the predicted minimum transaction demand value: determining whether the current transaction demand value is above a selected percentile value over a selected past window; and in response to determining that the current transaction demand value is not above the selected percentile value over the selected past window, providing a positive response to the query.

3. The method of claim 2, wherein: the selected percentile value comprises a P-th percentile value, P being between 20 and 30; and the selected past window comprises an M-block window, M being between 75 and 125.

4. The method of claim 2, wherein: the percentile value is selected based on a complexity of the transaction.

5. The method of claim 2, wherein: respective current transaction demand values determined at successive queries for the transaction are compared against increasing percentile values, thereby increasing a likelihood of a positive response.

6. The method of claim 1 , wherein: transaction demand is measured based on EIP-1559 base fee.

7. The method of claim 1 , wherein: transaction demand is measured based on at least one item of information selected from a group consisting of: block space usage, block gas usage, and transaction pool size.

8. The method of claim 1 , wherein: the act of determining a predicted minimum transaction demand value comprises an act of: applying at least one model to predict transaction demand over a prediction horizon that includes the deadline; and the at least one model is obtained based on historical transaction demand data.

9 The method of claim 8, wherein: the historical transaction demand data is obtained, at least in part, by applying at least one filter selected from a group consisting of: a low-pass filter and a percentile filter.

10. The method of claim 8, wherein: data points in the historical transaction demand data are weighted based on volatility.

1 1. The method of claim 8, wherein: the at least one model comprises a parametric function that is fitted based on the historical transaction demand data.

12. The method of claim 1 1 , wherein: the parametric function comprises at least one component selected from a group consisting of: a baseline component, a trend component, and an oscillating component.

13. The method of claim 1 1 , wherein: the parametric function comprises first and second oscillating components; and the second oscillating component is a harmonic of the first oscillating component.

14. The method of claim 8, wherein: the at least one model comprises a random forest model that is trained based on the historical transaction demand data.

15. The method of claim 1 , further comprising acts of: identifying one or more limits associated with the transaction; comparing the one or more limits against one or more current conditions of the distributed ledger; and in response to determining that the one or more current conditions of the distributed ledger do not comply with the one or more limits, providing a negative response to the query.

16. The method of claim 1 , further comprising acts of: performing a simulation based on the transaction and/or one or more current conditions of the distributed ledger; and in response to detecting a failure from the simulation, providing a negative response to the query.

17. A system comprising: at least one processor; and at least one computer-readable storage medium having stored thereon instructions which, when executed, program the at least one processor to perform the method according to any of claims 1 -16.

18. At least one computer-readable storage medium having stored thereon instructions which, when executed, program at least one processor to perform the method according to any of claims 1 -16.