How to setup your own node in a blink of an eye (Now support multi-nodes per host)

Oh, now I get it. Thanks a lot. Now it is stakable.

2 Likes

Hey @Support,

To avoid the risks of Ethereum full-node centralization (i.e. infura), is it possible to use our own Ethereum full-nodes?

For example, I’m a StrongBlock (provides single-click Ethereum fullnode setup) operator and have multiple Ethereum full-nodes which are ready to use with their RPC and WSS endpoints.

Thanks.

Hi @abduraman,

I think you just need to change the GETH_NAME into your RPC fullnode URL then all is well.

You’re totally able to do that, just change the GETH_NAME to your StrongBlock host

2 Likes

Will try. Thanks.

Hello I am trying to set up a full node by referring to this article @sid @Gaurav_Saini

I had a few queries though

  1. What are the minimum requirements for the VPS in order to run the full node? I read an article here which gives me the bare minimum requirements, also I posted a query on this topic and got mixed replies. Please let me know if the below-mentioned specs will be enough for running a full node?
  • 6 CPUs
  • 16 GB RAM
  • 400 GB SSD
  1. What do I do with the validator keys in the install script? I only intend to set up a full node for data retrieval purposes.

Please find the section below :

VALIDATOR_K="validator key 1,

validator key 2,

validator key 3"

Do I delete this part or do I set it as empty ie VALIDATOR_K=""?

  1. How will I know that the full node is synchronized up to date? I read in this article that we can Send request getbeaconbeststatedetail to our full node and if the If my epoch number “Epoch”: 932 is same as Incognito’s website https://mainnet.incognito.org/ , then your full node is synchronized up to date. Is this correct?
  1. The hardware config is good enough. but since the current data of a typical fullnode is now around 150GB, so I think you should throw in some more SSD if you plan to use it for a long time.
  2. For the best, you should set it as empty.
  3. You can use the following command to get your node current block height, then compare them with https://mainnet.incognito.org/
curl -s --header "Content-Type: application/json" --request POST --data '{ "jsonrpc":"1.0", "method":"getblockchaininfo", "params":[], "id":1 }' http://your-node-ip:rpc-port
4 Likes

Thank you so much. I had another query.

Once my full node setup is complete, how do I post RPC calls on this full node using postman?

Do I have to paste “https://node-ip:rpc-port” in the section where we paste the full node URL?

I have posted RPC calls on the community full nodes by using the community full node URLs ie

https://beta-fullnode.incognito.org/fullnode and https://mainnet.incognito.org/fullnode

Please find the screenshot below:
getreward amount
Will my full node URL look something similar to https://95.100.247.619:9221?

The URL has the following form: IP:PORT (with http or https prefix, depending on your server configuration, usually http for ip). For example: http://1.1.1.1:1111.

3 Likes

Hello @Rocky
Once the full node setup is complete. How much time does it usually take for all the data to sync completely?
How do i check if all the beacon and shard data (all eight shards) are synced for my full node ?
Is there a way to monitor the sync status of the full node?

You said i can use the following command to get my node current block height, then compare them with https://mainnet.incognito.org/

curl -s --header “Content-Type: application/json” --request POST --data ‘{ “jsonrpc”:“1.0”, “method”:“getblockchaininfo”, “params”:[], “id”:1 }’ http://your-node-ip:rpc-port

Do i have to use this command every time i want to check if my full node is in sync? @sid

1 Like

Hello @Jared @Rocky
I did set up my own full node.
I tried submitting an OTA Key to my full node using “authorizedsubmitkey” and it gave me the following error: fromHeight is larger than the current shard height
Please find the attached screenshot
fromheight is larger than current shard height
Can you elaborate on what does this error mean? The Description of the error in the following article says that the error means “The third parameter is larger than the current block height on the blockchain”

Does this mean that my full node is not in sync? How do I go about fixing this? @sid @Gaurav_Saini

2 Likes

Yes, it means that the fromHeight parameter is larger than the current shard height of the full-node. Make sure your node is fullly synced before doing the submission.

2 Likes

Thank you for replying. So will this get fixed automatically once my node is fully synced ? or do I have to make changes to my script? and do you have any idea on the amount of time the node might take to get synced completely?

1 Like

It could take a week for a full node to sync all the data and you must wait for your node to be fully synced before you can use it.
The command I gave you is to get the current sync status of a node, so yes, you have to run it every time you want to check.

2 Likes

Would it be possible to add a field for --RewardAddress when folks wants all nodes to go to a single address?

1 Like

Sorry, but it’s not possible.
This script only helps to set up and upgrade nodes, it does not affect how you stake your nodes.
So if you want all your rewards to go to a single wallet, you have to get to know how to use the staking RPC to get that.

1 Like

Or using incognito-cli instead, much easier :grinning:
image

2 Likes

I’ll take a look at the cli, I haven’t messed with it yet. Is it as simple as sending the stake command with the right private key and reward address?

1 Like

Yupp. I used to do it over RPC with Python, but after sending the wrong parameter by mistake once, I started using the CLI instead. :sweat_smile:

https://we.incognito.org/t/option-in-app-to-funnel-rewards-to-a-signle-account/15519/5?u=fredlee

1 Like

for example, all your fund is in account A, you have accounts V1, V2, V3… to set up with your node and you want all the reward go to account B, then run:

incognito-cli stake --privateKey A_private_key --miningKey V1_mining_key --candidateAddress V1_payment_key --rewardAddress B_payment_key
incognito-cli stake --privateKey A_private_key --miningKey V2_mining_key --candidateAddress V2_payment_key --rewardAddress B_payment_key
incognito-cli stake --privateKey A_private_key --miningKey V3_mining_key --candidateAddress V3_payment_key --rewardAddress B_payment_key
4 Likes