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).
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).
@HyperOracle, Prev @ForesightVen, @Google, @UnionPay Recent research is at HyperOracleBlog.eth's Mirror
@HyperOracle, Prev @ForesightVen, @Google, @UnionPay Recent research is at HyperOracleBlog.eth's Mirror
Subscribe to msfew
Subscribe to msfew
msfewzk, zkVM, zkEVM and their Future
TL; DRZero-knowledge proof, which can guarantee computational integrity, correctness and privacy, has a lot of use cases in blockchain scaling and privacy.zk-SNARK and zk-STARK have their own advantages, and the combination of these two has more potential.zkVM empowers applications with zero-knowledge proofs, and zkVM can be categorized by instruction sets in mainstream, EVM, or newly-built ones.EVM compatibility includes EVM compatibility, equivalence, and specification-level compatibility.z...
msfew(Almost) Everything about Rollup
This post focuses on the Layer2 Rollup universe of Ethereum (only including Secured Rollup), and will explore the good and bad of the current Rollups from the core concepts and mechanism design in an easy-to-understand way, and think about the potential routes and advantages and disadvantages of each of their future solutions in terms of decentralization, further scaling, composability, and additional features such as privacy. A Secured Rollup is a Rollup model like Arbitrum or Optimism, wher...
msfew「Unified to Divided」Modular Blockchain and Data Availability Layer
0. Rollup’s BottleneckIf you read the previous post on Rollup I wrote, then you probably noticed that there was an intentional bug in the endgame comparison between Optimistic and zk Rollup. The conclusion was that Optimistic Rollup would outperform zk Rollup in the long run because there is no proving overhead. But in fact, Optimistic and zk Rollup actually take turns to take the lead in performance over time:Different types of Secured Rollups have different bottlenecks at different stages, ...
msfewzk, zkVM, zkEVM and their Future
TL; DRZero-knowledge proof, which can guarantee computational integrity, correctness and privacy, has a lot of use cases in blockchain scaling and privacy.zk-SNARK and zk-STARK have their own advantages, and the combination of these two has more potential.zkVM empowers applications with zero-knowledge proofs, and zkVM can be categorized by instruction sets in mainstream, EVM, or newly-built ones.EVM compatibility includes EVM compatibility, equivalence, and specification-level compatibility.z...
msfew(Almost) Everything about Rollup
This post focuses on the Layer2 Rollup universe of Ethereum (only including Secured Rollup), and will explore the good and bad of the current Rollups from the core concepts and mechanism design in an easy-to-understand way, and think about the potential routes and advantages and disadvantages of each of their future solutions in terms of decentralization, further scaling, composability, and additional features such as privacy. A Secured Rollup is a Rollup model like Arbitrum or Optimism, wher...
msfew「Unified to Divided」Modular Blockchain and Data Availability Layer
0. Rollup’s BottleneckIf you read the previous post on Rollup I wrote, then you probably noticed that there was an intentional bug in the endgame comparison between Optimistic and zk Rollup. The conclusion was that Optimistic Rollup would outperform zk Rollup in the long run because there is no proving overhead. But in fact, Optimistic and zk Rollup actually take turns to take the lead in performance over time:Different types of Secured Rollups have different bottlenecks at different stages, ...
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
No activity yet