[NKP-0015] Removing inactive ID to reduce database size

There are massive spamming generate ID txn in the network and over a million ID has been generated so far. In the current mechanism, once an ID is generated, it is permanent and will use up some space not only in the block history, but also in account state.

We propose a mechanism such that a generated ID will be removed if the mining account is inactive for a period of time (e.g. a few months). A mining account is active if it generates an ID or mines a block. Once an ID is removed, it will be removed from state and will reduce state size (thus db size). The account needs to generate ID again and the new ID will be different from the previous one.

This proposal, combined with the state pruning mechanism we are working on, will reduce chain db size by removing empty account. If we implement both this proposal and [NKP-0014] Use PoW to prevent generate ID txn spam, then it shouldn’t bring much trouble to normal miners because if they haven’t mined for quite a long time and ID has been removed, then they just need to wait for a couple more minutes before re-joining the network.

Note: this proposal will not affect non-miner account since only miner account will generate ID.

  • Yes
  • No

0 voters

4 Likes

Just added a poll to vote :slight_smile:

generated ID itself should be a dynamic resource, for example, it should be deleted when it is not online for more than 24 hours, which can also filter out a large number of unstable nodes.

2 Likes

will current ChainDB shrink or only new usage will become smaller? if it’s about months, then there will be no immediate effect because the network is young?

Hi AG, we are implementing state pruning which will bring immediate relief to ChainDB size. We are talking about weeks, if not sooner.

Whether a node is online or not online is not something publicly verifiable. In blockchain, whenever we make an onchain operation (delete id, for example), we can only use publicly verifiable information to make sure EVERY node with the correct block history can make the same decision.

This NKP has been implemented