What are eth nodes?

Ethereum is a distributed network of computers (known as nodes) running software that can verify blocks and transaction data. The software application, known as a client, must be run on your computer to turn it into an Ethereum node.

Note: it is not possible to run an execution client on its own anymore. After The Merge, both execution and consensus clients must be run together in order for a user to gain access to the Ethereum network.

You should understand the concept of a peer-to-peer network and the basics of the EVM before diving deeper and running your own instance of an Ethereum client. Take a look at our introduction to Ethereum.

If you're new to the topic of nodes, we recommend first checking out our user-friendly introduction on running an Ethereum node.

A "node" is any instance of Ethereum client software that is connected to other computers also running Ethereum software, forming a network. A client is an implementation of Ethereum that verifies data against the protocol rules and keeps the network secure.

Post-Merge Ethereum consists of two parts: the execution layer and the consensus layer. Both layers are run by different client software. On this page, we'll refer to them as the execution client and consensus client.

Before The Merge, consensus and execution layer were separate networks, with all transactions and user activity on the Ethereum happening at what is now the execution layer. One client software provided both execution environment and consensus verification of blocks produced by miners. The consensus layer, the Beacon Chain, has been running separately since December 2020. It introduced proof-of-stake and coordinated the network of validators based on data from the Ethereum network.

With the Merge, Ethereum transitions to proof-of-stake by connecting these networks. Execution and consensus clients work together to verify Ethereum's state.

Modular design with various software pieces working together is called encapsulated complexity(opens in a new tab)↗. This approach makes it easier to execute The Merge seamlessly and enables the reuse of individual clients, for example, in the layer 2 ecosystem.

(opens in a new tab)↗ Simplified diagram of a coupled execution and consensus client.

Both execution clients and consensus clients exist in a variety of programming languages developed by different teams.

Multiple client implementations can make the network stronger by reducing its dependency on a single codebase. The ideal goal is to achieve diversity without any client dominating the network, thereby eliminating a potential single point of failure. The variety of languages also invites a broader developer community and allows them to create integrations in their preferred language.

Learn more about client diversity.

What these implementations have in common is they all follow a single specification. Specifications dictate how the Ethereum network and blockchain functions. Every technical detail is defined and specifications can be found as:

Multiple trackers offer a real-time overview of nodes in the Ethereum network. Note that due to the nature of decentralized networks, these crawlers can only provide a limited view of the network and might report different results.

If you want to run your own node, you should understand that there are different types of node that consume data differently. In fact, clients can run three different types of nodes: light, full and archive. There are also options of different sync strategies which enable faster synchronization time. Synchronization refers to how quickly it can get the most up-to-date information on Ethereum's state.

Instead of downloading every block, light nodes download block headers. These headers only contain summary information about the contents of the blocks. Any other information required by the light node gets requested from a full node. The light node can then independently verify the data they receive against the state roots in the block headers. Light nodes enable users to participate in the Ethereum network without the powerful hardware or high bandwidth required to run full nodes. Eventually, light nodes might run on mobile phones or embedded devices. The light nodes do not participate in consensus (i.e. they cannot be miners/validators), but they can access the Ethereum blockchain with the same functionality and security guarantees as a full node.

Light clients are an area of active development for Ethereum and we expect to see new light clients for the consensus layer and execution layer soon. There are also potential routes to providing light client data over the gossip network(opens in a new tab)↗. This is advantageous because the gossip network could support a network of light nodes without requiring full nodes to serve requests.

Ethereum does not support a large population of light nodes yet, but light node support is an area expected to develop rapidly in the near future. In particular, clients like Nimbus(opens in a new tab)↗, Helios(opens in a new tab)↗, and LodeStar(opens in a new tab)↗ are currently heavily focused on light nodes.

Syncing clients in any mode other than archive will result in pruned blockchain data. This means, there is no archive of all historical states but the full node is able to build them on demand.

Learn more about Archive nodes.

Running a node allows you to directly, trustlessly and privately use Ethereum while supporting the network by keeping it more robust and decentralized.

Running your own node enables you to use Ethereum in a private, self-sufficient and trustless manner. You don't need to trust the network because you can verify the data yourself with your client. "Don't trust, verify" is a popular blockchain mantra.

(opens in a new tab)↗

A diverse set of nodes is important for Ethereum’s health, security and operational resiliency.

If you run a full node, the whole Ethereum network benefits from it.

Interested in running your own Ethereum client?

