`into_sub_account` should check seed length

[shawntabrizi]

Currently, into_sub_account directly encodes the seed data into the generated account id bytes.

We do not check that the seed data is greater than the length of the account id type, and thus do not check that some of the data may be truncated and not used to seed an account. This can obviously be bad since all of the seed information should be used to generate a unique account, and any truncation could lead to unintended account collisions.

into_sub_account should return a result, and only generate an account if the seed data would fit completely into the account id space.

Otherwise, hash_into_sub_account can be introduced which takes a hash of the seed data and uses that to generate as much data as needed for the account.

We must review all uses of into_sub_account to make sure they would not suddenly stop working.

[xlc]

Yeah we had some issues in our test that using u64 as AccountId type and confused why the test isn't working...

[hirschenberger]

I changed into_sub_account to return an Option, (or should it really be a Result, what's the Error then?). Maybe we can rename the function to try_into_sub_account to be consistent and the into_sub_account be the one that's infallible and is hashing the seed.

For the hashing function, what hasher should be used?

And there may also be the case, that the hash value does not fit into the AccountId type. As I understand you correctly, the AccountId should just be filled up with the hashed seed, to reduce the probability of collisions, but may also be left out at all, as in the previous implementation?

[shawntabrizi]

You should be able to pass a generic hashing trait so the end user can pick the hasher.

Yeah, if the hash value is too much, we put as much as we can into the AccountId.

Is there some code I can look at?

[hirschenberger]

@shawntabrizi I opened a PR #8672

[gui1117]

I also see that into_sub_account will always return the same default account in case AccountId can't decode the byte slice.

substrate/primitives/runtime/src/traits.rs

Lines 1146 to 1150 in 37e97cf

	fn into_sub_account<S: Encode>(&self, sub: S) -> T {
	(Id::TYPE_ID, self, sub).using_encoded(|b|
	T::decode(&mut TrailingZeroInput(b))
	).unwrap_or_default()
	}

I think we should create a proper trait to be able to generate different account id safely.

For example we could a new trait to frame_system::Config::AccountId: GenerateAccountFromSeed

trait GenerateAccountFromSeed {
fn from_seed(s: &[u8; 8]) -> Self;
fn pallet_sub_account<P: PalletInfoAccess>(seed: &[u8]) -> Self {
  Self::from_seed(twox64("pllt"++encode(P::index)++Some(seed))))
}
fn pallet_account<P: PalletInfoAccess>(seed: &[u8]) -> Self {
  Self::from_seed(twox64("pllt"++encode(P::index)++None))))
}
}

and implement it for u64 and u128.
Or maybe another trait which allows more flexibility.

[hirschenberger]

This looks like a safe alternative. How about generalizing with the Encode-Trait for the seed?
And does pallet_account need a seed parameter?

trait GenerateAccountFromSeed {
    fn from_seed<S: Encode>(s: S) -> Self;
    fn pallet_sub_account<S: Encode, P: PalletInfoAccess>(seed: S) -> Self {
        Self::from_seed(twox64("pllt"++ encode(P::index) ++ encode(seed)))
    }
    fn pallet_account<P: PalletInfoAccess>() -> Self {
        Self::from_seed(twox64("pllt"++encode(P::index))))
    }
}

The drawback of hashing the whole representation is that it's not reversible/inspectable anymore.

What are the implications on changing the underlying representation for existing accounts or code that maybe rely on that representation? Is there some migration necessary?

[shawntabrizi]

I dont think this is exactly the direction we want to go.

In this case, the account for a pallet will change depending on the order a user puts the pallets in their runtime.

Currently, we have it that the treasury account for all substrate chains are the same account, which makes it easy for exchanges and block explorers to track those well known accounts.

I think the goal here is to keep the same underlying logic about PalletId, but simply make sure that there are appropriate error handling when a user programs too much value into the seed data.

[xlc]

we can explicitly set pallet index so the order shouldn't be an issue.

we should not assume treasury account address on different chains are the same, because there will be exceptions and I don't think that's a good idea anyway.

[gui1117]

I mean treasury doesn't have to use pallet_sub_account. My proposition was in order to cover the case paritytech/polkadot-sdk#324 at the same time

[hirschenberger]

This Issue and PR seems stuck. How can we make progress here?

I see three directions from here:

• Adding the hashed seed without any safety nets that relies on the the user to take care that everything fits. @shawntabrizi
• An implementation that reports missing the addition of at least a part of the (hashed) seed. @hirschenberger
• A version that guarantees the addition of the seed. @thiolliere