paritytech / paritytech/try-runtime-cli
Expose RPC endpoint
Personne n'a encore pris cette 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
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- 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