Jump to content
Guest Haydentiff

Is identity authentication required to run a validator? Is it an option?

Recommended Posts

Guest Haydentiff

What information (if any) is required to run a validator?

I found this on the website:

Quote

Does Ripple utilize a formal validator onboarding process?

No, a formal validator onboarding process is not compatible with Ripple, as it is a system with no central authority. Rather, Ripple Labs provides recommendations and best practices.

Does this mean there are no identity requirements?

Share this post


Link to post
Share on other sites

My understanding is that there are no identity requirements but if you want to be a trusted by other validators you'd need to provide some sort of identification/guarantees. Anyone can set up a validator but if no one trusts you then you have no ability to influence the validation of ledgers. In the future Ripple plans to publish a list of recommended validators based on ID and performance and some validators will be trusted just based on their preexisting reputation (Microsoft). Zeiler explains it starting here (1:00:00) the peer to peer network is described starting at 53:00:00:

 

Edited by cmbartley
added media

Share this post


Link to post
Share on other sites
Guest Haydentiff
1 hour ago, cmbartley said:

You can see which other validators a given public validator trusts by loooking at their ripple.txt file. You can see that Ripple trusts the 5 validators that it runs. PaleOrbGlow also trusts the Ripple validators but is not trusted by Ripple.

Thanks!

Share this post


Link to post
Share on other sites
2 hours ago, cmbartley said:

You can see which other validators a given public validator trusts by loooking at their ripple.txt file. You can see that Ripple trusts the 5 validators that it runs. PaleOrbGlow also trusts the Ripple validators but is not trusted by Ripple.

Do note, that the list of validators in ripple.txt is just a list that the owner of that domain recommends but not necessarily the list of validators the owner configures on their server's UNL.

Plenty of ripple.txt files don't list any validators at all. http://bougalis.net/ripple.txt is one such example.

Bottom line: you can't reliably deduce what entries are in a validator's UNL by looking at a ripple.txt file.

Share this post


Link to post
Share on other sites
3 hours ago, Haydentiff said:

What information (if any) is required to run a validator?

I found this on the website:

Does this mean there are no identity requirements?

There are none in the sense that you can start a validator without needing to show your ID to someone. All you need is to install rippled and add a [validation_seed] section to your config file.

Whether anyone will trust your anonymous validator is an entirely different question.

Share this post


Link to post
Share on other sites
31 minutes ago, nikb said:

Do note, that the list of validators in ripple.txt is just a list that the owner of that domain recommends but not necessarily the list of validators the owner configures on their server's UNL.

Plenty of ripple.txt files don't list any validators at all. http://bougalis.net/ripple.txt is one such example.

Bottom line: you can't reliably deduce what entries are in a validator's UNL by looking at a ripple.txt file.

Interesting, why don't I see your validator address listed at validators.ripple.com?

Share this post


Link to post
Share on other sites
1 minute ago, cmbartley said:

Interesting, why don't I see your validator address listed at validators.ripple.com?

I remote-upgraded the O/S on the box I was running that validator on a while ago, and it got borked. I need to go down to where the box is colocated and tinker with it. Just haven't had the time. Don't worry though, I'm running another validator, but I haven't followed the instructions on how to list it by name. Which reminds me, I probably should do that today.

Share this post


Link to post
Share on other sites
19 minutes ago, nikb said:

I remote-upgraded the O/S on the box I was running that validator on a while ago, and it got borked. I need to go down to where the box is colocated and tinker with it. Just haven't had the time. Don't worry though, I'm running another validator, but I haven't followed the instructions on how to list it by name. Which reminds me, I probably should do that today.

Microsoft says that they're working on doing this too but they haven't done this yet... would be great to see their name on the validator list, we're know they're running one, but it'd be nice to see their name. 

Share this post


Link to post
Share on other sites

Yeah, running a validator is something anyone can do. You can follow the network and send validations out to share. But unless someone else configures their validator to trust you, you're just shouting opinions into the void. You can also configure your server to follow and participate in a parallel network (like the Test Net) if you like.

In theory, a community (or a big corporation, etc.) could all start up a bunch of rippled nodes on a parallel network, configure them to trust each other, and have their own completely parallel network with a completely different XRP distribution, etc. Ripple doesn't like that, for obvious reasons -- it competes with "our" production network, and all XRP in the current mainnet (you know, Ripple's huge war-chest of XRP) would have little to no value in the altnet. So we don't encourage it. (Actually, that's more or less what Stellar did. The cool thing is, you can still set up gateways to automatically link the networks at market rates. In a weird way, having a similar parallel network that's interconnected with ours actually increases our value and furthers our goals -- less so the "getting rich" one, but stuff like financial inclusion and innovation in the finance space -- through our combined efforts.)

