Ethereum Full Node on RISC-V. Breakthrough by Web3 Pi

Introduction

RISC-V is an open-standard Instruction Set Architecture (ISA) that has been generating a lot of excitement in the tech community for its openness and potential to spark innovation. RISC-V processors are still relatively new and face challenges such as lower performance, less mature software ecosystems, and incomplete hardware acceleration support. This post details our approach to running a full Ethereum node on Ethereum mainnet using RISC-V hardware and shares the steps, experiences, and insights gained in the process.

I am Robert Mordzon, and this initiative was carried out under the banner of the Web3 Pi project. We believe that open-source hardware architectures like RISC‑V naturally align with the principles of decentralized blockchains, making this achievement both technologically significant and ideologically relevant.

Important Note: All experiments and results described here took place before the Pectra update. Future updates may bring changes in performance or compatibility.

Why RISC-V and Why Now?

• Open Source Philosophy: RISC-V is an open ISA, meaning anyone can design and fabricate RISC-V chips without hefty licensing fees. This openness mirrors the decentralization ethos of public blockchains such as Ethereum.
• Emerging Performance Potential: While current RISC-V dev boards often lag behind established ARM-based boards like the Raspberry Pi 4, the landscape is evolving rapidly. Over time, we expect to see more powerful processors and better hardware acceleration.
• Future-Proofing: As the industry explores the boundaries of edge computing, IoT, and decentralized infrastructures, RISC-V could become an enabler for trustless, open, and low-cost solutions.

Challenges

1. Limited Performance

RISC-V boards generally offer lower single-core performance than, for example, Raspberry Pi 4 or 5. This limitation became particularly noticeable when running resource-intensive Ethereum clients.

2. Immature Ecosystem

Many RISC-V dev boards are still relatively new, and community support can be scattered. The documentation sometimes appears in multiple languages (English/Chinese), and there isn’t a single go-to repository of best practices yet.

3. Lack of Hardware Acceleration

One of the main gaps is the incomplete implementation of vector extensions and other forms of hardware acceleration. While ARM boards benefit from mature cryptographic accelerators, RISC-V boards often lack these or perhaps provide minimal or partial support.

4. Compilation Hurdles

Not all Ethereum clients compile cleanly on RISC-V without source-code modifications. Although Geth was straightforward to build, Consensus clients posed more significant obstacles.

Ethereum on RISC-V: Our Breakthrough

Geth (Execution Client)

We tested Geth 1.14.12 on various RISC-V dev boards:

• Banana Pi F3 (Bianbu Linux OS, kernel 6.6) with a 2TB NVMe M.2 drive
• LicheePi 4A (custom Debian-based image) with a 2TB SSD on USB 3.0
• Milk-V Megrez (RockOS based on Debian, kernel 6.6) with a 2TB NVMe M.2 connected via a PCIe adapter

All of these dev boards were equipped with standard active air cooling. Their power consumption is comparable to ARM-based solutions (e.g., Raspberry Pi devices) under similar workloads. Thanks to Geth’s relatively moderate CPU demands, it kept up with Ethereum’s mainnet on these RISC-V boards regarding Execution layer tasks.

Inspiration from Devcon 2024 in Bangkok

At Devcon 2024 in Bangkok, a talk demonstrated that Lighthouse running on RISC-V failed to find any peers (0 peers) and could not sync. After attending that talk, I was motivated to try a hands-on approach by leveraging my experience from the Web3 Pi project—where we successfully run Ethereum clients on low-power ARM platforms—to see if I could make Lighthouse work on RISC-V. The result here is a fully synced RISC-V Ethereum mainnet node.

Nimbus (Consensus Client)

Nimbus is known for its low resource footprint on Raspberry Pi 4 and 5. However, due to single-core performance constraints on RISC-V boards, Nimbus could not maintain consensus sync. We repeatedly encountered the “Missed multiple heartbeats” error, indicating significant lag under the typical single-threaded load Nimbus imposes.

Lighthouse: The Successful Consensus Client

While other Consensus clients also refused to compile on RISC-V without heavy source modification, we managed to build and run Lighthouse v6.0.1 (both in release and MaxPerf modes) after:

1. Editing Cargo.toml build configuration file

2. Linking alternative library versions compatible with RISC-V like:

   1. rust-libp2p,
   2. ring 0.16->0.17,
   3. rcgen 0.11.3->0.13.2,
   4. tokio 1.38->1.42
   5. webrtc 0.9.0->0.12.0

3. Minor changes in the Lighthouse source code.

   

4. Testing both cross-compiling and native compilation (the latter is slow but still feasible).
   We also compiled Lighthouse in both Release and MaxPerf versions. The official Lighthouse releases are built with MaxPerf, which provides slightly better performance due to compilation-time optimizations.

