Jump to content
Sukrim

Decentralization implementation

Recommended Posts

https://ripple.com/insights/how-we-are-further-decentralizing-the-ripple-consensus-ledger-rcl-to-bolster-robustness-for-enterprise-use/

"As more validators join RCL, their performance will be monitored against a specific set of criteria, including their consensus agreement rate, uptime, verification of identity and public attestation. [...] Over the course of the next 18 months, for every two attested third-party validating nodes that meet the objective criteria mentioned above, we will remove one validating node operated by Ripple, until no entity operates a majority of trusted nodes on the RCL."

They are probably referring to https://charts.ripple.com/#/validators

I'm a bit concerned especially about agreement rate and uptime, since this might lead to actual centralization rather than decentralization, not of owners of the validator keys, but of owners of the hardware that runs validators.

The extremely high agreement rate between the top validators on that page lets me suspect that most of them are on the same network or at least very close together in a network and probably also physical sense (e.g. all hosted on Amazon AWS, maybe even in the same region). If now very high agreement rates observed by other nodes is required, this might lead in practice to the effect that only validators located close to existing validators can reach these rates in the first place.

While Consensus in theory should have enough time to also let validators participate that have high latency just because of their physical and/-or network location (1000 km adds about 5-6 ms latency in optical fibers just because of the speed of light limit - halfway around the earth this means that even a theoretically optimal optical fiber adds a bit more than 0.1 s of latency). In practice I suspect that operating a validator in a place that doesn't have very good peerings with AWS will land you in the bottom half of that chart rather fast.

Also I would argue that a very independent validator that is online only every second day or takes only part in every second round of Consensus is much better to have in your UNL than one that is hosted on the same physical infrastructure as a lot of existing ones. AWS/Azure/Hetzner/Google can go down or get funny government letters just like any other hosting provider out there.

Last but not least, mandated key rotations or similar might also be good to have, I personally do not see the value of requiring someone to buy(!) a domain just to run a "verified" validator but as soon as the concrete criteria are published I'll check if I meet them otherwise to see how one would get a domain without leaking private data all over the WHOIS databases... Also the process seems a bit closed: "In order to have the verified validator domain published, email validators@ripple.com with both signatures as well as the validator public key and domain name." RCL even has fields for domain names in every AccountRoot node. Time to use it...

Tl;DR: Please don't require extremely high agreement rates or uptimes and require independent on-premise hosting of validating nodes instead.

 

PS:
It would be nice if validators could also choose to sign and publish their currently used UNL.

Share this post


Link to post
Share on other sites

I think they will (have to) be more strict on checking that the validators are actually run by individuals, rather than checking performance metrics like uptime and latency.

If now is the time to recruit new validators, you better make sure multiple 'independent individuals/institutions' are not controlled by one larger organization.

Share this post


Link to post
Share on other sites
30 minutes ago, Sukrim said:

Tl;DR: Please don't require extremely high agreement rates or uptimes and require independent on-premise hosting of validating nodes instead.

 

On-premise hosting is a little bit too constraining.

Do you think that companies like GateHub physically have rooms (with appropriate AC, soundproof walls, fiber, etc.) where they can put large rack closet? GateHub UK office is virtual.

 

 

Quote

PS:
It would be nice if validators could also choose to sign and publish their currently used UNL.

 
 

Agreed.

Edited by T8493

Share this post


Link to post
Share on other sites
22 hours ago, Sukrim said:

https://ripple.com/insights/how-we-are-further-decentralizing-the-ripple-consensus-ledger-rcl-to-bolster-robustness-for-enterprise-use/

"As more validators join RCL, their performance will be monitored against a specific set of criteria, including their consensus agreement rate, uptime, verification of identity and public attestation. [...] Over the course of the next 18 months, for every two attested third-party validating nodes that meet the objective criteria mentioned above, we will remove one validating node operated by Ripple, until no entity operates a majority of trusted nodes on the RCL."

They are probably referring to https://charts.ripple.com/#/validators

I'm a bit concerned especially about agreement rate and uptime, since this might lead to actual centralization rather than decentralization, not of owners of the validator keys, but of owners of the hardware that runs validators.

The extremely high agreement rate between the top validators on that page lets me suspect that most of them are on the same network or at least very close together in a network and probably also physical sense (e.g. all hosted on Amazon AWS, maybe even in the same region). If now very high agreement rates observed by other nodes is required, this might lead in practice to the effect that only validators located close to existing validators can reach these rates in the first place.

