The TEA Project’s Value to the Polkadot Ecosystem

7 min readFeb 16, 2022

If a parachain could offer a fully decentralized computing layer, then Polkadot itself would become a fully decentralized Web3 ecosystem.

Current DApps Are Web 2.5, Not Web3

The premise that dApps that run on blockchains like Ethereum are actually running decentralized is often just an illusion. The extent of the illusion is only revealed when peeking into the dApp’s actual tech stack. Most dApps have parts that still run centralized on web 2.0 and operate like a “web 2.5” hybrid of web 2.0 and blockchain. For example, the code for the front-end of some hybrid dApps is often hosted in the cloud, making it open to security threats. Many decentralized apps will also need computing power beyond what the underlying blockchain can provide, including a database it can write to with more functionality and throughput than a blockchain ledger can provide.

A Preliminary Solution: IPFS + Back-end on Ethereum

A stopgap solution to make hybrid dApps more decentralized is to store their front-end code to IPFS. The user queries the dApp’s known CID to any IPFS node, receives the dApp’s front-end code in response, and then loads it in their browser. Because the IPFS CID ensures that the code will be associated with this address, there’s no way to hack the source code.

The dApp’s front-end code (mostly Javascript) uses web3.js to issue RPC calls to Ethereum nodes as a back-end for both querying data and sending transactions. This is undoubtedly a fully decentralized solution, but this works only if the application is super simple. Comparing this smart contract-based app with modern cloud computing would be like comparing a graphing calculator to an iPad.

What Are the Missing Pieces for Fully Decentralized Rich Apps?

Most modern internet applications use a three-tier architecture: a front-end, a back-end, and a database. The IPFS + Ethereum architecture explained above would be missing the back-end compute tier if we consider Ethereum’s state machine to function as a database with smart contracts functioning like stored procedures. But Ethereum’s state machine is far less capable compared to any modern database, not to mention the cost of gas would make apps writing to it prohibitively expensive.

Let’s see how we could re-construct this three-tier architecture that’s so common in the cloud world directly on the blockchain.

Front-end tier: We can use IPFS to host our front-end, so decentralizing the front-end tier has already been solved.
Back-end tier: A fully decentralized network where the nodes can host the back-end app logic.
Database tier: A powerful distributed database layer that’s also fully decentralized.

These tiers to be fully decentralized would need to have the following features:

Code or data running inside the node is fully isolated, with even the node owner having no way of knowing the internal state. This isolation, which happens inside of our concept of a trusted enclave, would solve any privacy and security concerns.
Nodes can join and leave the network at any time without affecting the overall network performance.
There should be no centralized authority to control the nodes. All nodes belong to individual miners who host any particular app because it’s profitable.
Users of the platform don’t need to trust any of the nodes or their owners. This is not because they “do not” do evil, but because the architecture makes it so they “cannot” do evil.

What Are the Existing Web3 Solutions?

There are currently some Web3 solutions available to provide truly decentralized cloud computing, but they each have different issues that make them less than ideal.

Some solutions still use the existing cloud computing tech stack where the individual node owners “rent” their node to you. If trusting Amazon is a concern, can you trust a cloud provider that you’ve never heard of? Taking your code or data away would hypothetically be too easy, and this type of architecture setup cannot enforce that they do no evil.
Some of the solutions still use partially centralized authorities. Some examples of common certificates issued by central authorities used by dApps include SSL for HTTPS and DNS for domain names.
The best existing solution so far has achieved the ability to run dApps fully decentralized but requires a huge amount of computing power and very low network latency, which basically means that only server-class hardware in major data centers are eligible to run nodes. This places a bottleneck on the number of nodes and the diversity of node types on the network, introducing a new type of centralization.

We’re therefore looking for a decentralized cloud computing solution that:

Can be run by individuals with affordable hardware requirements.
Doesn’t require any central authority or special hardware vendors.
Requires no trust as all roots of trust are built-in to the system.

Based on The Above Requirements for Truly Decentralized Computing, We Built the Tea Project

The TEA Project was built to bring cloud computing speeds directly to the decentralized blockchain. Its infrastructure is built with two layers, a trust layer (layer-1) and a fast execution layer (layer-2). This setup allows layer-1 to focus storing trust data to ensure all nodes running on the layer-2 are trustworthy. Because our layer-2 no longer needs to run BFT consensus, the nodes can execute the business logic of dApps at cloud computing speeds.

