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

capella: add withdrawal boost factor constant #3073

Closed
wants to merge 2 commits into from

Conversation

q9f
Copy link
Contributor

@q9f q9f commented Nov 1, 2022

A WITHDRAWAL_BOOST_FACTOR should always be 1 but can be used to inflate total supply through withdrawals in tests or testnet environments.

Opening this up for discussion. Context eth-clients/goerli#129

cc @parithosh

@ralexstokes
Copy link
Member

@lightclient raised this griefing vector:

I deposit 32 goETH and withdraw 320 goETH; rinse and repeat until I control an arbitrary amount of stake and then do what I want to the network, e.g. keep BASE_FEE unacceptably expensive

this is a nice idea to leverage the CL as a "minting" layer but I don't see a way around this particular issue

even w/ some kind of "lock up" period, it would just shift the timing of the attack, not its existence

@dapplion
Copy link
Collaborator

dapplion commented Nov 3, 2022

@ralexstokes before considering this PR it's necessary to model the exponential supply growth of Goerli for a reasonable timeframe

@pk910
Copy link
Member

pk910 commented Nov 3, 2022

I think it's even more problematic as anyone can deposit more than 32 ETH to their validator.
So a abusive user could just deposit his whole balance to a validator to get it back multiplied by the factor.

That issue could be mitigated by an additional WITHDRAWAL_BOOST_LIMIT, that limits the amount of funds where the factor applies:

if amount <= WITHDRAWAL_BOOST_LIMIT:
    amount *= WITHDRAWAL_BOOST_FACTOR

But it makes it more complex and doesn't fix the problem that @ralexstokes mentioned.

I'm also not sure if this doesn't break reward calculations for staking pools. They're probably calculating things based on the real validator balance and don't take care of such factors.
Therefore this factor introduces a "custom path" for reward calculations - that's something we wanted to avoid in testnets?

@q9f
Copy link
Contributor Author

q9f commented Nov 3, 2022

closing as per discussion during today's CL call. focus should be now to prepare application teams for sepolia and holesovice.

@q9f q9f closed this Nov 3, 2022
@q9f q9f deleted the q9f/withdr/boost branch November 3, 2022 16:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants