How to Bake a Raspberry PIe

---

Dear Hive Community ❗

Thank you again for meeting us at HiveFest! Special greetings to everyone we had the chance to talk with directly, especially during our workshops.

As @itsola demonstrated during the HiveFest presentation, the software optimizations made by the @thebeedevs group enabled us to experiment with running a hived node on a different architecture: ARM. Additionally, building the hive-protocol library as a WASM target (required for wax development) simplified our codebase and made it significantly more portable. This led us to experiment with using a Raspberry Pi 4B device equipped with 8GB RAM and a 128GB SD card as persistent storage.

It seems mini computers have come a long way! 😊 Fortunately, they remain affordable - the mentioned version should cost around 💲100 USD.

This project required us to solve at least two fundamental challenges:

1. How to build the hived source code on this platform
2. How to prepare a deployment procedure that avoids performing a full replay process on this small device

TL;DR

As promised at HiveFest 2025 we will share a complete microSD card image containing whole ready-to-flush setup. We just need to prepare it accordingly to avoid downloading 128GB while only c.a. 32GB is effectively used.

Also prebuilt ARM version of hived will be published.

Such artifacts will be available for download from Useful Hive stuff provided by @gtg (also soon there will land 1.28.x consensus node snapshot, ready to load on Pi machine).

The impatients ⚡💨, please read detailed instruction below...

Build Tools

As you may know, hived software is written in C++. This language requires preprocessing (compiling) the source code to produce a binary executable ready for use. Such compilation is a ⏳ time and resource-intensive process-doing it on a small Pi would be a nightmare and a waste of time. To optimize this process we need a cross-compiler - a tool that runs on an x64 host (a regular Ubuntu machine) but produces a binary code ready for execution on the selected target (ARM) device such as our Pi. Pure magic ✨!

1. How to obtain such a tool? You can build it yourself using buildroot software. We have added some configuration files to the hived repo. Please check the hived documentation. We are considering sharing a prebuilt toolchain, but for now, it would be valuable to encourage more people to try the configuration and improve the documentation in the process.

2. Build the hived software itself. In general, you can use regular CMake tools - the only change is pointing CMake to a toolchain file (in our case, Toolchain.cmake). For convenience, we created a bash script to build the hived executable targeting the ARM platform. You can find it here. Of course, it should still be executed on an x64 machine host - the same as for performing regular hived builds targeting the x64 Ubuntu platform.

Now you should be ready to transfer this hived binary to your Pi device.

How to Configure a Raspberry Pi Device

1. First, you need the hardware. A good solution is to buy a ready-to-use device: Raspberry Pi 4B, 8GB RAM. Of course, you could make it yourself: 😁

But seriously - after gathering the hardware (one prebuilt device) and storage (in our case a microSD card with 128GB capacity), all you need to do is flash a prepared image of Raspberry Pi OS onto it. We used this one: Raspberry Pi OS Bookworm. This is not the newest version (you can try the latest and it should work fine). Our setup which includes a fancy round screen (for presentation purposes), required us to use this older version.

Consider using the Raspberry Pi Imager.

During initial setup, please enable SSH remote access - it will be needed to transfer and start the hived tool. Configuring the network is also an important step (Wi-Fi or Ethernet LAN).

Once completed, you should have a running Raspberry Pi device on your network. Now you can create the initial directory structure and copy the hived binary there using the scp command-line tool, for example:

To prepare the initial directory structure (you can create your own; here we are proposing a structure similar to our tested deployment):

1. Create a top-level directory ~/hived-node to store all hived node files:

mkdir -vp ~/hived-node/bin
mkdir -vp ~/hived-node/datadir/blockchain
mkdir -vp ~/hived-node/datadir/snapshot

Then copy the built ARM hived binary to the created bin directory:

scp -C ./build_arm/programs/hived/hived user@4rp.local:~/hived-node/bin/

Once the binary is copied, we can perform a smoke test ⚗️🧪💥 and run:

~/hived-node/bin/hived --help

on your Raspberry Pi device. It should succeed and print the help information.

Preparing a Hived Deployment on an x64 Machine

At this point, you should have a working Raspberry Pi device as well as a hived tool ready to run on it. The missing piece is a hived state evaluated at a block close to the blockchain head block which enables quickly reaching a live sync state. The obvious approach - running a full replay on the Raspberry Pi device - is time-consuming as this tiny computer has a relatively slow CPU (though it is fast enough to work in live sync).

Fortunately, hived supports another powerful feature: dumping and loading state snapshots. Moreover, these are generated in a platform-independent way, so it is possible to perform a regular replay on an x64 Ubuntu machine, dump a state snapshot, copy it to the Pi device and load it there.

