Recommended Posts

This is a big step towards decentralizing control of the XRP Ledger! Update your validator settings!

Quote

Ripple has released rippled version 0.81.0, which introduces changes that improve the scalability of the XRP Ledger and transitions the recommended validator configuration to a new hosted site, as described in Ripple’s Decentralization Strategy Update post.

If you operate a rippled server, then you should upgrade to rippled version 0.81.0 immediately.

Ripple recommends that you:

Edit your rippled.cfg to remove the [validators] section, if one is present.

Replace the contents of any existing validators.txt file with the version included with this release. If you are upgrading to rippled version 0.81.0 using the rippled RPM package, then your default validators.txt file may automatically be updated, in which case you will not need to modify the file. The validators.txt file is usually in the same directory as your rippled.cfg file.

After starting your rippled server, confirm that it is configured to use the new defaults by executing:

If you operate a rippled server, but do not upgrade to rippled version 0.81.0, then your rippled server may periodically drop transactions and fall out of sync with the network.

On Tuesday January 16, 2018, the current validator keys on all five Ripple-operated rippled validator servers will be replaced. If you have been using the recommended default configuration and do not reconfigure your rippled server before that time, then your rippled server will stop seeing validated ledgers.

Consensus can only work in a guaranteed way with at least 80% honest nodes in your local UNL and also 80% global overlap of individual UNLs. How does the decentralization strategy ensure this property or even detect potential failures?

Share this post

Link to post

Share on other sites

Consensus can only work in a guaranteed way with at least 80% honest nodes in your local UNL and also 80% global overlap of individual UNLs. How does the decentralization strategy ensure this property or even detect potential failures?

How about a professionally curated list? Because that's what vl.ripple.com is.

For now, everyone using Ripple's curated list has 100% overlap with everyone else using it, so that solves the overlap issue for now. In a future with multiple different validator lists run by different parties, making sure that the lists have sufficient overlap is going to be a key challenge. We have some other plans to improve on that, which unfortunately I don't think I can talk about. Maybe @justmoon would be willing to spill just a few beans?

As for the honesty and non-colluding properties of validators, that's what Ripple's oversight of the validator list is about. It's partly about the kinds of institutions we hope to bring on board—universities and charities and other organizations working for the public benefit, in addition to businesses who might have a stake in the continued proper behavior of the XRP Ledger, like exchanges, banks, money transmitters, and even web hosting companies.

To recap the Decentralization Strategy, here's a summary:

Switch to using a validator list site (vl.ripple.com). This is where we are now.

All rippled instances configured to use the site can automatically follow Ripple's updates to the recommended set of validators, in lockstep.

In case you're curious, the validator list site publishes cryptographically signed recommendations of validators, so it's not easy to impersonate. And rippled caches the data it gets from the site, so the XRP Ledger won't go down even if vl.ripple.com is down for a while. (It might be tough to bring new rippled servers online while vl.ripple.com is down, but I think there are some protections against that, too.)

Update the site and the existing validators to use validator tokens instead of master validator secret keys.

This adds security to the existing validators. By using tokens, that Ripple can keep the master validator keys offline and periodically rotate the tokens, for example if an operations engineer who might've had access to the config files leaves the company.

Update the site to add 16 new Ripple-controlled validators to the existing 5.

The main reason for this is so that any new individual validator isn't too large a slice of the pie.

Add new third-party validators. For every two third-party validators, Ripple will remove a Ripple-controlled validator from the recommended list.

This will probably occur gradually over the course of 2018 and beyond.

Eventually, as the size of the network has grown, Ripple will encourage others to run validator list sites similar to vl.ripple.com. As long as the lists published on the different sites have sufficient overlap, servers using any list won't fork away from each other.

The "Secret Future Stuff" I alluded to, which may also occur before or as part of step 5.

I think a "manifest" is basically a synonym for a validator token (or the public part of it, anyway?), which is a somewhat ephemeral key signed by the master key pair, plus a sequence number (so it can invalidate previous tokens). Something like that. @wilsonianb knows this stuff better than I do.

Share this post

Link to post

Share on other sites

We have some other plans to improve on that, which unfortunately I don't think I can talk about.

Thanks, guaranteeing UNL overlap is _the_ major challenge in your consensus algorithm and I have yet to see any public discussion about solutions.

13 hours ago, mDuo13 said:

It's partly about the kinds of institutions we hope to bring on board

I personally am very critical about the idea of targeting institutions instead of individuals for validators, especially since I see potential conflicts of interest and because in the end institutions still are consisting of individuals again (and even within an institution not everyone has the same rights usually, so actually only a probably tiny subset of a large institution is actually aware that this group is running a validator).

13 hours ago, mDuo13 said:

validator tokens instead of master validator secret keys

These are not documented to my knowledge by the way and require a special program that you only ship in the RPM file...

Quote

As long as the lists published on the different sites have sufficient overlap, servers using any list won't fork away from each other.

As long as the lists overlap enough AND contain enough honest, non-byzantine validators (which is nearly impossible to verify). Also the initial set of validators that Ripple uses and now will expand has to be taken into account as a given initial "canonical" set. I am also not convinced that it would be in the best interest of list publishers to have high overlap - how the hell should I as a list publisher be specialized in making sure to recommend unique nodes while also having to respect a global(!) UNL overlap in areas and jurisdictions that I have zero stake or expertise in? I would feel confident to generate a localized UNL, e.g. because I know my country or city well, but I have no way of making sure that a Chinese and a Mexican validator are not colluding. Yet I risk putting my subscribers at risk of creating a local fork if I don't put in 80% of the other lists too.