It's been ten days since the Hyper Oracle whitepaper was released, and this article will explain and add to some of the content of the Hyper Oracle whitepaper. The original content was taken from my twitter.
The I/O Oracle data flow is actually Output Oracle, then Input Oracle. It is not called O/I, because O/I is less common than I/O. Also, there is no real combination of Input Oracle and then Output Oracle. It's more like two separate Oracles.
ZK just proves the validity of the computation, so the "price of the item purchased" is secured by the data source, not directly by zk. In Hyper Oracle, the security and validity of the data source is guaranteed by the on-chain data (the actual source) and zkPoS (the source fetching).
On The Graph's Indexer Explorer, indexers earn less than $1 per day in indexing rewards...... So, due to the lack of incentive, it is still essentially forcing developers to "run their own nodes". zkIndexing provides a solution with a trustless and decentralized hosted service.
All Subgraph tools can be used seamlessly with zkGraph. So everything from The Graph (such as their grant project) can be powering zkGraph.
The network itself is decomposed into separate jobs (zkPoS, zkGraph_N...) . If a node generates proofs for a job and collects rewards. Others will spontaneously make other proofs to get incentives. This allows >= 1 node to claim all proofs and execute them. Magic tricks like recursion, aggregation and parallelization are not considered here.
We have 14 ways to transfer, but the essence is that someone (human or robot or whatever) must trigger the on-chain signature. To keep the protocol running, developers need to automate the process of triggering some smart contract calls.
Even if the data source is about the assets on the chain, the price still comes from something like CEX. It still meets the definition of Input Oracle, having data feeds from off-chain (even if they are about on-chain data).