improvements: refactor to be able to support non-cosmos chains

[Anmol1696]

Redefining Primitives for Starship to Support Multiple Chains

Overview

The current design of Starship is centered around supporting cosmos chains. As the project aims to expand its capabilities to support more types of chains (starting from issue #155), it becomes necessary to redefine some of the core components used in Starship. This proposal outlines the key changes needed to achieve this goal, including introducing a kind field in the configuration, defining testing procedures for non-cosmos chains, handling chain expansion, and managing Docker images for new chains. Additionally, other services and toggles, such as explorers and registry, will also be addressed.

Proposal: Introducing kind of Chain

chains

To enable support for different types of chains, we propose introducing a new field called kind in the configuration file. This kind field will signify the ecosystem to which a particular chain belongs. Here's an example of how the configuration would be updated:

chains:
  - name: osmosis-1
    type: osmosis
    kind: cosmos
    ...
  - name: eth-4
    type: eth
    kind: ethereum
    ...

The kind field will be crucial as Starship expands, allowing for easy categorization of chains based on the ecosystem they belong to.

relayers

Relayers is something that can remain the same. Since relayers are running between 2 chains, ecosystem or kind keyword wont matter.

relayers:
  - name: new-bridge
    type: <crosschain-bridge-type>
    chains:
    - osmosis-1
    - eth-4

explorers

Same for explorers, the kind of explorers should inherit the kind of ecosystem it operates in

Note: There could be additional directives that are ecosystem specific, that might need to be spun up or handled seperately. This might cause directives to be ecosystem specific. (non-ideal)

Other feature toggles and paradigms

As part of this expansion, we need to redefine additional toggles, services and paradigms to accommodate different ecosystems. This includes:

1. Testing of Non-Cosmos Chains: To support non-cosmos chains, we'll need to establish different types of tests tailored for each ecosystem. The details of these tests and the testing framework will be defined in the documentation.

2. Addition of new ecosystems: We should outline a clear process for adding new kinds of chains to Starship. This process will include guidelines on adding support for new ecosystems, configuring chain-specific parameters, and ensuring proper integration.

3. Docker Images for New Chains: As new chains are introduced, Docker images will need to be created for each chain to facilitate deployment. Documentation and guidelines should be provided for maintaining and managing these images.

4. Other Services and Toggles: The proposal mentions explorers and registry as additional services. Further details should be provided on how these services will interact with different chains and how they can be toggled based on the chain's ecosystem.

Alternative Proposal: Separate Helm Charts per Ecosystem

An alternative approach to consider is the introduction of separate Helm charts for each ecosystem. This would involve having dedicated configuration files for individual ecosystems. Although these ecosystems reside in the same Kubernetes cluster namespace, communication between them can be facilitated through environment variables within the cluster or via a shared registry service acting as a central point of entry.

Note: The proposal acknowledges that interchain bridges or relayers might pose challenges when passing information across ecosystems.

In this alternative approach, each ecosystem will have its own configuration and initialization process using specific Helm charts, tailored to the unique requirements of that ecosystem.

References

To support the implementation of this proposal, the following references may prove useful:

• Helm Chart Dependencies
• Helm Tests
  By incorporating these changes and considering the alternative approach, Starship can be redefined to efficiently support various blockchain ecosystems, ensuring a robust and extensible platform for the future.

Conclusion

Currerntly both the approaches seem to have some caviates. A clean solution with seperate helm chart is currently what seems to make most sense. But more edge cases needs to be cleared out.

[Inkvi]

2 cents from Polymer's perspective. We need to run relayers that can relay packet between two separate ecosystems, e.g. eth and cosmos. Will the alternative proposal allow this kind of communication?

[Anmol1696]

Can you share the information needed of the 2 ecosystems that would be needed by the relayer?
Since these 2 helm charts are being deployed in the same namespace, there will be alot of context sharing, which Polymer could use.

If there is a k8s resource of the relayer that runs in between, do let me know.

Will the alternative proposal allow this kind of communication?

Yup, we want to support polymer requirements as the first class citizen for the alternative approach. Could you share more context, and I can make it part of the tests (to be able to run similar topology)

[Inkvi]

Right now I have a separate branch where I run 3 chains eth<->polymer<->wasmd with 3 relayers.

• go-relayer as a regular IBC relayer between polymer and wasmd chains.
• Eth-relayer and vibc-relayer to relayer packets between eth and polymer. For eth-relayer to work it has to access rpc endpoints from eth and polymer. Beyond that it needs access to a shared volume that is used by polymer chain to properly create a light client for eth.