
From Frontend to Database: How EthStorage Helps DApps Achieve True Trustlessness?
TechFlow Selected TechFlow Selected

From Frontend to Database: How EthStorage Helps DApps Achieve True Trustlessness?
How to host a DAPP's frontend, backend, and data entirely on Ethereum? EthStorage proposes two major solutions.
Author: EthStorage Team
Abstract
-
A decentralized application (dApp) consists of multiple components, but currently only the core backend logic runs on Ethereum. Other parts, such as frontend code, are still deployed off-chain, along with significant amounts of data not stored on the blockchain. As a result, most dApps cannot fully inherit Ethereum's security and remain far from the ideal state.
-
Two main factors cause this issue: first, Ethereum lacks standardized tools for developers to deploy frontends; second, on-chain data storage costs are prohibitively high.
-
To establish a decentralized frontend standard, the EthStorage team introduced the web3:// access protocol, providing developers with a complete set of standards and tools to deploy and access frontend code—and even file-like systems—via smart contracts. It has now become an official Ethereum standard.
-
To reduce on-chain data storage costs, the EthStorage team developed the Layer 2 storage protocol EthStorage, leveraging Proof of Random Access (PoRA) and zero-knowledge proofs to drastically lower storage expenses while inheriting Ethereum’s Layer 1 security.
Acknowledgments: We thank Faust from Geek Web3, Zhixiong Pan from ChainFeeds, Bruce from LXDAO, and Qi Zhou, Lun Deng from EthStorage for their feedback on this article.
Background and Challenges of Decentralized dApps
Ethereum's vision is to become a world computer, where applications built atop it inherit its security. Developers deploy once, and the application runs forever on Ethereum, immune to censorship or malicious manipulation by any entity.
But have current decentralized applications (dApps) achieved this goal? To answer clearly, we need to deconstruct a dApp into its components and analyze each part's degree of trustlessness before drawing conclusions.
Typically, a decentralized dApp includes a frontend interface, backend server, and database. When users access the frontend, their browsers use domain services to load content. Specifically:
-
Frontend and Domain Services: Most are not deployed or accessed via smart contracts, so blockchain features like resistance to single points of failure, immutability, anti-censorship, and community governance do not apply here.
-
Backend Server: Partially implemented via smart contracts; compute-intensive tasks often cannot be fully executed on-chain.
-
Database: Partially handled by smart contracts, but due to high on-chain storage costs, dApps typically rely on off-chain storage when dealing with large volumes of data.

From the above analysis, it is evident that only some components of today’s decentralized dApps gain protection through smart contracts on Ethereum. The ecosystem remains far from realizing the original vision of a "decentralized world computer."
At the end of 2023, Vitalik reflected on Ethereum’s development in a widely discussed article titled “Make Ethereum Cypherpunk Again,” calling for the community to return to cypherpunk principles. He outlined key values the Ethereum and broader Web3 communities should uphold, emphasizing one crucial point:
Decentralized applications should minimize reliance on any single entity, ensuring they continue functioning even if the core developers disappear permanently.

This shows Vitalik shares similar expectations for how dApps should be built. Next, we will analyze in detail the challenges faced by each component of decentralized dApps and explore ways to improve them.
Frontend and Domain Services
Among the components of a decentralized application, the frontend and domain services exhibit the highest degree of centralization. Most dApp frontends run on centralized servers, allowing project teams to modify frontend code at will—without community governance or time-lock restrictions. This undermines security compared to smart contracts deployed on Ethereum.
Hackers can compromise these servers and alter frontend code, causing users to lose assets through malicious interfaces. This repeatedly occurred during the last DeFi Summer. We must ask: Why can’t the frontend be deployed on Ethereum like the backend, requiring community governance and time locks for changes?

