Dependency on Moonbeam crates

[NunoAlexandre]

Context 🗺️

The Centrifuge Chain’s Connectors pallet depends on the following crates of interest to facilitate some of its features:

• provided by the PureStake/Moonbeam repository:

  • pallet-ethereum_xcm
  • pallet-xcm-transactor
  • xcm-primitives

• provided by the PureStake/frontier repository:

  • pallet-ethereum

The pallet-xcm-transactor offers all the infrastructure and functionality needed to send a Transact XCM message from the origin chain (Centrifuge) to a supported destination chain (only Moonbeam supported now). A Transact instruction requests the destination chain to execute a specific call that is encoded by the origin chain. In the case of Connectors v0, we request to transact an ethereum_xcm call that targets the ConnectorXcmRouter smart contract that is expected to be deployed in a Moonbeam chain.

With the use case in mind, all the other enumerated pallets offers the necessary types and calls that allow us to build the complete encoded call that will be decoded and executed on the Moonbeam side.

Problem 🐞

Moonbeam is a Substrate-based chain just like the Centrifuge chain. However, whereas the latter depends on the official and original supporting framework crates from paritytech, Moonbeam depends on their own forks of those.

I.e, whereas Centrifuge depends - for exampe - on github.com/***paritytech***/substrate, Moonbeam depends on github.com/***PureStake***/substrate. The same applies to any crate located in the polkadot and the cumulus repositories.

That divergence in dependencies is a major trouble for cargo since we are essentially attempting to both pull crates directly from ***paritytech***/{substrate|polkadot|cumulus} AND indirectly from ***PureStake***/{substrate|polkadot|cumulus} by depending on the Moonbeam crates enumerated above. This setup results in duplicated versions of all overlapping crates, which makes it impossible for cargo to successfully compile the Centrifuge Chain.

Workaround 🔨

The workaround we found to get the Centrifuge chain to compile successfully with this setup involves forking **PureStake**/Moonbeam and all the internal **PureStake/** repositories that the former depends on and change them so that they also point directly to ***paritytech***/{substrate|polkadot|cumulus} instead of ***PureStake***/{substrate|polkadot|cumulus}.

Pros/Cons

Whereas this is a simple solution, it is just as tedious, given that we either need to repeat this process for every new release of polkadot or we need to go through an enormous git conflict resolution, which may be aggravated shall any of the crates have changed their list of dependencies.

Another con is the fact that we are dependant on Moonbeam to fully upgrade to a new release of polkadot, since we first need them to upgrade to said version in order for us to update this fork.

Explored Alternatives ☑️

• Cargo patch feature

  This option didn’t cut it for us since it’s designed to handle multiple versions of the same crates from the same source. However, in our use case the duplicated crates originate from different sources (paritytech and PureStake)

  We tried to point to the official PureStake/Moonbeam repository instead of our own Moonbeam fork and set the patch feature. See branch cargo-patch-v0.9.29. We were able to get to a point where cargo no longer failed to handle the dependencies by force setting a specific revision from paritytech/{substrate|polkadot|cumulus} for every crate, but the compiler later fails since the compiler can’t convert types that originate in the paritytech source from and to functions and types that originate in the pureStake source, as they are effectively different types from the pov of the compiler. An example error we see here is:

Alternative Options 🧗

We can still try a few alternative options.

• Cargo Source Replacement

  This feature essentially allows us, from a single toml location, overwrrite all the dependencies of the Moonbeam repo to actually point to paritytech instead of PureStake. This would take place in our fork of Moonbeam and shouldn’t require any conflict resolution neither redoing any work for every new release of polkadot besides syncing our fork with the latest Moonbeam release of polkadot.

  A cons here is that this feature only works if the code of the source that’s replacing the original source of the dependencies is equal to the latter. That is, shall Moonbeam add new or alter functionality in their forks of {substrate|polkadot|cumulus}, following to the documentation of this feature the setup would fail.

• Drop all dependencies

This is a more radical alternative and it involves dropping all the dependencies on the Moonbeam crates. To replace xcm_transactor, we would write our own copy of said crate and for the remaining crates and their types used to build the encoded call wrapped in the Transact XCM instruction, we would build them manually.

A con of this approach is that we need to manually keep a very close look on any change in the Moonbeam repo regarding the crates of interest. A way to mitigate this effort would involve setting up true end-to-end tests which would allow us to quickly verify whether our current solution still works against a specific version of Moonbeam.

Another con is that it’s much more tedious to develop and therefore maintain such a solution.

• Copy all the relevant dependencies

A variation of the previous alternative which would mitigate the level of effort to develop and maintain such setup would involve simply copy the relevant crates to a separate, internal repository and - again - manually keep an eye on the original repository and stay up to date with any relevant change.

A cons of this approach is that for every change, the level of effort to keep up with changes may vary since such change may involve a new dependency which would complicate the whole dependency model.

And yet again, this setup would require us - rightfully so - to write true e2e tests to verify the latest revision works as expected.

[NunoAlexandre]

Update

I went on re-exploring the cargo patch option and learned a few interesting things.
First, it possible to use it to both state that we want to only use a specific revision of a crate within a specific source as well as to tell cargo to use a specific revision from a different source.

So for example we can have both of these statements:

[patch."https://github.com/paritytech/substrate"]
frame-benchmarking = { git = "https://github.com/paritytech//substrate", rev = "cc370aa61e15c18d23a2f686b812fd576a630afe" }

[patch."https://github.com/PureStake/substrate"]
frame-benchmarking = { git = "https://github.com/paritytech//substrate", rev = "cc370aa61e15c18d23a2f686b812fd576a630afe" }

The first tells cargo that, shall there be multiple versions of paritytech/substrate around, it should only use the revision cc370aa61e15c18d23a2f686b812fd576a630afe.

The seconds tells cargo that shall there be any version from PureStake/Substrate, that it should actually use the paritytech/substrate's revision cc370aa61e15c18d23a2f686b812fd576a630afe.

I managed to get cargo test -p pallet-connectors working on the branch cargo-patch-v0.9.29. The runtime-integration-tests are still failing tho.

But this is still a step in the right direction 🚀

[NunoAlexandre]

Update on the last message

I managed to get the development_runtime compiling 🥳 The integration tests still fail but this time because of some compilation error on Fudge:

Compiling fudge-core v0.0.10 (https://github.com/centrifuge/fudge?branch=polkadot-v0.9.29#782fefc5)
error[E0277]: the trait bound `MemDb: sc_client_db::Database<H256>` is not satisfied
   --> /Users/n/.cargo/git/checkouts/fudge-665fee1078ebbc96/782fefc/core/src/provider/state_provider.rs:113:9
    |
113 |                 db: Arc::new(MemDb::new()),
    |                     ^^^^^^^^^^^^^^^^^^^^^^ the trait `sc_client_db::Database<H256>` is not implemented for `MemDb`
    |
    = help: the trait `sc_client_db::Database<H>` is implemented for `sp_database::mem::MemDb`
    = note: required for the cast from `MemDb` to the object type `dyn sc_client_db::Database<H256>`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `fudge-core` due to previous error

[NunoAlexandre]

The fudge error reported above was caused both by faulty local cache and a duplicated crate (sp_datatabase) fetched from fudge, which wasn't included in the cargo patch rule for substrate. Solved now and the whole repository works ✅

I will try and use this wip setup and point directly to the official Moonbeam repo now.

[NunoAlexandre]

Got it working in #1120 🥳