What is a ZK Coprocessor?

ZK coprocessors are a new class of blockchain infrastructure that allows smart contract developers to statelessly prove offchain computation over existing on-chain data.

One of the biggest bottlenecks for smart contract developers continues to be the prohibitive cost associated with onchain computing. Because every operation is metered for gas, the cost of complex application logic can quickly grow infeasible. ZK has emerged as the flagship solution to this problem by allowing developers to introduce more complex compute to dapps. Its first usage was in ZK rollups to support the same type of compute used on L1, but at greater scale and volume, and it is now being applied within a new class of ZK coprocessors. 

ZK coprocessors introduce a new design pattern for onchain applications that removes the constraint that computation must be done in a blockchain virtual machine. This enables applications that access more data and operate at a greater scale than was possible before.

Defining ZK Coprocessors

In its original context of hardware chip design, the term coprocessor refers to a separate chip designed to augment a CPU and provide specialized operations like floating point arithmetic, cryptographic operations, or graphics processing. Though the term has fallen out of favor as CPUs have become more powerful, one can still view GPUs as a type of coprocessor for CPUs, especially in the context of machine learning.

The term ZK coprocessor extends the analogy of a physical coprocessor chip to blockchain computers.  ZK coprocessors enhance Ethereum by allowing smart contracts to trustlessly delegate historic on-chain data access and compute over it using ZK proofs. Instead of performing all operations in the EVM, developers can move expensive ones to a ZK coprocessor and simply use the results onchain. This offers a new type of scaling for smart contracts by decoupling data access and compute from blockchain consensus. 

The defining characteristics of a ZK coprocessor are not requiring applications to move their state but instead interoperating with and enhancing the capabilities of existing applications on L1 or L2.

Design Considerations for ZK Coprocessors

Two key design considerations for a ZK coprocessor are how it handles data access and compute.  

Data Access

One of the most important aspects of performing a computation on a ZK coprocessor is ensuring that all input data was correctly accessed from the history of the blockchain.  Surprisingly, this is difficult because smart contracts can only access the current blockchain state in their code, and even that access is the most expensive part of onchain computation. This means historic on-chain data like transaction receipts or previous balances – the interesting on-chain inputs to computations – are not natively available to smart contracts to validate results from a coprocessor.

ZK coprocessors address this issue in three different ways, which trade-off cost, security, and development difficulty:

• Store additional data in the blockchain state and verify all data the coprocessor uses onchain using EVM storage reads.  This is quite expensive and becomes cost-prohibitive for large amounts of data.
• Trust an oracle or network of signers to verify input data to the coprocessor.  This reduces security by requiring coprocessor users to trust the oracle or multisig providers.
• Use ZK proofs to check that any on-chain data used in the coprocessor is committed to in the history of the blockchain.  This uses the fact that any block in a blockchain commits to all past blocks and thus any historic data, thus giving cryptographic  guarantees for data validity and requiring no additional trust assumptions from users.

Axiom uses the last approach to verify all input data to our ZK coprocessor with ZK proofs of Merkle-Patricia trie inclusion and block header hash chains.  Although this is more difficult to develop, we believe it offers the best level of security and cost to the end-user, since it ensures that all results returned by Axiom are cryptographically equivalent to computations performed on-chain within the EVM.

Compute

Performing off-chain compute in a ZK coprocessor requires translating a traditional computer program into a ZK circuit, a special form suitable for generating ZK proofs to verify the computation.  All methods to do this currently incur a substantial performance impact, with ZK proving having 10,000 to 1,000,000 overheads over native program execution. On the other hand, ZK circuits have a different computational model than standard computer architectures (for example, all variables must presently be encoded modulo a large cryptographic prime and execution can be non-deterministic), meaning writing them directly is difficult for developers. 

As a result, the three main approaches to specifying computation in ZK coprocessors mainly trade-off between performance, flexibility, and developer experience:

• Custom circuits: Developers write their own circuits for each application.  This offers the greatest performance potential but requires substantial developer effort.
• eDSL / DSL for circuits: Developers write circuits for each application, but in an opinionated framework abstracting away ZK-specific concerns (similar to using PyTorch for neural networks). This trades off performance for developer experience.
• zkVM:  Developers write circuits in a virtual machine with execution is verified in ZK. This offers the easiest developer experience when using an existing VM, but has substantial performance overhead because of the differing compute models between VMs and ZK.  

Axiom uses the second approach in our V2 with an eDSL allowing users to access on-chain data and specify their own computations over it.  We also allow users to write their own circuits with our library of optimized ZK primitives.

What's Next?

In the coming weeks, we will be sharing more information about Axiom V2, which will offer smart contract developers access to more on-chain data and more compute over that data. Follow us on Twitter for updates!

In the meantime, Axiom V1 is live on mainnet. You can start building immediately with our developer docs at docs.axiom.xyz, discuss in our developer chat on Telegram, or fill out our early partner form if you want to discuss an idea for a project to build on Axiom.