Introduce Transaction Queue Support

[maschad]

We'd like to support the queueing of multiple transactions which can be executed sequentially. This feature is particularly useful in scenarios where a series of dependent transactions need to be processed in a specific order. It simplifies the workflow for developers who otherwise would have to manually handle the sequencing and execution of transactions.

There are few issues which could arise during this process though which need to be considered. Here are some example scenarios:

• if a user submits transactions A,B & C, and transaction B depends on A, but C is independent, if A fails do we abort the queue or retry, and do we proceed with C?
• we need to have the capability to allow for a slippage range in gas fees, if gas cost increases between transactions.
• what would be the limit on the queue? How many transactions can we reasonably guarantee would be executed sequentially?
• how many confirmations should be required before considering a transaction complete and moving to the next one?
• will we allow consumers to pause and resume the queue?

This list is by no means exhaustive but I think we should consider this before beginning work

[Torres-ssf]

For this feature, we would need to implement a robust solution to manage the queue of transactions.

if a user submits transactions A,B & C, and transaction B depends on A, but C is independent, if A fails do we abort the queue or retry, and do we proceed with C?

The TransactionQueuer would need to include options to control this behavior. For example, if TX A deploys a contract,TX B executes a function of this contract, but TX C is a simple transfer, then if A fails, it should not attempt B, but C can be submitted regardless.

we need to have the capability to allow for a slippage range in gas fees, if gas cost increases between transactions.

Since it is a queue of transactions, each transaction will ideally be funded just before being submitted. The SDK can already estimate safe defaults for gasLimit and maxFee, but it could also allow custom configuration inputs from the user.

It is also important to estimate and fund a transaction only when it is its turn in the queue. This approach prevents the use of the same UTXOs to fund multiple transactions, making the queue usable for accounts that own only one UTXO. For example, TX B will use the UTXO generated by the change from TX A, and so on.

What would be the limit on the queue? How many transactions can we reasonably guarantee would be executed sequentially?

I am unsure of the exact value to use here, but we could start with a small number to experiment.

how many confirmations should be required before considering a transaction complete and moving to the next one?

For this feature, I would suggest proceeding to the next transaction as soon as the current transaction is processed and its status is successful.

will we allow consumers to pause and resume the queue?

This level of fine control can be very complex to handle. We should start simple.

However, this is just brainstorming. This feature needs to wait until we improve some parts of the SDK, specifically the creation and submission of transactions.

[mvares]

Could the TransactionQueuer be implemented as a queue?

This data structure might help us handle transactions queued more efficiently.

[nedsalk]

For example, if TX A deploys a contract,TX B executes a function of this contract, but TX C is a simple transfer, then if A fails, it should not attempt B, but C can be submitted regardless.

This type of transaction dependency should be left for the user to define. The user might not want to submit C if B fails or is not attempted due to its dependencies failing. Whatever way we use to identify transactions in the queue, we can allow the user to specify a dependsOn: [txB, txE] which won't send the transaction until those transactions have executed.

[mvares]

Currently, I'm researching some approaches into this. I've had the chance to speak with other blockchain engineers, and it seems that a Petri Net could be quite useful here.

As mentioned earlier, in queued transactions, there may be individual transactions that don't depend on the others. I think leveraging the features offered by Petri Net would be an efficient approach for handling such scenarios.

A Petri Net is beneficial for managing transaction states effectively, enabling clear visualization and handling of transaction statuses (e.g., pending, in progress, completed). It facilitates automated transitions between transactions as they progress through different states, enhancing efficiency in transaction processing workflows.

Moreover, If tx C doesn't depend on the others, we can run it in parallel while resolving the remaining transactions.

PS: We need to consider how to handle gas calculation.