Why We Made the TEA Project
The TEA Project can be summarized on a technical level as decentralized cloud hosting that uses time instead of blockchain for consensus. The impetus for why we made the TEA Project arose from the data security breaches that plague traditional cloud hosting. And as we created a decentralized app hosting layer that runs on top of blockchain, we simultaneously created new monetization opportunities for our ecosystem participants.
You may have heard of the new opportunities awaiting end-users who’ll be able to monetize their own data in web3. It makes sense that freedom to monetize would go hand in hand with end-users having true ownership of their own private data. An additional departure from web2 is that TEA Project hosting nodes are complete separate from the apps that run on top of them. The hosting nodes are actually paid for by the end-users who need the compute resources to run the apps. This opens up a whole new business model for hosting node operators that’s explored later in this article.
Moving IPFS from Static to Dynamic Content
The TEA Project itself is built from many existing technologies such as TPM, WASM, and IPFS. These are all promising tools but they needed to be combined in a certain way to build a trustable and decentralized compute infrastructure. To see how we used these disparate tools as a starting point to create the TEA Project, let’s first start with how we overcame the limitations of IPFS.
Web3 involves decentralized data interacting with decentralized apps. For static content, developers have found IPFS perfect for their needs. Not only data but application binaries can be stored on the decentralized filespace that IPFS provides.
Because IPFS offers decentralized storage, it has an ideal use case for hosting static assets in a decentralized manner. Anyone can write a blog post and pin it to an IPFS node and voila, instant decentralized blog. But what if we want to go further than just serving static content?
We said earlier that web3 was essentially decentralized data interacting with decentralized apps. That’s fine for a static blogging app which could look something like this on IPFS:
- Blog post (text and images as the decentralized data) + blogging app that formats data into blog post (decentralized app).
This model of serving up static content is relatively simple as everything can be stored on IPFS. All economic incentives essentially amount to providing enough payment for the nodes to keep your content and dApp hosted.
But what if we wanted an actual dynamic app that could update its UI as users interacted with it? We would end up needing something that looks like this:
- Decentralized data interacting with decentralized apps on decentralized hosting.
This is exactly the value proposition that the TEA Project adds to web3: decentralized hosting.
Dynamic Content Through Decentralized Hosting
The TEA Project picks up where IPFS leaves off, offering app hosting just like the cloud together with a database layer. What makes it different from web2 cloud hosting is that all of it is decentralized. And what makes us different from other web3 projects is that we don’t run directly on the blockchain which would throttle dApp speed.
Another difference between TEA and other web3 compute projects is that we use hardware instead of software for security. Hardware is very difficult to attack, and the particular hardware technology we use (TPM) has a long established history behind it. This is in contrast to other projects that use software for encryption, which has increased costs and centralization effects associated with it. The TPM chips on-board the TEA network’s hosting nodes also helps to protect the integrity of the GPS units which are required for ordering transactions in our layer-2.
TEA Project Tokenomics: Providing the Right Incentives
The economic incentives built into the TEA Project helps encourage healthy participation from all in the TEA ecosystem. The central hub of activity is centered around TApps, the decentralized apps that run on the TEA network.
Working off the graphic above:
- The end-user pays and receives the utility of the TApp: a payment directly to the TApp and another payment to the hosting node(s) that run the TApp’s code.
- The TApp pays fees to the state machine nodes for occupying space in the state machine. Any TApp profits are sent to its TApp token.
- The CML hosting nodes receive payment from the TApp end-user as mentioned earlier. In addition, they receive public service rewards paid by the state machine maintainer nodes. These public services include remote attestation and are for the benefit of the entire ecosystem. Some CML nodes will subscribe to receive state machine updates faster than others, a fee that’s paid as global revenue to the TEA token. And just like TApps, each CML node has their own CML token which other users can invest in.
- The state machine maintainer nodes receive revenue from TApps and have the expense of paying out public service rewards to CML nodes. An additional expense known as the Harberger Tax is a % of the self-valuation price that’s paid to the TEA token holders.
The TEA Project combines an elegant layer-2 solution to securely run dApps at cloud computing speeds. User data remains private and secure thanks to the hardware security modules installed in every TEA hosting node. A well-designed tokenomics model helps ensure that all participants are rewarded for their contributions to the TEA ecosystem.