Jump to content
yxxyun

Why Checks Amendment haven't been enabled after a year?

Recommended Posts

It's clear that Ripple is not supporting IOUs on XRPL. So I'm fine with their choice of "vetoing" the check amendment. And I agree with @dik ... we can always remove Ripple's validators from UNL if we don't agree with their policies.

 

Share this post


Link to post
Share on other sites
On 4/7/2019 at 2:49 AM, Sukrim said:

(I assume that validators actually send votes/vetos, not imply that a missing vote means "yes"?).

To my understanding, validators only send "yes" votes, so a missing vote means "no."

 

On 4/7/2019 at 12:30 AM, Sukrim said:

Isn't it simply crazy that probably most validators out there (that just aren't in the Ripple recommended UNL) vote in favor of SHAmapv2?!

That's not been true for a few versions now. The SHAMapV2 amendment is commented out because of this (same w/ OwnerPaysFee and Tickets).

 

We've had numerous discussions within Ripple on how we could improve the amendment voting process, but it's a more challenging problem than most people initially think.

  • If you change the default to "no", then even minor fixes probably won't get enabled without a lot of collective effort. Validator operators might be more active than gateway operators, who are staggeringly nonresponsive regarding new features¹, but it's still a big ask to get everyone to go in and manually add "fix1XYZ" to their configs and restart every time there's a release with fixes to transaction processing.
  • If you add an "abstain" option (either explicit or treating non-votes as abstentions) then you have to figure out how that affects the necessary quorum for a majority. If abstentions are subtracted from the necessary total, then it could take very few explicit votes to get a majority, which makes voting "abstain" functionally very close to voting "yes". But if the necessary total doesn't change with abstentions, then voting "abstain" is identical to voting "no".

The current system works very well as long as all amendments in the code that validators are running are fully implemented and sane. (Historically, Ripple hasn't been great about this, as evidenced by SHAMapV2. In the time since adding more external validators to the list, we're being much more careful about it.) Even if validators update without thinking, the two-week approval process provides a safeguard for validators to see, investigate, and potentially vote against new amendments they're not ready for. On top of that, going forward, Ripple aims to publish information earlier in the process of developing new amendments, so what happened with Checks won't be the norm.

I do agree that "veto" is not really the right word for the setting in the config file, when it really means "vote no". If we do an update to the config file format, I'll push to change it to something a bit more intuitive.

 

¹ For example, when DefaultRipple got added, there was at least one gateway who never enabled it despite continuing to operate for quite a while, even after being contacted several times. Because of the way the NoRipple settings worked out, their legacy customers were still able to send and receive IOUs as normal, but new customers couldn't send to other new customers because the gateway was enabling NoRipple by default on new trust lines.

Share this post


Link to post
Share on other sites

You could require an explicit yes/no vote on all votable amendments before a server can validate ledgers instead of defaulting to anything (yes/no/abstain). That way "updating without thinking" cannot happen, as the server simply won't start until it knows explicitly the votes on fees, reserves and amendments that its operator wants to cast. Explicit is better than implicit!

What's also really bad by the way is the bleeding of JIRA ticket number into amendment names, especially considering that these tickets are private and their contents are not published. "fix1368" might be a useful name if I can look it up on https://ripplelabs.atlassian.net/, but for anyone outside Ripple that name is just random. It got a bit better lately, but even the quite recent version 1.2.0 contains the "fix1578" amendment.

(I guess you wanted to link to something else? Probably https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/Feature.cpp)

Share this post


Link to post
Share on other sites
35 minutes ago, Sukrim said:

You could require an explicit yes/no vote on all votable amendments before a server can validate ledgers instead of defaulting to anything (yes/no/abstain). That way "updating without thinking" cannot happen, as the server simply won't start until it knows explicitly the votes on fees, reserves and amendments that its operator wants to cast. Explicit is better than implicit!

I respect you and give a lot of weight to your opinions/positions because of that. I was a big fan of an “abstain” mechanism and argued in favor of adding it. I was, after talking to my colleagues, convinced that it only complicates things and offers no benefits. I genuinely think adding such a thing is a bad idea.

