The Game-Changer for TEA Project: Portability

Tea Project Blog
4 min readJun 13, 2022

Existing blockchains perform admirably in vouchsafing their trusted ledgers. What they have a problem with is scalability, and they try to make an end-around their speed issues through 2 main pathways:

• Attempting to increase scalability through tweaking the consensus mechanism.
• Increasing scalability through clearing transactions off-chain, i.e. a layer2.

The problem with tweaking consensus to scale is that you’re trying to work around one of the fundamental limitations of blockchain. You can try to improve your PoW consensus or move to PoS or Proof-of-something-else, but you’re still left trying to work around the fundamental problem that lots of time is wasted waiting on consensus being reached by peer nodes in the network.

That leaves us with the second solution, scaling through a layer2. But batching and sending txns off-chain to a layer2 has an extra verification step that is computationally expensive. And layer2s are deployed relative to a single layer1 at a time.

TEA Project’s Layer2 Is Portable Beyond Any One Blockchain

The first big departure when comparing TEA to other layer2s is that we’re not tied to any one blockchain. The portable nature of TEA allows it to deploy as a smart contract on any underlying layer1. We can say that the TEA Project’s layer2 is completely agnostic to the underlying blockchain and thus portable to any underlying layer1.

But what about the issue of verification? We know that other layer2s have complex verification algorithms (like ZKP) which are computationally expensive. How will TEA verify all of the transactions happening on its layer2?

Before we discuss how the TEA Project can solve the layer2 verification problem, note that TEA eschews traditional consensus as much as possible. That’s why we have two roots of trust in the TEA Project beyond just blockchain: trusted hardware and time.

Verify the Environment, Not the Result

To see how the TEA Project can bypass the need to verify every layer2 transaction, let’s compare it to how you’d trust the result of the calculator app on an iPhone. As long as the iPhone’s not jailbroken, the TPM chip on-board the iPhone ensures that the apps haven’t been tampered with. In that case, you can use the calculator app, and you don’t need any further verification. The fact that Apple has a TPM chip on board makes sure that the result is trustable as the environment in which the app is executing is also trustable.

In the TEA Project, the layer2 uses the same trusted environment principle. Any node running on the layer2 must be deemed trustable from the viewpoint of any app that wishes to run inside the node. So how do we ensure that any particular node is trustable on our layer2? We don’t have a central authority like Apple has when trying to determine which iPhones are jailbroken. Instead, we rely on randomly selected peer nodes to perform remote attestation. Once the candidate node passes remote attestation from its peers, it’s considered a trustable node on the network.

A critic may raise concerns about the possibility of multiple nodes colluding to promote a hacked node as trustable. But there’s enough randomness in the system and economic disincentives to dissuade potential hackers that it would make such attacks very rare.

What Data Flow Looks Like in TEA’s Layer2

The following diagram shows how data flows from among the protected enclaves (outlined in orange) within the TEA Project’s layer2.

The orange lines represent the boundaries of the TPM-protected enclaves. The red lines indicate protected data flow between enclaves, while the green lines show data flow between the enclaves and the environment outside the protected enclaves.

The red lines show the protected data flow and form the basis of the TEA Project’s model of apps as microservices. Imagine a TApp constructed out of many different microservices running in secure enclaves across the TEA Project network. These microservices can shuttle data between them and still have all data remain private. This allows multiple enclaves executing different code to work together to solve complex customer requests while preserving anonymity and privacy.

If you’d like to learn more about how the TEA Project aims to become the primary decentralized compute layer for the blockchain space, visit our Telegram where we share regular project updates.