From ecb8ec5d6b990354d2175497140bf72d8e7c5765 Mon Sep 17 00:00:00 2001 From: Yash Patil <40046473+ypatil12@users.noreply.github.com> Date: Tue, 18 Feb 2025 23:03:34 -0500 Subject: [PATCH] docs: add case 2 --- docs/core/accounting/SlashingEdgeCase.md | 67 +++++++++++++++++++++++- 1 file changed, 65 insertions(+), 2 deletions(-) diff --git a/docs/core/accounting/SlashingEdgeCase.md b/docs/core/accounting/SlashingEdgeCase.md index 3aae76dabc..4f91752744 100644 --- a/docs/core/accounting/SlashingEdgeCase.md +++ b/docs/core/accounting/SlashingEdgeCase.md @@ -15,7 +15,7 @@ Consider a staker, Alice who is in the following state: 1. Alice has verified a validator. `withdrawble: 32 ETH` 2. Alice's operator is slashed for 75%. `withdrawable: 8 ETH`
- View calculation details + Calculation * `depositShares: 32` * `maxMagnitude: 0.25` @@ -32,11 +32,15 @@ We define restaking as **reusing staked ETH as security for AVSs. Thus, the same In the above scenario, let's say the Alice now proves a checkpoint. 4. A checkpoint of BC state is proven. `withdrawable: 4 ETH` +
+ Calculation + * `depositShares: 16` * `maxMagnitude: 0.25` * `BCSF: 1` * `DSF: 1` * `withdrawable = 16 * 0.25 * 1 * 1 = 4 ETH` +
The checkpoint slash has devalued Alice's currently withdrawable assets by 50%. The AVS slashes from what's left due to the BC getting priority burning rights. Thus, AVSs must factor Native ETH (or an LST) being slashed by the beacon chain when designing their slashing conditions. The below diagram illustrates this behavior: @@ -53,4 +57,63 @@ The behavior of BC and AVS slashings for Native ETH mimics the behavior of slash **When an AVS slashes, its attributable slashed amount is between 0 and the originally slashed amount. The attributable slashed amount decreases in the event of BC slashes.** We see this behavior in the above example, where the 12 ETH that was attributed to the AVS is less than the original 24 ETH that was slashed. -Let's take another example, where \ No newline at end of file +However, given the asynchronous nature of the EigenPod proof system, Alice may have a different number of withdrawable shares depending on the ordering of her actions. Note that even in this case, **assets are not overslashed**. + +Let's start with our above scenario. + +Scenario A: + +4. Alice verifies another validator. `withdrawable: 40 ETH` +
+ Calculation + + * `depositShares: 64` + * `maxMagnitude: 0.25` + * `BCSF: 1` + * `DSF = 40 / (32 + 32) / 0.25 = 2.5` + * `withdrawable = 64 * 0.25 * 1 * 2.5 = 40 ETH` +
+ +5. Alice checkpoints all her pods. `withdrawable: 30 ETH` +
+ Calculation + + * `depositShares: 64` + * `maxMagnitude: 0.25` + * `BCSF = 48 / 64 = 0.75` + * `DSF: 2.5` + * `withdrawable = 64 * 0.25 * 0.75 * 2.5 = 30 ETH` +
+ +In this scenario, 25% of Alice’s currently proven assets are slashed. Similarly, the AVSs attributable slashed amount has been decreased by 25% (24 → 18 ETH). + + +Scenario B: + +4. Alice checkpoints her pod. `withdrawable: 4 ETH` +
+ Calculation + + * `depositShares: 32` + * `maxMagnitude: 0.25` + * `BCSF = 16 / 32 = 0.5` + * `DSF: 1` + * `withdrawable = 32 * 0.25 * 0.5 * 1 = 4 ETH` +
+ +5. Alice verifies another validator. `withdrawable: 40 ETH` +
+ Calculation + + * `depositShares: 64` + * `maxMagnitude: 0.25` + * `BCSF: 0.5` + * `DSF = 36 / (32 + 32) / 0.125 = 4.5` + * `withdrawable = 64 * 0.25 * 0.5 * 4.5 = 36 ETH` +
+ +In scenario B, 50% of Alice’s currently proven assets are slashed, along with a commensurate decrease in the AVSs attributable slashed amount. In both cases Alice’s withdrawable shares and the AVSs attributable slashed amount decrease by the same percentage. + +We acknowledge this edge case. A benefit of this system is that stakers are incentivized to immediatley prove BC slashed. Eigen Labs runs an off-chain process (EigenPod Health Checker) that monitors BC slashings and starts checkpoints as needed. + +Conversely, when Native-ETH burning is implemented, AVSs are incentivized to immediately exit stakers from the BC to recoup the maximum possible attributable slashed amount. \ No newline at end of file