HIP Identifier

Hyperledger Gardener

Sponsor(s)

Sylwia Rogowicz 

sylwia.rogowicz@espeo.eu

Krzysztof Wedrowicz

krzysztof.wedrowicz@espeo.eu

Krzysztof Spisak-Spisacki 

krzysztof.spisak.spisacki@espeo.eu

Ekin Tuna 

ekin.tuna@espeo.eu

Introduction

Gardener is a modular and secure oracle node implementation for transferring external data into a blockchain. It allows for the integration of multiple data sources and security features from which an oracle node can be containerized. Gardener provides the libraries and integrations for the data sources, security features and integration to Hyperledger Fabric.

Context

The initial contributions to Gardener have been made by Espeo Software (espeo.eu). It is licenced under the open source MIT license and the source code can be found at https://github.com/EspeoBlockchain. 

Motivation

Originally Gardener was realized through practical development challenges. At Espeo we developed multiple blockchain solutions that required data derived from an external source. All the oracles available were closed source at some portion of the software, and none of them were free to use. This is why we decided to offer a free and open oracle for every developer in the blockchain space.

Gardener is a free to use, fully open source oracle node implementation. It is important to have a modular solution that can be deployed easily and integrated to any blockchain. This will ease the development work and allow for a secure way for accessing off chain data. This is why we have developed the tools, modules and documentation for Gardener.

Status

The development work of Gardener is actively ongoing and undertaken by Espeo Software. So far the public API access, IntelSGX based random data (sgx_read_rand function) and oracle monitoring tool are already developed. The ongoing work tasks include:

  • Hyperledger Fabric integration
  • IntelSGX remote attestation 
  • Proven off chain computation

Our code is available at https://github.com/EspeoBlockchain. 

Solution

Oracle architecture diagram:

Gardener project consist of 2 main components and 1 support utility. The first main component is a set of smart contracts (or chaincodes) with the main one called Oracle and others, which act as helpers. All requests go through the Oracle contract, which knows how to handle each of them. The responsibilities of the Oracle contract are request validation. This means checking that the entity performing the request is valid and that the parameters of the request are correct. It also issues events about new requests and proxies the requested data back to the correct address. Contracts using the oracle have to be either extending Gardener using the Oracle contract or at minimum following its interface. 

Gardener offers also wrappers for other oracle solutions like OraclizeIT to allow users to easily migrate from SaaS solutions to Gardener without changing implementation. Wrappers are translators between the backward compatible interface of another oracle into the interface of Gardener oracle  (currently only OraclizeIT is supported, but others can be added easily on demand).

The second main component of Gardener project is the Gardener Server. It is the off chain entity that fetches and passes the information that was requested by the Oracle contract. It was designed using a hexagonal architecture approach. This means that in its core it keeps business logic of its behavior and all the technical implementations are external. Because of this new integrations can be added very easily by just writing the technical integration. This means that integration of, for example, a new blockchain, storage or data source is easy and does not require modifications to the main flow of the application. 

The main flow of the server application looks as follows: the server listens for new blocks in a given blockchain. If new blocks appear they are checked for events related to oracle requests. If there are any, the events are saved into storage (all requests are saved regardless if they are delayed or not). We use the system scheduler Cron for checking the saved events for delayed requests. Cron periodically asks storage for requests, which are ready to execute. The requests which are ready are parsed from the stored string request. After parsing the request the requested data is fetched and the received response is filtered using one of commonly known filtering patterns. Currently we support JSONPath and XPath supported for filtering. Finally, the filtered data is then pushed to the blockchain as a new transaction.

The third component, the helper for the main components, is Gardener Monitor. It helps to look at incoming requests and outgoing responses. It connects directly to Oracle contract and monitors state changes in it. It is designed to help during development as a GUI interface and in the future we plan that it would also allow to check proofs or executed processing.

Currently the only supported blockchain is Ethereum. However, Gardener team is on their way to introduce a Hyperledger Fabric integration. Thanks to the architecture design described above that integration should not be much time-consuming. We are currently working on writing the complementary chain codes which have the same responsibilities as smart contracts written for Ethereum. By doing so we will add a Hyperledger Fabric integration into the Gardener Server. Some Proof of Concept work was already done and now the result of it is waiting to be incorporated into more production-ready software.

Efforts and Resources

Currently there are four core people working on Gardener, outlined at the Sponsor(s) section. All are working part-time. 

Two main backend developers involved are Krzysztof Wedrowicz and Krzysztof Spisak-Spisacki. In addition we have multiple other developers working on various components  We hope to have larger Hyperledger community support in the future as we further our development. 

Road map

October 2019

  • Hyperledger Fabric integration
  • IntelSGX remote attestation
  • Update, refactor and polish the Monitor

After October 2019

  • Off Chain computation with and without proofs
  • Work on other Hyperledger greenhouse projects
  • Decentralized consensus based on ring signatures
  • SWIFT / payment integrations

Reviewed By

  • Arnaud Le Hors
  • Baohua Yang
  • Binh Nguyen
  • Christopher Ferris
  • Dan Middleton
  • Hart Montgomery
  • Kelly Olson
  • Mark Wagner
  • Mic Bowman
  • Nathan George
  • Silas Davis


  • No labels

