From an architectural perspective, what is a truly Crypto-native DApp?

Written by: msfew, Foresight Research

0. Web2 App Architecture

When we develop a modern toC application, whether it's a Web App, Mobile App, or Desktop App, their basic architecture can be summarized in the following three components:

From left to right:

• Frontend: Also known as the client. The frontend of the application is the page that users see in the browser or the app used on mobile devices. The frontend controls the view and presentation.

• Backend: Also known as the server side. The main purpose of the backend is to provide interfaces and data for the frontend, and typically the main business logic of the application resides in the backend.

• Database: As the name suggests, the database is specifically for storing data. The backend will read or modify the contents of the database.

Why do software applications need these three components? Why doesn't the frontend connect directly to the database? Why is there a backend in between? There are many reasons for this:

a) Engineering

From the developer's perspective: Modern application frontends do not have the capacity to handle complex data models and view state management simultaneously. From an engineering perspective, having every engineer maintain a bloated system is not ideal. Additionally, many logics do not require frontend involvement in presentation, such as inventory in e-commerce platforms.

From an architectural perspective: Each component has its own set of rules and languages to describe data. The frontend constructs pages using human-understandable concepts, the backend operates on data using object-oriented languages, and the database accesses physical storage using relational algebra languages. There is no way to establish a one-size-fits-all rule to unify the three components. At the same time, because each language has its own role, performance focuses differ.

b) Communication

From a protocol perspective: Observing the diagram, we can see that the two connection methods linking the three components are different. Typically, toC applications use the HTTP protocol for communication between the frontend and backend, while the backend and database use different protocols, such as MySQL and MongoDB having different protocols. We can achieve a similar effect to a frontend directly connecting to a database through a thin backend (GraphQL + Hasura) or by establishing a new protocol (OData). There are also protocols like CouchDB that are designed for such communication, but they still do not solve other drawbacks.

From a data mapping perspective: The frontend handles the UI, the backend handles objects, and the database handles data. The connection between the frontend and backend uses UI-object mapping, while the connection between the backend and database requires object-relational mapping.

c) Security

From a data perspective: Currently, many of the applications we use are web-based, so if we allow the frontend to connect directly to the database, it would be difficult to prevent data leaks and hacker attacks in the insecure and open environment of a browser. The database can theoretically control data visibility through various authentication methods, but another significant purpose of the backend is to ensure that operations run in a trusted environment, in a designed manner, and to eliminate known security issues.

d) Insights from Web2 Application Architecture for DApps

From the above three perspectives, we analyzed why Web2 applications have a three-component architecture, and this also gives us some thoughts on blockchain DApps:

1. Engineering: Corresponds to the modularity concept in blockchain. Each component has its own role, storage can use storage chains, and user data can be stored on traditional public chains. Developers do not need to bear a high cognitive burden.

2. Communication: Corresponds to different consensus mechanisms in blockchain networks. These different mechanisms also make interoperability in blockchain a challenge, but there are interoperability protocols like Cosmos and Polkadot that attempt to link the entire network. However, from the perspective of Web2 applications, this does not necessarily mean it is the best solution. Data mapping can correspond to account-oriented or UTXO design patterns, both of which have their pros and cons in terms of performance, privacy, and development complexity.

3. Security: Corresponds to the decentralization and "Verify, Not Trust" philosophy of blockchain. Security is even more critical in the blockchain space, so it requires verifiable and even completely transparent methods to adjust data processing and visibility, thus achieving transparent and permissionless DeFi, publicly owned NFTs, and the crucial composability of DApps.

1. Web3 DApp Architecture

Most Web3 DApps follow the architecture below:

• Simple applications (purely on-chain data with uncomplicated interactions), such as Uniswap and purely on-chain stored NFT projects.

• The frontend is no different from Web2 Apps.

• No backend (on-chain smart contracts serve as the backend).

• The blockchain acts as the database.

a) Components of Web3 DApp

More specifically, the complete workflow of a Web3 DApp involves more components:

• Frontend: Browser, wallet, page.

• Frontend-backend communication: Node provider, indexing protocol.

• Conceptual backend: Smart contracts on the blockchain network.

• Backend database communication: Node provider, storage network gateway.

• Database: Smart contract state and decentralized storage network.

b) How does Web3 DApp achieve no backend?

The existence of Turing-complete smart contracts on the blockchain allows the blockchain to become the best serverless platform, or can be viewed as a Trustware World Computer. The application's data and backend logic can be implemented in smart contracts.

Compared to serverless functions, smart contracts are superior and create a better architecture and model than Web2 applications:

• Payment method: Serverless functions are typically paid for by developers, while most interaction costs of smart contracts are borne by users, who are also willing to pay for on-chain space.

• Execution environment: Serverless functions have very flexible execution environments, while smart contracts have fewer choices but are very lightweight.

• Deployment environment: Serverless functions are deployed on centralized cloud service platforms, while smart contracts are deployed on decentralized and permissionless networks. Additionally, the operational costs of the network are shifted from centralized platforms to miners, making the economic system more autonomous.

However, for a truly complete application, relying solely on smart contracts as the backend cannot achieve full functionality, so other components like Keeper networks or oracles are needed.

2. Web3 Crypto-native DApp Architecture

Web3 DApps refer to simple decentralized applications implemented with smart contracts as the backend. To complete a complex application, it may introduce centralized services to some extent. To truly achieve a crypto-native and trustless DApp, new changes need to be incorporated into the architecture.

Complex Web2 applications are far more than the three components we previously summarized; they require a lot of modularization, middleware, and horizontal scaling architecture splitting.

a) Frontend ⇒ Open Source + Self-hosted Frontend

The triggering logic of Web3 frontends is actually quite different from Web2. Web3 operations are all performed and confirmed by users, centered around on-chain addresses, rather than the Web2 model where the client directly sends data updates to the server and database. I believe there are two major trends for the development of Web3 frontends:

• Framework choice: Among the two major frontend frameworks, React and Vue, React dominates Web3 mainly due to its ecosystem and the accumulation of various components.

• For example, web3-react and Center.dev. However, I personally feel that the dominance of React projects still lies with Meta, and changes to the open-source license have sparked controversy multiple times. Therefore, if there is an opportunity to use the Vue framework with minimal third-party library dependencies for frontend development, it would be better than React.

• Frontend hosting: The frontend is a major target for DApp hacks (malicious hijacking or script injection) and censorship (both Uniswap and Flashbots' source code contain OFAC blacklists). Yearn Finance has long encouraged users to self-host the frontend of DApps; hosting the frontend on permanent storage networks like Arweave can ensure that every version of the frontend is not deleted and is permanently accessible; Trustless.fi has also proposed the concept of a frontend marketplace, allowing users to choose from frontends hosted by multiple communities, which can ensure neutrality and "frontend diversity"; blockchain explorers like Etherscan can also be considered neutral frontends, allowing users to interact directly through them, or there are dedicated applications that generate frontends for contracts, such as okcontract; recently, Tornado was censored, and many communities (like codeisspeech and theshake) have spontaneously hosted its frontend.

  

  The development of these two points will give DApp frontends censorship resistance, greatly enhancing the overall security and decentralization of DApps.

  

b) Backend ⇒ ZKP + Smart Contracts

The evolution of app architecture will be as follows:

1. Web2 applications: Frontend ⇒ Backend ⇒ Database

2. Web3 simple applications: Frontend ⇒ Smart Contract

3. Web3 complex applications: Frontend ⇒ ZKP ⇒ Smart Contract

While smart contracts decentralize the entire application, using a smart contract on a public network to handle application logic is a double-edged sword. Data and code are public, ensuring transparency and composability, but also fully exposing privacy and security risks, while the costs of on-chain space and computation are very high.

ZKP will become the RSA of the Web3 era, eliminating the communication security shortcomings of applications and the decentralization shortcomings, truly achieving trusted yet trustless DApps.

The inclusion of ZKP as an intermediary layer and communication method between the frontend and backend effectively leverages its two major advantages:

• Privacy: In Web2 applications, privacy has always been a default option, but the nature of blockchain networks has rendered DApps with virtually non-existent "privacy." ZKP, as an intermediary layer, can process sensitive data off-chain, thus solving this issue.

• Scalability: On-chain space is limited, so many complex algorithms in Web2 applications cannot be implemented. ZKP can execute algorithms off-chain while ensuring computation is trustworthy, and verify on-chain.

Countless projects are working towards these two directions, and I won't list them here. The main challenges to overcome are:

• Computational feasibility: The types of computations that ZKP can handle are limited; not all computations can be solved with ZKP.

• Optimization: As the complexity of operations increases, computation time and space will significantly increase, requiring extensive software and hardware optimizations. In many cases, significant improvements can only be made in throughput, and the overall proving overhead is difficult to reduce.

c) Database ⇒ Decentralized Node Services

We previously discussed how DApps can use the blockchain as a backend and database. To connect DApps to the blockchain network, node services are required.

Currently, DApps commonly use centralized NaaS, such as Alchemy and Infura. In my vision for the future, there are three better directions:

• Decentralized NaaS, protocolized Infura, but this is not particularly necessary or feasible; the main purpose of decentralizing NaaS is to resist censorship, without other demands.

• Multi-central NaaS, using multiple centralized NaaS as alternatives (similar to the Chainlink + Uniswap oracle combination). This is a more feasible and reliable solution that can ensure resistance to censorship and uptime.

• Self-hosted NaaS. The ultimate solution, which can ensure the trustworthiness of "database" connections and the privacy and censorship resistance of various data, while also increasing the decentralization of the network. Coupled with self-hosted frontends, the entire DApp would be incredibly decentralized.

d) Crypto-native DApp Example

Recently sanctioned Tornado.cash (especially the old version) is a very crypto-native DApp that meets many of our definitions:

• The frontend uses the NuxtJS Vue framework, rather than the commonly used React framework.

• It is entirely implemented using ZK circuits and smart contracts in the frontend code, with no server-side code.

• The code is fully open-source and hosted on IPFS.

• The old version has no private key or multi-signature control.

I believe that more applications will be built using the Tornado.cash paradigm in the future; this is currently the most perfect decentralized Web3 application architecture in my mind.

3. Web3 Infra

The above is a simplified version of the architecture; below is a more specific architecture for an actual DeFi application:

This includes several supplementary infrastructures besides node services:

• Indexer: The Graph on the left. On-chain data cannot be conveniently queried, so an indexer is needed to assemble contract-related data.

• Oracle: Chainlink in the lower right corner. On-chain data needs to obtain prices or other data from outside the contract or network, so on-chain (Uniswap TWAP) or off-chain oracles (Chainlink) are needed to provide prices.

• Keeper: Keep3r Network in the lower right corner. Smart contracts themselves do not have the ability to automatically trigger execution tasks, so external triggers are needed for assistance.

These infrastructures are crucial in building a DApp, and we will detail the issues and innovation opportunities of Oracles and Indexers in future articles.

Why were only these infrastructures considered, while NFT creation tools, no-code contract generation tools, and contract frontend generators were not? Because I personally believe that a good Web3 infrastructure needs to have the ability for continuous value capture, growing together with the applications that use it, rather than ending with a one-time payment. This is also a lesson learned from Web2 SaaS and Web3 Protocol.

The bear market is a great opportunity to build and enhance infrastructure. I believe these innovative Fat Infras will support the next wave of DApp innovation and capture significant value as the Base Layer.