So much has been said about how to model blockchains in abstract terms Execution, Ordering, History and State Machines, and what properties they have. But it is finally time to define few concrete keywords about blockchains. Establishing these keywords now will also make reading the next chapters smoother, as a reader would have a concrete terms to refer to something (e.g. a block, transaction, or header).
Blockchain Systems != Blockchain
First, let’s establish that unfortunately we live in a world where names are often mistakenly attributed to a broader terms. In the consumer products, this is called genericized trademarks (like Xerox and Kleenex), and what we see here is the technological equivalent of that.
We refer to a very broad system, composed of many technologies, a blockchain, even though a blockchain is merely a data-structure used in a little corner of it, and it is not even a fundamental one.
So, going forward, when the word blockchain is used, we often mean a broad system that utilizes a blockchain. More on this in Blockchains Are Overrated.
Next, let’s jump into defining a keywords around blockchains, and how they link to what has been said in the previous chapter.
Blockchain Terminology
- Recall a blockchain’s main ultimate purpose is to store some (contentious) State, and it update in what is known as a State Transition Function or STF.
- The event that causes the STF to be executed is a new Block. So, the block is the input to the STF.
- A Block is composed of a Block Header, and a set of instructions. In most cases, these instructions come from external users, and are called Transaction.
- The Block Header contains a few key pieces of information, most notably:
- A Commitment Hash (in the form of a Merkel Tree) to the state of the blockchain after execution of this block, and all of the transactions in this block
- The hash of the parent block on top of which this block is meant to be considered valid
- These hashes, combined together, ensure some of the Resilience properties of blockchains.
- More about the blockchain State. the state of the blockchain is only ever meaningful when linked to a specific block. This is because, a blockchain system essentially has 2 types of states:
- the genesis state, which needs to be hardcoded and agreed upon by everyone
- All the rest
- The reason why we emphasize this is that the rest of the states, say at block , can always be re-computed by executing the sequence of blocks from to . Revisit the Genesis And Syncing for a refresher if need be.
Node Software / Client
Finally, why we have not zoomed out and looked at the entities that run a blockchain in a network (this comes in the next chapter, Blockchain Networks), for now assume that to run a blockchain, one typically has to run a software that is called Blockchain Node or client.
What we can re-emphasize here is a few key actions that each node does, and what data they stored. This information will be complemented further in the next chapter, Blockchain Networks.
- Most importantly, for all the reasons said in the above, most nodes opt to store the entire history of all past blocks, as it is the most straightforward way for them to (re)verify the entire history of the blockchain, one of the key pillars of its Resilience.
- Each node typically stores the State associated with a number of recent blocks, and at times, all of them. Recall that storing old states is entirely optional. Any old state can always be re-constructed when needed (although, it can be time-consuming, therefore some nodes opt to store all previous states).
- The node software runs the State Transition Function upon accepting new blocks, or when itself authors new blocks.
Summary
This chapter was mainly about terminology, and making the reader familiar with blockchain lingo, such as Block, Block Header, and Transaction.
We also briefly explained what each Node Software / Client in a network does, and we further explain this in the next chapter, Blockchain Networks.