Off-chain computation via Oracle

On chain computation is sometimes too expensive for critical data. One possible solution is to outsource the computation off-chain, like with the help of an external Oracle system. There might be two solutions for such an off-chain computation: 

-  with the help of a trusted external Oracle: of course the problem is that the off-chain actor has to be trusted. 

- with the help of decentralized Oracle system: here several independent off-chain actor would compute the result and they are incentivized with like game theoretical tokenization that produce the correct result. 

Update an Ethereum smart contract periodically with Oraclize

Ethereum smart contracts are normally not able to start automatically on a timely basis, there should be an external service that calls the contract periodically. You can however use Oraclize as an external service for such a use-case. Although Oraclize is an external service that one has to trust, but it works in a relative secure way providing different kind of security guarantees for the execution. Example code can be realized by the following two functions in a smart contract that is inherited from a version of the OrcalizeAPI, like from usingOraclize:

    function __callback(bytes32 myid, string result) {

// SECURITY CHECK

        if (msg.sender != oraclize_cbAddress()) revert();

// SCHEDULE NEXT UPDATE

        scheduleUpdate();

    }

    function scheduleUpdate() payable {

        if (oraclize_getPrice("URL") > this.balance) {

            LogNewOraclizeQuery("Not enough fund");

        } else {

    // NEXT UPDATE IS SCHEDULED IN 60 MIN

            oraclize_query(60, "URL", " .. test url ..");

        }

    }

Experimental implementation can be found under my github repo. Certainly, this is not necessarily the cheapest way for the operation, depending on the exact business logic operational cost might be extreme high. As a simple example, considering a simple code time of writing, the one simple transaction cost of incrementing a state variable with the cost of the service is around  0.01 ether, 

Creating native decentralized oracle with Hashgraph

Hashgraph provides the possibility to realize a fully decentralized Byzantine native oracle service. Let we imagine that we want to call an external data source in a smart contract function, like

function () {
 state = external_oracle("http://external_datasource/%22)
}

At event propagation each {N1, N2, ... Nm} node has to call the http://external_datasource/ independently from each other producing a {V1, V2 ... Vm} possibly different values as results for the calls. These values are propagated, voted and ordered by the events together with the transactions. 

As soon as both the transactions and the values are communicated ordered and voted (so practically at applying to the state), we can use the following function to calculate the result of oracle: 

external_oracle calculation:
step1: filter from {V1, V2, .... Vm} the extreme big or small values, like 33% of all of the values
step2: do an average of the non-filtered values
step3: the result of the function is the average

Since at the time of the calculation each node sees exactly the same set of {V2, V2, ...Vm} values and the external_oracler calculation is deterministic, at each state there will be exactly the same value calculated even if they are calculated independently from each other. 

Since the communication architecture (Hashgraph) is Byzantine fault tolerant, probably the Oracle itself will be probably Byzantine fault tolerant as well (might require some more considerations)

The algorithm can be cryptoeconomically further secured, like giving a bigger transaction fee for nodes producing values that are less far for the end result of the external_oracle calculation function (providing a Schelling point from a game theoretical point of view).

Demo implementation can found in the following github repository.

How to create real decentralized random oracle with Hashgraph

Real random oracle is one of unsolved Holy Grail of decentralized networks. Hashgraph technology promises perhaps a real possibility to solve it. A pseudo algorithm should be the following:

Let we assume that we have a smart contract function that assigns to a state a new value, like

function() {
 state = new_state
}

we basically do not call this function but create a transaction, like

TR: call function() signed by private_key of some account owner.

This transaction is propagated on the network by the gossip of gossip protocol, probably checked by every node, goes through a virtual voting and ordered with other transactions into a common order. Only after that, it is applied to the state (independently if it is an account based system or an UTXO based).

so let assume a function that calls a real native decentralized random oracle, like the following function:

function() {
 state = rand()
}

and a transaction that calls this function.

As soon as a node "sees" the transaction of function that contains a random oracle call, the node call its internal native random function and creates a ri random value, which is further propagated on the network similarly as the transactions. As a consequence there will be a set of {r1, r2, .... rN} random values propagated on the network, one for each node.

As a next step, we wait until there is a consensus and an order of these random values, so every node will see exactly the same order of these individual random values, like r4, r3, r1, r2 ... rN. And at this point we give a value to the random function as rand() = merkle_root(r4, r3, r1, r2 ... rN). As merkle_root is a deterministic function and and each node sees exactly the same order of individual random numbers, even if rand() is calculated independently at each node it will produce the same result.  

Certainly, the real quality depends on the individual random numbers as well. However as Hashgraph is Byzantine fault tolerant, if more than two third of the nodes provide a relative good random number meaning either cryptographically secure or pseudorandom, the result will have probably the same attribute, meaning cryptographically secure or  pseudorandom.

Experimental implementation can be found in the following github repo.