浅析 Web3.0 DApp(去中心化应用程序)设计架构
先来回顾下 Web2.0 应用程序架构,一图胜千言:
图示是对大多数 Web 2.0 应用程序如何工作的一个很好的抽象总结。以一个博客平台为例:
首先,必须有一个地方来存储基本数据,也就是数据库;
其次,要有后端代码(用 Node.js、Java 或 Python 等语言编写),用于定义业务逻辑;
第三,还要有前端代码(通常用 JavaScript、HTML 和 CSS 编写),用于实现 UI 和交互;
这些代码都托管在集中式服务器上。
视角来到 Web3.0 ,消除了中心化,没有集中式的数据库,没有存放后端代码的集中式 Web 服务器。采用了区块链技术,在互联网上的匿名节点维护的分布式 状态机 上构建应用程序。
“状态机”是指一台机器,它维护一些给定的程序状态、以及该机器上允许的未来状态,它具有非常严格的规则(即共识)来定义状态如何转换。
没有一个实体可以控制这个分布式的状态机 —— 它由网络中的每个人共同维护。
后端逻辑代码化身成状态机上的“智能合约”,这是开源的。
前端部分呢?暂按下不表,先看此时数据库、后端代码演变后的架构图:
再进一步看看这些新颖的概念:
-
ethereum blockchain,以太坊区块链,被认为是“世界计算器”,一个可全局访问的状态机,对等节点网络维护,状态的更改遵循共识规则的约束;只要是写入了数据,就会被记录,数据不能再更新回去;
-
智能合约:以太坊上运行的程序,由高级编程语言编写,例如 Solidity 或 Vyper;
任何人都能检查智能合约是否合理;
- EVM 虚拟机,用于执行合约的环境,相当于执行引擎;
OK,视野来到了前端代码部分。按道理将,前端代码应该也是用智能合约的方式实现,实际上,它也确实如此,不过要更为复杂一点。
当我们想要与区块链上的数据和代码进行交互时,我们需要与这些节点中的一个进行交互。任何节点都可以广播在 EVM 上执行交易的请求,然后矿工将执行交易并将结果状态更改传播到网络的其余部分。
广播新交易有两种方式:
借助第三方节点可能会更轻松一点,它的逻辑是这样的:
每个以太坊客户端(即提供者)都实现了 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 解决方案
在侧链操作,然后提交到主链。
这样既节约成本,又能达到目的,真是大聪明。
本瓜就把这个侧链执行,理解为代码的预编译吧,编译后再放到浏览器引擎上做真正的编译执行。
- 附:以上框架的开发工具是 Hardhat,有兴趣自行了解
本篇就是完整的“浅析 Web3.0 DApp(去中心化应用程序)设计架构”。
以上!作为入门级架构浅析,说的真的很通透了!三连了!👍👍👍
期待 Web 3.0 DApp 的开发~~ 欢迎留言评论。
我是掘金安东尼,输出暴露输入,技术洞见生活。
- 点赞
- 收藏
- 关注作者
评论(0)