Jump to content
Sign in to follow this  
NightJanitor

How It Works: Consent & Validity (working title)

Recommended Posts

This is - as one of my old friends is fond of saying, "the good talk, that I love" - and needs some discourse, explanation, and translation to various dialects/fields, plus more input.

[To do:  Fetch posts from Lucky and myself, in this thread concerning amendments, validators, and voting.  If you know how to do it, please do...]

[Sincere thanks to Kpuff for starting this off by "going there" and bringing up one of the issues that a lot of people say is kept swept under a rug.]

["Open, Sesame!"]

Edited by NightJanitor

Share this post


Link to post
Share on other sites

https://www.distributedagreement.com/2018/06/19/censorship-and-censorship-resistance/

Included by reference, D. Schwartz on Censorship Resistance at a ledger/transaction level, but not necessarily (?) with respect to amendments/validators/voting.

Teach me, please, anyone who knows.  Assume I'm an idiot, but also that I'm "willing to learn!" :)

"If you can't explain it to an idiot, I can't be sure you understand it." -D. Feynman (may have said it)

Edited by NightJanitor

Share this post


Link to post
Share on other sites

@NightJanitor I believe the thread you referenced is already a little here and there. There are questions about specific escrow, entities, etc. I think it would be better to remove the specific instances and just generalize the discussion. Please correct me if I'm wrong.

You want to understand how an individual who runs a validator could propose an amendment that could change an escrow? 

 

Share this post


Link to post
Share on other sites

I'm not exactly sure what either the general or the specific Q "is" (or ought to be), yet... So, pasting in the conversational genesis of this little tangent - and will try to work it back around to questions.

------------------------------------------

Kpuff:  I brought up the amendment rule in which the 55 or so billion can be taken out of their hands if we feel they are not handling it well. They kept bringing up the centralized argument so yeah I went there. If I stated any wrong information please correct me thanks.

NightJanitor:  Cool.  Go ahead and post the name of your validator node that'll be proposing that amendment so that all the sane validators can permanently remove it from their UNL's.  The amendments people try to propose will be very revealing about the values of those proposing them.  (I'd imagine a lot of people will flame out in public doing that stuff!)  "Amendment 99:  Bob said or did something that I don't like and I'm so mad that I want a majority to censor Bob's transactions on the XRPL.  Who's with me? ---Signed, Alice"  Watching the trust graph adjust would be rather interesting.  This is what all the people who understand "slippery slope" love about the decentralized allocation of UNL trust.  Even in the case where, say, a nation-state actor was running a validator, there's still some rather robust resiliency, in that any entity can be a validator and trust is adjustable.

Lucky:  And by the way, there is no reason to remove a validator from the UNL because you don't agree with it's vote. The amendment will only pass with 80% support, no UNL's need to be edited in the voting process. From a decentralization perspective, it's recommended to include a broad diversity of voices in your network, and accept that fact that you won't reach 100% agreement on everything.

NightJanitor:  NO reason?  Are you sure?  I'm not.  How's that 80% calculated?  (Another approach:  How's the 100%, of which the 80% is a subset, calculated?)  I have gedankens around this - and we should probably break this into another thread - but it's almost dawn and I need sleep - I'll let you explain.

Lucky:  Yes I am sure. https://developers.ripple.com/amendments.html  The reason you explicitly trust validators is that you trust that they will apply the network rules of the current version. The 80% threshold for applying new features is also a network rule of the current version, so a trustworthy node will conform to the outcome of the vote, whether it agrees to the amendment itself or not.

NightJanitor:  Sure --- but let's define our terms, for clarity.  Correct or not correct:  The 80% threshold for an amendment to pass - in your local reality - is for it to sustain 80% YES support of the validator nodes which are in your UNL and which you trust.  Is that statemet true or false?  If not, why not?  If so, what follows?

Lucky:  Well yes, you have a point there, and it also goes the other way:  the 20% that disagree with an amendment could continue with their own UNL.  But they don't even need the amendment voting process for that: anyone can fire up a new network today, with whatever network rules and whatever software version they please.  Yet the power of the amendment process is that it enables coming to an agreement about new features, while keeping everyone on board. Instead of fragmenting into smaller and smaller fractions of people that 100% agree with each other, but can't transact with other fractions because of compatibility issues. As we now see in the Bitcoin network.  But for this to work, voting should really reflect the diversity of opinions in the ecosystem. And that means participants of the network should not tamper with the voting process by silencing opinions by removing validators that have expressed an unfavorable opinion. That's like blocking people on twitter that express opinions you don't agree with. You end up in a bubble where everybody agrees with you, but that is alienated from the reality outside your bubble. In a sound democracy, you keep dissonant voices on board, to make sure that whatever you decide upon, has the maximum community support. Maximum community support is of course ultra important for a global payment system, where you want to be able to transact with the maximum number of people.  I believe they've really hit the ball with the amendment process, which allows smooth upgrades without drama. The planned Cobalt upgrade makes this process even more robust.

--------------------------

The bolded parts are the jumping off point for me...  You'll pardon me (and I'll pardon all, from tolerating me) while I do some more thinking (and celebrate Christmas).

--------------------------

Some of the questions I've seen at confs/social/etc lately are of the plain language forms:  How is the 100% of "voters" determined?  Are all votes "equal"?  Is there a weighted distribution based upon nodes who trust certain validator(s)?  Who counts the votes?  When do the polls close, exactly?  Is anyone "checking ID" / "who can vote"?  Does changing your UNL during a vote have any effect upon the calculations of the "results"?  What is a "trusted validator"?  How does one become "trusted""  (et cetera - and it may be of use to compile these types of questions, if only to distill them... though a completely new batch of commonly asked questions which need readymade answers will arrive, as soon as Cobalt does.....

Speaking of which, here's Cobalt, which lucky mentioned as making the amendment process "more robust":  https://arxiv.org/pdf/1802.07240.pdf

And here's an excerpt:  "The UNLs give structure to the network and allow a layered notion of trust, where a node that is present in more UNLs is implicitly considered more trustworthy and is more influential."

This is what I had in mind, maybe - though it was more of a picture - when saying I'd be super quick to cut any validator supporting a "bad" amendment from my validator node's UNL -  I believe I am dancing around the difference between the "quorum" method (which is now live) and then Cobalt's "subset" method, which is not now live... And, additionally, global vs local concerns.... I am not sure what my questions are, yet - but I do, in fact, believe there would - under Cobalt - be "a reason to actively distrust a validator by removing it from my UNL" *for supporting* an amendment with which I disagreed (to deprive it of "influence" - and this would be almost an abstracted form of voting, in itself - since "influence" is all that seems to "count"?) --- and...  I can see strengths and weaknesses for this that I suppose depend upon how it gets implemented.

It is quite possible that I am just visualizing/understanding Cobalt ("again, for the first time!") - and have somehow managed to confuse myself, again.  but, I don't know...

Has any of the peer review for Cobalt come in, yet?  That might be helpful..  Or... like... a version of "Cobalt Written In Something More Closely Resembling Plain English"?

I'd like to have more eyes on it - preferably, from a variety of backgrounds besides just computer science.

Anyway, I'll marinate on this stuff a bit... while waiting on Santa.

Share this post


Link to post
Share on other sites

I think we need/want a precise, granular account of what constitutes voting - timelines, credentials, propagation, how are they timed, what happens in the interstices of acceptance even if all these things are perpetual, etc.  Eventually someone on the internet will scheme about convincing as many nodes as possible to do something self-serving that is unethical.  The downside of consensus is that no one vote can stop something malicious from happening, either.    (Or can it?  Is there one, last vote that tips the %80 needed?  When? Where?) 

I'm sure Ripple, given their team, has thought through this and more but I would like to understand, too.  I'm not a computer scientist, though.  Hope this post in the spirit of the thread :)

 

