迈向大规模应用之路：使用Substrate实现基于存储共识的链下计算范式

关注

VIP免费原创最新推荐文章于 2026-08-05 11:22:41 发布 1.5w 阅读 AI 写同款· GEO 优化 ›

Substrate - 1 开始 - 1.2 架构（Architecture） 2.2 架构（Architecture） Substrate客户端是一个运行在以Substrate为基础的区块链节点，它的组成部分包括但不限于如下内容： **存储：**用于持续更新Substrate区块链状态。区块链网络允许参与者就存储达成去信任的共识consenushttps://docs.substrate.io/v3/advanced/consensus/。Substrate附带了一种简单而高效的键值存储机制https://docs.substrate.io/v3/advanced/storage/ 阅读详情

前言

一款大众意义上成功的 Web2.0 To C 应用，至少应该在百万月活量级。我们熟知的顶级的 Web2.0 应用 Twitter, Google, Facebook, WeChat, Tiktok 等，月活都在 10 亿量级以上。也就是说，面向 C 端的应用，必需搞定高并发及大数据量存储和检索，以及其它一些东西。

而我们来看看目前基于区块链的明星应用，截止目前（成文时：2021.10.15）：

● Audius，目前月活 400 万用户，号称建立在以太坊和 Solana 之上，具体其使用链的方式，对区块链的依赖有多大，信息并不透明

● Axie Infinity，有 170 万游戏用户，运行在其以太坊独立链 Ronin 上，不过这个 Ronin 的信息同样公开得较少

● 以太坊上的头部 24 个DeFi 应用，用户地址数加起来有 300 万[1]

总体来说，区块链上的用户量量级处于一个较低状态。

造成这种现状，除了用户本身关注度较少之外，还有两个重要的基础层面的原因：

1.现有的大部分 Dapp 的 UX 体验，普通互联网用户难以理解和操作

2.现有区块链的计算性能太低、数据存储成本太高，使得使用成本太高

也就是说，现在这些区块链（公链）的基础设计，其实承载不了互联网级别的用户量，这里面有结构性机制性的问题。

我们本篇尝试讨论如何才能让区块链适用于大规模应用场景。

月活百万用户应用的基本要求

我们这里仅对 Web2.0 月活百万用户入门级应用稍作分析。

1.用户 UX 要好用

Web App 和手机 App 的 UX 体验要平滑，流程要顺畅，前置要求不能过多（比如需要某个钱包账号，安装某个浏览器插件），用户上来就能用。并且账号不一定需要自己的重新注册，能方便地使用现有的第三方登录是最好的。

2.能支撑高并发，请求延迟要低

能支撑大量用户的同时访问，不能出现卡壳的情况，延迟也不能过高（超过数秒）。这些都会体现在产品的 UX 用户体验上面。面对大量的请求，不能出现服务崩溃，中断的情况。

3.计算低成本

计算成本与计算性能这个指标是相关的，服务端系统的计算性能不能太低，不然无法承载高并发的请求。计算成本不能太高，不然云服务器的成本会急剧攀升。

4.存储低成本

用户在使用 App 的过程中会产生大量的数据。这些数据不仅包含用户直接创造的 UGC 数据，还有很多服务中间状态数据，各个层级的日志数据。这些数据最后都会存储下来，存放在 SQL 数据库或、NoSQL 数据库、对象存储服务、或者文件存储服务等等。一些索引服务如 ElasticSearch 也需要单独存储被索引的数据。这些存储要占用大量的存储空间。考虑到数据的可靠性，还需要做冗余处理。做冗余处理，相当于数据占用的空间要大几倍。这些都要求存储成本要保持比较低的水平，不然会导致服务整体的成本过高，App 难以运维下去。

Web3.0的要求

其实，Web3.0 的目标只有一个：开放性（Openness）。开放性是 Web3.0 的唯一核心目标。那么，开放性这个词有哪些内涵呢？

1.数据的开放性

2.对数据的操作的开放性

3.组织形式的开放性

本文在这里不打算展开论述，详细讨论可参见拙作：《对Web3.0概念的梳理》[2]和《为什么Web3.0需要区块链》[3]。

目前区块链计算方式的瓶颈

我们这里讨论一下主流区块链以太坊 Ethereum 的技术方案存在主要问题。

1.合约虚拟机，分时复用，计算能力有限

全世界所有以太坊的节点都在 evm 中以单线程的形式运行一个合约序列。从合约程序的角度来看，每个对合约函数的调用按排队执行，一个执行完再执行另一个，相当于分时复用同一个 CPU。这种计算模型，决定了节点的计算能力受限于节点单个 CPU 的计算能力，其性能限制非常大。目前以太坊的处理能力 TPS 为 13 左右。

2.存储成本高昂

据计算，目前（发文时）在以太坊上每存储 1k 字节数据的费用超过：$100（一次性付费）。而传统云存储服务存储 1 G 数据的成本大概是：$0.02 每月。如果按10年来算，以太坊上的存储费用比云存储高 41,666,666 倍。

为了防止过度占用计算资源和存储资源，以太坊设计了 Gas 费机制。

扩容之路

由于以太坊的计算能力和存储能力都非常有限，其它的公链项目便有了出头的机会。不同的公链在不同的方向上做出了一定程度的创新。

● Solana

Solana 思路是把 Layer1 性能做到最好，号称目前 TPS 最高的公链。其 PoH 共识辅助机制，使得一些共识子流程可以使用 GPU 来做并行验证。目前 Solana 的 TPS 大概在 2000 左右。

Solana 一定程度上放弃了部分去中心化特性，并且其节点配置要求特别高。这些都是追求高 TPS 的代价。

● Ethereum 2.0，NEAR, Polkadot

这仨都是走的分片（Sharding）之路。分片非常难，可能是最难的扩容方案了。以太坊 2.0 节奏缓慢，遥遥无期。NEAR 据说 2021 年底发布 6 个分片的网络，目前还不清楚分片后的网络实际效果如何，带来多大优势，交易成本会不会增加。Polkadot 的平行链现在在稳步推进，其先行网已经上了几个平行链了，但还没经过真正应用的验证。

分片的难，难在原理上，详见 NEAR 的《夜影协议白皮书》[4]。现在尚无一个真正的稳定运行的分片网络，分片网络后面会不会遇到什么新的问题，是否具有实用性，这些都需要时间来验证。

● L2 群雄：Polygon, Arbitrum, Optimistic Rollup, ZK Rollup

L2 对以太坊的扩容是目前的主流扩容方向。详见：《以太坊的Layer2扩容之路》[5]。

● Cosmos, Octopus

这俩兄弟项目走的是多链跨链之路。基本出发点是认为支撑应用的最小单位是应用链（Appchain），而不是合约。每个应用一条链，然后所有应用链都可以通过 IBC 协议直接互联互通。

上述提到的这些项目，到目前为止，都已产生可观的影响。扩容之路不是那么容易，最后只能靠时间来检验，谁才能够走到最后。