Crypto-Native DApp Architecture

August 31st, 2022

0. Web2 App Architecture

When we develop a modern consumer facing application, whether it is a Web App or a Mobile App or a Desktop App, the basic architecture can be summarized by the following three ends:

From left to right are:

Front End: Also known as the client. The front end of the application is the page that the user sees in the browser, or the app that is used on the mobile device. The front end controls the view and data presentation.
Back End: Also known as the server side. The back end of the application exists mainly to provide the interface and data for the front end, usually the main business logic of the application will be in the back end.
Database: As the name implies, the database is dedicated to storing data. The back end reads or modifies the contents of the database.

Why do you need all three ends of the software? Why does not the front end directly connected to the database? Why is there a back end? There are actually many reasons for this:

a) Engineering

Developer perspective: The front end of a modern application does not have the enough bandwidth to handle both the complex data model and the state management of the view. From an engineering point of view, it is not good to have every engineer be omniscient and maintain a bloated system. In addition, there is a lot of logic that doesn’t need to be presented by the front end, such as the inventory data of an e-commerce platform.

Architecture perspective: Each end has its own set of rules and language to describe the data. The front end uses human-understandable ideas to build pages, the back end uses object-oriented language to manipulate data, and the database uses relational algebraic language to access physical storage. There is no way to specify a one-size-fits-all set of rules to unify all three ends. Also, because each language has its own role, the performance focus is different.

b) Communication

Protocol perspective: Looking at the diagram, you can see that the two connections to the three ends are different. Usually consumer facing applications use the HTTP protocol to communicate between the front end and the back end, while the back end and the database have different protocols, e.g. MySQL has a different protocol than MongoDB. We can achieve a similar effect to the front end direct connection to the database with a thin layer of back end (GraphQL + Hasura) or by specifying a new protocol (OData), and there are protocols like CouchDB that are made for such communication but still does not solve the other drawbacks.

Data mapping perspective: front end handles UI, back end handles objects, and database handles data. The front end connection to the back end uses a mapping of UI to objects, and the back end connection to the database needs to be mapped using object relationships.

c) Security

Data perspective: Because more and more of the applications we use today are web-based, it is difficult to protect against data leakage and hacking in an insecure and open browser environment if the front end is directly connected to the database. Databases can theoretically control data visibility through various means such as authentication, but another huge point of having a back end is to ensure that it operates in a trusted environment, in the way it was designed to operate, and to eliminate known security issues.

d) Insights from Web2 Architecture for Web3

From the above three perspectives, we analyze why Web2 applications are “triple-ended” architectures, which also brings us some thoughts on blockchain DApps:

Engineering: It corresponds to the modularity idea in blockchain. Each component has its own role, storage can use the storage chain, and user data is stored in the smart contract blockchain. Developers don’t need much development mental burden.
Communication: It corresponds to the different consensus mechanisms of the blockchain network. These different mechanisms also make the interoperability of blockchains difficult, but there are interoperability protocols such as Cosmos and Polkadot that try to link the whole network. However, from the perspective of Web2 applications, this does not mean that this is the best solution. Data mapping can correspond to account-oriented or UTXO design patterns, both of which have advantages and disadvantages in terms of performance, privacy, and development complexity.
Security: It corresponds to the decentralization of blockchain and the idea of “Verify, Not Trust”. Security is more important in the blockchain space, and therefore requires verifiable, or even fully transparent and open, ways to adjust data processing and data visibility to achieve transparent and Permissionless DeFi, public and ownership of NFT, and the most important composability of DApps.

1. Web3 DApp Architecture

Most of the Web3 DApps follow the following architecture:

Simple applications (pure on-chain data without compilcated interactions), e.g. Uniswap and NFT projects with pure on-chain storage.
The front end is no different from the Web2 App.
No back end (on-chain smart contracts as back end).
Blockchain as database.

a) More Components of Web3 DApp

In more detail, the workflow of a complete Web3 DApp involves more components:

Front end: browser, wallet, page.
Front end and back end communication: Node Provider, Indexing Protocol.
Conceptual back end: smart contracts on the blockchain network.
Back end and database communication: Node Provider, storage network gateway.
Database: Smart contract state and decentralized storage network.

b) How Web3 DApp Get Rid of Back End?

The existence of Turing-complete smart contracts on the blockchain network allows the blockchain to be the best Serverless platform, or the World Computer that can be seen as Trustware. The data and back end logic of the application can be implemented in the smart contract.

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

Payment: Serverless functions are usually paid for by the developer, while smart contracts are paid for by the user for most interactions, and the user willingly pays for the blockspace on the blockchain.
Execution environment: Serverless functions have a very flexible execution environment, while smart contracts have a very lightweight execution environment with few options.
Deployment environment: Serverless functions are deployed on a centralized cloud service platform, while smart contracts are deployed on a decentralized and permissionless decentralized network. In addition, the cost of operating the network is shifted from the centralized platform to the miners, and the economic system becomes more autonomous.

However, for a truly complete application, it is not possible to achieve full functionality with only smart contracts as the back end, so other components such as keeper networks or oracles are required.

2. Web3 Crypto-native DApp Architecture

Web3 DApp refers to a simple decentralized application implemented through a smart contract as the back end. To complete a complex application, it may introduce more or less centralized services, but to really implement a Crypto-native and trustless DApp, new architectural changes are needed.

The complex applications of Web2 are actually much more than the three ends we outlined before, and require a lot of modularity, middle-tier and horizontal expansion architecture.

a) Front End ⇒ Open Source + Self-hosted Front End