19 Comments

  1. Vipin Bharathan

    Gardener in the Hyperledger greenhouse! Love it!

    Interesting and timely proposal for off-chain interactions.

    Would be more acceptable if it were to support more than HL Fabric. Since you already have Ethereum Integration, will it not be possible to work on an HL Burrow integration; this would make the project more appealing as a full fledged project.

    Please elaborate on Ring-signature based consensus- is this purely in an off-chain context?


  2. Ekin Tuna

    Yes, what would the Hyperledger greenhouse be without a Gardener (smile)

    We took HL Fabric as the starting point as we have experience in developing on top of it. The idea is to start with Fabric and expand the support to more projects.

    We didn't build anything on top of Burrow yet, but if I understand correctly it would be straightforward as it runs EVM. So that in mind we will definitely develop a Burrow integration. Do you think it would be better to make the Burrow integration before Fabric?

    The ring-signature based consensus is something that would be only off-chain, you're right. The current standard for a decentralized oracle is for the oracle contract to allow multiple nodes to send the requested information to it, after which the contract evaluates if the answers sent by the nodes are in agreement (something like a weighted majority vote for example). So for reducing the traffic on-chain the idea would be to put the data validation in a ring signature that would be signed by the nodes off chain, and only once the signature is complete the value is passed to the contract. This would reduce the on-chain traffic and also allow to have either a dedicated oracle network for a single project, or one that is shared by multiple projects.

  3. Mic Bowman

    what does it take to integrate a new platform? I assume it is just a client interface and that the APIs for Gardener Server and Monitor are ledger/platform independent?

    1. Ekin Tuna

      Not exactly. As of now all the three different components involved need to be integrated with the new platform; the contract, server and the monitor. The thing is that the platforms are not standardized which means that the integrations need to be made individually for each platform. But as Gardener is already structured this in mind, the integrations are simple in relative terms. So in short the monitor and server are platform independent, but they will still need some integration work to be able to integrate to the new platform.

      In case you have any improvement suggestions we are open to discussing them always (smile)

    2. Krzysztof Spisak-Spisacki

      As Ekin said - all it takes to integrate new platform is implementing on-chain bit (which is easy because it's esentailly a proxy) . In off-chain part, there are no oracle-domain changes necessary. Only an adapter need to be implemented, since Gardener leverages a hexagonal architecture.

  4. Dan Middleton

    What makes Gardener unique as an oracle?

    1. Ekin Tuna

      From the end user's point of view our goal is to be fully open source and free to use. We have not seen any of the other Oracle projects do this so far and that is where we want to separate ourselves.

      From the development point of view we have worked on providing an architecture that allows us to support all types of blockchains as the server and smart contract / chaincode are individual components. This will allow us to support all various blockchains. The possibilities with this are quite vast if it is combined with the long term plan of an off-chain oracle network.

  5. Dan Middleton

    How is the TEE/SGX intended to be used? The code at the link generates a random number.

    1. Ekin Tuna

      Yes, currently we only support random number generation. Recently we obtained a commercial license from Intel which allows to use the SGX remote attestation service. This will allow Gardener to, for example, execute code in a trusted environment, and to be sure that the executed code is run correctly.

      This question is, however, best answered by Krzysztof Spisak-Spisacki as he is the one who is implementing the remote attestation service currently. For further discussion I can put you in touch with him, or he can clarify any questions over the next call we have.

    2. Krzysztof Spisak-Spisacki

      Generating number in SGX enclave is the part of SGX implementation that we've already finished. We wrote an article on that that has some more details: https://medium.com/gardeneroracle/random-number-generation-in-gardener-1660e5c25e00 but in short - that way a seed that we provide to Pseudo-RNG function called in SGX cannot be intercepted by a miner or other malicious user.


      SGX features that we look to leverage and are in progress implementing them:

      • Remote Attestation, so a process of attesting an SGX Enclave by Intel to verify it is genuine and has not been tampered with. This protects us against malicious user injecting code into SGX enclave.
      • Using SGX Sealing mechanism to seal users public key in the enclave and use it to send response encrypted with that key. This protects us from man in the middle attack - a malicious user intercepting a response while it's being sent from SGX enclave to blockchain via an offchain server application

      These combined features allow to prove that data provided by Gardener is genuine and not altered. The only Third Trusted Party will be Intel, so users don't have to trust the miner and don't even have to trust an entity that hosts an offchain part of Gardener.

  6. Dan Middleton

    Ekin Tuna et al, thanks for the proposal. I've added it to the TSC agenda for this week (August 15th 1400 UTC). Please indicate if you can make that time. If not we can look at discussing it the following week.

    1. Ekin Tuna

      Dan Middleton Today is a holiday in Poland, and as our team is mainly located there we would need to partake in the call next week. Is the call the same time (14:00 UTC)? And where can we find the link to it?

      1. Dan Middleton

        Yes please enjoy your holiday and we will look forward to discussing your proposal next week. The calendar is here: Calendar of Public Meetings

  7. Dan Middleton

    See also: https://tech.cornell.edu/built/town-crier/

    1. Krzysztof Spisak-Spisacki

      Town Crier is indeed a similar implementation to Gardener. It however seems that its development was dropped and it's not maintained anymore.

      1. Ekin Tuna

        ChainLink acquired Town Crier a while back. I think the contributors continued the work there.

        1. Krzysztof Spisak-Spisacki

          I am basing my opinion on TC GitHub: https://github.com/bl4ck5un/Town-Crier . Doesn't seem to have any significant activity for a year now.


          Currently they implemented just a couple of exemplary URL sources as described here: https://www.town-crier.org/dev.html#h4 . They do not have other data sources or an option to call any URL source - they just support few selected URL sources. It's a shame since they have very advanced SGX implementation, for example with SGX Remote Attestation finished.

  8. Dan Middleton

    Following discussions in the TSC meeting, please feel free to create a lab following the directions here: https://hyperledger-labs.github.io/

    and/or continue to work with the to-be-named TCF project.

    I will resolve this project proposal per that discussion from 2019 08 29 TSC minutes

    1. Ekin Tuna

      Sounds great! We'll make the lab environment according to the instructions.