Do we need a standalone chain?

[vayesy]

Currently, both versions of the network are supported: standalone and parachain.
Zero network was planned to release as a parachain in the Polkadot ecosystem, meaning priority shifts to parachain.

The questions are:

Do we need a standalone chain?
If yes, does having a standalone chain bring more upsides than downsides?
What are the reasons, and how would we make use of it?

Current development challenges:

• requires the support of two versions of pallet (ex. asset-registry);
• having primitive's CurrencyId type available for both versions, since the parachain-related trait is used there (feature flags probably could fix it, but still, it's something to be solved);

Other downsides:

• additional resources to develop, test and support. Every new feature should be developed and tested, taking into account the specifics of each chain. More infrastructure to support, run upgrades, monitor nodes, etc.;
• larger code base and possible code duplication;
• some features should be present only on one version of the chain (like cross-chain token transfers for the parachain, babe/grandpa vs. aura blocks production);
• possible divergences between live (parachain) and test (standalone) environments. Both chains might be in a different state with different versions, which may confuse;
• graph/frontend support;
• increases compilation time until we haven't created a service for feature flags utilization (ex. --parachain, --standalone).

[2075]

• imho we do not need to pursue explicit development of the standalone chain now
• we will need standalone chains connecting to zero chain at some point
• node/runtime setup should be flexible enough to build whatever we need using feature flags
• compile time can be reduced by commenting out unneeded builds, even in ci/cd
• standalone chain brings many upsides. flexibility in consensus and independence from polkadot ecosystem
• standalone chain provides proper validator setup with incentives for operators

conclusion

• i would deprioritise until needed again
• need a concept/idea for compute nodes in parachain setup
• need incentive ideas for node operators

[vayesy]

@2075 did I understand you right, that we can postpone support for the standalone chain and focus on parachain for now?
If so, next question arises.

At the moment there are few chains setup, two of which are standalone chains (alphaville & beeblebrox) and two are parachains (dev & rococo). We cannot use rococo as stable environment here due to fact, that Zero slot is not active all the time so chain would not be able to produce blocks periodically. I see it just as starting point for integration with other chains and features (like aUSD with Acala).
Since new chain versions would not be included for standalone version, I would suggest next:

1. Replace standalone chain with parachain on beeblebrox environment.
2. Use beeblebrox (or other chain?) for the stable (staging?) product release. This means it will contain working stack of the chain + graph (and probably frontend?), which was prior checked on other environments and proven to work without any issues.
3. Disable network switcher on the stable frontend and make it work only with single version of graph/chain.

Does that sound good?

[2075]

yes, please postpone the standalone chain support, we can catch up there later ( was not aware that anybody spent time on it recently tbh ).

I would use the staging relay/parachain, connect a graph to it ( done afaik ) and a frontend which works ( not done afaik ) and leave this running until we want to change this. like this it can be used by gamedao and partners as a showcase.

in this environment we can disable the network switcher if so wanted through the feature toggles in the graph.