Actually, one similar thing that could be important is the ability to load a ledger state from the current network, but then replace the set of validators completely. In the present, that would probably just manually fork the network from its current state unless. But in the case where Ripple (Labs) ceased to run our validators, interested parties could take up the mantle and run RCL themselves where we left off. If you're already running validators, it would be as simple as taking the official Ripple validators off your RCL and substituting some appropriate list of third parties.

Actually, Ripple's plans are basically a much more gradual, graceful version of that process, to minimize disruptions and chances of developing an unstable validator topology in the process. But if Ripple ever went out of business, or gave up on RCL all together, or was shut down by a government authority or something like that, you could decentralize the network without us.

Share this post


Link to post
Share on other sites

This thread has information relevant to this discussion, so I just thought that I would share the link.  Thanks for your very detailed response @mDuo13.  On the note you made regarding substituting a list of third parties into your UNL in the case of the Ripple Labs validators going down, we only have the validator registry statistics to base our decision on as validator operators for who to trust.  Can you or Mr. Schwartz share any more information regarding attesters right now at this time within this discussion? 

Edited by Twarden

Share this post


Link to post
Share on other sites

Basically, an "attestor" is someone who provides information much like what the Validator Registry provides right now, possibly including more detailed and varied data as well.

At some point we expect that you will just configure your rippled server to connect to an attestor directly and choose a reasonable selection of validators to trust. That's not happening in the next one or two versions of rippled, at least, so I can't say how long it'll be. Until then, you would modify the list of trusted nodes in your config file (and you might need to flush the cached list of validators from rippled's internal database, too). Of course, be extremely careful because poor UNL choices could cause your node to report ledgers as validated that the rest of the network doesn't agree are validated (aka forking), which could cause you to lose money, etc.

Some other points of note:

1. mduo13.com and paleorbglow.com are both operated by current Ripple employees in the San Francisco area.

2. Any validator whose "disagreement" is higher than its "agreement" is probably connected to the Test Net.

3. Running a validator is not very hard, although we're still working to make it even simpler. (One challenge: staying up-to-date with rippled software releases.) If you have a tool or a business that depends on the Ripple Consensus Ledger, it's in your interest to run a validator! Shoutouts to xagate.com, who not only recognized this but put in the few minutes it takes to get their validator's identity verified.

4. Regarding network bandwidth, I find that my validator tends to occupy about 475kbit/s up and down on average throughout the day, which is not insubstantial but also not really noticeable on my home broadband connection. CPU usage is pretty low, memory is hard to measure but probably a little on the high end with RocksDB as your database format (that's the default, by the way). I'm running a validator on a desktop PC that I built in 2009, so it shouldn't be too unaffordable to get a machine that can run a validator today.

5. The validator registry is still a work in progress. Sometimes a lack of validations from a server means that the registry didn't collect that data, even though the servers were validating. The code for it is open-source: frontend and backend. Feel free to fork it and build your own registry! At some point, there might be more standards for how an attestor should present its data (hint: JSON is a good idea!), but for now the field is wide open.

6. Some good ideas of data that you might take into account when choosing validators to trust:

  • the identity and reputation of the person or business running the validator (this is what the domain identification is meant to proxy)
  • the jurisdiction(s) in which they live or do business
  • the geophysical location where the validation server is running
  • the rates of agreement and disagreement of their validations with the rest of the network
  • the latency with which validations appear (otherwise, you can fake very high "agreement" by waiting for everyone else to decide on a ledger and belatedly casting a vote for it)
  • the past version history of the rippled server(s) doing the validation

Some of these are hard, or maybe even impossible, to prove. However, the more high-quality data an attestor can provide, the easier it is to make smart decisions about which nodes to trust.

Share this post


Link to post
Share on other sites
1 minute ago, mDuo13 said:

4. Regarding network bandwidth, I find that my validator tends to occupy about 475kbit/s up and down on average throughout the day, which is not insubstantial but also not really noticeable on my home broadband connection. CPU usage is pretty low, memory is hard to measure but probably a little on the high end with RocksDB as your database format (that's the default, by the way). I'm running a validator on a desktop PC that I built in 2009, so it shouldn't be too unaffordable to get a machine that can run a validator today.

What about SSD disk? Do you have any estimate which AWS instance is enough for running a validator?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...