eamesyi
commented
5 years ago There are three types of Oracles that we are planning for at this point:
- Identity Oracle
- Authority Oracle
- Event Oracle
Both the Identity Oracle and the Event Oracle would benefit from a pool arrangement (operational/organizational redundancy) for reliability and integrity using voting logic. Basically just compare the outputs and go with the greatest qty of. More complex voting logic can follow. On first blush, I don't believe anyone would benefit from an Authority Oracle operating in a pool fashion, nor do I think it would be practical.
We haven't properly integrated the Event Oracle system into the protocol yet, but I have it mostly worked out and it is on the road map. The pool feature for Event Oracles is trivial to implement and I already know how to approach it.
The system we have now works for the Identity Oracles to be used in a pool fashion to assist users to increase reliability and integrity. The incentives are such that this will be a wallet led activity. At present, the smart contract only requires one valid signature from one approved oracle. We could easily add a requirement for more signatures from different oracles to meet a certain threshold, but at present, I don't think we should make the system any more complicated. Long term we can definitely explore this line of thinking.
akb-tokenized
Can there be a pool or oracles with corresponding voting / majority rules for dealing with discrepancies / outliers. I can envisage the case where the oracle is a calculation agent effecting the value of a contract and the parties will want to ensure that the oracles are not subject to manipulation bu having a pool or trusted parties. This is especially the case when the oracle may only be used may years in the future so that those oracles which are trusted today may be trusted less so in the future - this risk can be reduced using a pool.
Also, consider how the oracle or pool of oracles will be maintained - members removed or added over time.