Jump to content
NateB

Criteria to become a “UNL” Validator

Recommended Posts

Posted (edited)

What exactly are the criteria for a validator to be added to the dUNL list to obtain voting rights?

It seems Ripple controls who is on/off this list and there is no decentralized mechanism to become a dUNL validator? Why is this?

I’ve seen this post by Rippleitin.nz detailing out the process that was involved prior to his validator being included on the default list -- https://coil.com/p/rippleitinnz/dUNL-Transparency-/6Y2GkMjg 

Can anyone provide any additional documentation?

It seems David Schwartz also posted this Twitter chain yesterday (07/16/20): 1283938459682398208?s=20https://twitter.com/JoelKatz/status/1283938459682398208?s=20

Edited by NateB
Grammar changes.

Share this post


Link to post
Share on other sites
23 minutes ago, xerxesramesepolybius said:

Here is an idea to prove Ripple and XRP are separate, Ripple turns off all their validators for a week. What would happen?

Here's a more radical idea: Ripple turns off vl.ripple.com for a month. What would happen?

Share this post


Link to post
Share on other sites

There is another one available at https://vl.coil.com/, so we are backed :P. but seriously, it's still sort of undocumented how to setup such an UNL. It's one of those final steps that have to be taken to make XRPLedger truly decentralized, but I guess we have to wait for Ripple to make the move. It's good to see at least some thought on the subject from David. 

I also note that the concept of dual layer consensus is used in more and more upcoming blockchains (e.g. Ellixxir, Celo, Ethereum 2.0). In general, good enough consensus can be obtained with small group of nodes, (the smaller groups allowing much faster consensus, larger capacity and finality), as long as that group of nodes is also created and managed under consensus rules. 

Share this post


Link to post
Share on other sites
4 hours ago, jn_r said:

There is another one available at https://vl.coil.com/, so we are backed :P. but seriously, it's still sort of undocumented how to setup such an UNL. It's one of those final steps that have to be taken to make XRPLedger truly decentralized, but I guess we have to wait for Ripple to make the move. It's good to see at least some thought on the subject from David. 

I also note that the concept of dual layer consensus is used in more and more upcoming blockchains (e.g. Ellixxir, Celo, Ethereum 2.0). In general, good enough consensus can be obtained with small group of nodes, (the smaller groups allowing much faster consensus, larger capacity and finality), as long as that group of nodes is also created and managed under consensus rules. 

Thanks for the response! So it seems at least I am not the only who doesn't understand the process? Ripple (the company) simple chooses who is on the dUNL based on an unknown criteria currently? I am as big a fan of XRP and the XRPL (and have much skin in the game investment-wise), however I couldn't find any resources on this topic hardly.

Share this post


Link to post
Share on other sites
12 minutes ago, NateB said:

Ripple (the company) simple chooses who is on the dUNL based on an unknown criteria currently?

That is basically the case. It is Ripples distributed (not decentralized) dUNL, so they control who is on it. I trust they make some right decisions on that part, but it is not decentralized and we do not know their selection process.

 

Share this post


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

Thanks for the response! So it seems at least I am not the only who doesn't understand the process? Ripple (the company) simple chooses who is on the dUNL based on an unknown criteria currently? I am as big a fan of XRP and the XRPL (and have much skin in the game investment-wise), however I couldn't find any resources on this topic hardly.

I think they have some standard,  your validator must have a domain,  and performed well in a relatively long time, those are the basic requirement. and maybe they have some considerations about the decentralization of physical location. and maybe others we don't know.

 

 

Share this post


Link to post
Share on other sites
On 7/18/2020 at 9:24 AM, jn_r said:

I trust they make some right decisions on that part

Why trust blindly instead of finding out if the validators being hand-selected for the dUNL meet ANY minimum standards? The network was one validator away from halting because of questionable validators on the dUNL. How do you justify selecting the 95th best validator? Or one operated by someone who "doesn't work weekends?" Why isn't there any accountability? 

For comparison, Stellar has a somewhat similar list to the dUNL. It's based on high standards and strict, OBJECTIVE criteria. 

