揭示下一代互联网Permaweb雏型：SCP理论下的去中心化微服务架构

作者：Outprog @ Contributor of PermaDAO

审阅：Xiaosong HU @ Contributor of PermaDAO

Permaweb 是 Arweave 生态提出的下一代互联网架构，Permaweb 所强调的是应用和网站具备永久可访问的特性，它可以让互联网拥有记忆，不再遗忘。同时，Permaweb 具有 Severless 的特性，开发者在构建的过程中不需要自行部署前端和后端，开发的所有服务都将由 Permaweb 的基础服务层提供。

更多关于 Permaweb 的概念和愿景，可以查看刘毅老师撰写的 “Arweave 的潜力是复兴亚历山大图书馆，而非 Filecoin 替代品” 了解更多关于 Permaweb（永在网）的理念。

本文将从技术角度结合 SCP 理论对 Permaweb 进行解读。

基本框架

Permaweb 使用了三层架构，顶层为应用层，是面向用户的接口。中间层是服务层，为应用提供后端服务。底层则是存储层，使用 Arweave 为应用提供数据存储服务。

Permaweb 的架构和 Web2 架构并没有太大的区别，应用层对应的是传统 Web2 的前端，服务层对应的是后端，存储层对应的是物理服务器或数据库。

使用去中心化存储是 Permaweb 和 Web2 的最大区别。Permaweb 应用集成永久存储 Arweave 后，篡改和抹除应用的内容将变得非常困难，应用将获得了去中心化的属性。虽然 Permaweb 的架构在表面上与 Web2 有相似之处，但其底层技术和设计哲学带来了根本性的区别。

Permaweb 的应用架构如下图所示

图片来自

下文将对 Permaweb 的三层架构进行详细介绍

存储层

存储层是 Permaweb 的核心，如果存储层没有使用区块链技术，Permaweb 和 Web2 将没有任何区别。Permaweb 的存储层不一定局限于 Arweave。理论上也可以使用 Bitcoin 或者 Ethereum 作为存储层打造一个完整的 Permaweb，只是开发者和用户很难承担过高的存储成本。Arweave 是目前最专业的做永久存储区块链，1 GB 仅需花费 5 美金是 Permaweb 的最优的选择。

那么存储层是否可以使用 IPFS？如果使用 IPFS，Permaweb 则将失去数据可追溯的特性，IPFS 的数据 CID 可以保障不可篡改，但 IPFS 没有使用区块链技术。IPFS 的数据没有区块时间戳，因此无法辨别数据的产生时间；同时，在 IPFS 服务节点关闭后数据也将丢失，无法保证数据永久可追溯。

服务层

服务层作为统一的中间件为应用提供 API，类似于 Web2 微服务集群, 是无状态的 可以水平扩展。通常，Permaweb 的服务层会提供标准化接口和协议 ( 类似于 Web2 的 gRPC 或者 Thrift 完全开源 开放的协议 )，这些接口和协议完全开放开源，任何部署服务的服务商可以按照协议标准提供同样的 API。任何应用只要使用了标准协议开发，就可以在不同的服务上运营和使用。

目前 Arweave 的服务层包含四个核心组件，分别是：

• • 网关服务：会缓存频繁使用的 Arweave 数据。如 , ， ， 等。
  • 数据绑定服务（批量数据打包）：使用 Arweave ANS-104 标准，将大量的数据批量打包到 Arweave。如 bundlr， arseeding 等。ANS-104 的数据也同样可以使用 GraphQL 进行检索。
  • 序列化服务：智能合约服务，支付服务等。如 Warp，everPay 等。
  • 索引服务：Arweave Tags 检索服务，全文索引服务。如 Adot，KNN3，goldsky 等。

目前标准协议仅含上述四个模块，未来 Permaweb 的服务层是可以进一步拓展新标准。

应用层

Permaweb 应用具备 Serverless 特性，开发者无需部署任何服务器。由于服务层为应用层提供了标准接口，按照规范开发的应用可以在任意的服务层打开和使用。

交互：用户仅需和服务层进行交互，无须和底层区块链进行交互。

• • 资源加载：标准化的网关为 Permaweb 的前端所需要加载的所有文件资源将，这些文件资源按照 Manifest 标准，将存储层上的资源组织成目录格式，便于 web 协议进行加载和组装。
  • 数据写入：Permaweb 的写入通常使用了 Arweave 上的 ANS-104 标准，该标准可以支持大规模的数据写入。采用 ANS-104 实现的 bundle 服务让 Permaweb 的写入体验和 Web2 完全一致。
  • 数据查询和索引：标准化的索引服务让 Permaweb 可以动态加载内容。索引的建立无需等待数据最终打包到 Arweave，数据上传到 bundle 服务后即可实时生成高效的应用索引，为用户提供实时的数据查询能力。

