Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

polls, voting, staking: Enhance voting consensus rules to allow for changeable magnitude weight factor and enhance CBR #2781

Open
wants to merge 20 commits into
base: development
Choose a base branch
from

Conversation

jamescowens
Copy link
Member

@jamescowens jamescowens commented Oct 24, 2024

This is the PR for the work to enhance the polls/voting consensus rules:

  • To allow for a different magnitude unit to change the emitted coins for the network magnitude.
  • To allow for different magnitude weight factor that assigns weight to magnitude for the purposes of vote weight of individual votes and AVW.
  • Refactors the GetBlockReward function to properly work with revised CBR values in the protocol registry and expands the clamp to anticipate a larger upper end value for CBR in the future.

This implements gridcoin-community/Gridcoin-Tasks#268.

For documentation purposes I am going to describe the changes introduced here. Note that all of these changes have been implemented in such a way as to be completely consensus compatible with the existing network rules prior to the V13 mandatory, which means that this PR can be merged prior to the setting of the mandatory height for V13.

Implementation of changeable magnitude unit and magnitude weight factor

Prior to this PR, the magnitude unit has been hard-coded to 1/4 and the magnitude weight factor has been hard-coded to 100/567. This has been true since the Fern mandatory rules went into effect. We needed a way to both increase the amount of paid crunching rewards (the research emission), and also change the weight ratio used to convert magnitude of a voter into weight units for the voting in balance + magnitude polls. This PR provides both:

  • The magnitude unit can be changed by a protocol entry (administrative contract) with key name "magnitudeunit" and a value specified as a whole number or rational fraction, such as 1/4 (the current value) or 5/4, for example. The maximum accrual has now been changed from a fixed value of 16384 to be (magnitude unit) * 32768 * 2, which represents the accrual that would occur for a CPID at the maximum magnitude (rounded up by 1 to 32768 from 32767) after two days with the network magnitude unit in effect. This reduces to the current value of 16384 with the magnitude unit at its current (default) value of 1/4.
  • The magnitude weight factor can be changed similarly with key name "magnitudeweightfactor". The current value is 1/5.67 (i.e. 100/567). The magnitude weight factor proposed in 268, for example, is 5702887/3524578, which is a good rational approximation of 2 / (1 + sqrt(5)) without risking overflow in integer arithmetic.

Enhanced CBR

The CBR code has been enhanced for V13+ to more reliably allow for changing the constant block reward via protocol entry (administrative contract) with the key name "blockreward1". The current value is 10 GRC.

New blockchain consensus parameters to support/control the above

The following blockchain consensus parameters have been implemented and are active as of the V13 mandatory. the floor and ceiling parameters act as clamps.

    consensus.DefaultConstantBlockReward = 10 * COIN;
    consensus.ConstantBlockRewardFloor = 0;
    consensus.ConstantBlockRewardCeiling = 200 * COIN;
    consensus.DefaultMagnitudeUnit = Fraction(1, 4);
    consensus.MaxMagnitudeUnit = Fraction(5, 1);
    consensus.DefaultMagnitudeWeightFactor = Fraction(100, 567);

Other corrections/additions

  • GetActiveNetworkWeight did not correctly compute AVW for balance only polls/votes, which should not include any magnitude component to the AVW. It should simply be the sum of balance attestations in the votes divided by the average network weight. This has been corrected in this PR.
  • The contract version for protocol contracts was never advanced, and the contract was still using the legacy format. This has been updated, although there is no hard enforcement of the older legacy contract in V13+ currently.

This PR has been tested on testnet and then mainnet for consensus compatibility prior to V13 mandatory, and comprehensively tested in a three node isolated testnet network post V13 mandatory, with several changes in the above protocols. Sync from genesis has also been conducted in all three cases.

@jamescowens jamescowens self-assigned this Oct 24, 2024
@jamescowens jamescowens added this to the Natasha milestone Oct 24, 2024
@jamescowens jamescowens force-pushed the enhance_voting_consensus_rules branch 6 times, most recently from 5c128f3 to 47a2ba2 Compare October 27, 2024 18:16
@jamescowens jamescowens force-pushed the enhance_voting_consensus_rules branch from 47a2ba2 to 3c6a501 Compare November 3, 2024 00:52
This commit adds

DefaultConstantBlockReward
ConstantBlockRewardFloor
ConstantBlockRewardCeiling
DefaultMagnitudeUnit
DefaultMagnitudeWeightFactor

to consensus parameters.
Extends the fraction class with a FromString method to support
parsing of a string representation of a fraction (i.e. "1/4")
into a formal fraction object.
This new method provides the ability to find the last version
of a key that exists with a timestamp prior to or equal to the
provided timestamp.
This refactors GetConstantBlockReward to use the blockchain
consensus paramters, removes the lookback limitation for block
v13+ to correspond with the removal of the contract
lookback window for protocol entries, and corrects the behavior
of the lookup if the input index is not at pIndexBest.
This fixes a compile error on ambiguous method with WIN32/64
This separates out the calculation of network weight from nBits
contained in GetActiveNetworkWeight and extends it with two
forms (overloads).
GetMagnitudeWeightFactor should return zero if index argument is
a nullptr.
@jamescowens jamescowens force-pushed the enhance_voting_consensus_rules branch from 3c6a501 to ca935a3 Compare December 15, 2024 23:46
The magnitude unit has been fixed at 1/4 since Fern. This commit
allows the magnitude unit to be changed via a protocol entry for block
V13+.
The contract version for V13+ is 3 and the legacy handler is not supposed
to be used.
This establishes an upper clamp on the magnitude unit. Currently set at 5.
Also implement 256 bit integer arithmetic in ComputeMRCFee() as an
overflow fallback.
@jamescowens jamescowens requested a review from div72 December 29, 2024 06:34
@jamescowens jamescowens marked this pull request as ready for review December 29, 2024 06:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant