Cellframe Node 5.3. Major Updates

All the functionality of our network is contained within the Cellframe Node code. It consists of two main modules:

DAP SDK is a low-level module responsible for the node’s interactions with memory, networks, and databases. It includes cryptography and various auxiliary data structures and algorithms.

Cellframe SDK, which outlines the mechanisms of blockchain operation: consensus algorithms, transaction validation, and block creation.

Additionally, there is a set of diagnostic tools and plugins necessary for installing the node on a user’s device and connecting it to the blockchain network.

In the new version, we have enhanced functionality and thoroughly revamped the network’s infrastructure. Let’s take a closer look at the updates in Cellframe Node 5.3.

New synchronization mechanisms

We have introduced two new mechanisms: epidemic update distribution and periodic synchronization. Together, they ensure timely receipt of up-to-date information by all nodes in the network. Now, let’s examine each of these mechanisms in more detail.

The first element is epidemic update distribution . It is triggered whenever new data appears in the network, such as blocks, mempool entries, new orders, and other events. It operates on the principle of spreading updates from one node to another: as soon as a node receives new data, it forwards it to neighboring nodes, which in turn do the same. This process continues until the updates reach all active nodes in the network. This approach ensures rapid propagation of new data while minimizing delays.

The second element, periodic synchronization, is implemented using a so-called “state machine,” which controls the transition between predefined states. In synchronization, these states include:

● Gathering information on data to be transmitted
● Transmitting the data
● Confirming receipt
● Idle state

Periodic synchronization runs on a timer every few minutes, regardless of whether there are changes in the network. Its primary task is to ensure that all nodes have up-to-date information. For example, if a node was temporarily offline and missed an epidemic update, it can retrieve the missed data during the next synchronization.

Unlike epidemic update distribution, which “pushes” updates, periodic synchronization “pulls” them. When a node reconnects to the network, it requests synchronization and retrieves any missing data from other nodes.

Cluster architecture

We have completed a major refactoring of the core network and implemented a cluster architecture transforming the Cellframe network into a system of interconnected clusters.

A cluster is an interconnected group of nodes that use GDB (“Global Data Base”, distributed data storage on the blockchain) groups to exchange data between nodes and a link manager to maintain their connections. In the cluster architecture of our network, we identify three types of clusters:

● GDB Group Clusters — groups of nodes responsible for data storage and node list management. For example, the KelVPN node cluster includes the groups KelVPN.nodes and KelVPN.nodes.aliases.
● Role Clusters — groups of nodes with special rights, such as the mainchain network validators.
● Stream Clusters — nodes grouped by certain attributes, such as belonging to the same network, with the ability for quick connection via an open streaming protocol.

Thus, one stream cluster can include many GDB group clusters, each of which, in turn, can have its own role clusters.

The cluster architecture lays the foundation for the future implementation of sharding, a technology that will significantly increase the network’s scalability and performance.

Sharding is an important mechanism that divides the network into segments, or shards. Sharding helps distribute network load more efficiently and increases its throughput capacity.

In our case, sharding is especially important since we use “heavy” post-quantum algorithms, which increase the size of transactions and affect network speed. To address this, we developed a unique two-level sharding mechanism.

● First level is heterogeneous. The first-level shards, or “networks” in our case, perform their unique functions, similar to parachains in Polkadot. Each service in our ecosystem, such as the decentralized VPN service KelVPN or the IoT platform Node.sys, has its own network. The main Cellframe network, Backbone Network, acts as a hub for all networks and hosts the decentralized exchange Cellframe DEX for trading CF-20 tokens.
● Second level is homogeneous. This will consist of shards or “cells” with identical functions (hence the name of the platform — Cellframe). This level is still under development.

Link manager

With the transition to cluster architecture in version 5.3, we have introduced the link manager functionality. Previously, connections between nodes were “anonymous,” making management difficult. Now, node addresses are verified. When establishing a connection, a node signs service data using a certificate with its private key, whose public pair is hashed into the node’s address. This ensures that the node’s address is cryptographically secure and almost impossible to forge without the private key.

A link is a collection of communication channels with a specified node address. It is defined in a special GDB group, with write access limited to network administrator nodes.

Links can be static, dynamic, or hybrid, depending on the settings. Static, or “permanent,” links have priority over dynamic ones. Their addresses are specified in the configuration file or defined externally. If the number of static links does not meet network needs, the missing dynamic links are requested from a load balancer, which selects the most suitable options at the moment.

The link manager performs several key functions:

● Link management. It prevents duplicate connections with nodes that already have an active connection. If the connection is initiated by a remote node, the local node uses the existing link.
● Cleaning up inactive links. The manager removes unused links and disconnects unnecessary connections, freeing up network resources.
● Updating information. It keeps link data up-to-date in each cluster and the network. Depending on the state of the nodes (online/offline), the manager decides whether to initiate or accept new links.

This update has improved link management efficiency and cluster operations within the network.

Fork auto-resolution mechanism

Forks, or blockchain chain splits, occur when multiple validators simultaneously propose different versions of the same block. Due to the specifics of our consensus, the likelihood of forks in our network is higher.

In the Cellframe blockchain, each block is signed by only 10 validators. This is due to the use of heavy post-quantum signatures, which are much more complex and bulky than traditional ones. To avoid slowing down the network, the number of algorithms required to confirm a block has been reduced.

To maintain network stability, we have introduced an automatic fork resolution mechanism. Previously, resolving this issue required manually stopping the network and transferring chains from the longest branch of the fork to other root and masternodes, working with validators to fix the consequences. Now, when forks occur, the network automatically selects the longest chain and continues to operate without our intervention.

What’s next?

The Cellframe Node functionality update is crucial for launching the bidirectional bridge mode. Our team is currently working on this to enable the Cellframe blockchain to fully interact with other blockchains, primarily Ethereum and BSC. We are now conducting an independent external security audit of the node’s functionality and an internal audit of the emission center, after which there will be minor adjustments to make the network even more reliable.

We appreciate your support! Stay tuned for our updates to be the first to know about the latest developments.