From ed409b850b762537339c67b1aecdbeca0cf69e41 Mon Sep 17 00:00:00 2001 From: Bryan Ischo Date: Thu, 26 Oct 2023 09:27:35 -0700 Subject: [PATCH] SIMD-0080: Allow commission decrease at any time during an epoch --- ...0-allow_commission_decrease_at_any_time.md | 89 +++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 proposals/0080-allow_commission_decrease_at_any_time.md diff --git a/proposals/0080-allow_commission_decrease_at_any_time.md b/proposals/0080-allow_commission_decrease_at_any_time.md new file mode 100644 index 000000000..92a2a059d --- /dev/null +++ b/proposals/0080-allow_commission_decrease_at_any_time.md @@ -0,0 +1,89 @@ +--- +simd: '0080' +title: Allow Commission Decrease at Any Time +authors: + - Bryan Ischo (bryan@ischo.com) +category: Standard +type: Core +status: Draft +created: 2023-10-26 +feature: TBD +--- + +## Summary + +The commission_updates_only_allowed_in_first_half_of_epoch feature disallows +commission decrease in the second half of epoch. Given that the purpose of this +feature was to prevent 'rug pulls' which are accomplished by increasing +commission at the end of epoch and then decreasing commission at the beginning +of next epoch, disallowing decreases during the second half of epoch is +unnecessary. + +A feature gate must be added to support this SIMD as all validators' vote +programs must treat commission change instructions the same or else consensus +will diverge. + +## Motivation + +Some validator operators may need to decrease commission in order to satisfy +their own operational criteria. Speaking personally, when I have an operator +error that results in reduced stake account rewards for the epoch, I reduce +commission to 0% to ensure that stake accounts are not disadvantaged by my +actions. Not being allowed to do this in the second half of an epoch is a real +problem for me. + +Allowing commission changes during the second half of epochs also enables +"reverse rug pulls" where a validator has commission set to 100% during the +majority of an epoch but reduces it to 0% across the epoch boundary. It's not +clear why some validator operators choose to do this, but it does not seem +harmful, and there does appear to be motivation for some validators to do this +as it's been done numerous times in the past. + +## Alternatives Considered + +No alternatives were considered. + +## New Terminology + +Reverse Rug Pull: Setting commission to 100% for most of an epoch, and to 0% +only across epoch boundaries. This has the effect of discouraging third party +stake to a validator while still charging 0% commission. This is not considered +to be a technique harmful to stakers. + +## Detailed Design + +A feature will be added which will enable set-commission logic to first check +whether the proposed commission change is a decrease, and if so, do not invoke +the "only allow commission change in first half of epoch" rule. + +In order to facilitate testing, all of the functionality for handling the +set-commission vote program instruction will be moved into the vote state module +instead of being half in the vote instruction processing logic and half in the +vote state module. All of the functionality being in the vote state module will +allow a new test which tests just commission updates at various points within an +epoch to be written. + +## Impact + +Validators will now be able to decrease commission at any time in the epoch, but +only increase commission in the first half of epochs (because of the +commission_updates_only_allowed_in_first_half_of_epoch feature already +implemented). + +## Security Considerations + +None + +## Drawbacks + +It may cause additional confusion to validators who might not understand why +some types of commission changes succeed only in the first half of epochs while +others succeed always. + +## Backwards Compatibility + +This feature requires a feature gate because software which includes the +implementation will allow certain set-commission transactions to succeed where +software without the implementation would fail those transactions. Thus all +validators must be updated to the new functionality at an epoch boundary so that +all validators agree on the result of executing those transactions.