Author: Mike@Foresight Ventures

1. Concept Introduction

Regarding the concept of coprocessors, a very simple and easy-to-understand example is the relationship between a computer and a graphics card. The CPU can handle most tasks, but when it encounters specific tasks that require more computing power, it needs the help of a graphics card. For example, in tasks such as machine learning, graphic rendering, or running large games, if we want to avoid frame drops or lag while playing large games, we definitely need a high-performance graphics card. In this scenario, the CPU is the processor, and the graphics card is the coprocessor. Applied to the blockchain, smart contracts are the CPU, and ZK coprocessors are the GPU.

The key point is to assign specific tasks to specific coprocessors, just like in a factory where the boss knows the steps of each process and can do it himself or teach the employees the entire production process. However, this is inefficient as it can only produce one by one. Therefore, the boss hires many specific employees who specialize in their own work in their own workshops along the production chain. The links in the chain can communicate and collaborate with each other, but do not interfere with each other's work. They only do what they are best at. Those with fast hands and good physical strength tighten screws, those who understand machine operation operate the machines, and those who understand finance and accounting calculate production quantity and costs. Asynchronous collaborative work maximizes work efficiency.

During the industrial revolution, capitalists had already discovered that this model could bring the maximum productivity to their factories. However, due to technological or other reasons, when a step in the production process encounters a bottleneck, it may be necessary to outsource it to another specialized manufacturer. For example, a company producing mobile phones may have the chips produced by another specialized chip company. In this case, the mobile phone company is the central processor, and the chip company is the coprocessor. Coprocessors can easily handle specific tasks that the central processor itself finds difficult and cumbersome.

In a broad sense, ZK coprocessors are quite diverse. Some projects call themselves coprocessors, while others call themselves ZKVM, but they all follow the same idea: allowing smart contract developers to prove off-chain calculations on existing data without state. In simple terms, it means offloading some on-chain calculations to the off-chain, reducing costs and increasing efficiency, while using ZK to ensure the reliability of the calculations and protect the privacy of specific data. In the data-driven world of blockchain, this is particularly important.

2. Why Do We Need ZK Coprocessors

One of the biggest bottlenecks faced by smart contract developers is still the high cost associated with on-chain calculations. Because each operation requires Gas, the cost of complex application logic quickly becomes too high to execute. Although the archival nodes in the DA layer of the blockchain can indeed store historical data, which is why off-chain analysis applications like Dune Analytics, Nansen, 0xscope, and Etherscan have access to so much data from the blockchain and can trace it back a long time, for smart contracts, accessing all this data is not simple. They can only easily access data stored in the virtual machine state, the latest block data, and the data of other public smart contracts. Accessing more data may require a lot of effort:

Smart contracts in the Ethereum Virtual Machine (EVM) can access the block header hashes of the most recent 256 blocks. These block headers contain all the activity information in the blockchain up to the current block, compressed into a 32-byte hash value using Merkle trees and the Keccak hash algorithm.

Although this data is hashed, it can actually be decompressed—it's just not easy to do. For example, if you want to access specific data from the previous block without trust, it involves a series of complex steps. First, you need to retrieve off-chain data from the archival nodes, then build a Merkle tree and a validity proof for the block to verify the authenticity of the data on the blockchain. Then, the EVM will process these validity proofs for verification and interpretation, which is not only cumbersome and time-consuming, but also very expensive in terms of Gas.

The fundamental reason for this challenge is that blockchain virtual machines (such as EVM) are not suitable for handling large amounts of data and intensive computing tasks, such as the decompression work mentioned above. The design focus of the EVM is to execute smart contract code while ensuring security and decentralization, rather than handling large-scale data or complex computing tasks. Therefore, when it comes to tasks that require a large amount of computing resources, it is usually necessary to find other solutions, such as using off-chain computing or other scaling technologies. This is where ZK coprocessors come into play.

ZK rollups are actually the earliest form of ZK coprocessors, supporting the same type of calculations used on L1 at a larger scale and quantity. This coprocessor operates at the protocol level, while the ZK coprocessor we are talking about now operates at the dapp level. By allowing smart contracts to use ZK proofs to offload historical on-chain data access and calculations without trust, ZK coprocessors enhance the scalability of smart contracts. Developers can offload expensive operations to ZK coprocessors and simply use the results on-chain, instead of executing all operations in the EVM. By decoupling data access and calculations from blockchain consensus, this provides a new way of scaling smart contracts.

ZK coprocessors introduce a new design pattern for on-chain applications, eliminating the limitation that calculations must be completed in the blockchain virtual machine. This allows applications to access more data and run at a larger scale than before, while controlling gas costs, without compromising decentralization and security, thus increasing the scalability and efficiency of smart contracts.

3. Technical Implementation

This section will explain how the zk coprocessor solves problems from a technical perspective using the architecture of Axiom. It mainly involves two core aspects: data retrieval and computation. In these two processes, ZK ensures both efficiency and privacy.

3.1 Data Retrieval

One of the most important aspects of executing calculations on the ZK coprocessor is to ensure correct access to all input data from the blockchain history. As mentioned earlier, this is quite difficult because smart contracts can only access the current blockchain state in their code, and even this access is the most expensive part of on-chain calculations. This means that historical on-chain data, such as transaction records or previous balances (interesting on-chain inputs for calculations), cannot be used locally by smart contracts to verify the results of the coprocessor.

ZK coprocessors solve this problem in three different ways, balancing cost, security, and development difficulty:

1. Storing additional data in the blockchain state and using EVM to store, read, and verify all data used by the coprocessor on-chain. This method is quite expensive, especially for large amounts of data.

2. Trusting Oracle or signer networks to verify the input data of the coprocessor. This requires users of the coprocessor to trust Oracle or multi-signature providers, which reduces security.

3. Using ZK proofs to check whether any on-chain data used in the coprocessor has been committed to in the blockchain history. Any block in the blockchain submits all past blocks, thereby providing cryptographic guarantees for data validity and not requiring additional trust assumptions from users.

3.2 Computation

Executing off-chain computations in the ZK coprocessor requires converting traditional computer programs into ZK circuits. Currently, all methods that achieve this have a significant impact on performance, with the cost of ZK proofs ranging from 10,000 to 1,000,000 compared to local program execution. Additionally, the computation model of ZK circuits is different from standard computer architecture (e.g., all variables must be encoded with a large prime number as the modulus, and execution may be non-deterministic), making it difficult for developers to write them directly.

Therefore, the three main methods for specifying computation in the ZK coprocessor mainly involve balancing performance, flexibility, and development difficulty:

1. Custom circuits: Developers write their own circuits for each application. This method has the greatest performance potential but requires a significant amount of developer effort.

2. eDSL / DSL for circuits: Developers write circuits for each application but abstract ZK-specific issues in an opinionated framework (similar to using PyTorch for processing neural networks). However, this slightly reduces performance.

3. zkVM: Developers write circuits in existing virtual machines and verify their execution in ZK. Using existing virtual machines provides the simplest experience for developers, but due to the different computation models between the virtual machine and ZK, both performance and flexibility are relatively low.

Four, Application

The application of ZK coprocessors is very extensive, covering all application scenarios that Dapps can cover in theory. As long as it is related to data and computation, ZK coprocessors can reduce costs, increase efficiency, and protect privacy. The following will explore what ZK processors can specifically do at the application layer from different perspectives.

4.1 Defi

4.1.1 DEX

Taking the example of the hook in Uniswap V4:

The hook allows developers to execute specified operations at any key point in the lifecycle of a liquidity pool—such as before or after token transactions, or before or after LP position changes—customizing the interaction between liquidity pools, exchanges, fees, and LP positions, such as:

• Time-weighted average market maker (TWAMM);

• Dynamic fees based on volatility or other inputs;

• On-chain limit orders;

• Depositing excess liquidity into lending protocols;

• Customized on-chain oracles, such as geometric mean oracles;

• Automatically compounding LP fees into LP positions;

• Distributing Uniswap's MEV profits to LPs;

• Loyalty discount plans for LPs or traders;

In simple terms, developers can customize the mechanism of pools in Uniswap based on their ideas by fetching any on-chain historical data, providing more composability for on-chain transactions and higher capital efficiency. However, once the code logic becomes complex, it will impose a significant gas burden on users and developers. This is where the ZK coprocessor comes into play, helping to save these gas costs and improve efficiency.

From a longer-term perspective, ZK coprocessors will accelerate the integration of DEX and CEX. Since 2022, we have seen DEX and CEX converging in functionality, with major CEXs accepting this reality and embracing on-chain liquidity shares using existing infrastructure or open source solutions such as Web3 wallets, building EVM L2, and adopting the Lightning Network. This phenomenon is closely related to the promotion of ZK coprocessors. All the functions that CEX can achieve, whether it's grid trading, copy trading, fast lending, or user data usage, can also be achieved by DEX through ZK coprocessors. The composability and freedom of Defi, as well as the trading of small coins on-chain, are difficult for traditional CEX to achieve. At the same time, ZK technology can also protect user privacy while executing.

4.1.2 Airdrops

If some projects want to conduct airdrops, they need smart contracts to query the historical activity of addresses without exposing user address information and execute without introducing additional trust proofs. For example, a project doing Defi lending wants to use the interaction volume with Aave, Compound, Fraxlend, Spark, and a series of lending protocols as the standard for airdrops. The ZK coprocessor's ability to fetch historical data and its privacy features can easily meet this requirement.

4.2 ZKML

Another exciting aspect of ZK coprocessors is in the field of machine learning. Since smart contracts can be given the ability to perform off-chain calculations, efficient on-chain machine learning becomes possible. In fact, ZK coprocessors are currently an indispensable part of ZKML data input and computation. They can extract the input needed for machine learning from the historical on-chain/off-chain data imported into smart contracts and then write the computation into ZK circuits to be deployed on-chain.

4.3 KYC

KYC is a big business, and the web3 world is gradually embracing compliance. With the ZK coprocessor, it is possible to provide smart contract-verifiable proofs by fetching any off-chain data provided by users without exposing any unnecessary user information. In fact, some projects are already implementing this, such as Uniswap's KYC hook, which uses the ZK coprocessor Pado to fetch off-chain data without trust. Asset proofs, educational proofs, travel proofs, driver's license proofs, law enforcement proofs, player proofs, transaction proofs… all historical on-chain/off-chain behaviors, and even a complete identity, can be written into highly credible ZK proofs on-chain while protecting user privacy.

4.4 Social

The speculative nature of Friend.tech is actually stronger than its social nature, with its core being the bonding curve. Is it possible to add a hook to the bonding curve of friend.tech, allowing users to customize the direction of the bonding curve? For example, after the end of the key trading frenzy and the departure of speculators, the bonding curve becomes smoother, lowering the entry barrier for true fans and achieving real growth in private traffic. Or let smart contracts obtain users' on-chain/off-chain social graphs, allowing them to follow their friends with one click on different social Dapps. Or establish private clubs on-chain, such as Degen club, where addresses that meet historical gas consumption conditions can enter, and so on.

4.5 Gaming

In traditional Web2 games, user data is a very important parameter that can improve game operations and provide a better user experience, such as the ELO matchmaking mechanism in MOBA games, the frequency of skin purchases, and more. However, on the blockchain, it is difficult for smart contracts to fetch this data, so centralized solutions are used or the idea is simply abandoned. But the emergence of ZK coprocessors makes decentralized solutions possible.

Five, Project Parties

In this field, there are already some outstanding players, and their ideas are quite similar. They use storage proof or consensus to generate ZK proofs and then deploy them on-chain. However, each has its own technical characteristics and functional implementations.

5.1 Axiom

As a leader in ZK (zero-knowledge) coprocessors, Axiom focuses on enabling smart contracts to access the entire Ethereum history and any ZK verification computation without trust. Developers can submit on-chain queries to Axiom, which then processes these queries through ZK verification and returns the results to the smart contract in a trustless manner. This allows developers to build richer on-chain applications without relying on additional trust assumptions.

To execute these queries, Axiom performs the following three steps:

1. Read: Axiom uses ZK proofs to read data from the block headers, state, transactions, and receipts of Ethereum historical blocks without trust. Since all Ethereum on-chain data is encoded in these formats, Axiom can access all content that archival nodes can access. Axiom verifies all input data of the ZK coprocessor through Merkle-Patricia trie and block header hash chain ZK proofs. Although this method is relatively difficult to develop, it provides the best security and cost for end users, as it ensures that all results returned by Axiom are cryptographically equivalent to on-chain computations in the EVM.

2. Compute: After data ingestion, Axiom applies verified computations. Developers can specify their computation logic in JavaScript frontend, and the validity of each computation is verified in the ZK proof. Developers can access AxiomREPL or refer to the documentation to learn about available computation primitives. Axiom allows users to access on-chain data and specify their own computations through eDSL. It also allows users to write their own circuits using the ZK circuit library.

3. Verify: Axiom provides ZK validity proofs for each query result, ensuring that (1) the input data is correctly extracted from the chain, and (2) the computation is correctly applied. These ZK proofs are verified on-chain in Axiom smart contracts, ensuring the reliable use of the final results in user smart contracts.

Since the results are verified through ZK proofs, Axiom's results have the same level of security as Ethereum's results in cryptography. This method does not make any assumptions about cryptographic economics, incentive mechanisms, or game theory. Axiom believes that this approach will provide the highest level of assurance for smart contract applications. The Axiom team is closely collaborating with the Uniswap Foundation and has received grants from Uniswap to build a trustless oracle on Uniswap.

5.2 Risc Zero

Bonsai:

In 2023, RISC Zero released Bonsai, a proof service that allows on-chain and off-chain applications to request and receive zkVM proofs. Bonsai is a general-purpose zero-knowledge proof service that allows any chain, protocol, and application to leverage ZK proofs. It has high parallelism, programmability, and high performance.

Bonsai allows you to directly integrate zero-knowledge proofs into any smart contract without the need for custom circuits. This enables ZK to be directly integrated into any decentralized application (dApp) on an EVM chain, potentially supporting any other ecosystem.

zkVM is the foundation of Bonsai, supporting broad language compatibility, provable Rust code, and potentially any language compiled to RISC-V (such as C++, Rust, Go, etc.) zero-knowledge provable code. Through recursive proofs, custom circuit compilers, state continuity, and continuous improvements to proof algorithms, Bonsai enables anyone to generate high-performance ZK proofs for various applications.

RISC Zero zkVM:

RISC Zero zkVM was first released in April 2022 and can prove the correct execution of arbitrary code, allowing developers to build ZK applications using mature languages such as Rust and C++. This release is a significant breakthrough in ZK software development: zkVM makes it possible to build ZK applications without building circuits and using custom languages.

By allowing developers to use Rust and leverage the maturity of the Rust ecosystem, zkVM enables developers to quickly build meaningful ZK applications without requiring advanced mathematical or cryptographic backgrounds.

These applications include:

• JSON: Proving the content of a specific entry in a JSON file while maintaining the privacy of other data.
• Where's Waldo: Proving the presence of Waldo in a JPG file while maintaining the privacy of other parts of the image.
• ZK Checkmate: Proving that you see a checkmate without revealing the winning move.
• ZK Proof of Exploit: Proving that you can exploit an Ethereum account without revealing the vulnerability.
• ECDSA signature verification: Proving the validity of an ECDSA signature.

These examples are implemented using mature software ecosystems: most Rust tooling is readily available in Risc Zero zkVM. Rust compatibility is a game-changer for the ZK software world: projects that may take months or years to build on other platforms can be easily addressed on the RISC Zero platform.

In addition to being easier to build, RISC Zero also delivers on performance. zkVM has GPU acceleration with CUDA and Metal, and achieves parallel proofs for large programs through continuity.

Previously, Risc Zero raised $40 million in Series A funding from institutions such as Galaxy Digital, IOSG, RockawayX, Maven 11, Fenbushi Capital, Delphi Digital, Algaé Ventures, and IOBC.

5.3 Brevis

Brevis, under Celer Network, focuses on fetching historical data from multiple chains. It empowers smart contracts to access their complete historical data from any chain and execute comprehensive trustless custom computations. Currently, it mainly supports Ethereum POS, Comos Tendermint, and BSC.

Application Interface:

Brevis' current system supports efficient and concise ZK proofs, providing the following source chain information through ZK proofs for decentralized applications (dApps) contracts connected to the blockchain:

1. Block hash values and related state, transactions, and receipt roots of any block on the source chain.
2. Slot values and related metadata of any specific block, contract, or slot on the source chain.
3. Transaction receipts and related metadata of any transaction on the source chain.
4. Transaction inputs and related metadata of any transaction on the source chain.
5. Any information sent from any entity on the source chain to any entity on the target chain.

Architecture Overview:

Brevis' architecture consists of three main parts:

1. Relayer Network: It synchronizes block headers and on-chain information from different blockchains and forwards them to the validator network to generate validity proofs. Subsequently, it submits the verified information and related proofs to the connected blockchain.

2. Prover Network: It implements circuits for light client protocols and block updates for each blockchain, generating proofs for requested slot values, transactions, receipts, and integrated application logic. To minimize proof time, cost, and on-chain verification cost, the prover network can aggregate and generate distributed proofs simultaneously. Additionally, it can utilize accelerators such as GPU, FPGA, and ASIC to improve efficiency.

3. Validator Contracts on Connected Blockchains: They receive zk-verified data and related proofs generated by the prover network and then provide the verified information to dApp contracts.

This integrated architecture enables Brevis to provide efficient and secure cross-chain data and computation, allowing dApp developers to fully leverage the potential of blockchain. With this modular architecture, Brevis can provide fully trustless, flexible, and efficient data access and computation capabilities for on-chain smart contracts on all supported chains. This provides a new paradigm for dApp development. Brevis has a wide range of use cases, such as data-driven DeFi, zkBridges, on-chain user acquisition, zkDID, social account abstraction, etc., increasing data interoperability.

5.4 Langrange

Langrange shares a similar vision with Brevis, aiming to enhance interoperability between multiple chains through the ZK Big Data Stack. It can create universal state proofs on all mainstream blockchains. By integrating with the Langrange protocol, applications can submit aggregated proofs of multi-chain states, which can then be verified by contracts on other chains in a non-interactive manner.

Unlike traditional bridging and messaging protocols, the Langrange protocol does not rely on specific node groups to relay information. Instead, it uses encryption technology to coordinate real-time proofs of cross-chain states, including those submitted by untrusted users. In this mechanism, even if the source of information is untrustworthy, the application of encryption technology ensures the validity and security of the proofs.

The Langrange protocol initially aims to be compatible with all EVM-compatible L1 and L2 rollups. Additionally, Langrange plans to support non-EVM-compatible chains in the near future, including but not limited to Solana, Sui, Aptos, and popular public chains based on the Cosmos SDK.

Difference between Langrange Protocol and Traditional Bridging and Messaging Protocols:

Traditional bridging and messaging protocols are mainly used to transfer assets or messages between specific pairs of chains. These protocols typically rely on a set of intermediary nodes to confirm the latest block headers of the source chain on the target chain. This pattern is primarily optimized for one-to-one chain relationships based on the current states of the two chains. In contrast, the Langrange protocol provides a more universal and flexible method for cross-chain interactions, allowing applications to interact within a broader blockchain ecosystem, not limited to single chain-to-chain relationships.

The Langrange protocol specifically optimizes mechanisms for proving inter-chain contract states, rather than just information or asset transfer. This feature allows the Langrange protocol to effectively handle complex analyses involving current and historical contract states that may span multiple chains. This capability enables Langrange to support a range of complex cross-chain application scenarios, such as calculating moving averages of asset prices on multi-chain decentralized exchanges (DEXs) or analyzing the volatility of currency market rates on multiple different chains.

Therefore, Langrange state proofs can be seen as an optimization for many-to-one (n-to-1) chain relationships. In this cross-chain relationship, a decentralized application (DApp) on one chain relies on aggregated real-time and historical state data from multiple other chains (n chains). This greatly expands the functionality and efficiency of DApps, allowing them to aggregate and analyze data from multiple different blockchains, providing more in-depth and comprehensive insights. This approach significantly differs from traditional single-chain or one-to-one chain relationships, providing a broader potential and application scope for blockchain applications.

Langrange has received investments from 1kx, Maven11, Lattice, CMT Digital, and gumi crypto.

5.5 Herodotus

Herodotus aims to provide synchronized on-chain data access from other Ethereum layers for smart contracts. They believe that storage proofs can unify the states of multiple rollups, even allowing synchronous reading between Ethereum layers. In simple terms, it involves data fetching across EVM main chains and rollups. Currently, it supports the ETH mainnet, Starknet, Zksync, Optimism, Arbitrum, and Polygon.

The Storage Proof defined by Herodotus is a composite proof used to verify the validity of one or multiple elements in a large dataset, such as data in the entire Ethereum blockchain.

The process of generating Storage Proofs roughly consists of three steps:

Step 1: Obtain a verifiable commitment of the block header storage accumulator

• This step is to obtain a "commitment" that can be verified for the proof. If the accumulator does not yet include the latest block header needed for the proof, we first need to prove the continuity of the chain to ensure coverage of the block range containing our target data. For example, if the data to be proven is in block 1,000,001, and the smart contract storing the headers only covers up to block 1,000,000, then an update to the header storage is needed.
• If the target block is already in the accumulator, the next step can be taken.

Step 2: Prove the existence of specific accounts

• This step requires generating a proof from the state tree comprising all accounts in the Ethereum network (State Trie). The state root is an important part of deriving the block commitment hash and is also part of the header storage. It is important to note that the hash value of the block header in the accumulator may differ from the actual hash value of the block because a different hashing method may be used for efficiency.

Step 3: Prove specific data in the account tree

• In this step, proofs can be generated for specific data points such as nonce, balance, storage root, or codeHash in the account storage. Each Ethereum account has a storage trie (Merkle Patricia Tree) for storing account data. If the data to be proven is in the account storage, additional inclusion proofs for that specific data point in the storage are needed.

After generating all necessary inclusion proofs and computation proofs, a complete storage proof is formed. This proof is then sent to the chain for on-chain verification, based on a single initial commitment (such as blockhash) or the MMR root of the header storage. This process ensures the authenticity and integrity of the data while maintaining system efficiency.

Herodotus has received support from Geometry, Fabric Ventures, Lambda Class, and Starkware.

5.6 HyperOracle

Hyper Oracle is specifically designed for programmable zero-knowledge oracles, aiming to maintain the security and decentralization of the blockchain. Through its zkGraph standard, Hyper Oracle makes on-chain data and on-chain equivalent computation practical, verifiable, and fast. It provides developers with a new way to interact with the blockchain.

The zkOracle nodes of Hyper Oracle mainly consist of two components: zkPoS and zkWASM.

1. zkPoS: This component is responsible for obtaining Ethereum blockchain block headers and data roots through zero-knowledge (zk) proofs to ensure the correctness of the Ethereum consensus. zkPoS also acts as an external circuit for zkWASM.

2. zkWASM: It uses the data obtained from zkPoS as a crucial input for running zkGraphs. zkWASM is responsible for running custom data mappings defined by zkGraphs and generating zero-knowledge proofs for these operations. Operators of zkOracle nodes can choose the number of zkGraphs they want to run, ranging from one to all deployed zkGraphs. The process of generating zk proofs can be delegated to a distributed prover network.

The output of zkOracle is off-chain data, which developers can use through Hyper Oracle's zkGraph standard. This data also comes with zk proofs to verify its validity and computation.

To maintain network security, the Hyper Oracle network only requires one zkOracle node. However, multiple zkOracle nodes can exist in the network, operating for zkPoS and each zkGraph. This allows for parallel generation of zk proofs, significantly improving performance. Overall, by combining advanced zk technology and a flexible node architecture, Hyper Oracle provides an efficient and secure blockchain interaction platform for developers.

In January 2023, Hyper Oracle announced a $3 million seed round financing with participation from Dao5, Sequoia China, Foresight Ventures, and FutureMoney Group.

5.7 Pado

Pado is a unique presence in the ZK coprocessor, as other coprocessors focus on fetching on-chain data, while Pado provides a path to fetch off-chain data. It aims to bring all internet data into smart contracts, partially replacing the function of oracles while ensuring privacy and eliminating the need for trusted external data sources.

5.8 Comparison between ZK Coprocessor and Oracles

• Latency: Oracles are asynchronous, resulting in longer delays when accessing off-chain data compared to ZK coprocessors.
• Cost: While many oracles do not require computation proofs, resulting in lower costs, they have lower security. Storage proofs have higher costs but higher security.
• Security: The maximum security of data transmission is limited by the security level of the oracle itself. In contrast, ZK coprocessors match the security of the chain. Additionally, oracles are susceptible to manipulation attacks due to the use of off-chain proofs.

The following image shows the workflow of Pado:

Pado uses encrypted nodes as backend provers. To reduce trust assumptions, the Pado team will adopt an evolutionary strategy to gradually decentralize the prover service. Provers actively participate in the process of retrieving and sharing user data from network data sources, while proving the authenticity of user data obtained from network data sources. The unique aspect of Pado is that it utilizes MPC-TLS (Multiparty Computation-Transport Layer Security) and IZK (Interactive Zero-Knowledge Proof), allowing provers to blind-proof data. This means that verifiers cannot see any raw data, including public and private user information. However, verifiers can still ensure the source of any transmitted TLS data through encryption methods.

1. MPC-TLS: TLS is a security protocol used to protect the privacy and data integrity of internet communication. When you access a website and see a "lock" icon and "https" in the URL, it means your access is protected by TLS. MPC-TLS mimics the functionality of a TLS client, allowing validators of Pado to collaborate with TLS clients to perform the following tasks:

• Establish TLS connections, including computing master keys, session keys, and verification information.

• Execute queries in the TLS channel, including generating encrypted requests and decrypting server responses.

  It is important to note that these TLS-related operations are performed between the client and the validator through a two-party computation (2PC) protocol. The design of MPC-TLS relies on encryption techniques such as Garbled Circuits (GC), Oblivious Transfer (OT), and IZK.

1. IZK: Interactive Zero-Knowledge Proof is a type of zero-knowledge proof in which the prover and verifier can interact. In the IZK protocol, the verifier's result is to accept or reject the prover's claim. Compared to simple NIZKs (such as zk-STARKs or zk-SNARKs), the IZK protocol has several advantages, such as high scalability for large statements, low computational cost, no need for trusted setups, and minimal memory usage.

Pado is actively developing the kyc hook for Uniswap, seeking more on-chain data application scenarios, and has been selected for the initial Consensys Fellowship program.

Future Outlook

The ZK coprocessor enables the blockchain to allow smart contracts to fetch more data in a cost-effective manner without compromising decentralization, access off-chain computational resources, and decouple the workflow of smart contracts, increasing scalability and efficiency.

From the demand side, the ZK coprocessor is a necessity. Looking at the DEX track alone, the potential of this hook is significant. It can do many things. If Sushiswap does not implement the hook, it cannot compete with Uniswap and will be quickly eliminated. If the ZK coprocessor is not used for the hook, gas will become expensive for developers and users because the hook introduces new logic, making smart contracts more complex, which is counterproductive. Therefore, currently, using the ZK coprocessor is the best solution. Different methods have their own advantages and disadvantages for data fetching and computation, and a coprocessor suitable for specific functions is a good coprocessor. The future of the on-chain verifiable computation market is broad and will demonstrate new value in more areas.

In the future development of blockchain, there is potential to break through the traditional data barriers of Web2, where information is no longer isolated, achieving stronger interoperability. ZK coprocessors will become strong middleware, providing efficient and secure data fetching, computation, and verification for smart contracts, while ensuring security, privacy, and trustlessness. This will unlock more possibilities and become the infrastructure for true application landing and on-chain AI agents. Only what you can't think of, there is nothing you can't do.

Imagine a future scenario where using ZK for high-trust data validation and privacy, ride-hailing drivers can establish an aggregated network outside of their own platforms. This data network can cover platforms such as Uber, Lyft, DiDi, Bolt, and others. Ride-hailing drivers can provide their platform's data, and by piecing it together on the blockchain, an independent network separate from their own platforms can gradually be established. This aggregated network would encompass all driver data, becoming a large aggregator of ride-hailing data, while also allowing drivers to remain anonymous and not disclose their privacy.

Index

• What is a ZK Coprocessor?
• Crypto Mirror Article
• RISC Zero API
• Uniswap V4 Blog
• Brevis: A ZK Omnichain Data Attestation Platform
• Lagrange Protocol Overview
• Herodotus Documentation
• Pado Labs Documentation

Special thanks to Yiping Lu for the advice and guidance on this article.

About Foresight Ventures

Foresight Ventures is dedicated to the innovative journey of cryptocurrency for the next few decades. It manages multiple funds, including VC funds, secondary active management funds, multi-strategy FOF, and a special purpose S fund "Foresight Secondary Fund l", with total assets under management exceeding $400 million. Foresight Ventures adheres to the philosophy of "Unique, Independent, Aggressive, Long-term" and provides extensive support to projects through its strong ecosystem. Its team consists of senior professionals from top financial and technology companies, including Sequoia China, CICC, Google, and Bitmain.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。