先来回顾下 Web2.0 应用程序架构，一图胜千言：
图示是对大多数 Web 2.0 应用程序如何工作的一个很好的抽象总结。以一个博客平台为例：
首先，必须有一个地方来存储基本数据，也就是数据库；
其次，要有后端代码（用 Node.js、Java 或 Python 等语言编写），用于定义业务逻辑；
第三，还要有前端代码（通常用 JavaScript、HTML 和 CSS 编写），用于实现 UI 和交互；
这些代码都托管在集中式服务器上。
视角来到 Web3.0 ，消除了中心化，没有集中式的数据库，没有存放后端代码的集中式 Web 服务器。采用了区块链技术，在互联网上的匿名节点维护的分布式 状态机 上构建应用程序。
“状态机”是指一台机器，它维护一些给定的程序状态、以及该机器上允许的未来状态，它具有非常严格的规则（即共识）来定义状态如何转换。
没有一个实体可以控制这个分布式的状态机 —— 它由网络中的每个人共同维护。
后端逻辑代码化身成状态机上的“智能合约”，这是开源的。
前端部分呢？暂按下不表，先看此时数据库、后端代码演变后的架构图：
再进一步看看这些新颖的概念：
- 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 解决方案
在侧链操作，然后提交到主链。
这样既节约成本，又能达到目的，真是大聪明。
本瓜就把这个侧链执行，理解为代码的预编译吧，编译后再放到浏览器引擎上做真正的编译执行。
我们团队从2016年做区块链技术开发以来一直从事前言技术探索和产品开发，2020年gamefi 爆发以来持续关注gamefi的最新动态并为大大小小的企业团队设计开发几十款链游产品，并且打造自己的元宇宙生态，如果有兴趣的团队个人可以和我们合作一起研发打造最新最有价值的区块链产品。
