Jump to content
Twarden

A 'Security Blanket' for our UNL

Recommended Posts

A long while ago there was a discussion about UNLs on the official forum regarding the function of validators and how the UNL operates.  Since attesters are still in development an Ripple currently suggests to validator operators to only trust RL1-5,  ledgers may fail to progress due to DDoS and power outages  should proposals fail to reach super majority.  I had posed a question about establishing a security blanket for the network in case the Ripple (Labs) nodes go down which went unanswered, so I hope to reopen the discussion here.

I propose to all entities who currently operate a rippled validator to establish a dialogue regarding the creation of a community organization (somewhat reminiscent of the late IRBA) which would be open to validator operators who voluntarily wish to apply for membership.  Members of this community organization would be required to update their rippled.cfg  to include the current list of all members' validation_public_key's, update their validation_quorom to reflect 80%, and to keep the member list up to date with new addition to the community 'security blanket' program.

If a Ripple employee can please provide any feedback and/or criticism about this proposal it would be of great assistance.  In addition, I would like to know if a senior member at Ripple can shed some light on the taboo that Ripple may encounter unexpected changes in development/a disaster in the future which could (even remotely possible) force the validation network from a decentralized model to a centralized model; like what happened with Stellar after the ledger forked in Winter 2014.

Share this post


Link to post
Share on other sites

The overlap of each validator's UNL should be >40% to prevent fork happened.  Ripple suggest to only trust RL1-5 so the overlap will be 100%

I think the key change of stellar's consensus is it‘s built-in a logic to dynamic manage the UNL and quorum.

For the community, maybe we should build a external tool to manage the UNL and quorum, but only change the rippled.cfg is not enough, maybe should restart the rippled to apply the change.

So if the rippled team add a admin API interface to rippled to make rippled can dynamic manage the UNL and quorum at run time to work with external tool will be perfect.

Edited by yxxyun

Share this post


Link to post
Share on other sites

@mDuo13 I'm sure ripple has some type of disaster recovery plan / fault tolerance in their security policy, but probably won't disclose what that is. Would be nice to have a global community fail-safe though :)  

Share this post


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

@mDuo13 I'm sure ripple has some type of disaster recovery plan / fault tolerance in their security policy, but probably won't disclose what that is. Would be nice to have a global community fail-safe though :)  

I agree that it is very improbable that Ripple will disclose their security policy regarding this topic but perhaps we will be proven wrong.  With saying that, ~32,000 ledgers were lost a long time ago, I would be very interested in learning the strategies that Ripple will apply to overcome another loss of history or learn of the strategies to mitigate risk or perhaps fail safes already in place/development.

A lot of people in the Bitcoin community bitch an complain about how Ripple is centralized, so I see that it would be very beneficial for the community to organize to provide a fail safe, whether that means developing a tool or Ripple collaborating with the validator operator community to ensure overlap requires the establishment of this topic and its 'taboos'. 

Share this post


Link to post
Share on other sites

I may be overstepping my bounds here, but I think I can say with confidence that Ripple is never going to pull a Stellar and go down to just 1 validator. That would be a major fuckup, IMHO. (Obviously, this is not an official company message.)

We can't stop you from including others in your UNL. I think with a requirement of 80%, you're not likely to diverge from the main network unless you choose your validators poorly, but at this point I am still compelled to tell you that you could diverge from the main network, incorrectly label ledger versions as validated, and consequently lose money.

Ripple is currently in the process of developing better metrics and software to help you choose validators. Also, we want to make it easier to keep rippled updated to the latest version -- because that's also a very important part of having a smooth consensus network. With the new Amendments code, it'll be a little less likely for new features to cause disruptions to the network, but right now part of the reason we maintain full control over the validation topology is that it gives us the power to control the schedule at which new features/amendments roll out. (That way we can have people watching new features to make sure they work properly, etc.)

Share this post


Link to post
Share on other sites

I totally support Ripple's vision for maintaining control over the validation topology for purposes of scheduling new feature roll-out.  I'm also confident that absent a global catastrophe, Ripple servers will be dependable and up and running. 

The absence of a pathway for non-FI's to become part of the trusted validator network is mildly disappointing, though; couldn't network response times be elevated by more trusted CPUs? 

Share this post


Link to post
Share on other sites

Actually, let me state it a different way:  Is there a way that Ripple can introduce that would enable participant CPUs to be rewarded for donating their CPU power?  (Not validators)

I'm not suggesting a mining equivalent, but rather a tapered reward system where the response times of the network can be measured and the rewards are adjusted automatically to either increase the network computing power, or level it off.  I wouldn't need to be part of a trusted validator network - rather, the validator network could securely utilize my CPU resources for processing. 

Share this post


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

Actually, let me state it a different way:  Is there a way that Ripple can introduce that would enable participant CPUs to be rewarded for donating their CPU power?  (Not validators)

I'm not suggesting a mining equivalent, but rather a tapered reward system where the response times of the network can be measured and the rewards are adjusted automatically to either increase the network computing power, or level it off.  I wouldn't need to be part of a trusted validator network - rather, the validator network could securely utilize my CPU resources for processing. 

