A New Oracle Scheme Using Conditional Timer
In terms of synchronous and asynchronous modes, Oracle can be roughly divided into:
• Asynchronous & Multiple transactions
The user request transaction be packaged on chain first, then the oracle response transaction which attached with data, be packaged again, and finally trigger to execute the user’s real task. Like the traditional oracle, using callback mechanism, and the user’s task is executed after the oracle response executed.
• Synchronous & Multiple transactions
The user request transaction be broadcast first, but will be waiting for the oracle response transaction. And oracle response will be executed before the user request transaction.
• One transaction
The user request transaction be broadcast, and oracle node will package the response data into the request transaction or consensus node put the response data into the new block data field, and the request transaction will be packaged and executed.
Today we are going to introduce an synchronous Oracle that using onchain conditional timer.
Conditional Timer
Some conceptual definitions:
• Object: Specify the transaction that can trigger the conditional timer (specify Sender or transaction hash). Unlike traditional timers, on the blockchain, any execution on-chain requires a transaction to trigger.
• Condition: In the contract called by the object’s transaction, the satisfaction conditions for the trigger task can be customized, such as the approval threshold condition of oracle contract.
• Task: A task is actually a transaction which registered in the conditional timer contract, will be executed, when the condition is satisfied.
The task(or transaction) should call the conditional timer contract to register the timer by adding the hash of conditional timer contract as a cosigner. Then the task will be packaged just like a normal transaction, and will be also be charges(advance payment), but it’ll not be executed at once. Only when the trigger condition is met, the task will be automatically executed at the end of block execution.
Some constraints:
• A object can only trigger one task
• A task can only be triggered once
• During the task execution, no other task can be triggered
• Need to pay certain fee to register the timer.
In summary, the conditional timer is a transaction on the blockchain. When the execution meets a certain condition, it will trigger another transaction that is registered in advance.
There is a conditional timer contract demo:
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
}
}Working Mechanism
Native Contract
A type of system built-in contract, has some relatively special permissions, can be before and after the block execution, to perform some special tasks.
Native Transaction
A type of special transaction. The Sender or Cosigner of the transaction contains the native contract address, which is the native transaction.
Then, we’ll enhance the current oracle by using OracleContract and ConditionTimerContract.
The work flow of oracle
1. User send the oracle request transaction and add OracleContract.hash as a cosigner. It’s actually a native transaction.
2. The request transaction will be packaged on blockchain.
3. As it’s a native contract, it’ll active the OracleContract. When oracle contract execute PreExecuteBlock method, it’ll invoke the registerTimer method of ConditionTimerContract to register the oracle request as a conditional timer. Then remove the request transaction from the execute transaction list, which means the script of request transaction will be executed.
4. When oracle nodes received a new block which contains oracle request transaction, it’ll request data by https or neofs, then send oracle response transaction.
5. After the response transaction packaged, it’ll invoke the AddResponse method of OracleContract.
6. When the approval threshold condition is met , it’ll trigger the timer registered by advance. Then, the oracle request transaction will be executed in PostExecuteBlock of ConditionTimerContract.
Aggregate data onchain
As no matter which way we choose, the oracle node’s signature must be onchain. We’ll make oracle response as a normal transaction to invoke the AddRespnose method of OracleContract.
OracleContract will make a consensus/agreement onchain by using the method discussed at: https://github.com/neo-project/neo/issues/1273.
Other processes, such as election nodes, incentives, etc., are traditional.
Advantage：
• The synchronous waiting problem is solved, that is, the user request transaction have to wait for the response transaction before it can be packaged.
Disadvantage：
• It breaks the block chain sequential execution rule, and the execution order is unpredictable.
Note: This solution is not the final implementation of Neo3, but a possible way to solve the synchronization problem on the chain that was discovered during development.
Author: Chuan Lu
