split template into 2 opinionated runtimes: AccountId20 + AccountId32

[bernardoaraujor]

Motivation

Ever since the merge of #1019 , we have the option of using AccountId20 as the native account type. The PR applied this new type into frontier-template-runtime, overwriting all the previous configurations for AccountId32.

Suggested Solution

As discussed in #1053, ideally there should be two template runtimes, so that newcomers can become familiar with the fact that both approaches are viable options (and how to use them correctly).

I thought this was going to be pretty quick to implement, so I started writing a solution.

I soon learned that the implementation wasn't going to be as straightforward as I initially thought. So I'm writing this issue to summarize my findings, so that I (or someone else) can try this again with more available time in the future.

The goal is making the template directory look like:

template
├── ...
└── runtime
    ├── accountid20
    │   ├── Cargo.toml
    │   ├── build.rs
    │   └── src
    │       └── lib.rs
    ├── accountid32
    │   ├── Cargo.toml
    │   ├── build.rs
    │   └── src
    │       └── lib.rs
    └── common
        ├── Cargo.toml
        └── src
            ├── lib.rs
            └── precompiles.rs

Here's a list of crates that would also need to be refactored (additionally to template/runtime):

• fc-mapping-sync: references to frontier_template_runtime::RuntimeApi inside unit tests.
• fc-cli: references to frontier_template_runtime::RuntimeApi inside unit tests.
• template/node: multiple modules with references to frontier_template_runtime::*.

These can be solved with something like:

#[cfg(feature = "accountid20")]
use frontier_template_runtime_accountid20 as frontier_template_runtime;

#[cfg(feature = "accountid32")]
use frontier_template_runtime_accountid32 as frontier_template_runtime;

...

These documentation files should also be modified accordingly:

• docs/accounts.md
• template/README.md

[bernardoaraujor]

PR #1061 was closed in favor of #1186

the approach there is different from the one originally proposed on this issue
in fact, it is much simpler and cleaner

it simply introduces one extra feature (unified-accounts) without creating two separate template runtimes.