Blockchains have revolutionised the world of finance, distributed computing, cryptography, and more. However, it has been observed that properly breaking down this new technology into its fundamental parts has been quite lacking. Most attempts in mainstream publications either conflate and misrepresent many concepts regarding the blockchain architecture or present them in a manner anecdotal to the implementation details of specific blockchain projects.

For example, one might often hear that “a blockchain consists of two core components: consensus and execution” or that “a blockchain comprises a hardware layer, data layer, consensus layer, and application layer.” Astute researchers and engineers exploring various blockchain projects and their architectures may notice these discrepancies which may often have them confused or adopt a skewed perspective, which could inadvertently complicate their future designs and analyses.

This article intends to offer a generalised view of the conventional blockchain architecture, abstracted from the implementation details of any specific blockchain project, such that it can serve as a universal framework for analysing any present-day blockchain project.

The term “Blockchain” is one that has been run through the mill so many times by so many people and publications to the point where it has become needlessly nebulous. Depending on where you read from, you might be told that a Blockchain is a “distributed database”, a “shared ledger”, or simply a “data structure”.

We will circle back to the intricate definitions and delineations of the term, exploring its use in a future article. For now, know that the term “Blockchain” is quite overloaded, and the definition suggested in this article is an effort to refine it, albeit from a subjective standpoint.

In this article, we define a blockchain as an internet technology that leverages a networking infrastructure (usually a peer-to-peer network), a set of coordination protocols, and a cluster of participating machines, to accomplish essential tasks under certain desired constraints, qualities, and guarantees, such as censorship and tamper resistance, access control, open accountability, privacy, etc.

Today, it can be estimated that there are at least a thousand operational blockchain projects, each with similar or distinct goals. Examples of these projects include Bitcoin, Ethereum, Solana, etc.

A full-fledged blockchain system is a complex assembly of technology, made up of various components functioning at different layers that work independently and collectively, much like a layered cake, to yield an operational blockchain. These components essentially exist as protocols in their own right, each functioning within its specific layer, inclusive of their respective sub-protocols and dependencies.

We describe the core architecture of the conventional blockchain system, commonly implemented in the form of a node software, in four core layers, in order of precedence: Networking, Consensus, Ledger, and Runtime.

You can think of these layers as the scopes within which core components operate, akin to how each layer of the OSI model has components that function within it.

Let’s dive in…

The first important step and requirement for constructing a blockchain system is to establish a common foundation for communication. This foundation allows all involved parties, i.e., nodes, to reliably discover and exchange messages, enabling them to collaborate effectively. The networking layer serves as this foundation and is typically instantiated in the form of a peer-to-peer (a.k.a. P2P) network, as this networking mode ensures that there are usually few-to-no central points of failure or capture in communication.

The Networking Layer is critical for the discovery of peers and the exchange of crucial data necessary for the coordination of work performed at the next layer of the blockchain architecture. A core networking protocol is implemented at this layer to ensure that appropriate data flows and resource controls are in place for a healthy communication framework of a blockchain.

Some core networking protocols used at the Networking Layer by blockchain projects include:

• LibP2P - used by Ethereum, Polkadot, etc.

• DevP2P - used by Ethereum

• Tendermint P2P - used by CosmosHub, Osmosis, Axelar, etc.

Additionally, a core networking protocol is made up of several sub-protocols needed to perform various interdependent tasks, all of which are important to verify and control the flow of data needed by all participants to do work at the subsequent layers of the blockchain architecture. Some of these include, but are not limited to, the following:

• Peer Discovery Protocol

• Inter-Node Communication Protocol

• Multiplexer

• Block Propagation Protocol

• Transport Protocol

• Chain Syncing protocol

• Authentication Protocol

• Mempool

Think of the Networking Layer as the Slack channel or group chat where all the parties involved in making the blockchain system operational find and talk to each other about everything they have to.

With an established Networking Layer enabling all interested parties to join a shared network, discover peers, and exchange messages, one might wonder, “Why?” The answer lies in the Consensus Layer, where the work necessitating a common network for communication is performed.

The Consensus Layer hosts the core coordination frameworks that guide all involved parties in identifying their roles, understanding their unique tasks, and ensuring the correct and honest execution of these tasks. A Consensus Mechanism serves as the core component implemented to specify and oversee the required work of the connected parties on the network.

