paritytech / paritytech/try-runtime-cli

Expose RPC endpoint

未关闭
#9 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

enhancement good first issue
主要语言
Rust
星标
25
派生
29
PR 合并指标
30 天内没有已合并 PR

描述

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.

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

阅读 try-runtime CLI 中 execute-block 和 fast-forward 的流程,然后检查 remote-externalities 如何提供测试状态。定义受支持的基于状态的 RPC 子集,包括 state_getStorage,并验证 try-runtime fast-forward 1000 --rpc 在执行后仍保持 RPC 服务器运行,以便 Polkadot JS 检查生成的状态。

由索引模型根据 Issue 内容生成。

评估

技术栈
rust
领域
api, blockchain, cli
Issue 类型
功能
难度
5/5
预计耗时
一周以上
活跃度
停滞
描述清晰度
需要澄清
新手友好度
25/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。