pallet-balances configuration might need adjustment because ED is 0

[gui1117]

there is those issues:
paritytech/substrate#10117
paritytech/polkadot-sdk#337

I proposed a fix on the configurations of the pallet: paritytech/substrate#10117 (comment)

that said I don't remember any details

Also some warning in the code:

		/// The minimum amount required to keep an account open. MUST BE GREATER THAN ZERO!
		///
		/// If you *really* need it to be zero, you can enable the feature `insecure_zero_ed` for
		/// this pallet. However, you do so at your own risk: this will open up a major DoS vector.
		/// In case you have multiple sources of provider references, you may also get unexpected
		/// behaviour if you set this to zero.
		///
		/// Bottom line: Do yourself a favour and make it at least one!
		#[pallet::constant]
		#[pallet::no_default_bounds]
		type ExistentialDeposit: Get<Self::Balance>;

[gui1117]

if ED is 0 then deposit_into_existing and repatriate_reserved are broken.

Eiter we try to put type AccountData = Option<super::AccountData<u64>>; on the configuration of frame_system or we put ED to be 1 unit.

to convince yourself add those test in polkadot-sdk/substrate/pallet/balances/src/tests/currency_test.rs
and run cargo test -p pallet-balances --features insecure_zero_ed

#[test]
fn deposit_into_existing_for_existing_zero_account() {
	// These functions all use `mutate_account` which may introduce a storage change when
	// the account never existed to begin with, and shouldn't exist in the end.
	ExtBuilder::default().existential_deposit(0).build_and_execute_with(|| {
		let alice = 666;
		let bob = 777;
		assert_ok!(Balances::force_set_balance(frame_system::Origin::<Test>::Root.into(), alice, 2000));
		assert_ok!(Balances::force_transfer(frame_system::Origin::<Test>::Root.into(), alice, bob, 2000));

		dbg!(666, frame_system::Account::<Test>::get(alice));
		dbg!(777, frame_system::Account::<Test>::get(bob));

		let _ = dbg!(Balances::deposit_into_existing(
				&alice,
				500,
		)).unwrap();
	});
}

#[test]
fn repatriate_reserved_works_for_zero_account() {
	// These functions all use `mutate_account` which may introduce a storage change when
	// the account never existed to begin with, and shouldn't exist in the end.
	ExtBuilder::default().existential_deposit(0).build_and_execute_with(|| {
		let alice = 666;
		let bob = 777;
		assert_ok!(Balances::force_set_balance(frame_system::Origin::<Test>::Root.into(), alice, 2000));
		assert_ok!(Balances::force_transfer(frame_system::Origin::<Test>::Root.into(), alice, bob, 2000));

		dbg!(666, frame_system::Account::<Test>::get(alice));
		dbg!(777, frame_system::Account::<Test>::get(bob));

		assert_ok!(Balances::reserve(&bob, 500));

		dbg!(alice, frame_system::Account::<Test>::get(alice));
		dbg!(bob, frame_system::Account::<Test>::get(bob));

		// Repatriate Reserve
		dbg!(Balances::repatriate_reserved(
				&bob,
				&alice,
				500,
				crate::Status::Free
		)).unwrap();
	});
}

[ggwpez]

I thought it could be done easier like paritytech/polkadot-sdk#3903, but does not seem like it.
So the type AccountData = Option<super::AccountData<u64>>; is probably the easiest way for now.

[shawntabrizi]

For the purposes of DropIt, we def want ED to be 0. Any non-zero value won't work for effortless distribution.

[gui1117]

what is the problem with having ED to be 1 unit? like 0.0000....0001 DOT

The dust when going below ED would always be 0.

I'm afraid some issue will arise when deposit_into_existing or repatriate_reserved get used indirectly.

It is like a sword of Damocles