The triggering logic of the Web3 front end is actually different from that of Web2 itself. Web3 operations are passed and confirmed by the user, and are focused on on-chain addresses, rather than Web2 where the client sends directly to the server and database to trigger data updates.

For the development of Web3 front end, I think there are two major trends:

Choice of framework: Among the two major front end frameworks, React and Vue, React dominates Web3, mainly because of the ecosystem of various components, such as web3-react and Center.dev. But I personally feel that the development of the React project is still in the hands of Meta, its open source protocol changes has been controversial, so if you have the opportunity to use the Vue framework with some minimal dependencies third-party libraries for front end development, it’s better than React.
Front end Hosting: Front end is the most affected area in DApp hacking (malicious hijacking or script injection) and censorship (Uniswap and Flashbots have OFAC’s blacklist. Yearn Finance has long been encouraging users to host their own DApp front ends; hosting front ends on permanent storage networks like Arweave also ensures that each version of the frontend is not deleted and is permanently accessible; Trustless.fi also proposes a frontend Marketplace concept, which allows users to choose between multiple community-hosted front-ends, which also ensures neutrality and “front-end diversity”; other blockchain browsers such as Etherscan are actually considered neutral front-ends, through which users can interact directly, or there are also dedicated applications that generate front-ends for contracts, such as okcontract; recently Tornado has been censored, and there are many communities (such as codisspeech and theshake) spontaneously hosting its front-end.

The development of these two points will allow the front-end of DApp to have censorship resistence, which greatly improves the overall security and decentralization of DApp.

b) Back End ⇒ ZKP + Smart Contracts

The evolution of the App architecture will look like this:

Web2 application: Front End ⇒ Back End ⇒ Database
Web3 simple application: Front End ⇒ Smart Contracts
Web3 complex applications: Front End ⇒ ZKP ⇒ Smart Contracts

Smart contracts make the whole application decentralized, but using a smart contract on the open network to handle the logic of the application is a double-edged sword. Data and code are made public, ensuring transparency and composability, but also exposing privacy and security risks, while the cost of on-chain space and computation is very high.

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

The addition of ZKP as a middleware and communication method between the front and back ends is another great use of its two advantages:

Privacy: In Web2 applications, privacy has always been the default option, but the nature of the blockchain network allows DApps to have a virtual “privacy”, ZKP as an intermediate layer can handle sensitive data off-chain, thus solving this problem.
Scaling: Space on the blockchain is limited, so many complex algorithms in Web2 applications cannot be implemented, ZKP can execute algorithms off-chain and verify them on-chain while ensuring computational trust.

There are countless projects working in these two directions, not to mention here. There are two main challenges to overcome:

Computational feasibility: ZKP is limited in the kinds of computations it can perform, and not all of them can be solved by ZKP.
Optimization: When the complexity of the operation increases, the computation time and space increases significantly, which requires a lot of hardware and software optimization. At the same time, in many cases only significant improvements in throughput can be made, and the overall proving overhead is difficult to reduce.

c) Database ⇒ Decentralized Node Service

We previously described how DApps can use the blockchain as a back end and database. In order for a DApp to connect to the blockchain network, it needs node services.

Currently, DApps are commonly using centralized NaaS, such as Alchemy and Infura, but in the future, I have three better directions in mind:

Decentralized NaaS, protocolized infura, but this is not particularly necessary and feasible, the purpose of decentralized NaaS is mainly to resist censorship, not for other needs.
Multicentric NaaS, using multiple centralized NaaS as an alternative (similar to the Chainlink + Uniswap oracle combination). This is a more viable and reliable solution, which guarantees censorship resistance and uptime.
Self-hosted NaaS. The ultimate solution, which not only guarantees trustworthy “database” connections with various data privacy and censorship resistance, but also increases the decentralization of the network. With a self-hosted front-end, the entire DApp becomes incredibly decentralized.

d) Crypto-native DApp Example

The recently sanctioned Tornado.cash (especially the original version) is a very crypto-native DApp, which meets many of our definitions:

The front-end uses NuxtJS and Vue framework, instead of the commonly used React framework.
It is implemented entirely using ZK circuits and smart contracts in the front end code, with no server side code.
The code is completely open source, hosted in IPFS.
Older versions have no private key or multi-signature control.

I believe more applications will be built in the paradigm of Tornado.cash, which is the perfect decentralized Web3 application architecture in my mind right now.

3. Web3 Infra

While the above is a simplified version of the architecture, the following is a more specific architecture for an actual DeFi application:

It contains several added infrastructures in addition to the node services:

Indexer: The Graph on the left. There is no easy way to query data on-chain, so the indexer is needed to assemble contract-related data.
Oracle: Chainlink in the lower right corner. The chain needs to have access to data such as contracts or prices outside the network, so it needs an on-chain (Uniswap TWAP) or off-chain oracle (Chainlink) to feed prices.
Keeper: Keep3r Network in the lower right corner. Smart contracts do not have the ability to automatically trigger the execution of tasks, so external triggers are needed to assist.

These infrastructures are critical in building a DApp, and we will cover Oracle and Indexer issues and opportunities for innovation in a future article.

Why were only these infrastructures taken into account, but not projects like NFT creation tools, No-Code contract generation tools, and DApp front end generators? Because I personally believe that a good Web3 infrastructure needs to have the ability to continually capture value and grow with the applications that use it, not just pay once and be done with it, which is the lesson learned from Web2 SaaS and Web3 Protocol.

The bear market is a great opportunity to build and upgrade infrastructure. I believe these revolutionary Fat Infra will underpin the next round of DApp innovation, and capture significant value as a Base Layer.

In future articles, we will discuss in detail the best potential optimizations for these infrastructures.