Starting with custom parachain runtime fails

[vikinatora]

Issue Description

I'm trying to import a custom runtime and observe it's behaviour. AFAIU you can do that by adding a genesis_wasm_path to the config. The runtime I'm using the latest rococo parachain one in order to verify that It's indeed possible before continuing with the customized runtimes.

[relaychain]
default_image = "docker.io/parity/polkadot:latest"
default_command = "polkadot"
default_args = [ "-lparachain=debug" ]

chain = "rococo-local"

  [[relaychain.nodes]]
  name = "alice"
  validator = true

  [[relaychain.nodes]]
  name = "bob"
  validator = true

[[parachains]]
id = 100
genesis_wasm_path = "genesis-wasm.wasm"

  [parachains.collator]
  name = "collator01"
  image = "docker.io/parity/polkadot-parachain:latest"
  command = "polkadot-parachain"
  args = ["-lparachain=debug"]

The startup crashes on creating temp-5:

Logs from temp-5 container:

2023-05-09 13:44:46 2023-05-09 10:44:46 Building chain spec    
2023-05-09 13:44:46 Error: 
2023-05-09 13:44:46    0: Other: Error parsing spec file: invalid hex character: , at 0 at line 218 column 11723310
2023-05-09 13:44:46 
2023-05-09 13:44:46   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2023-05-09 13:44:46                                  ⋮ 1 frame hidden ⋮                               
2023-05-09 13:44:46    2: polkadot::main::ha5f1b633794d3c30
2023-05-09 13:44:46       at <unknown source file>:<unknown line>
2023-05-09 13:44:46    3: std::sys_common::backtrace::__rust_begin_short_backtrace::h6d2245b14f448a23
2023-05-09 13:44:46       at <unknown source file>:<unknown line>
2023-05-09 13:44:46    4: main<unknown>
2023-05-09 13:44:46       at <unknown source file>:<unknown line>
2023-05-09 13:44:46    5: __libc_start_main<unknown>
2023-05-09 13:44:46       at <unknown source file>:<unknown line>
2023-05-09 13:44:46    6: _start<unknown>
2023-05-09 13:44:46       at <unknown source file>:<unknown line>
2023-05-09 13:44:46 
2023-05-09 13:44:46 Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.
2023-05-09 13:44:46 Run with RUST_BACKTRACE=full to include source snippets.
2023-05-09 13:44:46 copy files has finished

This suggests to me that the spec generation encounters an issue. I'm probably missing something but I can't seem to figure it out using the documentation. There aren't any examples using custom runtimes.

Steps to reproduce the issue

Steps to reproduce the issue

1. Download latest rococo parachain runtime
2. Create a config and reference the runtime using genesis_wasm_path
3. Run ./zombienet-macos spawn configs/config.toml

Describe the results you received

Network fails to build relay chain spec.

Describe the results you expected

Expected for the chain spec to be built successfully and the network to start.

Zombienet version

1.3.49

Provider

Kubernetes

Provider version

## For binaries
polkadot 0.9.41-e203bfb396e
polkadot-parachain 0.9.380-fe24f39507f 

## For Kubernetes/Podman
podman version 4.4.1

OR

kubectl version v0.26.3
cluster version 1.25.2

Upstream Latest Release

No

Additional environment details

No response

Additional information

No response

Screenshots

No response

[pepoviola]

Hi @vikinatora, thanks for your feedback. In this case yo need the hex representation of the downloaded file to use as wasm to include in the genesis (or register the parachain). You can use this snippet to generate the wasm

# buffToHex.js
const fs = require("fs");
const file = fs.readFileSync(process.argv[2]);
const buff = Buffer.from(file);
console.log(`0x${buff.toString("hex")}`);

And just run like this

node bufftoHex.js rococo-parachain_runtime-v9400.compact.compressed.wasm > genesis-wasm.wasm

And then should work using this file (genesis-wasm.wasm).

Ping me if you have questions, Thanks!!

[vikinatora]

Thank you @pepoviola, makes complete sense since it's referenced in the genesis.

[pepoviola]

Great, I will close this one. thanks!!

[reo101]

Me and my colleague @vikinatora are working on designing and developing a way to test the conformance of different parachains' PVF validate_block functions (stack and heap limits, time limit, etc). We've decided to use zombienet to aid us in our mission - we take a real parachain WASM blob, patch it to have some tracing in the validate_block function, "hex-ify" it for use with Zombienet and then run it on a real relay- and parachain combo, with the modified WASM on the parachain side. So far, we've tried to use genesis_wasm_path = "./some/path.wasm" to substitute in our modified WASM.

To test the waters we've been trying to launch a zombienet using the following config (in TOML):

Config

```toml [relaychain] default_image = "docker.io/parity/polkadot:latest" default_command = "polkadot" default_args = [ "-lparachain=debug" ] chain = "rococo-local" [[relaychain.nodes]] name = "alice" validator = true [[relaychain.nodes]] name = "bob" image = "docker.io/parity/polkadot:latest" validator = true args = ["--database=paritydb-experimental"] [[parachains]] id = 100 cumulus_based = true genesis_wasm_path = "./rococo_patched.wasm" [parachains.collator] name = "collator01" image = "docker.io/pepoviola/substrate-parachain-template-zombienet:v0.0.0" command = "parachain-collator" args = ["-lparachain=debug"] ```

