EnableAmendment timer starts at 77.78% (Version: [rippled 1.5.0])

[gnurag]

Issue Description

I may be reading this incorrectly - but I think the 14 day timer to enable an amendment starts at 77.78% (28 Ayes out of 36 as of today). 28 Ayes of 36 is only 77.78% agreement. Amendment process doc says this must be 80% or above.

Observed this behavior with RequireFullyCanonicalSig amendment which is hovering around 27 Ayes at the moment. Once it achieved 28 Ayes (=77.78% agreement), the validator inserted an EnableAmendment transaction and the 14 day timer started.

Steps to Reproduce

Run:

# /opt/ripple/bin/rippled feature

on the validator when an amendment has 28 Ayes out of 36.

Expected Result

1. EnableAmendment transaction is not inserted into the ledger.
2. majority property is not set.

Actual Result

1. EnableAmendment transaction is inserted into the ledger.
2. majority property is set (see screenshot above).

Environment

rippled-1.5.0

Supporting Files

[nbougalis]

Thanks for opening an issue. You aren't reading it incorrectly.

A couple of people had already reached out to me about the DeletableAccounts amendment, wondering how come it reached majority, since 28 validators seem to support it but (a) the consensus quorum is presently 29 and (b) 28/36 is strictly less than 80%, which is the amendment activation threshold, so I already had a chance to triage this..

The answer boils down to two things:

First, for historical and largely obsolete reasons, the calculation for the majority is done in base 256, with the quorum threshold set to (V * 204)/256 where V is the total number of trusted validations. There are currently 36 validators on Ripple's recommended UNL, so I am assuming a server running with a UNL with a size of 36 for this example, but similar calculations apply for other sizes:

So the code calculates (36 * 204) / 256. Ref:

vote->mThreshold = std::max(1,
    (vote->mTrustedValidations * majorityFraction_) / 256);

JLOG (j_.debug()) <<
    "Received " << vote->mTrustedValidations <<
    " trusted validations, threshold is: " << vote->mThreshold;

Now, if you plug that into a calculator you'll see it works out to 28.6875. So what's wrong?

The code is using integer arithmetic, which "truncates toward zero’’. Basically, you can think of it as "rounding down to the nearest integer" and what is the nearest integer that is strictly smaller? It's 28. For a little deeper dive into this check out this excellent StackOverflow answer.

The second, problem is that the code checks whether an amendment has achieved the required quorum by using greater than or equal to instead of strictly greater than. Ref:

bool const hasValMajority =
    (vote->votes (entry.first) >= vote->mThreshold);

While the behavior of the code is well-defined in terms of C/C++, it's not ideal from a human perspective and certainly complicates the understanding of quorum when it comes to amendments.

I believe that this issue needs to be addressed in a future release of rippled, preferably with the 1.6.0 release. Ironically, the fix will require an amendment. 😅