Author: Krzysztof Wędrowicz

Categories
Blockchain Financial Services

Introducing Gardener, our homegrown Ethereum oracle

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: krzysztof.wedrowicz@espeo.eu. Hope to hear from you soon!

Categories
Blockchain Software

Blockchain oracles: Can blockchain talk to the world?

In this article, I’ll take you on a journey to find out what blockchain oracles are, what they’re for, and see the technical aspects behind them. We’ll go through base oracle flow, external data sources, authenticity proof (proof that a party doesn’t tamper with data), as well as oracle verification. Fasten your seatbelts and let’s begin!

Update 23/1/2019: While we in the Espeo Blockchain development team use some of the blockchain oracles already available on the market, we weren’t completely satisfied. So we decided to build a solution for ourselves and to share it with you. We’ve just launched a free, open-source oracle called Gardener. Read more about the project here, or find it on GitHub. Enjoy!

What’s the issue with blockchain oracles?

Blockchains function in a closed, trustless environment and can’t get any information from outside the blockchain due to security reasons or so-called sandboxing. You can treat everything within the node network as a single source of truth, secured by the consensus protocol. Following the consensus, all nodes in the network agree to accept only one version of their managed state of the world. Think of it like blinders on a horse — useful, but not much perspective.

However, sometimes the information available in the network isn’t enough. Let’s say I need to know what the price of gold is on a blockchain-based derivatives trading app. Using only data from inside the blockchain we have no way of knowing that. Because the smart contract lives in the sandboxed environment it has no option to retrieve that data by itself, the only viable alternative is to request that data and wait for some external party we trust to send it back. That’s where the utility of blockchain oracles come in.

Two components

There are two components that any sensibly working oracle in the blockchain has to incorporate. One is a data source handling component that retrieves requested data from the reliable data feed sources. These data sources can be data stores or databases, APIs of various types, even internal data stored in some ERP or CRM enterprise systems. The second component is the off-chain monitoring mechanism. It looks for the requests from smart contract and retrieves the required data from the data source handling component. Then, it feeds it back to the smart contract using some unique identification data to communicate which request the submitted data is related to.

When do we need oracles?

I’ve already discussed how the data can be provided back to the requesting smart contract. We also need to consider the timing of when the data should be acquired from its source and at what moment it should be sent back to the smart contract. Let’s first consider in what situations a smart contract may need access to the blockchain oracles. There are endless cases and even more solutions to them, so let’s explore a handful of them:

  • Derivative platforms that need to know the pricing feeds for the underlying assets, such as one we worked on called CloseCross
  • Prediction markets, when the ultimate result of the event has to be established reliably,
  • Solutions which need provable randomness (Ethereum is a deterministic platform),
  • Information from other blockchains,
  • Heavy computations, which don’t fit within block gas limits (or even if they fit they’re extremely expensive)
  • Complex mathematical equations (using f.ex. WolframAlpha)
  • Retrieval of some data from IPFS or other data storage

Implementing the concept

I already wrote what sort of data you can retrieve, and how and for what reasons. Now, let’s dive into more details on how you can implement the whole oracle concept in more practical terms. Because part of the blockchain oracles is an off-chain mechanism, it could be developed using any modern programming language.

Of course, any language which has frameworks that allow it to communicate with the blockchain. It constantly searches (listens) for events emitted by a relevant smart contract and checks if they’re requests for external data. If so, it accesses that data from some data source and processes it according to the specified rules. One option is to use an external data provider we trust. Due to some external factors (agreements), we know it would never cheat.

On the other hand, if we use the data provider that we can’t trust or even force the smart contract clients to use our internal data, we can cause a lot of disruption in the client’s operation. For example, if the data finally provided cannot be trusted or isn’t reliable – as we can put literally any data we want there. We can try and cheat to force our contract to behave according to our expectations even though the truth about the external world’s conditions is different. To sum up, choosing the right data provider is half the battle.

An improvement to that could be to choose a few separate sources of the data, but then a problem related to data accuracy would become apparent. For example, when we want to get exchange rates for EUR/USD from a few different exchange rates agencies or exchanges, it’s almost guaranteed that the values would be slightly different for each of them. On the surface, the simple task of providing the data back to the smart contract appears to be, in general, quite a hard problem to solve correctly and reliably.

Proofs

Once we have our data inside the oracle software, it would be good to prove that we didn’t manipulate it. The most basic uses don’t include any proof. Our users have to believe that we just pass on what we get. But there are stronger proofs. Oraclize.it, the leader in Ethereum blockchain oracles at the moment, uses the TLSNotary proof, Android proof and Ledger proof. Let’s briefly check how they differ.

TLSNotary proof

The first one – the TLSNotary proof – leverages features of the TLS protocol to split the TLS master key between three parties: the server, an auditee and an auditor. Oraclize is the auditee, while a special locked-down AWS instance acts as the auditor. The TLSNotary protocol is open sourced and you can read more about it on the project site: https://tlsnotary.org/.

The black boxes are steps from the standard TLS protocol. The green ones are added in TLSNotary. Basically, what we achieved is that the auditor can get the original data and check if it’s not been tampered with. However, he doesn’t know the auditee’s credentials so he can’t perform the action on his behalf.

Android proof

The next one is the Android proof. It uses two technologies developed by Google: SafetyNet and Android Hardware Attestation. SafetyNet validates if the Android application is running on a safe and not rooted physical device. It also checks if the application code hash isn’t tampered with. Because the application is open source, it can be easily audited and any changes to it would change the code hash.

On the other hand, Android Hardware Attestation checks if the device is running on the latest OS version to prevent any potential exploits. Both technologies together ensure that the device is a provably secure environment where we can make untampered HTTPS connections with a remote data source.

Ledger proof

The last one from Oraclize is the Ledger proof. It uses hardware wallets from the French company Ledger (mainly known for Ledger Nano S or Ledger Blue). These devices encompass the STMicroelectronics secure element, a controller and an operating system called BOLOS. Via BOLOS SDK developers can write their own applications which they can install on the hardware just like cryptocurrency wallets. BOLOS exposes kernel-level API and some operations from that are about cryptography and attestation.

The last one is especially useful here. Via the API, we can ask the kernel to produce a signed hash from the binary. It is signed by a special attestation key, which is controlled by the kernel and out of reach of the application developers. Thanks to this, we can make code attestation as well as device attestation. Currently the Ledger Proof is used for providing untampered entropy to smart-contracts.

TownCrier

Another solution – TownCrier – offers Intel SGX, which is a new capability of some new Intel CPUs. SGX is an acronym for Software Guard Extensions and its architecture extensions. It was designed to increase the security of application codes and data. It is achieved by the introduction of enclaves – protected areas of execution in the memory. There, the code is executed by special instructions and other processes or areas don’t have access to them.

Source: http://www.town-crier.org/get-started.html

The image above shows how it works. The contract User calls the TC contract, which emits an event cought by the TC server. Then the TC server, via the TLS connection, connects to the data store and feeds the data back to contract. Because all of this happens in the TC server enclave, even the operator of the server can’t peek into the enclave or modify its behaviour, while the TLS prevents tampering or eavesdropping on the communication.

A word of caution

Keep in mind, however, that even though each of these solutions provides a way to prove data integrity, no one offers a verifiable on-chain method. You can either trust a big company (like Intel) or make a separate verification off-chain, but even then we notice tampering only after the first successful occurrence.

The last thing I haven’t mentioned yet is how the oracle contract verifies who to accept responses from. This solution is rather simple (at least in most cases). Every account in Ethereum, and the off-chain servers has private and public keys pairs, which identify each of them uniquely (as long as nobody steals it from the server).

Conclusion

To sum up, here’s how the business and technical aspects of oracle constructions work. I started with business needs and use cases, next switched to an oracle description and then started examining exactly how it works. I talked about data sources, authenticity proofs, and server identifications. All this knowledge should give you a general overview of blockchain oracles.

If you’d like to use one of the current solutions or feel that none of them meet your expectations for blockchain oracles, you can ask us for help 🙂 And by the way, here’s my previous article on Ethereum-related issues (gas costs).

Links:

http://docs.oraclize.it/#security-deep-dive
https://ethereum.stackexchange.com/questions/201/how-does-oraclize-handle-the-tlsnotary-secret
https://tlsnotary.org/
http://www.town-crier.org/

Categories
Blockchain Finance Financial Services Software