A consensus mechanism is fundamentally a set of rules or protocol that employs algorithms and incentives to guarantee honest and productive participation from all parties involved in a system, aiming to achieve consensus among all or the majority of participants, i.e., nodes.

In addition to coordinating work, the consensus mechanism plays a crucial role in ensuring robustness and implementing mitigation and recovery measures against potential threats posed by malicious actors. Blockchains commonly incorporate design decisions that promote fault tolerance and adopt economic strategies, such as locking requirements and slashing penalties on the staked resources of network participants.

Not all blockchain projects prioritise the same features, leading to a diversity in the design of consensus mechanisms. Each blockchain project must weigh the trade-offs to align with their specific goals. The qualities and guarantees preferred by a given blockchain determine the kind of consensus mechanism implemented in its Consensus Layer. Some examples of consensus mechanisms include:

• Nakamoto Consensus, used by Bitcoin, Bitcoin Cash, LiteCoin

• Gasper, used by Ethereum.

• Tendermint, used by CosmosHub, Osmosis, Axelar, etc.

• Ouroboros, used by Cardano, MINA, Ergo, etc.

Similar to the core networking protocol in the Networking Layer, the core consensus mechanism—or protocol—is comprised of various sub-protocols. Each of these sub-protocols plays a vital role in maintaining the integrity and functionality of the consensus layer. Some of these sub-protocols include (but are not limited to):

• Sybil Control Protocol: This includes mechanisms such as Proof-of-Work (PoW), Proof-of-Stake (PoS), and others that help prevent or resist Sybils i.e., multiple fraudulent identities, from influencing the network.

• Data Control Protocol: This touches on the storage sub-protocol which encompasses aspects like Data Availability and enforcing the set limits on resources such as Block size and Compute Units, to ensure efficient processing.

• Leader Selection Protocol: This involves methods such as Randomisation, Round Robin, Election, and more to fairly select the candidate node responsible for leading a consensus slot, i.e., creating the next block.

• Fork Choice or View Switch Protocol: This refers to the rules used to choose between conflicting chains or views, such as the Longest-chain rule in Nakamoto Consensus or Linear View Change rule in HotStuff.

• Finality Gadget: This sub-protocols ensures that all confirmed blocks are persistent after a period of time and/or certification. Ethereum’s Casper(FFG) and Polkadot’s GRANDPA are good examples.

The rigorous standards and work accomplished at the Consensus Layer culminate in a network that, despite operating under the assumption of potential adversarial activity, manages to establish distributed trust. We refer to this concept as a Distributed Trust Network. Essentially, it represents the core value proposition of blockchains, offering decentralised and reliable security for financial systems, identity frameworks, and various digital infrastructures.

Think of the Consensus Layer as the code of conduct and chores list that everyone in the Slack channel or group chat have to follow in order to stay and contribute in the chat.

If the Consensus Layer serves as the body of the conventional blockchain, then the Ledger Layer is indeed its soul, infusing it with meaning and purpose, a raison d’être. It not only provides further context to the "Why?” question for the Consensus Layer, but also answers the “What(for)?” question.

The Ledger Layer hosts the autonomous world in which digital ecosystems and resources exist, and stands as the paramount value system of the blockchain architecture. At the heart of the Ledger Layer lies the Ledger Protocol, which is characterised as a State Machine (alternatively termed a State Transition System in some literature) and widely acknowledged as the fundamental embodiment of the blockchain's mutable "state.”

The Ledger Protocol (or simply Ledger) strictly defines the structure, constraints, and rules of the (autonomous) world it encapsulates and serves as the authoritative record-keeping system for that world. Those who are very familiar with blockchains, like Ethereum, for example, better know the Ledger as the ‘World State’ that holds all the accounts and their respective balances of every participant (human and on-chain script) to ever interact within the Ethereum. This world state is commonly implemented as a kind of data structure(usually a Merkle Tree, or a variation of one) and stored as a database file. An example of this is in Ethereum, where the world state is specified as a Merkle Patricia Trie structure. An ethereum node implementations, like Go-Ethereum (Geth), leverages LevelDB to implement the structure.

The above example follows a similar practise taken by the majority of blockchain projects in the industry; however, not all blockchains are the same when it comes to how they view and access their world state. A key distinction in this context is the transaction-recording model they employ, which fundamentally dictates the method by which their operators manage the bookkeeping. Today, the popular transaction-recording models used by blockchains are:

• Unspent Transaction Output model (a.k.a. UTXO), which is used by Bitcoin, Zcash, etc.

