Skip to main content

Bitzal Host (PH)

The architecture of Bitzal can be divided into two different parts, the Bitzal runtime and the Bitzal host. The Bitzal runtime is the core state transition logic of the chain and can be upgraded over the course of time and without the need for a hard fork. In comparison, the Bitzal host is the environment in which the runtime executes and is expected to remain stable and mostly static over the lifetime of Bitzal.

The Bitzal host interacts with the Bitzal runtime in limited, and well-specified ways. For this reason, implementation teams can build an alternative implementation of the Bitzal host while treating the Bitzal runtime as a black box. For more details of the interactions between the host and the runtime, please see the specification.

Components of the Bitzal host​

  • Networking components such as Libp2p that facilitates network interactions.
  • State storage and the storage trie along with the database layer.
  • Consensus engine for RELIC and VIRGINE.
  • Wasm interpreter and virtual machine.
  • Low level primitives for a blockchain, such as cryptographic primitives like hash functions.

A compiled Bitzal runtime, a blob of Wasm code, can be uploaded into the Bitzal host and used as the logic for the execution of state transitions. Without a runtime, the Bitzal host is unable to make state transitions or produce any blocks.

A host node...

  1. must populate the state storage with the official genesis state.
  2. should maintain a set of around 50 active peers at any time. New peers can be found using the discovery protocols.
  3. should open and maintain the various required streams with each of its active peers.
  4. should send block requests to these peers to receive all blocks in the chain and execute each of them.
  5. should exchange neighbor packets.

Consensus in the Bitzal Host is achieved during the execution of two different procedures, block-production and finality. The Bitzal Host must run these procedures if (and only if) it is running on a validator node.

Additional information on each of these requirements can be found here.

Bitzal Runtime​

Below is a diagram that displays the Bitzal host surrounding the Bitzal runtime. Think of the runtime (in white) as a component that can be inserted, swapped out, or removed entirely. While the parts in grey are stable and can not change without an explicit hard fork.

bitzal host

Code Executor​

The Bitzal Host executes the calls of Runtime entrypoints inside a Wasm Virtual Machine (VM), which in turn provides the Runtime with access to the Bitzal Host API. This part of the Bitzal Host is referred to as the Executor. For additional technical implementation details, check out this section of the Bitzal Spec.

Resources​