Make worst-case slashing loss estimate more precise

[ryanberckmans]

Currently, the worst-case slashing loss is based on a rough estimate of the loss being equal to triple the proportion of validators recently slashed.

Instead, the estimate may be upgraded to a precise calculation based on the eth2 spec.

[libevm]

Do you have a link/examples to the precise calculations? (Sorry not that familiar with ETH2) 🙏

[ryanberckmans]

I don't have an example of precise calculations. It may be necessary to go into the eth2 spec https://github.com/ethereum/consensus-specs or ask client teams

[crypto-crack]

Look like I came to the same simplified solution: min((((3total_validatorspercentage_slashed32)/(total_validators32))*32),32) and since taking count of validators rather than balances etc. the fraction can be reduced to yours.
@libevm detailed calc described here: https://eth2book.info/altair/part3/transition/epoch#slashings

[crypto-crack]

Not to forget inactivity hit once network is leaking (participation below 66,7%):
ca =32-(322.718^(-1(((duration_hours*60/6.4)^2))/(2^24)))
Certainly less severe (ca 0.1 ETH for 24 hours, 4.4 ETH for 1 week), but prob more likely than slashing bugs?
https://medium.com/prysmatic-labs/eth2-medalla-testnet-incident-f7fbc3cc934a
@libevm detailed calc described here: https://eth2book.info/altair/part2/incentives/inactivity#inactivity-penalties
(I e.g. assumed one's validator to be completely offline)

[ryanberckmans]

@crypto-crack this is great. Would you be interested in opening a PR to modify the site to include some indication of the inactivity leak penalty that, to your point, may potentially correlate and scale with one's choice of client?

[crypto-crack]

@ryanberckmans sorry, but I am not a developer unfortunately, so afraid I cannot do PR. But if it helps I made my scenario spreadsheet available here for reference by you or others: https://docs.google.com/spreadsheets/d/12R8wkuv62hZyajrhhlkNrskkwH2-zjYZjXKkHJuxGQc/edit?usp=sharing