The architecture of Cere Blockchain can be divided into two different parts, the Cere runtime and the Cere host. The Cere 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 Cere host is the environment in which the runtime executes and is expected to remain stable and mostly static over the lifetime of Cere.
The Cere host interacts with the Cere runtime in limited, and well-specified ways. For this reason, implementation teams can build an alternative implementation of the Cere host while treating the Cere runtime as a black box. For more details of the interactions between the host and the runtime, please see the substrate specification.
Libp2p
that facilitates network interactions.A compiled Cere runtime, a blob of Wasm code, can be uploaded into the host and used as the logic for the execution of state transitions. Without a runtime, the host is unable to make state transitions or produce any blocks.
A host node...
Consensus in the host is achieved during the execution of two different procedures, block-production and finality. The host must run these procedures if (and only if) it is running on a validator node.
Think of the runtime 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.
The Cere Host executes the calls of Runtime entry points inside a Wasm Virtual Machine (VM), which in turn provides the Runtime with access to the Cere Host API. This part of the Cere Host is referred to as the Executor.
Can account's balance be altered without an associated on-chain transaction?
At what chain depth is deemed "secure"?
Is it necessary for users to engage with any smart contracts?
Does Cere implement state rent?
How to query the block height of the Cere Mainnet RPC node?