Share this post


Link to post
Share on other sites
On 12/23/2018 at 1:52 PM, WrathofKahneman said:

I think we need/want a precise, granular account of what constitutes voting - timelines, credentials, propagation, how are they timed, what happens in the interstices of acceptance even if all these things are perpetual, etc.  Eventually someone on the internet will scheme about convincing as many nodes as possible to do something self-serving that is unethical.  The downside of consensus is that no one vote can stop something malicious from happening, either.    (Or can it?  Is there one, last vote that tips the %80 needed?  When? Where?) 

I'm sure Ripple, given their team, has thought through this and more but I would like to understand, too.  I'm not a computer scientist, though.  Hope this post in the spirit of the thread :)

 

Thanks for translating my braindump. :)

Yes, "spirit of inquiry" is exactly the thing.

I can't follow some of this stuff - or at the least, I'm not certain I follow some of it - and that's partially a function of the complexity of it, but it's also a function of its opacity.

I think what I want is more plain language;  here, for example, is a pull request by NikB (seems to be a great guy;  I don't know him, other than through his code/comments):

https://github.com/ripple/rippled/pull/2811#issuecomment-448441917

There's a very interesting, almost magically clarifying, thing that happens when Schurr steps into the conversation to do a "Wait, wait! Let's translate!" - need more of that...

Now, I'm an idiot, so, who cares if I understand what's going on here, but I do see a rational incentive to want as many people developing on the ledger as possible and that "spark" of curiosity can only be turned into a flame if some of this stuff is translated out into plain language.  The fact that this little act of translation works for developers seems to indicate to me that it could also be helpful for the community, at large, not only in correcting/defending understandings that already exist, but also building more.

Share this post


Link to post
Share on other sites

"Validators" = "Sequencers"

That takes care of like nine of those first-order terminology confusions/questions, above - not to mention making all that time I spent listening to the below music worth it.

God bless the Musicians and the Dreamers of the Dream...  (Not least for not making me feel so damned old!)

https://www.youtube.com/watch?v=PZfi6G7vOuE&list=PLNu6lp2KBC7KKu5bumjj7ANFPrfx9CTFL&index=10

Good change!

Share this post


Link to post
Share on other sites
Sign in to follow this  

×