1. Web 3.0 vs Web 2.0
Web 3.0 应用（即DApps）的架构与 Web 2.0 完全不同。
以一个简单的博客网站Medium为例，用户可以在这里发布他们自己的内容并与其他用户的内容互动。
作为一个 Web 2.0 应用，可能听起来会很简单，但仍有以下这么多特性构成了Medium的架构，才使得一切成为可能：
首先，必须有一个地方用于存储重要的数据，比如用户信息、帖子、标签、评论、点赞等等，这需要一个不断更新的数据库。
其次，后端代码（使用Node.js、Java或Python等语言编写的）必须定义Medium的业务逻辑。比如当一个新用户注册时、发布一条新博客时 或 在其他人的博客上评论时，分别会发生什么。
第三，前端代码（通常用JavaScript、HTML和CSS编写）必须定义Medium的UI逻辑。例如，网页长什么样，用户跟页面上的每个元素交互时会发生什么。
把这些串联在一起，当你在Medium上写博客文章时，你跟它的前端交互，前端跟后端通信，后端跟数据库打交道。所有的这些代码都托管在中心化的服务器上并通过一个网络浏览器发送给用户（译者注：前端代码会通过网络发送到前端并在浏览器渲染，后端以接口形式对前端提供服务）。这是对现在大多数的 Web 2.0 应用如何运作的一个比较好的顶层抽象总结。
但所有这些都在变化之中。
区块链技术解锁了一个激动人心的Web 3.0应用新方向。在本文中，我们将聚焦于以太坊区块链给我们带来了什么。
是什么让 Web 3.0 如此不同？
不像Medium这样的Web 2.0应用，Web 3.0消除了中间人，没有中心化的数据库存储应用状态，也没有中心化的Web服务器承载后端逻辑。
取而代之的是，你可以利用区块链，在一个由互联网上匿名节点维护的去中心化的状态机上构建应用。
这里的“状态机”，指的是维护某个状态的机器，包括某个给定的程序状态和该机器上未来允许的状态。区块链就是由某个“创世”状态实例化，并有着非常严格的状态转移规则（即共识机制）的状态机。
更好的是，没有一个单一实体可以控制这个去中心化状态机，因为他是由网络中的每个人共同维护的。
那后端服务器呢？不像Medium的后端控制方式，在Web 3.0中，你可以编写定义了你的应用逻辑的智能合约，并将它们部署在去中心的状态机中。这意味着，每个想要构建区块链应用的人都在这个共享的状态机上部署他们的代码。
还有前端呢？几乎保持不变，除了一些我们后面将会介绍的特例之外。
现在架构大概长这个样子：
2. 一探究竟
现在，我们一起更深入地探究是什么让这一切成为可能。
1) 区块链
以太坊区块链被誉为“世界计算机”。这是因为他是由点对点节点网络维护的全球可访问、确定性的状态机。该状态机的状态改变受网络中的节点间遵循的共识规则所约束。所以，换句话说，跟字面意思一样，它确实是被设计为世界上任何人都可以访问和写入的状态机。这就使得该机器不由任何一个单一实体独有，而是由网络中的每个人共同拥有。
我们还要知道一件事：数据只能写入以太坊区块链——你永远无法更新现有数据。
2) 智能合约
智能合约是以太坊区块链上运行的一个程序，它定义了区块链上发生的状态改变背后的逻辑。智能合约使用高级语言编写，比如Solidity或Vyper。
因为智能合约的代码在以太坊区块链上存储，所以每个人都可以检查网络上所有智能合约的应用逻辑。
3) 以太坊虚拟机（Ethereum Virtual Machine, EVM）
再往下，就是以太坊虚拟机，用于执行智能合约中定义的逻辑，并处理在这个全球可访问的状态机上发生的状态改变。
EVM不理解像Solidity和Vyper这些用来编写智能合约的高级语言。取而代之的是，你必须把高级语言编译为EVM可以执行的字节码。
4) 前端
最后，是前端。如前所述，前端定义了UI逻辑，但是它也跟智能合约中定义的应用逻辑进行通信。前端和智能合约之间的通信比上图中显示的要复杂一些，接下来我们仔细看看这部分。
3. 前端与智能合约的通信
我们希望前端可以与智能合约通信，这样才能调用函数，但是请回想一下，以太坊是一个去中心化的网络。以太坊网络中的每个节点都保存了以太坊状态机上所有状态的副本，包括与每个智能合约相关的代码和数据。当我们想要与区块链上的数据和代码进行交互时，我们需要与其中一个节点交互。这是因为任何节点都可以广播会在EVM中执行的交易请求，然后，矿工会执行该交易，并将状态改变传播到网络中的其他节点。
有两个方法广播一个新交易：
如果你使用第三方服务，则不必头痛于自己运行一个全节点。毕竟，在你自己的服务器上构建一个新的以太坊节点可能需要几天的时间。（有很多数据需要同步——这甚至会占有比典型笔记本电脑能正常处理的更多带宽和存储空间）
此外，随着Dapp的规模逐渐扩大，存储完整以太坊区块链的成本也会增加，并且你需要增加更多节点来扩展你的基础设施。这就是为什么，随着基础设施愈加复杂，你需要全职的DevOps，他们会帮你维护基础设施，以确保可靠的正常运行时间和快速响应时间。
可以说，避免这些头痛是许多DApp选择使用Infura或Alchemy之类的服务来管理他们的节点基础设施的原因。当然，这是一个权衡，因为这会产生一个中心化的卡点，但是我们暂时先不讨论这个难以摆脱的难题。;)
继续往前，我们来谈谈Providers（提供商）。当你需要与区块链交互时，你连接的节点（无论是你自己建立的还是使用第三方服务提供的现成节点）通常被称为“providers”。
每个以太坊客户端（即provider）实现了一个JSON-RPC规范。这确保了当前端应用想要与区块链交互时，可以有一套统一的方法。如果你需要JSON-RPC的入门介绍，简单来说，它是一个无状态的、轻量级的远程过程调用（Remote Procedure Call, RPC）协议，定义了一些数据结构及其处理规则，它跟传输协议无关，所以这个概念可以在进程内通信、socket通信、HTTP通信或各种消息传输环境中使用。它使用了JSON（RFC 4627）作为数据格式。
一旦你通过一个provider连接上了区块链，你就可以读取存储在链上的状态。但是如果你想要写入状态，在提交交易到区块链之前，你还需要做一件事——使用你的私钥对交易进行签名。
例如，想象一下我们有一个DApp，用户可以在上面阅读博客或发布博客到区块链上。前端可能会有一个按钮，允许任何人查询特定用户写的博客。（回想一下，从区块链读取数据不需要用户对交易签名。）但是，当用户想要发布一个新帖子到链上时，DApp会要求用户使用他们的私钥对交易进行“签名”——只有这样，Dapp才会把交易转发到区块链上。否则，节点不会接受这个交易。
说到签名，就是 Metamask 大展身手的时候了。
Metamask也提供了与区块链的连接（作为一个provider），因为它已经与Infura提供的节点有连接（因为对交易签名时需要Infura（译者注：实际上签名的操作并不依赖Infura，只是Matamask在签名之前可能需要从Infura读取预估Gas等信息，另外，如果是通过Metamask来发送交易，Metamask自然也需要连接到Infura提供的节点））。这样，Metamask既是provider又是signer（签名者）。
原文地址：https://cloud.tencent.com/developer/article/2064892
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。