The explicit requirement is interesting, but one that may or may not fly with validator operators.

It’s a UX nightmare too—there is no UI here; just a command to update a package (or a set of commands to compile from source). Would the server just error out and refuse to start until admins manually edited a config file? This would make unattended automatic updates impossible and would lengthen the upgrade cycle when we should be looking to shorten it.

 

37 minutes ago, Sukrim said:

What's also really bad by the way is the bleeding of JIRA ticket number into amendment names, especially considering that these tickets are private and their contents are not published. "fix1368" might be a useful name if I can look it up on https://ripplelabs.atlassian.net/, but for anyone outside Ripple that name is just random. It got a bit better lately, but even the quite recent version 1.2.0 contains the "fix1578" amendment.

Agreed 100% and that’s already being phased out; see https://github.com/ripple/rippled/pull/2873 for example. 

We had already planned to do this anyways because referencing JIRA tickets is unhelpful if the JIRA is private. Once the community spoke up and made it clear that they wanted improved naming, we bumped up the priority of this. 

Share this post


Link to post
Share on other sites
12 minutes ago, nikb said:

This would make unattended automatic updates impossible and would lengthen the upgrade cycle when we should be looking to shorten it.

Validators should never automatically pull updates! That's a recipe for disaster, because whoever controls the place that offers these updates would control the whole system. A compromised repository at https://mirrors.ripple.com/ could mean major efforts including coordinated ledger rollbacks would be necessary if validator operators blindly update from it. https://developers.ripple.com/update-rippled-automatically-on-centos-rhel.html already mentions the possiblity of outages as well, I don't agree with the recommendation for automatic upgrades there, especially for validators.

13 minutes ago, nikb said:

Would the server just error out and refuse to start until admins manually edited a config file?

Yes, starting with e.g. 1.3.0. Since updates should happen manually anyways, it would be easy to display something already when updating/installing the package and/or write an error message to the log if amendment votes are missing. Validator operators on Ripple's UNL are in a shared Slack channel anyways, so you could also inform them, other ones would just need to read the patch notes I guess.

I imagine to simulate the existing behavior it could also be possible to offer "agree to everything except..." (and maybe "disagree with everything except..."?) options that allow for more automation. I would not like to see them implemented, but it could be argued that the first one is already the current behavior and it should be possible to keep it, in case someone wants to experiment or really wants everything enabled asap without even knowing what it is, as long as it is supported by rippled.

Share this post


Link to post
Share on other sites
31 minutes ago, Sukrim said:

Validators should never automatically pull updates! That's a recipe for disaster, because whoever controls the place that offers these updates would control the whole system.

I agree with you: validators should not automatically pull updates. But an unattended update isn’t always automatic.

Share this post


Link to post
Share on other sites

Yes, but in the case of switching to versions that contain new amendments, these should be reviewed manually anyways before the update to know if they (currently) should be "vetoed" (voted "no") or not. IMHO it is part of the responsibility of operating a validator to vote on these things (including fees and reserves by the way), so making people choose instead of silently assuming consent might be a good compromise to offering "abstain" votes and more complicated schemes around that.

Share this post


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

Yes, but in the case of switching to versions that contain new amendments, these should be reviewed manually anyways before the update to know if they (currently) should be "vetoed" (voted "no") or not. IMHO it is part of the responsibility of operating a validator to vote on these things (including fees and reserves by the way), so making people choose instead of silently assuming consent might be a good compromise to offering "abstain" votes and more complicated schemes around that.

I think that validator operators do make an explicit choice: to upgrade or not to upgrade.

If I choose to install 1.3 (when it becomes available) isn’t that me explicitly making a choice? I can make further explicit choices: to opt to veto amendments introduced in 1.3.

Conversely, if I choose to remain on 1.2, isn’t that me explicitly making a choice too? I can, again, make further explicit choices: to support amendments that my server doesn’t know about (and there are reasons I may want to do that).

Share this post


Link to post
Share on other sites
23 minutes ago, nikb said:

If I choose to install 1.3 (when it becomes available) isn’t that me explicitly making a choice?

About the server version, yes. About the amendments contained in that version... well, that's a bit more complicated. In theory you can also choose which features are enabled in your web browser, in practice you probably will go with whatever your browser vendor sets as default initially and only deviate if you absolutely have to (e.g. to enable beta features or to allow a connection that the browser sees as insecure because it doesn't know the CA).

If you're already updating consciously anyways, I don't see any harm in also asking the server operator for things (like votes) that the server software simply can not know or assume to know about the owner's intent. One operator might update because she heard that the new version has better performance, another one might feel passionate about a different feature and someone else just wants to run the latest and greatest. Choosing a server software version shouldn't mean that this implies any type of vote for/against any amendment.

A similar topic by the way are fee and reserve votes which are also set to default "recommended" values in https://github.com/ripple/rippled/blob/develop/src/ripple/app/misc/FeeVote.h with no explanation how these recommendations were chosen or when/how/if they might change. I was arguing for higher reserves already a while back when the price of XRP was even higher, what would be necessary to review and merge a change to these recommended default values for 1.3.0?

Share this post


Link to post
Share on other sites

Here's a thought that just crossed my mind, I can't imagine it has not already been thought of, so there must be some hooks..

A minor observation that currently Ripple holds veto over amendments. Which can be changed over time (we're getting close to it actually), it would be quite a step, but to me it shows the amendment voting actually is a good process that allows democratic decision making between the current validators. 

Now the idea: What if we would publish the UNL (the public keys of the validators) on the ledger and that changes to the UNL can only be made through the amendment process? 

Wouldn't that make the XRP Ledger more decentralised and thrust-less? The power of changing the UNL is no longer with one party, but with the group of validators.. What are the arguments to not publish the UNL on-ledger? I can imagine if 's**t hits the fan' you want to be able to make changes fast, but every node still has the choice of not following the on-ledger UNL but follow a self-defined UNL, so calamities could still be handled off-ledger.. 

Share this post


Link to post
Share on other sites
Posted (edited)
39 minutes ago, jn_r said:

Now the idea: What if we would publish the UNL (the public keys of the validators) on the ledger and that changes to the UNL can only be made through the amendment process?

There is no "the UNL".

A UNL is secret and (potentially) unique to each validator, it's just that a lot of them use the same list or at least maintain a high overlap (this guarantees forward progress) by using a service by Ripple that regularly signs and publishes a list they recommend. There's no need or advantage to putting this service on the ledger itself.

39 minutes ago, jn_r said:

Wouldn't that make the XRP Ledger more decentralised and thrust-less?

No. Neither thrust nor trust would be decreased by this, quite the opposite actually.

39 minutes ago, jn_r said:

What are the arguments to not publish the UNL on-ledger?

Spam and there can be a huge number of possible UNLs - if you want to publish only "recommended lists" instead on-ledger, who gets to publish them?

Edited by Sukrim

Share this post


Link to post
Share on other sites
3 minutes ago, Sukrim said:

There is no "the UNL"

I agree that there is no 'The UNL' and I didn't say you are obliged to follow the on-ledger UNL. The crux of the matter is, if you deviate enough, you will fork, and then you are on another ledger anyway. So why not publish on the ledger where you want to participate, the UNL that you want to intend to follow

8 minutes ago, Sukrim said:

No. Neither thrust nor trust would be decreased by this, quite the opposite actually.

pardon my English, I meant trust of course ;-) Imo because the UNL is published on-ledger you don't need to trust the website where the UNL is published and you don't need to trust the publisher of the UNL (Ripple in this case). On the other hand you would need to trust the group of validators.

11 minutes ago, Sukrim said:

Spam and there can be a huge number of possible UNLs - if you want to publish only "recommended lists" instead on-ledger, who gets to publish them?

The thought I had was that it would be published by amendment, but I see I made some false assumptions there. Amendments are software updates and not publishing on-ledger. Still the idea could be that validators vote by a similar process as the amendments on an UNL change. I agree that that process could indeed lead to spam..

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