https://developers.stellar.org/docs/run-core-node/tier-1-orgs/

 

 

Share this post


Link to post
Share on other sites
59 minutes ago, TiffanyHayden said:

Why trust blindly instead of finding out if the validators being hand-selected for the dUNL meet ANY minimum standards? The network was one validator away from halting because of questionable validators on the dUNL. How do you justify selecting the 95th best validator? Or one operated by someone who "doesn't work weekends?" Why isn't there any accountability? 

For comparison, Stellar has a somewhat similar list to the dUNL. It's based on high standards and strict, OBJECTIVE criteria. 

https://developers.stellar.org/docs/run-core-node/tier-1-orgs/

 

 

Ripple's lack of progress with XRPL is strange, but didn't the Stellar network actually pause or something a while ago?

Share this post


Link to post
Share on other sites
1 hour ago, elias said:

Ripple's lack of progress with XRPL is strange, but didn't the Stellar network actually pause or something a while ago?

Yes! Which is why they created the Tier 1 list, fixed the problem, and came out stronger. In retrospect, I think the XRPL would have been better off halting, rather than having 2-3 people secretly prop it up and go without sleep for days and days. That's not decentralized. That's not sustainable. But try and get people to believe that it happened, let alone care. Nothing. If the network had halted, it would've forced the issue to be addressed and fixed and we would be on the other side, like Stellar, but instead it just lingers. 

Share this post


Link to post
Share on other sites
14 minutes ago, TiffanyHayden said:

Yes! Which is why they created the Tier 1 list, fixed the problem, and came out stronger. In retrospect, I think the XRPL would have been better off halting, rather than having 2-3 people secretly prop it up and go without sleep for days and days. That's not decentralized. That's not sustainable. But try and get people to believe that it happened, let alone care. Nothing. If the network had halted, it would've forced the issue to be addressed and fixed and we would be on the other side, like Stellar, but instead it just lingers. 

I hardly understand this problem, but I did hear DS addressing the issue.  He described some sort of fall back/back up solution.  Generally I trust DS to take these sorts of issues very seriously, so if the system did come within inches of failing I would expect him to apply his mind to solving the issue properly?

Share this post


Link to post
Share on other sites

I'm also not into the technicals of nodes and validators, but isn't it natural evolution to shift from "everybody and his mum running a validator in the basement" to wanting those things run by 'trustworthy' companies? Not to say individuals are not trustworthy, but are a higher risk. Just like people don't mine bitcoin on their spare laptop anymore but build enormous BTC mining farms wich work together in pools?

The trouble with an open source community and everybody wanting and being able to run one is that those validators are linked to emotions. When experiencing a bearmarket for example people lose trust in crypto and XRP and validators are being unplugged. Or people start to disagree with Ripple, or not receiving payments for adding to the network. I think creating incentives to run one makes it even more dangerous.

Companies wanting to use Ripplenet/XRP should be the ones running the validators eventually.

Share this post


Link to post
Share on other sites
36 minutes ago, Caracappa said:

I'm also not into the technicals of nodes and validators, but isn't it natural evolution to shift from "everybody and his mum running a validator in the basement" to wanting those things run by 'trustworthy' companies?

I'm saying that trustworthy companies aren't what is being added to the dUNL. I think there are questionable, subpar validators on the dUNL and nobody is asking for any sort of justification as to WHY they were added. Are there any standards at all? On top of that, the validators that get added aren't given any guidance or made of aware of any expectations placed on them. Are they committing to something by being added? If so, they have no idea what that might be. 

Again, as a comparison, look is what is expected of Tier 1 nodes on Stellar:

Quote

To help with Stellar’s decentralization, the most reliable and advanced Stellar teams join the ranks of “Tier 1 Organizations.” These organizations run three validators, coordinate any changes to their quorumsets, and hold themselves to a higher standard of uptime and responsiveness.

Why Three Validators

The most important function of a Tier 1 Org is to set up and maintain three Full Validators. Why three?

