Coprocessors Overview

Coprocessors Overview

Coprocessors Overview

Curve

Curve

Nov 29, 2024

Introduction

With the need for more advanced dApps that utilize a greater range of historic data and complex computations, Ethereum mainnet faces design challenges due to high associated costs and processing capabilities. To overcome this, an offchain infrastructure in the form of coprocessors is both cost efficient and trust minimized, enables applications to introduce more innovative functionalities.

In this article we take a look at different coprocessors and how applications have implemented them. We define their key features and highlight potential risks/downsides associated with each coprocessor. Finally, based on some relevant considerations, we present some offchain use cases that would be beneficial in yield vault’s architecture.

An Overview of Coprocessors

In computing, coprocessors are additional processing units that support the CPU by taking on specific computational tasks that would otherwise overload the CPU. A working analogy is the GPU, which handles tasks like 3D rendering. Given the gas costs necessary for onchain computations, more complex & unique computations are not economically feasible for applications to utilize. Additionally, while smart contracts can access the most recent block data, access to more extensive onchain data is limited.

Computational tasks are offloaded to coprocessors that would ordinarily be prohibitive under normal circumstances. Data access and custom computations are delegated offchain, with the results being used onchain. Thus, applications are enabled to implement more innovative and data-driven features that previously were not viable through purely onchain implementations.

EigenLayer Coprocessors

As ‘Computational Enhancers’, coprocessors leverage Eigenlayer's consensus mechanism to expand application computational capabilities and access to data. As we’ll show with each coprocessor, different costs, latency, and security implications are involved.

Brevis coChain AVS

Brevis coChain is an Omnichain ZK coprocessor that uses Zero Knowledge proofs to verify computation results utilizing historic data sourced from archive nodes. The coChain model uses a hybrid coprocessing system that combines ZK proofs to verify ‘optimistic’ result proposals.

Source: Brevis Docs

A ‘propose-challenge’ system is used to generate results. This entails a smart contract proposer making a coprocessing request and a subsequent result being generated by validators based on data from archive nodes. Results are optimistically submitted onchain as ‘proposals’ without the need for a complete ZK proof computation.

Submitted proposals are subject to being challenged by ZK proofs during a ‘Challenge Period’ where challengers attach a bond for each ZK proof. If a proposal is successfully challenged, corresponding validator stakes are slashed. If the challenger fails, their bond is forfeited.

Advantages

  • Cost efficient: ZK proof generation costs are incurred only in the event of a challenge (computational overheads with upfront ZK proofs at this current stage).

  • Expanded use cases: e.g. Non-existence proofs for new user acquisition, identity, account abstraction, and compliance.

Disadvantages

  • Trust assumptions: An element of trust is placed on archive nodes.

  • Cost - Latency Trade Off: The optimistic approach reduces costs for results (as a computations only need to done when challenged), but introduces latency with challenge periods (additional coChain slashing window)

Automata Multi-Prover AVS

Automata Multi-Prover AVS is a TEE coprocessor (Trusted Execution Environments) that delegates computations to third-party providers without compromising privacy or the integrity of operations.

Source: Automata Docs

TEE coprocessors perform secure computations within isolated enclaves. Enclaves are unique and secure memory zones enabled by hardware or cloud based vendors such as Intel, AMD and AWS. Protocols submit multi-proving tasks to Automata AVS, tasks are then delegated to registered operators who execute the task on their TEE Prover. Multiple sets of Provers called ‘TEE committees’ execute computations which are then verified and submitted onchain.

TEE committees are required to provide a bond, adding cryptoeconomic security against operators tampering within the multi-prover model e.g. ‘Swift lanes’ that allow for task results to be optimistically accepted with a bond that is forfeited if results are invalidated by subsequent proofs.

Advantages

  • Reduced Latency: Multi-Prover systems allow Provers to issue proofs for initial confirmation, followed by more secure, final confirmations from slower but secure Provers.

  • Redundancy: TEE Committees composed of heterogeneous vendors (such as Intel, AMD, AWS) raise the bar against malicious actors and increase security through redundancy (machinehood attestations).

Disadvantages

  • Swift Lane and Optimistic Attestation: Fast attestations are less rigorous. Initial confirmations may be invalid - claims are bonded.

Lagrange ZK Prover Network

The Lagrange ZK Prover Network performs verifiable offchain computations through zero-knowledge proofs. It indexes blockchain data and processes computations of SQL-based queries offchain. The network comprises Provers and Gateways: Provers execute tasks, while Gateways manage and distribute these tasks.

Source: Lagrange Blog

Advantage

  • ZK-friendly Verifiable Database: SQL-based queries, accessible between different blockchains.

  • Efficient proofs: The ZK Coprocessor can generate a proof of correct computation over arbitrary block ranges. Can also smartly identify and update proofs that have changed, instead of recomputing from scratch.

Disadvantages

  • Upfront Proofs: Operators are required to pledge a bond as security for completing proofs within a specific timeframe. This trades off a degree of latency for security. (relative to Automata and Brevis).

  • Prover Limits: A stake is provided by Provers for security and which determines the amount of orders they can take on. Scale of the network therefore is contingent on the amount of stake per Prover.

General Coprocessors

Described here are additional offchain computational services that rely on their own nodes sets and security.

Axiom

Axiom is a ZK coprocessor that uses onchain data to perform custom computations verified by ZK proofs. Developers using Axiom's ZK circuits define computational requests and the related onchain data queries they want to perform. Nodes access onchain data and perform the specified computation. Results are then sent onchain with a ZK validity proof. After verification, the final results are sent to the chosen smart contract.

Source: Axiom docs

Advantages

  • No crypto-economic and incentive assumptions are made with computations.

  • Block Queries: Trustless onchain data access.

Disadvantages

  • Results ordinarily take a few minutes before they can be used in an application.

  • Typescript SDK circuits trade off performance for a more accessible developer experience.

Risc Zero Bonsai

The RISC Zero zkVM allows developers to build ZK applications in languages like Rust and C++. Any program whose execution needs to be proven is compiled into RISC-V, and then the prover can prove the RISC-V execution of that code. Bonsai is a zero-knowledge proving network developed by Risc Zero that enables applications across multiple chains to use the general-purpose zkVM to generate ZK proofs.

Source: Risc Zero Docs

API requests are sent to a ‘request pool’ which are then split into multiple portions in order to enable time-efficient proving. Proof generations are distributed between a network of zkVM prover nodes for offchain computations. The ‘Rollup engine’ takes proofs generated by the prover network and rolls them up into a singular root proof. The engine then publishes root proofs onto other chains which subsequently verify the proof's validity.

Advantages

  • Interoperability: ZK proof computations can be done without having to build a circuit nor having to write in a custom language. Contract codes all compile down to RISC-V

  • Functionality: Access to RISC Zero zkVM libraries and crates, enabling more performant and complex smart contracts possibilities.

Disadvantages

  • Centralized Node Operators: Currently not open, potential availability bottleneck

  • Overhead cost: A RISC-V interpreter adds an additional layer to already high ZK overheads.

Marlin Oyster

Marlin is a verifiable compute network, while Oyster is the sub-network of Marlin that specializes in TEE coprocessors. The network facilitates the delegation of offchain tasks to a pool of nodes. Node operators are listed on the Oyster marketplace and users rent instances that meet their hardware requirements.Task coordination and output submissions are coordinated via relay contracts and gateway nodes.

Like Automata - a TEE coprocessor - enclaves ensure confidentiality and integrity of data during computations running on host machines. Computational proofs are verified using enclave attestations by the TEE hardware manufacturer. Operators are required to stake POND and/or MPond. Oyster enclaves also power Kalypso, Marlin Network’s ZK coprocessor marketplace.

Advantages

  • Node Performance: Slashing mechanism to incentivize reduced offline node enclaves.

  • Complex Computational Efficiency: Direct hardware based support.

Disadvantages

  • Hardware Dependence: data security and computational integrity is reliant on the infrastructure of hardware provider attestations.

  • Scalability: TEE scalability is limited by the hardware requirements.

