The TEA Project’s Independent Layers: No Roll-ups!
When we tell people that the TEA Project has two different layers, they usually assume that we have a roll-up feature to connect the two. A roll-up is typical in chains like Ethereum, where a faster layer-2 with cheaper transactions will send transactions back to the layer-1. While that makes sense for a chain like Ethereum with throughput and transaction fee issues, this isn’t needed in the TEA Project.
Ethereum’s need for a roll-up function stems from limitations in its consensus mechanism for verifying transactions.
Although its TPS will be significantly improved when Ethereum 2.0’s consensus layer is finally released, Ethereum is currently limited to approximately 10–15 transactions per second. The most practical way to get around these TPS limitations is to bundle (“roll-up”) transactions for off-chain processing. The layer-1 blockchain only needs to confirm a single rolled-up transaction reported back from the layer-2 instead of all the individual transactions. One of the most popular of these scaling solutions is the Ethereum Virtual Machine compatible sidechain Arbitrum.
A Short Primer on Arbitrum
Arbitrum has gained popularity as an ETH scaling solution that can handle orders of magnitude more transactions (~40,000 TPS) than Ethereum. ETH dApp developers can simply recompile their code to run on Arbitrum. In practical use, a user’s dApp interactions can happen entirely within Arbitrum and thus off-chain from Ethereum. Arbitrum batches together transactions from the parent chain and settles them on its proprietary sidechain before feeding them back to Ethereum’s blockchain ledger.
- Arbitrum gets a transaction in its queue (“inbox”).
- It processes the transaction on its sidechain as part of a batch using an optimistic roll-up.
- The batches are reported back to Ethereum.
- A transaction receipt is generated.
The TEA Project’s Two Layers Are Independent
The TEA Project has two separate layers but doesn’t use any roll-ups. That’s because there are no TPS limitations to overcome in our blockchain design, nor are there any onerous txn fees associated with using our dApps.
The TEA Project’s layer-1 doesn’t process any of the dApps’ logic (called TApps in the TEA Project). Besides running the TEA Project’s token economy, the layer-1 is mainly concerned with establishing the trustability of the nodes running on layer-2. This is a point of departure with a project like Arbitrum with only implicit trust built into its system. Arbitrum uses optimistic roll-ups that assume all contained transactions are valid in the interest of speed.
Trust is one of the main pillars of the TEA Project’s foundation. As a user of the platform, we ensure that you don’t need to hope that there are no bad actors as TEA takes care of the trust issues. The TEA Project’s philosophy is that if the execution environment, code, and input data are trustable, then the execution result can also be trusted. The TEA Project ensures that the computation is based on the expected code and data.
As you can see, there’s nothing to “roll up” between TEA’s layer-1 and layer-2. The TEA Project’s layer-2 is where the actual business logic of a TApp is executed. App code interacts with decrypted user data within the protected enclaves of layer-2 mining nodes that have been deemed tamper-free through remote attestation. All app execution on layer-2 happens without any gas transaction fees and is entirely separate from the operations of TEA’s layer-1.
The TEA Project’s layer-2 has theoretically unlimited TPS because it uses time to order transactions.
TEA’s use of Proof of Time (PoT) as a root of trust allows for a unique consensus mechanism that maximizes scalability while maintaining data consistency. Just as Google Cloud and AWS don’t advertise TPS limitations, neither does the TEA Project. We see these cloud servers as our competition, not the smart contract-based blockchains with their inherent TPS limitations. Except with the TEA Project, everyone will be able to run at cloud computing speeds while still enjoying a decentralized tech stack that protects user privacy.
