Batch submission of transactions from single account

[ilblackdragon]

We are having more and more need for batching transactions to different accounts which continue running after first tx fully completed.

See details on the wallet side: near/near-wallet#1511

One of the issues is that tx can take multiple blocks to execute and if the next tx in the set already gets sent - tx may fail when it shouldn't.

Can we add requirement that next nonce can only be executed if transaction is fully done? Is there a better way to submit batch of transactions originating from single account but going to different destinations?

[bowenwang1996]

Do you want to batch them as one object or do you simply want them to be executed in a specific order?

[oysterpack]

the overall batch transaction flow should be composable using "then" and "and" combinators. For example, something like:

let txn1 = create_txn1(); // on contract-1
let txn2 = create_txn2(); // on contract-2
let txn3 = create_txn3(); // on contract-3
let txn4 = create_txn4(); // on contract-4

let flow1 = txn1.then(txn2);
let flow2 = txn3.then(txn4);
let batch_txn = flow1.and(flow2);

• the above batch transaction flow can be read as:
  • execute flow1 and flow2 in parallel
  • each of the subflows defines an ordered transaction chain workflow
• NOTE: the transactions span across multiple contracts

Today, in order to implement ordered transaction flows requires injecting callbacks between steps in the flow to drive the flow.

[bowenwang1996]

@ilblackdragon I read the description again and realize that it is more feasible than I originally thought since all transactions originate from the same account. This means they will all be processed first on the same shard before receipts are generated and sent to different shards. As a result, we can utilize the same mechanism as we do for callbacks: we put some receipts in PostponedReceipt and do not send them to the destination shards for further execution until their dependencies are fully executed. This can be done through DataReceipt or something similar. Of course this will be more expensive than sending those transactions individually, but probably usability is more important here.

On the implementation side, we could potentially change actions to be a collection of actions where each element is a list of actions and allow users to specify dependencies between different elements.

[MaksymZavershynskyi]

Requiring nonce to be processed only after the entire previous transaction is processed will break the bridge's catchup mechanism, because it is submits 10 transactions at a time optimistically expecting them to be executed in a correct order. This change would require creating multiple access keys with separate nonces for applications like bridge which degrades DevX. I would imagine there are other use cases besides the bridge that need it. CC @djsatok , @artob , @mfornet

[mfornet]

Actually for bridge we are using batched transaction given that all tx are calling the same function on a single contract. We do not expect anymore they are computed in the right order.

[alexauroradev]

The issue that we having though is that batched transactions are still treated as a single transaction on the protocol level, so they have a gas limit of a single transaction. This drastically decreases the bridge catchup speed. Would be good in the new batched transaction design to overcome this.