Jump to content
Sukrim

validator1.worldlink-us.com makes it to Ripple's recommended validator list

Recommended Posts

Guest
1 hour ago, Amigo said:

I don't know what discovery of consensus fails you mean btw

When I read the Cobalt doco I believe I recall them saying that the theoretical consensus failure is more possible than previously thought.

These are old fart, bad memory, half guesses, but I think I recall it was something like previously it was thought that 60% good actors ensured consensus,  but in fact it actually has to be like 85% or some such.  I'm sure someone will point out my inadequacy here, and have the real figures...  but the essence is that reliable consensus is not quite as robust as was previously thought.  Still way better than other systems and very robust, but not as good as imagined.

My point to all this is that perhaps in the light of this revelation Ripple are slowing the decentralisation until after Cobalt.  I have no basis for this just a vague guess.

Its purely speculative, and I could be waay wrong, and I only half think it might be the case.  Feel free to rip me a new one for being so stooopid.  :) 

Edit:.  Just adding that Cobalt apparently does increase the robustness of the consensus algorithm needing far less good actors to still achieve reliable consensus.

Edited by Guest

Share this post


Link to post
Share on other sites
9 hours ago, Tinyaccount said:

When I read the Cobalt doco I believe I recall them saying that the theoretical consensus failure is more possible than previously thought.

These are old fart, bad memory, half guesses, but I think I recall it was something like previously it was thought that 60% good actors ensured consensus,  but in fact it actually has to be like 85% or some such.  I'm sure someone will point out my inadequacy here, and have the real figures...  but the essence is that reliable consensus is not quite as robust as was previously thought.  Still way better than other systems and very robust, but not as good as imagined.

My point to all this is that perhaps in the light of this revelation Ripple are slowing the decentralisation until after Cobalt.  I have no basis for this just a vague guess.

Its purely speculative, and I could be waay wrong, and I only half think it might be the case.  Feel free to rip me a new one for being so stooopid.  :) 

Edit:.  Just adding that Cobalt apparently does increase the robustness of the consensus algorithm needing far less good actors to still achieve reliable consensus.

Some technical disambiguation:

Two properties of the Ripple Consensus Protocol Algorithm are at play for what you are thinking about: correctness and agreement.

The original RCPA paper[1] defines correctness as:

Quote

In order to achieve correctness, given a maximal amount of Byzantine failures, it must be shown that it is impossible for a fraudulent transaction to be confirmed during consensus, unless the number of faulty nodes exceeds that tolerance.

The original RCPA paper defines agreement as:

Quote

To satisfy the agreement requirement, it must be shown that all nonfaulty nodes reach consensus on the same set of transactions, regardless of their UNLs

 

Correctness means no failure. Invalid transactions (aka double-spends) aren't validated.

Agreement means no divergence. Multiple, mutually exclusive yet internally consistent consensuses (aka forks) don't emerge.

 

Finally, it is stated that:

Quote

The final round of consensus requires a minimum percentage of 80% of a server’s UNL agreeing on a transaction. All transactions that meet this requirement are applied to the ledger, and that ledger is closed, becoming the new last-closed ledger.

The original whitepaper concluded that using a 80% consensus threshold:

  • With more than (n-1)/5 non faulty validators in any server's UNL, forward progress is made and strong correctness is achieved.
  • With between (n-1)/5 included and (4n+1)/5 excluded non faulty validators in any server's UNL, forward progress can stall but weak correctness is still achieved (no consensus, but no failure either. As David Schwartz puts it, "failure to agree is agreement to defer").
  • With more than(4n+1)/5 included faulty validators in any server's UNL, fraudulent transactions might be validated if and only if, in addition to being faulty, the trusted nodes act as a cartel to push the same transactions. Forward progress would be achieved incorrectly as the result of a Sybil Attack orchestrated within the UNL.
  • With a number of shared validators in any two servers' UNL being at least 20% the size of the largest UNL of either one of the two, said two servers can't fork away from each other. Let's call this property connectivity.

 

In August of 2015, it was suggested[2] by independent parties that connectivity requirements were in the vicinity of 40% instead of the previously thought 20%. Then in February of 2018, it was shown[3] by Ripple that it is, in fact, at least 90%. That is a very far cry from the original number and an enormous constraint for scaling on an heterogeneous and asynchronous network with imperfect trust.

The replacement for RCPA is Cobalt[4]. This successor to the original algorithm requires at least 60% of overlap between any two server's UNL, which more manageable.

 

Side notes:

