Written on the train from Venice to Rome, 2023.01.12.
The real "finality" of the two is different, similarly to the "real performance". (Of course the definition of finality is also a matter of opinion, a matter of wisdom....)
OP systems (mostly) have a (human-adjustable) challenge period of about 7 days (aka. delay?) . This is like the long delay in Nakamoto consensus (which actually has no finality).
ZK system is fully confirmed once the proof is generated and verified. Also, with hardware acceleration, the proof generation speed and overhead can be infinitely close to zero (theoretically). It can be compared to the Tendermint consensus Single-slot Finality.
Of course, after all this about finality, you can actually see by comparing it with the consensus mechanism that this finality does not represent what is commonly referred to as "performance". Although Tendermint has Single-slot finality, it is not necessarily faster than Nakamoto. For the real performance measurement, we can write a seperate article (scalability, throughput, real tps, performance)...
Other than that, there is a difference in verification.
OP systems are more like verify after post. First post compute, then verify, so the latency is high.
The ZK system is more like verify before post. Although the proof needs to be verified after it is generated, the process of generating the proof actually puts a proof of validity on the computation process and the result before being posted.
If you want to compare it to a Math exam, OP is like a teacher following and redoing each step of your proof, while ZK is like a teacher looking directly at the scoring points in your proof after having all those scoring metrics.
The two trust bases are slightly different, resulting in different security of the system.
OP seems to be based on an economic mechanism, similar to following the "innocent until proven guilty".
ZK seems to be based on a purely mathematical mechanism, like following the "presumption of guilt".
In contrast, the purely cryptographic assumptions of ZK are definitely more rigid.
However, these are theoretical security. Mechanically secure ! = implementation-secure, mechanism-insecure ! = implementation insecure. In practice, as software, they all have bugs, and therefore they all have risks. Code security requires additional mechanisms to ensure it (picus, ecne...) .
Depending on the security assumptions, ZK can be considered as a more secure system than smart contracts (based on networks, which are actually based on consensus and mathematics), and can be used as an extension of smart contract functionality (zkExtension). For example, Scroll makes smart contracts more scalable in terms of scalability, Hyper Oracle makes smart contracts more capable in terms of indexing and automation...
So, to take it a step further, if you've ever pushed EIP, then you know that setting up a standard alone is a very long and complex (and random) process, and it's even harder to develop the development ecosystem around it. It is even more difficult to update the network level (EIP-1559, merge...). Therefore, the ZK system can be used as an extension for experimental innovations (the main reason is that ZK is secure enough and pluggable) without breaking Layer1's own features and mechanisms.
Another point that no one has mentioned, but which I think is worth mentioning, is the complexity of the system.
ZK can outsource a large amount of computation to a single node for proof generation, making it very efficient in a distributed consensus system like a blockchain network.
This also has the advantage that the overall architecture is very simple (who generates the proof, who sequences it, and who verifies it).
The complexity of the ZK system is shifted from the surface and macro level, to the micro and code level.
If you want to compare, the OP and ZK systems look like this:
OP's mechanism is particularly complex and different at the same time, and the token economy involves a myriad of curves and troublesome settlement mechanisms. In short, it is beyond the reach of normal people, and probably only we researchers and the project itself understand what is going on.
ZK's mechanism is extremely Succinct (good word!) . Prover, User, Verifier, can be fully expressed in one sentence/diagram. There may be subtle differences between each system, but the real differences and hard work are transferred to the system developers and architects.
I think this is the biggest advantage of ZK. The nature of software is to be easy to use for the masses (and for developers to lose their hair), especially in an already complex Web3/Crypto system.
Conclusion: Both, depending on the scenario.
I read an opinion the other day, written by Haseeb. Web3 is the left wing of freedom and openness, Crypto is the right wing of sovereign individuals. It is perfectly applicable to our topic.
OP gives more resemblance to the existing system of Web3. Systems like banks have been using OP-like mechanisms for a long time (credit cards), and for compliance etc., I think they will still use OP. Specific applications might be various Web2.5 "DeFi", cross-chains (like interbank transfers, but of course ZK does a good job too).
ZK gives a more pure and Crypto-Native Crypto. Because of the cryptography gene, ZK is very suitable for power applications such as Privacy Coin/True DeFi.
In my case, I'd go with Crypto's ZK.