The TApps 3-tier Decentralized Tech Stack

TEA Project TApps are decentralized apps that are able to run fast and provide a rich user experience. It’s true that the TEA Project uses blockchain on its layer-1, yet it doesn’t suffer from the same scalability issues endemic to other blockchains like Ethereum. Ethereum dApps are fully decentralized, but they are bound to the blockchain in ways that make their dApps slow. This is the dilemma facing many app developers: they’re attracted by the blockchain for decentralization yet the same blockchain tends to make their apps slow. The TEA Project is able break the shackles typical of most blockchains by devoting a second layer to run decentralized apps at full speed. The TEA Project focuses its layer-1 blockchain to make sure its decentralized nodes are trustable, creating the necessary conditions for TEA’s fast execution layer that allows rich, full-featured dApps to flourish on its network.

Although the TEA Project’s TApps are decentralized like other blockchain dApps, they have more in common with traditional internet applications in terms of its technical architecture. The similarities makes it easier for developers to port traditional app logic from cloud computing into the TEA Project’s network.

TEA Project TApp’s 3-Tier Architecture

While TApps act like traditional cloud computing applications, the tech stack only superficially resembles that of typical cloud computing apps. Similar to existing cloud apps, TApps have a similar three-tier structure: a presentation tier, a business logic tier, and a data tier.

By comparison, Ethereum really only exists in this third database tier compared to the TEA Project’s utilization of all 3 tiers. Ethereum dApps’ front-ends exist in the cloud using the centralized web hosting and domain name protocols. The back-end tier for Ethereum is also centralized and explains why CryptoKittes needed a webserver to host its blockchain game. We can only say that Ethereum’s blockchain is decentralized at the database tier. Its smart contracts function as the “stored procedures” of the database in a traditional three-tier architecture.

The TEA Project uses all three tiers, but its technology stack and implementation are very different compared to the corresponding tiers typically found in the cloud computing tech stack. The following sections go through each tier and show how they each form an essential part of the tech stack for TApps running on the TEA network.

The Presentation Tier: The Front-end of TApps

Taking web applications as an example, TApps store all front-end code on IPFS with a unique content identifier (CID). In this way, a common web server is no longer needed to store and feed front-end code to the user. Because IPFS is completely decentralized storage, that’s all that’s needed for the front-end to be decentralized. As long as there’s a CID, the front-end code can always be loaded.

Since there’s no web server, the ubiquitous domain name is no longer important and even SSL is no longer necessary (although many browsers are stuck in the old internet and will warn if it’s missing). Users will just need to know where to obtain the CID for the TApp and if their CID is the latest app version.

To make sure users are using the latest updated TApp version, the TEA browser wallet queries the layer-1 blockchain to find the latest CID of the requested TApp. To open the TApp, the browser loads the CID from any IPFS gateway that works with the TEA Project. The most readily available CID access points will be other B CML nodes, but any user can also host their own C CML node at home and load the TApp CID directly from there.

For all of the B CML hosting a particular TApp’s CID, users will be able to see all versions of the TApps listed in the TEA browser wallet. Each TApp will have multiple locations from which its executable can be accessed corresponding to the different nodes hosting it. Since each CID is the same, the user can access whichever one has the lowest ping time relative to their location.

The Business Logic Tier: The Back-end of TApps

Because the front-end is a static resource loaded from IPFS, all dynamic data queries and more complex user interactions need to be processed by the back-end. The back-end here is purely API driven and is not governed by any of the front-end logic which is static resource-based.

The API here is divided into two categories, query and command.

• The query operation does not modify the state of the application (commonly known as the database). The query command is similar to a smart contract transaction which is used to change the state. The query operation does not require any sorting or waiting and can directly query from the database tier.
• The command operation is much more complicated because it modifies the database, and these commands need to be sorted according to precise time. This involves using the Proof of Time algorithm of TEA. This algorithm is used to ensure that multiple replica nodes served by the host database can update their own data status separately but always in exactly the same order, so that the state can always be kept the same. This achieves a consensus mechanism that does not require constant communication between replicas. In this way, fully decentralized high-performance commercial applications can be achieved.

The command query operation must interact with the 3rd tier, the data tier. This is more complicated and will be discussed in the next article in the series.