paritytech / paritytech/try-runtime-cli

Expose RPC endpoint

Ouverte
#9 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

enhancement good first issue
Langage dominant
Rust
Étoiles
25
Forks
29
Métriques de merge des PR
Aucune PR mergée en 30 j

Description

Original issue https://github.com/paritytech/substrate/issues/13563

When we do follow-chain, it would be useful to have the basic RPCs implemented and exposed on a specific port, so that you can connect PJS Apps to your fake chain.

An alternative for this is to actually integrate this in the node. https://github.com/paritytech/substrate/pull/12537 envisioned that you would be able to run a node that is normally syncing, but instead of calling Core_execute_block, it would call into TryRuntime_execute_block. This would give us a fully working client.


Relevant comment: https://github.com/paritytech/substrate/issues/13563#issuecomment-1498622775

the scenario that he is interested in is:

You run execute-block or fast-forward, and once the block have all executed, you want to inspect the state.

one way to approach this is to make try-runtime cli programmable, so you can define more tests to be written, but this is a holy PITA in Rust.

an easier way, which Alan from Moonbeam is also asking is, to make the try-runtime cli capable of implementing a few important RPCs like state_getStorage and so on, and then we query it with Polkadot JS api/apps.

in principle, I think this is not hard, but I have no idea how hard it is.

So, imagine the try-runtime CLI being able to return a value to a subset of the RPC requests, namely all of the ones that can be answered by having a state.

because end of the day, try-runtime-cli is just a wrapper for remote-externalities, which is a "test state".

the problem though is that the underlying remote-ext can have a partial state etc. So there are a lot of edge cases that we may not be able to handle, and developers might confuse themselves.

For example, you would run:

try-runtime fast-forward 1000 --rpc and this will run 1000 empty blocks for you, and the process is still running, hosting an RPC server.

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Lisez le flux du CLI try-runtime pour execute-block et fast-forward, puis examinez comment remote-externalities fournit l’état de test. Définissez le sous-ensemble de RPC pris en charge et adossé à l’état, y compris state_getStorage, et vérifiez que try-runtime fast-forward 1000 --rpc maintient un serveur RPC en fonctionnement après l’exécution afin que Polkadot JS puisse inspecter l’état résultant.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
rust
Domaine
api, blockchain, cli
Type d'issue
Fonctionnalité
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
À l'abandon
Clarté
À clarifier
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.