Jump to content

Recommended Posts

7 minutes ago, mDuo13 said:

 @JoelKatz this article can be a little confusing when it switches between talking about the total number of validators and the trusted validators that most of the network pays attention to.

Happy to see this recognized. When I read the article I found some of it misleading exactly due to this. More specifically, I believe the article misleads regarding the voting needed for amendments to be enabled.

Share this post


Link to post
Share on other sites

Any plan to submit the RCL consensus whitepaper and/or the Cobalt paper to a peer reviewed conference/journal?

Maybe in collaboration with some prestigious university?

Share this post


Link to post
Share on other sites
3 hours ago, tulo said:

Any plan to submit the RCL consensus whitepaper and/or the Cobalt paper to a peer reviewed conference/journal?

Maybe in collaboration with some prestigious university?

I thought that Cobalt was submitted and being peer-reviewed by Cornell University's Computer Science division??

Share this post


Link to post
Share on other sites
7 hours ago, King34Maine said:

I thought that Cobalt was submitted and being peer-reviewed by Cornell University's Computer Science division??

What gave you that impression? It is published on arxiv!

Share this post


Link to post
Share on other sites

Hopefully I've just missed something here.

In support of @JoelKatz's article and its goal of illustrating the decentralised nature of the XRP Ledger, isn't what we really need to see a map of actual UNL relationships, how they've evolved over time and the nature of transaction submissions and validations?  For example, it wouldn't support decentralisation having a balance of 150 independent validators vs 10 Ripple-run validators if all 150 populated their UNL with 10 entries consisting only of the Ripple-run validators.  (Freedom to decentralise is presumably also freedom to centralise.)  Or, each of the 150 only had one entry of a Ripple-run validator, but those Ripple-run validators always "led the pack" validating ledgers while the independent nodes continually lagged and disagreed.

Would it be fair to say the potential for decentralisation has been well elucidated and explained, but the real-world trust relationships and how they function in practice, and so therefore the actual realised level of decentralisation has not been revealed?

I'm not familiar with an API call that allows probing of a remote validators UNL, if there is one I guess this would be easy to at least map that out.  I'm also not sure how to accurately account for disagreement over time.  For example, if disagreement only happened at infrequent busy times, an overly simple metric might artificially inflate recorded agreement figures.

Given its unique properties and the subtleties that may be involved in honouring them, does a reliable way to measure decentralisation on the XRP Ledger even presently exist?

Share this post


Link to post
Share on other sites
8 hours ago, Professor Hantzen said:

Given its unique properties and the subtleties that may be involved in honouring them, does a reliable way to measure decentralisation on the XRP Ledger even presently exist?

I think it's hard for now to talk about decentralization. The UNL overlap must be 90%, so either all validators agree on a "common" UNL list, or they'll diverge. So the only way to be decentralized is that this common UNL list is agreed between different parties, and not imposed suggested by Ripple.

Or to switch to Cobalt or Stellar Consensus which allow more flexible configurations.

 

But I like how step by step it's always more and more decentralized. 

 

Share this post


Link to post
Share on other sites
8 hours ago, Professor Hantzen said:

what we really need to see a map of actual UNL relationships

https://github.com/ripple/rippled/issues/1751 (June 2016, 0 comments)

9 hours ago, Professor Hantzen said:

I'm not familiar with an API call that allows probing of a remote validators UNL

Only Stellar has asuch an API and it is not punished to lie in the responses of that API as far as I understand their consensus algorithm. XRPL doesn't even try to expose/publish UNLs, sometimes for good reasons in my opinion.

9 hours ago, Professor Hantzen said:

For example, if disagreement only happened at infrequent busy times, an overly simple metric might artificially inflate recorded agreement figures.

https://github.com/ripple/rippled/issues/2396 (February 2018, 0 comments) could help a bit there.

Share this post


Link to post
Share on other sites
Posted (edited)
17 hours ago, Sukrim said:

XRPL doesn't even try to expose/publish UNLs, sometimes for good reasons in my opinion.

Thanks for those links, glad to see this is being pursued. 

I can understand intuitively the rationale not to publish UNL's, what are some specific reasons in your opinion?  

I wonder if, given the main issue in publishing UNL's is establishing how decentralised the network is by examining the state of the topology, and not necessarily the identity of the particular parties doing the publishing, it might be possible to employ some kind of anonymising to allow exposing UNL's in a way that it is reliably known that a particular validator is publishing its UNL, but not which validator it is? 

It may be a difficult problem, but I wonder if enough tools already exist on the XRP Ledger to put this together with minimal extra effort.

Eg:

1) Somehow employ the key(s) of each validator to provide a unique anonymous ID for a given validator.
2) The validator then creates a transaction from a known public account with a memo containing its UNL, signed with the above unique ID.

If there could be some way to do 1), such that it can be proved that the public key of that validator is included in a given set of validators public keys, but not which validator it is, maybe this could work.

A threshold of agreement could be determined prior, and at regular intervals all validators presently meeting that threshold could be published on chain via a memo (or memo's) and thus invited to register their UNL anonymously in response.  Doing so before the next interval would result in "inclusion" in that intervals set of anonymised UNL topology results.

From this it would be possible to glean a set of percentages regarding the frequency in which particular nodes are included in other nodes UNL's, but in an anonymous way that is also definitive (assuming the supplied UNL's can be trusted...).

As for validators lying about their UNL, I wonder if something could be employed internally in rippled such that each time a validator changes its UNL, something deterministic is exposed to the network that can be later used for the purposes of a collective audit, again without exposing particular parties or which UNL belongs to whom.  Maybe it's not possible, but I'd hope there could be an arrangement that uses the trade-off of knowing how many validators are lying, but not which ones they are.  This could at least provide a percentage figure regarding the integrity of the UNL results.

I would suggest that if it turns out its really not possible to ensure the level of integrity of any reported UNL topology, there's little point bothering to create one.  However, it should be explained clearly by Ripple in such a case that the level of decentralisation cannot be determined.

Edited by Professor Hantzen

Share this post


Link to post
Share on other sites

×