On Stellar, validators choose to trust organizations when they build a quorum set. If you are a trustworthy organization, you want your presence on the network to persist even if a node fails or you take it down for maintenance. A trio of validating nodes allows that to happen: other participants can create a quorum slice for your organization that requires ⅔ of your validating nodes to agree. If 1 has issues, no big deal: the other two still vote on your organization’s behalf, so the show goes on. To ensure redundancy, it’s also important that those three Full Validators are geographically dispersed: if they’re in the same data center, they run the risk of going down at the same time.

Here’s what else Tier 1 Orgs expect of one another:

Publish History Archives

In addition to participating in SCP, a full validator publishes an archive of network transactions. To do that, you need to configure Stellar Core to record history to a publicly accessible archive, and add the location of that archive to your stellar.toml. To be a Tier 1 Org, you should set each of your nodes to record history to a separate archive.

Public archives make the network more resilient: when new nodes come online, or when existing nodes lose synch, they need to consult an archive to figure out what they missed. Sharing snapshots of the ledger, which detail transactions and their results, allows those nodes to catch up, and more archives mean more redundancy and greater decentralization. Plus, sharing history keeps everyone honest.

Set Up a Safe Quorum Set

To maximize network resilience, we’re asking every Tier 1 node to use the same quorum set configuration, which is made up of subquorums of all validators from each Tier 1 Org.

That way, the validator community can experiment with a larger quorum, and can analyze the results of those experiments without disrupting the network. Using existing Tier 1 Orgs as a safety net, we can work together to expand the quorum methodically and deliberately. To see what that quorum set currently looks like, check out the example Full Validator config file.

Declare Your Node

SEP-20 is an open spec that explains how self-verification of validator nodes works. The steps it specifies are pretty simple: you set the homedomain of your validator’s Stellar account to your website, where you publish information about your node and your organization in a stellar.toml file.

It’s an easy way to propagate information, and it harnesses the network to allow other participants to discover your node and add it to their quorum sets without the need for a centralized database.

Keep Your Nodes Up To Date

Running a validator requires vigilance. You need to keep an eye on your nodes, keep them up to date with the latest version of Stellar Core, and check in on public channels for information about what’s currently happening with other validators.

The best two ways to do that:

Join the validators email list

download Keybase and join the #validators channel on the stellar.public team

We always announce new Stellar Core releases in those channels. You can also find those releases on our github.

It’s also critical that you pay attention to information about what those updates mean: often, you’ll need to set your validators to vote on something timely, such as when to upgrade the network as a whole, or how high to set the operations-per-ledger limit.

Coordinate With Other Validators

Whether you run a trio of validators or a single node, it’s important that you coordinate with other validators when you make a significant change or notice something wrong. You should let them know when you plan to:

Take your node down for maintenance

Make changes to your quorum set

Letting other validators know when you plan to take your node down for maintenance or to upgrade to the latest version of stellar-core prevents a critical mass of nodes from going offline at the same time.

Letting other validators know when you plan to change your quorum set allows them to respond, adjust, and think through the implications of expanding the quorum. For the quorum to expand safely, we all need to coordinate to ensure we maintain good quorum intersection.

Monitor your quorum set

We recommend using Prometheus to to scrape and store your stellar-core metrics, and Grafana to render that data for human consumption. You can find step-by-step instructions for setting up monitoring and alerts in Monitoring and Diagnostics, along with links to Grafana dashboards we’ve created to make things easier.

You can also use stellarbeat.io to view validators’ quorum configurations, and get information about their availability and uptime, and the quorum command to diagnose problems with the quorum set of the local node.

You should do regular check-ins on your quorum set. If nodes have bad uptime or prove otherwise unreliable, you may need to remove them from your quorum set so that you don’t get stuck and so that the network doesn’t halt. You may also want to add new organizations that come online and prove reliable. If you plan to do either of those things, remember to communicate and coordinate with other validators.

Get in touch

If you think you can be a Tier 1 Org, let us know on the #validators channel on Keybase. We can help you through the process, and once you’re up and running, we’ll work to fold you into the quorum so that you can take your rightful place as a pillar of the network. Once you’ve proven that you are responsive, reliable, and maintain good uptime, we will adjust the quorum set recipe above to include your validators.

 

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...