Batched Transactions

[evgenykuzyakov]

Ready for review. I'll start implementing it in a meantime.

[evgenykuzyakov]

Implementation branch in progress: https://github.com/nearprotocol/nearcore/tree/batched-tx-1

[DanielRX]

Something I noticed with this, does this not violate some basic logical cases?

If I can run tx1, tx2, tx3 and tx4 as a batch, it should be possible to run them all on their own, in sequence (assuming no txs interrupt them)? This will not hold for batched transactions, since if tx1 is a deleteKey op, tx2 could then fail?

If I add a key in tx1 and perform tx2 which needs the key to work, would this be valid? If so, the addKey must be changing the state, but the deleteKey is not.

[k06a]

Wish wallet to use this kind of transaction after bunch of transactions were "staked/collected" instead of "signed and sent". So wallet should allow grouping even for dapps that not initially support it.

[evgenykuzyakov]

@DanielRX

So we actually batching actions instead of transactions. The batched actions form a transaction which is signed. Once the transaction is authorized (e.g. with a full access key), all actions are executed and they don't require public key to be present. So the first action can be delete the access key and the 2nd action is something else, e.g. a function call.

This is done to support operations like deploy+migrate_call, or deploy+init.

@k06a
All Batched Actions are from one signer to one receiver. It's not always makes sense to batch actions, e.g. 2 function calls might need to go in a parallel or fail independently

[k06a]

@evgenykuzyakov but we need at least cover approve+transferFrom ERC20 flow. Approve should be called on token smart contract and second tx should be to receiver, which will internally make transferFrom call.

[evgenykuzyakov]

@k06a As we discussed in other channel, it should be done with something like approveThen, which approves and locks the token for contract_x, then calls given method on contract_x with a callback on itself to unlock a token if the contract_x doesn't act.

[k06a]

@evgenykuzyakov, hope both calls will be performed from account, not from token smart contract. Else this would behave like ERC827.

[evgenykuzyakov]

Ready to be merged

[k06a]

@evgenykuzyakov can you point to the locks implementation example?

[evgenykuzyakov]

@k06a I think locks are for the different NEP.