How do I opt in (or implement) the "Native H160 via AccountId20" strategy?

[julian-payne]

In the /docs/accounts.md it states the following:

The second strategy consists of using fp-account so that AccountId20 is the Account type used for frame_system::pallet::Config::AccountId.

How can someone opt in to this strategy?
Where in code does it have to be changed?

Some guidance would help tremendously for someone new to substrate and would like to get started quickly.

I'd be more than happy to create a PR with detailed explanation of this once I have understood how this works so following devs can make their switch quickly.

Many thanks.

[Niraj-Kamdar]

I am also interested in this one

[boundless-forest]

Nice question. You can check out our configuration at https://github.com/darwinia-network/darwinia/blob/main/core/primitives/src/lib.rs#L33-L37. Since there are already several projects based on Frontier that have been running for a long time, feel free to search and test by yourself.

[julian-payne]

@boundless-forest
Thanks for the reply!
But from what I can see, your link does nothing different from the Frontier runtime template.

I can see that you have H160 as address type in other places which means AccountId20 strategy is used?

I guess my real question is, why isn't there some kind of global struct with an associated type where the AccountId type is configurable for all other pallets to derive their behavior from...?

What't the idea here?
Why should we go around and change in a lot of places what the account id type is?

Also why is there a H160 struct and AccountId20 struct?
Why did we create 2 separate structs that is almost identical? (at least it looks like that to me)

I'm assuming there is some fundamental knowledge that I'm missing about polkadot-sdk that I just don't understand yet.

Would help if someone could enlighten me.

[Niraj-Kamdar]

I believe H160 and H256 represents the generic hash type which may or may not be the AccountId where AccountId maybe further constrained version of hashes which is the case most of the time. AFAIK, you don't need to change use AccountId20 everywhere, there is AccountId generic type which just works, also you only need to configure it in frame_system, you can also refer to it with <Runtime as frame_system::Config>::AccountId and it will point to whichever AccountId you are using.