AMA, February 17: security audit, development progress, mainnet
At Thursday’s regular AMA, the CEO of Cellframe Dmitriy Gerasimov has been talking about preparations for the main network launch and what happens afterward.
Mainnet
It is almost everything ready, including the block consensus. The final preparations will be made over the next 7–10 days. After that, the security audits will be started. Accordingly, the start of the audit will be delayed by a week, maybe a little more. The audit will last for two weeks. If the audit finds any vulnerabilities, the developers will fix them and launch the mainnet. It will also take two weeks to fix everything. If the audit finds no critical vulnerabilities, the mainnet will be launched on schedule.
Bridge auction services
After the mainnet is started, the bridge will work. It will work one way for a while because of security reasons. Also, the Proof-of-Stake will work together with Proof-of-Authority. A demo of the bridge is planned for early March. Development of the bridge and auctions are now in the refactoring stage and are on their way to finalization. It will be an example of a possible level two implementation because it will have its local consensus for transition states between different blockchains. After the main network launch, it will be possible to earn from the VPN service and other services that the company will prepare.
Hackathons
They are scheduled for March. The schedule will be published over the next few days. But beyond that, the company is preparing rapid development dApps. They will be simple but tasteful. It will be a kind of CDN or some dedicated storage. Right now, the team is investigating what will be the fastest.
Parachains
They will not be connected at the start, and the team will connect them during post-release development. This means that there will be no interoperability between the parachains at the beginning. So, you can’t pay with a Cell token for service provided in KelVPN parachain, for example, but you could directly use this exchange. However, the parachains will be present.
For example, you will connect to and use KelVPN parachain from the VPN. And it will also be possible to use KelVPN inside the core network with a fee for KelVPN as an author’s fee. This will be done after running the mainnet for dApps, and then it will be possible to run a node. We have reduced the stack size for running a node to about 1000 CELL, and stack size will reduce further.
The 2nd stage of the security audit
The Cell team is working 24/7 to have everything released on time. However, the sharding can either be done before the mainnet or after the mainnet. So, the audit without sharding will be done before mainnet, and after mainnet, the second audit with sharding will be turned on. “We need the audit, not for us. It’s more for enterprise usage, so that’s why it’s important”, — repeated the CEO.
The TPS will be measured while sharding is on. The Cell technology is supposed to be used on weak hardware, so we have to take measurements while sharding is on to achieve optimal TPS. Accordingly, the results of the TPS measurements will be published after the sharding is turned on. There is no requirement to have ultra-high TPS in a shard. But if you require it, it will be better to have your parachain or connect your transaction with two or more shards. “Inside one shard shouldn’t be a lot of activity because it could be used by a mobile application with no terabyte drive to store or all the sharded has no gigabyte bandwidth to download all this”, — explained Dmitriy.
Development progress report. Cellframe SDK
The part of the TON consensus protocol logic is developed.
It made the consensus protocol run on a timer. If the validator has a candidate for blocks, it generates a Submit event. The validator sends its candidate blocks to all validator group addresses in the Submit event. Each validator can only offer one candidate to blocks. When a validator receives a Submit event, the proposed block is validated; the validity of transactions in the block is checked (via leger). If the candidate passes validation, it is stored in the GDB Approve event is generated. Otherwise, the Reject event is generated. Events sent, and received, are stored in the event history hash table and GDB in case of failure. If any block candidate reaches 2/3 (two-thirds) of all validators in the Reject event group, that candidate is removed. Otherwise, if a candidate gets 2/3 of the Approve event, it goes to the next stage — voting for the candidate. A “quick try” is implemented, that is, a variant where the consensus coordinator and VoteFor event are not involved. The “quick try” is the first attempt to reach consensus in the TON consensus. If that fails, additional means in the so-called “long try” are included, but the first attempt is always sufficient.
A mailing is made, and the PreCommit event handler generates this event and tells the validator that it will only work with one candidate for blocks because this candidate has 2/3 of the votes.
The development of the CommitSign event has begun. The signature collection is the final consensus stage when 2/3 of the validators confirm the votes with the PreCommit event.
Minkowski Network
It is a parachain for KelVPN. The DAG-Proof-of-Authority consensus is fine-tuned. Paid transaction tests are underway.
Saving blocks are implemented to files and read from files. Similar to DAG, the mechanism saves blocks into files of chains and loads these files when a node starts. Each cell_id of the block has its file.
The custom notifiers for the changes in the GDB and separately for the orders were added;
The team has added a transaction generator for TPS measurements and has also created a test network. Also, an application for node services is developed, and SDK for Python-cellframe is finalized.
Bug fixing
Not all transactions were sent with -tx_num key when creating multiple transactions. This is fixed now. The team has added transaction trashhold deployment when adding an issue to the Ledger. Slightly optimized trashhold deployment in terms of speed. Added Notify server section and Minkowski network configs to the distribution. The work of the Notify server is restored. An error during synchronization is fixed as well. Now the actual data are always shown. Transactions made between different networks were shown as done. The name of a purse could consist of any symbols. Fixed “connection closed by peer” and “socket read error!” during emission with a standard certificate.
Dashboard application. Release branch.
The Node is being ported to Android for the mobile version of the Dashboard. The fonts of the icons and buttons are reworked. The bug is fixed where you could launch the app without a running service. We reworked Certificates, Wallets, Settings. dApps pages were redesigned to fit the layout.
The auto-complete commands in Console Tab are added. “I recommend using this tab because it opens a way to work with commands with a lot of features, much more than we have in UI, but that’s for advanced users, of course”,- said the Ceo.
The first word is added by pressing the Tab button, and command options can be scrolled through with up and down buttons. The right button on the keyboard confirms your choice. Console fans will enjoy this feature.
On the Settings Tab, you can now see the version number.
The Logs loading indicator has been updated. In addition, the team has fixed the bug with infinite log loading and a bug with freezing when exporting large amounts of data.
The frontend team has improved the animation of network indicators on the Networks Panel. Now they work synchronously. The dev team had fixed a bug that prevented one network from displaying when a user widened the Dashboard window. The Dashboard Wallets’ mobile interface, TX history, Settings, Network Panel tabs are developed.
The developers have implemented data storage models, the logic of tabs operation, and the transition between them. Also, implemented processes of transferring tokens and creating wallets.
The team has started to port the Node to Android. Node is built as a dynamic library, including linking two dynamic libraries. A Java wrapper for the Dashboard Service message and the Node is in progress. In Java, the team makes some node_cli for sending and receiving requests to/from the Node. Java Intent, JNI, API for Java to work with C code will be used for this.
Some questions:
How will Cellframe solve for the web3 server problem?
I don’t like the modern web3 conception because the server problem is a real problem. And I don’t think we need to stay with the current web3 infrastructure. There is a central storage and centralized DNS. We need to go away, and I think it will look like a Brave browser or extensions for Chrome, Firefox, etc. In other words, a browser should not work directly with the internet because the modern internet is too centralized. So, it should pass all these requests through Cellframe dashboards and then through the Cellframe Node. Then, it should balance between its uplinks to other nodes. There will be no server. So, the key to this problem is deep integration with Cellframe infrastructure.
What is CELL vision and main targets for 5–10 years duration?
Develop our ecosystem, develop more and more dApps and see how we could improve our protocol compared with our competitors. As I mentioned before, it’s oligopoly companies or corporations: is Amazon, Google, Microsoft. And they have a lot of services that we used to use. We need to make the same but better. It’s a super challenging task to make everything better, but we need to make it better. We need to make better Google Drive, make better Skype, and make better Youtube, Amazon web services, and others. We need to make everything better, not just be dedicated. For users, it’s not important: it’s dedicated or not. He wants to store his photos with cats, and that is all. We need to make it simpler than Google Drive or Dropbox. And that’s our goal. And that’s all about cloud services. So, the next five years will spend on developing our ecosystem to compare with cloud service providers.
What is your plan to make more attraction and new partnerships in the near future?
We are planning to publish press releases in a lot of media. We are working closely with influencers. And the result of our marketing is token price rising in last few weeks.
Which other ecosystem are a priority to bridge cellframe ecosystem’s with?
The first priority is to bridge with Ethereum and Bitcoin. Because they have a lot of liquidity, and mostly we need liquidity.
In addition to the Dashboard, it would be great to have a wallet browser extension ready to go out with the mainnet. Are you working on a browser wallet extension to interact with the Cellframe ecosystem?
We have proposals from a third party. They want to develop such a browser by themself. We are planning to develop this year. By the way, I don’t like it at all. I prefer a standalone application or a super application. But if you prefer a different one, we will develop a web extension. But it would be best if you remembered it’s not so safe to use such a wallet extension in a browser because you use some third party to provide some blockchain information. However, you sign it on your site, but you don’t download all the blockchain on the site. So, I advise downloading the Cellframe Dashboard and using it.
Is it possible to have more details about the 3 types of Cellchains?
- System-level Cellchains
- Auction-granted Cellchains
- Community Cellchains
System-level Cellchain will be one. It’s a core network. If we talk about the mainnet. There will also be a few test networks on the system level. Some more system levels of chains may be in the future, for example, a standalone parachain for decentralized exchange. Auction-granted Cellchains are all the rest. Finally, community Cellchains are granted for free for useful good projects.
The Cell team holds only 950 000 tokens. When the team tokens are sold, what incentive does the team have to continue working on the project? How does the team finance the development of the project in the next 5 years once team tokens are sold?
As I said before, we will have two fees. One is the author’s fee, which is paid after using some service. Another smaller fee is a network fee paid for any service from any transaction. It is flexible and will be sent to the community driving funds. It may be issued special government tokens or for all who stake CELL or CELL in pair with ETH or BNB for a long time. Such people could vote for spends. I hope the community will agree to fund development from these funds. Also, the Cellframe will issue a few more services which will be direct funding from the author’s fee.
📣Media Links📣
🌍 Website
🌍 Telegram Ann
🌍 Telegram Group
🌍 Twitter
🌍 Discord
🌍 Twitch
