Secret Oracles – connecting web2 to web3 with privacy

One of the things we’ve been discussing that would likely have a lot of impact, is re-using the Secret Network infrastructure to provide secure, secret oracle functionality – to both Secret Network and potentially other networks as well through future bridges (e.g., IBC).

The general method of enabling oracle functionality, and also to make them secret - i.e., allowing you to stream confidential data from web2 endpoints, such as databases, and feed them into secret contracts, is by leveraging TEEs in much the same way as they are leveraged in secret contracts. Specifically, we would use an idea similar to the one presented in the original Town Crier paper, where the TEE acts as a trusted bridge, which opens up a TLS connection with some web2 service, pulls data from it, and then creates and signs a transaction directly from the TEE that includes that data as an input to some secret contract (or a smart contract if this is bridged to another chain). Given the confidentiality and correctness properties of TEEs (and assuming a proper attestation is attached), one can be sure that data hasn’t been tampered with en-route.

The one (not so small) issue with this approach as it applies to Secret Network directly is that Secret Network is a replicated state machine (all blockchains are), which means, all nodes replicate computations and reach consensus on them, which implies these computations need to be deterministic. Reaching an external source of data from many different nodes at approximately the same time could lead to non-deterministic results and impair consensus. It’s also not very efficient (to say the least).

How do we solve this? There are two ways basically:

  1. On-chain: There needs to be some deterministic process in which validators choose a single validator that would serve as the Oracle for a given block, or a given transaction. Ideally, Oracle calls would be called in the beginning of the block (and therefore need to be known a-priori). The most natural choice would be to have the current leader/block proposer do this part. Then, oracle results could be sent as inputs to the contracts that need them.

This approach is the cleanest, but is also quite complicated and we haven’t considered all factors here.

  1. Off-chain - basically, take Secret Network and run it on a single node – this would constitute a single oracle. This oracle can directly interact with web2 services, but because it’s really running on a single node, there are no issues of non-determinism. From a single oracle, we can expand to a marketplace of incentivized oracles. We need to have a secret contract that manages oracle registration and other details. Users or other contracts can use these oracles directly off-chain, while paying them in SCRT for their work. There are more details to consider here as well, but this general approach does seem more attainable.

If you have further ideas on how to improve this, please let us know. Ideally, we’d like to see someone else build this – it could be a great idea for a community pool spend.

9 Likes

Thanks for this write-up @guy!

Which approach do you prefer, I’m curious :smiley: .

I like Option 1 (On-chain) because the Oracle is part of the Secret Network (like privacy the oracle functionality is built-in to the network). Also, how can the selected validator trust the Oracle data?

I kind of love Option 2 (Off-chain), especially the idea of a “marketplace of incentivized oracles”. I have the same question on verifying the results from the single Oracle too.

I would love to see more details on the two approaches such as a diagram illustrating the flow, how each option could work. Just trying to wrap my head around this very interesting and complex topic.

Could computational privacy be used to increase the security of secret oracles? For example:

  • It is unknown which contract the data is intended for
  • A contract may request data at a random point in time
  • A contract developer may hide what kind of data a contract requests
  • An input value only affects a random subset of contracts
  • A few data sources are selected to report an event, and they are unknown to each other

Hmmm, not sure how that’s useful for most cases?

I think it’s a great idea and is absolutely necessary for the project to succeed. @guy I know that a partnership with chainlink was announced back in the Enigma days… is there a possibility of combining the great minds of both projects (chainlink and secret network)? From my understanding chainlink is working on encrypting data for PII (through DECO). Also from my understanding DECO can not perform computations but rather encrypted confirmations of a set parameter. A combination of the two would be an absolute powerhouse in the space for many years to come, in my belief.

The intention is to make it harder for malicious actors to profit from exploiting specific contracts or to make it harder for them to find others to collude with.

Using web2 data to create reputation / identities is key for blockchain applications. This can help with sybil resistance (explored with DataWallet back in 2018, though they have not been able to complete their part) and identities for credit ratings.

On-chain credit is going to be a huge innovation in DeFi that allows for under-collateralized loans. This is a potential area of collaboration with Bloom.

@guy this is a great idea. One question that comes to mind first, is who would run this node (who would be the oracle that is) had the off-chain model been implemented? An existing node operator for example? Also what use cases could you foresee being implemented other than e.g. medical?

@johnredie,

There could be a bidding process to access the right to be an Oracle. I’m guessing Oracle calls will require users to pay fees. There can be NFTs for different data sources (i.e. plaid banking information or google location import), these data sources can be voted on by the network and auctioned to whoever wants to provide oracle service.

This is similar to how decentraland sold virtual land on their platform - a scarce resource…

1 Like

Thank you for the input @can! Very interesting.

A nice article on defi attacks caused by price oracles

It’s pretty simple to prove that it’s impossible to prevent people from finding actors to collude with if you can tell when your system is being used, but the exploitation difficulty is maybe something