LAYER:探讨面向大规模应用的技术路线：基于存储共识的链下计算范式_RO Slayers

前言

一款大众意义上成功的Web2.0ToC应用，至少应该在百万月活量级。我们熟知的顶级的Web2.0应用Twitter,Google,Facebook,WeChat,Tiktok等，月活都在10亿量级以上。也就是说，面向C端的应用，必需搞定高并发及大数据量存储和检索，以及其它一些东西。而我们来看看目前基于区块链的明星应用，截止目前：Audius，目前月活400万用户，号称建立在以太坊和Solana之上，具体其使用链的方式，对区块链的依赖有多大，信息并不透明AxieInfinity，有170万游戏用户，运行在其以太坊独立链Ronin上，不过这个Ronin的信息同样公开得较少以太坊上的头部24个DeFi应用，用户地址数加起来有300万总体来说，区块链上的用户量量级处于一个较低状态。造成这种现状，除了用户本身关注度较少之外，还有两个重要的基础层面的原因：现有的大部分Dapp的UX体验，普通互联网用户难以理解和操作现有区块链的计算性能太低、数据存储成本太高，使得使用成本太高也就是说，现在这些区块链的基础设计，其实承载不了互联网级别的用户量，这里面有结构性机制性的问题。我们本篇尝试讨论如何才能让区块链适用于大规模应用场景。月活百万用户应用的基本要求

我们这里仅对Web2.0月活百万用户入门级应用稍作分析。1.用户UX要好用WebApp和手机App的UX体验要平滑，流程要顺畅，前置要求不能过多，用户上来就能用。并且账号不一定需要自己的重新注册，能方便地使用现有的第三方登录是最好的。2.能支撑高并发，请求延迟要低能支撑大量用户的同时访问，不能出现卡壳的情况，延迟也不能过高。这些都会体现在产品的UX用户体验上面。面对大量的请求，不能出现服务崩溃，中断的情况。3.计算低成本计算成本与计算性能这个指标是相关的，服务端系统的计算性能不能太低，不然无法承载高并发的请求。计算成本不能太高，不然云服务器的成本会急剧攀升。4.存储低成本用户在使用App的过程中会产生大量的数据。这些数据不仅包含用户直接创造的UGC数据，还有很多服务中间状态数据，各个层级的日志数据。这些数据最后都会存储下来，存放在SQL数据库或、NoSQL数据库、对象存储服务、或者文件存储服务等等。一些索引服务如ElasticSearch也需要单独存储被索引的数据。这些存储要占用大量的存储空间。考虑到数据的可靠性，还需要做冗余处理。做冗余处理，相当于数据占用的空间要大几倍。这些都要求存储成本要保持比较低的水平，不然会导致服务整体的成本过高，App难以运维下去。Web3.0的要求

其实，Web3.0的目标只有一个：开放性。开放性是Web3.0的唯一核心目标。那么，开放性这个词有哪些内涵呢？1.数据的开放性2.对数据的操作的开放性3.组织形式的开放性本文在这里不打算展开论述，详细讨论可参见拙作：《对Web3.0概念的梳理》和《为什么Web3.0需要区块链》。目前区块链计算方式的瓶颈

我们这里讨论一下主流区块链以太坊Ethereum的技术方案存在主要问题。1.合约虚拟机，分时复用，计算能力有限全世界所有以太坊的节点都在evm中以单线程的形式运行一个合约序列。从合约程序的角度来看，每个对合约函数的调用按排队执行，一个执行完再执行另一个，相当于分时复用同一个CPU。这种计算模型，决定了节点的计算能力受限于节点单个CPU的计算能力，其性能限制非常大。目前以太坊的处理能力TPS为13左右。2.存储成本高昂据计算，目前在以太坊上每存储1k字节数据的费用超过：$100。而传统云存储服务存储1G数据的成本大概是：$0.02每月。如果按10年来算，以太坊上的存储费用比云存储高41,666,666倍。为了防止过度占用计算资源和存储资源，以太坊设计了Gas费机制。扩容之路

由于以太坊的计算能力和存储能力都非常有限，其它的公链项目便有了出头的机会。不同的公链在不同的方向上做出了一定程度的创新。SolanaSolana思路是把Layer1性能做到最好，号称目前TPS最高的公链。其PoH共识辅助机制，使得一些共识子流程可以使用GPU来做并行验证。目前Solana的TPS大概在2000左右。Solana一定程度上放弃了部分去中心化特性，并且其节点配置要求特别高。这些都是追求高TPS的代价。Ethereum2.0，NEAR,Polkadot这仨都是走的分片之路。分片非常难，可能是最难的扩容方案了。以太坊2.0节奏缓慢，遥遥无期。NEAR据说2021年底发布6个分片的网络，目前还不清楚分片后的网络实际效果如何，带来多大优势，交易成本会不会增加。Polkadot的平行链现在在稳步推进，其先行网已经上了几个平行链了，但还没经过真正应用的验证。分片的难，难在原理上，详见NEAR的《夜影协议白皮书》。现在尚无一个真正的稳定运行的分片网络，分片网络后面会不会遇到什么新的问题，是否具有实用性，这些都需要时间来验证。L2群雄：Polygon,Arbitrum,OptimisticRollup,ZKRollupL2对以太坊的扩容是目前的主流扩容方向。详见：《以太坊的Layer2扩容之路》。Cosmos,Octopus这俩兄弟项目走的是多链跨链之路。基本出发点是认为支撑应用的最小单位是应用链，而不是合约。每个应用一条链，然后所有应用链都可以通过IBC协议直接互联互通。上述提到的这些项目，到目前为止，都已产生可观的影响。扩容之路不是那么容易，最后只能靠时间来检验，谁才能够走到最后。面向Web3.0应用的计算范式

前面提到，Web3.0的核心在于开放性，而不是以下名词中的任何一个：安全性区块链去中心化密码学安全性是延伸属性，密码学和区块链是工具，去中心化是手段，开放性才是目的。而对区块链来讲，我们前面提到的所有主流的区块链，其实都是面向资产而设计，而非应用。回顾历史，如果从2008年比特币诞生开始算起，这十多年，所有主流区块链项目其实只做了一件事情：处理资产。12年的一个成果，刚刚好就是2020年之夏的DeFi热潮。即便只是资产这么一个东西，要处理好也是一件了不起的事情。也就是说，即使只处理资产、金融相关的业务，以太坊已经不够用了，还要出现那么多的L2、侧链、新型公链等项目来分担处理。这么多选手一起上也还差得远，离解决好金融业务这个目标还有太远的距离。也就是说，到目前为止，在区块链上做的那些努力，连基本盘金融领域都尚未处理得过来，更遑论面向Web3.0进行应用这一层次的创新了。链上逻辑只适合处理资产业务

在拙作《为什么区块链需要Web3.0》中提出：合约型公链仅适合于处理DeFi相关业务。而在本篇中，我们将进一步提出：所有链上逻辑都只适合处理DeFi相关业务。既然本篇我们讨论的是大规模的应用，那出发点就是大规模应用的标准，而不是做Demo，演示其可能性。对于合约型公链来说，可以把所有合约应用，组合起来看作一个大的应用，皆为链上逻辑。这是由基础的账户模型决定的。而对于由Substrate这种框架开发的应用链Appchain来说，其链上逻辑仍然只适合处理资产相关业务。区块链的链上逻辑，无法用于处理通用型大规模的应用。理由如下：1.链上逻辑的计算量受限于节点性能和出块间隔的限制2.链上逻辑必须在虚拟机体系内完成，不能有任何副作用3.链上状态的存储使用MPT实现，具有一系列优异的特性，但是也增大了中间存储量和计算量4.链上数据结构受限于存储特性和Gas费等，种类比较少，形式比较初级，要注意的细节点很多，在处理业务时很受限5.由于区块链的安全性要求，链上无法内置一个SQL这种Web2.0中最基础而又强大的检索引擎，这让写业务代码的时候，需要人为手动在数据插入的时候建立更新索引对象，非常别扭由于以上的这些问题，我们认为传统的区块链链上计算范式无法承载Web3.0应用的大规模实践。面向Web3.0应用，我们需要寻找另外的计算和存储范式。基于Arweave的存储共识范式

存储共识范式：通过Arweave永久存储和链下计算达到共识。存储共识范式是everFinance提出的下一代区块链应用开发范式。在Ethereum模型中，计算会被区块链网络中的所有节点执行，所有节点都会生成和存储全局状态以供查询。不同于Ethereum模型，存储共识范式分离了计算和存储，区块链仅进行数据存储不进行任何计算，所有计算由链下的客户端/服务器执行，生成的状态也由链下客户端/服务器进行保存。存储共识范式使用了链下智能合约，智能合约可以是任何语言编写的程序，这些程序的所有输入参数都来自存储型区块链。在范式中，区块链更像是计算机的硬盘，链下智能合约可以在任何具备计算能力的机器上进行。使用区块链作为硬盘，所存储的数据具备了不可篡改和可追溯的特性，区块链为数据赋予了可信的特性。链下智能合约对可信数据进行计算，能保证状态的最终一致性。存储共识范式开发的应用程序，具备区块链的透明和可信特性，同时又具备传统互联网应用的高性能和可用性。存储共识范式具备以下优势：1.可组合性：传统金融服务间进行业务对接，需要会计对账，对账过程繁复且容易出错。采用存储共识范式，将金融交易记录完全上链，把传统金融服务转化成区块链应用，实现自动化对账，达到应用间的快速协同，高效组合。2.开发门槛低：使用Ethereum虚拟机编写智能合约需要使用Solidity语言，链下计算则可以用任何的语言进行开发，开发者可以将传统的应用转化成区块链应用。3.无性能限制：链下计算，其性能跟传统应用一样，链下服务器可以承载大量的交易。TPS取决于提供服务的机器性能和构建应用的技术架构。4.共识成本极低：100万笔交易仅需要1美金。参考资料：Storage-basedConsensusParadigm。Substrate框架的OffChain特性

OffChain特性是Substrate中提供的一套相当强大的基础设施。毕竟对区块链来说，链上的逻辑操作空间非常有限，有些事情必须通过链下来完成。在没有OffChainWorker(OCW)之前，这一类事情，通常是由预言机Oracle来完成。预言机是外部服务，通过区块链节点RPC接口向区块链提交交易从而把外界的信息传到链上去。这种方式虽然是可行的，但它在安全性、集成性、可扩展性和基础设施效率问题上面，仍然不够好。为了让链下数据的集成更安全和有效，Substrate提供了offchain相关的特性。其架构图如下：

Off-chainWorker架构图Offchain特性包含三大组件：OffChainWorkerOffChainStorageOffChainIndexingOffChainWorker用于实现链下逻辑。其代码与Runtime代码写在一起，并被编译到同一个wasm字节码字符串中，在同一个交易中被传播到全网络。但是在执行的时候，OffChainWorker的代码是在独立的VM中执行的，即与Runtime逻辑的执行完全隔离开。具体来说，OffChainWorker能够实现如下功能：将计算的结果以交易形式提交到链上包含一个全功能的HTTP客户端，能够访问外部服务的数据可以访问本地node的keystore，这样便可以验证和签名交易可以访问本地的KV数据库，且在所有offchainworker中共享这个数据库本地的安全的熵源，用来产生随机数可以访问本节点的本地时间可以sleep和resume工作OffChainStorage是链下逻辑独立的存储空间，与链上的Storage是完全隔离开的。它具有如下特性：能被OffChainWorker读取和写入存储在node本地，不会传递到网络中其它节点去，不会参与网络共识被所有同时运行的OffChainWorkers共享访问。因此，可以利用其在不同的Workers之间通信能被Runtime代码写入，但是不能读。因此，可基于其实现一定的链上链下交互功能可被wasm环境外的node中的代码读取，因此能被RPC读取OffChainIndexing提供了在Runtime环境中，向OffChainStorage写入数据的能力。但是不能读取OffChainStorage中的数据。这为一些新的编程范式提供了可能性。其它还有一些，比如，完善的OCW集成测试框架等等。Substrate的OffChain特性非常强大，令人印象深刻。基于Substrate实现链基于存储共识的链下计算范式

从Arweave存储共识范式获得灵感，我们来看看在Substrate中如何实现类似基于存储共识的链下计算范式。整个Substrate框架其实分成三大块可编程逻辑：1.Runtime2.OffchainWorker3.Node容器和两大块存储：1.RuntimeStorage链上状态存储2.OffchainStorage链下存储详情见下图：

Substrate应用开发架构前面我们说过，Substrate中的Runtime只适合处理资产类逻辑，RuntimeStorage只适合存储资产类数据，它们不适合处理和存储其它大规模应用的逻辑和数据。在《为什么Web3.0需要区块链》中，有一幅Web3.0应用的通用架构图：

Web3.0App架构可以看到，在Web3.0应用中，链下计算和链下存储占据非常重要的位置。在本节，可以将这幅图针对Substrate做一细化，设计一套崭新的计算模式。我们理解：区块是应用的操作和输入数据的历史分段打包。其与数据库的SQL日志是类似的，区别在于：1.分段打包，离散化，邮戳化2.每一个分段都由多个节点参与共识确认，形成一个全网的共识，并在各自节点中敲定。敲定的过程，也是对每个节点中的交易池中的交易定序的过程每个块头包含三个Hash：1.前面一个块的Hash，以明确当前块是链到哪个块上的2.当前块中包含的交易序列的总Hash,merkle_root。用于验证，防止在网络传输途中被篡改交易3.当前节点中，全局链上状态空间的state_root。用于不同节点间全局状态空间的同步，每一个块都校验state_root，能让所有参与节点内部保持一个严格的同步的一致的链上全局状态。基于这些认识，我们可以基于前面的Substrate应用架构图，做出如下设计：将逻辑从Runtime中剥离。Runtime逻辑的作用仅在于：1.作为代理函数，将外部交易的调用的方法的名称和输入数据按一定规范写入OffchainStorage2.校验输入参数3.用于升级整个wasm代码。这个机制内建在substrateruntime中，不需要单独开发而链上存储不再需要了。真正的逻辑在OffchainWorker中执行。这部分代码是wasm字节码，由链上发交易统一管理升级，保证所有节点的一致性。OffchainWorker代码在块导入时执行。执行逻辑如下：1.Offchainworker入口函数执行2.检查offchainstorage中是否有符合某些键值对规范的存储内容，这个内容应该包括：方法名称，参数表。如果有，取出方法名称和参数表3.在Offchainworker中，按方法名称进行路由，并把反序列化后的参数表传到对应的路由handler中去。这些路由handler代码可以写在不同的文件中，在runtime主文件中引进来4.Handler可以使用offchainstorage中的数据，充分完成计算、聚合、重整化等工作5.Handler执行完成后，可以通过以下方式通知网关要返回的结果：a.通过offchainworker中的http请求能力，主动将结果发送给gateway，gateway监听到结果后，根据结果中的uri对应地将数据返回给前端b.将结果缓存在offchainstorage中。gateway定时轮询或监听substratenode的rpc接口，通过rpc接口从offchainstorage中取得相应结果，并返回给前端6.主流程结束。以上就是使用Substrate实现基于存储共识的链下计算范式的主要流程。这里需要解释一下为什么这种方式就是基于存储共识的链下计算：1.执行逻辑offchainworker中的代码，是通过substrate交易提交到链上，通过p2p网络，在各个节点通过验证后，更新到各个节点上的。这保证了执行代码的一致性2.Substrateoffchainindexing的一大特性就是：一致性。Substrate.dev中有一段话：”UnlikeOCWs,whicharenotexecutedduringinitialblockchainsynchronization,off-chainindexingispopulatingthestorageeverytimeablockisprocessed,sothedataisalwaysconsistentandwillbeexactlythesameforeverynodewithindexingenabled.”。有这个特性保证，就可以保证存储在offchainstorage中的对方法的调用和传入的参数在所有节点上是一致的。也即是保证了输入数据的一致性3.一旦Offchainworker开始执行，其是在链下执行的，与链上逻辑和存储完全分开。这也就对应了Arweave存储共识范式中的链下执行部分4.计算后的结果，并不会重新上链，这是非常重要的一点。在这方面，与Arweave存储共识范式也是相同的。好了，我们说了这么多，到底使用Substrate实现基于存储共识的链下计算范式有什么优势值得我们关注呢？下面一节，我们重点与目前已有的典型计算方案做一下对比。与目前典型计算方案的对比

与传统区块链计算范式的对比

这里，我们说传统区块链计算范式，指的就是链上计算范式。Substrate基于存储共识的链下计算范式的优势：1.Offchainworker计算不再受限于出块间隔的要求，可以实现长时间的计算或等待2.Offchainworker是独立的轻量级线程，同时可并发执行多个轻量级线程，以充分利用节点的计算能力3.Offchainworker具有访问外部服务的能力，也具有对外部产生副作用的能力，这点在实际的业务中，非常重要4.OffchainStorage，不再受链上设计制约，可以充分利用已有的数据库领域的历史积累和前沿创新，为大规模数据存储铺平道路5.OffchainStorage中的存储内容，可以分为三个部分。只有方法名调用和输入数据这块需要保持强一致性。逻辑运算结果需要访问一致性。在第三部分可以灵活地存取/缓存本地节点数据，以实现更灵活地编程6.用于Substrate链下计算的节点可以是整个区块链大网络节点中的一部分，这样可有效控制计算成本和存储成本，使得内容的处理和存储量级可以大规模的扩张Substrate基于存储共识的链下计算范式的劣势：1.SubstrateStorage目前是简单的kv数据库，失去了MPT结构天生的一些特性2.链上存储状态在每一个区块中都有state_root做同步，而Substrate链下计算范式则失去了这个特性。这样对存储状态的同步缺少强制性3.Substrate链下计算范式对计算结果的存储和中间状态的存储需要有一套自定义的规范，这些规范只是定义在offchainworker代码中，而没有其它节点强制验证的过程4.在Substrateworker中仍然要注意，诸如随机数和外部请求这些副作用，不能对需要一致性的存储区造成影响。因此在编写代码的时候，需要人为注意，需要有约定或者最佳实践与基于Arweave的存储共识范式的对比

Substrate链下计算范式的优势：1.链的集成度更高。Substrate节点本身组成一条区块链，不再单独需要一条链作为服务2.Substrate链的交易的验证过程比Arweave数据上传请求验证过程更细致。SubstrateRuntime中可以写交易的自定义验证代码，这是在链上执行的，而Arweave只是链上存储服务，做不到这一点3.Substrateoffchainindexing是从链上主动往链下写内容，而Arweave需要链下的计算客户端主动从Arweave网络上去拉对应的数据。这个过程显得不那么自动化，至少轮询的次数会多。另外，从Arweave上拉数据存在网络访问，可能存在网络访问失败的问题，如果数据量较大，那么下载完成也需要可观的时间。而Substrateoffchainindexing完全运行在一个节点内部，性能更好，集成度也更高，对开发者来说，掌控力更好4.基于Substrate节点，链上逻辑和链下逻辑是统一运维的，集成度更好，运维的可靠性更好5.Substrate链下逻辑强制使用wasm字节码来运行。在这点上，Arweave并没有要求。Webassembly是一套得到国际广泛支持的字节码标准，在其上有非常多的创新，生态在快速发展。从运行效率和未来生态来说，采用wasm来部署应用是一个优势简单来说，Substrate基于存储共识的链下计算范式，相当于实现了Arweave的一部分功能，但是没有提供Arweave永存的特性。这点上，如果将Substrate链的块历史上传到Arweave上存储，那么就充分地利用了Arweave的永存优势。Substrate链下计算范式的劣势：1.语言中不立。Substrate目前只能使用Rust语言进行开发，这意味着要使用Substrate实现Web3.0应用开发，必须学习使用Rust语言。而Arweave存储共识范式是语言中立的，可以用任何语言开发2.Substrate链下计算范式对编程方式有新要求，而基于Arweave存储共识范式的编程开发就与Web2.0开发类似，只需要调用Arweave相关的第三方服务即可3.Arweave实现的永存，对需要一致性共识的内容具有历史可靠性更好的优势。即使区块链项目倒闭了，它的那些内容还可以从Arweave上查到4.Arweave作为一个存储计算服务，类似于XaaS，在某些场景下会很方便我们前面描述过，Substrate链下计算范式需要人为做一些约定，在这点上，Arweave存储共识范式一样会遇到。这点上两者一致。与TheGraph/SubQuery的对比

Substrate是工具套件，TheGraph/SubQuery是服务。TheGraph/SubQuery是外部索引服务，主要用于对链上抛出的事件进行索引，并通过写Mapping方法实现事件信息提取，生成schema结构化数据存入数据库中。它们提供GraphQL接口，其内部本身也还是传统的SQL或NoSQL数据库。Substrate基于存储共识的链下计算范式的优势：1.集成度更高，TheGraph/SubQuery需要一个第三方外部服务才能获取数据2.Substrate的模式能提供的接口形式更灵活。在网关上配置RPC，Restful,GraphQL都可以3.Substrate更可控，更去中心化。TheGraph/SubQuery是一个服务，大家都用这个服务，对这个服务的依赖性也就更强，对其运行的稳定性也就有担忧。而Substrate这套工具，只需要对自己的链负责，别人出的问题不会影响到自己，自己出的问题不会影响别人。大家部署自己独立的服务，其实是更好的执行去中心化的过程Substrate基于存储共识的链下计算范式的劣势：1.目前将OffchainStorage替换/升级成支持SQL引擎的存储还没实现，索引还得自己来维护2.TheGraph能够对合约公链进行索引，而Substrate链下计算范式只适用于Substrate框架实现的Appchain3.TheGraph/SubQuery是对链上抛出的信息进行索引，链上写代码的方式该怎样就怎样，不受影响，也即没有侵入式。而Substrate链下计算范式对使用Substrate框架开发代码的方式有要求，要按照新的范式来写代码，所以是侵入式的对比可见，两者各有其适用的场景。TheGraph/SubQuery更适用于传统的基于合约的Dapp开发，Substrate基于存储共识的链下计算范式更适用于面向具体场景的Web3.0App的开发。与传统中心化应用的对比

由于链下计算的特性，传统中心化应用的那些成熟的基础设施，理论上来说都能被Substrate基于存储共识的链下计算范式应用所利用。Substrate基于存储共识的链下计算范式的优势：1.相对于传统中心化应用来说，Substrate的链下计算范式应用是去中心化应用，业务逻辑在各个节点上运行，并且通过区块链的强制特性保持了业务和运行结果的一致性。去中心化应用的一切优势，Substrate链下计算范式的应用都自动具有2.保障了开放性。前文提到的三个层次的开放性，在这个计算范式下，都能得到有效保证，这正是我们Web3.0追求的目标。任何一个感兴趣的人都可以运行Substrate节点，同步所有历史区块，跑出所有数据来。获取数据的人不一定要参与链的共识。而传统的中心化应用，在这三个层次上，都是封闭的Substrate基于存储共识的链下计算范式的劣势：1.同样的逻辑，需要在各个链下计算节点重复计算，并在每个节点都做存储。这在计算成本和能耗上，确实不是优势。但是由于参与链下计算的节点数量可以控制，这块的冗余性与传统中心化应用需要做的数据冗余和逻辑冗余，其实是类似的2.在基础设施层面，中心化应用能用到充分成熟的支撑大规模应用的基础设施，而Substrate链下计算范式的基础设施还不成熟目前SubstrateOffchain基础设施的不足

OffchainStorage目前只是最基础的kv数据库实现。要支撑真正面向实际的应用，基础设施还需要完善，有几个方向可以参考：1.Redis：Redis作为内存KV数据库，其内建丰富的数据结构的支持，使得其得到了各种领域大规模的应用2.Mongodb：Mongodb作为对象型数据库，特别适合某些领域3.Tikv+Tidb：作为新一代分布式数据库的代表，tikv在rocksdb之上做了分布式协议层，而tidb进一步在tikv之上做了SQL引擎层。这是非常有效合理的层次划分，这种理念也特别适合用在SubstrateOffchainStorage未来的改进上面。如果能够嫁接tikv/tidb到Substrate中来，那么tikv/tidb上面的很多生态设施都可以一并用到Substrate的链下计算上来，非常美好的局面另外就是代码编写的思维有些变化：OffchainWorker是定时器思维，或流编程思维。与传统的服务器的on_request/response思维有不同。这块儿如何最佳实践，还需要更多研究。对Web3.0App的定义

基于本篇前面章节的讨论，我们可以将区块链进一步做如下区分：用于处理链上资产的链，我们叫它资产链。用于处理Web3.0应用数据的使用链下计算范式的链，我们叫它数据链。基于这种区分，我们可以做出如下示意图：

这个图定义了：Web3.0App=DatasetChain+AssetChain的一部分+一部分Web2.0已有的基础设施数据链是Web3.0App的核心载体。基于存储共识的链下计算范式实现的Web3.0App，其位置处于区块链大生态的边界，一边连接资产区块链，一边连接已有的Web2.0基础设施。工具or服务？

在本文快要结束的时候，我们来简单做一下关于工具还是服务的思辨。这里的服务，指的是ToB基础设施层面的服务，而不是ToC业务型的服务。通常，你要完成一件事情，有两个选择：1.使用一个工具，在自己的电脑上运行计算，完成2.使用一个服务，在服务所在的服务器上运行计算，然后将结果返回给你这就是工具与服务的区别：计算，是在你自己的地盘内完成，还是在第三方的地盘上完成。云服务IaaS取得巨大的成功。从以前的自己买服务器托管至机房的模式，到云服务IaaS，开启了云时代，进而到现在的k8s，这条路目前还看不到尽头。而相对于IaaS，更上层的PaaS似乎并不成功。反而SaaS取得了一定的成功。服务的产生总是滞后的，开始总是先用一些工具进行实践。我们不要忘了，开启了Web2.0时代的是什么？是LAMP。而到目前为止，全世界仍然有30%的网站由Wordpress搭建。而JavaSpring框架、RubyonRails以及Nodejs等技术栈框架，在整个互联网的发展过程中，起到了相当重要的作用。这些框架给了你：1.在本地开发调试部署一个完整应用的流程和能力2.对你自己的代码逻辑有100%的掌控力3.在自己申请的云服务器上运行，自己对应用数据有100%的掌控力4.对互联网服务的运行成本可以有比较准确的预估5.其它等等这些框架没给你：1.随着业务的扩展，需要自己维护服务器集群2.需要自己维护服务器安全3.其它等等而第三方服务给了你：1.现成的功能组件，低成本的开箱即用2.完全无需关注运维的问题，需要的所有扩容都是自动完成的3.快速的试验环境4.其它等等第三方服务没给你：1.透明的实现2.准确的计算成本3.深入自定义优化的空间4.其它等等对于创业团队来讲，有些场景下力求短平快的服务启动，会倾向于直接使用第三方服务实现。而当业务规模扩张到一定阶段的时候，力求对各个组件的运行实现全面掌控，这时就倾向于用开发框架的配套组件自己来搭建服务了。当然实际情况是往往混搭起来使用。如果考虑文化、地域、国家政策等更多因素，具有自主搭建的能力的需求就更加强烈。最关键的一点是，各方能够自己比较容易地搭建相对完整的的服务，对于“去中心化”的实现，是一个非常重要的措施。如果所有人都在用同一个服务，这个服务是不是另一种层面的中心化？除非特别专业性的服务，一般来说，服务是可选项，开发框架才是根本立足点。不应忽视对开发框架的投资。结语

本文我们尝试为Web3.0App设计了一种面向大规模应用的技术路线：基于存储共识的链下计算范式。本文使用Substrate框架作为示例来讲解。理论上来说，任何框架都可以实现此计算范式——只有集成度、成熟度的区别。大家可以尝试将此计算范式引入到自己的框架中实践。本文由MikeTang和Outprog合作完成。我们的邮箱为：mike@oct.network，outprog@ever.finance，欢迎与我们联系。参考资料

:https://cryptobriefing.com/ethereum-defi-ecosystem-has-hit-3m-users/:https://mp.weixin.qq.com/s/vJM6TIZT2f-tnQ49cpMnrw:https://mp.weixin.qq.com/s/h76lTnFWlvpXs72aBVs3FA:https://near.org/papers/nightshade/:https://www.theblockbeats.com/news/24443:https://mp.weixin.qq.com/s/zXqJ0BGdEbvZypAwLWKmtQ:https://mirror.xyz/0xDc19464589c1cfdD10AEdcC1d09336622b282652/KCYNKCIhFvTZ1DmD7IpXr3p8di31ecC283HgMDqasmU:https://substrate.dev/docs/en/knowledgebase/learn-substrate/off-chain-features#off-chain-indexing:https://techjury.net/blog/percentage-of-wordpress-websites/#gref本文来自Web3Explorer

标签：SUBSNFT区块链LAYERSubstratumFYZNFT区块链工程专业学什么RO Slayers

区块链热门资讯