Content
@
0 reply
0 recast
0 reaction
Winston
@gumdropsteve
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.
1 reply
0 recast
0 reaction
Winston
@gumdropsteve
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."
1 reply
0 recast
0 reaction
Winston
@gumdropsteve
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.
0 reply
0 recast
0 reaction