That was the exact scenario we used to set it up 🚀! Since we are at release 1.28, a consensus-node snapshot should be published soon. It is usually available for download from Useful Hive stuff provided by @gtg . If you want to do it yourself, please use:

./hived --replay --stop-at-block=101060000 --dump-snapshot=101m --exit-before-sync --data-dir="$(pwd)"

This command performs a blockchain replay, generates a snapshot and exits the hived tool. Processing will stop at the requested block number.

The generated snapshot data (using default settings) should appear in the datadir/snapshot/101m directory. This directory should be copied to the Pi device.

Again, you can use the scp command, for example:

scp -r ./snapshot/101m user@4rp.local:~/hived-node/datadir/snapshot/

Back to the Pi Device

Now we should have everything needed to spawn the hived node and perform syncing.

1. Log in to the 4rp device using SSH and navigate to the ~/hived-node directory.
2. For convenience, you can create a helper script called load_snapshot.sh containing:

#!/bin/bash

set -xeuo pipefail

./bin/hived --data-dir=./datadir --load-snapshot=101m --replay --block-log-split=0 --exit-before-sync

What happens here?

• We are instructing hived to load a snapshot previously copied to the ~/hived-node/datadir/snapshot/ directory, named 101m.
• Use ~/hived-node/datadir/ as data storage.
• Avoid collecting block_log file(s) by specifying the --block-log-split=0 switch. This limits the amount of space required to run hived. Please refer to the hived documentation for details on using this option differently.
• Exit hived after snapshot loading completes.

Create a ~/hived-node/datadir/config.ini file:

backtrace = yes
plugin = webserver p2p json_rpc
plugin = database_api condenser_api
plugin = block_api network_broadcast_api rc_api
plugin = state_snapshot
plugin = wallet_bridge_api

shared-file-size = 6G

flush-state-interval = 0

p2p-endpoint = 0.0.0.0:2001
webserver-http-endpoint = 0.0.0.0:8091
webserver-ws-endpoint = 127.0.0.1:8090

Then run the ./load_snapshot.sh script to load the snapshot.

In our tests hived loaded the snapshot in this time:

State snapshot load. Elapsed time: 652133 ms (real), 175949 ms (cpu). Memory usage: 9095824 (current), 9732800 (peak) kilobytes. Free space in SHM: 2400563 kilobytes.

You may also consider creating a start_hived.sh convenience script in the ~/hived-node/ directory, containing:

#!/bin/bash
set -xeuo pipefail

/home/user/hived-node/bin/hived --data-dir=/home/user/hived-node/datadir --block-log-split=0 --replay 2>&1 | tee -i /home/user/hived-node/datadir/hived-sync.log

This script is responsible for the regular spawning of the hived node.

It can then be useful to create a systemd service to perform automatic startup by calling this script.

The above steps should allow you to start hived and reach the head block in a few minutes. We hope it will work for you as well.

Enabling Witness Plugin

During HiveFest, we received a lot of questions about the ability to enable a witness plugin on this version. After initial testing, there are no obstacles to do so: technically, the witness plugin does not involve any significantly higher performance requirements than a consensus node.

Further plans & maintenance

We plan to improve our experiments with ARM usage and conduct dedicated performance tests (using testing tools also prepared by our group) involving heavy traffic on the chain. It is hard to say how much data can be consumed safely by such a tiny device but we are optimistic.

Regular blockchain traffic requires tens of milliseconds to evaluate blocks at live-sync. Please take a look at the following statistics (gathered by collecting block stats logs produced by hived):

Block Num	Transaction count	Witness	Processing time (uSec)
101064823	36	roelandp	4258
101064824	21	mahdiyari	10130
101064825	16	stoodkev	4717
101064826	34	ausbitbank	5144

Periodically, processing time increases to 30 ms when flushing occurs.

This means we have significant headroom - up to 1.5-2.0 seconds - before block processing time becomes critically long.

Our mid-term stability test (when the hived node ran for nearly a month before the HiveFest presentation) did not show any stability problems.

We should also keep in mind that the proposed setup is close to the cheapest version (we might even try a 4GB RAM one). The Raspberry Pi platform offers numerous extension headers, allowing the use of regular SSD disks (or even NVMe drives) as storage. This opens another possibility: using it as a regular API server holding at least limited account history data filtered for a few accounts. This could still significantly decrease the costs of servers hosting Hive and hopefully make this platform much more popular.

---

Setting aside meticulous and painstaking tests, some of us (Good Rider on A Young horse 🐎, fighting ⚔ an evil and windmills) will attempt to tame the ARM squeezed into a smartphone... But that will be another part of this story 📜 (we will also share soon, how to make exact device as the one shown by @itsola at HiveFest and we had at our workshow room)...

Happy baking! 🍽️

Thank you for reading. We look forward to your feedback and hope these instructions will be useful.

thebeedevs Team