XLS-56d: Atomic/Batch Transactions

[mvadari]

Discussion thread can be found here: #162

This PR will be left open for easier commenting of specific lines/sections. The discussion will also still be available for ease of commenting for non-technical people.

[mDuo13]

I am somewhat concerned about the greater potential for front-running with batch transactions. It seems like that is the "use case" that receives the biggest direct benefit from this feature even though we would rather discourage front-running.

Related, I think the specification should make it explicit how the batch affects the canonical order of transactions. It seems like the intent is for the canonical order to contain the outer transaction followed by the successful inner transactions in direct sequence, and that would start from wherever the outer transaction gets placed in the canonical order?

It might also be worth adding a subsection to Security about transaction fees. Specifically, make a note about how the outer transaction pays fees for all the inner transactions even if using modes like ONLYONE where some of those transactions can fail, and how this is a precaution against exploits that could make the whole network do the work of processing candidate transactions that won't pay transaction fees.

[mDuo13]

I suggest renaming this mode to FIRST (tfFirst) to reflect that the order of inner transactions matters.

[mvadari]

That might imply to some people that it's something to do with the first transaction in the batch, rather than the first success.

[mDuo13]

You could optionally rename this to ALL (tfAll) which I think conveys the same idea as well or better. (The "nothing" case wouldn't really be a success in my book!)

[mvadari]

I thought tfAll might be confused with tfIndependent.

[mDuo13]

Is this "pointer" meant to be part of the canonical (hashed) metadata, or added afterward? It seems like something that would be useful to have in the canonical metadata, but if so it should be in PascalCase.

[mvadari]

I was thinking added afterward, but I'm not sure if that's possible. cc @dangell7

[dangell7]

I'm not sure this is possible. How would the inner txn have any context of the outer batch unless this is computed ahead of time.

[mvadari]

Should it be added to the metadata then?

[dangell7]

The metadata on the inner txn? We could maybe point the PreviousTxnID back to the batch? or add something similar to that?

Just to clarify you want to link the inner txn back to the outer txn?

[mvadari]

Just to clarify you want to link the inner txn back to the outer txn?

Yes, I think that would be very useful.

[dangell7]

An Inner account delete should be blocked if the same account is submitting the batch.

[dangell7]

I'm currently signing the entire txn for BatchSigners as I do not understand the TxnIDs completely and have not implemented that. It will also require more custom logic in both the rippled and repos to sign an array of hashes and a flag field.

[dangell7]

RE BatchIndex

Before it was thought that the batch index was the index of the transaction for a specific account. Now or with the addition of tickets, it is more correctly the index of the transaction for an account/sequence/ticket. Previously we were adding +1 to the sequence calculation if the batch txn was the outer account, however if using a combination of sequence and tickets there is no way to know. So the index needs to be calculated prior to submission.

Some examples.

OuterTxn: Alice using ticket
InnerTxn: Alice using sequence (Index = 0)
InnerTxn: Alice using sequence (Index = 1)

OuterTxn: Alice using ticket
InnerTxn: Alice using ticket (Index = 1)
InnerTxn: Alice using sequence (Index = 0)

OuterTxn: Alice using sequence
InnerTxn: Alice using ticket (Index = 0)
InnerTxn: Alice using sequence (Index = 1)

[mvadari]

@shawnxie999 @dangell7 @mDuo13 pushed the latest changes

[shawnxie999]

I think BatchExecutions in the metadata is missing in the spec

[mvadari]

I think BatchExecutions in the metadata is missing in the spec

@shawnxie999 see this section: https://github.com/mvadari/XRPL-Standards/blob/batch/XLS-0056d-batch/README.md#261-outer-transactions

[shawnxie999]

doesn't it also have sfTransactionType?

[mvadari]

It currently has that in place of TransactionHash. I'd prefer TransactionHash, personally.

[ckeshava]

This aspect of Batch transactions appears to diverge from the current understanding of the XRPL blockchain. If a non-batch transaction fails with a tec... error, such a transaction is included in the ledger. Docs

However, suppose an Outer-Batch transaction comprises of 10 inner transactions and the tfAllOrNothing mode. If it fails on the 9th inner transaction, then none of the transactions are included on the ledger. Am I understanding this correctly?

[mvadari]

That's the purpose of Batch - to be something new that is different from what is currently offered. If you don't need that change in functionality, then don't use it.

[ckeshava]

If the Batch transactions tec... codes are not included in the ledger, it leads to a break in the provenance of blockchain transactions. A few drops of XRP is irrevocably lost as transaction fees and we can never trace the reasons for such decrease in an account's balance.

Is there any design reason for excluding tec... transactions? What are the disadvantages?

Additionally, would the account_tx also not display such err-ing Batch transactions? account_tx uses a different database for indexing and storing the transactions and I haven't looked at the implementation.

[mvadari]

A few drops of XRP is irrevocably lost as transaction fees

Inner Batch transactions don't have a fee. The only fee comes from the outer transaction, which will still be validated. So no break in the provenance.

Is there any design reason for excluding tec... transactions? What are the disadvantages?

If, as in your example, the 9th of 10 transactions with tfAllOrNothing fails, why is only the 9th transaction validated and not the previous 8? That's not consistent.

Additionally, would the account_tx also not display such err-ing Batch transactions? account_tx uses a different database for indexing and storing the transactions and I haven't looked at the implementation.

It will show the whole Batch transaction as one, the inner transactions will not be displayed differently.

[ckeshava]

Inner Batch transactions don't have a fee. The only fee comes from the outer transaction, which will still be validated. So no break in the provenance.

I missed this aspect of the spec, this clarifies my doubts 👍

Is there any design reason for excluding tec... transactions? What are the disadvantages?

If, as in your example, the 9th of 10 transactions with tfAllOrNothing fails, why is only the 9th transaction validated and not the previous 8? That's not consistent.

No, I would have preferred to specify the execution status of all the inner transactions (not just a particular failing transaction) in the ledger. This provides the best transparency for debugging purposes.

To explain my stand further, could we execute all the transactions of an tfAllOrNothing Batch transaction and specify the transaction-execution-result for each of them?

Additionally, would the account_tx also not display such err-ing Batch transactions? account_tx uses a different database for indexing and storing the transactions and I haven't looked at the implementation.

It will show the whole Batch transaction as one, the inner transactions will not be displayed differently.

No, you are speaking from the perspective of the account which submits the Outer-Batch transaction. If I query account_tx with one of the inner-Batch-transaction account's, what is the expected outcome?

I can wait for the implementation and try-it-out myself, this question is not urgent.

[mvadari]

No, I would have preferred to specify the execution status of all the inner transactions (not just a particular failing transaction) in the ledger. This provides the best transparency for debugging purposes.
To explain my stand further, could we execute all the transactions of an tfAllOrNothing Batch transaction and specify the transaction-execution-result for each of them?

See the section on BatchExecutions (in 2.6.1).

No, you are speaking from the perspective of the account which submits the Outer-Batch transaction. If I query account_tx with one of the inner-Batch-transaction account's, what is the expected outcome?

The inner transactions that are validated will all show up in account_tx. Not sure if the failed ones will show up - I don't know how the tracking of "is an account involved in this transaction" works.

I can wait for the implementation and try-it-out myself, this question is not urgent.

https://dev.to/dangell7/batch-xls-56-is-now-available-for-testing-and-development-18bk

[ckeshava]

What's the influence of Batch transactions on the open-ledger cost? For instance, if 10 Batch transactions are included in a validated ledger, this is equivalent to inserting at most 80 non-Batch "usual" transactions. Is the soft-limit of the open-ledger cost calculation proportionately increased by this amendment?