By distributing tasks across multiple boards, we found a viable setup:

• Banana Pi F3 (or LicheePi 4A) handles the Execution client (Geth 1.14.12).
• Milk-V Megrez runs the Consensus client (Lighthouse v6.0.1 - maxperf).

This dual-device arrangement offloads Execution tasks to one board and Consensus tasks to another, and the two clients communicate over a local network (LAN). Both dev boards have 2TB of attached NVMe storage for blockchain data and connect to the internet through a home 600/200 connection, routed via a 1 Gbps switch.

Additionally, we managed to start Lighthouse on the Banana Pi F3 as well; however, it couldn't maintain continuous synchronization. The block delay varied between 1 and 8 blocks, occasionally syncing fully for a few minutes before falling behind, catching up, and repeating the cycle. It's clear that the board's computational power is slightly insufficient for stable performance over an extended period.

Current State of Sync and Monitoring

Our RISC-V Ethereum node (split across two boards) has kept the fully synced state on Mainnet for several days, staying up-to-date with the latest mainnet blocks all the time.

This monitoring setup (provided by the Web3 Pi project) proves that both devices remain synchronized and stable, despite occasional performance limitations.

Additional Testing & Observations

I also tested the Geth RPC API over HTTP with various tools — Postman, curl, and a custom C# .NET application. In all cases, the RISC-V node responded just like any standard Ethereum node. I did not perform extensive load or stress tests, but it is clear that under a heavier transaction load, the node might struggle to maintain sync and would likely take a significant amount of time to catch up.

When comparing the latest block number of this RISC-V node with a Raspberry Pi 5-based node, the difference hovered at around one block. This suggests that, under normal conditions, the RISC-V node keeps pace with the chain at near real-time.

In addition, here are a few photos of the physical setup:

Specialized High-Core RISC-V Boards

It’s worth noting that more specialized RISC-V development boards exist, sporting significantly higher core counts—some even reaching 64 cores. Such hardware would likely have an easier time running Lighthouse in a single-device configuration, but these boards are also costly. One of our main goals was to demonstrate that achieving a functional Ethereum node with hardware in a similar price range to a typical Raspberry Pi 5 setup is possible.

What Needs to Happen Next

While this proof-of-concept demonstrates that it’s possible to run a full Ethereum node on RISC-V today, broader adoption will require several key developments:

1. Faster RISC-V CPUs
   • We need more powerful processor designs hitting the market with competitive single-core performance.
2. Hardware Acceleration
   • Implementing vector extensions and dedicated cryptographic accelerators for RISC-V, then ensuring their software support.
3. Ethereum Client Readiness
   • Broader client compatibility, including upstream RISC-V support, so heavy manual patching is unnecessary.
4. Greater Dev Board Availability
   • Widespread availability beyond Asian markets to foster a global user base and developer community.
5. Mature OS Support
   • More polished Linux distributions for RISC-V, with robust package repositories and firmware updates.
6. Better Documentation & Multi-Language Resources
   • Well-developed documentation in English. Currently, for more advanced information, one has to search through Chinese websites using a translator.
7. Improved UX
   • Streamlined procedures for installing and running Ethereum clients on RISC-V, akin to what the Web3 Pi project has achieved with the Raspberry Pi (ARM).

Why This Matters

Even if today’s RISC-V boards aren’t yet ready for everyday use as Ethereum nodes, the rapid pace of development suggests that tomorrow’s hardware could close the gap. As open-source processors become faster and more readily available, the synergy between blockchain decentralization and community-driven hardware will grow stronger.

By demonstrating that Ethereum can already run—albeit marginally—on RISC-V, we hope to inspire further experimentation, development, and collaboration across the community.

Conclusion

Running a full Ethereum node on RISC-V is no longer theoretical—it’s a reality, albeit one that requires a good deal of technical gymnastics and specialized configurations. The Web3 Pi project has shown that using two different RISC-V boards for Execution and Consensus layers makes this ambitious goal achievable.

This achievement sets a valuable precedent: as RISC-V hardware, OS support, and Ethereum client software evolve, we’ll move ever closer to a world where open-source chip design and decentralized finance intersect in truly innovative ways. We’re already working on future experiments to push performance boundaries, refine compilation steps, and make the entire process more user-friendly.

Stay tuned for our next blog posts, where we’ll dive deeper into the technical steps, share code snippets and screenshots, and publish performance benchmarks from Geekbench6. If you want to follow or contribute to our ongoing work, check out the Web3 Pi project and join us as we push the frontiers of decentralized computing on open hardware.