Dmitry Gerasimov, CEO of Cellframe, talks about development progress, mainnet, GameFi and t-dApps.
- Added complete closure of the app by pressing “closing icon”.
- Added settings for android build.
- Improved quality of icons.
Added automatic scrolling to the bottom of the output when response is received from the node.
2. Transaction history
- The transaction explorer is integrated into the dashboard and expected to operate properly now.
Although the transaction explorer website is always available, “Personally I suggest checking the transactions through the dashboard. Because the explorer is afterall a website, and thus a part of centralization. So, it is better to open your blockchain locally”, — said Dmitriy.
- Added ‘filtering by network’ for transactions: It is now possible to filter, view and navigate transactions performed within the subzero network.
3. Network Panel
For easier navigation, our team reworked the “scrolling” function for the list of networks.
- Fixed launching the dashboard service in the console.
- Improved performance by adding a limited buffer (8000 characters per message) to output data from the node.
- Fixed autocomplete bugs. Console input now reacts properly to up/down arrows and does not overlay the autocomplete text on the text of the entered command
We fixed a bug that causes a crash during the plugin activation on a Mac.
The team added filtering by certificate name when uploading certificates to the dashboard, and now certificates with names in Cyrillic will not be loaded.
“It is about dedicated ‘certificates of authority’ which have been built in the Cellframe node. And there is a certificate management tab in the Cellframe Dashboard as well. It combines local safe certificates and those which are loaded from a blockchain”, — explained the CEO.
4. Network Panel
We added a limitation on displayed character-length in network names.
5. VPN service
Fixed an error in showing the order creation window.
Fixed a bug that caused incorrect removal of unverified plugins in the ‘Unverified’ filter.
A lot of security changes, refactoring, and optimization have been done. The long attempt logic is finalized. An in-detail article about it will be published soon. And you can surf the site about a TON, quick and long attempts as well. The long attempt includes a coordinator. It is important to have this, because at the beginning the network must be protected from 51% attacks.
In addition, the dev team has added a synchronization at the start of the round and reworked rounds a little.
The security audit of the main network
The team has been spending a lot of time looking for auditors. It is taking longer than expected because of the current war-situation. However, we are at the stage of completing the negotiations with one of the auditors. Only the security audit delays our mainnet. Also, the minor bugs are being fixed.
“We are on the finish line to the mainnet. On the other hand, a little more time to polish the code will benefit the project”, — explained the CEO.
Therefore, the launch of the mainnet is rescheduled for 31st March. This delay is bureaucratic in nature, rather than because of any deficiencies in coding or development.
The part of the KelVPN team, the Minkowski network is debugging the paid mode of KelVPN. Approximately one or two weeks before the mainnet launch it will be possible to test the VPN service on your node and check how it works with sharing your internet bandwidth. Also, the transaction hash has been improved as well.
Validator node address information has been added to stack transactions. Refactoring of the node’s code for synchronous writing has been implemented. Аlso, it is enabled in every database driver as well as SQL engine under our GDB. And soon some more performance drivers will be implemented. All of these will give us the ability to produce new products.
The team is going for some enterprise-level usage of the Global database. Because it is fast and has one ranked dedicated database. It will be a stand-alone service product that is not related to a blockchain, such as Global data and something more. Priorities in colab clear in the process threads are also created.
Also, the compatibility with one version of orders is implemented. There are two versions of limit service of orders. You should switch on the new one just by downloading the latest Cellframe node. The developers have done a function for converting orders from old to new ones. It emerges in the master branch.
Python SDK on the Cellframe is modified. During the workshops, the team has faced some issues with Python which are all fixed. By now it is possible to create a custom service, operate with its orders and receipts, have notification of all the creations and other APIs which are still being extended. Next week a summary video based on the previous workshops on how to create the service from the beginning is going to be released.
There are some examples of service servers and service clients in a Git repository. You can look through it on our GitLab or GitHub. Those services could be combined in one machine to exchange custom packages in addition. And your service architecture has been developed. By the way, it is now mostly documented. If you are interested in developing, you can watch the previous workshops and join our development group to ask any questions.
Also, the developers have fixed a few bugs related to input and output subsystem, token emission etc.
After the mainnet launch, the team is going to fund a lot of third-party teams that will develop t-dApps. But some of them will be developed by the Cellframe team as well.
One of the projects in the Cell ecosystem will be the game “Chipmunk’s Spaceshards”. The team implements the Proof of game decentralized consensus model. There will be the Proof-of-authority elements for initial distribution and the Proof-of-Stake consensus for voting. The project master node launches a unique interface through the unique token, which could be created with a certificate. For each winning consensus recognized by the participants, the master note transfers CSS tokens (Chipmunk’s SpaceShards for example) to the winner’s wallet in an amount logarithmically depending on the error-free passing (X of X collected crystals and 0 of X = 100 CSS — difficult to achieve and the biggest profit). It is a kind of a dedicated emission. The developers will demonstrate a custom the Proof of game combined with a smart contract which is WASM smart contract base. The developers will begin from a simple token like ERC-20. And this game will be an example of combined functionality of t-dApp infrastructure and smart contracts. The game management will be controlled by t-dApps mechanics and the emission will be based on smart contract mechanics.
Tell us more about Cellverse. How metaverse/NFT projects would benefit if they launch on Cellframe.
The Cellverse will be a kind of Metaverse, a combination of VR and AR worlds. The most commonly used device for metaverse platforms is a smartphone. So, we want to develop something which could be used by anybody. So, VR and AR worlds can be merged together and represent some shards in a blockchain. Those worlds will be related with some shards connected together. The Master node will serve this game, and it will have a lot of API, ready-made GameFi mechanics.
Blockchain-based games are usually simpler and smaller than modern game industry masterpieces. That’s because developers have to focus on blockchain mechanics and implement them into the game, which is often complicated and a long time-taking process. Any Metaverse NFT project could save a lot of that time and use ready-made instruments that save efforts and help to focus only on a game itself.
The developer need only:
- to compose a consensus,
- decide how in a trustless environment players could make this consensus,
- select a trustless winner and grant him funds.
We want to make it easier for other developers to use our libraries that are being prepared for.
May we get a better understanding of the reward system for running nodes? How will mainnet nodes be rewarded? In Cell tokens? If so, where do those tokens come from?
We have no $Cell emissions at all and all Cell tokens have been already mined. One can run a master-node to earn from services. You need to provide some services based on capabilities of your internal hardware — CPU, GPU, your hard drive etc. It could be a content delivery network, a streaming platform, a dedicated messenger, storage, a cloud system, or any other thing. When you start your master-node, you just take our t-dApps library. That is why we have engaged such efforts to build it. And after that, you just run an application backend and earn from providing service/s. Mainnet nodes will be rewarded with Cell tokens. There are no limitations to providing your service with other tokens. Providing service with $Cell is mandatory, and in addition you can create your own token as well. Moreover, it would be an interesting idea for third parties to develop token-based services on some stable coin mechanics and implement it.
Charles Hoskinson of ADA says, if the hardware is having the back door in it, quantum resistance is no good. How does cell frame address this issue?
If you have a backdoor in your hardware, all your protection has absolutely no sense. It means that there is direct access to all data. Quantum resistance is not intented against this backdoor, but against Man-in-the-middle attack — interception of your signal, malicious behavior on your connection lines, quantum encryption, cracking your wallets. Because if you operate with your wallet, you provide an example of your digital signature.
Having a quantum computer you can take your digital signature and calculate a private key based on a public one. I know, if you return this change address as Bitcoin does, it is saved. But people usually need static addresses. But if you at least one time have returned changed to the same address it could be hacked. By the way, in the coming stages of quantum computers, it could be absolutely possible to calculate your private key based on your address as well. Because hash has one direction but it also could be cracked by a quantum computer.
How much Cellframe is affected by the ongoing issue in Ukraine? Love the project, love the team.
As you know, we are neutral and not politically involved. However, this is a tragedy. It is certainly a great tragedy for all people.
Many of our employees have relatives in Ukraine or used to live there. It is a personal tragedy for us and we cannot and will not take any political side. However, all of our developers are based in the same country, Russia, and our development is not affected in any way.
In addition to that, sanctions cannot affect cryptocurrency. We are lucky in a sort of way.
We don’t want to take sides. We hope for a speedy end to the conflict. We want our project to be as international as possible. We want to make the project an example of cooperation between countries, not a war.
What will be the incentive structure for the validator for the mainnet?
If you are asking about rules how to become a validator, we’ll publish this later, near to the Mainnet launch. At the beginning stages all new validators (we call them just master-nodes) should pass some checks and will have part of Proof-of-authority consensus. We’ll need to check all results of the proof of stake consensus and have the ability to cancel any such consensus with a Proof-of-authority signal. We need this because if you have a 51% attack, we need to drop a malicious branch or double-spend or something like this.
Since Cellframe is built with WASM contracts does that mean it can potentially be interoperable with the other western contracts like cosmos? Would be interesting to see Cell on the IBC.
Yes, we could. I want to have interoperability with as many blockchains as possible. For this, we are also going to implement classical cryptography like ECDSA. So, we’ll have native support for other addresses and cosmos addresses are also in plans.
Will there be airdrops for earliest takers notes for the cell network, or will self-wise can trucks be IBC compatible?
I am not sure. We’ll try to have it compatible. But we have a lot of specific mechanics and not all of them could be moved safely to other platforms. Also, we don’t know any other platforms features. So, I promise that we will try to make 100% compatibility. Also, I promise to make it more compatible and reduce the required amount of change to more smart contracts from one network to another.
I will think about airdrops for early stakes. We have no mining, so we have no source for such airdrops. But maybe we could issue some NFTs. Feel free and suggest some ideas for such airdrops. Because I don’t want to make a new token on the stage for such rewards. You know, early stakers on early nodes have the next benefit. It’s a service providing. Imagine, some people joining our network. They want to use some service and not all such service requires an unlimited number of service providers. For example, IoT hub, IoT relay. Those services could require only 10 nodes. If you join in the early stages you could be one of these 10 nodes and take 10% of all market share of the service. Also, you could start to earn your reputation. For it, we’ll have a special subchain with reputation values. They may be with a special token. And if you start to earn your reputation in the early stages, you will be on top.
Could you explain dapps vs t-dapps and are t-dapps exclusive to Cellframe network? Does Cellframe tokens support smart contracts or do we have to build dapps on Cells parachain like polkadot/ kusama?
The main difference between dapps and t-dapps is that the last has a dedicated execution of some code with single addresses. It means that there is one
address and one wallet. Through this wallet passes all the funds. For example, if it will be hacked all these funds will be stolen. Such a common story happens a lot of times. And t-dapps has no such address. It is not a smart contract. It’s a service plugin that could be run by any node. And if it runs this plugin, it collects all this profit to itself except network fee and author fee.
We are planning to run support first simple token like ERC-20. It will be some kind of CRC-20. We will run it support next month. So, it will be planned for April.
You don’t need to run your own parachain for your t-dapp. But often it’s a good story. Because parachain helps to pass a big amount of transaction and pay a fee for this transaction by your own rules in your parachain or not to pay it at all. For example, if you have some service that holds non-financial data and you need to communicate with this. And you have a really big amount of transactions. If so, the best solution is to run your parachain.
Can you put a simple instruction in a layman’s language on how to set up a node, system requirements and earning potential for each node?
Information on how to run your node is described in the readme file that is displayed on a Gitlab sources page. I think we need to record some videos and make some pictures with simpler explanations.
Why should someone “pay” for an auction-chain, if anyone can build a community/sister-chain for free? I mean, what is the benefit/revenue for cell token holders from a sister-chain like “Community Cellchain” or similar?
Yes, you could bring up your independent network, that’s not connected with our core network, and still attract users. But most of the benefits from obtaining a CellChain are related to the listing of your parachain in the list of built-in chains shown on the Cellframe Dashboard. The first and most obvious benefit is that every user who has downloaded the Cellframe Dashboard sees this list. The second benefit is a transparent bi-directional bridging between your parachain and all other parachains in the ecosystem. For example, if you provide your service with your token you could spend your token anywhere on the ecosystem and trade it on a built-in desk and accept payment in your tokens from users from other parachains. So, the main benefit is deep integration with the ecosystem, that attaches further use-cases for your network.
Could you clarify how many types of nodes will be there, and their details/differences?
A light node is one that holds only your own transactions and usually, it could be used on mobile devices, on built-in devices. It will not use much of a hard drive or memory. The full node holds all its shards and calculates different balances in this shard.
The next stage is a master node that could push some data in the chain, propose states and consensus and the only node that can provide services. Then, there is an archive node that collects all shards of the network and stores these. And there are root nodes that form proof-of-authority consensus and issue Zero-chain. Maybe in about a year, this proof-of-consensus will be also replaced with Proof-of-Stake. And Zero chain will be produced by a master node as well and the root node will be removed. So, root nodes are temporary in the mainnet.