Suggestion: don't add transactions to AccountTransactions based on RegularKey=ACCOUNT_ONE or ACCOUNT_ZERO

[mDuo13]

Summary

The account_tx API method wastefully tracks and reports transactions as being "related to" the black hole set in a RegularKey field.

Background

ACCOUNT_ONE (rrrrrrrrrrrrrrrrrrrrBZbvji) and ACCOUNT_ZERO (rrrrrrrrrrrrrrrrrrrrrhoLvTp) are special addresses that encode the values 1 and 0 respectively. It is generally accepted that no one knows a private key that corresponds to these addresses and finding one would be effectively impossible, which makes them "black holes". Token issuers occasionally want to make their cold wallet a black hole as a public assurance that they won't issue further tokens; the process for doing this involves setting their RegularKey to ACCOUNT_ONE or ACCOUNT_ZERO and then disabling the master key.

The account_tx API method returns a list of transactions that "affected" a given account. This includes transactions sent and received as well as ones where it was an intermediary. For example, when tokens "ripple through" their issuer, this is recorded as affecting the issuer. To make this API performant, rippled uses the AccountTransactions table in the transactions.db SQLite database to track which transactions affected which accounts. One somewhat surprising case that counts for this purpose is when another account with a matching RegularKey is involved in a transaction—even if the key itself was not used, as long as an account with the key was modified.

Putting these two factors together, the account_tx results for ACCOUNT_ONE include quite a large number of transactions whose only connection to ACCOUNT_ONE is that they affected an issuer whose RegularKey is ACCOUNT_ONE. The same is true for ACCOUNT_ZERO.

Motivation

While surprising, this is not necessarily problematic. However, it is also not useful and tracking it is a waste of space. The number of such transactions is not currently that high, but each row in the table is at least 52 bytes (20 bytes for the AccountID and 32 bytes for the transaction ID) plus overhead, which can add up over time.

The number of transactions involving a blackholed issuer varies dramatically from ledger to ledger. If we estimate an average of 5 such transactions per ledger at one ledger every 4 seconds, that's maybe ~5 megabytes per day in wasted SQL table rows, plus whatever overhead is involved in indices, and so on.

Solution

The code that adds rows to the AccountTransactions SQL table should not do so when:

• the only connection is a regular key, and
• the regular key is ACCOUNT_ONE or ACCOUNT_ZERO

Paths Not Taken

Two other approaches that could be taken are:

• No action. This is fine, but a bit wasteful and surprising.
• Don't consider transactions as affecting an account purely based on RegularKey regardless of what key it is. This would be a slightly drastic API change. Some users might consider it an improvement to not have their related transactions "polluted" with transactions where an account happens to have their account as a regular key (regardless of whether that key was used). Some users might be sad for the loss of functionality. The vast majority of users probably wouldn't notice a difference.

Clio Compatibility

I don't know if Clio separately tracks related transactions for account_tx but based on comparing s2 (backed by Clio servers) to xrplcluster (backed by rippled) the behavior of both servers currently matches.