Worklog. July results
Welcome back to the Worklog, where we bring you a digest of all the news from the Cellframe team. We’ll discuss the latest development progress and important updates. Enjoy reading!
Web development
In July, we continued developing the Cellframe voting site. Users will use this convenient site to vote on and influence various parameters of the ecosystem. All holders of native CF-20 tokens will be able to vote, but the weight of one vote will be proportional to the number of tokens on the owner’s balance at the time of participation. We have already tested the functionality of the site on the Raiden network and added a window that displays all votes available to choose from. During the testing process, attention was also paid to the UX of the site. For example, we prepared a text box that explains the voting process, which will dynamically change depending on the type of vote.
In addition, we are continuing to redesign the Cellframe Explorer website. This site displays all transactions on the Cellframe network. For greater ease of use, we added a graph of transaction statistics on the main page.
Among the minor improvements, a button has appeared on the Cellframe staking website for quick access to the beginning of the list of stakes. Now users who have many different stakes will not have to scroll up manually.
Cellframe Dashboard
In July, we changed the installation and update process for Cellframe Dashboard and Cellframe Node. Previously, these two products were strongly dependent on each other. So, for example, in order to update and release the Cellframe Dashboard, it was necessary to run node assembly tests, update Node as part of the application, then run the tests again. Only then could we release the Dashboard. Now we have separated these processes, and there is no longer a rigid connection between applications. Thus, all Node updates can now be available to users earlier, regardless of Dashboard updates. We have also developed a mechanism in which the new version of the Dashboard itself identifies the required version of Node and offers a button for easy download.
We added a component to Cellframe Dashboard for displaying the initialization status of a node. In addition, we created an algorithm for processing status progress received through the “notify” message. This will ensure more accurate and timely updating of information about the node’s loading status for users.
And finally we finished developing a tab for launching a masternode through the dashboard, and are now debugging it. Currently, installing a masternode requires command line skills — not all of our users have such experience. We have developed a new feature that will make the launch process easier and more convenient. What has been done recently:
● We worked out the masternode launch algorithm
● Made a stepper to switch between masternode startup stages
● Added a panel with transaction history for the masternode wallet
● Implemented a new model for displaying and filtering orders
Cellframe Node
We always strive to make user interactions with the Node service more understandable and accessible. We recently launched a tray application that simplifies node management.
We also continue to work on a new version of the Cellframe Node 5.3. We are now finalizing the functionality alongside preparations for launching the two-way bridge mode.
In July, in the release candidate, we established a process for working with chain files. Previously, when using a map pointer — a special data type that stores key-value pairs — errors occurred. Now there will be significantly fewer failures and less data loss.
We have also improved the mechanism for automatically resolving forks. This mechanism is necessary for the stable operation of the blockchain. We fixed an issue that caused the node to crash when deleting a transaction while forks were being resolved.
We managed to speed up the operation of the node thanks to priority processing of CLI commands in proc threads. As a result, the node began to respond faster to these commands, even under high load. Synchronization with other nodes has also improved.
We also accelerated processing of hash tables, which increased the loading speed of the node by at least 10 times and had a positive impact on all aspects of its work.
Significant changes also affected the http client. Now the system responds to requests faster, and work with the node occurs within one connection, without the need for constant reconnection. This simplifies interaction with the node and improves overall performance.
Python plugins
Cellframe Node and SDK are written in pure C, which provides high performance and portability. However, due to the specific characteristics of this language, some actions in it take longer and are more complex. That’s why we’re building a companion Python SDK that will make our technology more accessible to developers. Our goal is to create wrappers and plugins in Python for all the functionality of Cellframe Node.
Version 5.3 of the Node is significantly different from the current one, so we had to rework the Python plugins for it. In fact, we needed to rework all infrastructure plugins. The emission center and bridge have already been prepared, and now we are working on the refactoring plugin and staking.
In the course of July, we rethought the mathematical model for staking management. From the user’s point of view, everything will remain the same, but there have been significant changes in development. We improved the internal structure of the code without changing its visible part, which increased the speed of work. We also finalized the reward system and prepared it for testing.
This month the team also improved the functionality of the node configurator — a special tool for configuring node parameters on various OSes — and introduced a launch system for Linux and Windows.
We continue to work to improve all aspects of the Cellframe Network. Thank you for staying with us!
