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

Kill dust accounts #168

Open
gavofyork opened this Issue Nov 1, 2016 · 12 comments

Comments

Projects
None yet
@gavofyork
Copy link

gavofyork commented Nov 1, 2016

Specification

Variant A

Following on from the definitions of EIP #161:

At the end of the transaction, any account touched by the execution of that transaction which is now dust SHALL instead become non-existent (i.e. deleted).

Where:

An account is considered dust when it has a balance less than KEEPALIVE_DEPOSIT and no code.

KEEPALIVE_DEPOSIT is a constant equal to 420 Szabo.

Variant B

Following on from the definitions of EIP #161:

At the end of any transaction, if the account sending that transaction has a balance of less than the transaction's gas_price multiplied by 21000, it SHALL become non-existent (i.e. deleted).

Variant C

Following on from the definitions of EIP #161:

At the end of the transaction, any account created or whose balance is decreased by the execution of that transaction which is now dust SHALL instead become non-existent (i.e. deleted).

Where:

An account is considered dust when it has a balance less than the transaction's gas_price multiplied by 21000 and no code.

Notes

This PR basically means that for any account to continue in existence on the Ethereum network it must have a minimum balance. Whenever the balance drops below the system constant KEEPALIVE_DEPOSIT the account would be deleted. Any remaining balance would be effectively burnt, any code or storage would cease to function and the effective nonce would become zero.

An important consequence of this is that accounts would become immediately insecure and susceptible to a variety of transaction-replay attacks if the balance were ever to drop too low. This means that third-party tools, particularly wallets, will need to ensure that any transaction which would result in an account's balance dropping to the point of being deleted is:

a) impossible to do without the user being told it will actually delete the account and make it no longer usable; and
b) that once done, the account is marked dead in the UI, indicating clearly that it should no longer be used to receive funds.

A more complex EIP could include a mechanism allowing it to increase or decrease over time according to miners' preferences similarly to the gas limit. To avoid a malicious miner cartel reducing it too speedily and compromising accounts with small but significant balances, the speed of movement of the limit should be slow, perhaps around 1.5x per month.

A still more complex variant would involve forcing miners to pay ether in order to raise the gas limit temporarily. From this behaviour, a reasonable gas price could be derived and from that a reasonable value for KEEPALIVE_DEPOSIT.

Rationale

The state trie is become clogged with dust accounts which, practically-speaking, are systematically created and orphaned at industrial volumes by irresponsible members of the Ethereum community. One particular offender, the operator of a popular exchange, produces around thousands of new dust accounts per day. Naively encoded, each such account adds around 100 bytes to the state trie. Overall this results in the storage and synchronisation bandwidth requirements of Ethereum needlessly increasing by up to 1 MB per day.

Implementing this EIP would allow around 500k accounts to be removed from the state, immediately saving up to 50 MB from databases and state-based synchronisation bandwidth. It would also prevent any new ones from being created, providing continued cumulative savings.

KEEPALIVE_DEPOSIT is defined as the current average cost in Ether to send a basic transaction, following from the assertion that a basic account is useless if it no longer has enough funds to send a basic transaction.

Contracts (at least those pre-existing) should be spared from this mechanism, through the requirement of dust accounts having no code, since their continued existence may be an important guarantee that caused prior actions to take place.

@vbuterin

This comment has been minimized.

Copy link
Collaborator

vbuterin commented Nov 4, 2016

This would work as a one-time clearing measure. For the longer term, once existing dust is cleared, I'm inclined to say that instead of having a fixed keepalive deposit, we say that if an account, after sending a transaction, has remaining ether less than that transaction's current gasprice times 21000, then the account should be deleted.

@pipermerriam

This comment has been minimized.

Copy link
Member

pipermerriam commented Dec 12, 2017

has remaining ether less than that transaction's current gasprice times 21000, then the account should be deleted.

If I understand correctly, this could be a very bad rule that ends up deleting accounts that should not be considered dusty. If someone sends a transaction with an extremely high gas price then this would end up wiping out their account entirely even though it still has plenty of ether in it.

@gumb0

This comment has been minimized.

Copy link
Member

gumb0 commented Feb 2, 2018

Some more recent data points I've collected while playing with warp snapshots.

As of block 4,945,000 (Jan-21-2018)
out of total ~23M accounts there are 12,53,9049 accounts that have balance < 420 szabo and no code.

And state trie DB savings in case of cpp-ethereum would be
9.7 Gb with dust vs 7.3 Gb without dust
(that's full state trie for one block, with storage and code and without prehashes)

Also for the price of ether around $1000 420 szabo is around $0.42.

@gumb0

This comment has been minimized.

Copy link
Member

gumb0 commented Feb 8, 2018

The graph of balances of accounts without code
x: account balance in wei, log scale
y: number of non-contract accounts with balance <= x

420 szabo is approximately the middle of x-axis.

y-axes doesn't start at 0, because there are 10,230,424 accounts with balance 0. (so the line starts at (0, ~10^7) )

image

@alexvandesande

This comment has been minimized.

Copy link
Contributor

alexvandesande commented Feb 9, 2018

My opinion that 420 Szabo is extremely high. Anything that is in the order of magnitude of cents, can become actual money depending on the very volatile market. It wasn't that long ago that 0.42 ether was worth $0.42.

I would prefer some longer term change: either introduce a "rent" concept where accounts would have to pay weis for storage or just create other styles of scalability.

Also, it's important to note that the unintended consequence of this EIP is that it might encourage users to use wallet contracts when they didn't need one, or to use wrapped eth instead of eth, which can end up using even more space. It also creates another difference between normal accounts and contracts, which might create issues.

@pirapira

This comment has been minimized.

Copy link
Member

pirapira commented Feb 19, 2018

I oppose account removals without the consent of the affected private key holders. There is no method to tell all of them about the to-be-removed accounts.

@AlexeyAkhunov

This comment has been minimized.

Copy link
Contributor

AlexeyAkhunov commented Feb 19, 2018

@realcodywburns

This comment has been minimized.

Copy link

realcodywburns commented Feb 21, 2018

Rather than burning coins, why not add the dust to the blockreward of the block in which the transaction occurs that would drop an account below keepalive level. Burning coins, even dust, feels wasteful.

@moeadham

This comment has been minimized.

Copy link

moeadham commented Feb 23, 2018

"One particular offender, the operator of a popular exchange, produces around thousands of new dust accounts per day."

Could we not first ask the offender (ex. s-s dot io) to reconsider their implementation, and attempt to clean up their current mess, before penalizing all users of the network?

@damientam

This comment has been minimized.

Copy link

damientam commented Feb 28, 2018

The proposal does not solve the problem
This policy could be bypassed easely by the offender simply by adding dumb code in the soon-to-be affected account.

The proposal creates other, bigger problems
This could also lead to destruction of account without their holder's knowledge. This destruction process could happened in the middle of an operation of exchange for example, Coins would leave, to be replaced by other coins soon, but when the new coins arrive, the account has been deleted.

@fergarrui

This comment has been minimized.

Copy link

fergarrui commented Apr 28, 2018

What if an account is eligible to be deleted but it has, for example ERC20 tokens balances in some contract(s)?

@Arachnid

This comment has been minimized.

Copy link
Collaborator

Arachnid commented Apr 29, 2018

@fergarrui Deleting the account will not affect its token balances.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment