One core constraint of Blockchain-based consensus is the need to operate within a walled garden. Everything must be predictable, reliable and reproducible. This fact is limiting for most projects. What if you want to develop applications that interact with the outside?
- A Facebook API to build a Chatbot on Blockchain;
- An Amazon AWS API for your Blockchain DApp;
- A Payment API to accept dollars on your Online Store.
For these cases: we design bridges between the “safe and secure” blockchain and the outside world.
Constraints of Smart Contracts on the Blockchain
Smart Contracts are tiny robots living in the Ethereum Blockchain. They live in a wallet that anyone can interact with. When someone sends a transaction to the wallet, miners execute the code of the Smart Contract. This code can update the blockchain and send more transactions.
These Robot Accounts make the blockchain “smarter”. We can write programs that react to what happens on the blockchain.
But they have one limitation, the Smart Contract Program must be Pure: its results depends only on the input of the program (the transaction). This is the source of Decentralized Consensus. Any member of the network can replay the whole history of the system and ensure its legitimacy.
This means that our Smart Contract must be Side Effect Free. It cannot interact with the outside world.
A counterexample: say a Smart Contract accesses a Weather API to take a decision. No miner would get the same result. It would be impossible to replay the transaction and prove that it is genuine.
We use Bridges to solve this. They expose the outside world through Oracles.
Blockchain Bridges to the rescue
A Smart Contract exposes an API that maps to the external system. This Smart Contract lives in the walled garden of the Blockchain. Ethereum for example. One of our server would observe this contract. When a transaction hits the contract of interest: the server forwards the request to the outside world.
Later, our server transmits the result of the query back to the Smart Contract. We may trigger transactions (callbacks) to forward the results to Clients of our Smart Contract / Bridge / API.
So part of the system lives in the Ethereum Blockchain and provide the Source of Truth. Another part of the system would watch and react much like a real human being would.
In a regular stack: this Smart Contract is the equivalent of your HTTP API Frontend. This API hides the complexity of your stack to customers.
Here are a few examples of projects that bridge between the Ethereum Blockchain and their platform:
Beyond the Void
They use the “basic” use case. They connect the ETH Blockchain with their Unity Game Servers:
One of their Smart Contract listens to incoming transactions on the ETH Blockchain. One of their servers translates exchange of their NXC token into transfers of assets in the Game World.
They use a slightly more generic system where you own the Bridge Contract:
When you deploy a distributed application on iExec, you also deploy a Smart Contract on the Ethereum Blockchain.
One of iExec server listens to transactions concerning this Smart Contract and forward requests to their platform. iExec lets you exchange their RLC token with Decentralized Computation time ala AWS.
You can look at their code on github: iexec-bridge.
Oraclize is a meta oracle that lets you access external resources without you having to build your bridges. They promise a generic solution to the need of creating oracles. They have a brief and interesting article about their platform on medium.
They are on github too: ethereum-bridge.
Storing and accessing data in Ethereum is reliable but costly. We have a strong and expensive consensus that we use to orchestrate other systems. The examples we saw are practical examples of the “metadata use case“
With Oracles we can “expand” Blockchain systems. But we are losing decentralization! When a Smart Contract starts to interact with an external API, it becomes dependent on a single entity, and it is not decentralized anymore!