Network Test Framework

After learning more about try-runtime a few weeks ago, I was thinking of a tool that could be useful for wallets/application developers. In brief, it would simulate the entire Polkadot network (including all parachains) for developers to test against, similar to Hardhat for Ethereum contract development.

This could be thought of as one layer above Chopsticks, which from my understanding looks like it’s targeted at parachain runtime developers who want to emulate the host functions of the Relay Chain runtime.

The main part that caught my eye was that try-runtime uses remote externalities to create a K-V database that eliminates the need for RocksDB and running an actual node. It just pulls the current state (which includes the Wasm runtime) and executes a given runtime upgrade directly, with some additional pre/post hooks.

So, given that all the Wasms are stored on chain, and try-runtime is already using the Wasm host to execute them, would it be useful to have a tool that pulls them all in and provides an API that shows every call available within Polkadot? Maybe a tool like this already exists (?), or some wallet teams like Talisman or Nova can comment on if something like this would be useful to pursue?

1 Like

Chopsticks already supports fork relay chains and it is part of the plan to make it support multiple networks so we can test XCM with it Support multiple networks · Issue #20 · AcalaNetwork/chopsticks · GitHub.

The goal of Chopsticks is to be able to one command fork the mainnets so we can run tests with mainnet data.

provides an API that shows every call available within Polkadot?

What do you mean? By API do you mean the extrinsic calls? Also simply knowing API/calls of a network is only useful for development purpose. There is no way we can present raw interface to users and expect they have a good experience with it.

The framework I have in mind is not for end users, it is for developers. The main point is that with just a Wasm host and K-V store, developers would not need to run nodes for every parachain they want to interact with. This is why I used “Polkadot simulator” and the comparison with Hardhat.*

Sorry about clarity on the API - as a simulator I didn’t just mean show the API metadata, but also actually execute the calls. For example:

  • Wallet developers could write unit tests that ensure successful decoding of every transaction they construct on every network.
  • Application/UI/UX developers could develop apps on a simulated “Polkadot back end”, without running one or multiple nodes on their machine.

Basically, spinning up a relay/multi-para network should not be a requirement for developers who want to write wallets/applications. I didn’t mean any criticism toward Chopsticks - it looks like a useful tool, but from my reading of the thread seemed targeted at a different audience (runtime developers). Although if it can do this too, then that’s even better. It should just have a different product/communication around it.

*This is a good example - ability to deploy/interact with a contract without running an Ethereum node, because it’s just simulating the EVM.

You are describing Chopsticks.

The plan is with one config file, it can fork the relaychain + multiple parachains. All without actually running any Substrate node. Smoldot will be used to execute the wasm runtime, which itself already supports running light clients for multiple chains so we know it will work.

Chopsticks is still very new but I already finding it super useful for many use cases. We intent to put resources into it and I do believe it can significantly changes how developers work with Polkadot ecosystem.

It is not just a testing tool, it is a customizable wasm runtime execution engine.

Those are for example other use cases that could be build on top of Chopsticks: Wasm view functions and Tool to dry run XCM transactions

2 Likes

In that case, awesome. I still don’t see why you need to run a client at all, why not just an emulator?

From reading the Chopsticks thread, though, I really understood that it’s a tool for parachain runtime developers, not application developers, which is why I started a separate thread. If it is for both, I really think it needs separate product/user stories to make that clear.

It doesn’t run a real client. It does use smoldot as the wasm executor but without all the real client part. e.g. there is no any p2p functionality. Chopsticks implements a test client by implementing the Substrate JSONRPC. Or in other words, it emulates a client.

We have expanded the scope of Chopsticks beyond the original post and we plan to apply for Polkadot treasury and are currently working on a new document about it.

1 Like

I think a great end goal that can be envisioned for Chopsticks is to run something like:

chopsticks --relay relay.wasm --para para1.wasm --para2.wasm --block-time 0.1s 

This will be a massive unlock for Runtime builders, and JS/CAPI/SubXT developers wishing to test their offchain applications in a quick way, or write e2e integration tests.

How far is Chopsticks from this?

From the chopsticks README:

npx @acala-network/chopsticks@latest xcm -r kusama -p karura -p statemine

I used it a while back and it worked alright.

1 Like

We are already using Chopsticks to write xcm e2e tests GitHub - AcalaNetwork/e2e-tests

2 Likes