The existential deposit is configured to be 0

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:

parameter_types! {
    pub const ExistentialDeposit: u128 = 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.

Locate the runtime configuration containing the parameter_types! block and the ExistentialDeposit value shown in the issue. Read the surrounding balance and account-storage configuration to determine the appropriate non-zero setting, then verify that the runtime configuration reflects it and that relevant tests pass.