一篇文章看懂Web3 Dapp产品架构

imToken 是一款全球领先的区块链数字资产管理工具[ZB]，帮助你安全管理BTC, ETH, ATOM, EOS, TRX, CKB, BCH, LTC, DOT, KSM, FIL, XTZ 资产，同时支持去中心化币币兑换功能 ...

原标题：：-DApp 架构

0. Web2 应用程序架构

当我们开发现代toC应用的时候，不管是Web App，还是App，或者说APP，它们的基本架构可以用以下三个端来概括：

从左到右依次为：

软件为什么需要这三端？前端为什么不直接连接数据库？中间为什么还要有后端？其实原因有很多：

a) 工程

开发者视角：现代应用的前端没有精力同时处理复杂的数据模型和视图状态管理。从工程角度来说，让每个工程师都知道所有事情，维护一个臃肿的系统并不好。另外很多逻辑并不需要前端参与展示，比如电商平台的库存。

从架构角度：每端都有自己的一套规则和语言来描述数据。前端使用人能理解的思想来构建页面，后端使用面向对象的语言来操作数据，数据库使用关系代数语言来访问物理存储。没有办法规定一套通用的规则来统一三端。同时，由于每种语言都有各自的职责，性能重点也不同。

b) 通讯

协议视角：看图我们可以看出连接三端的两种连接方式是不同的。通常一个toC应用的前端和后端使用HTTP协议进行通信，而后端和数据库则有不同的协议，比如MySQL。我们可以通过非常薄的后端（+）或者指定新的协议（OData）来实现前端直接连接到数据库的类似效果。也有专门为此类通信设计的协议，但其他缺点仍然没有解决。

从数据映射角度：前端处理UI，后端处理对象，数据库处理数据。前端与后端的连接使用UI与对象的映射，后端与数据库的连接需要使用对象关系进行映射。

c) 安全

数据视角：目前我们使用的应用越来越多都是基于Web的应用，如果前端直连数据库，在浏览器这种不安全、开放的环境下很难防范数据泄露和黑客攻击。理论上数据库可以通过各种认证方式控制数据可见性，但后端的另一大意义在于以设计的方式确保其运行在可信环境中，杜绝已知的安全问题。

d）Web2应用架构对DApp的启发

我们从以上三个角度分析了为什么Web2应用是三端架构，这也给了我们对区块链DApps的一些思考：

工程化：对应区块链中的模块化思想，每个组件都有各自的功能，存储可以使用存储链，用户数据可以使用传统公链存储，开发者不需要有太高的开发心智负担。 通信：对应区块链网络不同的共识机制，这些不同的机制也使得区块链的互通成为难题，但也有和等试图链接整个网络的互通协议。但从Web2应用的角度来看，这并不意味着它就是最好的解决方案。数据映射可以对应面向账户或面向UTXO的设计模式，这两种设计模式在性能、隐私、开发复杂度等方面都有各自的优缺点。 安全性：对应区块链的去中心化和Not Trust思想，区块链领域更看重安全性，因此需要一种可验证，甚至完全透明开放的方式来调整数据的处理和可见性，从而实现透明和DeFi、公有和所有NFT，以及DApp最重要的可组合性。 1. Web3 DApp架构

大多数 Web3 DApp 遵循以下架构：

a）Web3 DApp 详细组件

更具体地说，完整的 Web3 DApp 工作流程涉及更多组件：

前端：浏览器、钱包、页面。前后端通信：节点、索引协议。概念后端：区块链网络上的智能合约。后端数据库通信：节点、存储网络网关。数据库：智能合约状态和去中心化存储网络。

b）Web3 DApp 如何实现无后端？

区块链网络上图灵完备的智能合约的存在，使得区块链成为了最好的平台，或者说是世界，无论是应用数据，还是后端逻辑，都可以在智能合约中实现。

相比于功能Trust钱包如何使用DApp，智能合约更加优秀，也创造了比Web2应用更好的架构和模型：

然而对于一个真正完整的应用程序来说，仅通过智能合约作为后端是不可能实现完整的功能，因此需要网络或预言机等其他组件。

2. Web3 - DApp 架构

Web3 DApp 是指以智能合约为后端实现的简单的去中心化应用。为了完成一个复杂的应用，可能会或多或少地引入中心化服务。要真正实现完全去中心化的 DApp，需要对架构做出新的改变。

