How to update your witness to hardfork 26 release canidate 4 (Updated)

in LeoFinance2 years ago (edited)

image.png

Update: Release canidate 4 has been released to fix an issue with rc delegations. Post has been updated to reflect this.

Hardfork 26 is right around the corner and offers a lot of improvements. Many of which dramatically improve scalability and performance.

Some of the improvements include:

  • One Block Irreversibility
  • Increasing HBD haircut ratio
  • Allow more than one vote per block
  • Remove vote change penalty
  • Support for block log compression
  • Peer to peer performance improvements
  • Resource credit overhaul
  • Resource credit delegation
  • General improvements to improve operation handling

As of right now, the hardfork is schedule for October 11th. This may change if anything comes up, as of right now we are on target.

It is officially considered safe to run hardfork 26 release candidate 4 on your backup and producing nodes. Due to the time it takes to replay aa node, you may want to consider getting at least one of your witness nodes on rc4. I'm going to walk you through how to do this.


Installing hived release candidate 4


Install Operating System

Previous versions of hived generally recommended using Ubuntu 18.04, although it was possible to get newer version of Ubuntu working. With hardfork 26, it is recommend you run Ubuntu 22.04.

I generally never would recommend raid 0 for anything, but in this case it is safe to use raid 0 if you need the disk space as everything is replacable.

If this is your only witness node, I wouldn't recommend raid 0 as it will introduce a small amount of downtime risk.

You will need around 400G of space to maintain a hf26 witness. Although you will need almost 1TB more if you need to compress an existing block log or you need to download one. I would recommend a minimum of 1TB, ideally more if you want to back up your block_log and move in new ones.


Install Packages

apt-get install -y \
autoconf \
automake \
autotools-dev \
build-essential \
cmake \
doxygen \
git \
libboost-all-dev \
libyajl-dev \
libreadline-dev \
libssl-dev \
libtool \
liblz4-tool \
ncurses-dev \
python3 \
python3-dev \
python3-jinja2 \
python3-pip \
libgflags-dev \
libsnappy-dev \
zlib1g-dev \
libbz2-dev \
liblz4-dev \
libzstd-dev \
ninja-build \

I would also recommend installing chrony, an improved ntp client.

apt install chrony

Clone Repo

You will need to clone the git repo for hived.

git clone https://github.com/openhive-network/hive

Check out release canidate 4

ver='v1.26.0rc4'
cd hive && git fetch && git checkout $ver

Grab submodules

git submodule update --init --recursive

Make build directory

mkdir -p ~/build-$ver && cd ~/build-$ver

Run make

cmake -DCMAKE_BUILD_TYPE=Release -G Ninja ../hive

Compile

ninja

This command will try to compile with all cores available on your machine.


Move executables to bin folder

ninja install

Confirm version

hived --version

You should see the following:

"version":{"blockchain_version":"1.26.0","hive_revision":"ade84a4dfa0750235fcbe8ba910a5b45387f0274","fc_revision":"ade84a4dfa0750235fcbe8ba910a5b45387f0274"}


Compress Block Log (Optional)

One of the great features of harfork26 is using compressed block log. This drastically reduces the space needed for hived.

  • hardfork25 block_log: 673G
  • hardfork26 block_log: 350G

If you have an uncompressed block log file, you can compress it with the compress_block_log utility.

You will need to create the folder compressed ahead of time.

compress_block_log -j16 --benchmark-decompression -i witness_node_data_dir/blockchain -o witness_node_data_dir/blockchain/compressed

Notice you only point to the blockchain folder and not the block_log file.

If you do compress your block log, you will need to copy the block_log and block_log.artifacts files from the compressed folder to the blockchain folder overwriting any previous block_log file. You should delete block_log.index if you have one there.

I have noticed the compression will create two artifact files, one in the input folder of the old block log and one in the new compressed folder. Delete the following files in the original folder

  • block_log
  • block_log.index
  • block_log.artifacts

From the new compressed folder, you will copy the block_log and block_log.artifacts to the original witness_node_dir/blockchain.

Going forward, there will no longer be a block_log.index, it is replaced with the block_log.artifacts.


Config.ini

If you have an existing config.ini from a previous witness node, just give a once over and make sure everything looks good.

If this is not your only witness node, be 100% sure you are not using the same signing key on any other witness or you will double sign.

