The TEA Project’s Value to the Polkadot 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.

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.

  • 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.
  • 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.
  • 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.

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.

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.

  • 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.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store