Easier framing for blockchain nodes

In this article I outline the different types of blockchain nodes, explain their functions and suggest an alternative framework.

Before we dive into the world of blockchain nodes, I want to get one thing out of the way.

My goal is *not* to decide on standard terminology or flesh out precise technical definitions.

My goal is to share a mental model after synthesizing ideas from smart people in the industry. I’ll try to give credit to those people wherever possible.

Let’s start with the people who reviewed this article and offered feedback. Grateful for each of you: Sreeram Kannan (@sreeramkannan) Toghrul Maharramov (@toghrulmaharram) Dubbelosix (@dubbel06) Polynya (@apolynya) Hasu (@hasufl) Ryan Berckmans (@ryanberckmans)

Typically, blockchain nodes are thought about as:

• Validators
• Full nodes
• Light clients

📌 Yes there are other types of nodes (e.g. archive nodes) but these are the main three.

We’ll borrow definitions from Chainlinkgod’s awesome article on blockchain trust models and network participants. In the article he references “block producers’’ to include both PoW miners and PoS validators, but we’re going to focus on Ethereum-land and use the term validators.

Validators are “entities responsible for ordering and packaging transactions into discrete data structures called blocks which are then proposed to the network to validate. If two valid blocks are produced at the same block height, [validators] are responsible for determining which version of the chain is canonical.”

📌 What about PBS? PBS is a planned Ethereum upgrade that will split validators into two separate roles — one role (builders) will order and package transactions into blocks and another role (proposers) will propose and vote on blocks. It will likely take several years to implement and I don’t think it’ll be difficult to incorporate into the framework (which will be introduced soon), so I’ll leave it out of this article.

Full nodes “download and self-verify each block proposed by [validators]. If the block is found to be valid (i.e. protocol rules have been followed), then the block is added to the full node’s personal copy of the ledger and state changes are applied. Any invalid blocks not in line with the protocol’s rules are ignored and consequently discarded without any state changes occurring.”

Light clients (AKA light nodes) are “a limited form of a full node where only the headers (i.e. small unique cryptographic fingerprints) of blocks are downloaded. Light clients can verify if a transaction was included within a block, but because they do not download or execute all transactions within blocks, they implicitly trust that the majority of block producers are honest.”

I find these definitions fantastic, but it’s worth going a step further towards ELI5.

Basically, validators create and propose blocks (list of ordered transactions) when it’s their turn and vote on blocks when it’s not their turn. They vote on blocks that follow the protocol rules, since blocks that do not follow the rules are ignored. Validators know which blocks to ignore because they are also full nodes and verify transactions themselves.

Validators need to be full nodes, but full nodes don’t need to be validators. If your computer meets the minimum requirements, you can gain the benefits of a full node. You don’t need to stake 32 ETH.

Why is thinking about full nodes separately from validators important?

For that, I’ll refer you to this OG post by Dankrad, an Ethereum researcher. He walks through examples of how full nodes keep validators in check, “a bit like the separation of powers in liberal democracies”.

And where do light clients come in?

It’s clear that most users are not going to run full nodes, so light clients lower the cost of interacting with the blockchain. They enable things like in-browser / mobile wallets.

Light clients follow the canonical chain (what the majority of validators agree on). They check summary information of blocks by downloading block headers.

📌 If you want to better understand how light clients work, I recommend Etan Kissling’s talk from Devcon Bogota.

If you are building in the space or frequent Crypto Twitter (CT), you might already know some (or all) of the above.

So what’s the issue?

Well, if you frequent CT you might also see how often terms are questioned. Here’s Sreeram from EigenLayer questioning the term validator and Toghrul from Scroll expressing the need for new terms.

If this is problematic for CT, think about how hard it must be for newcomers. Here’s Vitalik explaining the many ways users can connect to blockchains. Ok — cryptographer Moxie might figure this out — but it’s a lot!

Why are current terms suboptimal?

The double-edged sword of decentralization! New tech and ideas sprout up across the ecosystem at a rapid pace and there’s no Blockchain Marketing Department.

Instead, we (the community) must collaborate across layers and protocols to make sure people aren’t speaking past each other. This article is meant to foster that collaboration.

When discussing nodes, we typically focus on implementation. But is this always the best approach when implementation changes over time? Should we instead focus on core functions?

First, let’s examine the term validators. Sreeram frames this nicely, peeling apart today’s implementation and distinguishing between replaceable / irreplaceable functions.

Both witness nodes and consensus nodes seem better than validators, but we’ll go with the latter since consensus is a more familiar term in the blockchain space.

Now let’s discuss full nodes and light clients.

Full nodes are at the center of many debates — about whether people “care” to run them, how many people run them, how expensive they are to run, etc. Light clients, on the other hand, aren’t discussed as much since they have just become possible in Ethereum-land.

But what are these nodes trying to accomplish and what are people typically debating? Fundamentally it’s about the cost to verify blockchain information.

This is where things get a little trickier, so bear with me. There are different types of blockchain information we might verify:

• Consensus verification
• Computation / state transition verification
• Data availability verification

📌 I’ll borrow the latter two definitions from Vitalik’s article.

Consensus verification means checking that a block was included in the canonical chain and that a transaction was included in that block.

Computation / state transition verification means “checking that some computation was done correctly, assuming you have possession of all the inputs to the computation”.

Data availability verification means “checking that the inputs to the computation themselves are stored in some form where you can download them if you really need to; this checking should be performed without actually downloading the entire inputs themselves”.

If consensus verification sounds familiar, it’s because we described the same functionality when we defined light clients earlier. This is in fact what light clients support today!

However, we should avoid equating light clients to consensus verification (which people often do). Due to technical improvements like ZK / fraud proofs and data availability sampling, light clients will eventually perform all three types of verification.

This will allow light clients to achieve roughly the same security guarantees as full nodes and will break the current mental model. We’ll need new terms.

📌 If you want to better understand the technical improvements mentioned above and their trust assumptions, I recommend these three posts by Vitalik.

Ok, let’s bring it all together and entertain a new framing. What if we thought about blockchain nodes like this:

Validators → consensus nodes

Nodes that verify blockchain information (less focus on full vs. light clients) → verifier nodes

Nodes that verify consensus → consensus verifiers

Nodes that verify computation / state transitions → state verifiers

Nodes that verify data availability → DA verifiers

Nodes that verify consensus, computation / state transitions and data availability (or the max number of types possible to verify on a given chain) → full verifiers

Here’s a cleaner visual. You can see there are two high-level categories and the latter can be broken into four low-level subcategories.

📌 Terms emerged from conversations with Sreeram, Toghrul and Dubbelosix.

Again, this article is meant to offer a framework for thinking about blockchain nodes — with the goal of making them easier to understand and discuss.

It’s likely some solutions take years to build (we’ll save specific implementations and timelines for another article), so it’s important that we can clearly communicate what we’re building towards.

Is this definitely the best framing?

Not sure! There could be better ones out there and I hope they surface. For example if you think of a nice way to incorporate PBS or Layer 2 nodes, would love to hear it! Let’s iterate.

If this article gets us closer to the endgame, I’ll be happy.

New to trading? Try crypto trading bots or copy trading