How DApps Reliance on Web 2.0 Can Cost Them Dearly

Web3 currently looks more like a hybrid ecosystem conjoined with parts from web 2.0 that we could term “web 2.5.” This current hybrid “web 2.5” model leaves dApps open to attack through the security problems of web 2.0 that Web3 is trying to leave behind. Let’s take a quick look at what makes a typical dApp a hybrid “web 2.5” app and some of the dire consequences for decentralized apps still dependent on the traditional cloud architecture.

DApp + Hosted Front-end = Hybrid DApp

To see what a hybrid “web 2.5” dApp looks like, let’s examine how a typical Ethereum dApp interacts with its underlying tech stack. The Ethereum dApp uses an application binary interface (ABI) for the front-end to interact with the underlying smart contract that is the core of the app. The smart contract backend coupled with a front-end user interface that’s often hosted suggests a hybrid application rather than a purely decentralized dApp. The code to run the dApp client front-end is hosted in the cloud, making it open to possible security threats. The dApp’s smart contract may very well be audited but its front-end would still be open to the type of hacks that plague traditional cloud servers.

Examples of DApps Getting Hacked Through Web 2.0

• BadgerDAO hacked for 2.1k BTC + 151 ETH among other assets through an insecure Cloudflare API key:

“The thing is that the attacker didn’t hack the protocol itself — they targeted Badger users. By integrating malicious UI into the website, the attacker was able to avoid triggering the security protocol because the smart contract saw them as a regular user who wasn’t doing anything wrong.” — Serhii Androsiuk, Hackless CEO.

And because BadgerDAO’s smart contract wasn’t exploited, any victims couldn’t put a claim in if they had crypto insurance (Nexus Mutual).

• CityDAO was hacked through their reliance on Discord for user announcements.

IPFS: A Solution for Decentralizing the Front-end

There are possibilities for Ethereum developers to use Web3 providers like IPFS or Skynet to host their front-ends even if these solutions are not currently widespread. But the growth of blockchain-based name resolution services like ENS will help pave a decentralized path for the front-end as Web3’s network effect grows. But if the front-end can eventually become decentralized, what about the limitations with the smart contract layer itself? That’s where the TEA Project can save developer’s by providing them a familiar tech stack to deploy to.

TEA Project Puts It All Together for Web3 Developers

The default 3-tier architecture is what developers are used to when deploying apps to the cloud.

TEA allows developers to deploy to the blockchain as if it were a cloud computing stack. One of the real innovations that TEA presents is how straightforward it is for developers to port their existing apps to Web3 as we use the same 3-tier architecture.

• The front end for TEA decentralized applications uses IPFS.
• The server layer handles dev code compiled to WASM, meaning developers can use their existing programming languages and set WASM as the output target. Dev code is encrypted and only decrypted to run in the TPM-protected enclaves of the network’s layer-2 miners (type-B CML mining nodes).
• The database layer is handled according to the developer’s needs — NoSQL data is sent to IPFS as governed by type-B CML mining nodes, while relationship data is stored in GlueSQL as governed by type-A CML mining nodes.

We look forward to making the TEA Project the preferred entrance for developers looking to enter Web3. Find out more about the infrastructure we’re building for Web3 at Teaproject.org.