Welcome to our deep dive series on the Metal Blockchain!
In this series, we will be taking an in-depth look at the various components and features of the Metal Blockchain. We will explain the Layer 0 concept, explore the history of consensus mechanisms and why the Metal Blockchain employs Avalanche protocols as the latest advancement in consensus technology.
We’ll also take an indepth look at the flow of a single blockchain on the Metal Blockchain, the underlying components, such as the Virtual Machine, Subnets, and the $METAL token, including its tokenomics, fee burns, fee schedule, and staking rewards.
Subnets: designed for scalability
Decentralized independent governance model
This series aims to provide a comprehensive understanding of the Metal Blockchain for both experienced and new users. Join us as we delve into the technical details and discover the unique advantages of the Metal Blockchain.
In the second article of our deep dive series, we will delve into the flow of a single blockchain on the Metal Blockchain and its components.
The components of a blockchain on Metal, including the virtual machine, database, consensus engine, sender, and handler, work together to ensure smooth operation. In addition, the P2P layer and chain router facilitate communication between blockchains by allowing them to send and receive messages.
Peer-to-Peer (P2P) layer
The peer-to-peer network is the communication layer that connects the nodes on the Metal Blockchain platform, allowing them to exchange messages and data.
These messaging functions can be grouped into the following categories:
Handshake: Nodes need to have a compatible version before they can join the network.
State Sync: A new node can request the current state of the network from other nodes, only syncing the necessary information for a specific block.
Bootstrapping: Nodes can request blocks from other nodes to construct their own copy of the chain, fetching all blocks from their locally last accepted block to the current last accepted block on the network.
Consensus: Once a node is up-to-date, it can participate in consensus by conducting polls with small, random samples of the validator set, and communicating decisions on whether to accept or reject a block.
App: VMs use application-specific messages to communicate with other nodes through app messages, a common example is mempool gossiping.
Chain Router
The ChainRouter directs incoming messages to the appropriate blockchain by utilizing the ChainID. It does this by delivering messages to the appropriate Chain Handler's queue. The ChainRouter keeps track of all existing chains on the network.
The ChainRouter also manages timeouts. When sending messages on the P2P layer, timeouts are registered on the sender side and cleared on the ChainRouter side when a response is received. If a response is not received, the timeout is triggered. The ChainRouter's handling of timeouts ensures that the handler is reliable. Timeouts are activated when peers do not respond and the ChainRouter will notify the Handler of failure cases. The timeout manager within the ChainRouter is adaptive, adjusting timeouts as necessary when network latencies are high.
Sender
The Sender is responsible for constructing and transmitting outbound messages. It functions as a streamlined version of standard networking code, with added functionality for registering timeouts and informing the router of expected response messages. If a response is not received within the set timeout, the Sender will notify the router of a failure and mark the message as failed. If a node consistently fails to respond, it may be "benched" and lose its rewards as a validator if deemed unresponsive by a significant portion of the network.
Handler
The Handler's primary task is to transfer messages received from the Chain Router to the consensus engine. It accomplishes this by adding the messages to a sync or async queue, depending on their type. The messages are then extracted from the queue, interpreted, and directed to the appropriate function within the consensus engine.
The Virtual Machine
A Virtual Machine (VM) is a blueprint for a blockchain. Just as objects are instantiated from a class definition, blockchains are instantiated from a VM. This allows VMs to define the transactions that are executed on the blockchain and how blocks are created.
VMs can be customized to define a wide range of parameters and features for a blockchain. This flexibility enables the creation of blockchains with different features and capabilities, making it possible to support a wide range of applications and use cases on the Metal Blockchain.
Overall, VMs are an important part of the Metal Blockchain platform, as they provide the foundation for creating and deploying custom blockchains on the network.
Blocks and state
Virtual Machines are used to manage blocks and state in a blockchain. They provide the necessary functionality to define the representation of a blockchain's state, represent the operations that can be performed on that state, and apply those operations to transition from one state to another.
Each block in the blockchain contains a set of state transitions, and these blocks are applied in order from the initial genesis block to the most recent block to arrive at the current state of the blockchain.
A blockchain system typically consists of two major components: the Consensus Engine and the Virtual Machine (VM). The VM defines the application-specific behavior of the blockchain and determines how blocks are constructed and parsed to create the blockchain.
Interaction with the Consensus Engine
VMs typically run on top of a Consensus Engine, such as Snowman, which enables nodes in the network to reach agreement on the state of the blockchain. The Consensus Engine provides the underlying mechanism for achieving consensus among the nodes in the network, while the VM defines the rules and operations that govern the behavior of the blockchain. Together, these two components form the backbone of a blockchain system.
Here's an example of how VMs and the consensus engine work together in a blockchain system:
A node wants to update the state of the blockchain.
The node's VM sends a request to the consensus engine to update the state.
The consensus engine requests the block containing the desired state update from the VM.
The consensus engine verifies the returned block using the VM's implementation of the “Verify” function.
The consensus engine then asks the network to reach consensus on whether to accept or reject the verified block.
All virtuous nodes on the network will have the same preference for a particular block.
Depending on the consensus results, the engine will either accept or reject the block.
The specific behavior of the VM when a block is accepted or rejected depends on its implementation. The consensus engine will then communicate that decision to the Sender.
In the Metal Blockchain network, the consensus engine is used for every blockchain. The consensus engine relies on the VM interface to handle the creation, parsing, and storage of blocks, as well as the verification and execution of state transitions on behalf of the consensus engine. This separation of concerns between the application layer and the consensus layer allows developers to quickly build their applications by implementing VMs, without having to worry about the consensus layer, which is managed by the Metal Blockchain.
In the following article we’ll take a closer look at the subnet architecture and the different internal chains on the Metal Blockchain.
