Ripple Validator Profits?

[lonnylot 1]

Are there any direct profits to be made from running the Ripple Validator? Or do you just run them because it supports other business activities that are profitable (or out of goodwill)?

[Duke67 1,675]

No direct profit. I run the machine just because I want to help as much as I can.

[DarthTrader 277]

Is there a way to implement a profit based system? would also help to decentralize more

[tulo 2,157]

4 minutes ago, GreatValue said:

Is there a way to implement a profit based system? would also help to decentralize more

The decentraliziation is not a matter of missing validators. It is just a matter of Ripple deciding to decentralize...

[DarthTrader 277]

@tulo sorry it isn't? my fault  But what makes it decentraized?

[tulo 2,157]

2 minutes ago, GreatValue said:

@tulo sorry it isn't? my fault  But what makes it decentraized?

The UNL list of the validators. Right now 5 validators of Ripple (the only ones "running" the RCL) have in their list only the other 4 Ripple's validators, so it's a closed circle.

They should start to extend the list to other trustworthy validators (Gatehub, MIT,...) .

[JoelKatz 7,441]

While you don't make any money directly from running a validator, you do get a say in how the Ripple network evolves. Changes to the protocol are voted on by validators.

2 minutes ago, tulo said:

They should start to extend the list to other trustworthy validators (Gatehub, MIT,...) .

Unfortunately, you can't really start to extend it. You either extend it or you don't. All trusted validators run by one party works perfectly fine as long as that party remains trustworthy. And a dozen parties who are unlikely to collude works perfectly fine. There is really nothing safe in the middle.

[tulo 2,157]

1 minute ago, JoelKatz said:

While you don't make any money directly from running a validator, you do get a say in how the Ripple network evolves. Changes to the protocol are voted on by validators.

Unfortunately, you can't really start to extend it. You either extend it or you don't. All trusted validators run by one party works perfectly fine as long as that party remains trustworthy. And a dozen parties who are unlikely to collude works perfectly fine. There is really nothing safe in the middle.

So when and how the UNL will be extended? How did you imagine the decentralization process? How is the transition from centralized to decentralized?

What's wrong in having 8 validators (5 Ripple + MIT + Gatehub + attokyo)? 3 external colluding shouldn't achieve a separate consensus, but can put the veto and avoid the ledger to advance. I think it is a good start in case Ripple does strange stuffs....

[JoelKatz 7,441]

5 hours ago, tulo said:

What's wrong in having 8 validators (5 Ripple + MIT + Gatehub + attokyo)? 3 external colluding shouldn't achieve a separate consensus, but can put the veto and avoid the ledger to advance. I think it is a good start in case Ripple does strange stuffs....

You need a quorum of 7 to make that work with total security, which could provide poor availability. 6 is barely acceptable, but would be less secure against harmful forks. 3 of 5 is a special case (because the set of possible overlaps is limited and we can test each one). As the numbers get larger, you don't have special cases any more and you need 80%.

[tulo 2,157]

6 minutes ago, JoelKatz said:

You need a quorum of 7 to make that work with total security, which could provide poor availability. 6 is barely acceptable, but would be less secure against harmful forks. 3 of 5 is a special case (because the set of possible overlaps is limited and we can test each one). As the numbers get larger, you don't have special cases any more and you need 80%.

So what's the plan? Never decentralize? Wait for 200 validators to pop and make a huge network? I was expecting that adding a few trusted validators was the natural way of handling it.

MIT validated 99.986% of transactions, Gatehub 99.275%, attokyo 99.986%. They come from US, japan and EU. A company, an organization and a university. I don't see any better candidates. If Ripple will be always picky with the UNL then we'll never have the decentralization. And the biggest risk I see is a stop of the ledger advancement, not anything "critical".

[Guest dfault123]

10 hours ago, tulo said:

So what's the plan? Never decentralize? Wait for 200 validators to pop and make a huge network? I was expecting that adding a few trusted validators was the natural way of handling it.

MIT validated 99.986% of transactions, Gatehub 99.275%, attokyo 99.986%. They come from US, japan and EU. A company, an organization and a university. I don't see any better candidates. If Ripple will be always picky with the UNL then we'll never have the decentralization. And the biggest risk I see is a stop of the ledger advancement, not anything "critical".

I know the things I'm about to say are speculation, but that's all we got. Issue with all this is ripple is very likely unable to tell us, NDA perhaps, if something regarding validators is going on behind the scenes. I know they were aiming to decentralize RCL by around Q3-Q4/2016 (If I recall correctly). Just have to wait and see what happens.

What you say makes sense though, which is why I think ripple isn't telling us everything about the situation.

Edited April 11, 2017 by dfault123

[Mercury 5,040]

I wonder if this is something the Steering Committee is engaged in and advising on. If so they might be waiting for some heavy banks to be ready to rock n' roll

[Xi195 1,307]

The "Dynamic UNL Lite" feature which was implemented in rippled version 0.60.0 seems like a feature that sets the groundwork for dealing with decentralization. As a non-techie my understanding of it is very limited though (I hardly understand the UNL and how it is managed in general).

 @JoelKatz , would you mind explaining how this feature works in layman's terms?

For those who curious here is an explanation on GitHub: https://github.com/ripple/rippled/pull/1842

[Guest dfault123]

@Xi195, I liked this explanation:

Quote

Dynamic UNL Lite

At the core of RCL is the consensus process. Through the consensus process, validating nodes agree on a specific subset of the candidate transactions to be considered for the next ledger. Consensus is an iterative process in which nodes relay proposals, or sets of candidate transactions. Nodes communicate and update proposals until a supermajority of peers agree on the same set of candidate transactions.

During consensus, each node evaluates proposals from a specific set of peers, called chosen validators. Chosen validators represent a subset of the network which, when taken collectively, is “trusted” not to collude in an attempt to defraud the node evaluating the proposals. This definition of “trust” does not require that each individual chosen validator is trusted. Rather, validators are chosen based on the expectation they will not collude in a coordinated effort to falsify data relayed to the network.

The rippled version 0.60.0 release introduces new Dynamic UNL configuration options, which allow rippled to update its set of trusted validators without reconfiguring and restarting. Instead of specifying a static list of trusted validators in the config or validators file, you can configure a trusted publisher key and a URI where the publisher serves signed lists of validators. rippled will regularly query the configured URIs for the latest recommended list of validators from the trusted publishers. Configuring the validation quorum is no longer required, as rippled will automatically update its quorum based on its current trusted validator set.

Dynamic UNL Lite is a progressive step towards fully automated dynamic UNLs, to which each client of the Ripple network determines its UNL through policies, rather than trusting a pre-provided list of validators.

 

Source: https://ripple.com/dev-blog/rippled-version-0-60-0/

[corak 1,009]

In the "fully dynamic" scenario, how does the network reach a consensus about whats the "correct" policy for choosing who the validators are? if there isn't one, couldn't the network theoretically fork transactions-wise? (my validators have accepted a certain subset of transactions, yours have accepted another)?

Edited April 14, 2017 by corak
clarify