Since Cellframe is a high-tech decentralized project with nonlinear hierarchical structure, it is hard to describe its architecture in the usual way. We can start with the fact that the Cellframe blockchain platform consists of different networks, and every network serves different purposes.
Here is a list of networks available now:
Backbone, KelVPN, minkowski, mileena, raiden, riemann,and subzero
- The only way to establish interaction between networks is through bridging
Important
For better understanding you can refer to Terms and Definitions page
Network structure
Every network includes its own zerochain and mainchain:
Zerochain is a base chain where tokens are declared and emissions are issued. Also zerochain serves for storage of decrees - controlling datums of the network. As a structure, it represents a linear DAG where every atom is an event.
Mainchain is the second chain, organized as a list of blocks (the Blockchain itself). It stores transactions and anchors (special marks which specify points of decree application if they affect the mainchain). Anchors also provide synchronization between zerochain and mainchain.
Mainchain and zerochain are connected through basic transactions, which serve as token emission providers.
Network data
All Cellframe networks store data about their current status, changes, and history. This data is distributed among several storage systems.
Global Database (GDB) is an aggregate of key-value access databases and a subsystem of the Cellframe network. GDB collects information from all installed and functioning nodes and stores it in tables.
One of the most important parts of GDB is the mempool. It stores datums that require a consensus check. After checking, a datum can be accepted as a block in the mainchain or as an event in the zerochain.
The second key component of data storage is the distributed ledger of transactions. The ledger stores the entire blockchain state (if a full node is installed) and also maintains a history of all transactions and balances. Each node receives data from other nodes and maintains a complete copy of the ledger.
Network maintenance
All networks function through nodes.
A node is a discrete device whose owner decided to become a part of the network. Here is a list of available roles for the nodes: root, full, master, and archive.
- Full Node - stores the entire blockchain
- Archive Node - keeps all hardforks in the network
- Master Node - similar to a Full Node but with validator permission
- Root Node - consists of all blockchains and all subchains
Each node can maintain several networks simultaneously.
Network clusterization
Clusterization is the next stage in the evolution of our blockchain, and also preparation for 2-level sharding (between database and chains).
Definition
A cluster is a set of nodes, connected with each other based on their similar properties, and work together as one.
Cluster architecture is a concept which allows us to represent a network as an open cluster. Such a cluster is able to accept new members by request from nodes. This concept allows for the use of a common synchronization algorithm for both opened and closed clusters using the standard network protocol (TCP).
This clustered architecture lays the foundation for the future implementation of sharding, a technology that will significantly enhance the network’s scalability and performance. Sharding is a crucial mechanism that divides the network into segments or shards.
Sharding helps distribute network load more efficiently and increases its throughput. In our case, sharding is particularly important because we utilize “heavy” post-quantum algorithms, which increase transaction weight and impact network speed.
Cellframe clusters
Clusters can have different types; depending on the cluster’s type, both its link management and its ability to automatically add members to the cluster will vary.
In the Cellframe network we have three types of clusters:
- GDB Group Clusters are collections of nodes responsible for data storage and node list management. For instance, the KelVPN node cluster includes groups like KelVPN.nodes and KelVPN.nodes.aliases.
- Role Clusters are groups of nodes with specific privileges, such as mainchain network validator, root, etc.
- Link Clusters are nodes grouped based on link management.
Currently, we use the SYSTEM, AUTONOMIC, and EMBEDDED types of Link Cluster. The ISOLATED type is also defined, but full support for this type has not been added yet.
-
SYSTEM clusters are basic clusters with “local.” and “global.” groups, which either contain a single local node or all authorized nodes that have connected to the current one. Node authorization is based on its address. Unauthorized nodes cannot participate in clusters.
-
EMBEDDED clusters are network clusters. Links in these clusters are created through a load balancer, which is called back by the link manager. Anyone can join a network by announcing themselves using a special protocol. They will simultaneously be added to the cluster of that network. There is also the possibility of denunciation, which allows sharing a single link among multiple networks, as well as with static clusters represented by the type.
-
AUTONOMIC clusters are specifically designed for emission center tasks and are also known as static clusters. This cluster type establishes links to all members assigned roles within the cluster. No other members have access to the cluster.
Role Cluster types are presented in the next enums:
ROLE_NOBODY- nobody, member with this node address can’t have access to cluster in any wayROLE_GUEST- guest, member with this node address has access to cluster only in read modeROLE_USER- user, can write to GDB groups of cluster and read from themROLE_ROOT- super user, has additional right to rewrite/delete records in GDB groups of clusters.
The role is written by default for clusters with EMBEDDED type upon auto adding new members. All new members automatically get exactly this role. For static clusters (AUTONOMIC type) this parameter is not necessary, but you can set ROLE_NOBODY which will be correct.
The owner_root_access parameter allows the user, who created the record in GDB, to independently change/remove it. Other users, except super users, can’t do that.
There is also a parameter called TTL (time to live) - the lifetime of records in cluster groups. This parameter is set in hours for convenience, but the internal value is calculated in seconds.
Network services
The Cellframe blockchain platform allows for t-dApps services to be built on the top of it. All currently available services are described on the Cellframe Ecosystem page.
To establish or maintain such a service (become a provider), the node operator has to become Master Node.
Note
This is just a brief architecture overview. For those who want to have a deeper understanding of our blockchain there will be technical documentation available.