Run vNode by source code?

Hi Incognito team,

Is there an instruction for running an Incognito node by source code?
I saw the instruction for Docker, but IMO it’s not suitable for decentralization because the binary file is pre-compiled.

Thanks!

1 Like

Of course. Just three steps (https://github.com/incognitochain/incognito-chain#build-the-code):
1- Clone the repo (production branch).
2- Build the executable (1 line).
3- Run the executable (1 line).

1-2 years ago I had built and run a fullnode in that way. Some problems may occur due to your golang version and some go modules. In those cases, GO111MODULE and replace features may help you.

3 Likes

I doubt the instruction in Github works.
The beacon is stalled after syncing some blocks:

-1164: Shard Sync Validator Hash Error 
 Expect 2cd4d1dc54c2849b08935b71894b08be1e16cf5552c2d9b2cdad04c71a8e0086 but get 5cdf65604adca4f1b386b591169d37eaa19c00170d10266496d0f1df98482d5c
Shard Sync Validator Hash Error
github.com/incognitochain/incognito-chain/blockchain.NewBlockChainError
	/root/incognito/incognito-chain-enhanced/blockchain/error.go:404
github.com/incognitochain/incognito-chain/blockchain.(*BeaconBestState).verifyPostProcessingBeaconBlock
	/root/incognito/incognito-chain-enhanced/blockchain/beaconprocess.go:497
github.com/incognitochain/incognito-chain/blockchain.(*BlockChain).InsertBeaconBlock
	/root/incognito/incognito-chain-enhanced/blockchain/beaconprocess.go:169
github.com/incognitochain/incognito-chain/blockchain.(*BeaconChain).InsertBlock
	/root/incognito/incognito-chain-enhanced/blockchain/beaconchain.go:274
github.com/incognitochain/incognito-chain/syncker.InsertBatchBlock
	/root/incognito/incognito-chain-enhanced/syncker/utils.go:104
github.com/incognitochain/incognito-chain/syncker.(*BeaconSyncProcess).streamFromPeer
	/root/incognito/incognito-chain-enhanced/syncker/beaconsyncprocess.go:357
github.com/incognitochain/incognito-chain/syncker.(*BeaconSyncProcess).syncBeacon
	/root/incognito/incognito-chain-enhanced/syncker/beaconsyncprocess.go:266
runtime.goexit
	/usr/local/go/src/runtime/asm_amd64.s:1594

This issue is not specific to your version. Dockerized versions also sometimes face this. Mostly it heals itself. Or you may restart the node (not PC, I mean the executable) or try bootstrapping for earlier blocks.

Btw, I assume that your VPS/PC have sufficient specs. Slow disks usually cause this type of stalls.

Restart doesn’t help, and the fact is I also tried to run the dockerized version with the same parameters, and it’s worked. That is why I am asking questions here!

You think so deterministic. It may not be about parameters. As I said, there are many factors. For example, your VPS’s disk may have enough performance but VPS provider sometimes may throttle your disk performance or since VPS is a shared entity, depending on the other users’ tasks, its performance may decrease. That’s why I also suggest “bootstrapping for earlier blocks”. If you do not want bootstrapping, you may delete block data and restart the executable. In your case, it seems only shard sync problem. So probably deleting shard data may also be sufficient.

I don’t think so but if you still insist that there are some differences between source code and dockerized version, you may tag @ support.

1 Like

That can’t explain how the dockerized version works on my VPS but not the build version

Bootstrap doesn’t help when syncing near the latest block

IMO, the more trustless setup, the better it is. I don’t insist on anything, FYI.

All I want is an updated setup guide for running node by code @Support :sweat_smile:

This explains why my docker nodes are in “Beacon stall” (sync error) currently :slight_smile:

I’ve suggested it since “mass” syncing increases load so much and so risk of sync errors. Doing that, you would decrease that load and risk, and catch the latest block easily.

I agree.

No, you insist but you are not aware :slight_smile: docker just forwards some essential parameters to the executable. If the parameters are “same”, they should work same. Otherwise, the source code of executable in dockerized version and source code in production branch should be different. Of course, this is a possibility which I cannot be sure since I’m not a part of the core team. Then, let’s wait for the support.

hey @hollyrae

You should build and run the binary file from the same machine (I mean OS and Arch). You can prefer to this post, step 4 if you build for cross-platform.

Here is the step I used to do:

git reset --hard
git checkout production
git fetch -a
git pull

mkdir block-data

go build -o incognito 
sudo apt install tmux 
tmux new -s run_incognito

# we are going to run the incognito validator in tmux session
ulimit -Sn 100000
./incognito --datadir block-data --rpclisten 0.0.0.0:9334 --listen 0.0.0.0:9335 --miningkeys "your-validator-key" --relayshards "auto" --discoverpeersaddress "mainnet-bootnode.incognito.org:9330" --externaladdress 0.0.0.0:9335 --norpcauth

# wait for it initialize the process then exit tmux 
Ctrl + B + D

checking your node sync status:

curl -s --header "Content-Type: application/json" \
  --request POST \
--data '{"id":1,"jsonrpc":"1.0","method":"getblockchaininfo","params":[]}' \
http://127.0.0.1:9334 | grep "Height"
Advance: Modify config as you want (NOT Recommended)
  1. stop incognito in current tmux:
tmux a
Ctrl + C 
# wait 1 minute for it stop successfully
Ctrl + B + D
  1. edit config: running your own ETH endpoint, enable prune, etc.
nano config/mainnet/param.yaml
nano config/mainnet/config.yaml


Then go back to tmux and run your node again

Good luck :v: