Substrate应用开发基础架构概述

1. 请求如何接入？是http，restful,还是rpc？ 2. 应用逻辑写在哪里，怎么写 3. 数据如何存储？用什么数据库？ 4. 当前服务如何调用其它服务（高级，异步）

将此模式应用到Substrate上，官方给出了如下结构图。在这个图中，Off-chain workers起到了非常重要的作用。

笔者通过对substrate的深度分析，在这里给出上图的一个细化图，基于此图，采用substrate进行Web3.0的开发就就豁然开朗了。

区块链应用开发更加复杂一些，因为涉及到链上链下不同部分的操作。对上图Substrate Application Structure的解释如下：

1. 外界使用JsonRPC与substrate node进行交互 2. （几乎）所有对链上状态的修改，都应该使用transaction提交到Runtime logic中进行处理 3. Runtime logic对Runtime的Storage具有完全的读写能力。对Offchain Storage具有写能力 4. Substrate node能直接对Offchain Storage进行读写 5. Offchain Workers能直接对Offchain Storage进行读写，只能读取Runtime Storage中的内容 6. Offchain Worker可以提交新的交易来实现对链上状态的更新 7. Offchain Worker可以请求外部服务，获取相应的数据回来，（异步）更新链上状态或者本地存储 8. Substrate node可以通过Runtime API机制对链上状态进行读取，也可以传参数进Runtime logic以更灵活地读状态 9. 链上状态的变更，会生成event，发送到substrate node中，经由rpc被外界监听到

基于Substrate这种清晰的结构，我们可以设计一些不同的Web3.0应用的编程范式。比如其中一种是：

1. 所有修改状态的操作，都提交到链上处理。但是链上不一定存储所有信息，可以通过Offchain Indexing存一部分到local storage(Offchain Storage) 2. 所有查询状态的操作，可以只通过local storage查询。或者链下与链上 storage相结合的方式查询（链上存储代价较大，而链下存储代价小）。 3. Offchain层可以只需要专注于substrate体系本身。而不受外部接口和数据的影响

还可能出现一些疯狂的玩法，比如：

- 直接使用substrate node和offchain storage,offchain worker部分，实现一个传统的应用服务。完全跟区块链没有关系 - 所有交易先提交到offchain storage中，由offchain worker监听后，来代理提交交易？：P

不过现在Offchain Storage的能力和接口还比较弱。作为kv数据库，功能比redis之类差太远。而如果能有一层sql数据层就更完整更好用了——能否嵌入一个sqlite进去呢？

热点：web开发