Jump to content
WrathofKahneman

Understanding Validator relationships

Recommended Posts

When looking at the list of validators on this page: https://xrpcharts.ripple.com/#/validators,   there are three categories for validators: 1) main, 2) alt-net (Ripple's testnet) and 3) several listed as different  chains.   What do the chains mean and what is their relationship to the rest of the network?  Apologies if this is in the wrong section.  

1008355608_validators1-Copy.thumb.png.b0b1b73a5adda1f1de77fbdb8e1c874f.png

Share this post


Link to post
Share on other sites

https://developers.ripple.com/data-api.html#get-daily-validator-reports

Definition of chain:

Quote

Ledger hash chain which this validator is currently following. The value main indicates the main network and altnet indicates the XRP Test Network. Other forks are named chain.{NUMBER}, where {NUMBER} is a unique number for each fork.

I think it must be rippled validators that are found to be linked to the network - as they are found with the XRPL Network Crawler - but that are not validating the same set as either main net or altnet.. Therefor they are other forks of XRPLedger.

It is also interesting to click on the validator link, then you will see that most of them switch from one chain to the other, apparently having difficulties to stay on the same chain

Edited by jn_r

Share this post


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

What are these other forks, then?  Some of those switchng validators still manage to process a lot of TX's - whose?  Would they be valid?

They would only process if they have reached their own quorum from their own UNL. Maybe they deliberately try to create a fork, have maybe 3 other validators in their UNL doing the same thing. They would send out the agreed upon transaction set over the rippled network, but as nobody is following them, it will just be in thin air 

Share this post


Link to post
Share on other sites

Got it, so these are forked networks unrecognized by the main network (they do seem to drop a lot of TX's).  I suppose this is speculative, but these forked networks are clearly not trusted by the real UNL, and I assume they, in turn, do not trust the real UNL either (or do they to even show up?).  Can these forked networks choose to trust the real UNL at some point, and what happens if they do?

And thanks @jn_r for tolerating my ignorance :)

Share this post


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

Got it, so these are forked networks unrecognized by the main network (they do seem to drop a lot of TX's).  I suppose this is speculative, but these forked networks are clearly not trusted by the real UNL, and I assume they, in turn, do not trust the real UNL either (or do they to even show up?).  Can these forked networks choose to trust the real UNL at some point, and what happens if they do?

And thanks @jn_r for tolerating my ignorance :)

no problem @WrathofKahneman I don't know either what they exactly are and am curious/interested to find out more.

- The assumption that they do not trust the real UNL I am not sure that is correct. Maybe some of them just can't keep up with the network, but on the other hand I think they would then not propose a new transaction set, so maybe your assumption is right. 

- If the forked network would choose to trust the real UNL at some point, then they should 1) forget about their current history and then 2) start again by receiving ledgers from the UNL validators.But I haven't tried this out yet myself, would love to hear from some ripple-representative.

Share this post


Link to post
Share on other sites

×