Diving deeper into Cellframe: (Trying to) explain t-dApps

This article was originally written by Mika Hyttinen. Medium link: https://medium.com/@mika.hyttinen

People, it’s time! t-dApps!

I think it’s quite relevant to start talking about this for the Cellframe ecosystem as the project is getting more mature day by day and I think that soon we will start to see some “real” t-dApps flowing out.

In this article, I‘m trying to explain in layman’s terms the key differences between dApps and Cellframe ecosystem t-dApps.

I was actually going to even build one simple t-dApp for Cellframe Dashboard (which will be (or already is) one of the key elements managing your wallets / nodes / dApps) and Cellframe node.

Unfortunately I had to skip this part for now as there wasn’t (yet) enough documentation out for the Dashboard extensions. However, I will return to this later when we have some better documentation out.

Let’s go!

. . .

About Cellframe

Cellframe is an ambitious third generation blockchain project and few people (me included) have already started to talk about it as the next Polkadot or Kusama.

This project is, however, more service oriented and has some advantages compared to Polkadot/Kusama (eg. post-quantum cryptography, 2-level sharding, P2P cross-chain operations).

Cellframe is written in C (which will make it FAST and portable), and it has an SDK for C and Python at the moment. More supported languages are coming in the future.

I really recommend visiting their website (https://cellframe.net) and read their whitepaper!

. . .

What are the key differences between dApps and t-dApps?

Multiple persons would probably agree with me that when we talk about dApps currently, we mean a smart contract which is running on a Ethereum network. This dApp is usually owned by a person (or persons) who has full control to it.

If a rogue person for some reason gets access to your private key in Ethereum network, your funds would probably get stolen.

In t-dApps, this is done quite differently. In Cellframe ecosystem, the t-dApp doesn’t have private key as the provided t-dApp is running strictly inside the system and doesn’t rely on any type of smart contract.

t-dApp can actually be considered as a server and a client plugin combined (for Cellframe nodes).

If a node chooses to run a plugin, it collects all the profit to itself (excluding network fee and author fee).

One truly important advantage is also that on the Cellframe ecosystem, you have access to full hardware resources on the host system. Sure, there are some networks already built directly to circumvent these issues (file sharing, cpu power etc.) but what if you could build all of those on a one ecosystem?

How do you build an t-dApp then?

Here’s an image how a simple t-dApp data flow could look like.

The backend for a t-dApp is a plugin for Cellframe node. A plugin will be distributed through master nodes. Every plugin will be checked before distributing and because of that, all these plugins needs to be open source.

Every master node which chooses to run this plugin should receive rewards when doing so.

The green lined button in the picture above is a light/full node. That particular node is expected to run on a clients own service plugin which will provide the protocol for connecting to a master node plugin.

This light node is obviously not tied to any particular master node, it can connect to any of them (like as in mesh network).

The yellow lined button in this picture is a user/client. This client could for example use a website, Cellframe Dashboard extension, console based application etc. for connecting to the client plugin, which would then provide the service for the user.

You could also develop some type of “social” plugin for Cellframe master node which would be a free service to a user. It could be a tip bot for Twitter / Telegram / Discord or even some type of wallet tracking bot.

Example: Video streaming service

Here’s an image how a video streaming platform data flow could look like. (It’s honestly really simplified, but you probably can understand the basics with this picture 😉).

First, a check is made on the client plugin: If service subscription is valid (eg. payment is made), then connect to the service plugin part on master node.

If there’s no valid subscription for the user available, return an error to the customer. After this, user can pay for subscription and then return to the validation part.

Master node runs the backend plugin which could also have a GlobalDB (global database) set. That particular database could have information about the users favorite movies / series, maybe some movies for recommendations etc.

In this example though, the client plugin just checks for validity of subscription. If subscription is valid, you can access the movie database and select the movie you would like to watch (with some popcorn maybe?).

Conclusion

I really think that soon we will see some real t-dApps flowing out. I’m not sure which type of apps we will see, but wild guess would be: Advanced.

By the way, I honestly thought that writing this article would be an easy task to do. “Hey, just write an article and that’s it.”

I was so wrong 😆.

It’s quite hard to actually make this type of article so everyone could understand how a system like this works. If you have trouble understanding, you can always contact me via Telegram or Twitter (@CELLgainz).

If you want to get involved with building on the future of blockchains, you can always join Cellframe Development Telegram channel.

Thank you for reading!