feat: CVM for Solana

[dzmitry-lahoda]

This document outlines the background and requirements for the implementation of CVM on Solana. Very high level. To split into many more smaller parts.

It includes only links and terms that are difficult to search on the internet. For clarification and links, ask ChatGPT or search via GitHub/Sourcegraph (primarily in the ComposableFi/cosmos repositories).

CVM is an AST (Abstract Syntax Tree) that describes a recursive route to transfer assets locally or via IBC (Inter-Blockchain Communication) and exchange (swap).

This AST is then interpreted by an executor, which is currently a CW (CosmWasm) contract on Neutron/Osmosis/ComposableCosmosCentauri Cosmos Go IBC chains.

Recently, ComposableFi implemented Cosmos IBC in Rust for Solana.

IBC can transfer assets to/from Solana.

The next step is to implement the ComposableFi/emulated-light-client#229, which will be an SVM hook. This allows for the transfer of assets and the calling of a contract simultaneously. Solana is a very constrained environment, so it will likely need to be implemented as part of a single Solana IBC contract to avoid hitting call depth/compute limits.

After the ComposableFi/emulated-light-client#229 is completed, it will allow for calling a contract with assets transferred by IBC. This works in both directions, from Solana to Cosmos and back. From a user's perspective, it is as easy as adding a string to a transaction memo. However, these memos differ between Cosmos and Solana and change from chain to chain.

What if we want to write once and send that to any chain, and it will format the data as needed, including a shared representation of assets and accounts and multi-hops? That is what CVM aims to achieve.

Currently, the CVM interpreter is implemented for Cosmos CW. It is to be ported to Solana with a high degree of sharing. The CW side is extended with knowledge about the counterparty chain it sends to (that may require making part of Solana program SDK to compile to CW, like account derivations).

Target is easy to reproduce locally the scenario of sending an asset from the ComposableCosmosCentauri chain to Solana, swapping there, and moving funds back to be executed. All reasonable parts of the current CVM CW implementation are to be implemented on Solana too, to support routes found by the MANTIS Solver Blackbox.

[dzmitry-lahoda]

During implementation:

• Codes on Solana, CW, MANTIS Solver to reuse same code base and share Rust interfaces. High reuse is must.
• Fix composable-ibc relayer branch for solana if needed (Rust based backend server)
• Interfaces for TypeScript and Python generated.
• Python MANTIS blackbox maps Solana exchanges data (can start from highest volument contracts 3 pools) and maps them to CVM to unified format as part of solution. Routes be autodiscovered to be usefull.
• TypeScript examples to call Solana are shared and made a part of e2e TypeScript tests, so all FE/QA will understand how it works and will not be able to use and have robust quality gate.
• Easy to run container or nix package to see all things in action to be provided. One liner.
• Ability to run Cosmos->Solana->Cosmos and Solana->Cosmos->Solana programs to be here for sure :) And ability to update one share fork of ibc-rs to update ibc-rs in all contracts too.

All of above was done to CW CVM.

[dzmitry-lahoda]

First, finalize alignment on:
ComposableFi/emulated-light-client#229 (pure IX to solana inside packets)

In order to start building CVM on Solana need to:
implement Solana contract https://github.com/cosmos/ibc/blob/main/spec/app/ics-027-interchain-accounts/README.md . make TODO in ibc-core for missing parts. Split this task into phases.

Make basic CW interface compile to Solana by doing CW-core crate as per CosmWasm/cosmwasm#1956

After these are done:
Implement Cosmos IBC module interface for packets observation (need to error/rollback/fails handling - mentioned in cosmos/ibc-go#4706 ). In case of solana is convenient interface on solana accounts
Implement IBC core missing parts (proven state and state finalization)
Make official release pipeline for working and maintained Docker compose file with Solana IBC composable devnet ComposableFi/composable-ibc#439
Make Solana SDK to do Solana IBC calls from from CosmWasm

After these done:
Make solana IBC relayer to support LUTs
Make solana IBC relay support TX for ics27 facet.
Setup Jupiter protocol on devnet Solana
Added error/rollback/fails/state reading account to force relayer to pass accounts to contract
After these are done - make e2e tests of IBC calls back and forth.
Setup dummy contract to call to Solana from CW
Fix ICS27 setup on Composable Cosmos and make it merged to validators nodes
Deploy indexer for LUT extension events(and any other Anchor events) from simulator(and executor) for debugging

Release to mainnet:
Upgrade ibc-core contract
Setup owner of ics27 facet

None of an on chain code (in solana programs) of above code will verify accounts provided by relayer and will assume these are correct.
Async ACK is not supported (because of old ibc-rs usage).

Adding new facets or upgrading existing ones(like making CVM global lookup table part of ICS27 call or separate contract) will not need to change the IBC core nor relayer.
Optimization of accounts reuse is out of scope of prerequisites.

And start designing and building CVM from here.

[dzmitry-lahoda]

need dynamic accounts before LUT

[github-actions]

stale-issue

[dzmitry-lahoda]

up