New nodes acceptance process

[bartekn]

We've been receiving quite a lot of PR adding new nodes but some of them are unmaintained after merging. I've been thinking about the process and I came up with something like this:

1. Validation - first we need to validate if the node is really run by the organization. We wil require organizations to add their node information to stellar.toml file. The validator's host should be a subdomain of the organization's root domain. If the data matches, we merge the PR and deploy.
2. Trial period - every new node is hidden by default but we start monitoring it's uptime. Trial period lasts 30 days. If the node is up for less than 97% (t as trial) of time we remove the node from the list and block the organization from adding a new node for the next 3 (b as block) months.
3. Removing unhealthy nodes - after the trial period a node is made visible. To make sure that organizations are monitoring and maintaining their nodes we check the uptime stats every quarter. If the uptime in the last 3 months is below 99% (q as quarter uptime) we remove the node and block adding it back for the next 3 (b) months.

I selected t to be 97% because it's around one day in 30 days period. I guess these people would still be learning how to run a node so it sounds fair to have a downtime that sums up to 24 hours. q is higher (99%) but it's also around one day in 90 days period. We should require high uptime for production nodes. b is 3 months as it should be high enough to make sure people care about their nodes' uptime but also don't discourage them too much from adding them back.

It's not the final process, just a starting proposal. Thoughts?

[tomerweller]

I think the criteria you set here is great.

Correct me if I'm wrong but it seems that there's still a manual component to this system in terms of submission and review?

How about completely automating this system? Essentially:

• Have a crawler that collects information about all validators on the network (style stellarbeat.io)
• Monitor uptime for all known validators
• Have the Dashboard only display validators that pass the uptime criteria and have all required metadata associated with it.

How does one associate metadata with their validator?
They create an account with the node address that has a homedomain associated with it. That homdomain's stellar.toml file will contain the required metadata.

Moderation?
We might still be interested in moderation. Either removing smelly validators or adding kosher validators that haven't passed the criteria (good for bootstrapping). One option is to have the monitor inform moderators that a validator is above to pass the uptime criteria if they want to whitelist/blacklist it. (I prefer blacklisting)

Thoughts?

[robertDurst]

While Bitcoin's consensus protocol calls for a different flavor of node dashboard, I like earn.coms's dashboard/leaderboard quite a lot. It uses metrics to quantitatively calculate which nodes are the most beneficial to the bitcoin network.

It has an automated process for discovering nodes:

The current methodology involves sending getaddr messages recursively to find all the reachable nodes in the network, starting from a set of seed nodes.

Implementation code: link
Overview of crawler: link

It also includes a handy tool to make sure your node can be detected by the crawler:

Moderation?

Since quorum sets are built around trust, I agree that we wouldn't want to allow anyone to claim to be a Lightyear node (where the metadata comes in) and we do want to differentiate between well performing nodes and bad performing nodes. However, I'd support letting the user moderate for themselves. If we have accurate stats showing uptime and historical performance along with some metadata, I think that would enable people to make informed quorum set decisions.

[tomerweller]

For validator details, essentially this: stellar/stellar-protocol#111

[vcarl]

Closing in favor of #107