-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Comments
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. |
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. |
Some more recent data points I've collected while playing with warp snapshots. As of block 4,945,000 (Jan-21-2018) And state trie DB savings in case of cpp-ethereum would be Also for the price of ether around $1000 420 szabo is around $0.42. |
The graph of balances of accounts without code 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) ) |
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. |
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. |
More data in this blog post for reference: https://medium.com/@akhounov/more-data-for-eip-168-kill-dust-accounts-83e8dd0938d3 |
Rather than burning coins, why not add the dust to the |
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? |
The proposal does not solve the problem The proposal creates other, bigger problems |
What if an account is eligible to be deleted but it has, for example ERC20 tokens balances in some contract(s)? |
@fergarrui Deleting the account will not affect its token balances. |
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
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.
The text was updated successfully, but these errors were encountered: