Introducing local-polkadot

1

Hello polkadot users. I would like to introduce a handy tool that I have been developing and using to streamline the process of setting up a local polkadot rpc node and polkadot-js-apps explorer without the hassle of multiple terminals or remembering what polkadot --flags to use.

I call it local-polkadot because that’s what it does. It downloads, prepares and runs polkadot --chain polkadot --tmp --rpc-port 9944 and some more opts and apps for you in a single command and lets you explore polkadot mainnet quicker than say when using a rpc node that’s seeing heavy load during peak hours.

This is possible because of warp sync a feature without which this wouldn’t work. Just run local-polkadot and give it a couple of minutes to install explorer node_modules dependencies and warp sync with mainnet. You may refresh the explorer tab once you stop seeing warp-sync logs in your terminal.

It runs each time with warp-sync and --tmp so as to not leave any persistent state in your system. It will download the latest polkadot and apps source code from github releases and place them in $HOME/.local-polkadot or a --path <path> of your choosing. You may even run local-polkadot with --tmp to store nothing anywhere, or --fresh to update downloaded artifacts in $HOME/.local-polkadot.

My main motivation for creating this tool was to declutter my terminal and reduce frustration when I would be staring at the staking dashboard, waiting for minutes for it to load. I found that running a local polkadot node mitigates that drastically and thus due to a combined need for simple one command launch + good bandwidth, local-polkadot was born. Furthermore, I just feel more secure using polkadot in a decentralized way. :stuck_out_tongue_winking_eye:

It does have a few system dependencies at the time of writing, such as bun and curl and unzip, but subsequent releases might knock out a couple and replace them with rust-crate dependencies. I also might add support for kusama.

If you find it useful or if you have any improvements to add, please do let me know.
GH: GitHub - weezy20/local-polkadot: Run polkadot RPC node and explorer with 1 command
demo

3 Likes
2

Have you ever tried interacting with the Polkadot network using Polkadot/Substrate Portal and found it to be frustratingly slow?

Too much load on the rpc server can lead to a bad user experience.

Alternatively, you could just use https://dev.papi.how which -by default- connects to the polkadot relay-chain using a light-client (smoldot) that runs on the background of your browser :wink:

5 Likes
3

nice! didn’t know about that.

1 Like
4

Cool, will check it out.

Just tried using zombienet the other day, still struggling to get it to work for my Substrate chain that’s not supported (messing around with adding network support) - wouldn’t mind to have something that works (and --network sounds encouraging, I hope it’s easy to add other Substrate networks).

My use case is simple - no complex testing and workflows - so I wouldn’t mind a KISS approach, especially if I could warp-sync from LAN nodes where I have a chain archive node (although, to be honest, I should just rsync that into the chain and then start this local setup).

That’s interesting. Can you add -n xxnetwork (details)? I use that on LAN.

1 Like
5

@somedude I tried running a local setup with zombienet and was able to do it for the substrate kitchensink node, but for my local network, it would fail during the build-spec process. Not sure if that was a limitation of my chainspec.rs file or zombienet, I am yet to find that out. Here’s the toml file I used with the substrate kitchensink node.

[relaychain]
default_command = "./target/release/node"
chain = "dev"

  [[relaychain.nodes]]
  name = "alice"
  validator = true

  [[relaychain.nodes]]
  name = "bob"
  validator = true

is the configuration I used.

Coming to local-polkadot, the main pain point it solves (for me at least) is to interact with already deployed networks and not relying on public rpcs. I think zombienet should still be the preferred method of spinning up local networks.

2 Likes
6

Thank you for sharing. I’ve hit a similar problem and got stuck (plus I’ve hit network-specific problems on several other projects I’ve been evaluating, so it’s been too many problems, too little time).

I may revisit zombienet and try again.

(Tangentially related to this, I recently used zombienet to eval another chain, and noticed some flakiness with testnet coin generation and transfer from one address to another, which made me spend time on learning how to deal with that, at which point I though I’d rather use mainnet because the coin I use is very cheap - for me it’s inexpensive to use mainnet rather than deal with bugs and complexity).

I looked at your repo and it seems it should work with other Substrate chains/networks, right?

7

Yeah it should. Just changing the POLKADOT const to whatever RPC url, and options and it should work. It’s just spawning 2 processes at the end of the day.

1 Like