Checkout our latest Litepaper here:

https://mirror.xyz/hyperoracleblog.eth/FKvpIGI7fiuNr5rnTlFWAdxk4QCNFIR9rmqDPxWLc2w

Abstract

Blockchain has completely transformed the way we view trust and decentralized systems. However, decentralized applications face challenges when it comes to securely and reliably organizing as well as automating data in an off-chain context. This is where programmable zkOracle comes in - a new type of decentralized oracle network that utilizes zero-knowledge proofs to bring on-chain data to off-chain context, perform off-chain computation for on-chain context, and verify off-chain proofs in any environment.

In this article, we introduce HyperOracle (Hyper Oracle), a programmable zkOracle protocol that aims to address the limitations of existing middle layer solutions and enable a new wave of decentralized applications.

0. Definition of zkOracle

a) Framing of Oracles

When people hear the term "oracle," they often associate it with the price feed oracle, which provides off-chain data to on-chain smart contracts. However, this is just one type of oracle among many.

A straightforward explanation of the Oracle concept, as outlined in this educational resource, divides it into two main types:

• Input Oracle: delivers off-chain data to on-chain context (ex: Chainlink Price Feeds).

• Output Oracle: delivers on-chain data to off-chain context for advanced computation (ex: HyperOracle zkIndexing).

In the realm of blockchain, the terminology "input" and "output" are used to distinguish between two types of oracles: input oracles and output oracles. In addition, HyperOracle is defining the I/O oracle, a specialized type of oracle that integrates both input and output oracles by first following the output oracle's flow and then the input oracle's. Each oracle can be further broken down into three components: data source, computation, and output.

• Input Oracle

  • Data Source: Off-chain data (e.g. CEX price feeds, real-world weather data)

  • Computation: Aggregation of off-chain data and "uploading" of data

  • Output: On-chain data (equivalent to off-chain data, but stored on-chain)

• Output Oracle

  • Data Source: On-chain data (e.g. smart contract interactions or events like ERC-20 transfers or ERC-721 minting)

  • Computation: Indexing, aggregation, filtering, or other complex computation

  • Output: Off-chain data in an organized and easy-to-use form

• I/O Oracle

  • Combines Input Oracle and Output Oracle with Output flow first, then Input flow.

In summary, oracles are software programs that handle information within the context of a blockchain. Further information about HyperOracle zkAutomation and zkIndexing will be discussed in subsequent sections.

b) ZK (Zero-Knowledge)

'Trustless' refers to a quality of a decentralised blockchain, whereby in using the network there is no need to rely on trust in a third party.

Zero-knowledge protocols or proofs ensure the validity of computation as explained in this article. They allow us to prove that the computation is correct without relying on external trust. As verifiers, we can be sure that the output data is also correct.

With zk, the computation outputs both the final computational result and a zk proof. You can think of zk proofs as a receipt that is always correct. We can verify the short receipt to ensure that all the data (items bought) and computation (summation of item costs) are correct.

The benefits of zk proofs are:

• Easy to verify (no need for complex consensus to agree on data or to re-run computation with full data; verification can be performed in any context, leading to interoperability and composability possibilities)

• Faster finality (once data and zk proof are verified, they can be considered fully correct and finalized)

• Highest security (purely based on cryptography and math)

• Simpler system and mechanism (no need to learn about complicated tokenomics or mechanisms)

• Can be used for any computation

In summary, zk is a powerful cryptographic stack for trustless and secure computation.

c) Issue of Traditional Oracle Network

Traditional oracle networks, such as Chainlink or The Graph, have typically created new staking networks, rather than extending the base layer. These networks rely on tokenomics and staking mechanisms to ensure overall security and decentralization. However, this approach results in several issues:

• Security

  • Lack of Uniformity with Base Layer Blockchain:

    These networks create separate new networks in addition to the base layer blockchain. They cannot inherit the established security level and mature ecosystem model of Ethereum. In practice, they are much less secure than base layer blockchains such as Ethereum.

  • Uncertain Trust Established by Tokenomics:

    The security of these networks depends on variables such as the number of nodes and the number of honest operators in the network. It is difficult to determine the actual level of trust and security of the oracle network. Additionally, the security of the network is tied to tokenomics, introducing another risk factor that comes with usually high trading activity of a network's token.

  • Low Cost and High Profit of Attack:

    These networks often serve as the primary component of decentralized applications with high accrued value. The potential profit of attacking these protocols by attacking the oracle network is high, while the cost of attacking the oracle network is low if its token price or the staking requirement is too low.

• Decentralization

  • High Network Participation Barrier:

    The more nodes or parties participate in a network, the better the decentralization level. However, in some traditional oracle networks, the barrier or lowest staking amount is too high for normal actors to afford participation. For example, The Graph requires about 100K GRT (US$16000 as of 3/1) to simply start an indexer node without considering hardware requirements, and 10K GRT (US$1600 as of 3/1) to challenge and report a wrong behavior. These high barriers make it difficult for spontaneous and honest nodes to participate in network activities. Additionally, starting up a new network requires large capital for initial staking.

  • Token Distribution Centralization:

    Usually, the entities behind these networks control a large portion of token supply. A metric to measure the decentralization level of a network is the Nakamoto Coefficient. It represents the smallest number of independent entities that can act collectively to shut down a blockchain. A larger coefficient may indicate a more decentralized network. However, only 4 entities are needed to shut down The Graph's network. The centralization of token distribution makes the tokenomics and overall mechanism centralized.

• Efficiency

  • Overhead in Performance:

    The most critical factor of an oracle network is performance. A traditional distributed network usually increases latency as the number of nodes in the network grows. If it’s not a 1-of-N trust model (”the system works as long as at least one of them does what you expect them to.”) like zk network, it’s hard to both achieve decentralization (more nodes), and performance (relatively less nodes).

  • Waste of Computation Power:

    Traditional decentralized networks with PoW mechanism have a lot of redundant computation and wasted computing power. These are used in the consensus generation process to protect the overall security of the network. However, this wasted computing power also represents a higher cost of operation and service usage.

d) zkOracle

A zkOracle addresses and resolves the aforementioned issues with the following solutions, including:

• Providing a unstoppable autonomous network

• Math as the consensus

• Safeguarding the security of the base layer

• A 1-of-N trust model

• Optimal cryptography-native decentralization

• Efficient computing power allocation (ideally no excess wasted)

In later sections, we will compare traditional oracle networks with zkOracle protocol, detailing their differences.

As a component that processes data, an oracle must ensure both the accuracy and security of computation. It is important to confirm that the output is valid and correct and that the verification process is fast (sublinear).

To achieve a trustless and secure oracle, we need to make it a zkOracle.

HyperOracle zkOracle is natively categorized as output zkOracle and I/O zkOracle.

I. Output zkOracle

An output zkOracle is an output oracle that uses zk to prove its computation’s validity. An example of this is HyperOracle zkIndexing Meta App.

• Data Source: On-chain Data

  The straightforward solution is to use on-chain data as the source. This data has already been verified and secured by the blockchain. Off-chain data sources cannot efficiently reach the trust level of on-chain data (at least not yet, according to this source). The on-chain data source solution requires zkOracle to act as an output oracle.

• Computation: Execution and ZK Proof Generation

  The solution is to create a zk proof of the computation (typically indexing, aggregation, and filtering…) and enable the step of accessing the data source in a zero knowledge fashion. This adds a layer of validity and trustlessness to the computation. The output will now be accompanied by a zk proof, making the computation and output verifiable.

• Output: Execution Output and On-chain Verifiable zk Proof

  The output of the computation will be both the execution output and a verifiable zk proof. The proof can be easily verified in a smart contract or any other environment. The verification component can confirm the validity of the execution of the zkOracle.

II. I/O zkOracle (Output + Input)

An I/O zkOracle is an output oracle and an input oracle both with ZK as computation. An example is HyperOracle zkAutomation Meta App.

In this case, zkOracle will function as a combination of two oracles that operates in two stages:

• Data Source: On-chain Data

  The data source for I/O zkOracle is identical to the output zkOracle.

• Computation: Execution and ZK Proof Generation

  The computation of I/O zkOracle includes the output zkOracle (which involves indexing, aggregation, and filtering) as well as the input zkOracle (which involves setting up off-chain computation results as calldata for smart contract calls). The combination of both parts makes it feasible to automate smart contracts with complex off-chain computation.

• Output: On-chain data and On-chain Verifiable zk Proof

  The output for this stage includes on-chain data which is the execution output provided on-chain as calldata, and a verifiable zk proof. This proof is easily verifiable in smart contracts or any other environment. The verification component can confirm the validity of the execution of I/O zkOracle.

III. Definitions

Technically, zkOracle is an oracle with verifiable pre-commit computation.

Functionally, zkOracle utilizes zk to ensure the computation integrity of the oracle node for the oracle network's security, instead of staking and slashing mechanism.

In essence, zkOracle is an oracle that utilizes zk for computation and data access, while also using on-chain data for the data source to secure the oracle in a trustless manner.

1. zkOracle Protocol

zkOracle = zkPoS + zkGraph run in zkWASM

a) zkOracle Overview

HyperOracle is a network of zkOracles designed for blockchains. At present, the zkOracle protocol operates solely for the Ethereum blockchain. It retrieves the data from every block of the blockchain as a data source with zkPoS and processes the data using programmable zkGraphs that run on zkWASM, all in a trustless and secure manner.

Here is the zkOracle design for the Ethereum blockchain. This serves as a foundational design for a zkOracle, complete with all of the essential components.

zkPoS verifies Ethereum consensus with a single zk proof that can be accessed from anywhere. This allows zkOracle to obtain a valid block header as a data source for further processing.

zkWASM (zkVM in the graph) is the runtime of zkGraph, providing the power of zk to any zkGraph in the HyperOracle Network. It is similar to the kind of zkEVM used in ZK Rollups.

zkGraph (run in zkWASM) defines customizable and programmable off-chain computation of zkOracle node’s behaviors and zkGraph Standards (Previously called Meta Apps). It can be thought of as the smart contract of the HyperOracle Network.

b) zkPoS

Trustless Block Header Fetching, the “Data Source” in HyperOracle Network

One crucial step in implementing a zkOracle is to retrieve blockchain data for the data source, specifically block header data. Block header data serves as the essential entry point for obtaining the actual data (the three roots) needed for the zkOracle.

There are different methods to acquire a block header, but the simplest and least secure or decentralized way is to obtain it from a trusted source, such as Infura. Another option is to use current light clients like Helios.

The solution for trustless block header fetching is zkPoS, which proves Ethereum's consensus with zk. Combining zkPoS and light clients like Helios, we can build a SNARK-based light client that uses off-chain computation to eliminate most of the computation of client verification..

To maintain its trustless nature, zkPoS for a zkOracle presents the following challenges:

• Constant (short) verification time

• Constant (small) proof size

• Performant proof generation

• No external trust to third-party

HyperOracle zkPoS will deliver a zk light client and address the above challenges by:

• SNARKifying block attestation and other logics of Ethereum consensus (see graph below)

• Recursive proof for multiple blocks of Ethereum consensus

For more details, please refer to our previous blog post: zkPoS: End-to-end Trustless.

zkPoS will enhance the end-to-end trust minimization of HyperOracle zkOracle by providing a trustless data source as the input for the oracle.

c) zkGraph

Customizable Off-chain Computation, the “Smart Contract” in HyperOracle Network

I. Intro to zkGraph

zkGraph defines the off-chain computation of HyperOracle nodes, including data-related behaviors and zk proof generation, much like how smart contracts define the EVM computation of Ethereum nodes.

Smart contract developers can build both the smart contract and the zkGraph. Users can then interact with both.

To utilize the infrastructure of HyperOracle zkGraph Standards, developers must configure and code their zkGraph to specify how they want the data to be handled. The HyperOracle nodes then process the data and generate a zk proof based on the specified definitions.

In summary, a zkGraph is a program that defines the mapping of data (after the data preprocessing of zkPoS) and configures zkGraph Standards.

II. Develop zkGraph

A zkGraph is customizable and programmable, consisting of three main components that can be fully customized:

• Manifest (zkgraph.yaml): The data source, used to configure information such as the zkGraph Standards used, the target blockchain network, and the target smart contract.

• Schema (schema.graphql): The data structure, used to define how data is stored and accessed.

• Mapping (mapping.ts): The data mapping (Off-chain Computation), used to compute blockchain data into other forms.

The core of a zkGraph is the mapping (mapping.ts) file. The code defines the off-chain computation program.

The mapping file usually defines handlers for filtering on-chain events or setting up calldata of smart contract automation. The filters are run in zkWASM (details in the next section), and the zk proofs are generated to ensure computational integrity and validity.

For deployment, all code files for zkGraph will be stored in EthStorage, which is a storage scaling layer supported by Ethereum ESP. This will guarantee that development pipeline for zkGraph is fully decentralized.

Below is the sample code of a zkGraph (for illustrative purposes only):

III. zkGraph’s Subgraph-Equivalence

It is a common practice to avoid reinventing the wheel and instead leverage the existing ecosystem. zkGraph is the equivalent to The Graph's Subgraph.

Migrating existing Subgraphs (over 600 and growing) to zkGraph requires just 10 lines of configuration difference. Implementations such as Standardized Subgraph and ecosystem tooling like Instant Subgraph and Subgraph Uncrashable can be used for developing zkGraph.

With zkWASM, zkGraph supports the general computation of any AssemblyScript (~TypeScript) syntax. In other words, HyperOracle zkGraph Standards are fully customizable and programmable.

d) zkWASM

Power zkGraph with ZK

Since zkGraph is fully customizable and programmable, it requires a general runtime environment to execute. Similar to how EVM runs smart contracts, zkWASM (zkVM of WebAssembly) runs zkGraphs.

As a part of the Subgraph-Equivalence, zkGraph also employs WASM-based mappings. It is "translated" into AssemblyScript, a language designed to be run in a WebAssembly runtime environment.

The Graph uses wasmtime as the WebAssembly runtime for Subgraph, while HyperOracle uses zkWASM as the WebAssembly runtime for zkGraph. This difference in execution engines makes zkGraph zk, without sacrificing any general computation ability. Replacing wasmtime with zkWASM is like replacing EVM with zkEVM. Any program run in zkWASM has the superpower of ZK, including verifiability, trustlessness, decentralization, and computational integrity.

HyperOracle zkGraph are not limited to be running exclusively in zkWASM. We value the decentralization of prover/client diversity and are constantly exploring new ways to power zkGraph with zk.

To learn more about zkWASM, please take a look at our previous blog post: zkWASM, The Next Chapter of ZK and zkVM. For further technical details, you can refer to the paper titled ZAWA: A ZKSNARK WASM Emulator.

zkWASM will enable HyperOracle zkGraph to achieve programmable configuration, general computation, subgraph equivalence, and the superpower of zero-knowledge proofs.

e) zkOracle in HyperOracle Network

Here is the conceptual architecture for a running zkOracle node in the HyperOracle network.

The design at the start of this section is similar to the previous one, with a few changes made to highlight certain details.

To discuss the design, let's move from left to right and top to bottom:

1. Ethereum blockchain serves as the original on-chain data source for zkOracles, but in the future, any network can be used.

2. The HyperOracle zkOracle node consists of two main components: zkPoS and zkWASM.

   • zkPoS fetches the block header and data roots of the Ethereum blockchain by proving Ethereum's consensus with zk. The zk proof generation process can be outsourced to a decentralized prover network. zkPoS works as the foreign circuit of zkWASM.

   • zkPoS feeds the block header and data roots to zkWASM. zkWASM takes this data as essential inputs for running zkGraphs.

   • zkWASM runs customized data mappings defined by zkGraphs and generates zk proofs of those operations. The operator of the zkOracle node can choose the number of zkGraphs they wish to run (from one to all deployed zkGraphs). The zk proof generation process can be outsourced to a decentralized prover network.

3. The output of a zkOracle is off-chain data that developers can use through HyperOracle zkGraph Standards (which are covered in the next sections). The data also comes with zk proofs that demonstrate the validity and computation of the data.

Only one zkOracle node is necessary to maintain network security. In the HyperOracle network, there can still be multiple zkOracle nodes targeting zkPoS as well as each zkGraph. This enables parallel generation of zk proofs, which can significantly enhance performance.

2. zkGraph Standards (Previously Meta Apps)

zkGraph Standards = zkIndexing + zkAutomation, with zkGraph

zkOracle protocols are the technical architecture of HyperOracle. zkGraph Standards (or zkOracle services) are the “products” of HyperOracle.

HyperOracle zkGraph Standards provide a range of infrastructure services that can be used by any DApp developer. As every DApp requires specific infrastructure, zkGraph Standards offer fully decentralized and secure options for the DApp.

a) Fixing Infrastructure

Note: A better and more accurate term for “Infrastructure” is “Middleware”. Here we use the generic term of “Infrastructure” for ease of the understanding.

A decentralized application (DApp) is more complex than just a smart contract. A complete DApp should include at a minimum:

• Interface (usually a website serving as the front-end)

• Infrastructure/middleware component (which may include an indexing service to organize data, an automation/keeper network to automatically call functions, a price oracle to provide data, or all of these)

• Smart contract

Since the introduction of smart contracts, consensus researchers and network engineers have been exploring ways to scale the network and increase the computational capabilities of smart contracts.

To achieve better performance without sacrificing the decentralization of a blockchain, the best approach currently available is to use rollups, such as Optimistic Rollup and ZK Rollups.

Moving forward, we must also enhance the infrastructure for DApps. It's important to note that the issues with current infrastructure protocols extend beyond scalability, encompassing concerns around decentralization, trustlessness, and security. Since infrastructure is not inherently built into the blockchain network, it cannot fully leverage the existing advantages of blockchain technology. But is there a solution?

By extending DApps' capabilities, infrastructure can become an extension of smart contract's original features, which are currently isolated on the blockchain.

To achieve the desired level of decentralization, the infrastructure must convince the blockchain network (which is not aware of it) of the infrastructure's off-chain computations.. There are two effective ways to accomplish this:

Firstly, convince L1 and then upgrade the infrastructure for decentralization:

• Run in smart contract. (However, infrastructure is an extension to smart contracts, so it cannot be run in smart contracts by definition.)

• Provide some kind of proof. (Optimistic, ZK, CK, or Modular Hybrid…)

We will go over the advantages of ZK over Optimistic for infrastructure in later sections. For now, we look at a more fitting solution, HyperOracle zkGraph Standards, to:

1. Convince L1 with zk proof (a short receipt ensures computational integrity).

2. Provide decentralized infrastructure.

3. Build the next generation of DApps.

In essence, HyperOracle Meta Apps bring innovation to infrastructure, similar to the way ZK Rollups bring innovation to blockchain.

b) zkAutomation

Trustless Automation for Smart Contracts

I. Intro to zkAutomation

The blockchain world is driven by automation, bots, and keepers. Automated programs are required to call smart contracts at certain intervals to maintain the AMM's optimal price flow or to keep lending protocols healthy by avoiding bad debt.

Sometimes, these automation calls are too complex for on-chain calculation, too frequent for governance voting, and too critical for permissionless system. In such cases, developers require automation protocols to provide these services, so they don't have to build and run their own automation.

However, having a universal protocol for automation and keeper functions is insufficient. The automation's execution and off-chain data source computations must be secure. If these computations are invalid, the operator nodes must be flagged and punished on the automation network.

zkAutomation is the only automation infrastructure in the market that can execute both with zero knowledge proofs. zkAutomation is not just an output zkOracle meta app, but it is also an I/O zkOracle, because the data flows from on-chain (original data) to off-chain (zkGraph source) to on-chain (automation triggered).

zkAutomation is HyperOracle’s trustless automation protocol based on zero knowledge proofs. zkAutomation's automation execution is entirely secured by zk, and the automation sources (data sources of the automation) and trigger conditions (when to trigger the automation) are fully customizable using zkGraphs. Developers can build bots, such as arbitrage bots, to perform on-chain trading for profit, keepers like liquidation keepers to safeguard their protocol health, or even automated protocols like on-chain ETFs or on-chain stable coins to achieve fully decentralized financial applications.

II. Use zkAutomation

Developers can use zkAutomation by deploying their automation program through HyperOracle's Web App. They simply need to specify their target contract, target function, and source (when to trigger). For more complex trigger conditions, developers can choose to either trigger automation every N-th block (in scenarios like a keeper bot) or use a zkGraph as the off-chain source.

zkGraphs for zkAutomation can be built from scratch, migrated from zkGraphs for zkIndexing or existing subgraphs, or by reusing deployed ones. If developers choose to migrate from an existing zkGraph for zkIndexing, they only need to change the Meta App type of that zkGraph to make it a valid source for zkAutomation.

Once the zkAutomation job has been registered (and the zkGraph has been optionally deployed), the corresponding zkAutomation service will start and automation jobs will be executed when the trigger condition is met.

c) zkIndexing

Trustless Indexing, Querying, and Accessing of Blockchain Data

I. Intro to zkIndexing

Accessing most on-chain data directly can be a challenge for developers. One potential solution is for developers to run their own indexer to organize the data into a more easily searchable format. However, this can be a difficult and time-consuming process as it involves rebuilding the entire blockchain state and indexing events from smart contracts. This is where indexing protocols like The Graph come in handy.

As mentioned in a blog post about Helios., blockchains are used for their trustlessness, allowing self-sovereign access to wealth and data. Ethereum has delivered on this promise, but there are concessions for convenience, such as centralized RPC servers like Alchemy. These providers run high-performance nodes on cloud servers so users can easily access chain data, but users must trust them and can't verify the correctness of their queries.

Having a centralized RPC, or a universal indexing and querying protocol is not enough. It is also important to ensure that the indexed data is accurate and reliable since incorrect data can be even more problematic than not having an indexer at all. In other words, it is crucial to guarantee the computational integrity and security of the indexing process.

zkIndexing is a unique indexing infrastructure that excels in both accuracy and security using zero knowledge proofs. zkIndexing is a typical output zkOracle meta app, with the data flowing from on-chain (original blockchain data) to off-chain (zkGraph indexed data).

zkIndexing is HyperOracle’s trustless indexing protocol based on zero knowledge proofs. zkIndexing’s indexing and querying schema are fully customizable with zkGraphs. Developers can build any end-to-end decentralized application with zkIndexing.

II. Use zkIndexing

After the deployment of a zkGraph, the corresponding zkIndexing service will start indexing the blockchain and data will be queryable for any developer.

To utilize zkIndexing, developers need to utilize a zkGraph to define the indexing behaviors and querying schema.

Developers can build zkGraphs for zkIndexing from scratch, migrate them from existing subgraphs, or reuse deployed zkGraphs. For existing protocols like Uniswap, AAVE, or Curve, there are multiple open-source implementations available.

Once the zkGraph is deployed, the corresponding zkIndexing service will start indexing the blockchain, and the data will be queryable for any developer.

3. Comparisons

a) zkOracle Protocol vs. Other Oracle Network

When creating a decentralized oracle, the zkOracle protocol has notable differences compared to traditional ones.

To start, the workflow and architecture are distinct. The zkOracle protocol is more streamlined since all intensive computation is carried out securely and trustlessly off-chain using ZK. In contrast, traditional oracles are restricted to trustless aggregation and "trusted" computation by a smart contract's limited computing capability.

Based on the graph shown above, we can compare the advantages of zkOracle protocol to traditional oracle networks:

• Decentralization (Trustlessness, Security, and Censorship-Resistence)

  The zkOracle protocol, HyperOracle, operates without requiring external trust in third parties, making it a trustless network. In contrast, traditional oracle networks rely on trusted third parties and networks. The zkOracle protocol follows the 1-of-N trust model, as defined in Vitalik Buterin's article on trust models, which only requires one node to maintain the network's health and uptime. Traditional oracle networks, on the other hand, are only considered decentralized when they reach an extremely large number of nodes. The security of the zkOracle protocol is fully based on mathematics and cryptography, and it inherits its security from Ethereum, which serves as its data source.

• Performance and Finality

  Finality is achieved at the end of the challenge period, according to a widely-accepted definition of finality for rollups. Traditional oracle and zkOracle protocols can be compared to Optimistic and ZK Rollups, respectively, so we can use this definition for performance comparison. Input oracles, such as Chainlink Price Feeds, and output oracles, such as The Graph Protocol, rely on the slashing or challenge period, which can take days or even weeks. However, zkOracle protocols, like HyperOracle, are based on the zk proof generation time. While zk proof generation has overheads compared to pure computation, the oracle's performance still improves from days or weeks of challenge period to minutes or even seconds even without considering parallel proving. Due to the nature of zk, adding more nodes to the zkOracle protocol can nearly linearly boost its performance with parallel proving, instead of only creating redundancy in the network.

• Cost

  The zkOracle protocol follows a 1-of-N trust model, which means that only one honest node is needed to create a secure network. This eliminates the redundancy found in traditional oracle networks, making it a more secure option. Despite the added cost of zk proving (in the case of zkEVM, proving cost for a large batch of transactions is only $0.06), the zkOracle protocol generates lower fees than traditional oracle networks.

• Mechanism and Architecture

  Traditional oracle networks have complex architectures that involve multiple components with different mechanisms. They also have many dependencies, such as complex tokenomics, and uncertain third-party reputation. In comparison, the zkOracle protocol has a much simpler architecture and its mechanism is much more straightforward. As long as there is one honest zkOracle node and the zk proofs are verified, all associated data is correct.

b) zkAutomation vs. Other Automation Protocols

zkAutomation offers all the advantages of zkOracle protocol, along with specific benefits when compared to other automation protocols like Keep3r Network, Chainlink Automation, and Gelato Network. In addition to having all the features of these automation protocols, zkAutomation also provides:

• Trustless Off-chain Source

  zkAutomation provides trustless automation based on off-chain source with programmable zkGraph. This allows for flexible automation that triggers based on off-chain computation results while maintaining a secure mechanism.

• Verifiability and Security with ZKP

  zkAutomation's zk proofs enable full verifiability. Other automation protocols usually rely on DAO, "social consensus", or even legal documents to restrict bad behaviors, which can create uncertainty and additional time or power burden for protecting the network's health. In contrast, zkAutomation's network is autonomous and automated with pure cryptography-based proof generation and verification without human intervention.

c) zkIndexing vs. Other Indexing Protocols

zkIndexing offers all the benefits of the zkOracle protocol, as well as several advantages over other indexing protocols like The Graph. These include:

• Improved Performance with Trustlessness

  Performance is a key metric for an indexing and querying service, with latency of request and response largely dependent on the geographic distance between the node and requester. Traditional decentralized indexing networks struggle with this due to the honest majority assumption. While requesters can trust the outcome from the entire network, they cannot trust a single node, which can affect performance. zkIndexing solves this with zk proofs. Developers can request data trustlessly from only one HyperOracle zkOracle node, which is geographically closest and fastest.

• Verifiability and Security with ZKP

  Traditional indexing networks currently only serve certain types of decentralized applications that do not consider data correctness as a critical component, such as dashboards. This is not due to a lack of desire on the part of developers to integrate these indexing services as core components, but rather because these networks are not yet secure enough through multi-sig controlled dispute council. zkIndexing addresses this issue with verifiability and security backed by the mathematics and cryptography of zk proofs. Developers can build any type of decentralized application with zkIndexing.

Summary

This whitepaper introduces HyperOracle, a programmable zkOracle protocol that safeguard blockchain security and decentralization.

HyperOracle has three main components: zkPoS, zkGraph and zkWASM. zkPoS securely retrieves block headers and data roots from the Ethereum blockchain; zkWASM runs programmable customized off-chain computation and data mapping defined by zkGraph. Additionally, HyperOracle Meta Apps - zkAutomation and zkIndexing - provide secure automation for smart contracts and indexing/querying of blockchain data defined by zkGraph. Compared to other traditional oracle networks, HyperOracle addresses existing issues of security, decentralization, and performance through proposing a trustless zk powered infrastructure solution.

As the blockchain industry evolves and demand for the next generation of decentralized applications increases, HyperOracle, with advances in oracle technology, will serve as a crucial backbone for DApps and establish the new paradigm for programmable infrastructure.