Topic: ZK-proof on Bitcoin - page 2. (Read 543 times)
If I have to trust a chain-state built from an alternative proof system that is practically like not running a full node whatsoever. I am just trusting that someone whether that be your organization or whoever else ran the prover built the proof correctly. If they did not they can easily spoof the important parts of transaction data and relay something that the end user is completely unaware of. The matter of it being part of an alternative proof system does not strengthen any of the underlying assumptions it does not even preserve them.
requires that I trust a consortium of keys that have approved ZKPs of chain state.
That is a fundamental misunderstanding. STARKs are transparent which means there is no trusted setup. What you mean is SNARKs and not wanting to trust a 'consortium' is exactly why STARKs were invented.
Hi, I am the project lead at ZeroSync. Happy to see our work discussed on bitcointalk. Would like to clarify a few points mentioned here:
- We are using STARKs, which is a form of zero-knowledge proof that requires no trusted setup. It is a *transparent* ZKP.
- "Zero-knowledge" is indeed misleading in a way. This technology was invented for privacy reasons but it turned out to be also very useful to compress a computation. To be precise, actually it doesn't even use the zero-knowledge property really. Nevertheless it became an industry standard to call this tech ZKPs. We use it just because it is a *succinct* proof.
- Using ZeroSync requires no global consensus. Every user can decide individually if they want to sync using a proof or the conventional way. You can even zerosync Bitcoin Core without any code modifications: Use an external tool to verify a UTXO set and then copy it into your chainstate folder.
- ZeroSync is not a company but a Swiss nonprofit creating FOSS software.
- ZeroSync is not just a chain proof but creates a toolkit for Bitcoin developers to apply ZKPs to their own products and services.
On our project website https://zerosync.org you can find more details.
Happy to answer any questions you have.
- We are using STARKs, which is a form of zero-knowledge proof that requires no trusted setup. It is a *transparent* ZKP.
- "Zero-knowledge" is indeed misleading in a way. This technology was invented for privacy reasons but it turned out to be also very useful to compress a computation. To be precise, actually it doesn't even use the zero-knowledge property really. Nevertheless it became an industry standard to call this tech ZKPs. We use it just because it is a *succinct* proof.
- Using ZeroSync requires no global consensus. Every user can decide individually if they want to sync using a proof or the conventional way. You can even zerosync Bitcoin Core without any code modifications: Use an external tool to verify a UTXO set and then copy it into your chainstate folder.
- ZeroSync is not a company but a Swiss nonprofit creating FOSS software.
- ZeroSync is not just a chain proof but creates a toolkit for Bitcoin developers to apply ZKPs to their own products and services.
On our project website https://zerosync.org you can find more details.
Happy to answer any questions you have.
A ZKP that represents chain state effectively shunts the usefulness of a full node entirely. Why not just concatenate the entire chain into a merkle proof? They are small, succinct, speedy to verify, and are completely transparent. ZKSTARK for verifying a block requires that I trust a consortium of keys that have approved ZKPs of chain state. This goes against not just Bitcoin fundamentals but basic cryptographic assumptions.
Just to have an high level idea in a quick/lazy way ;-) , any diagram/note/schema about who plays the role of public STATEMENT & private WITNESS (in the SNARK meaning of those keywords) in each of the 3 stages of your chainproof (header/assumedvalid/full)?
The statement is the bitcoin consensus rules, basically expressing "I know a chain of blocks that is valid and results in chain state X". The (private) witness is the chain of blocks.
The chain state contains data like the block height, the total work, etc, but also a UTXO set commitment. To get a feeling for it, see our demo https://zerosync.org/headers-chain.html
Hi, I am the project lead at ZeroSync. Happy to see our work discussed on bitcointalk. Would like to clarify a few points mentioned here:
thanks your notes
Just to have an high level idea in a quick/lazy way ;-) , any diagram/note/schema about who plays the role of public STATEMENT & private WITNESS (in the SNARK meaning of those keywords) in each of the 3 stages of your chainproof (header/assumedvalid/full)?
Hi, I am the project lead at ZeroSync. Happy to see our work discussed on bitcointalk. Would like to clarify a few points mentioned here:
- We are using STARKs, which is a form of zero-knowledge proof that requires no trusted setup. It is a *transparent* ZKP.
- "Zero-knowledge" is indeed misleading in a way. This technology was invented for privacy reasons but it turned out to be also very useful to compress a computation. To be precise, actually it doesn't even use the zero-knowledge property really. Nevertheless it became an industry standard to call this tech ZKPs. We use it just because it is a *succinct* proof.
- Using ZeroSync requires no global consensus. Every user can decide individually if they want to sync using a proof or the conventional way. You can even zerosync Bitcoin Core without any code modifications: Use an external tool to verify a UTXO set and then copy it into your chainstate folder.
- ZeroSync is not a company but a Swiss nonprofit creating FOSS software.
- ZeroSync is not just a chain proof but creates a toolkit for Bitcoin developers to apply ZKPs to their own products and services.
On our project website https://zerosync.org you can find more details.
Happy to answer any questions you have.
- We are using STARKs, which is a form of zero-knowledge proof that requires no trusted setup. It is a *transparent* ZKP.
- "Zero-knowledge" is indeed misleading in a way. This technology was invented for privacy reasons but it turned out to be also very useful to compress a computation. To be precise, actually it doesn't even use the zero-knowledge property really. Nevertheless it became an industry standard to call this tech ZKPs. We use it just because it is a *succinct* proof.
- Using ZeroSync requires no global consensus. Every user can decide individually if they want to sync using a proof or the conventional way. You can even zerosync Bitcoin Core without any code modifications: Use an external tool to verify a UTXO set and then copy it into your chainstate folder.
- ZeroSync is not a company but a Swiss nonprofit creating FOSS software.
- ZeroSync is not just a chain proof but creates a toolkit for Bitcoin developers to apply ZKPs to their own products and services.
On our project website https://zerosync.org you can find more details.
Happy to answer any questions you have.
non ZK proofs can just be merkle proofs, they are extremely small and easy to verify. Such there is no reason to use zk proofs where the zero knowledge factor is not being leveraged, this is a waste of ones time.
ll Knowledge" system would be more suitable for public blockchain verification, there is no sense in wrapping stuff in ZK for the hell of it.
[...]
These things are not going to be any better than SPV at network security, might they offer a trusted solution that is scalable? Hopefully. But other than that no one will replace a full node with zero knowledge unless they dont care about what code they are running and in that case why even run a node?
[...]
These things are not going to be any better than SPV at network security, might they offer a trusted solution that is scalable? Hopefully. But other than that no one will replace a full node with zero knowledge unless they dont care about what code they are running and in that case why even run a node?
I'm not ZeroSync evangelist nor I have any interest with them.
That said, I think you are thinking to zkSNARKs, but SNARKs can be also non-ZK. Their use is justified by being "Succinct", short proof (and quickly verifiable). Also ZK-Rollups, despite the name, are not zero knowledge, they use SNARKs because of succinctness.
So, I don't know if ZeroSync idea is good for blockchain size reduction (because any serious evaluation of schemes of that complexity should require a careful study of the proposed solution) , or if it will be accepted (I don't think so to be honest), but the usage of SNARKs to have succinct and fast checkable proof is brand new but well established.. confusing it with ZK flavours is not a good service to the OP imho
I am not sure how the Bitcoin community and pro full-node proponents will accept the idea of not being the ones that perform the full verification process themselves. If the idea has always been to verify and not trust, I don't see that changing. I guess it's also going to depend on how ZeroSync exactly verifies those transactions. An increase in centralization will surely not be something hardcore-bitcoiners will approve of.
Yea UNFORTUNATELY the implementations of these "Zero Knowledge" proofs on EVM chains mainly seems to completely throw away the purpose of using ZK systems in the first place which is privacy and they instead institute some sort of consortium of trusted keys to validate AND verify these proofs and use them for scaling( even though they are much larger than the underlying data inherently)? Seems dumb to me.
ZK proofs for privacy purposes on the other hand is a wonderful application, ZKSTARK implementation seems very promising in a quantum resistance sense and also is acceptably scalable.
But using these things to verify something that is not going to be private ever? That makes no sense, why even use zero knowledge for that application.
There needs to be a legitimate use case for the proofs and one that is reasonably weighted for the Bitcoin network so that it can scale properly.
I am positive a "Full Knowledge" system would be more suitable for public blockchain verification, there is no sense in wrapping stuff in ZK for the hell of it.
These things are not going to be any better than SPV at network security, might they offer a trusted solution that is scalable? Hopefully. But other than that no one will replace a full node with zero knowledge unless they dont care about what code they are running and in that case why even run a node?
I am not sure how the Bitcoin community and pro full-node proponents will accept the idea of not being the ones that perform the full verification process themselves. If the idea has always been to verify and not trust, I don't see that changing. I guess it's also going to depend on how ZeroSync exactly verifies those transactions. An increase in centralization will surely not be something hardcore-bitcoiners will approve of.
I don't know ZeroSync actual tech, but from what I read my educated guess is they are going to use recursive or folded SNARKs, in the path of an "old" idea called UTREEXO... so not possible to judge just from that simple article, but tech to do something good exist... and StarkWare funding seems reassuring
I am not sure how the Bitcoin community and pro full-node proponents will accept the idea of not being the ones that perform the full verification process themselves. If the idea has always been to verify and not trust, I don't see that changing. I guess it's also going to depend on how ZeroSync exactly verifies those transactions. An increase in centralization will surely not be something hardcore-bitcoiners will approve of.
So in the last week, two companies released the first-ever (mainnet) Zero-knowledge solutions to help scale Ethereum (L2s).
Today, one of these companies announced that they will be using that technology for bitcoin as well so I'd like like to get your thoughts on this:
This should also help with other use cases:
Today, one of these companies announced that they will be using that technology for bitcoin as well so I'd like like to get your thoughts on this:
“It's very much in the prototype stage,” ZeroSync co-founder Robin Linus told CoinDesk. “But the grand vision is that you download that one megabyte of proof and that is as good as if you had downloaded the 500 gigabytes.”
.....
Light clients or simple payment verification (SPV) nodes have always existed on the Bitcoin blockchain. In fact, Satoshi Nakamoto mentioned the concept in his original whitepaper. They are critical for small devices like mobile phones that can’t download the entire blockchain.
“It is possible to verify payments without running a full network node,” Satoshi wrote. "Verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker.”
ZeroSync goes a step further by verifying transactions via cryptographic proof rather than merely trusting honest nodes as suggested by Satoshi.
.....
Light clients or simple payment verification (SPV) nodes have always existed on the Bitcoin blockchain. In fact, Satoshi Nakamoto mentioned the concept in his original whitepaper. They are critical for small devices like mobile phones that can’t download the entire blockchain.
“It is possible to verify payments without running a full network node,” Satoshi wrote. "Verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker.”
ZeroSync goes a step further by verifying transactions via cryptographic proof rather than merely trusting honest nodes as suggested by Satoshi.
This should also help with other use cases:
A fully functioning zk-proof mechanism can be used to enable a wide range of applications outside of the flagship node syncing use case. ZeroSync has created a developer tool kit to enable applications like proof-of-reserves on exchanges and transaction history compression on second layer protocols like Lightning Labs’ Taro.
Jump to: