Jump to content

What would happen if Ripple turned off their validators for a week


Recommended Posts

8 hours ago, xerxesramesepolybius said:

Gee thanks.

Where is the best place to see the up-to-date UNL?

One of the things I recall Tiff complaining about was that there are validators and validators and the ones not on the UNL don't really matter.

If anything, without a UNL, there would be more diversity of validation (as far as my understanding goes). A "bad actor" would need to convince at least 80% of validators to create a ledger with bogus data (again, as far as my understanding goes). 

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

You’re welcome. I appreciate the opportunity to discuss the topic.

Thanks for participating here Nik, it’s great to see input from experts.

Can I ask regarding the UNL...  given that Ripple serve a UNL and most validators would leave that as their default trusted list, what is the point of non UNL validators?

Obviously one point is that over time their behaviours and uptime might inform future versions of the UNL...  by participating they are creating a record that they can stand on to be counted in a future UNL.

But apart from that,  do the other validators add to robustness?  (I don’t see how,  if the majority are following the UNL.)

 

Also, should we be hoping for growth over time in the size of the UNL?  The larger the pool and the more diverse in nature, location and jurisdiction,  the less vulnerable the ledger?

 

Thanks for an thoughts you have time to share on this.

Link to post
Share on other sites
On 9/17/2020 at 7:10 AM, nikb said:

If a sufficient number of validations from validators on a server's UNL were received, that server would advance its ledger. If not, the server would not. For servers using the UNL currently published by Ripple (which currently includes a total of 38 validators), the remaining 32 non-Ripple validators would be enough to continue advancing the ledger, regardless of whether Ripple's validators were online or what they did.

What would the minimum number of validations be? and what determines it? Wasn't this the thing that @TiffanyHaydenwas worried about, not having enough validators?

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

What would the minimum number of validations be? and what determines it? Wasn't this the thing that @TiffanyHaydenwas worried about, not having enough validators?

In the instance that Nik mentioned because 32 of 38 validators is 84% (greater than the 80% threshold) then consensus is met.

I’m not an expert but believe the 80% is a setting in XRPL code based on the theoretical understanding of the consensus algorithm and may change in future if the algorithm or the theory advances.  I could be wrong though.

So if my understanding is correct, if validators are configured to be using the Ripple UNL and Ripple suddenly pulled their validators (they wouldn’t,) then because 84 is greater than 80, the XRPL would seamlessly sail on.  
 

But I am not an expert,  and I have a number of areas I’m not clear on.  I also suspect this is a non-trivial subject with emergent properties that are not obvious to the uninitiated.  That’s why it’s so good @nikb was willing to share.

Link to post
Share on other sites

@BillyOckham's analysis is correct:

80%—the quorum requirement—is a threshold for consensus defined in the code. The developers chose the number 80% based on the best understanding of the nature of the problem and the overall algorithm's behavior in various theoretical and tested circumstances, and (I believe) because 80% is an easy number for humans to understand.

The XRP Ledger's protocol is designed so that each server operator can choose their server's UNL based on their own ideas/rules/parameters. It was always known that servers that have very different lists from each other would likely diverge, but research efforts showed (disappointingly) that anything short of about 90% overlap was not totally fork-safe if the internet connection between the servers suffers very specific types of delays¹. Thus a recommended UNL, such as the one Ripple publishes (and the equivalent one Coil publishes) defines a set of validators everyone can use; everyone who uses the same (or similar enough) list is guaranteed not to fork from one another.

As of today, Ripple's list has 38 validators, 6 of which are run by Ripple. Even if all six of Ripple's validators turned off, the rest of the network could make forward progress since 32/38 is still over 80%, but it would be working with a thinner margin of error. It would only take a couple validators disagreeing or turning off to cause an outage. To resolve this, XRP Ledger users would need to reconfigure their UNLs, possibly by using a new list from a different publisher such as Coil.

One area of consensus tech that is progressing is the idea of a "negative UNL". A preliminary implementation of this feature is in v1.6.0 and we are actively testing it on the Devnet right now. With negative UNL, validators who are still online can add a note to a ledger saying, "Hey, Ripple Validator 5 seems to be offline," and if a consensus of them agree, they can temporarily adjust the quorum requirement down so that the validators who are offline don't count towards the total number of validators (unless they come back online and vote). So if Ripple Validator 5 is on the negative UNL, the quourum requirement becomes "80% of 37 validators not including Ripple Validator 5, or 80% of 38 validators including Ripple Validator 5."  And if it does come back online, then a consensus can remove it from the negative UNL.

If the Negative UNL system were in place on Mainnet, then the scenario where Ripple disables 6 validators could go a lot smoother: pretty quickly, the remaining validators could say, "Hey, all six of these are offline" and as long as that remains the case, the quorum would be 26 of 32 (still 80%) instead of 38 total validators.

A bigger problem would be if Ripple were to stop signing new recommended UNLs. Each one has a built-in expiration date, so if Ripple just let the latest one expire, servers that use Ripple's list would have an outage until their operators reconfigured their UNLs. If there's no obvious alternative or backup, this could be an extended outage during which the XRP Ledger community would have to figure out which validators to put on their lists now or who should sign the lists from now on.

 

¹ The original Ripple whitepaper relied on the assumption that all messages from any given server would either reach all participants in a timely fashion, or would not reach any of them in a timely fashion; under those constraints, something like 60% overlap was sufficient to prevent forking. However, the standard in consensus research is to assume that some malicious actor could fully manipulate all network messages to arriving with arbitrary delays to specific participants only. Under these more restrictive network conditions, it's possible for byzantine validator(s) to issue multiple validations of different ledger candidates of the same ledger index to different parties, while network delays prevent the parties from noticing until it's too late that the byzantine validator is sending out mutually-incompatible validation messages.

Link to post
Share on other sites
47 minutes ago, mDuo13 said:

@BillyOckham's analysis is correct:

and short and superficial compared to the ones by MDuo13 and NikB.   :)    Thanks so much for that detailed and thoughtful reply.

 

It was most interesting to learn of the dead-man switch inside the UNL.  (A surprise to me, but that is no surprise.  :))

I don’t actually get why that was done,  (but I have confidence the logic is sound).  I would have thought it better to leave it as a ‘no news is good news’ type thing, if nothing changes carry on, if something needs changing then there is not a time limit looming to get it done in type thing.

All of this is fascinating,  but a bit above my capacity to really understand in detail.  So I just assume that Ripple and other XRPL devs know what they are doing,  and that 58 million ledger closes is fairly good evidence of that.  :) 

 

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

It was most interesting to learn of the dead-man switch inside the UNL.  (A surprise to me, but that is no surprise.  :))

I don’t actually get why that was done,  (but I have confidence the logic is sound).  I would have thought it better to leave it as a ‘no news is good news’ type thing, if nothing changes carry on, if something needs changing then there is not a time limit looming to get it done in type thing.

A published UNL reflects the publisher's recommendations, based on whatever criteria the publisher has and information available to him or her. Such judgements represent a given moment in time and have a shelf-life. They shouldn't be "perpetual."

It would speak volumes if nobody cares enough if no UNL were published to actually go and publish their own. Inertia is a horrible thing. It is, in fact, deleterious to things that are open to anyone but belong to nobody. Codifying inertia would be tantamount to a death knell, in my opinion. 

 

3 hours ago, BillyOckham said:

All of this is fascinating,  but a bit above my capacity to really understand in detail.  So I just assume that Ripple and other XRPL devs know what they are doing,  and that 58 million ledger closes is fairly good evidence of that.  :) 

Please don't feel this way: it's great that people and groups have earned your trust, but don't leave it at that. Expand your knowledge and ask yourself whether it makes sense for you to simply trust others or for you to actually seek to minimize your reliance upon others, even those you deem trustworthy.

The XRP Ledger doesn't need cheerleaders. It needs fervent, passionate and educated advocates who are willing to point out the issues where improvement is not only possible but, indeed, imperative and who will, if needed, step up and do what's needed instead of waiting for someone else to.

:moil:

Link to post
Share on other sites
Please don't feel this way: it's great that people and groups have earned your trust, but don't leave it at that. Expand your knowledge and ask yourself whether it makes sense for you to simply trust others or for you to actually seek to minimize your reliance upon others, even those you deem trustworthy.
The XRP Ledger doesn't need cheerleaders. It needs fervent, passionate and educated advocates who are willing to point out the issues where improvement is not only possible but, indeed, imperative and who will, if needed, step up and do what's needed instead of waiting for someone else to.
:moil:

Wow. Thats what I call a masterclass answer! [emoji106]


Verzonden vanaf mijn iPhone met Tapatalk
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...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.