4 ms·

> All NP problems have transcripts that are validatable in polynomial time Sure, but are they provable in polynomial time? Proof generation is much more expen

> All NP problems have transcripts that are validatable in polynomial time Sure, but are they provable in polynomial time? Proof generation is much more expensive than just running through the original computation through standard means. > However with some cool zero-knowledge crypto magic, you don't even have to reveal the Merkle inclusion proof, nor even the key itself. I hate that the exact way that ZK systems work is always omitted from any discussion of the subject. It is very complicated, which explains why no one like to (or is even able to) get into the specifics, but somehow this also leads to handwavy assertion that all we need to do to avoid all that expensive and duplicative computation is to sprinkle in some zero-knowledge proofs. Due to performance limitations, for all intents and purposes ZK tech is impractical to the point of being infeasible for truly decentralized blockchains with turing-complete smart contract capabilities. It works for more specialized purposes, but it is not a currently solution to the "duplicative computation" problem.

adastra22 3y ago
> Sure, but are they provable in polynomial time? It doesn’t matter, does it? That computation happens off-chain. As an actual example, there are contracts locked to providing a collision proof for various hash functions. The one for SHA1 was claimed a few years ago when Google generated the first SHA-1 collision. That represented a lot of work on Google’s behalf, but was trivial for bitcoin nodes to validate. > Due to performance limitations, for all intents and purposes ZK tech is impractical to the point of being infeasible for truly decentralized blockchains with turing-complete smart contract capabilities. It works for more specialized purposes, but it is not a currently solution to the "duplicative computation" problem. You misunderstand me. I’m not suggesting that such a general zkp system be used, but rather offering it as a theoretical point. In practice you make a specialized zk proof for whatever you are trying to do. And despite the hype, the practical use cases for Turing complete smart contracts are quite small and limited in scope. If you have a smart contract with real world applicability that can’t be reduced down to a handful of easily checked signatures and if-else clauses (or something of similar complexity), I’d like to see it. I know of scant few examples, and this is my field of expertise.
- deleted 3y ago
  [deleted]

adastra22 3y ago

> Sure, but are they provable in polynomial time? It doesn’t matter, does it? That computation happens off-chain. As an actual example, there are contracts locked to providing a collision proof for various hash functions. The one for SHA1 was claimed a few years ago when Google generated the first SHA-1 collision. That represented a lot of work on Google’s behalf, but was trivial for bitcoin nodes to validate. > Due to performance limitations, for all intents and purposes ZK tech is impractical to the point of being infeasible for truly decentralized blockchains with turing-complete smart contract capabilities. It works for more specialized purposes, but it is not a currently solution to the "duplicative computation" problem. You misunderstand me. I’m not suggesting that such a general zkp system be used, but rather offering it as a theoretical point. In practice you make a specialized zk proof for whatever you are trying to do. And despite the hype, the practical use cases for Turing complete smart contracts are quite small and limited in scope. If you have a smart contract with real world applicability that can’t be reduced down to a handful of easily checked signatures and if-else clauses (or something of similar complexity), I’d like to see it. I know of scant few examples, and this is my field of expertise.

deleted 3y ago
[deleted]