Skip to main content

Building an Ethereum node for fun, not profit

· 4 min read

As one of the most innovative blockchains, Ethereum provides many learning opportunities for those interested in the web3 tech stack.

A practical way to understand Ethereum's architecture is by dissecting the components of an Ethereum node. Does it run the same familiar software we find in modern open-source web2 tech stacks? Are these components truly the same? And what sets an Ethereum-based Web3 stack apart?

Let's dive in and find out.

Web2 and Web3 stacks

Conceptually, Web3 brings together the decentralised and community-governed principles of the early web, built on open protocols, with the advanced functionalities of modern web2, which, despite their sophistication, tend to be siloed and centralised.

This intriguing description was popularised by Chris Dixon in his seminal blog post Why web3 matters, and originally coined by Packy McCormick.

While the disruptive concept of an internet owned by the builders and users, orchestrated with tokens, hasn't permeated the online experience of most of us, the significance of web3 tech innovations shouldn't be underestimated. A permissionless, credibly neutral, and transparent financial system seems to be emerging out of the Ethereum blockchain, which is now powering a decentralised-finance (DeFi) industry worth trillions.

Surprisingly, the servers powering this disruption need only to run a few components. Really well-designed, highly-complex components, but only a few nonetheless.

Here's an exhaustive list of the mandatory software your computer needs to run to become part of the Ethereum blockchain:

  1. An Ethereum execution client (there's plenty to choose from)
  2. An Ethereum consensus client (there's even more)

That's it.

In other words, the web3 stack is new, but it's built on contemporary free and open-source systems we already know and love:

  • The Linux kernel, versatile and highly performant
  • Modern programming languages, typically Golang, Rust, Java, or NodeJS, depending on the client
  • Orchestration systems, like Docker and Kubernetes

There are usually other software components deployed alongside the Ethereum clients for monitoring and management purposes. In addition, there are certainly compute, bandwidth, and specialised skills requirements to keep these software components running smoothly.

Sadly, many of these requirements are fairly demanding, and usually discourage all but power-users from operating their own Ethereum node.

Running your local Ethereum node

If you have spare hardware and a decent internet connection, you can provision your own local node as a weekend project. The execution and consensus clients are memory and cpu efficient, but have significant storage and bandwidth requirements due to the need to transfer and persist the entire Ethereum blockchain to disk.

At the time of writing, the Ethereum Prater testnet (which is the most appropriate for development purposes) will consume approximately 300GB of disk storage. You will need an uncapped internet connection with at least 20Mbps of dedicated bandwidth for Ethereum. On the other hand, the proper Ethereum mainnet will require at least 1TB of disk space, but will operate at capacity; the recommendation these days is at least 2TB of storage.

The good news is that you can experiment with Ethereum nodes at your own pace. There's no implicit risk in provisioning the node and running the software because you don't need to become a validator and put your ETH at stake to run a local node. You can stake on your own node when you feel comfortable doing so.

Conclusion

Running an Ethereum node should be straightfoward to those who already have some knowledge of platform engineering and Linux systems, because the technology stack is perfectly aligned with contemporary open source tooling and deployment methodologies.

If you don't consider yourself very knowledgeable in this space, experimenting with a local node is a great opportunity to develop your skills, but you should consider whether you're prepared to become a proper validator given the hardware and technical requirements and the staking penalties for downtime.

My personal experiences with a local Ethereum node have been both a fun learning experience and a valuable research mechanism. Currently, my motivation is not to assume the responsibility of becoming a validator with ETH at stake, but rather to make technical contributions in this space to continue to learn and enhance accessibility for non-technical users. In my next post, I will describe the infrastructure I have developed for my node and how I will evolve it into an open-source project.

I hope to see you there!