解决链上同步问题？Pick下这个方案

Oracle分类

按照同步与异步方式，Oracle大体上可以分为：

●多笔交易，异步方式

例如，user request交易先上链，Oracle response 交易再上链，最后触发再出发用户真的任务执行。比如传统的Oracle采用回调方式，Oracle response上链后执行用户的回调任务。

●多笔交易，同步方式

比如，user request先被广播，但将处于等待状态，当Oracle节点发出Response交易时，再将request交易放在response后打包上链执行。

●一笔交易

拓展user request交易，再将Oracle节点请求到的数据，存入到requset交易或区块的拓展字段中，再打包上链执行。

今天我们将介绍一种，使用链上条件定时器来实现同步方式的Oracle。

条件定时器

概念定义

●对象

特定的交易才能触发定时器（指定交易的Sender或交易hash），不像传统定时器，在区块链上，任务的触发执行，都需要交易进行触发。

●条件

在特定对象交易中，调用时所进行的条件检查，用户可以自定义设置检查条件，如Oracle的response数据阈值条件等。

●任务

一个任务即是在条件定时器中注册的交易，当条件被满足时，将触发该交易的执行。

一个任务必须在条件定时器中被注册，可通过在交易的联合签名者列表中（Tx.Cosigner）添加条件定时器合约的hash值。该任务（交易）将被当成普通交易打包上链，以及被收取费用，但是不会被立刻执行。只有当条件定期器被触发时，才会被自动执行该交易。

一些约束条件

●一个对象只能触发一个任务执行

●一个任务只能被触发一次

●在任务执行过程中，不能再触发别的任务执行

●需要支付一定费用来注册条件定时器

概括之，链上条件定时器，注册在条件定时器的交易（尚未执行），当被后续的某一笔交易满足其触发条件时，将触发之前注册的交易进行执行。

一个条件定时器原生合约定义示例：

class ConditionTimerContract: NativeOnctract
{
private Map<Task, Object> timers;
private List<Task> triggeredTasks;

public bool verify(){
// verify the tx.fee >= basic fee
}

protected registerTimer(task, object){
// Only can use native transaction to register or other native contract
}

public bool activeTimer(task.hash){
// check object
}

@override
public list<tx> PreExecuteBlock(blockTxs){
// register condition timer...
registerTimer(task, object)
}

@override
public void PostExecuteBlock(blockTxs){
// execute tasks which be triggered
}
}

工作原理

原生合约

作为一种系统内置的合约，具有相对比较大的权限，可以在区块执行前后做一些特殊的任务操作。

原生交易

是一种特殊的交易，交易发起者（Tx.Sender)或联合签名者(Tx.Cosigner)包含原生和合约的hash值，即原生交易。

然后，我们将介绍通过使用原生合约的条件定时器(ConditionTimerContract)和Oracle(OracleContract)设计方案。

Oracle的工作流程

1. 首先，用户发送Oracle Request交易，设置OracleContract.hash作为该交易的联合签名者, 实际上该交易将作为原生交易。

2. Request交易，将被当成普通交易打包上链。

3. 由于是原生合约，区块执行前，将触发OracleContract将会调用条件定时器合约ConditionTimerContract的注册方法registerTimer, 完成该Requset交易的注册，并从待执行交易列表中移除，其意味着该交易不会被当前区块所执行。

4. 当Oracle nodes检测到新区块包含Request请求交易时，开始请求数据，并发送携带数据和签名的Response交易上链。

5. Response交易作为普通交易，上链执行时，将会调用OracleContract的AddResponse方法，将Oracle节点请求的数据收集起来。

6. 当Oracle的请求阈值条件被满足时，将之前注册的Request交易添加到可执行交易列表中，最终完成对用户发起的Request交易执行，完成数据访问请求。

链上聚合数据

无论我们选择哪种Oracle的数据聚合方式，都需要将Oracle节点的数据跟签名上链。因此，我们将采用链上聚合数据的方式，Oracle节点的Response消息将被当成普通交易上链，将调用OracleContract的AddResponse方法。

聚合方式可以有很多种，这里我们采用的是之前方案签名阈值方法，详情可参考:

https://github.com/neo-project/neo/issues/1273

其他处理流程，与普通的Oracle方式类似，就不再做详细介绍。

优势

1. 解决了同步等待问题，即用户的Request交易不必等待Response交易后才能上链。

2. 对比起传统回调方式，保持了同步方法，对于合约开发者更加便捷。

劣势

破坏了区块链打包交易上链就执行的规则，执行顺序具有不可预测性。

*注意，该方案并非Neo3最终实施方案，而是开发过程中一些发现解决链上同步问题的一种可能方式。

本文来源：Neo智能经济
原文标题：解决链上同步问题？Pick下这个方案

—-

编译者/作者：Neo智能经济

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。