This week’s article will explore one of the more technical aspects of blockchain technology, proof-of-concept, which is often mentioned in the blockchain space, but which only technical developers usually care about. Recent advances in BSV have made the technology open and accessible, so I hope to spend some time explaining what they are and why they are important to the entire industry.
What is evidence of ZK?
Besides sounding like a very cool word, zk-proofs (or zk-SNARKs as they are commonly called) are basically a way a party (or prover) can prove to a second party (the prover) that they know something hidden. ) without revealing the actual one to the public. So this allows a buyer to buy a secret from an untrusted seller if the purchase itself can be done atomically.
This turns out to be a key cornerstone of all smart contract technologies on blockchains, as it allows complete privacy for smart contracts while providing transparency for actual transactions.
Some blockchains, such as ZCash, use ZKPs as part of their base protocol to implement things like fixed inflation, coin supply, and distribution schedules, while others allow the use of ZKPs in their native scripting languages, such as BSV and ETH.1.
Although ZKPs have been a technology that has existed since the 1980s, their practical use in blockchains has been fraught with challenges, mainly due to trade-offs in the size and computational resources needed to create and use them effectively. Traditional zk-SNARKs required a secure ‘setup’ phase, which if compromised (via secret leakage or a compromised key) would compromise the entire system in a hard-to-detect manner. In addition, common applications required significant computational resources to generate proofs (>100MB for >10 seconds and several gigabytes of memory). All of this really hindered its use in Bitcoin, given BTC’s scaling limitations2 in terms of transaction block sizes and also the impracticality of waiting 20 seconds for proof generation for each transaction.
However, the potential benefits of proof-of-concepts far outweigh their practical limitations, so many blockchain projects are currently working on ways to accommodate proof-of-concepts while relaxing their limitations.
Such benefits become clear when considering the main purpose of any blockchain: decentralization or distribution of computational logic in the case of smart contracts (in bitcoin they are called simple predicate scripts or payment terms). In theory, if zk-proofs were implemented as the underlying consensus protocol of the blockchain, then it would effectively become something like ZCash, and in projects like Ethereum, each node would need to compute the same redundantly to make sure the validator is valid. ‘didn’t cheat.’ Instead, the prover can only calculate the result of executing the contract, post the proof of zk and be done – at least in theory.
In practice, due to witness metrics (proof), it is becoming increasingly prohibitive due to the blockchain economy for non-volatile platforms like ETH, where there will be more complex (and thus useful) blockchain-proof applications. It is very expensive to operate due to the size of the data to be put on the chain and the gas fees measured by the amount of computation required. This severely limited the implementation of zk-proofs on Ethereum. The problem with BTC is that there is a hard limit on the size of transactions and blocks, which puts positive pressure on the cost of including such proofs on the public blockchain.
However, there are no such restrictions with BSV, and thus we have seen some significant progress in the development of native applications of zk-proofs in recent months.
SCrypt, a project that combines a Typescript-like smart contract language and compiler with Bitcoin ASM (op-codes), is pioneering work on zk-proofs and their derivatives in BSV. What started as a theoretical proof of concept a year ago has turned into a plethora of tools and examples for leveraging the power of zk-proofs on bitcoin. I will briefly review the stages here in chronological order. Feel free to use this as a “reading list”.
1) November 2, 2021 — The first describes how to build a ZKKSP in theory, where proof can be used by an outside party to help a recipient find the private key that results in the desired empty address. This can be done without the seller of the data knowing the actual private key (which would defeat the purpose), while also allowing the buyer to not have to do the computations themselves to get the key for the empty address they want.
2) August 6, 2022 — Almost a year later, a major breakthrough in creating recursive CPCs can be applied to problems where the overall aggregate problem can be solved in small steps. Each step can then produce an equivalently small ZKP, which proves the “change” from the previous solution. This way, instead of calculating a very LARGE single proof, which is prohibitive in many ways, as mentioned above, the proof can be “extra”. It is also useful for problems where the response is not discrete but rather on a continuum. and can be infinitely refined as optimization problems for which the buyer is willing to pay for a sufficiently “good enough” solution. The work can then be paid incrementally rather than in a winner-take-all fashion. Work can be distributed among a pool of workers, each contributing and paid in part for their contributions. For example, calculating the Fibonacci series or finding consecutive digits of pi or running BitTorrent!
3) November 10, 2022 — Sudoku puzzle! Billed as the first “hands-on” implementation of ZKPs in bitcoin (which includes all bitcoin chains), sCrypt last week released a ZKP implementation for outsourcing Sudoku puzzle solving. While it’s been talked about in theory for the past year or so, it’s finally something to actually see code for.
With this example, developers can now release common issues to the public in an untrusted manner as a stateless boonand the solutions provider can securely collect the reward in a non-required manner any deposits or intermediaries. This deserves some pause and thought because this is what people have been trying to get to work for a while.
An improvement over the previous implementation, which required a setup process between buyer and seller (meaning it could not be easily used as a pseudonymous reward), this version can be done in a single reward transaction sent by the buyer, and collected by the pseudonymous seller in one transaction.
Although this example uses Sudoku as a puzzle to solve, any easily verifiable puzzle can use this method.
Consider traveling salesman solutions for logistics companies or solving chess endgames for profit! Or something like putting a premium on creating a more efficient sorting algorithm? Or as a way to evolve genetic algorithms to do something useful like boolean operations? (Both have simple algorithmic methods to verify that they are indeed valid solutions).
4) November 14, 2022 — Proof of Reserves — In light of the recent bankruptcy of Defi giant FTX, many companies have started talking about implementing proof of reserves to show the world that they control the assets they claim to need, and anyone else besides. their liabilities can be “counted” to ensure that their assets cover all their liabilities. This describes how it can be done in Bitcoin.
5) November 26, 2022 – Payment for decryption key – Swiss army knife of ZKP!
This is the true multi-tool of blockchains… the ability to securely pay for a private key. The applications of this are probably worthy of an article on their own. Malicious hackers have exploited this use case in the past with attacks like cryptolocker, where a hacker encrypts all of your personal data on your computer and demands a ransom to decrypt it again by selling you a private decryption key. Adding insult to injury for many victims who have paid the ransom in bitcoins, the hacker will still refuse to deliver the private key, leaving the victim out of pocket and causing data loss. This enables many use cases, with the ability to change the private key in a non-trusted manner, confirming both that the vendor controls the necessary key and that payment for the key cannot occur if the key is not simultaneously released. Insecure digital marketplaces are driving legacy and digital legacy planning. It is a generic “escrow” smart contract that can be used to build most other complex contracts.
6) Bitcoin zkBattleship — Finally, any discussion of online gaming using ZKPs would not be complete without an example of a shared game board like Battleship that does not require oracle knowledge to know the state of a shared game board. Such games can be applied to most card games where there is a ‘dealer’ state, or rather who keeps track of which players have which cards? This example shows an implementation using the game Battleship, where the blockchain manages the “game state” in a trustless manner.
As you can see from recent posts from the SCrypt team, the technology is developing rapidly and is not yet mature, as well as the development of easier tools to help novice developers start writing smart contracts on bitcoin that use ZKPs. But the floodgates are now officially open. Let the games begin!
width=”562″ height=”315″ frameborder=”0″ allowfullscreen=”allowfullscreen”>
/djc
Wall Street technologist
[1] The lack of BTC is noticeable because they disable required language features
[2] Also, as previously mentioned, BTC Core has not reactivated the original Bitcoin 2009 opcodes to make this possible.
See: BSV Global Blockchain Convention presentation, Smart Contracts and Computing at BSV
width=”562″ height=”315″ frameborder=”0″ allowfullscreen=”allowfullscreen”>
New to Bitcoin? Check out CoinGeek Bitcoin for beginners section, the ultimate resource guide to learning more about Bitcoin – as originally envisioned by Satoshi Nakamoto – and the blockchain.