Space and Time

Proof of SQL is a ZK coprocessor that allows users to use SQL queries to generate ZK proofs. Built on top of the Space and Time Network, queries and computations are enabled by the Validator Layer (data coordinator) and the Data Warehouse (database and computational nodes) to facilitate onchain and offchain data queries.

Source: Space and Time Docs - Proof of SQL

The Proof of SQL protocol submits queries from a client or smart contract (Verifier) to the database service that performs the computational work (Prover). The initial phase of this process involves data ingestion, where the Verifier checks the integrity of the data from a data source for any tampering. The data is then either stored or updated on the Prover database, in the query phase the Verifier submits a request to the Prover. A result is then computed and a proof is generated.

Advantages

  • Developer accessible SQL-based queries offer fast, optimized proving.

  • Verified index of onchain and offchain data.

Disadvantages

  • ZK proof generation cost: Medium to large analytics have a high estimated price differential.

Case Studies and Use Cases

To explore offchain designs, let's look at three applications that have integrated coprocessors or some kind of offchain infrastructure.

Fluid DEX

Fluid is a liquidity layer upon which other user facing protocols can build, such as money markets and DEXs. Liquidity from these protocols is consolidated under the liquidity layer and it manages access to this liquidity in the form of regulating rates and limits between protocols. The protocol aims to reduce capital friction and fragmentation associated with scaling in DeFi.

The DEX protocol enables the use of debt and collateral as liquidity for trading. Repurposed Smart Debt earns swap fees that reduces the debt (cost of capital reduction). Smart Collateral pools employ multipurpose collateral for re-lending and deployment on the DEX as liquidity to earn trading and lending fees.

Since liquidity is consolidated and utilized concurrently across different protocols, an added layer of complexity is introduced. In terms of risk, under adverse market conditions a liquidation mechanism makes appropriate ETH/USDC liquidations. An accurate pricing model therefore is important for the Fluid protocol.

An offchain infrastructure is used to calculate the exchange rates used across different markets. Offchain components source and verify external price data e.g. from Uniswap and Redstone Oracles, this enables more efficient and less costly access to real-time pricing. Additionally, it reduces the risk of manipulation.

The process for obtaining an aggregate oracle price:

  1. Fetch the UniV3 TWAP, the latest interval is used as the current price.

  2. Verify this price is within an acceptable DELTA from the Uniswap TWAP.

  3. Verify this price is within an acceptable DELTA from the Chainlink / Redstone Oracle (unless UniV3 only mode).

  4. If it passes all checks, return the price. Otherwise use fallbacks, usually to Chainlink. In extreme edge-cases, revert. For UniV3 with check mode, if fetching the check price fails, the UniV3 rate is used directly.

Sommelier Finance

Sommelier Finance is a Cosmos based PoS appchain that coordinates offchain updates to vaults implementing investment strategies (’Cellar’ contracts). Permissioned strategists perform offchain computations to manage positions, rebalance messages are then sent to a set of validators for consensus before a rebalance can be actioned onchain through a message bridging solution, either via a Gravity Bridge for Ethereum or a Axelar bridge for alt-EVMs.

Source: Sommelier docs

Strategists interact with Cellar contracts through a Steward API (for rebalances and other contract calls). Cellars utilize the same architecture as Veda’s BoringVault (developed by Se7enSeas Capital) for strategy deployment and updates. The contract’s Manager function regulates the strategies that BoringVaults can employ by storing all possible actions in a merkle tree.

Other protocols that utilize the BoringVault architecture include yield aggregator Nucleus. Sommelier’s use of messaging bridges effectively enable it to be a ‘coprocessing’ layer for the native strategies deployed across different chains.

Gearbox

Gearbox is a decentralized leveraging protocol that uses credit account abstraction. Asset lenders provide liquidity utilized by borrowers who look to increase their positions by borrowing liquidity from the protocol at multiples of their collateral. Leveraged positions are determined by a ‘Credit Account’ which is an isolated smart contract which contains both the user funds and the borrowed funds.

