Initial doc for running a local subtensor

[rajkaramchedu]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 18, 2024 6:41am
new-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 18, 2024 6:41am

[rajkaramchedu]

@eduardogr and @ifrit98 see below:

1. We use the terms "local blockchain" and "local subtensor" to mean different things. It can be confusing because a local blockchain is really a pair of local subtensor nodes. Also, in reality, "a local subtensor node," whether a lite node or an archive node, is really a public subtensor node because this node has incoming and outgoing peer connections. So, I wrote this document as "Running a Public Subtensor".
2. I want to document the command options we use here: https://github.com/opentensor/new-docs/pull/67/files#diff-ca25d8be23b5ece0a865da752092499cd5179fd0da5923141b52f69752940f86R102 for running a lite node and archive node. @eduardogr what do you think?
3. Also, is there a way we can document a step that verifies the correctness of the node sync? For example if we can document some way to print the latest block synced by the node, and the user can compare this to the scanner (explorer) display of the latest block? This would differ initially but after sync they both should be the same?
4. Also, the command line options seem to indicate the max allowed WebSocket connections with the peers, but can we also come up with a way to test the network connectivity of these nodes? This way the user can verify the network connection before making sure the node is all okay.
5. More important, can both an archive node and a lite node be run on the same machine? I think perhaps the IP addresses might collide? I want to document this and any other networking aspects, such as specific port #s that should either open or closed? I also want to write a similar section on networking for running subnet validator and a subnet miner. This might get us started.

[eduardogr]

shall we create 4 subsections as we have for docker for mainnet/testnet lite/archive ?

[eduardogr]

An alternative to create 4 sections to the same command and diff details....we could place the command that is common with a some env variables that has been set previously. Indicating the user to set just one of the "SPECIFIC_OPTIONS" exposed.

Something like this:

# different command options by network and node type
MAINNET_BOOTNODE='--bootnodes /dns/bootnode.finney.opentensor.ai/tcp/30333/ws/p2p/12D3KooWRwbMb85RWnT8DSXSYMWQtuDwh4LJzndoRrTDotTR5gDC'
TESTNET_BOOTNODE='--bootnodes /dns/bootnode.test.finney.opentensor.ai/tcp/30333/ws/p2p/12D3KooWRwbMb85RWnT8DSXSYMWQtuDwh4LJzndoRrTDotTR5gDC'
NODE_TYPE_ARCHIVE='--pruning=archive'
NODE_TYPE_LITE='--sync warp'

# mainnet archive
SPECIFIC_OPTIONS='$MAINNET_BOOTNODE $NODE_TYPE_ARCHIVE'

# mainnet lite
SPECIFIC_OPTIONS='$MAINNET_BOOTNODE $NODE_TYPE_LITE'

# testnet archive
SPECIFIC_OPTIONS='$TESTNET_BOOTNODE $NODE_TYPE_ARCHIVE'

# testnet archive
SPECIFIC_OPTIONS='$TESTNET_BOOTNODE $NODE_TYPE_LITE'

# command to run subtensor
./target/release/node-subtensor \
  --base-path /tmp/blockchain \
  --chain ./raw_spec.json \
  --rpc-external --rpc-cors all \
  --ws-external --no-mdns \
  --ws-max-connections 10000 --in-peers 500 --out-peers 500 \
  $SPECIFIC_OPTIONS

What about that?
But if it's convenient for us and it's better to hide details I could create a script for this to simplify the instruction and let it look like:

./run_subtensor main archive
./run_subtensor main lite
./run_subtensor test archive
./run_subtensor test lite

[rajkaramchedu]

This script idea is better. It saves the user from making mistakes. The only minor change I suggest is to make them as,

./run_subtensor mainnet archive
./run_subtensor mainnet lite
./run_subtensor testnet archive
./run_subtensor testnet lite

This way, it is closer to Docker commands.
Also, if you plan to use the below scheme in your script,

# mainnet archive
SPECIFIC_OPTIONS='$MAINNET_BOOTNODE $NODE_TYPE_ARCHIVE'

# mainnet lite
SPECIFIC_OPTIONS='$MAINNET_BOOTNODE $NODE_TYPE_LITE'

# testnet archive
SPECIFIC_OPTIONS='$TESTNET_BOOTNODE $NODE_TYPE_ARCHIVE'

# testnet archive
SPECIFIC_OPTIONS='$TESTNET_BOOTNODE $NODE_TYPE_LITE'

then I am thinking a slight change might make the script easy to understand. For mainnet archive, change the name SPECIFIC_OPTIONS to MAINNET_ARCHIVE_OPTIONS and so on for other cases also. That way, even the variable itself is self-documenting.

[eduardogr]

