Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement fork from live chain capabilities #988

Open
cmichi opened this issue Feb 28, 2023 · 9 comments
Open

Implement fork from live chain capabilities #988

cmichi opened this issue Feb 28, 2023 · 9 comments
Assignees
Labels
blocked This task is blocked until blockers are resolved. OpenZeppelin

Comments

@cmichi
Copy link
Collaborator

cmichi commented Feb 28, 2023

This is an involved issue. Before any implementation is started, please discuss the design of the CLI API here.

To facilitate testing and development, it would be convenient to have the ability to implement fork capabilities in cargo-contract. This feature would allow developers to test their smart contracts using the current state of a target blockchain, which can help identify and fix potential issues before deploying the contract to a live network.

This will be more involved, there is existing tooling in the Substrate ecosystem and this command should be built just using Rust dependencies.

Starting points:

@kianenigma
Copy link

I think nowadays Chopsticks from Acala is also a very good tool and should be considered.

@kianenigma
Copy link

@brunopgalvao asked me about this and I rather write my thoughts here for the sake of posterity.

Executing the contract is at the end of the day just another call into the runtime, and if you want to "execute a particular runtime API call, on top of a particular state", then the underlying machinery used in try-runtime, or perhaps itself directly, can be used.

ATM only nodes that integrate try-runtime-cli can use the high level CLI. That means it can be part of some kind of a contract node, not this repo.

That being said, we are working with AlephZero to move it to a new repository, usable as a library. paritytech/try-runtime-cli#1

@brunopgalvao
Copy link

Thanks @kianenigma.

Looks like substrate-contracts-node currently does not have the try-runtime cli configured.

A few scenarios that I see:

  1. Wait for try-runtime to be its own separate tool
  2. Look into integrating try-runtime into substrate-contracts-node ( this could be more involved )
  3. Acala's chopsticks could be a good solution to this ( I will look into it)

@brunopgalvao
Copy link

brunopgalvao commented Mar 14, 2023

Also, one thought that I have, teams that are building with pallet-contracts most likely use Cumulus (or parachain template) (which has try-runtime already configured) and add pallet contracts vs forking substrate-contracts-node. If so this could be good because it means that they already have try-runtime available. For demo purposes, we can configure a substrate node with pallet contracts or configure substrate-contracts-node with try-runtime and run the ink! e2e tests off of this try-runtime enabled node.

@kianenigma
Copy link

Look into integrating try-runtime into substrate-contracts-node ( this could be more involved )

This is actually a fairly simple thing to do. If you look into now it is integrated into node-template, is is merely adding a new CLI subcommand, and the rest is handled elsewhere.

@brunopgalvao
Copy link

brunopgalvao commented Apr 23, 2023

Thanks @kianenigma

This is actually a fairly simple thing to do. If you look into now it is integrated into node-template, is is merely adding a new CLI subcommand, and the rest is handled elsewhere.

I replicated how the node-template integrates try-runtime. You can see my work here:

I am running into the following issue when running try-runtime on the contracts node:

2023-04-23 10:56:06.342  INFO main try-runtime::cli: subscribing to "chain_subscribeFinalizedHeads" / "chain_unsubscribeFinalizedHeads"    
2023-04-23 10:56:06.344  INFO main remote-ext: since no prefix is filtered, the data for all pallets will be downloaded    
2023-04-23 10:56:06.345  INFO main remote-ext: scraping key-pairs from remote at block height 0x0000000000000000000000000000000000000000000000000000000000000000    
2023-04-23 10:56:06.345 ERROR main remote-ext: Error = Call(Custom(ErrorObject { code: ServerError(-32000), message: "Client error: UnknownBlock: Header was not found in the database: 0x0000000000000000000000000000000000000000000000000000000000000000", data: None }))    
Error: Input("rpc get_keys failed")

So the issue here, most likely is that the contracts node does not use BABE/GRANDPA instead it uses manual-seal. I don't believe it will be able to get keys. This PR which removes aura and grandpa and implements manual-seal may help:

Details on how to replicate the issue:

@cmichi
Copy link
Collaborator Author

cmichi commented May 17, 2023

Current state of the issue: We want to implement it via Chopsticks. Bruno got pretty far here, but it then turned out that smoldot (which Chopsticks uses) doesn't support pallet-contracts yet, due to missing support for child tries. This issue is currently blocked by this.

There are two ways how this issue can be unblocked:

@cmichi cmichi added the blocked This task is blocked until blockers are resolved. label May 17, 2023
@ashutoshvarma
Copy link
Contributor

PR smol-dot/smoldot#166 is now merged, and smoldot should support pallet-contracts now, if I understand correctly?
Also chopsticks was recently updated to use new smoldot version, that should have the above PR but when running Astar (or any other runtime with pallet-contracts) it failed to deploy/interact with contracts.

@brunopgalvao
Copy link

You are correct. However, chopsticks is still using version 0.8.0 of smoldot:

Which it looks like it is linked to this commit:

The child trie support is in version 0.9.0 of smoldot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked This task is blocked until blockers are resolved. OpenZeppelin
Projects
None yet
Development

No branches or pull requests

4 participants