While Consensus in theory should have enough time to also let validators participate that have high latency just because of their physical and/-or network location (1000 km adds about 5-6 ms latency in optical fibers just because of the speed of light limit - halfway around the earth this means that even a theoretically optimal optical fiber adds a bit more than 0.1 s of latency). In practice I suspect that operating a validator in a place that doesn't have very good peerings with AWS will land you in the bottom half of that chart rather fast.

Also I would argue that a very independent validator that is online only every second day or takes only part in every second round of Consensus is much better to have in your UNL than one that is hosted on the same physical infrastructure as a lot of existing ones. AWS/Azure/Hetzner/Google can go down or get funny government letters just like any other hosting provider out there.

Last but not least, mandated key rotations or similar might also be good to have, I personally do not see the value of requiring someone to buy(!) a domain just to run a "verified" validator but as soon as the concrete criteria are published I'll check if I meet them otherwise to see how one would get a domain without leaking private data all over the WHOIS databases... Also the process seems a bit closed: "In order to have the verified validator domain published, email validators@ripple.com with both signatures as well as the validator public key and domain name." RCL even has fields for domain names in every AccountRoot node. Time to use it...

Tl;DR: Please don't require extremely high agreement rates or uptimes and require independent on-premise hosting of validating nodes instead.

 

PS:
It would be nice if validators could also choose to sign and publish their currently used UNL.

You make some great point!

I can tell you (from personal experience) that validators not on AWS perform just fine. I'd urge you to run one (if you aren't already) just to see your performance. Run for a day or two and check charts.ripple.com.

Your point about key rotation is well taken. There is support for manifests (which will allow you to give your validator an ephemeral key that can be rotated as often as you feel is necessary—almost anyways: you can only rotate through 4,294,967,294 keys) and you'll be hearing more about those.

As for requiring a domain: it's a convenient way to identify things. Think of it as one of the criteria that Ripple imposes to have a validator on its own UNL. Another entity might choose to not require domains. 

As for the procedure to list validators, I believe that the method you describe is only one of a number of options. I'll check on that.

Again, you raise some interesting points. Rest assured that we are listening and taking notes, and your feedback and that of others is both appreciated and carefully considered.

P.S.: re your post-script, do stay tuned! :victory:

 

Share this post


Link to post
Share on other sites

Thanks for the nice answer. :-)

I am sure that validators on AWS perform fine, I'm worried that only validators on AWS will be able to perform fine enough to matter, because most/all of the existing ones perform fine on AWS. Exactly this increased "performance" since most peers are on the same network segment seems worrying. In the end, validators (just like Bitcoin mining pools) have good reasons to not directly expose their IP address, so it is rather difficult to tell where they are even actually located. Disclosing at least the hosting provider (in a signed filed next to the domain) however could already give some useful indication to build UNL selection rules around.

 

Edit: I misread... I thought you wrote "validators on AWS perform fine" and overlooked the "not" in there. I am already running a rippled server semi-continuously since 2013 and have switched on validation for fun a year back or so (not that it matters anyways). If I wanted to operate it more reliably, I'd have to turn off full history though I guess, since as soon as it needs to fetch a bit more history, it still seems to hit the SSD array relatively hard, causing the agreement rate to drop quite a bit. At the moment I don't see this as a priority though, I'd rather focus on finally getting import/export of historic data done since it'll likely still take a while until the scheme described in the OP is set in place. I'm not even sure if I as a private person not in the US am even allowed to take part in this...

Edited by Sukrim

Share this post


Link to post
Share on other sites
On 5/13/2017 at 7:34 AM, nikb said:

I can tell you (from personal experience) that validators not on AWS perform just fine. I'd urge you to run one (if you aren't already) just to see your performance. Run for a day or two and check charts.ripple.com.

I can confirm this.

for experiment purpose, I had just deployed a validator on a Non-AWS server, locating half-globe away from US (to be specific, Singapore). and its performance had been ranking among the tops on https://charts.ripple.com/#/validators in the past few days.

for those who like to monitor, this is my validator: nHBbzjMdbM4ChzKYB3F6Sua9ebPiAamEMJA7DJqpbrFjPGDxvXE1
 

Edited by ripplerm

Share this post


Link to post
Share on other sites

×