• Account-Balance Pair model, which is used by Ethereum, Optimism, etc.

Note: The transaction-recording model employed by a given ledger very much influences its (world) state access patterns and (dis)advantages, such as parallelism, localisation, privacy, etc.

The Ledger Protocol extends beyond its state; it encompasses various sub-protocols that stipulate and enforce policies and parameters, including (but not limited to):

• Monetary Policy: Examples include Bitcoin's 21 million bitcoin hard cap and Ethereum's EIP-1559.

• Governance Protocol: Examples include Polkadot’s OpenGov, Tezos Governance, CosmosHub Governance, and others.

• State Transition Ruleset: This involves provisions and conditions for correct state changes such as signature requirements, native scripting and state transition function, conservation of value, and much more.

• Fee Cost Models: This encompasses parameters like base fee costs for transactions.

• Consensus Participation Rules: Examples include minimum stake requirements and slashing penalties.

• Resource Limits: Parameters like Block Size and Transaction Size fall under this category.

Think of the Ledger Layer as the system that controls how long your username can be, what emojis are allowed, and logs all the things that represent your being in the Slack channel or group chat, such as your current follower/following counts.

For the initial six years following the inception of the very first conventional blockchain project, Bitcoin, most blockchain systems primarily depended on the native scripting functionality of their ledger protocols for simple computation. More complex computation needs were addressed through off-chain environments.

This persisted as the norm until the Ethereum project revolutionised blockchain architecture with the introduction of a Runtime Layer via the Ethereum Runtime Environment (ERE), which included the Ethereum Virtual Machine (EVM). The Runtime Layer marked a significant departure, providing a comprehensive runtime environment equipped with essential sub-protocols, including a virtual machine. This advancement enabled the execution of advanced computations directly within the blockchain system. Notably, Ethereum, introduced in 2015, presented a Turing-complete system, empowering the platform with the ability to handle arbitrary computations.

The Runtime Layer plays a crucial role as it defines the State Transition Function built on top of the Ledger protocol. At the heart of the Runtime Layer, the Runtime Environment serves as a core component or protocol, ensuring the availability and functionality of essential libraries, structures, and primitives, necessary for the valid execution of complex computations on the Ledger State.

Composed of sub-protocols, the Runtime Environment efficiently manages diverse fields and contexts of computation within the system. Some of these sub-protocols include(but not limited to):

• Abstract or Virtual Machine: a software implementation of a physical or abstract machine in which on-chain scripts are executed. eg. EVM, MoveVM, SVM, etc.

• Interfaces: a framework of API endpoints that are used to communicate between the runtime layer and its components, and the rest of the blockchain system. eg. RPC, Ledger-API, etc.

• Compilers and Interpreters: a module responsible for converting high-level instructions to low-level instructions, for script execution.

• Cost Modelling and Evaluation Unit: a module responsible for setting the resource budget limits, and evaluating the resource utilisation of an on-chain script, to apply appropriate costs for computation.

Over the years, we've witnessed the emergence of various blockchain projects releasing their own solutions for the Runtime Layer. Some notable examples include:

• Ethereum Runtime Environment, which incorporates the Ethereum Virtual Machine (EVM) and is utilised by projects such as Ethereum, Polygon, Optimism, etc.

• Substrate Runtime, featuring the WASM runtime and employed by projects such as Polkadot.

• Sealevel Runtime, integrating the Solana eBPF Virtual Machine (a.k.a. SVM) and utilised by projects such as Solana.

The Runtime Layer, equipped with a Runtime Environment and its associated sub-protocols, notably a Virtual Machine, provides the essential tools and prerequisites for the execution of on-chain scripts(a.k.a. smart contracts) that power up end-user applications.

Think of the Runtime Layer as the feature in the Slack channel or group chat that allows you to use special commands, shortcuts, and bots to enhance your productivity and general experience.

The conventional blockchain system is a sophisticated assembly of technology, meticulously organised into four core layers: Networking, Consensus, Ledger, and Runtime. These layers, akin to a layered cake, operate independently and collectively to bring a blockchain system to life.

Whether you're a blockchain researcher, engineer, or just an enthusiast, this generalised view of the conventional blockchain architecture aims to provide a universal framework independent of any specific blockchain project. Understanding these fundamental layers is crucial for forming the appropriate mental models to design robust blockchain systems and for the effective analysis of them.