For a beginner-friendly introduction visit our run a node page to learn more.

If you're more of a technical user, dive into more details and options on how to spin up your own node.

Setting up your own node can cost you time and resources but you don’t always need to run your own instance. In this case, you can use a third party API provider like Infura(opens in a new tab)↗, Alchemy(opens in a new tab)↗, Chainstack(opens in a new tab)↗, QuikNode(opens in a new tab)↗, Tenderly(opens in a new tab)↗, Blast(opens in a new tab)↗, DRPC(opens in a new tab)↗, or GetBlock(opens in a new tab)↗. For an overview of using these services, check out nodes as a service.

If somebody runs an Ethereum node with a public API in your community, you can point your light wallets (like MetaMask) to a community node via Custom RPC(opens in a new tab)↗ and gain more privacy than with some random trusted third party.

On the other hand, if you run a client, you can share it with your friends who might need it.

The Ethereum community maintains multiple open-source execution clients (previously known as 'Eth1 clients', or just 'Ethereum clients'), developed by different teams using different programming languages. This makes the network stronger and more diverse. The ideal goal is to achieve diversity without any client dominating to reduce any single points of failure.

This table summarizes the different clients. All of them pass client tests(opens in a new tab)↗ and are actively maintained to stay updated with network upgrades.

Note that OpenEthereum has been deprecated(opens in a new tab)↗ and is no longer being maintained. Use another client implementation!

For more on supported networks, read up on Ethereum networks.

Each client has unique use cases and advantages, so you should choose one based on your own preferences. Diversity allows implementations to be focused on different features and user audiences. You may want to choose a client based on features, support, programming language, or licences.

Hyperledger Besu is an enterprise-grade Ethereum client for public and permissioned networks. It runs all of the Ethereum Mainnet features, from tracing to GraphQL, has extensive monitoring and is supported by ConsenSys, both in open community channels and through commercial SLAs for enterprises. It is written in Java and is Apache 2.0 licensed.

Besu's extensive documentation(opens in a new tab)↗ will guide you through all details on its features and setups.

Erigon, formerly known as Turbo‐Geth, started as a fork of Go Ethereum oriented toward speed and disk‐space efficiency. Erigon is a completely re-architected implementation of Ethereum, currently written in Go but with implementations in other languages under development. Erigon's goal is to provide a faster, more modular, and more optimized implementation of Ethereum. It can perform a full archive node sync using around 2TB of disk space, in under 3 days.

Go Ethereum (Geth for short) is one of the original implementations of the Ethereum protocol. Currently, it is the most widespread client with the biggest user base and variety of tooling for users and developers. It is written in Go, fully open source and licensed under the GNU LGPL v3.

Learn more about Geth in its documentation(opens in a new tab)↗.

Nethermind is an Ethereum implementation created with the C# .NET tech stack, licensed with LGPL-3.0, running on all major platforms including ARM. It offers great performance with:

Nethermind also has detailed documentation(opens in a new tab)↗, strong dev support, an online community and 24/7 support available for premium users.

There are multiple consensus clients (previously known as 'Eth2' clients) to support the consensus upgrades. They are running the Beacon Chain and will provide a proof-of-stake consensus mechanism to execution clients after The Merge.

Lighthouse is a consensus client implementation written in Rust under the Apache-2.0 license. It is maintained by Sigma Prime and has been stable and production-ready since Beacon Chain genesis. It is relied upon by various enterprises, staking pools and individuals. It aims to be secure, performant and interoperable in a wide range of environments, from desktop PCs to sophisticated automated deployments.

Documentation can be found in Lighthouse Book(opens in a new tab)↗

Lodestar is a production-ready consensus client implementation written in Typescript under the LGPL-3.0 license. It is maintained by ChainSafe Systems and is the newest of the consensus clients for solo-stakers, developers and researchers. Lodestar consists of a beacon node and validator client powered by JavaScript implementations of Ethereum protocols. Lodestar aims to improve Ethereum usability with light clients, expand accessibility to a larger group of developers and further contribute to ecosystem diversity.

More information can be found on our Lodestar website(opens in a new tab)↗

Nimbus is a consensus client implementation written in Nim under the Apache-2.0 license. It is a production-ready client in use by solo-stakers and staking pools. Nimbus is designed for resource efficiency, making it easy to run on resource-restricted devices and enterprise infrastructure with equal ease, without compromising stability or reward performance. A lighter resource footprint means the client has a greater margin of safety when the network is under stress.