Ripple was at one time considering giving incentives to those who would create a validating node and verify the validator.  The system would have dispensed the equivalent of 50$ of XRP on a weekly basis to the account listed in the ripple.txt file.  I believe that the reason why this program was discontinued was due to the perception that a fork could been created if an unscrupulous party were to attempt to bribe validator operators with a greater incentive; the incentive to operate a validator should exist directly between the operator and their business whether it is for-profit or for-science.

@mDuo13 Thank you for your response!  Can you share any news regarding the status of the attesters feature in development?  Can you provide any criticism of the proposal provided within the opening post?  Your professional insight through incorporating the perspective of a member of the Ripple community who may be fearful that ledgers may fail to progress and as an employee at Ripple is invaluable to this topic.

Edited by Twarden

Share this post


Link to post
Share on other sites
Guest
5 hours ago, Hodor said:

Actually, let me state it a different way:  Is there a way that Ripple can introduce that would enable participant CPUs to be rewarded for donating their CPU power?  (Not validators)

I'm not suggesting a mining equivalent, but rather a tapered reward system where the response times of the network can be measured and the rewards are adjusted automatically to either increase the network computing power, or level it off.  I wouldn't need to be part of a trusted validator network - rather, the validator network could securely utilize my CPU resources for processing. 

Interesting idea - a distributed/virtualized validating node? I'm afraid that latency would be an issue, especially with Ripple pushing the ledger close time lower and lower. A virtualized validator might not have very good performance. (Lower ledger close times great for several reasons - I'm not the only one to wonder if they're going to aim for some point-of-sale type uses.)

 

Share this post


Link to post
Share on other sites
15 hours ago, tomxcs said:

Interesting idea - a distributed/virtualized validating node? I'm afraid that latency would be an issue, especially with Ripple pushing the ledger close time lower and lower.

Well, I guess I wasn't even thinking that specific, but rather more open-ended.  One of the features of the Ripple network that is progressive from BTC is that there is no wasteful mining eating up electricity, but then again, if Ripple wants to procure some more computing power dynamically for the distributed network, then why not have some way of harnessing it with a dynamic XRP reward system?  I would definitely be up for this.  :smile:

Share this post


Link to post
Share on other sites
6 hours ago, Hodor said:

Well, I guess I wasn't even thinking that specific, but rather more open-ended.  One of the features of the Ripple network that is progressive from BTC is that there is no wasteful mining eating up electricity, but then again, if Ripple wants to procure some more computing power dynamically for the distributed network, then why not have some way of harnessing it with a dynamic XRP reward system?  I would definitely be up for this.  :smile:

No, this is a poor idea.  Incentives for providing computing power to the validation network should be because you or your business already operates a rippled node during the course of your business or research and development.  The reason why Bitcoiners bitch and moan primarily about Ripple comes from the fact that there is no direct gain in exchange for computing power; you must be a component of the network in some form that benefits from additional security of the Ripple network for your contribution of computing power which in turn could equal profit

Please see this post here from mDuo on the official forum from a few months back which is the basis of this entire thread.  Note that the link under the second point no longer points towards the information about the incentive program I described in an earlier post; it takes you to the ripple test net page.

Quote

At present, we recommend that people trust only our 5 Ripple Labs validators that are listed in the config file by default. However, we are working hard on improving that situation in a few ways.

(1) We're collecting stats about the performance of validators that others are already running, and looking to make it easier to set up your ownvalidator.
(2) We're thinking of temporarily incentivizing people to run their own validators by paying out XRP.
(3) We're working on a graceful-upgrade path where new features to the network can be approved by the consensus process and only take effect after everyone has had time to upgrade.

We think the interim step between the present day ("only trust us") and the future that JoelKatz described will be one where we basically operate the first directory that attests to various validators, and people can manually set their UNLs based on the information in that directory (they can still make that decision any other way, if they so choose).

As far as how many servers across how many jurisdictions, that depends on how many bad actors there are who are trying to disrupt or take advantage of the consensus process. The more bad actors, the more agreement from different places you should require in order to be sure. ;)In fact, it's a direct correlation, as shown in the Consensus Whitepaper -- if you set your quorum to 80%, then more than 80% of your trusted validators would have to collude in order to approve a fraudulent transaction.

 

Edited by Twarden

Share this post


Link to post
Share on other sites

In case it wasn't obvious, Ripple decided that paying people to run validators sends the wrong message. We don't want people to run validators just because Ripple is paying them XRP -- that's not sustainable indefinitely, and it encourages people to become validators for the wrong reasons. Validators should be run by people and businesses who have a stake in the network.

The Ripple Consensus Ledger should be and will be run by its users, for its users.

Share this post


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

The Ripple Consensus Ledger should be and will be run by its users, for its users.

By its Users, For its Users = BUFU

Reminds me of FUBU

photo-9.png

Edited by cmbartley

Share this post


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

Validators should be run by people and businesses who have a stake in the network.

But running a validator (with a decent uptime) is quite expensive and a lot of people and business can't afford to run it (at least currently when doing anything Ripple related is unprofitable). 

 

Edited by T8493
bold text is mine

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