Blockchains have revolutionised the world of finance, distributed computing, cryptography, and more. However, it has been observed that properly breaking down this new technology into its fundamental parts has been quite lacking. Most attempts in mainstream publications either conflate and misrepresent many concepts regarding the blockchain architecture or present them in a manner anecdotal to the implementation details of specific blockchain projects.

For example, one might often hear that “a blockchain consists of two core components: consensus and execution” or that “a blockchain comprises a hardware layer, data layer, consensus layer, and application layer.” Astute researchers and engineers exploring various blockchain projects and their architectures may notice these discrepancies which may often have them confused or adopt a skewed perspective, which could inadvertently complicate their future designs and analyses.

This article intends to offer a generalised view of the conventional blockchain architecture, abstracted from the implementation details of any specific blockchain project, such that it can serve as a universal framework for analysing any present-day blockchain project.

The term “Blockchain” is one that has been run through the mill so many times by so many people and publications to the point where it has become needlessly nebulous. Depending on where you read from, you might be told that a Blockchain is a “distributed database”, a “shared ledger”, or simply a “data structure”.

We will circle back to the intricate definitions and delineations of the term, exploring its use in a future article. For now, know that the term “Blockchain” is quite overloaded, and the definition suggested in this article is an effort to refine it, albeit from a subjective standpoint.

In this article, we define a blockchain as an internet technology that leverages a networking infrastructure (usually a peer-to-peer network), a set of coordination protocols, and a cluster of participating machines, to accomplish essential tasks under certain desired constraints, qualities, and guarantees, such as censorship and tamper resistance, access control, open accountability, privacy, etc.

Today, it can be estimated that there are at least a thousand operational blockchain projects, each with similar or distinct goals. Examples of these projects include Bitcoin, Ethereum, Solana, etc.

A full-fledged blockchain system is a complex assembly of technology, made up of various components functioning at different layers that work independently and collectively, much like a layered cake, to yield an operational blockchain. These components essentially exist as protocols in their own right, each functioning within its specific layer, inclusive of their respective sub-protocols and dependencies.

We describe the core architecture of the conventional blockchain system, commonly implemented in the form of a node software, in four core layers, in order of precedence: Networking, Consensus, Ledger, and Runtime.

You can think of these layers as the scopes within which core components operate, akin to how each layer of the OSI model has components that function within it.

Let’s dive in…

The first important step and requirement for constructing a blockchain system is to establish a common foundation for communication. This foundation allows all involved parties, i.e., nodes, to reliably discover and exchange messages, enabling them to collaborate effectively. The networking layer serves as this foundation and is typically instantiated in the form of a peer-to-peer (a.k.a. P2P) network, as this networking mode ensures that there are usually few-to-no central points of failure or capture in communication.

The Networking Layer is critical for the discovery of peers and the exchange of crucial data necessary for the coordination of work performed at the next layer of the blockchain architecture. A core networking protocol is implemented at this layer to ensure that appropriate data flows and resource controls are in place for a healthy communication framework of a blockchain.

Some core networking protocols used at the Networking Layer by blockchain projects include:

• LibP2P - used by Ethereum, Polkadot, etc.

• DevP2P - used by Ethereum

• Tendermint P2P - used by CosmosHub, Osmosis, Axelar, etc.

Additionally, a core networking protocol is made up of several sub-protocols needed to perform various interdependent tasks, all of which are important to verify and control the flow of data needed by all participants to do work at the subsequent layers of the blockchain architecture. Some of these include, but are not limited to, the following:

• Peer Discovery Protocol

• Inter-Node Communication Protocol

• Multiplexer

• Block Propagation Protocol

• Transport Protocol

• Chain Syncing protocol

• Authentication Protocol

• Mempool

Think of the Networking Layer as the Slack channel or group chat where all the parties involved in making the blockchain system operational find and talk to each other about everything they have to.

With an established Networking Layer enabling all interested parties to join a shared network, discover peers, and exchange messages, one might wonder, “Why?” The answer lies in the Consensus Layer, where the work necessitating a common network for communication is performed.

The Consensus Layer hosts the core coordination frameworks that guide all involved parties in identifying their roles, understanding their unique tasks, and ensuring the correct and honest execution of these tasks. A Consensus Mechanism serves as the core component implemented to specify and oversee the required work of the connected parties on the network.

A consensus mechanism is fundamentally a set of rules or protocol that employs algorithms and incentives to guarantee honest and productive participation from all parties involved in a system, aiming to achieve consensus among all or the majority of participants, i.e., nodes.

In addition to coordinating work, the consensus mechanism plays a crucial role in ensuring robustness and implementing mitigation and recovery measures against potential threats posed by malicious actors. Blockchains commonly incorporate design decisions that promote fault tolerance and adopt economic strategies, such as locking requirements and slashing penalties on the staked resources of network participants.

Not all blockchain projects prioritise the same features, leading to a diversity in the design of consensus mechanisms. Each blockchain project must weigh the trade-offs to align with their specific goals. The qualities and guarantees preferred by a given blockchain determine the kind of consensus mechanism implemented in its Consensus Layer. Some examples of consensus mechanisms include:

• Nakamoto Consensus, used by Bitcoin, Bitcoin Cash, LiteCoin

• Gasper, used by Ethereum.

• Tendermint, used by CosmosHub, Osmosis, Axelar, etc.

• Ouroboros, used by Cardano, MINA, Ergo, etc.

Similar to the core networking protocol in the Networking Layer, the core consensus mechanism—or protocol—is comprised of various sub-protocols. Each of these sub-protocols plays a vital role in maintaining the integrity and functionality of the consensus layer. Some of these sub-protocols include (but are not limited to):

• Sybil Control Protocol: This includes mechanisms such as Proof-of-Work (PoW), Proof-of-Stake (PoS), and others that help prevent or resist Sybils i.e., multiple fraudulent identities, from influencing the network.

• Data Control Protocol: This touches on the storage sub-protocol which encompasses aspects like Data Availability and enforcing the set limits on resources such as Block size and Compute Units, to ensure efficient processing.

• Leader Selection Protocol: This involves methods such as Randomisation, Round Robin, Election, and more to fairly select the candidate node responsible for leading a consensus slot, i.e., creating the next block.

• Fork Choice or View Switch Protocol: This refers to the rules used to choose between conflicting chains or views, such as the Longest-chain rule in Nakamoto Consensus or Linear View Change rule in HotStuff.

• Finality Gadget: This sub-protocols ensures that all confirmed blocks are persistent after a period of time and/or certification. Ethereum’s Casper(FFG) and Polkadot’s GRANDPA are good examples.

The rigorous standards and work accomplished at the Consensus Layer culminate in a network that, despite operating under the assumption of potential adversarial activity, manages to establish distributed trust. We refer to this concept as a Distributed Trust Network. Essentially, it represents the core value proposition of blockchains, offering decentralised and reliable security for financial systems, identity frameworks, and various digital infrastructures.

Think of the Consensus Layer as the code of conduct and chores list that everyone in the Slack channel or group chat have to follow in order to stay and contribute in the chat.

If the Consensus Layer serves as the body of the conventional blockchain, then the Ledger Layer is indeed its soul, infusing it with meaning and purpose, a raison d’être. It not only provides further context to the "Why?” question for the Consensus Layer, but also answers the “What(for)?” question.

The Ledger Layer hosts the autonomous world in which digital ecosystems and resources exist, and stands as the paramount value system of the blockchain architecture. At the heart of the Ledger Layer lies the Ledger Protocol, which is characterised as a State Machine (alternatively termed a State Transition System in some literature) and widely acknowledged as the fundamental embodiment of the blockchain's mutable "state.”

The Ledger Protocol (or simply Ledger) strictly defines the structure, constraints, and rules of the (autonomous) world it encapsulates and serves as the authoritative record-keeping system for that world. Those who are very familiar with blockchains, like Ethereum, for example, better know the Ledger as the ‘World State’ that holds all the accounts and their respective balances of every participant (human and on-chain script) to ever interact within the Ethereum. This world state is commonly implemented as a kind of data structure(usually a Merkle Tree, or a variation of one) and stored as a database file. An example of this is in Ethereum, where the world state is specified as a Merkle Patricia Trie structure. An ethereum node implementations, like Go-Ethereum (Geth), leverages LevelDB to implement the structure.

The above example follows a similar practise taken by the majority of blockchain projects in the industry; however, not all blockchains are the same when it comes to how they view and access their world state. A key distinction in this context is the transaction-recording model they employ, which fundamentally dictates the method by which their operators manage the bookkeeping. Today, the popular transaction-recording models used by blockchains are:

• Unspent Transaction Output model (a.k.a. UTXO), which is used by Bitcoin, Zcash, etc.