1/ The consensus threshold and the connectivity requirement are inversely correlated[5]. You can decrease the the threshold and get quicker consensus, but it requires higher connectivity. Conversely, you can increase the threshold if you want to afford more flexibility in connectivity, but the price is slower consensus. The extremities of that spectrum are obvious: a single trusted party for a rigid but super fast network, and many trusted parties for a flexible but slow network. The 80% threshold strikes a good balance between the two desirable properties of speed and flexibility[5] (free Alan Turin Award for anyone who breaks the shackles this inverse correlation is).

 

2/ Vitalik Buterin was impressed with what Ripple had already accomplished in 2013[6], but as he correctly noted in February of that year, a mathematical proof of the algorithm had yet to be provided. Jed McCaleb had stated 6 months before[7] that one was coming. It took two years[8], and the proof was incorrect. 3 years and a half later[9], the mathematical foundations of the RCPA were finally proven.

 

References:

1. The Ripple Protocol Consensus Algorithm.

2. Trust and Trustworthy Computing.

3. Analysis of the XRP Ledger Consensus Protocol .

4. Cobalt: BFT Governance in Open Networks.

5. Why does Ripple's consensus process have a 80% threshold ? (see answers by David Schwartz)

6. Introducing Ripple, a detailed look at the cryptocurrency's new kid on the block.

7. Ripple Wiki > Consensus. Revision as of 17:30, 12 July 2012 by Jed.

8. Reference 1 was released on August 28, 2014.

9. Reference 3 was released on February 2, 2018.

Edited by F6FNU
Typo and rephrasing

Share this post


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

Some technical disambiguation:

Understatement of the year right there!

Thank you very much for your excellent post.  After seeing so much crap in this forum of late,  it is a refreshing blast of fresh air to read your well constructed and comprehensive contribution.

So...  as always has been the case,  there is reason for Ripple to want to be sure that only good actors get on the UNL.  However in the light of the newly discovered lower threshold for consensus issues, they may be inclined to go slow on decentralisation until after Cobalt is live.

As against that, there is possibly some pressure from the SEC to decentralise as soon as possible.  Therefore the tightrope they might be trying to walk is perhaps to decentralise via known good commercial and organisational entities in the first instance.

To some extent I suppose not much has changed....  at no point would they ever have wanted to decentralise the UNL to anyone other than very reliable parties.  Interesting times....   

Share this post


Link to post
Share on other sites

@Tinyaccount , I think you might have conflated two ideas:

  1. The required percentage of "good actors" in a given server's UNL.
    If your server's UNL has >X% faulty nodes, they can stop your server from declaring consensus. If it has >Y% faulty nodes, they can make your server think fraudulent transactions have been confirmed. I don't remember offhand what numbers X and Y are, but I think they were something like 20% faulty stops network progress and 80% faulty is needed to confirm fraudulent transactions.
  2. The required amount of overlap between different servers' UNLs.
    If your chosen UNL has  <Z% overlap with another server's UNL, then it's possible your servers may come to different conclusions as to what has been "validated". Originally, it was believed that Z was 40%, but that proof did not follow the academic standard of assuming that all network messages may be arbitrarily delayed or dropped as if by a malicious network operator. The recent research paper proved that Z is ~90% given this assumption.

It is difficult to know how many servers will be faulty (which includes both malicious and buggy behavior) but obviously everyone hopes there are no faulty validators in their UNL at any given time. Of course, having a larger list means that there's more chance that one or two are faulty but also decreases the impact of that happening since any given validator represents a smaller percent.

Cobalt's advantages are primarily related to the required overlap percentage (which it reduces from ~90% to ~60%), not the good/faulty node requirements. Plus it has some other advantages like simplifying the calculations on how much one's UNL overlaps with another because you would no longer have to worry about who's on your UNLs' UNLs, and so on.

But as long as people have configured their servers to follow the validator list which is published at vl.ripple.com, their overlap percentage will be 100%—everyone has the exact same UNL.

 

 

Share this post


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

 

@Tinyaccount , I think you might have conflated two ideas

 

Ah, thanks so much for setting me straight there.

So my basic idea above that you guys might have an incentive to be going slow on decentralisation doesn't seem to hold water.

The big lowering of a safe UNL overlap threshold that Cobalt brings doesn't seem to bias Ripple against decentralising the UNL since it's not the content quality required but the overlap threshold that's mainly being improved.

Thanks again for being so informative here on the forum.  I wish you guys every success,  (but must admit that is not a wholly unselfish sentiment....   :) )

Share this post


Link to post
Share on other sites

Another one - flagshipsolutiongroup.com:

UNL at https://vl.ripple.com:

01 - nHUBGitjsiaiMJBWKYsJBHU2shmYt9m29hRqoh8AS5bSAjXoHmdd => ripple.com
02 - nHUpwrafS45zmi6eT72XS5ijpkW5JwfL5mLdPhEibrqUvtRcMAjU => ripple.com
03 - nHUgoJvpqXZMZwxh8ZoFseFJEVF8ryup9r2mFYchX7ftMdNn3jLT => ripple.com
04 - nHUXh1ELizQ5QLLqtNaVEbbbfMdq3wMkh14aJo5xi83xzzaatWWP => ripple.com
05 - nHBtzeujejMTAWCymPjcaQUjLgxnfxDGTGoZnP3PvHRkR24hVgjw => ripple.com
06 - nHBvriTnYGxP8ix3HfWo2GTFFo2zuxNXyRh3U8F9LvVZd718hhxF => ripple.com
07 - nHULGMbQHyXe92wtnxA1X9TEp26qPiRfwfTv5MskD1yMro7bQ2df => ripple.com
08 - nHUKp8XUkaFN6GzQ3o4qTE1w9aAD5uFjZ8vDt6pwjBsTFRq5FWEb => ripple.com
09 - nHBtDzdRDykxiuv7uSMPTcGexNm879RUUz5GW4h1qgjbtyvWZ1LE => ripple.com
10 - nHUzum747yqip3HWSgzSNHNMjmLUqhroNVWidSRTREswEVhKNQEM => ripple.com
11 - nHUon2tpyJEHHYGmxqeGu37cvPYHzrMtUNQFVdCgGNvEkjmCpTqK => ripple.com
12 - nHU2Y1mLGDvTbc2dpvpkQ16qdeTKv2aJwGJHFySSB9U3jkTmj4CA => ripple.com
13 - nHDDasc9BHNB99PW8KUduS8Phqg8NPUmjufzMU6HGGDMUH2xNpPh => ripple.com
14 - nHUUrjuEMtvzzTsiW2xKinUt7Jd83QFqYgfy3Feb7Hq1EJyoxoSz => ripple.com
15 - nHB29c3ohq7KDtecLSLRrTV9k9Z3rLgmo1v8uuNmEEHxhTqfaQwo => ripple.com
16 - nHUkp7WhouVMobBUKGrV5FNqjsdD9zKP5jpGnnLLnYxUQSGAwrZ6 => validator1.worldlink-us.com
17 - nHU95JxeaHJoSdpE7R49Mxp4611Yk5yL9SGEc12UDJLr4oEUN4NT => flagshipsolutionsgroup.com

 

Share this post


Link to post
Share on other sites
1 minute ago, nikb said:

Can you elaborate?

Just expected more pomp and circumstance. 

Sukrim's points about it being very opaque as well make it a bit disappointing.

I'm also a bit disappointed at the lack of notoriety that the first validator has... and now the second mentioned above.

It feels like at this rate we will end up seeing validators run by data-centers, since they're the only ones with the technical know-how and care to do so.

Share this post


Link to post
Share on other sites

I hear you re: pomp and circumstance, but pomp and circumstance can get in the way sometimes. We just started the journey; let’s wait until we get to the destination. Then we can discuss some of the points Sukrim made—which come from a good place.

As for the criteria, I think that Ripple ought to publish a blog post explaining them, for all to know and see. 

Share this post


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

We just started the journey; let’s wait until we get to the destination. Then we can discuss some of the points Sukrim made

Thanks Nik for being part of the conversation.  I for one, really appreciate how employees are so helpful on here.  

But I might disagree a bit with your idea ‘let’s wait till we are there before discussing’ (paraphrasing)....  I think better to discuss before travelling.  

One seriously important point about the UNL is geographic distribution.  Can you say anything about the current and future state of distribution geographically (and politically)?

Another is the problematic one of obligations.  As Sukrim says it would be best if non-beholden entities were involved.  

I know you are busy but I’m sure many would be interested in any info you could share.  Again,  thanks guys for being so helpful.  

Share this post


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

I’ve said all I want to and can say at this time.

That’s perfectly understandable Nik.  Thanks very much for even just advising that you can’t.  :) 

I’m confident in the team at Ripple...  I’m sure you guys are doing the smart thing and the best thing for the XRP ecosystem. Thanks for your work.  

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