· A decentralized application consists of multiple parts, but currently only the core backend logic runs on Ethereum, and other parts such as front-end code are still deployed outside Ethereum. At the same time, it also contains a lot of data that is not on the chain, so most DAPPs cannot fully inherit the security of Ethereum and are far from the ideal state.
· There are two main reasons for the above problems: one is that Ethereum does not provide developers with corresponding front-end standards and tools, and the other is that the cost of storing data on the chain is too high.
· In order to provide a decentralized front-end standard, the EthStorage team proposed the web3:// access protocol, providing developers with a complete set of standards and tools for deploying and accessing front-end code through smart contracts, and even file systems, which has now become the official standard of Ethereum.
· In order to reduce the storage cost of data on the Ethereum chain, the EthStorage team developed the second-layer storage protocol EthStorage, which uses PoRA (Proof of Random Access) and zero-knowledge proof to greatly reduce storage overhead while inheriting the security of Ethereum’s first layer.
Acknowledgments: Thanks to Faust from GeekWeb3, Zhixiong Pan from ChainFeeds, Bruce from LXDAO, Qi Zhou, and Lun Deng from EthStorage for their feedback on this article.
Ethereum’s vision is to become the world’s computer, and applications built on it are expected to inherit its security. Developers only need to deploy it once, and the application will run on Ethereum forever, and no entity can censor it or maliciously manipulate it.
But have the current decentralized applications DAPP achieved the above goals? In order to answer this question more clearly, we need to deconstruct a DAPP application to see what parts it includes, and then analyze the degree of trustlessness of each part to draw the final conclusion.
Generally speaking, a decentralized DAPP will include a front-end interface, a back-end server, and a database. When users access the front-end interface, they will load the front-end content through a browser and a domain name service. Among them:
· Front-end and domain name services:Most of them are not deployed and accessed through smart contracts. The features provided by the blockchain, such as avoiding single point failures, code immutability, anti-censorship, and community governance, are not reflected in this part of the front end.
· Back-end servers: Partly implemented by smart contracts, some computationally intensive tasks cannot be fully on-chain.
· Database: Partially implemented by smart contracts. Due to the high storage costs on the chain, DAPP still uses off-chain storage solutions when the amount of data is large.
Through the above analysis, we can see that only some components of the current decentralized DAPP have been protected by Ethereum through smart contracts, and the Ethereum system is far from realizing the original vision of “decentralized world computer”.
At the end of 2023, Vitalik reviewed the development of Ethereum and wrote a highly responsive article “Make Ethereum Cypherpunk Again”, discussing how the Ethereum community should return to the concept of cypherpunk. In the article, he summarized the values that Ethereum and even the larger Web3 community should adhere to, and mentioned a very important point:
Decentralized applications should minimize their dependence on any single entity, so that even if the core developers of DAPP disappear forever, the application can continue to operate.
It can be seen that Vitalik has similar expectations for how decentralized applications should be built. Next, we will analyze in detail the problems faced by each component in decentralized DAPP and explore how to improve them.
Among the several components of decentralized applications, the front-end and domain name services are the most centralized. Currently, most dApp front-ends use centralized servers. Project owners can modify the front-end code at any time without community governance or time locks. The security of this part is far from that of smart contracts deployed on Ethereum.
Hackers can hack into the server to modify the front-end code, and dApp users will lose assets because of using the malicious front-end. This problem has repeatedly appeared in the last DeFi Summer, and we can’t help but ask: Why can’t the front-end be deployed on Ethereum like the back-end, so that the modification behavior can only take effect through community governance and time locks?
Also, please imagine, If the Uniswap development team no longer pays for their front-end servers and domain name services one day, how will Uniswap users and LPs use Uniswap?
Most users do not know how to bypass the front-end and interact with smart contracts. Although Uniswap has tried to upload its front-end to IPFS, IPFS and Ethereum are different networks, and their reliability and trustlessness are completely different. It is worth mentioning that the access speed of IPFS content is very slow, and most users are still interacting with Uniswap’s front-end deployed on centralized servers.
In addition, because the operator of Uniswap’s front-end is Uniswap Labs, they have increased the review of the token list in order to cater to supervision, which is in contrast to the smart contracts they deployed on Ethereum, because no one can modify the smart contracts at will. Therefore, the tokens that are reviewed at the front end can still be interacted with at the contract level, which shows the importance of code on-chain to resist censorship.
Because EVM can provide a Turing-complete execution environment, most of the backend logic can be executed on the Ethereum chain. We can say that smart contract applications can fully inherit the security of Ethereum. It is just because of cost reasons that some computation-intensive tasks cannot be performed directly on the chain.
To address this issue, the current exploration is to use ZK or OP to transfer the calculation to the off-chain, and the Ethereum chain only confirms the calculation results, so as to expand the capacity at the computing level. Some AI-related projects have pushed this method to the extreme, hoping to link super-computation-intensive tasks such as large AI models with blockchains, which is worth our close attention.
For databases, EVM originally supports key-value pairs/KV storage (Key Value Store), which can cover a wide range of usage scenarios, but the core problem is: the cost of on-chain storage is too high.
How expensive is it? When the Gas Price is 10Gwei, it takes more than 6,200 ETH to store 1GB of data on the chain, which is more than 20 million US dollars!Obviously, storage costs have become the core issue of database decentralization.
We may wonder if we can use a similar method to the above-mentioned computing expansion to expand storage, that is, off-chain storage and on-chain verification of storage effects. We will elaborate on this idea later.
After analyzing the DAPP components mentioned above, we found that only when each part of DAPP is secure and trustless enough, can it truly become a decentralized DAPP as a trustless whole. Ethereum, as the operation and hosting platform of dApp, needs to provide developers with corresponding solutions to breed an application ecosystem that meets the vision of Ethereum.
Around how to make DAPP completely based on Ethereum to deploy and access, the EthStorage team proposed two solutions:
web3:// Access Protocol
web3:// can be understood as a decentralized version of http://. Similar to the http URL that accesses centralized resources by specifying a server IP address or domain name, the web3 URL needs to specify a smart contract address or ENS domain name to access the resources stored on it.
We can deploy the entire front end of a website into a smart contract and access it through web3://! You can compare the difference 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. In order to better manage files in smart contracts, we proposed ERC-5018, which simulates a set of file system interfaces in smart contracts, so that you can upload the packaged front-end code folder to a smart contract through ethfs-cli, and access this website through web3://.
If you are interested, you can follow the tutorial to complete a simple decentralized application deployment and access.
With the web3:// access protocol, we can truly make the dApp front-end have the attribute of “Code is law”. For developers, once deployed, this front-end will be executed forever. Imagine if Uniswap labs also deployed its front-end to Ethereum, then even if the team wanted to censor and restrict users at the front-end level, it would not be able to prevent people from using its front-end deployed on Ethereum.
Of course, after solving the feasibility problem, we also realized that the cost of storing large amounts of data on the chain would be very high, which caused developers to face troubles when deploying the front-end on the chain. We further developed the EthStorage second-layer storage protocol, which greatly reduces storage overhead while inheriting the security of Ethereum.
The EthStorage protocol consists of smart contracts deployed on Ethereum and storage nodes in the Layer2 network, where smart contracts provide key-value storage, while the second-layer storage nodes are responsible for storing the data itself.
Users upload the data to be stored to Ethereum through the BLOB of EIP-4844. The EthStorage smart contract only records the hash of the data in the BLOB, thereby effectively reducing storage costs.
At the same time, the second-layer storage node will download the corresponding BLOB data to the local disk, and use PoRA (Proof of Random Access) and ZK to submit the storage proof to the contract on Ethereum for verification.The contract needs to use the previously recorded Blob hash to confirm whether the ZK proof uploaded by the storage node matches, so as to confirm that the storage node in the second-layer network really stores this data.
The specific process is as follows:
For developers, the interface for uploading and obtaining data is very simple:
Application developers can directly read and write large blocks of data through the contract interface provided by EthStorage, and the writing cost is approximately one thousandth of that of directly storing data on the chain.Therefore, EthStorage not only supports on-chain deployment of the front end, but also provides a lower-cost solution for a wider range of key-value storage database operations.
Currently, EthStorage has obtained the official Grants of Ethereum and has deployed a public testnet on Sepolia. Everyone is welcome to join.
Most important components of DAPP, such as the front-end and database, are not deployed on Ethereum and cannot inherit the security of Ethereum, resulting in the inability of the application as a whole to be permanently executed, censorship-resistant, and governable.
EthStorage has proposed two solutions to this problem: the web3:// access protocol solves the problem of using smart contracts to deploy and access the front-end; the EthStorage second-layer storage protocol solves the problem of high storage costs.
In order to realize the original vision of Ethereum, we believe that it will evolve into a decentralized web server, and the decentralized applications in the ecosystem will deploy all their components on Ethereum. Whether it is the back-end code, the front-end or the data, once deployed, the code can run permanently and the data can be permanently accessed, becoming a truly unstoppable Dapp.
The EthStorage public testnet is currently conducting its second incentive campaign. Interested community members can follow the Guide to complete their first Unstoppable Dapp deployment and access!
This article is reproduced from [Geek Web3], the copyright belongs to the original author [EthStorage Team], if you have any objection to the reprint, please contact Gate Learn Team ), the team will handle it as soon as possible according to relevant procedures.
Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.
Other language versions of the article are translated by the Gate Learn team and are not mentioned in Gate.io), the translated article may not be reproduced, distributed or plagiarized.
· A decentralized application consists of multiple parts, but currently only the core backend logic runs on Ethereum, and other parts such as front-end code are still deployed outside Ethereum. At the same time, it also contains a lot of data that is not on the chain, so most DAPPs cannot fully inherit the security of Ethereum and are far from the ideal state.
· There are two main reasons for the above problems: one is that Ethereum does not provide developers with corresponding front-end standards and tools, and the other is that the cost of storing data on the chain is too high.
· In order to provide a decentralized front-end standard, the EthStorage team proposed the web3:// access protocol, providing developers with a complete set of standards and tools for deploying and accessing front-end code through smart contracts, and even file systems, which has now become the official standard of Ethereum.
· In order to reduce the storage cost of data on the Ethereum chain, the EthStorage team developed the second-layer storage protocol EthStorage, which uses PoRA (Proof of Random Access) and zero-knowledge proof to greatly reduce storage overhead while inheriting the security of Ethereum’s first layer.
Acknowledgments: Thanks to Faust from GeekWeb3, Zhixiong Pan from ChainFeeds, Bruce from LXDAO, Qi Zhou, and Lun Deng from EthStorage for their feedback on this article.
Ethereum’s vision is to become the world’s computer, and applications built on it are expected to inherit its security. Developers only need to deploy it once, and the application will run on Ethereum forever, and no entity can censor it or maliciously manipulate it.
But have the current decentralized applications DAPP achieved the above goals? In order to answer this question more clearly, we need to deconstruct a DAPP application to see what parts it includes, and then analyze the degree of trustlessness of each part to draw the final conclusion.
Generally speaking, a decentralized DAPP will include a front-end interface, a back-end server, and a database. When users access the front-end interface, they will load the front-end content through a browser and a domain name service. Among them:
· Front-end and domain name services:Most of them are not deployed and accessed through smart contracts. The features provided by the blockchain, such as avoiding single point failures, code immutability, anti-censorship, and community governance, are not reflected in this part of the front end.
· Back-end servers: Partly implemented by smart contracts, some computationally intensive tasks cannot be fully on-chain.
· Database: Partially implemented by smart contracts. Due to the high storage costs on the chain, DAPP still uses off-chain storage solutions when the amount of data is large.
Through the above analysis, we can see that only some components of the current decentralized DAPP have been protected by Ethereum through smart contracts, and the Ethereum system is far from realizing the original vision of “decentralized world computer”.
At the end of 2023, Vitalik reviewed the development of Ethereum and wrote a highly responsive article “Make Ethereum Cypherpunk Again”, discussing how the Ethereum community should return to the concept of cypherpunk. In the article, he summarized the values that Ethereum and even the larger Web3 community should adhere to, and mentioned a very important point:
Decentralized applications should minimize their dependence on any single entity, so that even if the core developers of DAPP disappear forever, the application can continue to operate.
It can be seen that Vitalik has similar expectations for how decentralized applications should be built. Next, we will analyze in detail the problems faced by each component in decentralized DAPP and explore how to improve them.
Among the several components of decentralized applications, the front-end and domain name services are the most centralized. Currently, most dApp front-ends use centralized servers. Project owners can modify the front-end code at any time without community governance or time locks. The security of this part is far from that of smart contracts deployed on Ethereum.
Hackers can hack into the server to modify the front-end code, and dApp users will lose assets because of using the malicious front-end. This problem has repeatedly appeared in the last DeFi Summer, and we can’t help but ask: Why can’t the front-end be deployed on Ethereum like the back-end, so that the modification behavior can only take effect through community governance and time locks?
Also, please imagine, If the Uniswap development team no longer pays for their front-end servers and domain name services one day, how will Uniswap users and LPs use Uniswap?
Most users do not know how to bypass the front-end and interact with smart contracts. Although Uniswap has tried to upload its front-end to IPFS, IPFS and Ethereum are different networks, and their reliability and trustlessness are completely different. It is worth mentioning that the access speed of IPFS content is very slow, and most users are still interacting with Uniswap’s front-end deployed on centralized servers.
In addition, because the operator of Uniswap’s front-end is Uniswap Labs, they have increased the review of the token list in order to cater to supervision, which is in contrast to the smart contracts they deployed on Ethereum, because no one can modify the smart contracts at will. Therefore, the tokens that are reviewed at the front end can still be interacted with at the contract level, which shows the importance of code on-chain to resist censorship.
Because EVM can provide a Turing-complete execution environment, most of the backend logic can be executed on the Ethereum chain. We can say that smart contract applications can fully inherit the security of Ethereum. It is just because of cost reasons that some computation-intensive tasks cannot be performed directly on the chain.
To address this issue, the current exploration is to use ZK or OP to transfer the calculation to the off-chain, and the Ethereum chain only confirms the calculation results, so as to expand the capacity at the computing level. Some AI-related projects have pushed this method to the extreme, hoping to link super-computation-intensive tasks such as large AI models with blockchains, which is worth our close attention.
For databases, EVM originally supports key-value pairs/KV storage (Key Value Store), which can cover a wide range of usage scenarios, but the core problem is: the cost of on-chain storage is too high.
How expensive is it? When the Gas Price is 10Gwei, it takes more than 6,200 ETH to store 1GB of data on the chain, which is more than 20 million US dollars!Obviously, storage costs have become the core issue of database decentralization.
We may wonder if we can use a similar method to the above-mentioned computing expansion to expand storage, that is, off-chain storage and on-chain verification of storage effects. We will elaborate on this idea later.
After analyzing the DAPP components mentioned above, we found that only when each part of DAPP is secure and trustless enough, can it truly become a decentralized DAPP as a trustless whole. Ethereum, as the operation and hosting platform of dApp, needs to provide developers with corresponding solutions to breed an application ecosystem that meets the vision of Ethereum.
Around how to make DAPP completely based on Ethereum to deploy and access, the EthStorage team proposed two solutions:
web3:// Access Protocol
web3:// can be understood as a decentralized version of http://. Similar to the http URL that accesses centralized resources by specifying a server IP address or domain name, the web3 URL needs to specify a smart contract address or ENS domain name to access the resources stored on it.
We can deploy the entire front end of a website into a smart contract and access it through web3://! You can compare the difference 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. In order to better manage files in smart contracts, we proposed ERC-5018, which simulates a set of file system interfaces in smart contracts, so that you can upload the packaged front-end code folder to a smart contract through ethfs-cli, and access this website through web3://.
If you are interested, you can follow the tutorial to complete a simple decentralized application deployment and access.
With the web3:// access protocol, we can truly make the dApp front-end have the attribute of “Code is law”. For developers, once deployed, this front-end will be executed forever. Imagine if Uniswap labs also deployed its front-end to Ethereum, then even if the team wanted to censor and restrict users at the front-end level, it would not be able to prevent people from using its front-end deployed on Ethereum.
Of course, after solving the feasibility problem, we also realized that the cost of storing large amounts of data on the chain would be very high, which caused developers to face troubles when deploying the front-end on the chain. We further developed the EthStorage second-layer storage protocol, which greatly reduces storage overhead while inheriting the security of Ethereum.
The EthStorage protocol consists of smart contracts deployed on Ethereum and storage nodes in the Layer2 network, where smart contracts provide key-value storage, while the second-layer storage nodes are responsible for storing the data itself.
Users upload the data to be stored to Ethereum through the BLOB of EIP-4844. The EthStorage smart contract only records the hash of the data in the BLOB, thereby effectively reducing storage costs.
At the same time, the second-layer storage node will download the corresponding BLOB data to the local disk, and use PoRA (Proof of Random Access) and ZK to submit the storage proof to the contract on Ethereum for verification.The contract needs to use the previously recorded Blob hash to confirm whether the ZK proof uploaded by the storage node matches, so as to confirm that the storage node in the second-layer network really stores this data.
The specific process is as follows:
For developers, the interface for uploading and obtaining data is very simple:
Application developers can directly read and write large blocks of data through the contract interface provided by EthStorage, and the writing cost is approximately one thousandth of that of directly storing data on the chain.Therefore, EthStorage not only supports on-chain deployment of the front end, but also provides a lower-cost solution for a wider range of key-value storage database operations.
Currently, EthStorage has obtained the official Grants of Ethereum and has deployed a public testnet on Sepolia. Everyone is welcome to join.
Most important components of DAPP, such as the front-end and database, are not deployed on Ethereum and cannot inherit the security of Ethereum, resulting in the inability of the application as a whole to be permanently executed, censorship-resistant, and governable.
EthStorage has proposed two solutions to this problem: the web3:// access protocol solves the problem of using smart contracts to deploy and access the front-end; the EthStorage second-layer storage protocol solves the problem of high storage costs.
In order to realize the original vision of Ethereum, we believe that it will evolve into a decentralized web server, and the decentralized applications in the ecosystem will deploy all their components on Ethereum. Whether it is the back-end code, the front-end or the data, once deployed, the code can run permanently and the data can be permanently accessed, becoming a truly unstoppable Dapp.
The EthStorage public testnet is currently conducting its second incentive campaign. Interested community members can follow the Guide to complete their first Unstoppable Dapp deployment and access!
This article is reproduced from [Geek Web3], the copyright belongs to the original author [EthStorage Team], if you have any objection to the reprint, please contact Gate Learn Team ), the team will handle it as soon as possible according to relevant procedures.
Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.
Other language versions of the article are translated by the Gate Learn team and are not mentioned in Gate.io), the translated article may not be reproduced, distributed or plagiarized.