8 posts were split to a new topic: Hosting a Virtual Node from Home
How to host a Virtual Node
Hi anon,
I rent an ubuntu server on Digital Ocean. But I used the console of my Windows PC to run it and not the Console in Digital Ocean. If now I close the console on my laptop, the node stop working?
Update: I close console on my laptop but on Digital Ocean server seems to be still high usage of CPU so I guess node is still live, can someone confirm it? Thanks 
Your node being active relates to the server it is running on, not the device the software was started with.
who is anon?
1 Like
anonymous! 
How can I check if my vnode is live and is working before staking 1750prv?
we have a user who picked that name, so it looks a bit weird. At first I thought you were replying to his messages and ended up creating new posts instead.
All you need to check your vNode is in this post
1 Like
@khanhj. Is the run_2.sh script still valid with all the changes that have been made, specifically, the eth_mainnet is commented out here, do we no longer need eth_mainnet running on vNodes?
If we do, how would you modify this script to add it back? More specifically, how would you add it into this script:
I tired to modify the script above to add the:
docker network create --driver bridge inc_net || true
docker run -ti --restart=always --net inc_net -d -p 8545:8545 -p 30303:30303 -p 30303:30303/udp -v $PWD/eth-mainnet-data:/home/parity/.local/share/io.parity.ethereum/ --name eth_mainnet parity/parity:stable --light --jsonrpc-interface all --jsonrpc-hosts all --jsonrpc-apis all --mode last --base-path=/home/parity/.local/share/io.parity.ethereum/
but the eth_mainnet container seems to be restarting all the time… the inc_mainnet’s are running and syncing fine
here is the relevant code snippet:
docker pull incognitochain/incognito-mainnet:${latest_tag}
docker network create --driver bridge inc_net || true
docker run -ti --restart=always --net inc_net -d -p 8545:8545 -p 30303:30303 -p 30303:30303/udp -v $PWD/${eth_data_dir}:/home/parity/.local/share/io.parity.ethereum/ --name eth_mainnet parity/parity:stable --light --jsonrpc-interface all --jsonrpc-hosts all --jsonrpc-apis all --mode last --base-path=/home/parity/.local/share/io.parity.ethereum/
for i in "${!validator_keys[@]}"
do
docker run --restart=always --net inc_net -p $((9334 + $i)):$((9334 + $i)) -p $((9433 + $i)):$((9433 + $i)) -e NODE_PORT=$((9433 + $i)) -e RPC_PORT=$((9334 + $i)) -e BOOTNODE_IP=$bootnode -e MININGKEY=${validator_keys[$i]} -e TESTNET=false -v $PWD/data${i}:/data -d --name inc_mainnet_${i} incognitochain/incognito-mainnet:${latest_tag}
done
you don’t need that container running anymore.
1 Like
Hey @doc,
I personally prefer using Infura (a 3rd party service - free 100000 requests/day). As running eth-client docker will consume server power/resource.
Please check this file: run_3.sh for sample config
2 Likes
Thanks @khanhj… do we need the eth-client (or Infura) running on our vNodes anymore? From @Jamie comment, I didnt think it was needed… but with the updated script your provided, it sorta looks like we do, so just wanted to get some clarification on this too. Thanks!
For now Infura/eth-client required to verify blocks that have shield/unshield transaction.
We’re working on the upgrade that validator doesnt require eth-client anymore. Will keep u guys inform when this release.
2 Likes
Hi @Jared,
- Committee selection is totally random.
- Eth-client(parity) or Infura is required to validate new shard blocks
1 Like
@khanhj Just an FYI… based upon comments seen in this thread and others, I dont think everyone is running an Eth-clinet on their vNode… I dont really understand what the repercussion of this is, as I know I had vNode selected, part of committee for multiple epochs and it did not have the eth-client running.
I plan on adding it back now that you have stated it is needed, and provided the updated script for showing how to add it… but I am not sure wha this means for the chain, that we have several people running vNodes without an eth-client.
Fastest way to add eth_mainnet back to your server is to just rerun the script.
The updated script @khanhj provided,
I am more curious about how this effects the overall chain, since there are apparently multiple people who did not think it was needed and @mesquka mutlinode script has the Eth client removed:
1 Like
@doc Ah, my mistake. I’m still using the old script and hadn’t checked to see if a new one was available.
1 Like
Hi @doc
I’ll check with CS team to update the official run.sh script. As i said before, when validate block that have shield/unshield (deposit/withdraw ETH/ERC20), the docker inc_mainnet will query data from eth-client, that why we need ETH Parity docker running (or query via Infura service)
The reason why your node could still earn without eth-client is that your node would have been in a shard that gave enough proper votes to commit a new block.
Here is a sample screenshot of testnet:
@Peter can you please check our official run.sh file?
1 Like
@Peter and @khanhj Just to be clear, I am sure the official file is fine, what I am referring to is the file that was created here, and is used by several people (which all have more than 1 vNode, so could be a substantial portion of the community validators), does not utilize the eth-mainnet.
There seems to be confusion among community and incog team members (if you look at the responses in last few days to both threads), that didn’t think it was necessary anymore. It appears this is ok because Incog core team hold 2/3 of validator spots, but surely sounds like something you would want to point out to vNode owners, especially those running that script.
I assume its not really a huge issue until new shards and spots are opened up, and that has been pushed out to mid 2021, but IMHO it doesn’t sound great that possibly a large portion of the community run validators would be returning invalid results for shield/unshield transactions… Of course if the dev team is looking to remove the dependency before the new positions and shards are opened up, then its really moot.
Just trying to elevate an issue that could arise in future based upon confusion that has been seen and now cleared up.
1 Like