In the current runtime configuration, the existential deposit is set to be 0. This could result in cheaply filling up the blockchain storage with a lot of accounts that have low or zero balance. We recommend to set the value of the existential deposit to a sensibly low, but non-zero value.
Issue description
In substrate, the reason for requiring an existential deposit for accounts is to optimise storage. Having an account go below the existential deposit will result in the account being reaped (the account data will be deleted along with the remaining funds in that address) to conserve space on the blockchain. In the current runtime configuration of Joystream, the existential deposit is set to be 0:
This means that once an account had any balance stored, the AccountData associated with it will never be cleared from the storage. Having transaction fees lower the risk but do not mitigate this issue: the cost of permanent storage is not accounted for in the weight calculation for extrinsics (similarly to Issues #5 and #6). This could allow an attacker to fill up the blockchain storage, for example by distributing 100 dollars worth of JOY tokens to 100 thousand accounts.
Risk
Attackers could cheaply fill up the blockchain storage by distributing small amounts of balances between large numbers of accounts.
Mitigation
We recommend to set the value of the existential deposit to a sensibly low, but non-zero value.
Summary
In the current runtime configuration, the existential deposit is set to be 0. This could result in cheaply filling up the blockchain storage with a lot of accounts that have low or zero balance. We recommend to set the value of the existential deposit to a sensibly low, but non-zero value.
Issue description
In substrate, the reason for requiring an existential deposit for accounts is to optimise storage. Having an account go below the existential deposit will result in the account being reaped (the account data will be deleted along with the remaining funds in that address) to conserve space on the blockchain. In the current runtime configuration of Joystream, the existential deposit is set to be 0:
This means that once an account had any balance stored, the
AccountDataassociated with it will never be cleared from the storage. Having transaction fees lower the risk but do not mitigate this issue: the cost of permanent storage is not accounted for in the weight calculation for extrinsics (similarly to Issues #5 and #6). This could allow an attacker to fill up the blockchain storage, for example by distributing 100 dollars worth of JOY tokens to 100 thousand accounts.Risk
Attackers could cheaply fill up the blockchain storage by distributing small amounts of balances between large numbers of accounts.
Mitigation
We recommend to set the value of the existential deposit to a sensibly low, but non-zero value.