TEA Project: Filling the Gap Between Cloud Apps and dApps

The Decentralization Movement

Although still at an early stage, decentralization is becoming a new movement for many tech pioneers and business investors.

During the 2017–2018 Blockchain and crypto hype train, I heard many cool ideas everyday about how traditional business applications will become decentralized apps in the blockchain world. Quite a few of them made sense from a marketing and business demand standpoint (although some others may not). Unfortunately, when the hype faded, those projects are (almost) all gone with very few of these ambitious ideas being turned into real applications. I know there are many reasons, but one of the most important reasons in my mind is the technical difficulties. Any distributed system is hard, very hard to build. We have to acknowledge this before moving forward.

Building dApps is very different than cloud apps

ETH could be the first blockchain project to introduce the concept of dApps since the first crypto, BTC, is not programmable. ETH opened a window to a new type of application — the smart contract. This could be the basis of all other dApps, including those on the TEA Project as well. However, if you already know the technical details behind smart contracts, then you’ll understand that it’s not ideally suited for common business applications.

Many so-called existing dApps only utilize a few smart contract features but have to host on a traditional cloud computing infrastructure. I would call these kind of dApps “Hybrid apps”. No matter how much they claim to be decentralized, they can be taken down by removing them from their cloud host as opposed to dApps which are robust and disaster-resistant.

Why is that? It’s because we don’t have a decentralized computing infrastructure as we have had in cloud computing. Nowadays it’s so easy to deploy cloud services to Digital Ocean or Amazon, or use the CDN from Cloudflare or Fastly to get fast pings from all over the world. We don’t care about how the complex cloud system works, all you need to do is to pay.

Deploy and run your code/data in a decentralized manner as we currently do in cloud computing

What if we can build a similar “de”-cloud computing infrastructure that developers can simply “deploy” and pay. Their code or data will automatically run in a decentralized manner — with no way to be taken down as in the cloud computing world — worry free! This is how the idea of the TEA Project came to be.

When we design the TEA project, we try to fill the gap between dApps and Cloud Apps. We make it easy for developers to reuse whatever they already know: programming languages, tools, OS, even IDE. In most cases, you can still work as if you’re still working with a server, even though it’s not technically true. Your code will not be running on a server. Instead, it will be running in many unknown and unpredictable nodes. The reason we designed it this way is because with these underlying unknown and unpredictable nodes we need to reinforce resilience and security. If hackers know where your code/data is located, it will become an easy target. However, as a developer, you don’t care about this. What you will need to do is simply the following steps.

• Compile your server code to WebAssembly.
• Using our deployment tools to deploy to the TEA network (based on IPFS).
• Do not forget to pay :)

Your code/data is encrypted first before saved to IPFS. Only trusted TEA nodes (who have passed remote attestation) have a copy of the decryption keys in their secured memory. The security of the TEA nodes is protected by hardware (TPM or HSM) and guaranteed by TEA consensus on its Substrate-based Blockchain.

I listed quite a few concepts in my last long sentence. If you do not know all of them, let me give you a basic explanation here.

• Wasm: WebAssembly, a new ISA, bytecode binary executable format.
• IPFS: A decentralized file system.
• TPM or HSM: Trusted Computing technologies in chips or hardware enclosure.
• Substrate: The tech base of the popular Polkadot blockchain.
• TEA: Trusted Execution and Attestation, which forms the basis of the TEA Project.

You can use your existing programming languages, but you still need to compile to a new compile target: WASM. Not all existing code can be directly compiled to WASM and run, and not all languages can directly compile to WASM. Likely you may have to rewrite some business logic…but this is still much easier than learning a new smart contract language. As far as I know today the languages that can compile to WASM include:

• .Net
• AssemblyScript
• C/C++/C#
• Go
• Java
• Javascript/TypeScript etc
• Kotlin
• PHP
• Perl
• Python
• Ruby
• Rust
• Swift

For a full list of 37 languages click here.

For your client-side app, you’ll need to make sure it can be load statically. For example, if your client-side app is a WebApp. Make sure to compile it as static resources. It would be eventually loaded from IPFS as static files (js, HTML, CSS, jpg, etc.). NO SERVER is required!

In our milestone 1 demo, our client-side app is written in Vue.js. Our server-side code is written in Rust compiled to WASM which Tensorflow supports.

I have to mention although we try to allow you to reuse your existing tech stack, building a decentralized app is fundamentally different than a centralized app. Many concepts you may take for granted do not exist any more in our decentralized platform. For example, there’s no longer any networking built into our mining nodes and have been replaced with unix sockets. This is to ensure there’s no private data being sent outside the platform, an obvious security concern.

Generally speaking, the decentralized app will run slower than a centralized app. In return, you gain resilience, security, privacy and trust. Consider your app can never be torn down no matter how powerful your enemies are. No pain no gain, right?

My dispassionate point of view on dApps

Even during the 2018 blockchain hype, I clearly talk to everyone my point of view on dApps: If an existing business logic runs well in a centralized way, there is NO need to convert to decentralized way. There should only be a focus on the business logic should that should exist but has not existed due to lack of technologies before.

As I just mentioned, dApps usually run at a higher cost than traditional cloud apps. Unless there is a huge gain (privacy, national security, national defense, etc.), converting exists apps to dApps would be a bad idea. On the other side, if there is an opportunity that should exist to satisfy consumer or institutional demand, but does not exist yet because we did not have the technologies to build it until today, well lucky you, now is your opportunity!