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

黄沙百战穿金甲，不破楼兰终不还。这篇文章主要讲述浅析 Web3.0 DApp（去中心化应用程序）设计架构相关的知识，希望能为你提供帮助。
本篇带来 DApp 设计架构浅析~
先来回顾下 Web2.0 应用程序架构，一图胜千言：

图示是对大多数 Web 2.0 应用程序如何工作的一个很好的抽象总结。以一个博客平台为例：
首先，必须有一个地方来存储基本数据，也就是数据库；
其次，要有后端代码（用 Node.js、java 或 python 等语言编写），用于定义业务逻辑；
第三，还要有前端代码（通常用 javascript、html 和 CSS 编写），用于实现 UI 和交互；
这些代码都托管在集中式服务器上。
视角来到 Web3.0 ，消除了中心化，没有集中式的数据库，没有存放后端代码的集中式 Web 服务器。采用了区块链技术，在互联网上的匿名节点维护的分布式状态机上构建应用程序。
“状态机”是指一台机器，它维护一些给定的程序状态、以及该机器上允许的未来状态，它具有非常严格的规则（即共识）来定义状态如何转换。
没有一个实体可以控制这个分布式的状态机 —— 它由网络中的每个人共同维护。
【浅析 Web3.0 DApp（去中心化应用程序）设计架构】后端逻辑代码化身成状态机上的“智能合约”，这是开源的。
前端部分呢？暂按下不表，先看此时数据库、后端代码演变后的架构图：

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

ethereum blockchain，以太坊区块链，被认为是“世界计算器”，一个可全局访问的状态机，对等节点网络维护，状态的更改遵循共识规则的约束；只要是写入了数据，就会被记录，数据不能再更新回去；
智能合约：以太坊上运行的程序，由高级编程语言编写，例如 Solidity 或 Vyper；

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

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

OK，视野来到了前端代码部分。按道理将，前端代码应该也是用智能合约的方式实现，实际上，它也确实如此，不过要更为复杂一点。
当我们想要与区块链上的数据和代码进行交互时，我们需要与这些节点中的一个进行交互。任何节点都可以广播在 EVM 上执行交易的请求，然后矿工将执行交易并将结果状态更改传播到网络的其余部分。
广播新交易有两种方式：

设置自己运行以太坊区块链软件的节点；
使用??Infura???、 ??Alchemy???和??Quicknode??等第三方服务提供的节点；

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

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

Metamask 将用户的私钥存储在浏览器中，每当前端需要用户签署交易时，它就会调用 Metamask。
将所有内容都存储在区块链上是很昂贵的，更新数据都需要收费，所以还有一个去中心化的链下存储解决方案 —— ??IPFS???/??Swarm??
架构图如下：

IPFS/Swarm 是用于存储和访问数据的分布式文件系统，你可以轻松去检验它。
到目前为止，我们已经讨论了如何写入，那如何读取数据呢？
答案是借助 ??The Graph??，The Graph 是一种链下索引解决方案，可以更轻松地查询以太坊区块链上的数据。前端工程师可以直接调用，这比传统的 REST API 更具有吸引力。
现在，Dapp 架构如下：

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

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

这样既节约成本，又能达到目的，真是大聪明。
本瓜就把这个侧链执行，理解为代码的预编译吧，编译后再放到浏览器引擎上做真正的编译执行。