Technical debt on token issuers

[shortthefomo]

Summary

With the explosion of tokens on the XRPL, there is a lot of people rushing to create tokens to simply grab at the rise in interest. This is great, but now we are facing issues with scaling and debit on the infrastructure in place.

Motivation

The idea is to impose a level of technical debit on the token issuers. As fees associated with issuance seem to be of issue to some.

Solution

Require the running of a node/validator to issue a token.

1. It help provide infrastructure to the network that is currently abused by free loaders.
2. It help require some technical skill from the issuers. At the moment anyone can run to a faucet and issue a token.

Idea is to have a pointer from the validator to an account that only then allows an account to issue a token.

[cjcobb23]

I am not convinced that more people running nodes will solve the scalability problems. I think more people using their own nodes for RPC will take the load off of public services like s2 and xrplcluster.com, but there are numerous other load problems that would not be affected by more people running nodes. For instance, nodes are taking a long time to sync. More people running nodes most likely won't improve sync times, as each node still needs to sync fully. Maybe the peer network will have more capacity if more people run nodes, but it also could lose capacity if people run nodes that don't perform that well. Or consider the fee issue. More nodes on the network is not necessarily going to bring down fees.

I should also note the there has been significant work on the public facing services front. Reporting mode exists in rippled today, and allows people to run public facing RPC services in a much more scalable way. Project clio (https://github.com/cjcobb23/clio) is coming soon, and further improves on reporting mode.

[cjcobb23]

I do agree with the notion that we should make issuing a token cost more to the issuer. What if we just charge higher fees, or a higher reserve, or even burn the reserve?

[shortthefomo]

Do not confuse the issue of trustset transaction SPAM, that is another issue. This is around only the issuance of a new token.

The wider ecosystem using and running trustset transactions can be handled by fees, that is relatively straight forward. This issue is around tokens like BumcrackXRP raising the technical "debit" level these issuers need to cross filters out a lot of this rubbish.

[syeduali93]

I do agree that issuing tokens should with some sort of commitment/cost to the issuer that ultimately benefits the network.

At the very least I think large issuers should connect to their own nodes rather than leeching off the public clusters. How to go about that is the challenging part.

[wojake]

I've had a few conversations about nodes and it is safe to say that if we implement such thing:

Require the running of a node/validator to issue a token.

Is not appropriate to force users of the XRP Ledger to run their own rippled servers since we need node maintainers that know what they're doing, it takes a considerable amount of time to understand the basics of linux CL, hardware, distros, the XRP Ledger, rippled and not only that, if the network shits itself, we need node maintainers that can understand the crisis and try fixing their own nodes without needing support from rippled maintainers.

I'm also not saying that people shouldn't try running their own server(s) since experience is one of the most important building blocks in this industry. It's generally just not appropriate to force users to participate in the network's consensus to use it's features, it creates an unbalanced network where a good majority of its participants are forced to do so with bad tools and hardware.

Hopefully, once Lite Accounts are deployed, more users migrate there, this creates a situation where users are only allowed to mint tokens via privileged accounts (normal accounts, similar to today's).