解决链上同步问题?Pick下这个方案 | Neo专栏

作者:卢川

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最终实施方案,而是开发过程中一些发现解决链上同步问题的一种可能方式。

发表评论

Top