Skip to main content

Flow of a Single Blockchain

Blockchain Flow

Intro​

The Metal Blockchain network consists of 3 built-in blockchains: X-Chain, C-Chain, and P-Chain. The X-Chain is used to manage assets and uses the Avalanche consensus protocol. The C-Chain is used to create and interact with smart contracts and uses the Snowman consensus protocol. The P-Chain is used to coordinate validators and stake and also uses the Snowman consensus protocol. A set of validators makes up a Subnet. Subnets can validate 1 or more chains. It is a common misconception that 1 Subnet = 1 chain and this is shown by the primary Subnet of Metal which is made up of the X-Chain, C-Chain, and P-Chain.

A node in the Metal network can either be a validator or a non-validator. A validator stakes METAL tokens and participates in consensus to earn rewards. A non-validator does not participate in consensus or have any METAL staked but can be used as an API server. Both validators and non-validators need to have their own copy of the chain and need to know the current state of the network.

Each blockchain on Metal has several components: the virtual machine, database, consensus engine, sender, and handler. These components help the chain run smoothly. Blockchains also interact with the P2P layer and the chain router to send and receive messages.

Peer-to-Peer (P2P)​

Outbound Messages​

The OutboundMsgBuilder interface specifies methods that build messages of type OutboundMessage. Nodes communicate to other nodes by sending OutboundMessage messages.

All messaging functions in OutboundMsgBuilder can be categorized as follows:

  • Handshake
    • Nodes need to be on a certain version before they can be accepted into the network.
  • State Sync
    • A new node can ask other nodes for the current state of the network. It only syncs the required state for a specific block.
  • Bootstrapping
    • Nodes can ask other nodes for blocks to build their own copy of the chain. A node can fetch all blocks from the locally last accepted block to the current last accepted block in the network.
  • Consensus
    • Once a node is up to tip they can participate in consensus! During consensus, a node conducts a poll to several different small random samples of the validator set. They can communicate decisions on whether or not they have accepted/rejected a block.
  • App
    • VMs communicate application-specific messages to other nodes through app messages. A common example is mempool gossiping.

Currently, MetalGo implements its own message serialization to communicate. In the future, MetalGo will use protocol buffers to communicate.

Network​

The networking interface is shared across all chains. It implements functions from the ExternalSender interface. The two functions it implements are Send and Gossip. Send sends a message of type OutboundMessage to a specific set of nodes (specified by an array of NodeIDs). Gossip sends a message of type OutboundMessage to a random group of nodes in a Subnet (can be a validator or a non-validator). Gossiping is used to push transactions across the network. The networking protocol uses TLS to pass messages between peers.

Along with sending and gossiping, the networking library is also responsible for making connections and maintaining connections. Any node, either a validator or non-validator, will attempt to connect to the primary network.

Router​

The ChainRouter routes all incoming messages to its respective blockchain using ChainID. It does this by pushing all the messages onto the respective Chain handler’s queue. The ChainRouter references all existing chains on the network such as the X-chain, C-chain, P-chain and possibly any other chain. The ChainRouter handles timeouts as well. When sending messages on the P2P layer, timeouts are registered on the sender and cleared on the ChainRouter side when a response is received. If no response is received, then it triggers a timeout. Because timeouts are handled on the ChainRouter side, the handler is reliable. Timeouts are triggered when peers do not respond and the ChainRouter will still notify the handler of failure cases. The timeout manager within ChainRouter is also adaptive. If the network is experiencing long latencies, timeouts will then be adjusted as well.

Handler​

The main function of the Handler is to pass messages from the network to the consensus engine. It receives these messages from the ChainRouter. It passes messages by pushing them onto a sync or Async queue (depends on message type). Messages are then popped from the queue, parsed, and routed to the correct function in consensus engine. This can be one of the following.

  • State sync message (sync queue)
  • Bootstrapping message (sync queue)
  • Consensus message (sync queue)
  • App message (Async queue)

Sender​

The main role of the sender is to build and send outbound messages. It is actually a very thin wrapper around the normal networking code. The main difference here is that sender registers timeouts and tells the router to expect a response message. The timer starts on the sender side. If there is no response, sender will send a failed response to the router. If a node is repeatedly unresponsive, that node will get benched and the sender will immediately start marking those messages as failed. If a sufficient amount of network deems the node benched, it might not get rewards (as a validator).

Consensus Engine​

Consensus is defined as getting a group of distributed systems to agree on an outcome. In the case of the Metal network, consensus is achieved when validators are in agreement with the state of the blockchain. The novel consensus algorithm is documented here. There are two main consensus algorithms: Avalanche and Snowman. The engine is responsible for adding proposing a new block to consensus, repeatedly polling the network for decisions (accept/reject), and communicating that decision to the Sender.

Blockchain Creation​

The Manager is what kick-starts everything in regards to blockchain creation, starting with the P-Chain. Once the P-Chain finishes bootstrapping, it will kickstart C-Chain and X-Chain and any other chains. The Manager’s job is not done yet, if a create-chain transaction is seen by a validator, a whole new process to create a chain will be started by the Manager. This can happen dynamically, long after the 3 chains in the Primary Network have been created and bootstrapped.