Applications of ZKP
We recently had the pleasure of hosting a panel to discuss different applications of ZKP, on Friday August 12. We hosted six wonderful speakers from Slush SDK, Neptune, Aztec and o(1) Labs.
The recording can be found on our YouTube channel here: https://youtu.be/m5WiIOC3xcM. You can join our ZKP discussion Telegram group chat here: delendum.xyz/telegram.
Ago Lajko & Kalman Lajko: ZK Rollups for App Specific Scaling
The core insight into the product is that app-specific rollups will be crucial for fractal scaling. The team predicts that there will be many L2s, and these L2s will be hosting L3s, and a large portion of these L3s will be app-specific, in the sense that there will be a single VM, running a single app which has significant control over the VM.
This is where the Slush SDK comes into play. Slush SDK is an open-source application that allows you to spin up L3s on demand. Initially starting off, by implementing the Tendermint consensus mechanism to work on StarkNet, so that the L3s spun are decentralized. Here the crucial problems the team is trying to solve are building a live client that runs on the StarkNet VM that is able to read Tendermint, and also adapting Tendermint to work with STARK signatures.
However, with this situation, there will be a lack of communication between the different apps-specific rollups.
To solve this communication problem, the solution proposed is to implement a trustless bridging mechanism. This is so that when a transaction happens on a L3, it can be proved that this transaction occurred on any of the L2s, L3s and the L1. This can be done by passing along a Merkle branch off-chain to the different nodes in the L2s, L1s which gets verified by comparison to the hash of the Merkle branch sent on chain.
Ferdinand Sauer: Can Machines Learn with Zero Knowledge?
Generally speaking, executing a virtual machine (VM) requires two inputs: a program, and the program’s input. Running the VM then produces some output. A zk-VM that has attached to this a STARK prover, also produces a proof. If you take these four items: (input, program, output, proof) as a four tuple, you can use a verifier to assure that the four tuple is integral. zk-VMs also have a third interface for input, generally called the “witness” or secret input, which is not shared with the verifier.
In machine learning, the term “model evaluation” refers to the process of querying a model using a, well, query, resulting in a classification. Using a zk-VM to perform the model evaluation ensures that the classification result was computed honestly, guaranteeing fairness across all inputs. Unfortunately, this grants the verifier access to the model, which can be undesirable. Using a technique known as “program attestation”, the model can stay hidden, while the correct execution can still be attested to. One way (of several) to achieve program attestation is to supply the actual program as a witness to the VM, publicly revealing only the program’s hash digest.
In model training, the flow is usually inputting data into a learning algorithm, to get a model. We can use a zk-VM and use the data as a witness, to hide the data, but prove that the learning algorithm was applied correctly, and did not introduce bias. To extend this and hide the model you have to hash the model and only output the digest. You can then get the model as a secret output.
For model refinement, if you have a model that works, but now have more new data, what is ideal is to use the old model and improve it with the new data. This is where recursion comes into play: by supplying the proof of the old model as input, it’s possible to use the recursive verifier to attest to the correctness of the old model, generating a proof for the new model as a result. Recursive verification can also be used to realize federated machine learning: by distributing the training across multiple instances of the zk-VM, then combining all their models and batch verifying the associated proofs, a new model can be computed in a verifiably correct manner.
The Potential of Private Smart Contracts: Michael Connor
Currently in Ethereum today, all information is public such as state variables, inputs and computation. Additionally, it is very expensive to transact in Ethereum mainnet due to gas fees and network congestion.
The first iteration of Aztec, was zk-money, that just made the transfer function of the ERC-20 contract private, however it was still expensive as it was on mainnet. Then Aztec L2 was invented which was a rollup that allowed cheap, private money.
Aztec Connect is the most recent release that allowed two new functions other than the ERC-20 transfer function: DeFi deposits and DeFi claims. This allowed users to interact with more smart contracts privately. This works through the established pool of private contracts, and a bridge contract that is deployed. So anonymity is retained but amounts are public. There is also batching for gas optimization. However, a lot of information is still left public: L1 inputs, states, computations and contracts.
The next iteration will also support private functions and private states which are not available on mainnet or any L2. Therefore there will be three layers to the structure as shown below:
Instead of traditional blockchains or rollups where computation is run by the block leader or sequencer, the change of private state computation must be done on the user’s device to retain privacy and prevent leaks.
Furthermore, currently we have composability in functions, where functions can call other functions, and composability in smart contracts. To also incorporate composability with circuits, a validation circuit is needed to check that you are adhering to all rules of the smart contract platform. This then allows circuits to call other circuits, leading to recursion! This helps to design and optimize zero-knowledge proofs on an ultimate, private Layer 2.
Phil Kelly & Brandon Kase: Scan of emerging cases
Running through some emerging uses for ZKPs. Firstly there is private transactions, which includes protocol-shielded accounts and transactions. As well as private transaction on the D-App level similar to mixers.
Secondly, is identity, an exciting hot space right now. A lot of new startups in the one-to-one anchoring of real world ID to unique / linked group of on-chain addresses (PoH). Non-doxxing verified credentials as either non-transferrable NFTs or off-chain proofs will also be needed in the space which helps with anti-spam, voting and other forms of gated interactions.
Using ZKPs in oracles can help you mask information sets and maintain some privacy in specificity, a good example being credit scores. Finally, bridges with privacy-preserving functionality similar to Mina’s Mina-ETH bridge built by nil-Foundation is a very interesting area that is expected to see a lot more innovation.
The current landscape of ZK computation with blockchains can be classified into the following three categories:
- On-chain computation in typical smart contract platforms. (does not include ZK computation).
- Self-sovereign ZK: (at least one recursive layer of)-Proofs happened client-side, private data leaks to a counter-party.
- Typical ZK rollups: Off-(main)-chain computation sequenced by a counter-party.
A use of recursion that has previously not been explored can be classified as Multiparty self-sovereign ZK recursion. This is when recursive composition happens on client side custody at different steps of computation. It is an interesting and growing area to discuss and practice in the ZKP field — more to come in the future!
We host monthly panel discussions and publish research blogs. If you want to share your ideas, or seek advice, review, or co-publish, feel free to contact us at hello@delendum.xyz.
