Chainlink Oracles Bridge to Secret Network

Inspiration

The basic need addressed is having trusted off-chain data available for the Secret Network dApps. The first straight-forward solution considered was to port the Chainlink solution onto the Secret Network, have them made compatible.

Then the considered options and thoughts have been the following:

Re-implement the CL oracle contracts (Solidity, EVM) in Secret contracts (Rust, CosmWasm) a. protocols: Chainlink node jobs' talking to SN instead of Ethereum b. contracts: 1. iterative migration from Solidity to Rust programming languages 2. different libs and APIs between ETH and CosmWasm 3. many different contracts, patterns & techniques c. complete fork shall be opted since keeping the 2 implementations in synch would be costly / isn't realistic d. would be like rebasing Chainlink on top of Cosmos (/SecretNetwork)
Import CL oracle contracts' data into Secret relaying contracts a. Ethereum Chainlink Oracle data contracts, e.g. asset pricing quotes, are extracted by a trustless off-chain service using on-chain queries and update triggers b. report that result in dedicated Secret Oracle data contracts c. DApp contracts can query the updated Oracle data provider d.
Implement another Oracle solution based on Cosmos/Secret Network, different than the Chainlink solution a. An occasion for an Oracle solution to benefit from the SN contracts' data privacy to protect & monetize them using a different model than current CL one b. huge work/challenge. would be like reinventing the wheel, for geniuses with time ahead c. The Band Chain is on Cosmos, else IBC starting up and EVM-chain bridges underway

--> Option #2 has then been taken in the context of this Chainlink Spring 2021 hackathon.

What it does

Having Chainlink oracles data available in Secret Network. Providing Secret Network contracts access to Chainlink Oracle data, without reimplementing the Chainlink solution on top of the Secret Network.

Why Secret Network?

Secret is the network of choice because of its users & apps' privacy-preserving solution and its huge potentials in terms of businesses with smart apps having actual added-value.

Such a community-supported solution can be made sustainable because service fees can be collected and be fair with the Chainlink tokenonomics: access to oracle privatized data can be paid using secretLINK tokens, a supported SNIP-20 wrap and peg-in of LINK tokens, and access to Chainlink oracles on chain can be paid using LINK tokens.

Secret is a Level1 Proof-of-Stake network backed by the Tendermint BFT consensus engine and the Cosmos SDK, where contracts are executed in a Trusted Execution Environment. It is fast, cheap and reliable.

What problem does it solve?

Having existing or new Chainlink trusted oracle data feeds accessible by Secret Network dApps.

Easily benefit from the already existing and trusted data feeds, their reliablity & safety * without requiring building new complex Chainlink Node jobs, adapted to CosmWasm contracts * without having to port ETH Solidity contracts to CosmWasm Rust contracts, and maintain them to catch up with evolutions made on ETH side. I consider that dev power far beyond the reach of an isolated dev team Complex jobs and contracts mean actual advanced Chainlink solutions like flux and off-chain aggregator against proxy contracts, not the simple 1 Node Job for 1 External Adapter towards 1 oracle and 1 data contract. Considering that the latter option doesn't offer much reliability. Meaning the Chainlink model might look simple to implement or port at first glance, then you realize that it deals with a huge technical and social ecosystem, with its inherent complexity, to make the solution worth integrating with, aka sleeping tight on data continuously consumed by dApps. If new and serious data feeds are required, then have them supported by the proven Chainlink solution, on other well-integrated chains, and relay them in Secret Network.

The aim of this Chainlink bridge solution is actually not about addressing the need for data changing on high frequencies, as many DEX apps would require. However being aligned with actual Chainlink price feeds' heart beat is easily supported.

Another consideration: Other Cosmos dev teams, like Binance DEX or Kava on Binance Smart Chain, are implementing a porting of Chainlink Node jobs & contracts on Cosmos. Once the Inter-BlockChains (IBC) protocol will be effectively in production and adopted, their Chainlink-based oracle data can spread across Cosmos-based networks such as Secret Network. This Chainlink bridge could then be deprecated by these competing solutions' cost and sustainability.

How does it make life better for others?

The solution enables to create new off-chain fueled oracle contracts on Secret, from existing Chainlink data feeds: spotted on the Ethereum network, L1 or L2 EVM chains, and potentially Binance Smart Chain or others later on. There are many tools, e.g. Chainlink Data, Market, enabling to discover the existing oracle feeds and get their access info, i.e. the deployed contract address to be queried. Community users, network apps developers and admin can then request for adding new oracle data feed to be imported and reported to dedicated Secret data oracle contracts.

