On Fri, May 12, 2023 at 02:12:03PM +0200, Robin Linus via bitcoin-dev wrote: > Hi all, > > Today we are publishing a summary of our research on "ZeroSync: Introducing > Validity Proofs to Bitcoin". > > > Here's the preface: > > We introduce ZeroSync, the first-ever proof system addressing Bitcoin’s > scalability challenges with Succinct Non-Interactive Argument of Knowledge > (SNARKs). ZeroSync compresses the entire Bitcoin blockchain into a compact > proof of validity, enabling instant verification and unlocking various > innovative applications. We discuss our prototype implementation of a chain > state proof, utilizing the Cairo language, Utreexo, and recursive STARKs. Our > work enables diverse applications, including quick bootstrapping of full > nodes, trustless light clients, enhanced Lightning Network privacy, and > secure cross-chain bridges. Chain state proofs require no consensus changes, > which is crucial as forks in Bitcoin are challenging to implement and achieve > consensus for. Despite the existing bottleneck of prover performance, we > present a range of optimization strategies and demonstrate the practicality > of generating a complete chain state proof. > Finally, we introduce zkCoins, a client-side validation protocol combined > with zeroknowledge SNARKs, drastically improving privacy and throughput of > token transactions. In combination with future Bitcoin features, such as > Simplicity, zkCoins also enables private and more scalable BTC transactions. > The groundbreaking compression capabilities of SNARKs initiated a paradigm > shift in cryptocurrency design, and ZeroSync is pioneering their application > to Bitcoin. > > > You can find the full paper here: https://zerosync.org/zerosync.pdf > <https://zerosync.org/zerosync.pdf> > Happy to receive any comments and answer any questions the bitcoin dev > community may have about the paper!
Two serious issues with this proposal: 1) You're creating an alternative implementation of the Bitcoin protocol. There is a _long_ history of such implementations failing to implement an exact copy of the consensus rules, leading to potential forks. Obviously, if only used by otherwise lite clients, there is less of a risk associated with this. But the risk is there and will expand as this tech is used for more sophisticated things. 2) If the tech advances to the point where proof-generation is fast enough to happen in real time, Bitcoin miners adopting it along with and other widepsread adoption it may cause Bitcoin to lose its decentralization. At the heart, Bitcoin's consensus is a proof of publication scheme: miners are (weakly) forced to publish blocks by the fact that users and other miners demand blocks to both validate their coins, and mine further. Without blocks themselves being published on a timely basis, the censorship resistance of Bitcoin fails because only a subset of miners actually have the necessary block data to create new blocks with transactions in them. There's also other scenarios where these capabilities could be abused, eg with "illegal data" being published in the chain. Re: #2, the Bitcoin technical community would be smart to find ways to *defeat* ZKP schemes, with the goal of making it technologically infeasible to use them for recently created blocks (eg the last few days worth). -- https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
