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:
- 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.
- 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.