The inevitable adoption of coprocessors, driven by Uniswap v4

by Hill Tan , SevenX Ventures Research

Uniswap v4 is just announced. Although it’s not fully built out yet, we expect the community to widely explore the boundary of newly enabled possibilities. Since there might be a ton of articles explaining how powerful v4 is on the defi side of things, I would like to address how Uniswap v4 can inspire a new category of blockchain infrastructure: coprocessors.

Short intro on Uniswap v4

As described in the whitepaper , v4 contains mainly 4 improvements:

• Hooks: Hooks are externally deployed contracts that execute some developer-defined logic at a specified point in a pool’s execution. These hooks allow integrators to create a concentrated liquidity pool with flexible and customizable execution.

• Singleton: UNISWAP v4 uses a singleton design pattern where all pools are managed by a single contract, making pool deployment 99% cheaper.

• Flash Accounting: each operation updates an internal net balance, known as a delta, only making external transfers at the end of the lock. Flash accounting simplifies complex pool operations, such as atomic swapping and adding.

• Native ETH: allows for both WETH and ETH pairs.

Most gas savings will certainly come out of the last 3 improvements, but certainly, the most exciting new feature brought in is by the first mentioned new shiny bits: the hooks.

Hooks make liquidity pools more complicated and powerful

Uniswap v4’s primary enhancement revolves around the programmability unlocked by hooks. This feature introduces a new level of complexity and power to liquidity pools, allowing them to be more flexible and customizable than ever before. In comparison to v3’s concentrated liquidity, which was a net upgrade from v2, v4’s hooks provide a wider spectrum of possibilities for how liquidity pools can behave.

This can be viewed as a net upgrade from v3, but it might not be when it comes to actual implementation. Uniswap v3 pools will always be an upgrade compared to v2 pools, since the “worst” upgrade you can do in v3 is to “concentrate” the liquidity across the entire price range, which works the same as in v2. In v4, however, liquidity pools can be programmed to an extent that might not result in a good trading or liquidity-providing experience. Bugs can occur and there will be new attack vectors. Due to the wider array of changes to the liquidity pool’s behavior, developers wishing to utilize the hook feature must exercise caution. They need to thoroughly understand the implications of their design choices on the pool’s functionality and the potential risks for liquidity providers.

The introduction of hooks in Uniswap v4 represents a significant shift in how code is executed on the blockchain. Traditionally, blockchain code is executed in a predetermined sequential manner. However, hooks allow for a more flexible execution order, ensuring that certain code is executed before other code. This feature pushes complex computations towards the edge of the stack, rather than solving them in a monolithic stack.

In essence, hooks enable more complicated computations to be performed outside of the Uniswap native contract. While this was achievable in v2 and v3 through manual computation outside of Uniswap and triggering with external activators such as other smart contracts, v4 integrates hooks directly into the liquidity pool’s smart contract. This integration makes the process more transparent, verifiable, and trustless compared to the previously manual process.

Another side benefit hooks bring is extensibility. Uniswap now no longer have to rely on new smart contract (which requires liquidity migration) or forks to deploy innovations. Hooks can now make an old liquidity pool feels like a new one by directly implementing new features.

What happens to v4 liquidity pools will happen to other Dapps

I expect more and more dapps to push computation outside of their own smart contracts, just like Uniswap v4.

What v4 is doing here is by allowing the liquidity pool executions to be broken up at any step, arbitrary conditions can be inserted, and triggering computation that’s outside of the v4 contract. The only similar thing we have seen so far is flash loan, where the executions will be reverted if the loan is not given back within the same block. Just that the computation still happens in the flash loan contract.

Uniswap v4’s design brings multiple benefits that either weren’t possible or were suboptimal to implement in v3. For instance, the use of embedded oracles is now possible, reducing the reliance on external oracles that often introduce potential attack vectors. This embedded design enhances the security and reliability of price information, a critical factor in the operation of DeFi protocols.

Furthermore, automation, which previously had to be triggered externally, can now be embedded directly into the liquidity pool. This integration not only mitigates security concerns but also addresses reliability issues associated with external triggers. It provides a more seamless and efficient operation of the liquidity pool, enhancing its overall performance and user experience.

Finally, the introduction of hooks in Uniswap v4 opens up the possibility for more diverse security features to be implemented directly into the liquidity pool. In the past, the primary security measures available to liquidity pools were audits, bug bounties, and insurance purchases. With v4, developers can now design and implement a variety of fail-safes and low liquidity warnings directly into the pool’s smart contract. This development not only enhances the security of the pool but also provides greater transparency and control to liquidity providers.

Compared to traditional phones, smartphones win on programmability. Smart contracts have kind of lived under the shadow of “persistent scripts” for a long time. Now, thanks to the advant of v4, liquidity pool smart contracts get a new programmable upgrade, getting “smarter”. I can’t imagine why not all dapps want to upgrade in this direction given the opportunity to upgrade yourself from a Nokia into an iPhone. Since Nokia is more reliable than iPhone I can see plenty of reasons why some smart contracts would like to stay the way it is, but you get my point on where the future of Dapps is heading to.

Dapps wish to use their own “hooks” has a scaling problem

Imagine applying this to all the other dapps, where we can insert conditions to be triggered, and then insert arbitrary computations in between the original sequence of transactions.

This sounds like how MEV works, but MEV is not an open design space for the dapp developers. It’s more like an uncertain hike into a dark forest, the best they can do is to seek external MEV protection but can only hope for the best.

Assume that the flexibility of Uniswap v4 inspires a new generation of dapps (or upgrade from existing dapp) to adopt similar philosophy, where they allow their own execution sequence to be more programmable. Since these dapps are usually only deployed on one chain (an L1 or an L2), we expect most state changes to be run on this chain.

• The additional computation inserted within the state-changing process of a dapp might be too complicated and burdensome to run on this chain. We might go beyond the gas limit really quickly, or it’s just outright difficult to realize. It also introduces a host of challenges, particularly in the areas of security and composability.

• Not all computations are equal. As evidenced by dapps’ reliance on external protocols such as oracles and automation networks. However, this reliance introduces security risks, as highlighted in a recent tweet by Dan Elitzer in.

Summarizing the problem: incorporating all computations into state-altering smart contract execution on one single chain is far from optimal.

Hint on the solution: it’s been solved in the real world

To solve this problem brought by the new generation of dapps (which might be largely inspired by Uniswap v4), we have to look into the core of the problem: that 1 single chain. Blockchain works as distributed computer, with one single CPU processing everything. On a PC, modern CPU has come a long way to solve that exact problem.

Just as computers have transitioned from single-core monolithic CPUs to a modular design comprising multiple efficiency cores, performance cores, GPUs, and NPUs.

DApp computation can scale in a similar manner. By specializing processors and combining their efforts, outsourcing some computation outside of the main processor offers flexibility, optimality, security, scalability, and upgradability.

Actual solution

There are really only two categories of coprocessors:

• External coprocessors

• Embedded coprocessors

External coprocessors

External coprocessors are like a GPU on the cloud. It’s nice and powerful, but you have additional internet lag between the CPU and the GPU communication. Plus you are not ultimately controlling the GPU, so you have to trust that it’s doing the job right.

Using Uniswap v4 as an example, let’s say some ETH and USDC were to be added to a liquidity pool at the last 5 mins TWAP. If the TWAP calculation is done in Axiom, v4 is essentially using Ethereum as the main processor and Axiom as the coprocessor.

Axiom

Axiom is a ZK coprocessor for Ethereum which provides smart contracts trustless access to all on-chain data and arbitrary expressive computing over it.

Developers can make queries into Axiom and trustlessly use the ZK-verified results on-chain in their smart contracts. To fulfill queries, Axiom performs three steps:

1. Read: Axiom uses ZK proofs to trustlessly correct reads from block headers, states, transactions, and receipts in any historical Ethereum block. All Ethereum on-chain data is encoded in one of these forms, meaning that Axiom can access anything an archive node can.

2. Compute: Once data has been ingested, Axiom applies verified compute primitives on top. This includes diverse operations from basic analytics (sum, count, max, min) to cryptography (signature verification, key aggregation) and machine learning (decision trees, linear regression, neural network inference). The validity of each piece of computing is verified in a ZK proof.

3. Verify: Axiom accompanies the result of each query with a ZK validity proof that (1) the input data was correctly fetched from the chain and (2) the compute was correctly applied. This ZK proof is verified on-chain in the Axiom smart contract, and the final result is then trustlessly available for use by any downstream smart contract.

Warp Contract (by RedStone)

Warp Contracts is the most popular implementation of SmartWeave, which is an architecture aimed at creating a reliable, fast, and production-ready smart contracts platform/engine on Arweave. Essentially, SmartWeave is a sequenced array of Arweave transactions that benefit from the absence of a fee market for transaction block inclusion on Arweave. These unique properties allow for unlimited transaction data without additional fees beyond storage costs.

SmartWeave utilizes a unique approach known as “lazy evaluation,” which transfers the responsibility of executing smart contract code from network nodes to the users of the smart contract. In essence, this means that the computation of transaction validation is deferred until it is required, reducing the workload on network nodes and allowing for more efficient processing of transactions. This approach enables users to execute as much computation as needed without incurring additional fees, offering functionalities that are not feasible with other smart contract systems. Obviously attempting to evaluate contracts with thousands of interactions on a user’s CPU would be a futile exercise. To overcome this challenge, an abstraction layer, such as Warp’s DRE, has been developed. It comprises a network of distributed validators that handle contract computations, leading to significant improvements in response time and user experience.

Furthermore, the open-ended design of SmartWeave enables developers to write the logic in any programming language, offering a refreshing alternative to the often rigid Solidity codebase. By delegating certain high-cost or high-throughput actions to Warp, existing social graph protocols built on EVM chains can be enhanced with seamless SmartWeave integration, leveraging the strengths of both technologies.

Hyper Oracle

Hyper Oracle is a network of zkOracles designed for blockchains. At present, the zkOracle network 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.

Developers can define custom off-chain computations with JavaScript, deploy those computations to Hyper Oracle network, and utilize Hyper Oracle Meta Apps to index and automate their smart contracts.

Hyper Oracle’s indexing and automation Meta Apps are fully customizable and flexible. Any computation can be defined and all computations will be secured by a generated zk proof, even machine learning computation.

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

• The Hyper Oracle 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 or any other computation 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.

• The output of a zkOracle is off-chain data that developers can use through Hyper Oracle Meta Apps (which are covered in the next sections). The data also comes with zk proofs that demonstrate the validity and computation of the data.

Other projects worth mentioning

There are also a few projects that can be used as an external coprocessor if you decided to use them in that way. It’s just that they have overlapping positioning in other verticals of the blockchain infra space that they don’t uniquely classify as a coprocessor.

• RiscZero : if a dapp use RiscZero to compute ML tasks of an onchain agent and feeds the result back to it’s game contract on StarkNet, it’s using the StarkNet as main processor and RiscZero as the coprocessor.

• Ironmill : if a dapp runs their zk circuit in Ironmill but have smart contracts deployed on Ethereum, it’s using Ethereum as the main processor and Ironmill as the coprocessor.

Potential use cases for external coprocessors

• Governance and Voting: Historical on-chain data can help DAOs record how much voting power each member holds, which is necessary for voting. Without this data, members may not be able to participate in the voting process, which could hinder governance.

• Underwriting: Historical on-chain data can assist asset managers in assessing the performance of their managers beyond profits. They can see the level of risk taken and the types of drawdowns experienced, which can help them make better decisions when it comes to compensation or potential reward reductions.

• Decentralized Exchanges: Historical price data on-chain can assist decentralized exchanges in trading based on past trends and patterns, potentially leading to higher profits for users. Additionally, access to historical trading data can help exchanges improve their algorithms and user experience.

• Insurance Products: Historical on-chain data can be used by insurance providers to assess risks and set premiums for different types of policies. For example, when setting premiums for a defi project, an insurance provider may look at past onchain data.

Note that all of the above is async use cases because the customer dapp needs to call external coprocessors’ smart contract when triggered in block N. When coprocessors return the computation result, the result has to be accepted or verified in some shapes or forms in at least the very next block, which is N+1. This makes the utilization of co-processing results happen at least on the next block of triggering. It’s really like a cloud-based GPU. It runs your ML model well, but you can’t really play fast-paced games on it very well due to the lag.

Embedded coprocessors

Embedded coprocessors is like a GPU on your PC’s motherboard, sitting right beside the CPU. It has very little lag communicating with the CPU. Also it’s right below your palm so you can be pretty certain it’s not tampered with. Just that it will get very expensive if you wish it can run ML as fast as a cloud GPU.

Still using Uniswap v4 as an example, assume that some ETH and USDC were to be added to a liquidity pool deployed on Artela at the last 5 mins TWAP. If the pool is deployed in the EVM on Artela, and the TWAP calculation is done in the WASM on Aretla, this pool is essentially using Artela’s EVM as the main processor and Artela’s WASM as the coprocessor.

Artela

Artela is an L1 built with Tendermint BFT. It provides a framework that supports the dynamic extensions for any execution layer to achieve on-chain customized functionalities. Every Artela full node runs two VMs at the same time.

• EVM, which is the main processor storing and updating smart contract states.

• WASM, which is the coprocessor storing and updating Aspect states.

Aspects represent arbitrary computation that a developer wishes to run without touching the state of the smart contracts. Think of it as a Rust script that provides dApps with customized functionality beyond native composability of smart contracts.

If this is a bit hard to comprehend, try from the two following perspectives.

• From the perspective of blockchain architecture

  • Aspect serves as a new execution layer.

  • In Artela, the blockchain operates two execution layers simultaneously—one for smart contracts and one for other computations.

  • This new execution layer does not introduce new trust assumptions, thus not affecting the security of the blockchain itself. Both VMs are secured by the same set of nodes running the same consensus.

• From the perspective of application runtime

  • Aspects act as programmable modules that work in synergy with smart contracts, enabling the addition of customized functionality and independent execution.

  • It offers advantages over sole smart contract in several ways:

    1. Non-invasiveness: It can intervene before and after contract execution without modifying the smart contract code.

    2. Synchronous execution: It enables hook logic throughout the entire transaction lifecycle, allowing for fine-grained customization.

    3. Direct access to the global state and base layer configuration, allowing for system-level functionality.

    4. Elastic block space: providing independent block space with protocol guarantees for dApps with high transaction throughput requirements.

    5. Compared to static precompiles, it enables dApps to achieve dynamic and modular upgrades at runtime, balancing stability and flexibility.

The really exciting breakthrough Artela makes by introducing this embedded coprocessor is that now, Aspects, the arbitrary extension module, can be executed THROUGHOUT THE SAME TRANSACTION as smart contracts. Developers can bind their smart contract to Aspects and have all transactions calling the smart contract processed by Aspects.

Also, like smart contracts, Aspects store data on-chain, which enables smart contracts and Aspects to read the global state of each other.

These two features unlock a new level of composability and interoperability between smart contracts and Aspects

Aspect Functionality:

Compared to smart contracts, Aspects provide capabilities primarily focused on pre and post-transaction execution. Aspects do not replace smart contracts but rather complement them. In comparison to smart contracts, aspects offer the following distinct capabilities for applications:

• Automatic insertion of reliable transactions into upended blocks (e.g., for scheduled tasks).

• Reversion of state data changes caused by transactions (only authorized contract transactions can be Reversion).

• Reading of static environmental variables.

• Passing temporary execution states downstream to other aspects.

• Reading of temporary execution states passed from upstream aspects.

• Dynamic and modular upgradability.

Differences between Aspects and Smart Contracts:

What sets Aspects apart from smart contracts is:

• Smart contracts are accounts with code, while Aspects are native extensions of the blockchain.

• Aspects can run at different points in the transaction and block lifecycle, while smart contracts are only executed at fixed points.

• Smart contracts have access to their own state and limited context of the block, whereas Aspects are allowed to interact with the global processing context and system-level API.

• The execution environment of Aspects is designed for near-native speeds.

Aspects are simply pieces of code logic and are not associated with an account. Therefore, they do not have the ability to:

• Write, modify, or delete contract state data.

• Create new contracts.

• Transfer, destroy, or hold native tokens.

These aspects make Artela a unique platform that extends the capabilities of smart contracts and offers a more comprehensive and customizable development environment.

*Note that the Aspects we mentioned above is strictly called “built-in” Aspects, which is embedded coprocessors run by the full nodes of the Artela Chain. Dapps can also deploy their own Heterogeneous Aspect, which is run by external coprocessors. These external coprocessors can be executed on external networks, or by a subset of nodes in another consensus. It’s more flexible as the dapp developer can literally do anything they want with it as long as they feel safe and reasonably doing so. It’s still under exploration, and specific details are yet to be announced.

Potential use cases for embedded coprocessors

1. Complex calculations involved in new DeFi projects (such as intricate game-theoretical mechanisms) may require more flexible and iterative on-the-fly computational capabilities from an embedded coprocessor.

2. More flexible access control mechanisms for all kinds of dapps. Currently, access control is typically limited to blacklisting or whitelisting based on smart contract permissions. Embedded coprocessors can unlock instant and granular levels of access control.

3. Certain complex features in Fully On-Chain Games (FOCG). FOCGs have been constrained by the EVM for a long time. It might be easier if the EVM is reserved for simpler functionalities like transferring NFTs and tokens, while other logic and state updates are computed by coprocessors.

4. Security mechanisms. Dapps can introduce their own proactive security monitoring and fail-safe mechanisms. For example, liquidity pools can prevent from more than 5% of withdrawing every 10 mins. If one of the withdrawals is detected by a coprocessor, the smart contract can halt and trigger some alarm mechanisms, such as injecting emergency liquidity at a certain dynamic price range.

Closing thoughts:

Dapps getting big, bloaty, and uncomfortably complicated is inevitable. Therefore the adoption of coprocessors is also inevitable. It’s only a matter of time and adoption curve.

Running external coprocessors allows dapps to stay in their comfort zone: whatever chain they previously lives on. However, for the new dapp developers out there looking for an execution environment to deploy to, embedded coprocessors is like a GPU for a PC. If it calls itself a high-performance PC, it has to have a decent GPU.

Unfortunately, none of the above-mentioned projects are on mainnet yet. We can’t really benchmark and show which one is better for which use case. However, one thing is certain. Technology progresses in an upward spiral. It looks like we are going around in circles, but remember when seen from aside, history shows that it’s up only.

Long live the scalability trilemma, long live coprocessors.

Reference

https://www.axiom.xyz/blog/intro
https://docs.artela.network/main
https://docs.axiom.xyz/using-axiom/what-does-axiom-do
https://docs.hyperoracle.io/how-hyper-oracle-works
https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf
https://medium.com/logos-network/everything-you-know-about-the-scalability-trilemma-is-probably-wrong-bc4f4b7a7ef
https://medium.com/@warp_contracts/smartweave-vs-evm-403487e88fc6
https://mirror.xyz/hyperoracleblog.eth/qbefsToFgFxBZBocwlkX-HXbpeUzZiv2UB5CmxcaFTM
https://twitter.com/delitzer/status/1661755779240841222?s=20