Home

Hackathon project: Chainlink Oracles Bridge to Secret Network

What’s the point of this project submission?

Having Chainlink oracles data available in Secret Network.

Providing Secret Network contracts access to Chainlink Oracle data, without re-implementing the Chainlink off-&on-chain integrations on top of the Secret Network.

Why Secret Network?

Secret is the network of choice because of its configurable privacy-preserving contract models and huge potentials in terms of smart apps with real added-values. Native privacy protection is a major key differentiating feature, and is unique, compared to actual inherent all-data-is-publicly-exposed for other blockchains supporting smart contracts.

Such a community-supported solution can be made sustainable because service fees can be collected and be fair with the Chainlink tokenomics: 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 (PoS) backed by the Tendermint BFT consensus engine and the Cosmos network, where privacy-preserving contracts are executed in Trusted Execution Environments (TEE). It is fast, has low costs and is reliable.

What problem does it solve?

Having existing or new Chainlink trusted oracle data feeds made accessible to 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. We consider that dev power far beyond the reach of a small dev team

Complex jobs and contracts mean actual advanced Chainlink solutions like off-chain flux 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 socio-economic ecosystem, with its inherent complexity, to make the solution worth integrating with, aka sleeping tight on the data feeds 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 to 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' update frequency can be easily supported.

Another consideration: Other Cosmos dev teams, like Binance DEX or Kava on Binance Smart Chain, are porting 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 be spread across Cosmos-based networks such as Secret Network. This Chainlink bridge could then be deprecated by these competing solutions, depending on their cost / Secret apps sustainability.

How does it make life better for others?

The solution enables to create new off-chain oracle contracts from existing Chainlink data feed: spotted on the Ethereum network, and BSC later on.

There are many discovery tools, e.g. Chainlink Data, Market, enabling to review existing & available oracle data feeds and get their necessary access info, i.e. the deployed contracts' address to be queried. Community users, network apps developers and admin can then request for their support/integration in Secret Network.

Using a simple 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):

1. 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.
2. 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.
3. 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 like approach to regularly query contracts data. Then data feed value changes are reported to the corresponding Secret contract.

Does it address any current social or economic issues?

Unfortunately not. Except benefiting from reliable off-chain data for the Secret dApps, that can support many use cases addressing social and economic issues, primarily based on their contracts' configurable privacy model.

Does it promote economic fairness, transparency, and efficiency?

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 tokenomics
• the fact of addressing a low-consumption solution, via serverless-based deployment + event-based triggering architecture, and moderated continuous watch

Transparency:

• open source code of all the modules part of the data provisioning chain: web services & contracts
• usage statistics are expected to be exposed as well

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

How useful would the project be in the real world?

Accessing trusted off-chain data on chains: Chainlink core business. Plus benefiting from a privacy-preserving smart contract model.

Solution

Overview

Overview of actual solution implementation:

Modules

There are 4 main tech components composing this solution:

1. Ethereum network clients: to pull Chainlink contracts data, or listen to their emitted events
2. the main bridging service of Ethereum contract changes towards Secret contracts' update: with an event-driven architecture, minimum consensus support for validating any updates, highly available MS & cloud functions deployment
3. Secret Network clients that report data feed updates to Secret oracle data contract
4. Dedicated Secret contracts that get updated by the offchain service, and have their data consumed/queried by other SNIP contracts

Adding other client SDKs will be addressed, e.g. BSC for their Chainlink-based oracle data feeds, to augment the data feeds offering.

Considered alternative options

What other solutions were considered, and why option 2 was taken for the hackathon:

1. re-implement the CL ERC contracts into SN SNIP contracts

   • protocols: Chainlink node jobs' talking to SN instead of Ethereum
   • contracts:
     • iterative migration from Solidity to Rust programming languages
     • different libs and APIs between ETH and CosmWasm
   • many different contracts, patterns & techniques
   • complete fork shall be opted since keeping the 2 implementations in synch would be costly / isnt realistic
   • consists in re-basing the Chainlink on-chain integration, on top of Cosmos (/SecretNetwork)

2. Import ERC oracle contracts' data into SNIP oracle contracts

   • act as an ETH ERC contract querying an oracle contract's data
   • report that result in a dedicated SN SNIP Oracle data contract
   • DApp SNIP contracts can query the updated SNIP Oracle data provider

3. Implement another Oracle solution based on Cosmos/Secret Network, different than the Chainlink solution

   • 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
   • huge work/challenge. sounds like reinventing the wheel, for geniuses having time ahead.
   • BandChain is on Cosmos, and Cosmos IBC is taking off

What's next

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.

A Web Admin interface is also a must-have. It should pertain the ease of using that solution to integrate new data feeds, consisting in price or other types of assets/info feeds.

Interfacing with alternative networks than Ethereum, hosting Chainlink oracle contracts, will be addressed. This will assess the solution extensibility and its security by relying on different data services / sources.

Then adaptation of the v1 depending on the demand, usage and sustainability.

It is also considered to adopt a DAO approach to manage this service and share its benefits, if any. Another interesting chapter.