Nervos CKB 预言机的初步探索

中文 CKB 开发与技术讨论
1

Nervos CKB 预言机的初步探索

众所周知，预言机（Oracle）是保证 DeFi 可以正常运行非常重要的一环，所谓的预言机其实就是把链外的数据通过某种方式传递到链上，DeFi 依赖的更多的是各种链外 Token 交易对价格，例如 BTC/USDT，当然预言机不止可以提供交易对价格，理论上任何数字信息都可以通过预言机传递到链上。

可能很多人会有疑问，区块链为什么不自己主动去获取那些链外的数据，而非要借助预言机呢？这里就牵扯到区块链很重要的一个特性了，就是确定性。何为确定性呢，简单来说就是区块链上的智能合约执行结果都是确定性的，否则就没法达成共识了。

而确定性就使得区块链智能合约无法直接访问链外的数据 API，因为不同的时间、环境等条件下，得到的链外数据很有可能是不同的，例如不同时间获得的 Token 交易对价格就很有可能是不同的，如果网络环境不好，数据请求就会有不同程度的延迟，甚至请求失败，这些都会导致合约执行结果充满着不确定性，因此区块链的智能合约就必须是一个封闭系统，它只能访问链上已有的数据，而不能访问链外的数据。确定性还会引出另外一个问题，那就是无法在链上直接实现随机数，因为随机数本身就是不确定的。

那有人可能会说了，我通过发交易把链外的数据发送到链上不就行了，当然这个方法是可行的，而且预言机本质上也是类似的思路。但是这里会引申出很多问题，我们以 Token 交易对价格为例，比如说别人凭什么相信发送者发的交易对价格不是伪造的或者不是过时的，再比如别人凭什么相信发送者不会因为某种主观或者客观的原因中途停止了交易对价格的持续更新，类似的问题和挑战还可以举出很多。

简言之，如何让别人相信你可以诚实、不作恶且持续地更新交易对价格，只有解决了这个问题，别人才会在链上放心地使用你提供的交易对价格数据。

那么对于 Nervos CKB 来说，如何实现可信的预言机呢？

CKB 上的合约开发

目前我们看到的绝大多数预言机都是基于 Ethereum，原因我想无外乎这几个，Ethereum 支持图灵完备的智能合约、Ethereum 的开发者和用户量都比较大、Solidity 合约开发门槛低等等，而对于 BitCoin 来说，虽然它的知名度和影响力可能比 Ethereum 还大，但是合约的非图灵完备性是其致命伤，因为这会限制很多复杂的计算，导致无法实现相对复杂的预言机合约。

而对于 Nervos CKB 来说，由于包含了基于 RISC-V 的 CKB-VM（你可以将它看成是一个微型计算机），因此可以在其上开发任何复杂的智能合约，不过相比 Ethereum 来说，CKB 更接近于 BitCoin 的 UTXO 模型，而非账户模型，这两种模型的不同，可能会让熟悉 Ethereum 合约的开发者有些不适应。

具体来说，Ethereum 是链上计算，合约调用本质上是通过发送交易指定要执行的合约方法和对应的参数，其他一切都由链上完成，而 CKB 是链下完成合约的计算，链上验证，这样会大幅提高交易上链速度，提升交易并发性和 TPS，而代价则是需要同时实现链下的 Generator 和链上的 Validator，无疑提升了合约开发的门槛。

为此 Nervos CKB 的 Develop Tooling 团队正在开发更多工具来方便开发者开发 CKB 合约，目前已经有 Lumos / Capsule / Polyjuice / animagus ，可以为开发者在 Generator 和 Validator 两侧的开发提供帮助，未来还会有更多的工具和框架，敬请期待。

CKB 上的初步探索

说回到预言机，要解决预言机上面提到的挑战，就必须要建立一套安全可靠且可信的机制，比如说多个参与方来往链上发送交易对价格数据，建立监督机制，一旦有人作恶或者服务不可用，就会受到惩罚，再比如发到链上的数据要携带摘要和签名，这样链上可以验证数据的完整性和来源。

为此 Nervos CKB 的 MAKE 团队和 Nervos 的预言机合作伙伴配合做了一些尝试，目前我们和 Band Protocol 和 ChainLink 都有合作，而我们的尝试是基于 Band Protocol 和支持 Open Oracle 协议的 OKEX Oracle，未来也许我们还会加入 ChainLink 和 Coinbase Oracle。

Band Protocol 基于安全性程度分类三个等级，分别为 Level1 / Level2 / Level3，具体可以参考 https://hackmd.io/Y_Ckq7woQbi_Kji8epX66w 。目前我们的尝试是基于 Level1，也就是直接从 Band Protocol 的链上取数据，不做校验。而 OKEX Oracle 的交易对价格数据会同时附带相应的签名信息，我们会在 CKB 链上做验签，所以其会有相对更高的安全性。

我们的尝试分两部分，一部分是从 Band Protocol 和 OKEX Oracle 获取交易对价格数据，并通过发交易的形式将其上传至 CKB 链上；另一部分持续监测链上交易，根据相应的 Oracle Lock Script 解析相应交易中的 Data。

先说第一分部分，来自 Band Protocol 和 OKEX Oracle 的交易对数据分别有 10 个和 8 个，其中有 BTC/USDT、ETH/USDT，也有 BAND/USDT、DAI/USDT等，为了提高并发性，我们用两个不同账户，分别生成了 10 个和 8 个 Live Cell，然后每出一个新块就用最新的交易对价格信息（包括价格和时间戳）更新 Cell Data，每次的数据更新都会用一笔交易（Outputs 对应要更新的 LIve Cells）完成，从而提高并发性。对于 OKEX Oracle 来说，每次上链的数据都会在 Lock Script 对应的合约中做数据校验和验证签名。

再说第二部分，我们利用 ckb-indexer 和 lumos 持续监测 CKB 链上的交易，过滤出包含 Band Protocol 和 OKEX Oracle 的交易，过滤条件就是上述交易发送者的 Lock Script 和以 OKEX Oracle 验签合约为 code hash，OKEX Oracle 公开的公钥哈希为 args 的 Lock Script，解析其 Data（两种 Oracle 的解析方法有所不同），并存储到服务端的数据库中，同时提供相应的 api 接口（接口数据包含交易对价格、价格时间戳、数据来源以及对应的 CKB 交易信息）供 web 端调用并展示，因此这部分包含了 server 和 web，目前我们已经将其部署到 https://oracle-bridge.ckbapp.dev/。

由于我们只是初步尝试 CKB Oracle，或者说这更像是一个 MVP（最小可用原型），并非是一个可以直接商用的产品，因此我们并没有引入多个服务去更新 Oracle 数据，也没有引入监督机制，希望我们这个 MVP 尝试可以帮助社区开发者降低开发类似应用的门槛。

结语

经历过流动性挖矿的起伏，我们逐渐认识到 Oracle 的重要性，同时也看到了 CKB 在合约开发上工具不完善的现状，为此我们还在努力提供更多更好用的工具、框架、Demo和教程，希望让更多开发者更容易在 CKB 上实现他们的 DApp，因为 CKB 相比 Ethereum 有更低的交易费，更高的 TPS，更好的并发性，同时 CKB 的矿机已经进化到 ASIC，安全性已经有非常大的保证。当然我们相比 Ethereum 的合约开发体验还有一些差距，希望我们这个关于 Oracle 的尝试可以帮助更多开发者来 CKB 上实现他们的想法。

源代码和 MVP 页面链接

4 Likes