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.
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.
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?
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…
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
Can share my issues with oracles, they are basing “rates” on oracles to address instabilities when they are unable to simultaneously process bidirectional conversions. Many of the cases where people drain those systems, for example the recent Harvest Finance hack that took $24 million and caused 500 million to immediately drain from the contract by spooking everyone, are due to the fact that external oracles are literally impossible to keep in sync and can be gamed if used for the internal system truth. I think this is a fundamental misunderstanding of people who are stuck on the model of old, time-based, serialized markets. I would suggest a different approach, unless some form of it in the future actually proves to not have these weaknesses. At present, I haven’t seen any.
Conversion prices should be set by the market with zero spread between conversion in one direction or the other. That means that in any currency at all, you will either get a better than Forex rate in one direction or the other, or for most people without high volume institutional access, it could be better in both. When the prices on any currency relationship get out of sync with larger markets or perceived value if there is no larger market, people can arbitrage to make money as they bring the prices in sync. This is the model for algorithmic conversions that in the long run will provide the most efficient conversions. imho. i.e. simutanous conversions instead of sequential…
.