综上所述，交互上 Permaweb 可以做到和 Web2 完全一致的体验。

抗审查：标准协议和接口为应用提供了抗审查性的特性。下面列出网址就是一个 Permaweb 应用名字叫 cookbook：

可以发现，打开任何一个网址都可以访问 cookbook 这个应用，该网站由全球不同的网关，不同的服务器提供服务。如果 不能访问，用户仍然可以使用其他几个网址继续使用该应用。就算所有的网关被关闭，cookbook 的数据使用了 Arweave 存储，这些数据不会丢失让服务商可以随时恢复 cookbook 应用。

使用 Arweave 永久存储作为存储层，可以保障每一个 Permaweb 应用的数据去中心化；采用了标准化的、开源的协议作为服务层，可以避免个别服务器由于不可抗力的原因被关闭所带来的审查风险。Permaweb 应用具备去中心化抗审查的特性。

微服务版本的 SCP

Permaweb 的架构和传统 Web2 的架构相似，本质上 Permaweb 就是一套基于去中心化存储的微服务应用架构。

微服务是 Web2 开发使用的软件架构模式，它将一个大型复杂的应用程序拆分成一系列更小、更独立的服务单元。每个微服务都是一个独立的功能模块，可以独立开发、部署和运行。这些微服务之间通过明确定义的 API 进行通信，可以使用轻量级通信协议（如 HTTP 或消息队列）来实现。

Permaweb 的整体架构和微服务非常相似，每一个 Permaweb 应用由标准化、独立的服务单元组合而成。同样的设计理念让 Permaweb 具备构建大型复杂应用的能力。

与传统微服务的不同之处在于，Permaweb 符合 SCP，是基于存储共识的应用程序。Permaweb 即是 SCP 的微服务架构版本。

什么是 SCP（Storage-based Consensus Paradigm）？基于存储的共识范式，核心思想是只要存储不可变，上面的交易可追溯，那么应用再任何地方计算都是唯一的结果，可以获得共识。 SCP 的特点是底层数据可以有无限的组合性。只要数据和数据组装标准，应用可以从任何的存储层，甚至多存储层一起聚合生成唯一状态。

使用 SCP 开发应用时，传统应用架构无需作大量的调整，仅需将 DB（存储层）更换为不可篡改和可追溯的区块链存储。

优势

使用这套去中心化微服务架构所开发的应用程序可以获得区块链的同等特性，这些特性包含去中心化、不可篡改、可追溯、抗审查等等。

同传统微服务架构一样，该架构具备以下开发优势：

1. 模块化和可维护性：独立的服务，每个负责一个特定的功能。这种标准化和模块化设计使得每个服务可以独立开发、测试、部署和维护，从而提高了应用的可维护性和灵活性。

2. 独立性：每个服务可以由不同的团队开发和维护。更符合 DAO 的特性，让不同的组织和个人为 Permaweb 提供最好的性能和开发速度，并允许开发者选择最合适的技术栈和工具。在 Arweave 生态中我们可以看到不同的团队提供不同的服务，如 提供了网关，bundlr 和开源的 arseeding 提供了数据绑定服务，everPay 和 Permaswap 提供了专门的金融服务等等。

3. 可扩展性：独立的服务可以根据需要对某些服务进行水平扩展。甚至可以类比每个服务就是 ETH 2.0 所提到的分片，但是 Permaweb 并没有分片数量的限制，可以进行无限的横向拓展。另外，同一个协议标准也可以提供不同的数据集服务，比如某些网关，为了优化特定应用的访问速度，可以仅缓存和加工计算特定应用的数据。

4. 高可用性：拥有多个可用的网关（微服务）, 应用不会出现单点故障，有更好的可用性。

该架构继承了微服务架构的所有优势，并打破了区块链应用的不可能三角问题。传统的区块链应用必须在性能、安全性和去中心化之间放弃某个特性，才能保证另外两个特性的完整性。在 SCP 理论下，由于使用了分层的架构设计，共识将由存储层和通用协议进行保障，此时去中心化不需要和节点数量强相关，而是和协议的开放（开源）程度相关。当我们谈论 Ethereum 的去中心化时，除了考量它们的节点数量，也应该认识到 Ethereum 软件本身就是一种标准协议，用户和矿工是在使用同一套协议达成共识，即可形成较高程度对去中心化。在 Ethereum 的例子中，目前绝大部分用户和开发者使用了 提供的服务， 虽然是中心化服务，但是用户随时可以部署 Ethereum 协议并使用自主接入该网络。同样地，去中心化微服务也能满足以上特性，但是去中心化微服务不是一个特定的 VM 架构（如 EVM），而是更灵活，更接近传统架构的理论模型，是微服务结合 SCP 理论诞生的下一代去中心化互联网架构。