Where ./rococo_patched.wasm is a patched version of the rococo parachain WASM which has the validate_block function just return 0 which should raise an error somewhere (since the returned i64 is seen as a pair of 32-bit integers holding a pointer and length to the actual "returned" data, and 0 is basically a nullptr) which is exactly what we are trying to catch happening.

We are having some trouble running a zombienet with that modified WASM (or in fact, any custom WASM). Although, we intentionally setup the chains to use a bad WASM, we expect the validator to operate normally, while the parachain to not to make any progress, because of the whole candidate backing process.

Here you can see (using the above config, same results with slight modifications to it as well) how the collator even refuses to start when given the injected WASM.

Here's the software used and its versions:

zombienet version: 1.3.52 - Installed using Nix, using the new packaging strategy from #1055 polkadot --version: polkadot 0.9.41-e203bfb - Also installed with Nix

Flake used:

```nix { inputs = { nixpkgs = { url = "github:NixOS/nixpkgs/nixpkgs-unstable"; }; zombienet = { url = "github:paritytech/zombienet"; }; flake-utils = { url = "github:numtide/flake-utils"; }; }; outputs = { self , nixpkgs , zombienet , flake-utils , ... } @ inputs : flake-utils.lib.eachDefaultSystem (system: let pkgs = import nixpkgs { inherit system; overlays = [ # zombienet.overlays.default ]; }; in { devShell = pkgs.mkShell { buildInputs = with pkgs; [ ### Main polkadot zombienet.packages.${system}.default ## Libs libiconv ]; }; }); } ```

Using this bash script to convert the wasm blob to hex

```bash #!/usr/bin/env bash src="${1}" dest="${2}" xxd -p "${src}" | tr -d "\n" | sed "s/^/0x/" > "${dest}" ```

[reo101]

Hey, @pepoviola, should we reopen this issue or create a new one?

[pepoviola]

Hey @reo101, thanks for the info. Let me try to reproduce, which provider are you using? Thanks!

[vikinatora]

We're using k8s on docker if that makes any difference.

[reo101]

Yes, the integrated k8s provider from Docker Desktop, running on MacOS.

[pepoviola]

Hi @reo101 / @vikinatora, I tested with this config and the network works as expected.

[relaychain]
default_image = "docker.io/parity/polkadot:latest"
default_command = "polkadot"
default_args = [ "-lparachain=debug" ]

chain = "rococo-local"

  [[relaychain.nodes]]
  name = "alice"
  validator = true

  [[relaychain.nodes]]
  name = "bob"
  validator = true

[[parachains]]
id = 100
genesis_wasm_path = "./rococo-v9420.wasm"

  [parachains.collator]
  name = "collator01"
  image = "docker.io/parity/polkadot-parachain:0.9.380"
  command = "polkadot-parachain"
  args = ["-lparachain=debug"]

Did you check the logs from the collator? Thanks!

[reo101]

Hi @pepoviola, thanks for taking the time to give this a spin. I've tried to run your config (modulo the wasm, see note) but, again, hit a road-block: the parachain does not seem to produce any blocks whatsoever.

Config

Rococo `wasm` *made* like this: ```bash wget "https://github.com/paritytech/cumulus/releases/download/parachains-v9420/rococo_runtime-v9420.compact.compressed.wasm" ./fix.sh ./rococo_runtime-v9420.compact.compressed.wasm > ./rococo_v9420.hex ``` where `fix.sh` (like before) is: ```bash #!/usr/bin/env bash src="${1}" dest="${2}" xxd -p "${src}" | tr -d "\n" | sed "s/^/0x/" > "${dest}" ``` And the `zombienet` config is: ```toml [relaychain] default_image = "docker.io/parity/polkadot:latest" default_command = "polkadot" default_args = [ "-lparachain=debug" ] chain = "rococo-local" [[relaychain.nodes]] name = "alice" validator = true [[relaychain.nodes]] name = "bob" validator = true [[parachains]] id = 100 genesis_wasm_path = "./rococo_v9420.hex" [parachains.collator] name = "collator01" image = "docker.io/parity/polkadot-parachain:0.9.380" command = "polkadot-parachain" args = ["-lparachain=debug"] ```

Conversly, this config manages to produce blocks:

Working config

Assuming the same `rococo_v9420.hex` ```toml [relaychain] default_image = "docker.io/parity/polkadot:latest" default_command = "polkadot" default_args = [ "-lparachain=debug" ] chain = "rococo-local" [[relaychain.nodes]] name = "alice" validator = true [[relaychain.nodes]] name = "bob" validator = true [[parachains]] id = 69420 wasm_genesis_path="./rococo_v9420.hex" [parachains.collator] name = "collator01" image = "docker.io/parity/polkadot-parachain:latest" command = "polkadot-parachain" args = ["-lparachain=debug"] ```

It seems the only change is the collator's version (380 vs latest) and the parachain id (100 vs 69420).

Again, I'm running on MacOS, Kubernetes on Docker Desktop.

[pepoviola]

Hi @reo101, sorry about the delay. Did you check the logs of the collator to review if there is some error or info? The config looks ok. Thx!

[vikinatora]

Hi @pepoviola, we couldn't figure out what was causing the issues, so we created a linux vm in order to run the tests and it's working perfectly there. We can probably close this issue since I believe it's not related to the chain spec but rather the OS.

[pepoviola]

Hi @vikinatora, thanks for you answer. Closing now, please re-open if needed. Thx!