Worklog. March results

Hello everyone!

We've prepared a traditional Cellframe news digest. Here, we cover development progress, ecosystem growth, and marketing activities. Today, we're sharing the highlights from March. As usual, we've gathered all the most interesting updates for you - so read on and enjoy!

Cellframe Wallet

In the last issue of our digest, we mentioned that we've resumed active development of the multi-functional Cellframe Wallet application. Essentially, this is a simplified version of the Cellframe Dashboard, specifically designed for mobile platforms, and it will contain all the essential features for users.

In February, we adapted all updates made in Cellframe Dashboard for Cellframe Wallet and updated the backend. In March, we worked on improving the UI.

Here's what we accomplished:

- Added virtual keyboard functionality

- Implemented the ability to expand the application to full screen

- Updated the list of available post-quantum signatures for wallets and certificates (currently Falcon and CRYSTALS-Dilithium)

- Fixed several layout and functionality bugs for wallet operations

Cellframe Dashboard

A significant focus on the Cellframe Dashboard project was directed towards backend development. As you know, Cellframe Dashboard is closely linked with another of our applications - Cellframe Node, and ensuring their compatibility is crucial.

Since there were updates in the node regarding JSON-RPC protocol responses, we also needed to adapt the handler for these responses in the dashboard. This resolved compatibility issues for network, wallet, transaction, and Web3 API operations.

Additionally, we worked on the TX Explorer tab. Here, we updated the network selection combo box and implemented the display of a new transaction type - exchange transactions.

Most importantly, in March, we prepared a pre-release build of Cellframe Dashboard which included the updated DEX tab. The new functionality was sent for beta testing, and after receiving feedback, necessary changes were implemented. In early April, the long-awaited release (version 2.14 - 12) was deployed to production. We've discussed the functionality of the new exchange in a separate post

As you know, the main component of Cellframe is the CellframeNode software, which facilitates user interaction with networks in our ecosystem.

Cellframe Node

Python Wrappers

As you know, the main component of Cellframe is the CellframeNode software, which facilitates user interaction with networks in our ecosystem.

Cellframe Node software is implemented using two SDKs - DAP SDK and Cellframe SDK. They provide network and blockchain APIs respectively and are implemented in C language.

C code provides us with high performance, which is particularly important for a blockchain with heavy post-quantum signatures, as well as maximum portability across different operating systems.

However, C language is very specific - many things are done more complexly and time-consuming compared to high-level languages. Therefore, we are not only developing our node and SDK, which are written in C but also creating auxiliary Python SDK, which simplifies and accelerates extending the logic of the base software, using a system of plug-ins in Python. This also lowers the "entry barrier" into the technology for crypto enthusiasts and application developers.

Each time we update or expand the functionality of Cellframe Node, we also reflect this in Python SDK, establishing interaction with new APIs from the plugins.

For ease of development and documentation creation, we nominally divided SDK into three levels:

- Level 0 (L0 SDK) - Cellframe SDK. Here, C language is used, and all the core functionality is written and tested.

- Level 1 (L1 SDK) - Python-cellframe, low-level API. At this level, methods are passed between Cellframe SDK and Python SDK.

- Level 2 (L2 SDK) - Python helpers, high-level API. At this level, a python-way object interface is formed, which is convenient for the user.

Our ultimate goal is to implement Python wrappers for L1 and L2 levels for all Cellframe Node functionalities. For example, the latest major updates of node functionality (L0 level, Cellframe SDK) - DEX and voting mechanisms on the Cellframe platform. They are also implemented at the L1, while L2 is currently in development.

Two-way mode of the Cellframe bridge

In the last worklog issue, we discussed actively preparing for the release of a new version of our node, which will include significant enhancements crucial for launching the two-way mode of the Cellframe bridge. In March, we continued this work and implemented several important features.

Completed the implementation of IPv6 in Cellframe Node

Why it's important: IPv6 is the 6th version of the IP protocol, critical for the Internet, which unifies network segments and facilitates data packet transmission between network nodes.

The previous version of the protocol - IPv4 - has nearly exhausted its network address limit. IPv6 protocol expands the address space and offers improved performance and security, prompting many internet service providers to fully transition to it and cease support for IPv4.

Implemented a load distribution system between network nodes, consisting of two key components:

Link Manager oversees all links (communication channels) between nodes in the network, based on the needs of each network cluster it administers. The main tasks of the link manager include avoiding duplicate connections to network nodes and regularly updating information about the network's link composition and clusters.

Links are categorized into three types: static, dynamic, and mixed. Static or permanent links take precedence over dynamic ones - they are pre-defined in settings or set by other external means. If there are insufficient static links for stable connectivity, the missing (dynamic) links are requested from the network balancer.

Network Balancer is used for evenly distributing connections between nodes. It has access to address statistics updated by all nodes in the network. The balancer's goal is to create a uniform "web" where each node is connected to approximately the same number of nodes.

Additionally, as part of network synchronization improvement efforts, we implemented a mechanism that adapts the data transmission speed between nodes to the capabilities of the receiving side. Traffic is now sent in batches, and depending on the receiving side's processing speed, the transmission rate for subsequent batches is adjusted - ranging from halting further transmission to developing the maximum possible data transfer speed between nodes.

This scheme allows the transmitting node to save resources and pause transmission, including refraining from sending data that can no longer be accepted, while the receiving node can free up memory. As memory is limited, it's crucial to address this now to avoid potential issues as the blockchain network grows.

Finally, in March, we implemented another mode of operation for the Cellframe bridge. Now, it facilitates direct token transfer between Ethereum and BSC networks for CELL and KEL tokens. For users, this means they can easily move their assets between these networks (we've detailed this in a separate post)

For us, this is a significant step towards the two-way mode of the bridge. This allows us to fine-tune the operation of distributed consensus based on smart contracts, which will also be utilized in the bridge mode from CF-20.