实践：出自 Arweave，超越 Arweave

目前 Permaweb 仅有网关、数据绑定、序列化和索引四个服务，这些服务已经形成了一定的标准。那么一个 Permaweb 实例到底是什么样的？具体是如何使用四个标准服务构建一个 Permaweb 的？

Now 应用

是一个 Permaweb 应用（下文简称为 Now），是一个为 Arweave 生态开发者提供交流的平台。Now 的主要功能是用户发起 Blog，用户可以对这些内容进行点赞。

Now 的所有数据都存储到 Arweave 上，不可变的存储层保障了 Now 的去中心化。当用户打开 Now 的时候，浏览器会首先从 Arweave 的网关服务上加载一个前端框架，如下图所示，该页面框架主要包含了 Now 的 Header 组件，并没有包含 Now 应用的展示数据。

浏览器加载应用框架后，我们可以看到 Now 的内容展示部分会显示 Loading stamps ，这时候 Now 应用正在发起 GraphQL 请求，对应用的数据进行检索。等待几秒后检索完成，Now 应用将展示出最新的用户评论和点赞（Stampers），如下图所示：

在该页面中，初始化框架和所有用户数据，以及页面所呈现的所有图片都是通过网关获得。这些元素将在浏览器中计算并组装出 Now 的完整页面。网关提供静态资源加载能力，索引服务提供动态数据加载能力。

当用户想要增加一篇 blog 时，用户可以用自己的钱包将内容上传到 Arweave。这些内容会标记特定 Tags 便于索引服务提供对这些内容的 GraphQL 查询功能。Blog 上传成功后，再次刷新 Now 应用，新的内容将呈现在应用的内容展示中。

上图展示了 Permaweb 写入和读取的基础过程。在实际应用里，Permaweb 的写入和读取都将通过服务层进行。

横向扩展

微服务的最大优势就是可扩展性，该特性将完全继承到 Now 应用上。我们可以使用任意一个网关访问 Now：

类似的网关可以无限横向扩展，让 Now 应用具备近乎无限的性能。

SCP 最佳实践

在 Permaweb 的架构中，底层仅仅使用了 Arweave 作为存储层。但是去中心化微服务不应该局限于此，我们应该深刻的吸取 Permaweb 和微服务架构的优势，去探索 SCP 的最佳工程实践。

下图来自文章《共识的变迁，区块链应用范式进化之旅》，所描述的是未来的区块链应用架构——用户不在和区块链系统本身进行交互，而是和服务层进行交互。区块链应用经历了从图 1 到图 3 的演化过程，更多内容可阅读：

从上图 3 可以看出，应用所依赖的区块链不局限于 Arweave，同时 Bitcoin 和 Ethereum 也是区块链对象，这些区块链作为应用的共识来源，为应用提供去中心化和可信保证。同样，Permaweb 和去中心化微服务也可以进行扩展，存储层无需限制 Arweave，同时也可以使用 Bitcoin 和 Ethereum 作为存储层，此时存储层也可以是其他各种类型的区块链。一个可能的最佳实践架构如图下所示：

我们使用从底至上的顺序进行描述：

• 共识层：对 Permaweb 扩展后命名为存储层不再合适，我们将原来的存储层更名为共识层。共识层可以是任何的区块链系统，这些系统都具备不可篡改和可追溯的特性。
• 服务层：服务层和 Permaweb 的最大区别是标准协议底层不局限于 Arweave 存储，可以为任意的区块链系统建立微服务。以索引服务为例子，Nansen 为现有的 EVM 公链提供数据查询能力，很多的 Dapp 和前端的数据可以直接使用 Nansen 作为数据源。KNN3 也提供了类似的索引能力，为区块链数据创建了标准化的关系查询层，同时 KNN3 也提供和 Arweave GraphQL 兼容的存储索引能力。在该架构中，微服务有更多标准和更好的共识层兼容性。
• 应用层：不局限于 Permaweb 应用，该架构可同时为去中心化应用（Web3）和 Web2 应用提供支持，完全能兼容原有的架构体系。

总结

当我们回顾过去 30 年计算机软件工程的演变，思考过去 10 年区块链工程的演变时，不得不反思一种全局虚拟机（如 EVM）加上 Layer2 的扩容方案是不是去中心化系统的终极解决方案？

本文没有去深究 Layer2 或者分片技术的可行性，而是为区块链应用方式提供了另外一种可能性。 本文以 Arweave 生态的 Permaweb 为实例，结合存储共识范式（SCP）和微服务架构的思想重新梳理了一种工程上可行的方案。该方案不仅具备极强的扩容能力，也能让应用具备去中心化的特性。更关键的是该方案并不是镜花水月，而是已经在工程上可实践的架构体系。

参考

1.

2.

3.

4.

5.