以 Web 2.0 框架（图 5-1）为基础，Web 3.0 的简要框架如上图 5-2 所示（以 Ethereum 网络为例），除了没有存储应用程序状态
的中心化数据库和后端逻辑所在的中心化 Web 服务器，Web 3.0 在多个方面较目前传统的互联网模式也有较大的不同，详情如下：
①：前端代码与以太坊上的智能合约通信
当我们想要与区块链上的数据和代码进行交互时，我们需要与这些节点之一进行交互39。这是因为任何节点都可以广播在 EVM 上执行
交易的请求。然后矿工将执行交易并将结果状态更新传播到网络的其余部分。
广播新交易有 3 种方式：
1）开发者自己运行以太坊节点；
2）使用 Infura、Alchemy 和 Quicknode 等第三方服务提供的节点；
38 《The Architecture of a Web 3.0 application》，Preethi Kasireddy
39 以太坊网络中的每个节点都会在以太坊状态机上保存一份所有状态的副本，包括与每个智能合约相关的代码和数据。
– 25 –
3）使用去中心化的节点服务商，如：Pocket Network。
目前对于大部分以太坊上的 Dapp 开发者来说，大多都是选择第三方服务提供节点的方式来广播交易，主要原因是由于，运行以太坊
全节点需要从零开始下载到目前最新的每个区块，对于以太坊主网，目前超过 1000 万个区块和数十亿笔交易，实际上可能需要花费
数周的时间去同步这些信息。并且由于运行节点在网络机制中基本没有经济激励。
这就导致了，虽然自行搭建一个以太坊全节点可以完全保证链上操作的安全和隐私，但迫于成本的考虑，大多数的用户和开发者最终
都不会自己去搭建一个全节点，而是选择中心化全节点服务商（如 Infura）。
另一方面，虽然现有的中心化全节点服务商通常都可以很好的完成工作，但它需要用户、开发者去信任提供节点数据的公司，即存在
中心化的信任问题和单点失效风险。所以目前开始有项目着手于构建一个去中心化的节点网络（如：Pocket Network），不过这方面
的发展也才刚刚起步，较传统的第三方服务商来说，还有相当的距离。
②：RPC 接口
每个以太坊客户端（即提供者）都实现了 JSON-RPC 规范。这确保了当前端应用程序想要与区块链交互时有一组统一的方法。
注：JSON-RPC 是一种无状态、轻量级的远程过程调用 (RPC，Remote Procedure Call) 协议，它定义了多个数据结构及其处理规
则。它与传输无关，因此这些概念可以在同一进程中、通过套接字、通过 HTTP 或在许多不同的消息传递环境中使用。它使用
JSON (RFC 4627) 作为数据格式。
RPC 的接口主要是给链外使用的，比如用户登录了 Metamask 钱包，钱包需要显示我账户的余额，就需要通过指定的 RPC 节点提供
的 RPC 接口来调用我账户的链上资产数据来显示。那些提供了 RPC 接口的人运行了主链客户端（主链节点），并且打开了 RPC 节点
的端口权限，允许被 RPC 方式调用。
③：签名
通过以太坊节点连接到区块链后，我们可以读取存储在区块链上的状态。但是，如果想要写入状态，将交易提交到区块链之前，我们
还需要做一件事——使用私钥“签署”交易。也只有使用私钥“签署”交易，Dapp 才会将交易中继到区块链，否则节点不会接受交
易。
合约只有在被交易调用时才会执行。以太坊上所有合约的执行，归根结底，都是由来自外部账户所创建的交易触发的。一个合约可以
调用另一个合约，然后一层层的在合约之间不断调用，但是这个执行链条中的第一个合约的执行，一定是由外部账户所创建的交易触
发的。智能合约永远不会“自动执行”，或者“在后台运行”。在没有交易触发（不论是直接触发，还是通过智能合约调用链）执行
的情况下，合约永远处在等待调用的状态40。
在以太坊上，这种交易的“签名”，我们通常都是通过 Metamask 来实现。
④：数据存储
理论上，将 Dapp 数据完全存储在以太坊区块链上，并结合区块链不可篡改的特性是十分有意义的。不过，不可篡改的特性也会引申
出一些优缺点，优点是：1）数据不可被篡改，可以“永久”保存；2）任何人可以访问该数据。缺点是：1）数据无法更改，将导致
程序版本迭代成本过高；2）数据没有隐私保护；3）成本昂贵，就我们讨论的以太坊以及大部分区块链而言，用户每次向区块链添加
新数据时都需要付费。这是因为向去中心化状态机添加状态会增加维护该状态机的节点的成本。
基于这些不足，目前的做法大多是通过去中心化的链下存储解决方案，如：IPFS、Swarm 和 Storj 等（注：由于 Arweave 是去中心
40 《精通以太坊：开发智能合约和去中心化应用》，作者：Andreas M. Antonopoulos，Gavin Wood Ph. D. 译者：喻勇 杨镇 任
露露 Elisa Jiang
– 26 –
化云存储的链上数据存储，细分领域不同，因此在本文不做对比）。
IPFS（全称为 Inter Planetary File System）星际文件系统，其是以内容寻址的方式在网络中访问数据，是一个分布式传输协议。
IPFS 通过将数据存储在不同矿工的硬盘上，采用 P2P 的形式，以便用户在需要数据时可以轻松的检索。
不过由于 IPFS 本身没有很好的激励机制驱动更多矿工参与网络存储，因此还有一个被称为“Filecoin”的激励层，本文调研的
Aleph.im 同样也是 IPFS 的激励层，激励层激励世界各地的节点存储和检索 IPFS 上的数据。用户还可以使用 Infura 提供 IPFS 节点
或 Aleph.im、Pinata 之类的提供商——将文件“PIN”到 IPFS，获取 IPFS 哈希并将其存储在区块链上。
Swarm 和 Storj 作为链下存储的解决方案，有一个显著的区别：虽然 Filecoin 和 Aleph.im 都作为一个单独的系统，但 Swarm 和
Storj 的激励系统是内置的，并通过以太坊区块链上的智能合约执行，用于存储和检索数据。
⑤：前端代码存储
在传统的 Web 2.0 中，我们通常是在 AWS 这类的中心化云计算平台上托管代码，但这也带来了潜在的中心化风险：1）AWS 单点故
障；2）中心化机构的审查。
这时候 Dapp 开发者可能会将其前端托管在一个去中心化的存储解决方案上，比如 IPFS 或 Swarm。
本文探讨的 Aleph.im 就是让用户可以在 IPFS 中拥有自己的前端，然后节点会去查找所有可以响应请求的后端 microVMs host。
⑥：索引
上述我们讨论了如何通过签署交易然后将它们发送到区块链来写入区块链。而对于从以太坊区块链上的智能合约中读取数据，目前主
要有两种方法：
1) 智能合约事件
使用 Web3.js 库来查询和监听智能合约事件，通过监听特定事件并在每次触发事件时指定回调。例如，如果有一个智能合约在每个
区块中从 A 地址向 B 地址提交连续的交易请求，那么我们可以在每次向 B 地址提交新的交易请求时发出一个事件。前端代码可以
监听被触发的事件，并通过智能合约执行特定的操作。
2) The Graph / Covalent
上述方法有效，但有一些局限性。例如，如果开发者部署了一个智能合约，后来意识到需要一个最初没有包含的事件/条件，那么开发
者必须使用该事件和数据重新部署新的智能合约。此外，使用回调来处理各种 UI 逻辑会变得非常复杂。
这就是 The Graph 和 Covalent 等索引服务的用武之地41。当然对于数据索引，我们也可以选择 Infura 此类的中心化服务商，但是
同样的，这也会带来中心化的问题。
The Graph 是一个去中心化的数据索引协议，目前主要索引来自以太坊和 IPFS 的开源数据，同时也在积极的支持更多的区块链。其
基于广泛流行的 GraphQL 查询语言，开发人员无需设置完整节点和编写脚本。
41 如果 The Graph 上的子图运行到一半，并且已经同步到很后面的区块，这时候开发者发现少了 name 字段，有两种方法补救：1）
临时再部署一个子图加一个 name 字段嫁接之前子图(在 manifest 里面配置)，然后剩下的数据就直接索引之前那个子图；2）重新部
署。
注：嫁接要求索引器已索引基本子图。但目前团队不建议在 The Graph Network 上使用，开发人员不应通过 Studio 将使用该功能
的子图部署到网络。
因此，在 The Graph 中部署的子图一旦业务逻辑要进行修改，那么之前采集的数据也可能就变得无效。只是容错率较 Web3.js 库的
形式来看更高。Covalent 也是类似的情况。
– 27 –
通过 The Graph 和 Covalent 索引区块链数据，可以帮助开发者减少查找特定信息所需的时间，并且避免了单点故障的问题。
另一方面，随着近两年公链生态的百花齐放，每个区块链对于数据索引的需求也是日益上升。Aleph.im 目前就是立足于 Solana 生
态上的数据索引服务，虽然团队目前暂未披露相应的 dashboard，但从 Aleph.im 过去一年接连不断的与 Solana 生态上头部的
DeFi 项目集成的信息来看，目前 Aleph.im 与 Solana 生态有较为深度的合作，并且已经取得了不错的成效，是目前 Solana 生态上
索引领域的龙头。
⑦：扩容
以太坊扩容，就是提高以太坊每秒能够处理的交易数量。Layer 2 扩容是改变区块链的使用方法，将原先放在以太坊链上执行的计
算、存储等活动放在主链外的“二层（Layer-2）”协议中执行。二层的所有活动需要生成一个证明并提交到主链上，证明主链外发生
的一切活动是可信的。
目前 Layer 2（链下）扩容方案主要包括：状态通道、托管型侧链、非托管型侧链（Plasma、Rollup）。

以上，就是目前 Web 3.0 的大体框架，从上述的介绍中，我们可以看出，目前 Aleph.im 主要在其中的存储、数据索引领域发力，
并且具有实际的产品需求。