DApps Can Potentially Run Anywhere Thanks to TEA Project
The average developer has some decisions to make when they’re looking to bring their dApp to the world of web3 and blockchain. Which blockchain do they target if they want quick uptake of their dApp, and what are the drawbacks of deploying to one blockchain project over another?
In this post, we’ll provide at brief overview of the different kinds of blockchain platforms that an app team could develop on. We’ll place them into different categories (layers) based on characteristics of their architecture. And then we’ll finally turn our attention to how the TEA Project can unlock many of these underlying blockchains through its own layer-2.
An Overview of Existing Blockchain Protocols
Layer-0 protocols are at the most meta-level, having a data layer that allows blockchains to run their own independent chains. Layer-0 protocols can be thought of as tunnels that allow communication between the different platforms on its own ecosystem. In a layer-0 ecosystem, layer-1s function like dApps, and all of these layer-1 “dApps” on a layer-0 are interoperable unlike with traditional layer-1s.
The two biggest layer-0s are Polkadot and Cosmos.
Polkadot is comprised of a relay chain for inter-chain communication as well as parachains for the dApps themselves running on its platform. It’s helpful to think of the Polkadot ecosystem like a mall, and all of the dApps on Polkadot are like stores in the mall. To extend the metaphor, the stores must rent from the mall just like dApps have to lease space on Polkadot through a parachain auction. Each dApp inherits essential infrastructure from Polkadot just as every mall store benefits from the mall’s lighting, HVAC, and security systems.
Cosmos is a bit different as all of its “dApps” have their own application specific blockchains built on Tendermint. This makes them more independent of their parent Cosmos chain.
Layer-1 protocols are like decentralized databases that allow dApps to be built on top of them. The biggest issue with layer-1s is scalability, and how congestion leads to prolonged transaction times as well as escalating gas fees.
There are many layer-1s, and listed below are some of the most popular ones.
- Bitcoin is the original layer-1 blockchain, with smart contracts having since been added with the Lightning network’s layer-2.
- Ethereum has the most users, developers, and TVL of all the layer-1s.
- BNB Chain, Fantom, and Tron are all forks of Ethereum. BNB Chain, technically built on Cosmos, uses centralized validators for scalability and features cheaper gas costs compared to Ethereum.
- Solana is another blockchain that focuses on scalability by sacrificing decentralization.
- Avalanche boasts fast time to finality and EVM compatibility.
- Cardano, arguably one of the more difficult blockchains to build for, recently introduced smart contracts.
- Elrond built their own virtual machine not related to Ethereum.
- Algorand’s relay nodes are permissioned and therefore centralized. Algorand’s chain is primarily built for large enterprises and governments.
A layer-2 solution involves a separate blockchain or network that sits on top of a layer-1 blockchain. Layer-2s typically help a layer-1 scale by offering a space to off-load execution of transactions and dApps that periodically syncs back up with the layer-1. End users get faster execution and lower fees without interfering with the decentralization of the base layer.
Ethereum has attracted many layer-2s because of its modular (as opposed to monolithic) design.
The two main types of layer-2 scaling solutions on Ethereum are optimistic rollups and zk-rollups. Optimistic rollups are faster because they are optimistic: they assume the result is correct, though the results can always be challenged. ZK-rollups include a proof along with the batched transactions sent back to the layer-1.
These are some of the most popular layer-2s:
What TEA Project Brings to Blockchain: A Compute Layer
We want to emphasize that the TEA Project’s layer-2 isn’t limited to only running smart contracts. DApps based on smart contracts can run on TEA’s layer-2, but why limit yourself to a go-kart when you can drive a race car? Developers can deploy full-speed rich applications on TEA, opening up a world of possibilities beyond traditional smart contracts.
The Game-Changer for TEA Project: Portability
Existing blockchains perform admirably in vouchsafing their trusted ledgers. What they have a problem with is…
And TEA’s layer-2 doesn’t rollup its transactions back to the layer-1 it’s running on top of. Stated differently, all of the transactions generated by the dApps running on TEA’s layer-2 will not be recorded anywhere on the underlying layer-1 ledger.
What TEA Project can offer to web3 developers is a gateway through which to run their dApps on potentially any underlying blockchain. Our first target will be Ethereum, and the process will look like this for each blockchain that TEA wants to run its layer-2 on top of:
- The TEA Project development team writes a smart contract specific to the layer-1 that communicates with TEA’s layer-2 nodes.
- The smart contract relays the trustability of the nodes on layer-2 when the nodes perform remote attestation to prove their trustability to each other.
- DApps running on TEA’s layer-2 can run full-stack, full-speed as the ubiquity of trustable nodes means TEA can use non-traditional consensus on its layer-2.
Running DApps on TEA’s Layer-2 is Like Running Web Apps in the Browser
Imagine that a developer wants to have their app run on top of multiple operating systems. Developing for each operating system separately would add huge overhead costs. Development teams could instead deploy as a web app and have their app available to all operating systems via any web browser.
The metaphor of Firefox versus the underlying operating system was one we explored in a recent post:
Our goal with the TEA Project is to make it as easy as possible for developers to onboard to web3 through our development framework. The deploy once, run anywhere paradigm takes the guesswork out of having to first choose the right layer-1 to deploy to while also removing the limitation of having to stick with only smart contracts.
Any questions or comments, feel free to discuss them in our Telegram group.