Prevent amendment majority "flapping" (Version: 1.9.4)

[intelliot]

Summary

Improve the way amendment majorities are calculated in order to reduce the amount of "flapping" (an amendment repeatedly gaining and losing majority in a short period of time).

Motivation

An amendment can repeatedly gain and lose majority many times in a short period of time. Often, this occurs when an amendment is on the verge of gaining majority, and a validator not in favor of the amendment goes offline. The majority-calculating logic This creates noise and uncertainty about whether the amendment is on track to become activated.

Solution

A few different potential solutions have been proposed.

Currently, an amendment majority is calculated by dividing the number of Yeas (numerator) by the # of trusted validations received in that round (denominator). With 35 validators, an amendment that has 28 Yeas will not have "majority". But when one of the validators saying "Nay" misses a validation, then the calculation becomes 28/34, and the amendment gains majority. When the "Nay" validator resumes issuing validations, the amendment then loses majority. For example, at the time of writing, this is occurring to "CheckCashMakesTrustLine" (98DECF327BF79997AEC178323AD51A830E457BFC6D454DAF3E46E5EC42DC619F).

Instead of using "the # of trusted validations received in that round" as the denominator, the logic could instead use "the # of validators on my UNL".

Paths Not Taken

There could be a different threshold that must be met before an amendment loses majority (vs gaining majority). For example, amendments could gain majority with "Yeas" from > 80% of validators, and not lose majority until <= 65% of validators are saying "Yea".

[RichardAH]

Crosspost from XRPLF mattermost:

What if we mapped validator keys to on-ledger accounts and made votes first class objects. Then flag ledgers are just used to tally them

This provides the same persistence mechanism everything else on the ledger has (by making it part of the ledger) and we also open the door for further changes for the price of a transactor amendment (rather than a consensus amendment.)

There’s a tool to turn validator pubkey into account ids here https://github.com/RichardAH/xrpl-tools/tree/master/validator-address-tool

Other benefits include: validators could manage their votes inside a wallet by sending a txn to change their vote. The voting history is preserved in full history servers.

Tallying of the votes at flag ledger should ignore nUNL and only use actual UNL. Votes should be accompanied by some sort of UNL hash and the validator's current rippled version number so that other validators have a better idea of which votes might cause a fork.

[nbougalis]

I tried to assign this issue to @a-noni-mousse, who opened #4364 to address this, but I was unable to. Perhaps @intelliot can do it?

[intelliot]

I can't assign to @a-noni-mousse because they are not a collaborator for this repo. I invited them for read-only access; if they accept, then I think we may be able to assign them.