Web2的复杂应用其实远不止我们之前总结的三端，需要大量的架构模块化、中间层、水平扩展等。

a) 前端 ⇒ 开源 + 自前端

Web3前端的触发逻辑其实和Web2本身是不一样的，Web3的操作都是由用户认可和确认，以链上地址为中心，而不是像Web2中客户端直接发送到服务端、数据库来触发数据更新。

关于Web3前端的发展，我认为有两大趋势：

框架的选择：在 React 和 Vue 两大前端框架中，React 在 Web3 中占据主导地位，主要是因为生态的积累和各类组件，比如 web3-react、.dev 等。但个人觉得 React 项目的主导权还是在 Meta 手中，开源协议的变化也多次引发争议。所以如果有机会用 Vue 框架配合一些依赖尽可能少的第三方库做前端开发，还是比 React 强。 前端：前端是 DApp 被黑客攻击（恶意劫持或脚本注入）和（并且源码有 OFAC 黑名单）的重灾区。Yearn 长期以来一直鼓励用户自己托管 DApp 的前端；将前端托管在这样的永久存储网络上也能保证前端每个版本不会被删除，永久可访问； .fi 还提出了前端的概念，让用户可以在多个社区托管的前端中进行选择，这样也能保证中立性和“前端多样性”；其他区块链浏览器其实也是中立的前端，用户可以直接通过它进行交互，或者也有专门的应用程序为合约生成前端，比如；最近也有不少社区（比如和）都在托管自己的前端。

这两点的发展将大大增强DApp整体的安全性和去中心化程度。

b）后端⇒ZKP+智能合约

App架构的演进将会如下：

Web2 应用程序：前端 ⇒ 后端 ⇒ 数据库 Web3 简单应用程序：前端 ⇒ 智能合约 Web3 复杂应用程序：前端 ⇒ ZKP ⇒ 智能合约

虽然智能合约让整个应用变得去中心化，但是使用公网上的智能合约来处理应用的逻辑是一把双刃剑，数据和代码都是公开的，保证了透明性和可组合性，但同时也将隐私和安全风险完全暴露，同时链上空间和计算的成本也非常高昂。

ZKP将成为Web3时代的RSA，消除应用程序的通讯安全性和去中心化缺点，真正实现DApp。

ZKP作为前后端之间的中间层和沟通方式的加入，再次很好的发挥了它的两大优势：

有无数的项目在朝着这两个方向努力，这里就不一一列举了。主要有两个困难需要克服：

c) 数据库⇒去中心化节点服务

我们之前描述了DApp如何使用区块链作为后端和数据库。为了让DApp连接到区块链网络，需要节点服务。

目前DApp经常采用中心化的NaaS，比如 ，而在我看来，未来有三个比较好的方向：

去中心化NaaSimToken官网，基于协议，但是这个其实不是特别必要和可行的。NaaS去中心化的目的主要是为了抗审查，没有其他要求。多中心NaaS，使用多个中心化NaaS作为替代方案（类似+预言机组合）。这是比较可行可靠的方案，可以保证抗审查和。自托管NaaS。最终的解决方案，既可以保证“数据库”连接的可信度和各种数据的隐私和抗审查，又可以增加网络的去中心化程度。有了自托管的前端，整个DApp就会极度去中心化。

d)-DApp 示例

最近批准的 .cash（特别是旧版本）是一款非常棒的 DApp，它符合我们的许多定义：

我相信未来会有更多的应用使用.cash范式构建，这是我心目中最完美的去中心化Web3应用架构。

3. Web3 基础设施

上面只是简化版的架构，下面是一个实际 DeFi 应用的更具体的架构：

它除了节点服务之外还包括几个补充基础设施：

这些基础设施对于构建DApp至关重要。我们将在后续的文章中详细介绍其中的问题和创新机会。

为什么只考虑这些基础设施，而 NFT 创建工具、No-Code 合约生成工具、合约前端生成器等则不予考虑？因为我个人认为，好的 Web3 基础设施需要具备持续捕获价值的能力，并且随着使用它的应用程序不断成长，而不是一次性付费。这也是从 Web2 SaaS 和 Web3 中得到的经验。

熊市是建设和完善基础设施的一个非常好的机会。我相信这些创新的 Fat Infra 将支持下一轮 DApp 创新，并作为基础层捕获巨大的价值。

在未来的文章中，我们将详细讨论这些基础设施的最佳潜在优化。