Worklog. November results

Welcome to the Cellframe and Demlabs news digest! Here we talk about all the latest development progress, ecosystem news and marketing activities.

CELL staking program

At the end of November we changed the calculation for distribution of rewards. Now the total rewards are divided equally between stakers and network validators. At this stage, there are few transactions on our network, which means the income level of validators is relatively small. It is important for us to increase the number of masternodes, because this makes the network more stable, decentralized, secure and attractive for developers. At the same time, we did not want to make additional emissions and increase the number of tokens beyond the limits specified in Tokenomics 2.0 without agreement with the community. So we made this decision. In the near future we will hold a community vote to determine the size and source of rewards for validators, and also address other questions.

To maintain their previous income levels, we recommend that CELL stakers run Cellframe masternodes. If this option does not suit you, you can delegate your keys to other validator nodes. Such cooperation will be beneficial to both parties: masternodes will be able to increase their weight in the network, and therefore their level of income, and you will receive a certain share of income from validating transactions without having to run a masternode on your own.

To make the process of delegation of rights more transparent and user-friendly, we are preparing to launch a new functionality. It will run on the same limit-order engine that powers the Cellframe platform's service-delivery mechanism. When the new feature is released, the order functionality will be used for key delegation. The user will create an order in which it will be possible to specify all the necessary conditions, such as the number of delegated mCELLs and the share of income from the total amount of awards. This functionality is currently under development. We will give more detail about the launch and how it will work at a later date.

Web development

Refactoring of the Explorer site continues. This site displays all the events occurring on our blockchain network. We are completely redesigning the backend to take into account future changes in the platform architecture. Work is currently underway to implement a special plugin for filling the database with information from the blockchain. It will perform a caching function and allow you to quickly load all the necessary data.

In addition to this, we also continue to work on improving the UI of all our sites. In November we worked on fixing minor visual bugs on the staking, migration and in Cellframe Wiki sites. For example:

• Fixed layout problems in the Android version of the migration site.

• Fixed the Cellframe Wiki site header offset for mobile platforms.

• Solved the problem with displaying long wallet names on the staking site. 
• On the Explorer website, we adjusted the display of transactions and corrected the behavior of the drop-down network list.

Cellframe Dashboard Updates

In Dashboard, we optimized the logging system. We removed redundant logs that took up a large amount of memory, and added automatic clearing of logs when they reach 1 GB.

We have also implemented a transaction queue - now you can send several linked transactions at once. What this means: Previously, when attempting to send a second transaction immediately after the first, the second would be rejected because it referred to the same output that had already been spent by the previous transaction. Now the user will not need to re-send the second and subsequent transactions if they were made before the first one was processed. In the interface, we have added transaction statuses to the Last Actions field.

We have now prepared this new feature on the Cellframe Dashboard side - we plan to include it in the release at the end of December. Later we will also include this feature on the Cellframe Node side.

We also updated the output of the GetWallets command: we added a field with the wallet status (active/blocked).

KelVPN project news

The KelVPN team has added a gas auto-substitution function for Metamask on the KelVPN staking site. Inside the application, they fixed an incorrect display of interface elements in the version for macOS, plus several other bugs. But the team's main efforts remain focused on the KelVN and Cellframe Dashboard/Wallet collaboration mode.

What was done in November:

The logic for working with orders for VPN nodes has been optimized. Problems with node crashes and check-signing in the VPN-service mode have been fixed.

The team changed the method of storing data on partially executed orders.

Information about the size of the remaining prepaid service (by time and traffic) is now stored not on the server, but in a special GDB group, that is, on virtually all the nodes at once. To gain access to data for a specific user and provider, you can use the net_srv command.

Work with paid services has been optimized for when the node is offline.

If the provider node disconnects from the network and goes offline while the service is being provided, the VPN order for connected users will not be continued. This will avoid payment errors for the KelVPN service.

Cellframe Node and SDK updates

In November, we worked on expanding the functionality of Cellframe Node and Cellframe SDK. Several important improvements were made:

We implemented a new conditional transaction type to provide rewards to network validators.

Each validator will now be able to create a transaction to collect rewards for each block signed by them using the command: block reward collect [-hashes -cert -fee]. You can view the current size of the base reward using the block reward show command.

Thus, the basic reward will be received by the validator based on its signature of one block, which is generated exactly one minute after the previous one.

A conditional transaction for collecting rewards can be created no more than once a day. The reward will be awarded immediately for all blocks specified in the transaction. The restriction is necessary to reduce the flow of created transactions, as well as to avoid looping.

We are also currently preparing a feature for automatically collecting rewards for blocks. In this option, you will not need to manually specify the hash of each block signed by the validator. To ensure that the reward is not offset by the network fee for collecting the reward, the minimum amount will be at least 10 blocks.

With automatic collection, the restriction on creating conditional transactions - once a day - does not apply. The total amount that will be collected in the next autocollect transaction can be found using the ‘block autocollect status’ command. This feature is almost ready for launch; it is now undergoing the final stage of testing.

As for the choice between “manual” and automatic collection of rewards for blocks, automatic collection will almost always be the best solution. Manual collection can be used to collect rewards/commissions from those blocks for which automatic collection has not yet been configured, or if problems/gaps arise with automatic collection.

We also fixed the issue with looping releases of new blocks based on the same mempool datums.

This looping led to a sharp increase in the number of blocks, and hence an increase in the load on the network. At the growth stage, such a load can have negative consequences, so we carefully ensure that our network grows gradually and that we respond to its needs in a timely manner.

The multisignature algorithm has been improved.

Multisignature is a mechanism that is used to sign transactions not with one, but with several signatures at once. Why this is necessary: ​​if one of the signatures is hacked, then the remaining signatures included in the chain will still guarantee encryption protection. The user can choose the composition, order and number of signatures that make up a multisignature independently. But it is important to understand that the multisignature is a real “heavyweight” (especially in our case when we are talking about post-quantum signatures, each of which is quite large in itself). Therefore, it is better to use such algorithms for cold wallets so that transactions with them are rare.

Bidirectional bridge

In preparation for the launch of the bidirectional bridge, we are working to expand the functionality and improve the stability of Cellframe Node.

What was done in November:

• Removed the possibility of double-spending within one base transaction. A base transaction is a transaction where new tokens are issued on the network, and a double spend is a situation in which this set of tokens can be used twice. This vulnerability poses a serious threat to the network, so it was very important for us to solve this problem.

• Implemented node address authentication at the stream level. This will allow you to use an open stream in both directions. What this means: if one node has established a connection with another and remembers it, the second node will be able to contact the first within the same stream. Why this is important: Opening a new stream is a resource-intensive process. This option will allow us to optimize the use of resources.
• We optimized the operation of the JSON-RPC protocol for data exchange between the Cellframe Dashboard and Cellframe Node services.

Marketing News

In November, the Demlabs team took part in a forum on global trends and emerging technologies - The Trends 2023 in Moscow.

The trip turned out to be eventful and educational. We not only acquired useful contacts, but also gained a more complete understanding of what is currently happening in the Russian segment of the blockchain technology market. We learned where everything is moving, and what demands and trends will be relevant in the next couple of years.

In addition, we also regularly published content on our social media accounts and held two AMA sessions.

• Traditional stream with answers to community questions on our YouTube channel

• Partner AMA session with the CryptoTitans channel on X Spaces.

Recently, partner AMA sessions have become regular for us. This is important because events like this help expand our audience. By talking about the capabilities of Cellframe in various crypto communities, we attract new users to our platform. We see that this tactic works - the numbers on our own social media accounts always go up after partner streams. Therefore, we will continue to actively introduce the crypto world to our ecosystem.