Blockchain Networks

Blocks, Transactions, And Blockchain Systems and finished with introducing an important component, a blockchain node software. This is because a blockchain is in fact a network of entities each running a node softwares that interconnect together. These nodes then play different roles at different times. In this chapter, we will look at these roles, and see what each do at specific times. Notably, we should learn exactly when nodes in the blockchain networks execute the STF.

The ultimate purpose of the participants of this network is to come to a consensus about what the final State of the blockchain is, and what was the sequence of events (or Blocks, as we learned in the previous chapter) that led to this particular state. The umbrella term used to define the set of algorithms that dictate the above is the Consensus Algorithm of a blockchain.

Authoring Nodes

The first and most important role we look at is who can author a new block?. Different networks have different specification for this, but one common theme among them is as follows: One node authors a block, everyone else will check it.

In networks like Bitcoin and early-day Ethereum, all nodes can in principle be an author, although the chances of actually authoring a block might be near-zero for smaller participants.

In other more modern networks like current-day Ethereum and Polkadot, a subset of nodes are periodically elected as the set of authors, and for a period of time (often called an Epoch) rotate the authorship role among themselves. Once the epoch is over, a new set is elected and so on.

Note on Proof of Work and Proof of Stake

Ultimately, the defining the rules of authorship is the role of the Consensus Algorithm of the said blockchain and varies from protocol to protocol. The above two examples are broadly how Proof of Work and Proof of Stake work, two of the most popular Consensus Algorithms. We will discuss these two in detail in upcoming chapters.

Block authors usually have some sort of a Transaction queue within themselves, which is a queue of all transactions that are pending to be executed. When each of them gets a chance to author a block, they execute a subset of transactions (based on their preference, for example transactions that pay the most fee) using the STF, bundle them in a Block, and share it with the rest of the network.

While authoring a new block, the block author must also decide on 3 important Commitment Hashes that end up being in the header of their newly authored block:

• What is the State Root of the blockchain after this block is executed
• What is the parent block on top of which they authored a block. This matters, because two parent blocks would have different states, and therefore the current State Root would be different.
• The Commitment Hash of all transactions that they included in this block

Checking

A subset or all other nodes might be tasked to actively check the work of the authors, and report any misbehavior. The checkers will re-execute and check all aspects of the block, but it is most important to understand subset of it related to checking the State Root:

• They know the STF of the blockchain
• They receive a new block $B$ with header $H$ from an author.
• They first inspect the header $H$, and extract the parent hash $p$ from it.
• Then, they look up the state associated with block $p$ from their database, $S_p$.
• They import block $B$ on top of $S_p$, and re-create the state associated with execution of Block $B$: $S_B$
  • In other words: $STF(B,S_p)\to S_B$
• Then they re-calculate the State Root from their own local $S_B$, and ensure that this value matches to the state root noted in $H$.
• This, in effect, ensures that the block author executed $STF(B,S_p)$ correctly, and they noted the correct State Root in the header $H$.

What else checkers would typically do but are not mentioned above:

• Ensure the block number is correct and incrementing the parent by exactly $1$.
• Ensure the block author was eligible to author a block (depending on the Consensus Algorithm)
• Ensure the rest of the Commitment Hashes in the Header are correct.
• Any other checks specific to that blockchain.

Misbehavior

It is worth adding that the consequence of an author producing an invalid block (among other mis behaviors) is also different depending on the Consensus Algorithm. Some reside to actively slashing some funds from the block author, while some rely on social consensus and game theory.

Full Node

Full nodes are the ones that are following the work of the authors by re-executing the STF based on proposed blocks, but don’t actively participate in creation of new blocks.

For a network to have Resilience, it is utmost important for a full node software to be available, not need sophisticated hardware to run on, and be able to successfully sync the entire blockchain from genesis all the way to the tip of the chain.

This would the consequently allow anyone to verify any (old) state (e.g. how much BTC I had a year ago, and today?) which was one of the properties of Science-based Trust.

In the early days of blockchains, the assumption was that each user would run their own full node. This has proven to not work out these days, and Light Nodes are more feasible for individual users. But nowadays, we still often see organizations run their own full nodes: Exchanges, RPC providers etc.

Archive Nodes

Full nodes typically store the entire history of Blocks, but discard intermediate States. Because, given the correct $STF=F$, the genesis state $S_0$, and the sequence of $[bloc{k}_1,bloc{k}_2,...,bloc{k}_n]$, they can recreate any of the intermediate state $S_n$ by re-executing the sequence of:

• $F(bloc{k}_1,S_0)\to S_1$
• $F(bloc{k}_2,S_1)\to S_2$
• $...$
• $F(bloc{k}_n,S_{n-1})\to S_n$

If a node decides to store all of the intermediate states, it is typically called an archive node.

RPC Node

Either a full node or an archive node that decides to expose its database (of most notably $[bloc{k}_1,bloc{k}_2,...,bloc{k}_n]$ and $[S_0,S_1,...,S_n]$) over RPC is called an RPC node. Users of blockchains would frequently then connect to the RPC nodes to:

• Read information from the blockchain
  • What is my current BTC balance
  • What are the latest transactions that I submitted
• Submit new transactions to the blockchain

Crucially, an RPC node that merely replies to queries into its database with the raw answer is not particularly Resilience. This is because there is no easy way for the one asking the query to verify the result. The recipient would have to trust that the RPC node is being honest.

This is why the theoretically ideal scenario for connecting for a blockchain network is for each user to have their own full node running locally, such that they don’t need to rely on an external RPC node. Yet, this is not great for user-experience, and is generally addressed by using State Proofs within a Light Node, explained next.

Moreover, an RPC node can easily decide to censor certain users and transactions, something that has already happened. Using Light Nodes is orders of magnitude more resilient towards censorship.

State Proofs

One way to fix the problem with RPC Node is to use what is known as a State Proof. State proofs are cryptographic proofs of any given query over the state that are sent alongside the response, allowing the recipient to have absolute guarantee about the correctness of that response. The ability to generate efficient state proofs is the main reason why the Merkel Tree is used to represent the blockchain state, and the Commitment Hash of the state (State Root) is not merely a hash-list of the entire state, but rather the root of the Merkel tree.

Light Node

Light nodes are similar to full nodes in that they are not actively participating in authoring, and are merely following the chain. Yet, to save resources and be able to run with minimum CPU and storage requirement (for example, in a mobile phone or browser extension), they don’t re-execute the STF at every single block.

Instead, they only follow the block headers, and verify cryptographic proofs that the information in the header is correct. Crucially, if they know the correct header at a given block, they also know the correct State Root at that block. Then, they request State Proofs from other RPC/Full nodes to receive information with full Resilience.

Appendix

Proposer Builder Separation (PBS).

Predominantly in Ethereum, the task of finding the most efficient block to propose is further decoupled from the Authors, and is given to a market of other nodes that are actively searching and bidding for the best block to produce, called Proposers.

This is an implementation detail and does not alter the role of Authors and Checkers mentioned above. At the end of the day, Authors must somehow find a good block to propose. They either do that by looking at their transaction queue themselves, or by delegating this task to a proposer.

Consortium Blockchains

A blockchain may have a closed set of nodes that perform the Consensus Algorithm and is known as a Consortium Blockchains. Such networks only offer a subset of the Resilience aspects.

Two Layers of Networks

• Each blockchain is a network of nodes
• some blockchain ecosystems (Polkadot, Cosmos, Ethereum) is a network of blockchain
• Entire blockchain ecosystem can be seen as one big network
• Bridges acting

Summary

• Blockchain is a network of nodes
• Authors
• Checkers
• Full / RPC / Light / State Proof