Important: Update your Node to extend its life cycle.

What’s up, everyone? We are here to bring wonderful news for our validator community.

From April 2020, the blockchain size has been optimized and the volume requirement to run a Node has been reduced from 160 GB to 50 GB. It helps to cut down your operation cost and expands the lifetime of your Node significantly. Now let’s dive into what you need to do to update your node for the changes:

1/ For Physical Node operators:

As it is a plug & play device, you don’t have to do complicated steps. We already push a silent update to your Node on April 20, 2020. Hope you all enjoy it!

2/ For Virtual Node operators:

Login to your server and perform this command: sudo rm -rfv data

1

Wait until it is done. Then enter this command: sudo bash run.sh

2

You will get a new tag: 20200406_1

Untitled

Your Node will start to sync the new blockchain data now :rocket:

7 Likes

Since doing this I now have eth_mainnet appearing to run OK however inc_mainnet consistantly reports a ‘Restarting (1) x seconds ago’.

I have tried (1) re-running sudo bash run.sh (2) restarting Google Cloud VM with sudo reboot but have not had any success.

image

Think I figured it out. Following the sudo rm -rfv data command, I have had to re-run the initial command again curl https://node.incognito.org/run.sh > run.sh && sed -i s/xxx/Validator_Key/ run.sh && sudo bash run.sh

That appears to have fixed it as processes now appear to run OK.

1 Like

Nearly two days passed.

I have two nodes in the same machine. One’s beacon height is around 113k, the other’s beacon height is around 117k. So slow.

In Telegram, Jaroslav has complained about this issue, too. Could it be possible to provide some initial chain data in an achived/zipped bootstrap file ? @Peter

1 Like

Hi @abduraman,

If you are using more than 1 Node in a machine, the resources are shared and it takes longer than normal. In my personal VM (1 Node/ 1 instance), it takes about 20 hours to get the height ~ 350k.

We can provide an archived/ zipped data file from a synced Node. However, it is not recommended because it makes the network centralized.

Hi.

this is strange. I tried earlier to resync 200gb blockchain - it took <24hours - OK.
Now we have 50GB - and it syncs around 7-10GB daily.

So it seems we now need around a week now - to get synced.

As I talked in some other topic earlier. It probably would be nice to run a script;
check your stauts - and if possible just download shard0.tar.gz and extract - bingo.

1 Like

Also someone in incognito channel wrote:

Looks like the new code update gets your account banned on google cloud
Resources associated with your project My First Project (id: ) are being suspended for violating our Terms of Service by mining cryptocurrency.

Hi @huglester,

200GB or 50GB data(I think now is 18GB for fullnode db v2 and less than if you’re validator node) are after node download block and fetch data from block(contain: block data and info which be fetched from block). In db v1, still sync the block as db v2, but we fetched and storage data with a new way to reduce a lot of space of disk. The fact that, db v1 sync faster than dbv2 a little bit, because it not process and reduce space on fetched data much, on fetch and write, not redue anything -> db v1 is very bad in storage with a big space.

We also have plan to profile and optimize write data of db ver.2. It may take 3-4 weeks to find out a better way

Thanks

Hey @Peter, after I wrote this(Important: Update your Node to extend its life cycle.), 8 hours passed. However, the height of both nodes increased just about 5000. That means, a rough calculation is that synching both nodes will take 230000/15000 = 15,3 days. Even if I shut down one node, synching other node will take 7,15 days.

@huglester (Jaroslav) also is in very same situation.

I even tried to sync on dedicated server with 1gbit port. With NVME disks. Still same speed

But as I see we just wait. The only sollution for now

1 Like

Yes we noticed. Google Cloud users will have to find another host, unless Google changes its mind which they hardly ever do.

I’m really confused :slight_smile: Since the synching is slow, I check https://incognito.mesquka.com/nodes page frequently. I noticed that my node had some rewards just now. However, its shard id was -2. The reward is 0 in the figure since I withdrawn the reward before taking the screenshot.
Region capture 14

Then I checked https://mainnet.incognito.org/committees and I saw that my node was in the committee of shard 6.

How is this possible? Is it so normal? @Peter

Could it be a bug? @mesquka

@abduraman hey. did you /data was truncated after this last update?

@abduraman The nodes page shows the data returned by the node directly. I’m considering changing it to display ‘syncing’ if the block height it reports is more than 1000 blocks below the current block height. Not sure at what point the node can start earning, need to investigate that a bit more.

1 Like

If you mean removing old data, then yes, I had deleted all of data.

Yes. Ok my data was truncated also :slight_smile:

Something now is changed. CPU load is dropped a lot.
so something was changed. Just not sure what :slight_smile:

Strange we got databases truncated also.
I think it was done to “fix” those who auto-update nodes but did not truncate old database.
Maybe there should be smth like “subfolder”
/data/dbv1
/data/dbv2

that way system would detect if its on “old” or “new” db format.

just my 2c.

1 Like

@Peter - what is current expected database size?
I jsut want to know when its is “synced” :slight_smile:

Hi @huglester So far I have 3 results: 1 is 4.7 GB, 1 is 7.3 GB, and 1 is 14 GB. If you are swapped in and out many times, there is a chance your Node synced the data from all the shards and it will reach the fullnode size: ~ 18 GB.
Untitled