RichardAH
commented
1 year ago 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
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".