Optional storage hashers in pallet dev mode

[kianenigma]

In dev-mode, all hashers could default to Blake2_256_Concat.

We could also maintain the same in production, but omit a warning.

An idea that arose in the spirit of simplifying FRAME during the academy.

[ruseinov]

It's a good idea to simplify things, although I'm not completely sold on the fact that having an expensive hasher as default is the best idea. For dev mode - maybe. Yes, it is safe. But it also makes users unaware of the price they have to pay and the choices they can make when building pallets.

Maybe we could have some aliases for hashers though, like Safe / Cheap or whatever to make it easier for people to understand and choose between the two? :)

[ggwpez]

But it also makes users unaware of the price they have to pay and the choices they can make when building pallets.

That is basically the point of the dev-mode; to hide complexity from new-comers. Otherwise it is just too complicated to understand. We also allow unbounded storage in there, which you dont want in production as much.

Normally in Rust a map is written as as StorageMap<Key, Value>. If we can get FRAME in dev-mode to be like that, I think it would be easier to understand for new-comers. Probably should also get rid of the annoying map _ prefix, huh?

[ruseinov]

Sounds good, let's do this for dev-mode. However I'm still not sold on hiding this kind of complexity in production, as we work hard to NOT have magic, like for example pallet getters, we should not be easy on the users when they actually have to choose a hashing algorithm suitable for their purpose.

[xlc]

This hide complexity from new-comers and make it harder later for them to build a production pallet. I don't really know if this is the right trade-off.

[gupnik]

Is it possible to introduce another mode as a "playground" where most things are set to reasonable defaults? I think that it would have definitely helped a lot of folks during the academy.

[kianenigma]

However I'm still not sold on hiding this kind of complexity in production, as we work hard to NOT have magic..

The issue explicitly says this is only for dev-mode.

This hide complexity from new-comers and make it harder later for them to build a production pallet. I don't really know if this is the right trade-off.

I get your point, but I am not convinced yet. We want more developers to be capable of onboarding into FRAME and trying new things. dev-mode is meant to enable that. Also, we already hide weight in dev-mode. So your comment is essentially the fact that you don't like dev-mode, not the hasher thing per se.

Is it possible to introduce another mode as a "playground" where most things are set to reasonable defaults? I think that it would have definitely helped a lot of folks during the academy.

I think dev-mode is basically that. It defaults them to something that is enough for you to have a dev/local testnet.

@sam0x17 what is the default weight used in dev-mode?

[sam0x17]

@sam0x17 what is the default weight used in dev-mode?

See here: https://github.com/paritytech/substrate/pull/12536/files#diff-702aefc48c38cab59eddce87758199f5439477ba32125385a924c96ed9505861R220-R222

It is zero. Happy to change this if we think there is a more reasonable number for dev mode. Zero was on the original spec for dev mode that I inherited.

[ruseinov]

We could also maintain the same in production, but omit a warning.

I was mostly referring to this part of the issue description which mentions prod setup.

[ruseinov]

So, is this a confirmed issue then or still pending discussion? I've taken a look at what "dev mode" is and I guess I'm convinced that it's fine to hide the hashers. That question will pop up once a pallet get switched over to production mode, which is when we could produce a comprehensive error present a user with a choice. Adoption is important and if this helps that - definitely worth doing it.