How does EthStorge help DAPP achieve true decentralization from the front end to the database?

Author: Geek Web3

Abstract:

A decentralized application consists of multiple parts, but currently only the core backend logic runs on Ethereum, while other parts, such as frontend code, are still deployed outside of Ethereum, and there is also a lot of off-chain data. As a result, most DApps cannot fully inherit the security of Ethereum and are far from achieving the ideal state.

There are mainly two reasons for the above issues: first, Ethereum has not provided developers with corresponding frontend standards and tools; second, the cost of storing data on-chain is too high.

To provide a decentralized frontend standard, the EthStorage team proposed the web3:// access protocol, offering developers a complete set of standards and tools to deploy and access frontend code through smart contracts, even resembling a file system. This has now become an official standard of Ethereum.

To reduce the storage costs of on-chain data in Ethereum, the EthStorage team developed the Layer 2 storage protocol EthStorage, utilizing PoRA (Proof of Random Access) and zero-knowledge proofs, greatly reducing storage overhead while inheriting the security of Ethereum Layer 1.

Acknowledgments: Thanks to Faust from Geek Web3, Zhixiong Pan from ChainFeeds, Bruce from LXDAO, Qi Zhou, and Lun Deng from EthStorage for their feedback on this article.

Background and Issues of Decentralized DApps

The vision of Ethereum is to become a world computer, hoping that applications built on it inherit its security. Developers only need to deploy once, and the application will run forever on Ethereum, with no entity able to censor or maliciously manipulate it.

But have current decentralized applications (DApps) achieved the above goal? To answer this question more clearly, we need to deconstruct a DApp and see what parts it includes, then analyze the degree of trustlessness of each part to draw a final conclusion.

Generally, a decentralized DApp will include a frontend interface, backend server, and database. When users access the frontend interface, they load the frontend content through a browser and domain name service. Among them:

· Frontend and Domain Name Service: Most are not deployed and accessed through smart contracts, and the features provided by the blockchain, such as avoiding single points of failure, code immutability, censorship resistance, and community governance, are not reflected in this part of the frontend.

· Backend Server: Some are implemented by smart contracts, but some compute-intensive tasks cannot be fully on-chain.

· Database: Some are implemented by smart contracts, but due to the extremely high costs of on-chain storage, DApps still adopt off-chain storage solutions when the data volume is large.

From the above analysis, we can see that the current decentralized DApps only have some components protected by Ethereum through smart contracts, and the Ethereum system is far from realizing the initial vision of a "decentralized world computer."

At the end of 2023, Vitalik reviewed the development of Ethereum and wrote a widely discussed article titled "Make Ethereum Cypherpunk Again," discussing how the Ethereum community should return to the ideals of cypherpunk. In the article, he summarized the values that the Ethereum and even the broader Web3 community should uphold, mentioning a very important point:

Decentralized applications should minimize reliance on any single entity, so that even if the core developers of the DApp permanently disappear, the application can continue to operate.

It is evident that Vitalik has similar expectations for how decentralized applications should be built. Next, we will analyze the issues faced by each component in decentralized DApps in detail and explore how to improve them.

Frontend and Domain Name Service

Among the components of decentralized applications, the centralization of frontend and domain name services is the most severe. Currently, the vast majority of DApp frontends use centralized servers, allowing project teams to modify frontend code at any time without community governance or time lock restrictions, making the security of this part far from that of smart contracts deployed on Ethereum.

Hackers can invade servers to modify frontend code, and DApp users may lose assets due to using that malicious frontend. This issue repeatedly occurred during the last DeFi Summer. We can't help but ask: why can't the frontend be deployed on Ethereum like the backend, allowing modification actions to take effect only through community governance and time locks?

Additionally, imagine this: If the Uniswap development team stops paying for their frontend server and domain name service one day, how will Uniswap users and LPs use Uniswap?

The vast majority of users do not know how to bypass the frontend to interact with the smart contract. Although Uniswap has attempted to upload its frontend to IPFS, IPFS and Ethereum are different networks, with completely different reliability and trustlessness. It is worth mentioning that the content access speed of IPFS is very slow, and currently, most users are still interacting with the frontend deployed on centralized servers.

Moreover, since the operational entity of the Uniswap frontend is Uniswap Labs, they have increased scrutiny over the token list to comply with regulations, which contrasts with the smart contracts deployed on Ethereum, as no one can arbitrarily modify smart contracts. Therefore, tokens that are censored on the frontend can still be interacted with at the contract level, highlighting the importance of code being on-chain to resist censorship.

Backend Server

Because the EVM can provide a Turing-complete execution environment, most backend logic can be executed on the Ethereum chain. We can say that smart contract-like applications can fully inherit the security of Ethereum. However, due to cost reasons, some compute-intensive tasks cannot be performed directly on-chain.

To address this issue, there is currently a lot of exploration into using ZK or OP methods to offload computation off-chain, with Ethereum only confirming the final results on-chain, thus scaling at the computation level. Some AI-related projects have pushed this method to the extreme, hoping to link super compute-intensive tasks like AI large models with blockchain, which is worth our close attention.

Database

For databases, the EVM originally supports key-value (KV) storage, covering a wide range of use cases, but the core issue is: the cost of on-chain storage is too high.

How high is it? With a gas price of 10 Gwei, storing 1 GB of data on-chain requires over 6200 ETH, exceeding 20 million USD! Clearly, storage costs have become the core issue for the decentralization of databases.

We might wonder if we can use a method similar to the aforementioned computation scaling to scale storage, that is, off-chain storage with on-chain verification of storage effectiveness. We will elaborate on this idea later.

After analyzing the components of DApps mentioned above, we find that only by ensuring that each part of the DApp is sufficiently secure and trustless can it truly become a decentralized DApp as a trustless whole. As the operating and hosting platform for DApps, Ethereum needs to provide developers with corresponding solutions to nurture an application ecosystem that aligns with Ethereum's vision.

Trustlessness Solutions for DApps

Regarding how to deploy and access DApps entirely based on Ethereum, the EthStorage team has proposed two solutions:

• web3:// access protocol: solving how to use smart contracts to deploy and access frontend code, even resembling a file system.
• EthStorage Layer 2 storage protocol: significantly reducing storage costs while inheriting the security of Ethereum.

web3:// Access Protocol

web3:// can be understood as a decentralized version of http://. Similar to how the URL of http specifies a server IP address or domain name to access centralized resources, the URL of web3 needs to specify a smart contract address or ENS domain name to access resources stored on it.

We can deploy an entire website frontend to a smart contract and access it via web3://! Let's compare the differences between the two:

Currently, web3:// has become the official standard of Ethereum (ERC-4804). If you want to learn more about the content of the web3:// access protocol, you can visit its official website. To better manage files in smart contracts, we proposed ERC-5018, which simulates a file system interface in smart contracts, allowing packaged frontend code folders to be uploaded to a smart contract via ethfs-cli and accessed through web3://.

If you're interested, you can follow the tutorial to complete a simple decentralized application deployment and access.

With the web3:// access protocol, we can truly endow the DApp frontend with the property of "Code is law." For developers, once deployed, this frontend will execute permanently. Imagine if Uniswap Labs also deployed its frontend to Ethereum; even if the team wanted to censor and restrict users at the frontend level, they could not prevent people from using the frontend deployed on Ethereum.

Of course, after addressing the feasibility issue, we also realize that the cost of storing large amounts of data on-chain can be very high, causing developers to face challenges when deploying frontends on-chain. We further developed the EthStorage Layer 2 storage protocol, which significantly reduces storage overhead while inheriting the security of Ethereum.

EthStorage Layer 2 Storage Protocol

The EthStorage protocol consists of smart contracts deployed on Ethereum and storage nodes in the Layer 2 network, where the smart contract provides key-value storage, while the Layer 2 storage nodes are responsible for storing the data itself.

Users upload the data to be stored to Ethereum via EIP-4844's BLOB, and the EthStorage smart contract only records the hash of the data within the BLOB, effectively reducing storage costs.

At the same time, the Layer 2 storage nodes will download the corresponding BLOB data to local disks, using PoRA (Proof of Random Access) and ZK to submit storage proofs to the contract on Ethereum for verification. This contract needs to confirm whether the ZK proof uploaded by the storage node matches the previously recorded Blob hash, thereby confirming that the storage node in the Layer 2 network indeed holds the data.

The specific process is as follows:

For developers, the interfaces for uploading and retrieving data are very simple:

Application developers can directly use the contract interfaces provided by EthStorage to read and write large amounts of data, with writing costs approximately one-thousandth of directly storing data on-chain. Therefore, EthStorage not only supports on-chain deployment of frontends but also provides a lower-cost solution for broader key-value storage database operations.

Currently, EthStorage has received official grants from Ethereum and has deployed a public testnet on Sepolia. Everyone is welcome to join.

Conclusion and Outlook

Most important components of DApps, such as frontends and databases, are not deployed on Ethereum, failing to inherit Ethereum's security, resulting in the application as a whole being unable to achieve permanent execution, censorship resistance, and governance.

EthStorage proposes two solutions to address this issue: the web3:// access protocol solves the problem of deploying and accessing frontends using smart contracts; the EthStorage Layer 2 storage protocol addresses the issue of high storage costs.

To realize Ethereum's original vision, we believe it will evolve into a decentralized web server, where decentralized applications in the ecosystem will deploy all their components on Ethereum, whether backend code, frontend, or data. Once deployed, the code can run permanently, and the data can be accessed permanently, becoming a truly Unstoppable DApp.

The EthStorage public testnet is currently conducting its second incentive activity. Interested community members can follow the guide to complete their first Unstoppable DApp deployment and access!