Data-Driven Suggestions for Reserve Voting

[mDuo13]

There has been some discussion lately about if and how much XRP Ledger reserves should be lowered now that the price of XRP is much higher than it used to be. (In recent weeks, it's dropped a bit down to about $0.83 USD from recent peak of over $1.50 after spending most of the last 3 years closer to about $0.30.) But none of the discussions so far have actually looked at how the reserve cost serves its main function of preventing data spam from increasing the size of the ledger too much.

I used nixerFFM's new ledger data API to determine how much space most objects actually occupy to see how much in-ledger storage their reserve requirement gets you. Here's what I found:

OBJECT TYPE         AVG SIZE      RESERVE      BYTES/XRP
                    (bytes)       (XRP)
================================================================================
accountroot         178            20*          8.9
ripplestate         422             5          84.4
signerlist          301             5**        60.2   **some have a legacy higher reserve
offer               392             5*         78.4
escrow              252             5          50.4
paychannel          327             5          65.4
check               288             5          57.6
depositpreauth      198             5          39.6
directorynode       353             * (factored into ++ rates; details below)
ledgerhashes      16413
feesettings          70
amendments         2392
--------------------------------------------------------------------------------
accountroot++       239            20          12.0
offer++             406             5          81.2

Reminder: see Ledger Data Formats for explanations of all these types.

LedgerHashes, FeeSettings, and Amendments objects are part of the blockchain infrastructure and not owned or influenced by any one user, so they are just overhead. (Together, they're just over 1.4% of a ledger's total data.)

Directories (DirectoryNode objects) are the only other type of object that doesn't have an associated reserve requirement. However, the presence of these objects is directly related to usage, so their storage cost are implicitly covered by other reserve requirements. At about 17% of the ledger's total data, these are the third most significant category after accounts and trust lines, so we should make an attempt to measure how much of the implied reserve requirements apply to these objects.

Directories are comprised of two types: owner directories, which track objects owned by an account; and offer directories, which track offers for a given currency pair and exchange rate. 96% of directories are owner directories, and 4% are offer dirs. For simplicity, I assume average owner and offer directories occupy similar amounts of space. (Offer directories have a few hundred bits more fixed space each, but each directory contains a vector of 256-bit hashes which varies in length from 1 to 32 entries. For both types, a few large directories for active issuers and markets probably occupy a disproportionate amount of overall data.)

There are about 3 million accounts and a little over half a million owner directories. Dividing owner dirs by accounts, the average account owns (or causes the creation of) about 0.17 owner directories.

By contrast, there are about 31k offers and 22.8k offer directories, so the average offer is associated with about 0.73 offer directories.

Therefore, I designate two adjusted object types, with the average size plus a weighted average size of the directories they create.

accountroot++: size of an average accountroot + 17% of an average directory size
offer++: size of an average offer + 73% of an average directory size

In the table above, we can see that even in their adjusted state, accounts are by far the most expensive bytes to reserve in the XRP Ledger. In fact, even if we decreased the base account reserve to 5 XRP while leaving the incremental owner reserve at 5 XRP, the account reserve would, on average, buy you less space in the ledger than most data types.

Now, it is true that accounts may have other "hidden costs" besides the amount of space they and their directories take up in the ledger. They can send transactions, they may need to be cached or parsed through more often, and they certainly can be bigger than the average size of one. And the way that account deletion works is that the incremental reserve (that is, the price of a non-account object) has to be destroyed to delete an account, so unless we also change that, we can't set the account reserve below the incremental reserve, and if it's equal that's technically fine but it means there's much less incentive to delete accounts in general. (And since accounts are currently ~47% of all data in the ledger, we probably would like it if people deleted their unused accounts.)

Another way of thinking about it is the cost of storing all this data in memory. The current ledger is very roughly 1 GB of data, which is enough to fit over 4000 accounts. Taking a quick glance at Newegg, server RAM costs are about $6 per GB which means that enough RAM to store the entire ledger costs less than 8 XRP at today's prices. Obviously the prices of RAM aren't linear, but I think this does serve to confirm that the current account reserve requirements are too high in terms of real value.

However, I believe this data also shows that a 2 XRP owner reserve (as in the proposed "10 / 2" reserve schedule) is also probably not right. If anything, "10 / 5" is probably a much more appropriate cost, given this data. But I'm curious to see what else people have to go on, or if I missed anything. Among other things, I don't have any data on the rate of account creation and if/how that correlates to the price of XRP when the reserve is steady; I don't know how many of the ledger's many accounts were originally created when the reserve requirement was much lower in dollar value.

[WietseWind]

I completely agree that an automated adjustment process would be an interesting approach. Possibly an automated factor on top of voted amounts?

The memory (ram) storage costs however are just a tiny factor of the costs to operate the XRPL infra: bandwidth, storage (especially FH) etc. are much bigger factors than the memory to store a single ledger. Also, the fees being in place as an anti spam mechanism opposed to compensating for infra cost (fees are burned anyway, so don't cover anything) I feel that infra (RAM, CPU, bandwidth, etc.) costs shouldn't really be something to consider when determining the fee/reserve height.

[mDuo13]

While it's true that memory is just one cost, and a smaller one at that, the other costs you mentioned are all "downstream" of the same thing: the raw amount of data being stored. The difference is that full history and bandwidth are also affected by transaction volume—which is regulated by the transaction cost.

And while I agree it's too simplistic to pick reserve costs linearly based on the cost of hardware, it's committing too far the other direction to say that infra costs shouldn't weigh into fees & reserves at all. The reason the reserves exist is to help ensure that commodity hardware can sync and meaningfully participate in the blockchain, making it accessible to a diverse range of contributors. The definition and price of "commodity" hardware is a little slippery, but the price of the hardware certainly a big part of the definition, so it should also be a factor in how we set the reserves.

If the costs of running XRPL infrastructure were so low that any random machine could support an unlimited amount of data, there would be no need for a reserve. And if machines that are widely available now are capable of storing much more data at no additional cost than is being stored now, then the reserves are doing more harm than good by preventing low-value usage.

Anyway, I'm not suggesting at this point that we implement any kind of automatic adjustment for the reserve requirements. (Having that process be slower and involve actual deliberation is probably best for everyone since changing it can be disruptive.) This discussion is largely meant to be adding some actual facts and numbers other than "the price has gone up" into the discussion of what the right reserve amounts should be right now.

tl;dr I think people should stop voting for 10/2 and start voting for 10/5, because accounts are actually cheaper for the ledger to store than offers and trust lines.