Using a web interface the service providers can define 3 main info types for having a new oracle contract deployed in Secret Network (and watcher services integrating feed updates):

the Secret oracle contract info, e.g. name, type, description, associated token pairs for a price feed, possible service fee, etc. Mostly consisting in public info so that the service can be discovered by any data consumer.
the external data source: the target network and corresponding Chainlink contract address. OffChainAggregator contracts are the first target and will be supported out of the box. Custom target contract fields can eventually be set in an advanced mode.
the expected update frequency, i.e. corresponding service's watch mode. Either by continuously listening to the target contract events (if emitting events, e.g. AnswerUpdated) or via scheduled pull requests, a cron-based approach to query the contract data. Then contract value changes are reported to the corresponding Secret contract

Solution

Overview

There are 4 main components addressed in this project:

an Ethereum Network client: to pull Chainlink contracts data, or listen to their emitted events
a Secret Network client that reports the Eth contract data updates to its counterpart Secret oracle contract
the bridging of Ethereum contract changes towards Secret contracts, events based for triggering on demand only
the dedicated Secret contracts that gets updated by the offchain service and their data consumed by other contracts

How we built it

The off-chain web services have been implemented using the NestJS app server dev framework, using the TypeScript programming language. The micro services will be deployed as serverless services, to be triggered on demand only, i.e. avoiding to be full time on. The AWS Lambda & GCP platforms are considered, to have redundant services hosted on different platforms and locations. These off-chain services are thought to be resilient and in no way a bottleneck or weak point. Chainlink off-chain solution has interesting responses for these matters.

The Ethereum client SDK Ethers is used, and is great when you have some practice of its API. TypeScript The Secret Network client SDK SecretJS is used, and is also great, very different than the EthersJS logic and terminology, but aligned with the Cosmos SDK. JavaScript The CosmWasm library is used to build Oracle contracts on Secret. Rust

Challenges we ran into

First a lot of time was spent on running a full Chainlink node locally, with a local Ethereum Web3 provider, DB, etc. Defining Jobs and deploying their oracle and data contracts on Ethereum. It was interesting to have a real grasp and better understanding of Chainlink's underlying tech and logic. Before admitting that this simple oracle config was not serious enough and provided no real trust & value. The real solution to be deployed via Chainlink was far more complex to undertake.

New to blockchain actual implementation, time was spent on integrating the Chainlink Ethereum contracts from the off-chain service. The 2 techniques have been implemented to extract contract data, on time: either by using a cron-based scheduling to pull the data, or by listening to emitted change events. The toughest has been on developing the new oracle contracts for Secret: that's something for a very first time implementing in Rust, the tough learning curve is confirmed, even if experienced with other programming languages. Happy to see the light now and benefit from that ramp up. So hang on and refer to apps' implemented codes as reference for patterns, techniques, etc to make it your own. Strong typing and mindful memory management are good. The Rust out-of-the-box tools and compiler guidance are great, very pro, hopefully. The Secret Network also has good toolkits, instruction docs, ref implementations and an open community spirit.

The end-to-end full stack solution was too ambitious for a sole developer willing to catch up in that blockchain & smart apps domain. The final lap is actually missing: there is some missing glue among the services & their expected serverless deployment, as well as a web UI demonstrating the operations, or a Secret app consuming the provided oracle data. These dev activities will be achieved in the coming weeks in the hope to be put in production.

Accomplishments that we're proud of

Main benefits in the short have been the huge learning session, very beneficial and that will be further invested. Many design and implementations ideas came out of this hackathon session, now leveraged with a real grasp on the implied know-how.

Enabling Secret dApps to benefit from reliable off-chain data, so that many use cases addressing social and economic issues can be addressed, based on these contracts' configurable privacy model.

Fairness:

the fact of enabling to avoid actual Ethereum network fees by running on alternative by still benefiting from the Chainlink solution
the fact of being fair with Chainlink by participating to their tokenonomics
the fact of addressing a low-consumption solution, via serverless-based deployment and moderated/aggregated continuous watch to limit data centers usage to their minimum

Efficiency: on edge technological (PoS, serverless) and design (modularity, tasks and workload dispatching) choices have been made to lower down the service consumption as much as possible.

What's next for the Chainlink Oracles Bridge to Secret Network

Finalizing a v1 of the solution is the priority: clean deployment, fault-tolerant integration among the many different services, review with peers and promotion of the service put on the table for the Secret community. Admin UI is also a must-have, should pertain the ease of using and extending that solution. Then adaptation of the v1 depending on the demand and usage. It is expected to adopt a DAO approach to manage this service and share its benefits, if any. Another very interesting chapter.