TEA’s layer-2 can run dApps at full speed as there is no traditional blockchain consensus necessary to be performed on its layer-2. The traditional blockchain is not the solution to running dApps at full speed. Traditional blockchain needs to use a consensus algorithm to handle trust issues. If the app execution layer has any kind of consensus, then there’s no way dApps can be made to run at the speed of cloud apps. To find a solution, we need to think beyond the scope of pure software and math-based consensus and look for a root of trust from the physical world.

The TEA Project Uses Two Hardware Roots of Trust

The TEA Project leverages two hardware roots of trust to build its decentralized cloud computing architecture: TPM chips and GPS modules that are both part of every mining node on TEA’s layer-2.

Hardware-protected enclaves function as one of TEA’s hardware roots of trust since software is too easily hacked. Every mining machine on TEA’s layer-2 network has an onboard TPM chip that oversees the mining node’s protected enclave. The encrypted dApp code and user data are only decrypted within the secure enclave, and not even the hosting miner can see them in their decrypted state. Our TPM-based enclave solution is in contrast to FHE and MPC which require a much higher level of computing power. The TPM chip also monitors any attempts to alter the mining machine’s hardware which will be revealed through an attestation process run by peer nodes. The nodes are all trustable through the remote attestation that’s performed on the layer-1 blockchain.

The accurate time of GPS satellites as relayed by the miners’ onboard GPS module forms the basis of our state machine and SQL database tier. All blockchain consensus algorithms are trying to solve the same basic problem: how do we get every node to agree on the order of transactions? The smart blockchain inventors designed a lot of proof-of-alot-of-things algorithms that end up burning lots of energy, bandwidth, and storage-space to reach such a consensus. But what if we used the basic concept of time to do the same without any cost?

We use the true timestamp to sync the state machine between all nodes without any complicated consensus in between. Using time as a root of trust allows the TEA state machine to update continuously because there’s no block, and there’s no need to wait every few seconds to get the consensus from peer nodes. Besides the regular Ethereum-like state machine, an embedded SQL database instance is included in the state machine (GlueSQL). The presence of this database tier allows developers to use the SQL language to handle complicated business logic.

As far as TPS, we don’t use such a measurement because there’s no block. Just as Amazon EC2 doesn’t publish TPS constraints, dApps that run on TEA Project’s layer-2 don’t have a TPS constraint. The discrete unit of a block is what limits almost all other blockchains. If there’s no block, then there’s no limit.

TEA Can Provide Polkadot a Decentralized Hosting, Computing, and Database Layer

The TEA Project was designed from the start to allow other projects to integrate our trust concepts and use our layer-2. As a project built on Substrate, it’s been a straightforward process preparing the TEA Project’s layer-1 to become a parachain of Polkadot. With TEA running as a parachain, other projects in the Polkadot ecosystem can host their back-end logic on TEA as necessary. Other parachains would be able to fully decentralize their tech stack and no longer be dependent on centralized servers such as the Amazon cloud. Besides a back-end, a decentralized SQL database is also available in TEA. The database layer makes business logic much easier to write than relying purely on blockchain. We anticipate that having the typical back-end and database tier available will make it easier for developers to transition to Web3.

With TEA acting as a middleware layer, other projects can offload complicated computing tasks to TEA, effectively reducing the blockchain cost and workload. Farming out computing tasks to TEA allows parachains to focus on what they do best and utilize TEA when they need on-chain computation.

A gaming dApp could continue to write their digital asset logic to the ledger while running its actual gameplay on the TEA Project. Many gaming dApps currently use AWS servers because the underlying blockchain they’re built-on doesn’t have the necessary throughput. Instead of funds escaping to the web 2.0 ecosystem, developers can have their gaming apps run through TEA and keep the funds within Polkadot.
TEA can also function as a decentralized hosting provider to projects requiring decentralized hosting within the parachain ecosystem.
A dApp might want to write and store data without it being written to the blockchain. They could use the database service provided by the TEA Project instead of using a centralized cloud service.

With TEA’s presence, the Polkadot ecosystem would become a truly decentralized Web3 ecosystem that hosts and runs rich applications!

If you’re curious and would like to learn more, visit us at Teaproject.org.