1. We use the terms "local blockchain" and "local subtensor" to mean different things. It can be confusing because a local blockchain is really a pair of local subtensor nodes. Also, in reality, "a local subtensor node," whether a lite node or an archive node, is really a public subtensor node because this node has incoming and outgoing peer connections. So, I wrote this document as "Running a Public Subtensor".

Yeah, i think that's perfect. We talk about "local subtensor" to make the difference between our finney endpoint and having your own subtensor. But having a guideline like this, i think that's implicit.

2. I want to document the command options we use here: https://github.com/opentensor/new-docs/pull/67/files#diff-ca25d8be23b5ece0a865da752092499cd5179fd0da5923141b52f69752940f86R102 for running a lite node and archive node. @eduardogr what do you think?

+1, I have commented something related to run the command that can lead us to expose better the details or hide the details and make the instructions clear and not exposed. Give it a look to that comment and let me know what you think. The TL;DR is, i could provide a script to run a subtensor command so people have a better and simpler guidelines (it's content would be the low-level documentation of the differences between those options)

3. Also, is there a way we can document a step that verifies the correctness of the node sync? For example if we can document some way to print the latest block synced by the node, and the user can compare this to the scanner (explorer) display of the latest block? This would differ initially but after sync they both should be the same?

Yeah, because we have the possibility that one node is not connecting with the bootnode and not being introduced to the network. I think that's one scenario that could happens. We can have a section for that and add scenarios as we discover them, what do you think?

4. Also, the command line options seem to indicate the max allowed WebSocket connections with the peers, but can we also come up with a way to test the network connectivity of these nodes? This way the user can verify the network connection before making sure the node is all okay.

so, that's actually something that's not going to come into play if the node is not explicitly exposed to the internet in their setup. We are not configuring that dimension so far. We are connecting the subtensor node with the networks but not exposing their APIs to the world for other users (unless their servers are doing this automatically, exposing all ports for example)

5. More important, can both an archive node and a lite node be run on the same machine? I think perhaps the IP addresses might collide? I want to document this and any other networking aspects, such as specific port #s that should either open or closed? I also want to write a similar section on networking for running subnet validator and a subnet miner. This might get us started.

They could, but we would have to add the capability of specifying ports. Right now both are using same set of ports, so, users will find a conflict if they try to run both at the same time. But that's possible if we add the capability of customize:

• ports
• blockchain database path

[rajkaramchedu]

2. I want to document the command options we use here: https://github.com/opentensor/new-docs/pull/67/files#diff-ca25d8be23b5ece0a865da752092499cd5179fd0da5923141b52f69752940f86R102 for running a lite node and archive node. @eduardogr what do you think?

+1, I have commented something related to run the command that can lead us to expose better the details or hide the details and make the instructions clear and not exposed. Give it a look to that comment and let me know what you think. The TL;DR is, i could provide a script to run a subtensor command so people have a better and simpler guidelines (it's content would be the low-level documentation of the differences between those options)

Yes, the script approach is better. Let's do that.

3. Also, is there a way we can document a step that verifies the correctness of the node sync? For example if we can document some way to print the latest block synced by the node, and the user can compare this to the scanner (explorer) display of the latest block? This would differ initially but after sync they both should be the same?

Yeah, because we have the possibility that one node is not connecting with the bootnode and not being introduced to the network. I think that's one scenario that could happens. We can have a section for that and add scenarios as we discover them, what do you think?

Perfect. Where can I find it so I can document it?

4. Also, the command line options seem to indicate the max allowed WebSocket connections with the peers, but can we also come up with a way to test the network connectivity of these nodes? This way the user can verify the network connection before making sure the node is all okay.

so, that's actually something that's not going to come into play if the node is not explicitly exposed to the internet in their setup. We are not configuring that dimension so far. We are connecting the subtensor node with the networks but not exposing their APIs to the world for other users (unless their servers are doing this automatically, exposing all ports for example)

Okay, understood. No action on this item for docs.

5. More important, can both an archive node and a lite node be run on the same machine? I think perhaps the IP addresses might collide? I want to document this and any other networking aspects, such as specific port #s that should either open or closed? I also want to write a similar section on networking for running subnet validator and a subnet miner. This might get us started.

They could, but we would have to add the capability of specifying ports. Right now both are using same set of ports, so, users will find a conflict if they try to run both at the same time. But that's possible if we add the capability of customize:

• ports
• blockchain database path

So, let's instruct them how to specify different ports and database paths for archive and lite nodes, then they can decide what to do. I will also add a warning note that keeping the values same for both node configurations will lead to conflicts. Is this too much extra work for you now? If yes, then we can postpone customization instructions and simply add warning about the conflict. I am okay either way.

[rajkaramchedu]

One other question. I use the terms "authority node" in describing the local blockchain. This is a nice way to avoid using the terms "validator" or "miner" in Bittensor blockchain. I want to describe a bit more what these authority nodes actually are and why they are two and how one is different from the other. @eduardogr? Thanks!