Intro
The following is my experience in the attempt to run:
- An Ethereum Node
- On Raspberry pi
I did manage to have my node up and running moreover it was very difficult and time consuming to maintain it. Nonetheless it was a great experience and I learnt immensely on node files structures, data structures, hardware and limitations. In addition I have discovered the power of Raspberry Pi.
Here are the different options I had, my decisions, tools and documents, sites that helped me.
Node definition
From Ethereum org definition we have 3 types of nodes, depending on the amount of information available/stored and therefore, size and syncing time:
//
-
Light node:
-
Stores the header chain and requests everything else.
-
Can verify the validity of the data against the state roots in the block headers.
-
Useful for low capacity devices, such as embedded devices or mobile phones, which can't afford to store gigabytes of blockchain data.
-
-
Full node:
-
Stores full blockchain data.
-
Participates in block validation, verifies all blocks and states.
-
All states can be derived from a full node.
-
Serves the network and provides data on request.
-
-
Archives::
-
Stores full blockchain data.
-
Participates in block validation, verifies all blocks and states.
-
All states can be derived from a full node.
-
Serves the network and provides data on request.
-
//
My objective for running an Ethereum node is to have access to blockchain data in order to perform on-chain analysis on DeFi ecosystem.
Focus was on Full or Archive Node and decision factors were:
Node size
-- Full Node: half TB with
-- Archive Node: 4.5TB
Syncing / completion time
-- Full Node: circa 5/7 days
-- Archive Node: up to 30 days (the additional time is not due to syncing but about building the data
Data available in the node to be analysed
-- Full Node:
----- up to the sync date: only full transactions information and related recipes would be available in the node, no information on the chain states previous sync date
----- once synced, state info would also would be available fin the node to be queried
-- Archive Node: in addition to full transactions information, full blockchain states history would be available
My choice was for the full node: good compromise on size (around half tera, versus almost 5 tera with raise practical and cost issues.
It is fair to mention, an archive node would allow you to perform on-chain analysis on events occurred from Inception: from block 0
My first attempt to build an Ethereum node was based on the following article:
- https://kauri.io/running-an-ethereum-full-node-on-a-raspberrypi-4-m/9695fcca217f46feb355245275835fc0/a
The steps to be taken are very well explained moreover once the node is sync it is when the challenges start: it became technically very complex and very time consuming to solve all the issues the node was running into. It seems the root cause reside in the discrepancy between Rasbian OS 32bits versus Geth 64Bits. A solution has been been provided by Ethereum org itself in the following link:
- https://ethereum.org/en/developers/tutorials/run-node-raspberry-pi/#references
It is more out if the box solution, the steps are very well explained and since my node synced I rarely had any issues: it seems you still need to monitor the node closely when an upgrade or hard fork is performed.
Still I recommend it.
Hardware:
- Raspberry Pi 4 Model B: Memory: 8GB
https://thepihut.com/collections/raspberry-pi/products/raspberry-pi-4-model-b?variant=31994565689406
- Drive: Samsung Portable SSD T5 1TB, UBS 3.1
https://www.amazon.co.uk/Samsung-MU-PA1T0B-Portable-SSD-1TB/dp/B074M774TW/ref=sr_1_3?dchild=1&keywords=Samsung+Portable+SSD+T5+1TB&qid=1604084227&sr=8-3
- Memory Card: SanDisk Ultra 64 GB
Raspberry pi preparation:
-From my iMac:
1) Download Raspberry Pi OS (32-bit) Lite:
https://www.raspberrypi.org/downloads/raspberry-pi-os/
2) Unzip the OS: Unarchiver recommended
3) Insert the card in your PC and flash it, Etcher recommended
4) Create ssh file in the OS boot:
-- Go to directory: Volume
-- touch ssh
5) Eject the card
At this stage I found very interesting the chaindata directory: the folder collect the blocs in leveldb format: ########.ldb
You can monitor the size of chaindata directory to undestand where you are with the sync and how the blockchain gorws
Old blocks are then moved to to the 'ancient' directory which contains frozen DB, cold data in cdat format:
- bodies.####.cdat
- receipts.####.cdat
