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.

Sign up for GitHub

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

Jump to bottom

Involuntarily decrease all authorizations in case of slashing #87

Merged
merged 2 commits into from
Apr 22, 2022
Merged

Involuntarily decrease all authorizations in case of slashing #87

merged 2 commits into from
Apr 22, 2022

Commits on Apr 6, 2022

  1. Involuntarily decrease all authorizations in case of slashing 

    The original approach was to decrease authorization on the slashing
application and decrease authorizations on other applications only
if necessary, that is, if the staked amount after the slashing was
lower than the authorization on the other application.

For example, let's assume the staking provider has 1000 T delegated
and three applications authorized:

A application authorized for 950 T
B application authorized for 500 T
C application authorized for 100 T

If C slashed for 50 T, authorization on C would be reduced by 50 T,
to 100 - 50 = 50 T.

If A slashed for 950 T, authorizations on A would be reduced to 0,
and authorizations on B and C would be reduced to 50 T.

The new approach assumes all applications are decreasing authorizations
in case of slashing, no matter which application executed the slash.

If C slashed for 50 T, authorization on A would be reduced to
950 - 50 = 900 T, authorization on B would be reduced to
500 - 50 = 450 T, and authorization on C would be reduced to
100 - 50 = 50 T.

If A slashed for 950 T, authorizations on A, B, and C would be reduced
to 0 T.

Depending on how staker thinks about setting their risk profile, the
first or second approach could make more sense for them. One staker
could argue slashing event on one application should not affect their
authorizations on other applications, and another staker would argue
they set their original risk profile based on another staked amount,
and given that the situations changed and they have less tokens now,
the risk profile should be adjusted.

Most importantly though, this change is made to avoid storing the
address of slashing application in the slashing event structure. This
change allows reducing the gas cost of slashing large groups
SIGNIFICANTLY given that we store one EVM word less per each member
seat in the group. For a group of 64 members, it means storing 64 EVM
words less. For a group of 100 members, it means storing 100 EVM words
less. This is extremely important for random beacon and tBTC where
signing groups have 64 and 100 operators respectively.

This change was tested with the `RandomBeacon` contract's
`reportUnauthorizedSigning` call with the cost of `TokenStaking.seize`
extracted.

Before this change:
- for group size 64, gas cost: 3 142 093,
- for group size 100, gas cost: 4 860 500.

After this change:
- for group size 64, gas cost: 1 720 849,
- for group size 100: gas cost: 2 639 758
    @pdyraga
    pdyraga committed Apr 6, 2022
    Configuration menu
    Copy the full SHA
    6eaf4d5 View commit details
    Browse the repository at this point in the history

  2. Linting TokenStaking unit tests file

    @pdyraga
    pdyraga committed Apr 6, 2022
    Configuration menu
    Copy the full SHA
    225c4e2 View commit details
    Browse the repository at this point in the history