Jump to content

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

Recommended Posts

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 Tinyaccount

Share this post

Link to post
Share on other sites
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
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
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
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...