TEA Hosting Nodes: “Dynamic” IPFS Gateways
The TEA Project uses IPFS throughout its tech stack as a decentralized data store. For example, TEA’s decentralized apps known as TApps are stored on IPFS and loaded onto TEA network mining nodes when called by end-users. It turns out that TEA’s hosting nodes share many commonalities with IPFS gateways with one crucial difference: they’re also able to serve dynamic content. This post will take a closer look at how the interplay of TApps and TEA hosting nodes allows users to interact with decentralized dynamic content that goes beyond the network’s roots in IPFS.
TApps Are Fundamentally IPFS CIDs
In the TEA Project, the TAppStore stores a registry of all TApps running on the network via their content IDs (CIDs). For a refresher on how the end-user finds the location of the TAppStore to load in their browser, the details can be found in the following article:
Now that the end-user is able to access any TApp’s CID through the listing provided by the TAppStore, the end-user just needs to find a suitable TEA hosting node through which to run their desired app. The hosting nodes are similar to IPFS gateways except for a major difference: the TEA hosting nodes can also run dynamic content.
Static IPFS Gateways vs Dynamic TEA Hosting Nodes
IPFS provides gateways to CIDs through URLs that are structured like
http(s)://some_gateway_ip_or_domain_name/ipfs/cid_of_static_content
The end-user can choose any IPFS gateway to replace some_gateway_ip_or_domain_name in the URL. It won’t change the result because only changing the last part cid_of_static_content would return a different content result. IPFS is “location agnostic” because it uses “content addressing”.
The TEA Project’s nodes are very similar to the IPFS concept of a gateway. In the TEA Project, the URL of a TApp would look like
http(s)://some_hosting_node_ip_or_domain_name/ipfs/cid_of_tapp_front_end_code
In the TEA Project, we don’t care about the specific hosting node used to access the TApp but rather its CID which makes all the difference.
Although IPFS gateways and TEA hosting nodes can both serve static IPFS content, the TEA hosting nodes go further in their ability to serve up dynamic content. We’ll go into further details but let’s first look at how traditional blockchain-based dApps serve up their dynamic content.
TEA Project TApps Are Truly Dynamic DApps
The front end of a TApp is actually loaded inside the user’s browser from an IPFS CID. If it’s a front-end to a dynamic TApp, it’ll start utilizing hosting nodes in order to execute the functions to process the dynamic content. This layer that processes the business logic is usually called the backend in traditional cloud computing.
But when it comes to smart contract based platforms like Ethereum, most of their network dApps don’t have a backend. An Ethereum dApp will either get its dynamic content from its blockchain directly, or it will make remote calls to centralized cloud hosting for its necessary compute cycles. The problem with remote calls to cloud hosts is that you end up with hybrid dApps that aren’t truly decentralized.
The problem with relying on the Ethereum blockchain for dynamic content is that Ethereum’s ledger is an extremely inefficient database. It can’t even be considered a backend compute server tier when it comes to generating dynamic content. Some API providers such as Infura or Alchemy are widely used as the “thin backend” to accept query and mutation requests. But those thin backends fall short of the fully capable server backends that we’re talking about here.
Layer1 blockchains function as de facto databases (the state) along with smart contract code (stored procedures). So although you could make the argument that Ethereum dApps can have a decentralized front-end (through IPFS) and a very rudimentary database tier, it’s still missing the important backend tier that would make it comparable to the cloud’s “function as a service” or “lambda” backends.
TEA Project’s Decentralized Serverless Backend
In current smart contract-based dApps, the lambda layer is missing. That’s exactly the role that hosting nodes in the TEA Project play.
In the TEA Project, function calls act as microservices that move data back and forth between enclaves. A single TApp will spawn multiple microservices (actors in TEA Project’s terminology for lambda functions) that are generally executed across multiple enclaves. These inter-enclave data flows are also protected which preserves the data privacy of all the functions as a whole that execute on behalf of a TApp.
The missing middle backend tier means that complex server logic is also missing from smart contract-based dApps. Platforms like Ethereum lack the backend tier which is the main reason that dApps lack the power that a decentralized compute layer would give them. The decentralized TEA Project hosting nodes host the pure functions that allows TApps to run at speeds comparable to web2 cloud computing while also leveraging IPFS for the decentralized app front-end and SQL for the database tier.
If you’d like to learn more about the TEA Project’s goal of bringing full-speed compute to the blockchain, join our Telegram group.
