Blockchain on real devices: 72 hours with three Raspberry Pis

01Why real devices

In a distributed system, keeping several nodes on the same chain looks easy when they are processes on one computer. Once network latency, limited hardware and long runtimes come into play, the picture changes. That is why I wanted to observe the system not only in a local process, but on real devices and in a long run.

Several processes on one machine share the same clock, the same memory and the same network stack. That makes testing fast, but it also hides some questions. Nodes running on separate devices each have their own resources and their own timing, and they talk over a real network in between. Resource-limited devices like the Raspberry Pi seemed to me a suitable environment for observing these conditions over a long period.

02Architecture

The system runs as a permissioned PoA, with finality reached through signed validator votes. The blockchain core is written in Go, a NestJS layer exposes the services, gRPC connects the services and PostgreSQL holds persistent data. GraphQL and Docker are also part of the stack. Block production, validator coordination, wallet and contract services are treated as separate responsibilities.

core       Go (PoA, signed validator votes)
services   TypeScript / NestJS
transport  gRPC
data       PostgreSQL
nodes      3 × Raspberry Pi 4B

Keeping the core and the services in separate layers is a deliberate choice. Separating the parts that determine the system's correctness, such as consensus and block production, from the parts that face the outside world, such as wallet and contract services, makes it easier to evaluate each under its own conditions. The split also shows in the choice of language: Go in the core, TypeScript in the services. It also becomes easier to see how a change in one layer affects the other.

Having the services on the TypeScript side makes it quicker to experiment with work outside the core. In the core, the priority is not speed but predictability. Unexpected behavior in a blockchain core does not just cause a bug; it can also push nodes into different states.

03Permissioned PoA and finality

In a permissioned PoA, the right to produce blocks belongs to predetermined validators. Finality is reached through signed validator votes. For me, the instructive side of this model is that it separates two questions: are blocks still being produced, and are the produced blocks being finalized? A system can keep producing blocks while finality stalls; conversely, a chain that looks consistent may have stopped producing new blocks. So in a long run you need to look at the two separately.

Signed votes also make it traceable which validators' approval a finalization came from. A permissioned structure lets me work on consensus and finality without needing a participation model as complex as the one on open networks. For a personal R&D project, that is a reasonable way to narrow down the questions I want to focus on.

04The 72-hour test

In a 72-hour test between 13 and 16 July 2026, three Raspberry Pi 4B nodes reported 86,553 blocks. Across 863 checks between the nodes, no chain split or finality stall was observed.

When I look at these numbers, I try to keep two things apart. The block count shows that production continued throughout the run. The cross-node checks show whether the different devices shared the same chain. Each is incomplete without the other: a high block count means nothing if the nodes are advancing on different chains, and a consistent but stalled chain does not prove long-running operation.

In a run like this, the most valuable information is often not a single number but numbers confirming each other. If the reported block count and the result of the cross-node checks tell the same story, I can trust the run more; if they diverged, that divergence would be the thing to investigate.

A node that looks alive does not mean the system works.

05What this result does not say

This is a finding for that specific run. It does not cover every failure scenario of the system; cases like a network partition, a malicious validator or many more nodes need separate tests. Recording the result together with its limits matters as much as the result itself.

Three nodes make a small network. In a larger validator set, vote collection, network latency and resource usage may behave differently. So I see the 72-hour run not as a destination, but as an observation, with clear limits, of how the system behaves on real devices.

Verifying long-running operation means looking at consistency between nodes, continued block production and a record of the run's limits, all together. Doing this in a personal R&D project has one advantage: there is no pressure to make the result look bigger. I can write down what I saw and what I did not see with the same clarity. Those gaps are also what shape the next steps.