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.