• Account-Balance Pair model, which is used by Ethereum, Optimism, etc.

Note: The transaction-recording model employed by a given ledger very much influences its (world) state access patterns and (dis)advantages, such as parallelism, localisation, privacy, etc.

The Ledger Protocol extends beyond its state; it encompasses various sub-protocols that stipulate and enforce policies and parameters, including (but not limited to):

• Monetary Policy: Examples include Bitcoin's 21 million bitcoin hard cap and Ethereum's EIP-1559.

• Governance Protocol: Examples include Polkadot’s OpenGov, Tezos Governance, CosmosHub Governance, and others.

• State Transition Ruleset: This involves provisions and conditions for correct state changes such as signature requirements, native scripting and state transition function, conservation of value, and much more.

• Fee Cost Models: This encompasses parameters like base fee costs for transactions.

• Consensus Participation Rules: Examples include minimum stake requirements and slashing penalties.

• Resource Limits: Parameters like Block Size and Transaction Size fall under this category.

Think of the Ledger Layer as the system that controls how long your username can be, what emojis are allowed, and logs all the things that represent your being in the Slack channel or group chat, such as your current follower/following counts.

For the initial six years following the inception of the very first conventional blockchain project, Bitcoin, most blockchain systems primarily depended on the native scripting functionality of their ledger protocols for simple computation. More complex computation needs were addressed through off-chain environments.

This persisted as the norm until the Ethereum project revolutionised blockchain architecture with the introduction of a Runtime Layer via the Ethereum Runtime Environment (ERE), which included the Ethereum Virtual Machine (EVM). The Runtime Layer marked a significant departure, providing a comprehensive runtime environment equipped with essential sub-protocols, including a virtual machine. This advancement enabled the execution of advanced computations directly within the blockchain system. Notably, Ethereum, introduced in 2015, presented a Turing-complete system, empowering the platform with the ability to handle arbitrary computations.

The Runtime Layer plays a crucial role as it defines the State Transition Function built on top of the Ledger protocol. At the heart of the Runtime Layer, the Runtime Environment serves as a core component or protocol, ensuring the availability and functionality of essential libraries, structures, and primitives, necessary for the valid execution of complex computations on the Ledger State.

Composed of sub-protocols, the Runtime Environment efficiently manages diverse fields and contexts of computation within the system. Some of these sub-protocols include(but not limited to):

• Abstract or Virtual Machine: a software implementation of a physical or abstract machine in which on-chain scripts are executed. eg. EVM, MoveVM, SVM, etc.

• Interfaces: a framework of API endpoints that are used to communicate between the runtime layer and its components, and the rest of the blockchain system. eg. RPC, Ledger-API, etc.

• Compilers and Interpreters: a module responsible for converting high-level instructions to low-level instructions, for script execution.

• Cost Modelling and Evaluation Unit: a module responsible for setting the resource budget limits, and evaluating the resource utilisation of an on-chain script, to apply appropriate costs for computation.

Over the years, we've witnessed the emergence of various blockchain projects releasing their own solutions for the Runtime Layer. Some notable examples include:

• Ethereum Runtime Environment, which incorporates the Ethereum Virtual Machine (EVM) and is utilised by projects such as Ethereum, Polygon, Optimism, etc.

• Substrate Runtime, featuring the WASM runtime and employed by projects such as Polkadot.

• Sealevel Runtime, integrating the Solana eBPF Virtual Machine (a.k.a. SVM) and utilised by projects such as Solana.

The Runtime Layer, equipped with a Runtime Environment and its associated sub-protocols, notably a Virtual Machine, provides the essential tools and prerequisites for the execution of on-chain scripts(a.k.a. smart contracts) that power up end-user applications.

Think of the Runtime Layer as the feature in the Slack channel or group chat that allows you to use special commands, shortcuts, and bots to enhance your productivity and general experience.

The conventional blockchain system is a sophisticated assembly of technology, meticulously organised into four core layers: Networking, Consensus, Ledger, and Runtime. These layers, akin to a layered cake, operate independently and collectively to bring a blockchain system to life.

Whether you're a blockchain researcher, engineer, or just an enthusiast, this generalised view of the conventional blockchain architecture aims to provide a universal framework independent of any specific blockchain project. Understanding these fundamental layers is crucial for forming the appropriate mental models to design robust blockchain systems and for the effective analysis of them.