UX: improve UX for deploying ink! smart contracts locally using Pop CLI

[brunopgalvao]

Right now, as a newcomer into the Polkadot ink! ecosystem, it is confusing when I should use substrate-contracts-node and/or when I should use Pop parachain.

Proposed solutions:

• replace substrate-contracts-node with a manual seal Pop node to provide a seamless experience for ink! developers: one place for ink! deployments: Pop.

• Or create a flavour of substrate-contracts-node for Pop - this could be as easy as forking the repo. This is a semantics issue. By simply including this node under the Pop umbrella, we can create a better user experience and prompt the user with the following:

pop up contract

┌   Pop CLI : Deploy your contract locally
│
◆  Select the Pop node to spin up to deploy your contract:
│  ○ Solochain
│  ● Parachain
│
◆  Select additional Polkadot appchains to spin up:
│  ◻ AssetHub
│  ◻ PeopleChain
└  

[al3mart]

We could maybe improve the CLI experience when it comes to deploying contracts. If the contract is depending on pop-api, then there's only one platform where that can run, Pop.

It might even be good to have something similar to a zombienet spec file, but for contracts deployments. (In case it is even necessary). That would come handy when a solution is composed of multiple contracts deployed in different networks. Or one contract that interacts with other third party contracts, and the user wants to see all pieces working together.

[brunopgalvao]

We could maybe improve the CLI experience when it comes to deploying contracts. If the contract is depending on pop-api, then there's only one platform where that can run, Pop.

More so than usual, developers will use Pop CLI with custom ink! smart contracts. We would need to have the CLI tool detect multichain usage e.g. Pop API, ink! v5, etc.

Also, the underlying blockchain types (Balance, AccountId, etc) may vary from blockchain to blockchain. For example, what one defines as the Balance type in one blockchain runtime may differ in the pop-node runtime.

I am more in favor of simply using Pop parachain as the default for local deployments.

It might even be good to have something similar to a zombienet spec file, but for contracts deployments. (In case it is even necessary). That would come handy when a solution is composed of multiple contracts deployed in different networks. Or one contract that interacts with other third party contracts, and the user wants to see all pieces working together.

This is interesting. I definitely agree with this. The ability to spin up Pop with X, Y, Z parachains and certain configurations.

So the flow would be for Pop CLI to check if this config file exists, otherwise prompt the user for the deployment and save a configuration file locally.