Ethereum ❤ Witnet

Ethereum smart contract developers know that smart contracts are self-contained in their own supporting blockchain. Contracts have very little capability to interact with other blockchains, the Internet and the rest of the world . Currently, external information can only be fed into Ethereum contracts by trusted authorities (probably, the developer of the contract) who need to sign claims about the state of the world. These are called “ oracles ”. But relying on a single oracle completely defeats the point why smart contracts are used in the first place. It’s not “trustless” and leaves too much space to contestation, repudiation and tampering.

Mission-critical smart contracts aren’t viable without decentralized and trustless oracles.

That’s exactly why we started building Witnet : a decentralized oracle network whose claims are reliable not because any kind of authority but because they’re made by combining all the claims coming from a number of anonymous players who are incentivized to be honest and compete against each other for rewards . Those rewards are paid by the requesting parties using the Witnet blockchain’s native token: Wit . Now you’ll be wondering: “If this Witnet thing has its own blockchain, how on Earth will Ethereum contracts interact with it?”

Ethereum bridges, a quick overview

The Witnet whitepaper explains that Ethereum bridges are:

“Witnet nodes which also run an Ethereum node, have full access to the Ethereum blockchain and have the capability to operate with ether and make contract calls”.

In the Witnet ecosystem, Ethereum bridges are in charge of two missions:

Ethereum bridges, in practice

An example use case

Let’s say Alice and Bob want to create a smart contract paying one or the other depending on how’s the weather like tomorrow at noon in London, UK.

The Witnet Bridge Interface contract

The WBI contract helps the bridge nodes discover new Witnet requests in the Ethereum blockchain without the need to interpret every transaction in the network. It also correlates the requests with the results and acts as a escrow for the rewards offered to the bridges. In their call to the WBI contract, Alice and Bob will attach enough ether to bear the cost of the Witnet request . They must also specify the Witnet “replication factor”. This is, how many witness nodes to employ for the request. The higher the replication factor, the greater the certainty but also the higher the price. The WBI contract will mantain an index of all the requests made through it so that when they get resolved it can route the results back to their requesting parties. Using the same “miner selection algorithm” explained in the Witnet whitepaper , during each Witnet epoch (every 90 seconds) a different __ bridge node (an “eth-to-wit epoch leader” ) wins the right to self-assign all the unasigned requests, post them into the Witnet blockchain and claim the ether reward:

Block header relaying

In order for the WBI contract to verify Witnet Proofs of Inclusion and Proofs of Leadership , it needs to be aware of all the Witnet blocks to date . That’s possible also thanks to bridge nodes. For every Witnet epoch, one bridge node wins the right to act as a block header relayer . Block header relayers are in charge of disclosing new Witnet blocks to the WBI contract. In doing so, they’ll get a percentage of the ether fees attached to all the eth-to-wit requests that ended up being published in that block. This scheme is expected to consume a significant amount of gas, as proof verification will likely require quite a bunch of hashing rounds. But it completely succeeds achieving its purpose of allowing the WBI contract to trustlessly verify that the request was published to Witnet by the contract caller.

Reporting the results

Once a request has been resolved by the Witnet decentralized oracle network, we get a single result value . To continue with the weather contract example, let’s say the result value is “sunny” . Again, using the same “miner selection algorithm” explained in the Witnet whitepaper , during each Witnet epoch a different bridge node is elected as “wit-to-eth epoch leader” . It’ll be in charge of calling the WBI with the result value as a parameter. When calling the WBI, any competent bridge node holding epoch leadership should be able to provide the following parameters:

Want to know more about the use cases of Witnet?

Don’t miss the next article in the series: You can also: