The reason why ZK tech development is taking longer than Optimistic is because the EVM is inherently not ZK friendly.

Its seems as if Optimistic tech has taken off and gotten implemented way faster than ZK tech. In fact, we’ve been talking about how excited we were about ZK tech for almost a year now. But there’s a valid reason behind this. The Ethereum Virtual Machine simply isn’t ZK friendly, which makes it hard for devs copy code at an efficient rate.

Now of course, there are different types of zkEVMs and each of them comes with a certain level of implementation difficulty.

The vast majority of scaling solutions right now implement zkEVMs that work at language-level

This makes proofer times way faster but this also means that devs have to work harder migrating contracts since the code has to be compiled down to bytecode that differs from the EVM. This requires a compilation step specific to the zkEVM network on which the contract is being deployed.

The real challenge however, is creating a zkEVM that’s at bytecode-compatible.

This means that proofer times are still incredibly fast but the developer doesn’t experience any changes to his/her experience other than where the contract is deployed. The same Solidity code, compiler, and bytecode are used. Developers are basically able use the same exact programming languages/tools as they would usually, while also taking advantage of the scalability and the security of zero-knowledge tech.

Although very challenging to accomplish, both Polygon and Scroll were able to create such zkEVMs. So some major development is indeed being witnessed, albeit, slower than the developments we’ve witnessed with Optimistic tech. However what Polygon and Scroll are currently doing is very much worth the wait because it will indeed change Ethereum in a much more positive way.