Also consider: If Uniswap’s development team one day stops paying for their frontend server and domain service, how would Uniswap users and liquidity providers continue using the platform?
Most users don’t know how to interact directly with smart contracts, bypassing the frontend. Although Uniswap has attempted to upload its frontend to IPFS, IPFS operates on a separate network with different reliability and trust assumptions than Ethereum. Notably, IPFS content loads slowly, and most users still interact with Uniswap’s frontend hosted on centralized servers.
Moreover, because Uniswap Labs controls the frontend and must comply with regulations, they have added censorship to the token list, which contrasts sharply with their immutable smart contracts on Ethereum—no one can arbitrarily change those. Thus, tokens censored on the frontend can still be accessed at the contract level, highlighting the importance of deploying code on-chain to resist censorship.
Backend Server
Since the EVM provides a Turing-complete execution environment, most backend logic can be executed on-chain. We can say smart contract-based applications fully inherit Ethereum’s security. However, due to cost constraints, compute-intensive tasks cannot be performed directly on-chain.
To address this, extensive research focuses on using ZK or optimistic rollups to offload computation off-chain while only finalizing results on Ethereum, thereby scaling computational capacity. Some AI-related projects push this approach further, aiming to integrate super compute-intensive AI models with blockchains—a trend worth close attention.
Database
For databases, the EVM natively supports key-value (KV) storage, covering many use cases. But the core problem remains: on-chain storage is extremely expensive.
How expensive? At a gas price of 10 Gwei, storing 1GB of data on-chain requires over 6,200 ETH—more than $20 million! Clearly, storage cost is the primary barrier to decentralizing databases.
We might wonder: Can we apply a method similar to computational scaling—store data off-chain and verify storage validity on-chain? We’ll expand on this idea shortly.
After analyzing the components of dApps discussed above, we conclude that only when every part of a dApp is sufficiently secure and trustless can the application as a whole truly qualify as decentralized. For Ethereum to serve as a true platform for hosting dApps, it must provide developers with comprehensive solutions to foster an ecosystem aligned with its original vision.
Trustless Solutions for dApps
To enable dApps to be fully deployed and accessed based on Ethereum, the EthStorage team proposes two solutions:
-
web3:// access protocol: Solves the problem of deploying and accessing frontend code—or even file-like systems—via smart contracts.
-
EthStorage Layer 2 storage protocol: Inherits Ethereum’s security while drastically reducing storage costs.
web3:// Access Protocol
The web3:// protocol can be understood as a decentralized version of http://. While HTTP URLs access centralized resources via server IP addresses or domain names, web3 URLs specify a smart contract address or ENS domain to retrieve resources stored on-chain.
We can deploy an entire website’s frontend within a smart contract and access it via web3://! Here’s a comparison:

Currently, web3:// has become an official Ethereum standard (ERC-4804). For more details about the web3:// access protocol, visit its official website. To better manage files within smart contracts, we proposed ERC-5018, which simulates a file system interface inside smart contracts. Using ethfs-cli, developers can upload packaged frontend folders to a contract and access the site via web3://.
Interested readers can follow the tutorial to deploy and access a simple decentralized application.
With the web3:// access protocol, dApp frontends finally achieve the property of “Code is law.” Once deployed, the frontend runs permanently. Imagine if Uniswap Labs also deployed their frontend on Ethereum—then even if the team wanted to censor or restrict users via the frontend, people could still use the uncensorable version running on-chain.
Of course, after solving feasibility, we recognize that storing large amounts of data on-chain remains costly, posing challenges for developers. That’s why we further developed the EthStorage Layer 2 storage protocol, which inherits Ethereum’s security while dramatically lowering storage costs.
EthStorage Layer 2 Storage Protocol
The EthStorage protocol consists of smart contracts deployed on Ethereum and storage nodes operating in a Layer 2 network. The smart contract provides key-value storage functionality, while Layer 2 storage nodes store the actual data.
Users upload data via EIP-4844 BLOBs to Ethereum. The EthStorage smart contract records only the hash of the data within the BLOB, effectively minimizing storage costs.
Meanwhile, Layer 2 storage nodes download the corresponding BLOB data to local disks and generate storage proofs using Proof of Random Access (PoRA) and zero-knowledge (ZK) proofs, which are submitted to the Ethereum contract for verification. The contract uses previously recorded BLOB hashes to confirm whether the uploaded ZK proofs match, thus verifying that Layer 2 nodes genuinely store the data.
The process works as follows:

For developers, the data upload and retrieval interfaces are straightforward:

Developers can directly use EthStorage’s contract interface to read and write large datasets, with write costs approximately one-thousandth of direct on-chain storage. Therefore, EthStorage not only enables on-chain frontend deployment but also offers a low-cost solution for general key-value database operations.
Currently, EthStorage has received grants from the Ethereum Foundation and has deployed a public testnet on Sepolia. Community members are welcome to join.
Conclusion and Outlook
Critical components of most dApps—such as frontends and databases—are not deployed on Ethereum, so they fail to inherit Ethereum’s security. As a result, applications cannot operate permanently, resist censorship, or support decentralized governance as a whole.
EthStorage proposes two solutions: the web3:// access protocol addresses the deployment and access of frontends via smart contracts; the EthStorage Layer 2 storage protocol solves the problem of excessive storage costs.
To realize Ethereum’s original vision, we believe it will evolve into a decentralized web server, where all components of dApps—including backend logic, frontend, and data—are deployed on Ethereum. Once deployed, code runs forever and data remains perpetually accessible, forming a true Unstoppable Dapp.
The EthStorage public testnet is currently running its second incentive campaign. Interested community members can follow the Guide to deploy and access your first Unstoppable Dapp!
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News














