Ethereum

Two big problems with ZK Coprocessors, that were probably also encountered in the early days of the first Coprocessors (hardware), are:

TLDR
- If everything is a Coprocessor, nothing is a Coprocessor.
- Modern computer system design kinda defaults to everything being a Coprocessor by integrating concepts like modularity and composability.
- Coprocessors that took off in web2 solved one problem. E.g. floating-point operations.

2. There are too many types of ZK Coprocessors trying to solve too many problems.
- This is not a bad thing, but it does cause confusion that can be a turn off not only for non-technical but also for technical audiences.
- Coprocessors that will be remembered as "the first" will likely solve a single problem. We saw this with hardware Coprocessors that specifically solved floating point operations (interestingly also a problem faced by EVM).
- It is possible that ZK is "the first" problem. Established and well-used L2s may be selling themselves short by diversifying into ZK. Sometimes less is more.
- Web2 companies that became and/or currently act as Coprocessor leaders released several Coprocessors, rather than upgrading their initial success.

1. Everyone thinks Coprocessors have to be ZK Coprocessors.
- There are no bounds on what a Coprocessor is other than it needs to be able to help another Processor complete a task.
- The first Coprocessors solved floating point operations. Several modern Coprocessors suck at floating point operations. GPUs are an example of a generalized and programmable Coprocessor.
- Polygon or pretty much any L2 is currently marketed as a "scaling solution" which is the definition of Coprocessor. Some of these solutions do see "ZK as the end game."