Report stellar transaction count, not operation count

[brson]

We are reporting stellar "operations", but operations are performed in a single atomic transaction. In this way stellar is like solana, but on solana we are reporting the transaction count, not the "instruction" count.

Stellar operations and transactions: https://developers.stellar.org/docs/fundamentals-and-concepts/stellar-data-structures/operations-and-transactions

I think we should be reporting the transaction count instead.

In general we should define transactions as the user-visible unit of atomic writes.

Here are my recent thoughts about what we should consider a "transaction": https://github.com/Aimeedeer/realtps/issues/48

cc @graydon @leighmcculloch thoughts?

[graydon]

Practically, I think we have three somewhat different sets of txs flowing through the system:

1. those that are 1 op in 1 tx, the difference is not relevant
2. those that bundle multiple ops into a tx for atomicity, to represent a single action
3. those that bundle multiple ops into a tx for simplicity, because there's a synchronous tx-submit endpoint and they are submitting an effectively unlimited stream of ops, would actually probably be submitting 1000 ops per tx if we let them, but we cap ops-per-tx at 100

I think it's reasonable to measure the transaction envelope count for cases 1 and 2, but case 3 is fairly prominent in the txsets I see. I just clicked one at random and found https://horizon.stellar.org/ledgers/43261506/operations?limit=100 which is someone doing an airdrop of claimable balances, clearly those 100 ops are not so much "one thing" as "a stream of zillions of separate things arbitrarily split into 100-op chunks".

(Put another way: it seems odd / unfortunate to me that if we raised the MAX_OPS_PER_TX number, currently set to 100 somewhat arbitrarily, our "TPS" number as reported here would appear to go down due to the prevalence of such case #3 transactions. Or put yet another way: if you started measuring "TPS" this way we'd have an incentive to lower MAX_OPS_PER_TX, which seems not great!)

[dmkozh]

Probably some simple heuristics could distinguish most of the batch transactions from the atomic sequence (that would be fair to count as 1 tx):

• If all the ops in tx are payments, then likely they're just batched together
• If there is more ops than some threshold (say, 10), then likely they were just batched together

[brson]

After thinking over this for a while, I am not inclined to judge how users use transactions. If they are grouping ops into a transaction I can only assume they have a reason.

Adding per-chain heuristics for one chain would lead to per-chain heuristics for more chains, and I don't see any way to manage that situation.

[brson]

Fixed in https://github.com/Aimeedeer/realtps/pull/86