一块链习是首家区块链技术学习社区，提供最系统的区块链技术课程学习，定期出品有深度的技术观察 + 评论。

《Substrate区块链开发入门》是由Parity 和一块+ 联合出品的全球首个Parity 官方合作课程系列的开发者入门课程。

每周日晚8点，作为课程内容知识拓展——大咖技术分享会，由波卡生态的优质项目方代表自发轮流在线上进行分享，为学员们详细解读一个 Substrate 技术相关内容。

上周日晚，由 Crust Network CTO 核心开发者—— 子琨 在直播间为大家带来第三讲「Substrate Offchain Worker机制与实战应用」。

内容复盘如下

大家好，我是子琨，之前在浙大 CCNT lab学习分布式系统和云计算，后来就职于微软，做Azure Kubernetes团队容器化服务，现在是Crust Network CTO。我的Github地址：zikunfan。

Crust本身是做去中心化存储的，所以想从链下存储的角度出发，谈一谈Crust Network在实战应用substrate的过程中对于Offchain Worker这块的经验和遇到过的问题。

| 什么是 OCW

有一个很有意思的观点，就是在计算机行业看来，区块链技术和所有的计算机技术是背道而驰的，因为计算机技术是想方法用有限的资源做更多的事情，而区块链是用同样的资源做相同的事情从而达到去中心化信任的目标。

随着区块链的发展，越来越复杂的逻辑被期望放到链上，也就是说，大家都觉得用区块链解决信任问题的同时也要能处理现实问题，所以scalability就顺理成章成为了区块链中最为重要的技术目标，ETH2.0 Casper，Polkadot平行链，Cosmos跨链这些都是在解决这个问题。

思考两个问题：

一、什么该被放到链上，什么不该被放到链上。on-chain logic i会被整个网络执行。所以简单的来讲，需要全网达成共识的部分（共识，交易，区块）我们是一定要放到链上的。BTC最早就是简单的这么设计的，但复杂的区块链越来越多想要更多。而更多的复杂计算，巨量存储，隐私计算等等，这些都不应该被放到链上。

二、Oracle的缺点：

1、Off-chain mechanisms是独立的，和链不绑定的程序，其往往是中心化的服务，这违背了去中心化的愿景。

2、Offchain 通常通过RPC调用来完成，这会非常慢并且不可靠。

| 为什么我们需要 OCW

• 更高效

• 更安全

• Forkless Upgrade

OCW作为substrate中的重要模块，其本身就被Include到了Substrate的WASM环境中，这样在一定程度上保证了全网执行的一致性，并且跟随substrate一起升级。

这也就在根本上定义了OCW并不是作为独立程序运行去aware链，而是作为链的一部分存在的。

并且，其本身还自带了支持SignedExtrinsic的机制，也就是说，传统oracle需要去签名发送交易的过程，OCW都可以一键通过将private key set到本地节点而完成。

再者，OCW并不是通过RPC调用，而是WASM之间的hook直接进行链上交易的。

OCW中目前支持的特性：

• 本地KV 数据库

• 功能完善的HTTP客户端

• 安全的随机数生成算法

• 本地精准时间

• 本地keystore签名和验证算法

• 链上回掉

| OCW的运行机制

• 轻松读取链上状态

• 提交链下运行结果

刚刚讲了，OCW其实是和WASM Code绑在一起的，但是又有所区别，因为Runtime的WASM Code是会校验世界状态（World State）的，而OCW的WASM仅仅是一段独立运行的VM线程。

Runtime interface是substrate里面一个很独特的接口，其链接了WASM和Native，也是OCW的底层实现逻辑，但在runtime interface中，你可以定制任意的native接口，和链上的WASM进行交互（平行链是不行的），但是在OCW中，对其调用进行了限制，刚才说的几类，所以其本身的native环境（平行链是可以的）。

Callback要注意 Unsigned extrinsic（其本身需要自定义一套验证逻辑）。

 | OCW的适用范围

• Long Running Task：substrate中的Offchain Phragmen代码

• 合并链上状态，缩减链上状态爆炸的问题

• 链下通知系统：substrate中的im_online模块

 | 处理状态爆炸

Crust对OCW的第一个实际应用是，利用OCW来处理链上状态爆炸的问题

先讲一下整体的sOrder流程：

1、On-chain：用户直接对着链进行下单

2、Off-chain：用户带着链上orderid传递文件

Locally，是对用户的订单进行打包，然后逐步上链验证。

三个难点：

1、Crust设计了一套Offchain的接单系统

2、在offchain订单达到4GB之后提交一个“大”订单到链上

3、在ValidateUnsign的部分，Crust设计了一个Delayed Proof Function，Delayed proof function中处理了节点恶意提交订单的情况（会被惩罚，具体是整体订单价值的2%）。所以用户在打包订单的同时，需要有文件被存储，并且链上已经存在匹配的用户锁定金额的交易。

  | 处理复杂的链上计算

Crust对OCW的第2个实际应用是，利用OCW来处理链上的复杂计算（长时间状态更新任务）的问题，就像kusama和polkadot中的offchain phragmen算法一样。

先讲一下这个Long Running Task是什么，这就涉及到MPoW中File Inspector的工作机制：基本上，它将所有文件根哈希存储在encalve内，encalve是CPU内受信任的硬件运行时模块。并定期要求外部文件系统提供特定的文件片段，并在Enclave内对其进行检查。然后对检查的结果在Enclave内部进行签名并且最终形成工作量报告提交到链上。

而其中的工作量报告包含每个节点的文件存储信息，我们需要使用此信息来更新相应存储订单的状态。这可能会花费很多时间来处理更新，因为其索引结构在链上，是一个反向索引的Hash Map。

而利用OCW，我们可以把这个更新操作放到链下，不断读取链上工作量报告，并不断向链上提交更新的结果，并交给链去验证即可。

扫码进直播间，回看完整分享！