浅析 Web3.0 DApp（去中心化应用程序）设计架构

先来回顾下 Web2.0 应用程序架构，一图胜千言：

图示是对大多数 Web 2.0 应用程序如何工作的一个很好的抽象总结。以一个博客平台为例：

首先，必须有一个地方来存储基本数据，也就是数据库；

其次，要有后端代码（用 Node.js、Java 或 Python 等语言编写），用于定义业务逻辑；

第三，还要有前端代码（通常用 JavaScript、HTML 和 CSS 编写），用于实现 UI 和交互；

这些代码都托管在集中式服务器上。

<hr>

视角来到 Web3.0 ，消除了中心化，没有集中式的数据库，没有存放后端代码的集中式 Web 服务器。采用了区块链技术，在互联网上的匿名节点维护的分布式 状态机 上构建应用程序。

“状态机”是指一台机器，它维护一些给定的程序状态、以及该机器上允许的未来状态，它具有非常严格的规则（即共识）来定义状态如何转换。

没有一个实体可以控制这个分布式的状态机 —— 它由网络中的每个人共同维护。

后端逻辑代码化身成状态机上的“智能合约”，这是开源的。

前端部分呢？暂按下不表，先看此时数据库、后端代码演变后的架构图：

<hr>

再进一步看看这些新颖的概念：

• ethereum blockchain，以太坊区块链，被认为是“世界计算器”，一个可全局访问的状态机，对等节点网络维护，状态的更改遵循共识规则的约束；只要是写入了数据，就会被记录，数据不能再更新回去；

• 智能合约：以太坊上运行的程序，由高级编程语言编写，例如 Solidity 或 Vyper；

任何人都能检查智能合约是否合理；

• EVM 虚拟机，用于执行合约的环境，相当于执行引擎；

<hr>

OK，视野来到了前端代码部分。按道理将，前端代码应该也是用智能合约的方式实现，实际上，它也确实如此，不过要更为复杂一点。

当我们想要与区块链上的数据和代码进行交互时，我们需要与这些节点中的一个进行交互。任何节点都可以广播在 EVM 上执行交易的请求，然后矿工将执行交易并将结果状态更改传播到网络的其余部分。

广播新交易有两种方式：

1. 设置自己运行以太坊区块链软件的节点；

2. 使用Infura、 Alchemy和Quicknode等第三方服务提供的节点；

借助第三方节点可能会更轻松一点，它的逻辑是这样的：

每个以太坊客户端（即提供者）都实现了 JSON-RPC 规范。这确保了当前端应用程序想要与区块链交互时，有一组统一的方法。JSON-RPC 是一种无状态、轻量级的远程过程调用 (RPC) 协议，定义了多个数据结构及其处理规则。它与传输无关，可以通过多种方式传输，比如 HTTP、套接字、其它传输环境，JSON (RFC 4627) 作为一种数据格式。

还有一个很重要的东西，进行身份验证，鉴权。通常借助 Metamask 实现；

Metamask 将用户的私钥存储在浏览器中，每当前端需要用户签署交易时，它就会调用 Metamask。

<hr>

将所有内容都存储在区块链上是很昂贵的，更新数据都需要收费，所以还有一个 去中心化的链下存储解决方案 —— IPFS/Swarm

架构图如下：

IPFS/Swarm 是用于存储和访问数据的分布式文件系统，你可以轻松去检验它。

<hr>

到目前为止，我们已经讨论了如何写入，那如何读取数据呢？

答案是借助 The Graph，The Graph 是一种链下索引解决方案，可以更轻松地查询以太坊区块链上的数据。前端工程师可以直接调用，这比传统的 REST API 更具有吸引力。

现在，Dapp 架构如下：

截至目前，架构图已初成雏形。

<hr>

引申补充，完整的实现上图这一架构，成本有点高昂。所以，有一种流行的扩展方案 —— L2 scaling 解决方案

在侧链操作，然后提交到主链。

这样既节约成本，又能达到目的，真是大聪明。

本瓜就把这个侧链执行，理解为代码的预编译吧，编译后再放到浏览器引擎上做真正的编译执行。

• 附：以上框架的开发工具是 Hardhat，有兴趣自行了解

<hr>

本篇就是完整的“浅析 Web3.0 DApp（去中心化应用程序）设计架构”。

以上！作为入门级架构浅析，说的真的很通透了！三连了！👍👍👍

期待 Web 3.0 DApp 的开发~~ 欢迎留言评论。

我是掘金安东尼，输出暴露输入，技术洞见生活。