If you need to create a new key, use the cli-wallet "suggest_brain_key" command. This will create a unique public & private key you can use for signing your witness. Keep this safe, you will need the private key in your config.ini file. You will need the public key when switching active witnesses.


Start Screen session

You will want to either use screen or tmux to prevent your node from shutting down when you close SSH. Tmux is nicer, but screen is has logging built-in without a plug-in.

I recommend starting a named session, as well as enabling logging.

screen -S witness -L -Logfile witness.log

This will start a new terminal that will remain running when you close SSH. It will also log all activity to a file so you can easily monitor errors and troubleshoot problems.

You can detach from a screen session using Control-A + D, but I usually just close the SSH session.

You can always reconnect to your screen session to shutdown your node using:

screen -r witness

Start Replay

At this point you either have no block_log file and are going to do a full replay from scratch or you compressed an existing block_log and will start your replay with it.

From your screen session, start the replay.

./bin/hived

You can speed up the replay by providing a checkpoint. This is a combination of a block number and block id. You can find this information from hiveblocks.com. For example, using the current block as our target you would add the following argument.

./bin/hived --checkpoint [68492031,04151aff878fe5945aca7f4e9052044ecf743875]

This will reduce the amount of work needed to be done as it knows the hash of the checkpoint block.


Expectations

I've done some testing with replay and compression.

Replaying without an existing block log took me 24.3 hours to complete on a Ryzen 3600 with Raid 0 2xNVME drives.

Compressing an existing block log file on Raid 0 2xNVME drives with an Intel i7 8700 took around 3.4 hours.

A compressed block log is currently 363G with a 1.6G artifact file. If you compress an existing block_log I have noticed it to be around 10% smaller than creating it through a full sync.

I haven't tested a replay using a compressed block log, but from what I gather it should take around 8-10 hours, plus the time to download and compress the block log.


Posted Using LeoFinance Beta

Sort:  


~~~ embed:1577663625426247681 twitter metadata:dGFza21hc3RlcjQ0NTB8fGh0dHBzOi8vdHdpdHRlci5jb20vdGFza21hc3RlcjQ0NTAvc3RhdHVzLzE1Nzc2NjM2MjU0MjYyNDc2ODF8 ~~~

The rewards earned on this comment will go directly to the people( @yeckingo1, @taskmaster4450le, @alokkumar121 ) sharing the post on Twitter as long as they are registered with @poshtoken. Sign up at https://hiveposh.com.

Who needs to vote more than once per block?

There are a lot of use cases for it. Not common for average Joe but there are use cases in trails and other automated bots.

Lovely.
Did they set a new limit?

I haven’t checked the code if there is a limit. The reasoning behind the changr was less that it was needed and more that the limit was just some arbitrary rule that served no real purpose.

Uh huh, we'll see how long it takes to be abused.
I liked the 4 post soft cap on rewards, I don't see why I wouldn't like limiting voting to one per block, too.
But, it's done now, I guess.

Uh huh, we'll see how long it takes to be abused.

What would they abuse, using all their voting power in a short period of time? So what?

I don't know, I'd have to think like an abuser.
I'd assume a bot net would be in play.
It does allow batching for trail votes, I guess.
How many votes can a block hold?

Almost there! Anxious about RC delegation, which will help me better manage my accounts, besides their benefits to the apps!

Super awesome knowledge and thank you very much for posting this here and I can't wait to see the new changes our blockchain has and thank you very much.

Easiest way I see for small accounts operating in the future happens to be investing in themselves. Which is very smart idea as well as Resource Credit delegation for newer accounts to have an opportunity to invest in themselves.

Excellent post and two paws up!

Definitely dog approved!

IMG_20221005_101210250.jpg

This is huge!
Thank you for sharing ❤️

Thanks for sharing this helpful information👍

We cant wait for the amazing improvement this comes with.

Good to see you around mate :)

Posted Using LeoFinance Beta

So, as much as I enjoy alluding to the whole AI mirror force retribution thing, I do think it's worth setting that aside for long enough to mention that I sincerely appreciate the effort involved in being a competent and legitimate hive witness, even if you technically have some vested interest in doing so, and I also appreciate your relatively bulletproof demeanor in combination with that position, so thanks.

Nice information, that's great now we can delegate some RC instead HP. Good. Thank you.

Thank you very much for this post. So the replay is mandatory due to the new compressed block_log?