Implemented by Trinity. Works like fast sync but also downloads the data needed to execute latest blocks, which allows you to query the chain within the first few minutes from starting.

Learn more in Nimbus docs(opens in a new tab)↗

Prysm is a full-featured, open source consensus client written in Go under the GPL-3.0 license. It features an optional webapp UI and prioritizes user experience, documentation, and configurability for both stake-at-home and institutional users.

Visit Prysm docs(opens in a new tab)↗ to learn more.

Teku is one of the original Beacon Chain genesis clients. Alongside the usual goals (security, robustness, stability, usability, performance), Teku specifically aims to comply fully with all the various consensus client standards.

Teku offers very flexible deployment options. The beacon node and validator client can be run together as a single process, which is extremely convenient for solo stakers, or nodes can be run separately for sophisticated staking operations. In addition, Teku is fully interoperable with Web3Signer(opens in a new tab)↗ for signing key security and slashing protection.

Teku is written in Java and is Apache 2.0 licensed. It is developed by the Protocols team at ConsenSys that is also responsible for Besu and Web3Signer. Learn more in Teku docs(opens in a new tab)↗.

To follow and verify current data in the network, the Ethereum client needs to sync with the latest network state. This is done by downloading data from peers, cryptographically verifying their integrity, and building a local blockchain database.

Synchronization modes represent different approaches to this process with various trade-offs. Clients also vary in their implementation of sync algorithms. Always refer to the official documentation of your chosen client for specifics on implementation.

Full sync downloads all blocks (including headers, transactions, and receipts) and generates the state of the blockchain incrementally by executing every block from genesis.

Fast sync downloads all blocks (including headers, transactions, and receipts), verifies all headers, downloads the state and verifies it against the headers.

Light client mode downloads all block headers, block data, and verifies some randomly. Only syncs tip of the chain from the trusted checkpoint.

NB Light sync does not yet work with proof-of-stake Ethereum - new versions of light sync should ship soon!

More on light clients

Snap sync is the latest approach to syncing a client, pioneered by the Geth team. Using dynamic snapshots served by peers retrieves all the account and storage data without downloading intermediate trie nodes and then reconstructs the Merkle trie locally.

More on snap sync(opens in a new tab)↗

Optimistic sync is a post-merge synchronization strategy designed to be opt-in and backwards compatible, allowing execution nodes to sync via established methods. The execution engine can optimistically import beacon blocks without fully verifying them, find the latest head, and then start syncing the chain with the above methods. Then, after the execution client has caught up, it will inform the consensus client of the validity of the transactions in the Beacon Chain.

More on optimistic sync(opens in a new tab)↗

Checkpoint sync, also known as weak subjectivity sync, creates a superior user experience for syncing Beacon Node. It's based on assumptions of weak subjectivity which enables syncing Beacon Chain from a recent weak subjectivity checkpoint instead of genesis. Checkpoint sync makes the initial sync time significantly faster with similar trust assumptions as syncing from genesis.

In practice, this means your node connects to a remote service to download recent finalized states and continues verifying data from that point. Third party providing the data is trusted and should be picked carefully.

More on checkpoint sync(opens in a new tab)↗

There is a lot of information about Ethereum clients on the internet. Here are few resources that might be helpful.

An Ethereum node is simply any computer running the software needed to connect with the Ethereum network. Nodes connect with one another to send information back and forth to validate transactions and store data about the state of the blockchain.

An Ethereum node is simply any computer running the software needed to connect with the Ethereum network. Nodes connect with one another to send information back and forth to validate transactions and store data about the state of the blockchain.

Though the terms are often used interchangeably these connected computers are the nodes and the software that they run is called the client.

‍

Nodes make up the blockchain network and are the only way to access it.

Each node maintains its own copy of the blockchain and works to ensure this copy checks out with all the other nodes and their respective copies.  Anytime you do anything and a new block needs to be added to the blockchain, every single node on the network has to process it.

Each node chooses to accept or reject the newest block based on the validity of its signatures and transactions. If the block is accepted then it continues to be shared with other nodes until a consensus is reached and they are all in sync. Nodes are quickly able to reject invalid blocks and identify bad nodes that are attempting to break the rules. It’s this network of nodes constantly communicating that makes it possible to not need to rely on a single source of truth and all the problems that come with it.

This consensus among different nodes makes blockchain networks decentralized and is the backbone of Web3. The more nodes there are running, the stronger the blockchain becomes!

‍

There are three types of nodes:

A light node downloads only the block headers, which is the minimum data it needs to transact on the network. A light node can validate a transaction because it is able to regenerate the specific block it needs to check by using this data.

This enables light nodes to efficiently interact with the network and save megabytes of bandwidth and gigabytes of storage.  Because of this, light nodes can run on everyday devices with limited memory resources, like smartphones and laptops.

But light nodes also have their limitations. Light nodes will sometimes need to ask full nodes for the data they don’t have access to, which could take longer than a full node validating the transaction.

While a light node is the easiest way to run a node, it still takes time and know-how to install the client, configure variables, download block headers, and check to ensure that everything is running smoothly.

A full node has everything it needs to verify that the blocks on the network are correct. It can interact with any smart contract and deploy its own.

The full use and storage of data means that full nodes require a lot more computing and bandwidth resources. A full node downloads, stores, and verifies the full blockchain state - everything from block zero to the most recent block (+10M and counting), which can take weeks to sync!

An archive node goes one step further than a full node. While a full node trims entries that it no longer needs to verify, the latest interactions with the chain, the archive node maintains everything (terabytes of extra data). These details are great for querying information more efficiently and handy for a few applications, but are excessive in most cases.

‍

Getting a node up and running can be a lengthy and challenging process. This is especially true if you are new to the Web3 world and don’t have the technical expertise (at least, not yet).

Just the potential weeks it takes for a full node to sync to all +10M nodes for the current state of blockchain can turn off many from building in the space.

Costs are also a factor, and they can add up quickly. These include the high initial investment to purchase hardware and the ongoing costs of electricity and server hosting. When operating a node you have to also make sure it is constantly in operation. Laggy internet, electric outages, or hardware issues can lead to costly downtime.

While client updates help to constantly improve the scalability, security and sustainability of Ethereum, these changes can lead to unexpected issues. And the problems really begin when you try to build something bigger!

‍

Ethereum nodes were never really designed to scale to this level of requests and can pose some unique challenges.

Some requests will ask the node to query all the way back from log zero to the current block and can time out.  These “queries of death” can crash a node and can happen at any time of the day. Even if a node is 72% reliable like a standard node, that means that an application can be offline for over a hundred days a year!

Scaling node infrastructure can be tricky. Imagine the application you’re building goes viral overnight on Twitter but the existing nodes you’re running can’t keep up with the sudden spike in traffic and transaction volume.

You can’t just quickly spin up new nodes because they take weeks to sync. On top of that, the new demand could overwhelm your existing nodes and cause them to crash. This could result in downtime, where no one can use your application, and unhappy users who don’t think they can rely on what you’ve built!

In Web2, sites are able to work around these issues of scalability by using load balancers, a network layer that sits on the top and distributes traffic across indistinguishable servers. This isn’t possible with nodes because blockchain is asynchronous. While two nodes should share an identical latest block eventually, at any given time, one might lag behind another.

Load balancing could lead to two very different results because traffic is routed through different nodes with different views on the latest block. Imagine buying that NFT you’ve been coveting but then refreshing to find that it seems to have disappeared!

Attempting to avoid these sort of data inconsistencies leads developer teams to patch together complex workarounds that inevitably cause errors and crash their application. All these problems mean that when dealing with nodes, developers often must choose between scaling, maintaining reliability or ensuring consistent data, which leads to a less than ideal experience for everyone.

‍

If this all seems a bit overwhelming, don’t worry! Whether you’re just getting started or think you’re spending too much time and money on node problems, then nodes-as-a-service might be the solution for you.

Node providers like Alchemy run nodes so you can focus on developing your application. It’s incredibly easy to integrate most providers - it’s often just an API to  get started reading and writing onto the blockchain.

That means instead of having to pay for server access, meet hardware requirements and maintain state all by yourself, you can use Alchemy's Supernode infrastructure…

… with a single line of code.

Alchemy is able to ensure supercharged data correctness through a proprietary coordinator service and best-in-class reliability. They do this through a dedicated, distributed system allowing you to scale quickly and seamlessly to help you build better and ship faster.

Leading blockchain companies and projects like OpenSea, Dapper Labs, 0x, Royal, Axie Infinity, and hundreds more all choose Alchemy because of our incredibly high reliability, legendary customer service, and amazing suite of products that makes building in Web3 more accessible than ever.

‍