Ethereum gas: how to pay it on behalf of your users

On Ethereum, every transaction that changes the state of a smart contract costs a small fee: this is called gas. Most commonly, end users pay gas while interacting with a smart contract. However, when you’re making a profit on your product by charging some transaction fee or just want to gain many users quickly, you may think about covering the Ethereum gas costs yourself. Well, good news — it’s achievable! In this article, I’ll describe how to do this from both the business side and technical side.

To calculate the precice amount of gas you need to know two factors: Ethereum gas price and the complexity of the operation you want to execute. The current average gas price of Ethereum depends on the current demand on the Ethereum network. Now, let’s see how you can offload the gas costs from the transaction creator to the platform itself.

Blockchain use case: P2P options exchange

The need for offloading the transaction fee in order to achieve cheaper prices is real! We’ve recently faced the problem of moving as much Ethereum gas cost as we can from the end user to the contract creator. The project in question was a blockchain peer-to-peer options exchange, which got a percentage of profit from every successful option settlement. The goal was to encourage people to use the product by waiving any additional cost, just like in non-blockchain solutions.

One of the functions that needed to be free for the users was a standard ERC20 functionality – approve(). User A can allow user B to transfer a certain amount of tokens from user A’s wallet. This method, like any other, normally costs Ethereum gas to execute, but we want to achieve this with no cost to the user. Let’s call the target solution zero-fee allowance. The following requirements must be met for a trusted and secure solution:

  1. The transaction has to be executed by the contract owner, not the end user.
  2. It has to be clear which action is performed by the contract owner on behalf of which end user.
  3. The transaction can be invoked only once.
  4. Two transactions containing two intents by the same end user have to be executed in the order of creation.

Dealing with the Ethereum gas cost challenge

We began by searching through Ethereum Improvement Proposals for problems similar to ours and maybe some solutions. Jackpot! Issue 662 addressed our problem.
After a detailed analysis we were ready to develop our own solution based on what we learned.
We divided the process into 3 parts:

  1. Arbitrary data (the intent) is signed offline using the end user’s private key. The data contains the approve method signature, all parameters and contract address on which the request should be executed. The resulting data signature is sent along with rest of data to the server. Within this step, the user doesn’t make any state changing transactions, so there’s no transaction fee.
  2. The server gets the data from the end user and pushes it to the network using the smart contract owner’s key. The smart contract owner pays the transaction fee.
  3. The contract verifies if the sent data is really the end user’s intent by validating the signature. Then it checks for replay attacks and user intent’s execution order. Lastly, it executes the actual approve function.

Implementation

This part describes the technical solution. So, if you’re not interested in the guts of implementation details, then just skip to the next section, where I’ll discuss the financial aspect of the zero-fee allowance approach.

We based our solution on StandardToken from OpenZeppelin framework. It gave us base methods like the aforementioned approve(). Next, we moved to validating the end user’s intent in the getSigner() function. Firstly, the end user address is recovered from the data signature. Then, the signature is checked against the signature calculated for the arbitrary data passed by the end user. In this step, the intents order is checked by incrementing the nonce value. Lastly, the intent is checked for any previous executions.
After all these checks pass, the flow continues like the standard approve method with the spender address being replaced with the one belonging to the user who signed the message. For readability, the code is split into three methods – checkProvableApprove and provable_approve. The first one is constant and can be used for checking intent correctness, while the second changes the state.

Business calculation of the Ethereum ETH price

Let’s take a look on price per unit that user has to spend per transaction with zero-fee allowance in comparison with the traditional approach.

The gas price and ETH/USD ratio given at the time of writing:

Gas price (Gwei) ETH/USD
49 995.5
Method Gas used Wei cost Ether cost USD cost
Zero-fee allowance 98213 4.81244E+15 0.004812437 $4.79
Traditional allowance 45324 2.22088E+15 0.002220876 $2.21

The conclusion is quite clear. The zero-fee allowance approach costs over 2 times more than when the approve() function is executed directly by the user. In our use-case, that move was worth it, but it should be an individual decision. After all, as the popular song goes, “it’s all about the money”.

If you liked this article, then give it a share. We’ve got more great stuff on our blog (e.g. a guide on how to start an ICO), so make sure you subscribe to our newsletter to be up to date!