If smart contracts and blockchain technology are going to disrupt anything, they need a way to speak to the outside world. Also known as the blockchain oracle problem, blockchains can’t gather off-chain data without help. Enter the Ethereum oracle — or a way to connect smart contracts with outside information. Until now, there are only a few blockchain oracles on the market, each with limitations — and none for free. Espeo Blockchain development team has changed that. We’ve just launched the first open-source Ethereum oracle, Gardener. At Espeo we strongly believe in transparency and would like to share the code with you.
Gardener
Before we get into the Ethereum oracle, and the blockchain oracle problem, let’s start with a metaphor that I think captures what oracles do. Imagine a big, beautiful garden with lots of plants. But they’re not everyday plants. Instead, they can talk to each other and they thrive on information. Unfortunately, the garden is surrounded by a high wall, so no one inside can see over it.
Lucky for the plants, there is a gardener, who comes in to take care of them — and fill them in on what’s happening outside. The plants trust everything that the gardener says, and he also feels the responsibility since the information he passes to the plants is their only version of the truth about the world beyond the walls.
Sometimes the plants get suspicious and want the gardener to prove what he says. Let’s say they want to know if any apples grow outside. They want to see an apple from the other side.
Of course, the gardener has to bring an apple with him in order to convince the plants that he’s telling the truth. The gardener knows he can’t lie. If the plants demand proof and discover he’s lying, they would never trust him again and he would lose all his friends in the garden. Living in a state of symbiosis, the plants need the gardener to get information about the outside world and the gardener needs the plants’ trust to keep his job.
Now switch the walled garden for the blockchain oracle problem, the plants for smart contracts, and the gardener for the Ethereum oracle.
The blockchain oracle problem
Even though it may sound like the plot of a children’s book, our fictional garden demonstrates a few key things about oracles and the problems they address. An oracle in blockchain terminology is an off-chain solution, which acts as a trusted user for a smart contract, which can feed it with data it needs — just like the gardener.
For a deeper dive into the Ethereum oracle topic, you can read my previous article here.
During multiple blockchain development projects at Espeo, we hit the same problem. Smart contracts can cooperate with each other but they have one serious limitation — the blockchain oracle problem. Like the plants in the walled garden, they can’t fetch anything from the world outside of their own blockchain. Do you need to check the current price of bitcoin in an Ethereum smart contract? Sorry, nope. Weather in London? Forget it. In most of our projects, we lacked a good tool to do it. So we built a solution.
Why start a new project?
In the blockchain ecosystem, there are already a few solutions to the blockchain oracle problem. The most popular is OraclizeIT, which our team found really useful. It supports many different data sources (e.g. URL, IPFS, random, computation). It met our expectations in terms of functionality and we used it in our first implementations.
Another very promising solution is Chainlink. It’s flexible and capable of providing almost any input data to the smart contract and generating an output for other blockchains, payments, etc… The biggest problem, however, is that it only lives on a test network and isn’t ready for production use quite yet.
TownCrier is another solution from Cornell University developers. Their strong academic background results in a completely different approach using Trusted Execution Environment — Intel SGX in particular. This approach guarantees that no one can alter data during processing, because the whole process lives in a safe enclave, which isn’t accessible from any other process or area.
A drawback of this solution is that it has very limited functionality and hasn’t been updated for a while. Chainlink recently acquired TownCrier so it seems things may start to move forward but most probably we’ll still need to wait for a fully functional production-ready solution.
Of course, these solutions are only available as SaaS products and the code isn’t open-source or free for the community. Espeo Blockchain places transparency among its core values, which is especially important for blockchain solutions as that’s one of the key blockchain advantages. That’s why we decided to create our own Ethereum oracle product, which would be free and open-source for the community. In parallel to implementing current projects with OraclizeIT (to deliver them quickly), we started working on a replacement. That’s how Gardener was born.
Current State
Today we are happy to say that we have a working version we can share with you. The product is in its early days but we successfully use it internally and can’t wait to challenge it with your use cases.
What we have now:
- Ethereum smart contracts for the oracle
- Ethereum libraries for integrating the oracle into your contracts
- Off-chain server written in Node.js
- Simple monitor web application for watching what happens with the requests
- Documentation hosted at gardener.readthedocs.io
- A GitHub organization with MIT-licensed open source repositories ready to be cloned
Summing up, so far we’ve delivered everything you need in order to fetch any data from any public API into Ethereum smart contracts.
Roadmap
What we have for now is limited but fully functional and ready to use. However, it’s not enough for us. We have big ambitions and a plan on how to improve our solution greatly.
First, we would like to add an ETH and ERC20 based fee model. This would give Gardener instance owners the ability to decide who should pay for the request to the Ethereum oracle — them or the users creating requests. Also, it would allow instance owners to add a profit margin, if necessary.
Next, we will focus on accepting more data source types and formatting options. This step will include parsers for unstructured (binary) data, access to IPFS, random data source and access to closed APIs in a secure and safe way. We will also want to incorporate heavy computing calculation using container-based approach. All of these will give users great flexibility and no constraint in the matter of data type and source.
Later, we will focus on providing proofs to our solution, specifically Intel SGX. It will guarantee data immutability during fetching and parsing processes.
Finally, we want to move on to blockchain integrations other than the Ethereum network. We will support EOS, Hyperledger Fabric, Corda and Hyperledger Sawtooth.
The above goals are something we want to focus on the first place but we don’t exclude other improvements. If you see a particular feature lacking please drop me an email or raise an issue in our Github.
Stay Tuned
Effective blockchain projects need oracles to get data from the outside. We’ve launched the first open-source solution to the blockchain oracle problem.
This is the first article from the series on the Gardener project and we’re looking forward to hearing your feedback. All the code is MIT-licensed and you can find it on GitHub. If you have any questions or would like to get help with incorporating Gardener in your project don’t hesitate to reach me by email: [email protected]. Hope to hear from you soon!