Source: Gearbox docs

What yield users receive is based on the output of leverage Farming Pools and duration of liquidity provision. The limitations of using Farming Pool logic for rewards included:

  1. Payouts only occurring in one reward asset

  2. An inefficient share based payout mechanism

  3. Incorrect balances being displayed on Etherscan

The implementation of Lagrange’s ZK coprocessor allows the payout mechanism to change to one that uses proofs, which allows for multiple reward asset payouts, more accurate and gas efficient share allocation computations. Additionally crosschain rewards are enabled, for example, users with L2 LP can claim with a proof on mainnet.

Use Cases

Based on the key considerations, a few coprocessor/offchain implementations are highlighted below. These suggestions relate to the case studies shown above along with other proposed ideas.

Strategist Layer

A Strategist layer that facilitates offchain computations to manage positions, as seen in the case of Sommelier Finance. Offchain computations that rebalance vault strategies could be coordinated by validators based on a set of parameters.

Exchange Rate Pricing

Similar to Fluid DEX’s, a coprocessor could aggregate oracle sources to determine the share exchange rate, moving calculations offchain to optimize cost and against manipulation (e.g. checking different TWAPs and a Chainlink oracle, comparing them against a current Uniswap price).

Parallel Processing

Performing computations of a potential swap with independent paths offchain, the most efficient route thereafter would be executed onchain. Additionally, proof verification costs could be amortized by batching multiple swaps together.

Dynamic Withdrawals Fees

A fluctuating withdrawal fee depending on network congestion or withdrawal volume using oracle data in offchain computations. Increasing fees during high network demand/long withdrawal queues and lower fees in the inverse scenarios. These adjustments would be done to optimize yield earnings for longer term investors, and improve withdrawal cost-effectiveness for all users.

Considerations

In defining possible offchain implementations, two relevant areas are outlined: strategy management and share accounting.

Strategy Management

Introducing an offchain component should improve the dynamism of vault strategy management. The main points to note include:

  • Strategies should make computations that determine optimal asset allocations and trade routes across restaking and DeFi.

  • Vault rebalances based on market volatility, liquidity states and yield opportunities. Actions should be affected within set parameters.

An optimal coprocessor should enable the automation of the related offchain computations and asset allocations. Latency is a constraint to consider given the need to adjust strategies simultaneously with market conditions.

Share Accounting

To determine vault shares, an exchange rate used to price shares for underlying assets and yield allocation should be cost efficient. An offchain calculation would also improve manipulation resistance versus using onchain data sources directly. Share accounting here is a catchall term relevant for deposits, share minting and balance adjustments.

Future Potential

By examining the long-term price and profitability potential of each coprocessing system - ZK proofs and cryptoeconomic models - some interesting implications arise for the coprocessor market. As noted in Brevis, ZK proof generation costs are currently suboptimal, introducing considerable computational overheads and are relatively more expensive than cryptoeconomic coprocessors. In the short term, this means that cryptoeconomic coprocessors have a pricing advantage over ZK coprocessors. However, as computational demand increases, more hardware capable validators will need to be onboarded which introduces scaling challenges and eventually an increase in computation costs. In the long run, ZK coprocessors have a potential advantage in this regard, as ZK performance becomes more optimized the price and profit margin differential seen in the short run erode with greater demand.

Source: rob-tech blog - Coprocessor Market Structure: Cryptoeconomic vs ZK

In essence, cryptoeconomic coprocessors theoretically will continue to have pricing advantages over ZK proofs so long as demand can be absorbed. But as the more price elastic of the 2 systems, additional demand beyond a certain level of absorption and the optimization of ZK proving, profit margins should even out until a reversal takes place in favor of ZK coprocessors.

Coprocessors offer a scalable and cost effective means of performing intensive computations. As we’ve shown, either through EigenLayer or General coprocessors, offchain solutions can be applied to fulfill a number of use cases. While adoption is still in its early stages, relevant considerations and constraints offer a way to think about how coprocessors could be implemented.

© 2023 Llama Risk. All rights reserved.