Foresight Ventures: Crypto-native DApp Architecture

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:

  • 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.

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.

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.

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:

  1. 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.
  2. 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

  • 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 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.

  • 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.

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.

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.

  • 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.

b) Back End ⇒ ZKP + Smart Contracts

The evolution of the App architecture will look like this:

  1. Web3 simple application: Front End ⇒ Smart Contracts
  2. Web3 complex applications: Front End ⇒ ZKP ⇒ Smart Contracts
  • 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.
  • 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.

  • 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:

  • 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.

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:

  • 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.

About Foresight Ventures

Foresight Ventures is dedicated to backing the disruptive innovation of blockchain for the next few decades. We manage multiple funds: a VC fund, an actively-managed secondary fund, a multi-strategy FOF, and a private market secondary fund, with AUM exceeding $400 million. Foresight Ventures adheres to the belief of “Unique, Independent, Aggressive, Long-Term mindset” and provides extensive support for portfolio companies within a growing ecosystem. Our team is composed of veterans from top financial and technology companies like Sequoia Capital, CICC, Google, Bitmain and many others.

Related Links

0:

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Foresight Ventures

Foresight Ventures

137 Followers

Foresight Ventures is a blockchain technology-focused investment firm, focusing on identifying disruptive innovation opportunities that will change the industry