【eos】解决链上同步问题?Pick下这个方案
摘要:Oracle分类按照同步与异步方式,Oracle大体上可以分为●多笔交易,异步方式例如,user request交易先上
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下这个方案 | 火星号精选
- 免责声明
- 世链财经作为开放的信息发布平台,所有资讯仅代表作者个人观点,与世链财经无关。如文章、图片、音频或视频出现侵权、违规及其他不当言论,请提供相关材料,发送到:2785592653@qq.com。
- 风险提示:本站所提供的资讯不代表任何投资暗示。投资有风险,入市须谨慎。
- 世链粉丝群:提供最新热点新闻,空投糖果、红包等福利,微信:juu3644。