[HN Gopher] What's the Deal with Zkapps?
___________________________________________________________________
What's the Deal with Zkapps?
Author : baby
Score : 59 points
Date : 2022-10-20 16:48 UTC (6 hours ago)
(HTM) web link (www.cryptologie.net)
(TXT) w3m dump (www.cryptologie.net)
| simpsond wrote:
| Cool. My takeaway is this: Instead of sending an RPC call to the
| network to execute code and change state, code is executed off
| chain (locally), and the state change is sent to the network with
| proof that it's valid state. If my thinking is correct, this is
| pretty awesome. The article was very well written IMO.
| shakow wrote:
| Yes, that's the idea. In a nutshell, you can see it as a
| checksum for program execution instead of static data.
| phlip9 wrote:
| Woah this looks cool! My current (clearly outdated) mental model
| requires fixed inputs for a zkp, e.g., some fixed view of the
| chain state, some encrypted inputs, etc... I'm curious to know
| more how Mina overcomes these limitations.
|
| OTOH, secure enclaves like SGX are convenient since the
| overhead's not bad, you can run the enclave as a networked
| service, make HTTPS connections, sample randomness via RDRAND,
| etc...
|
| Do you think zkapps might have similar capabilities in the
| future? I'm not sure the analogy works all that well in
| blockchain land, but perhaps more as a virtual software-only
| enclave or something?
|
| It's not super clear to me how you would sample private
| randomness, or perform remote attestation, or prevent replay
| attacks without a remote trusted storage.
|
| I also remember even the best proof systems seemed to have like
| 100x prover overhead on CPU + memory usage, but that was a few
| years ago. Have things gotten better recently?
| camdenlock wrote:
| What's stopping Ethereum from gaining zkapp support?
| DennisP wrote:
| It already has zkrollups, which run zkapps off-chain but store
| their state and the proofs on chain. That multiplies Ethereum's
| transaction capacity by an order of magnitude or two, without
| losing any security.
|
| Long-term, Ethereum might implement it natively, but right now
| the tech is advancing so fast that they're happy having
| multiple layer-2 systems doing it.
| dane-pgp wrote:
| > These chips would typically be certified by some vendor (for
| example, Intel SGX) with some claim that it's hard to tamper with
| them. Unfortunately for Intel and others, the security community
| has found a lot of interest in publishing attacks on their
| "secure" hardware, and we see new hacks coming up pretty much
| every year.
|
| Even if Intel engineers were capable of writing firmware with
| zero bugs and their chips were able to resist all hacking
| attempts, any user of those chips has to treat Intel as a trusted
| third party.
|
| This is especially bad if, in practice, you have to regularly
| apply (encrypted?) firmware updates from Intel whenever they tell
| you to (because your users won't trust an execution which comes
| with a proof from an out-dated firmware version).
|
| Once you've accepted Intel as a trusted third party, then
| consider that they are subject to interference by at least one
| government, so now your threat model has to include them too.
| born-jre wrote:
| There are projects doing general propose computing/turning
| complete vm to zk which will be big deal. Maybe some research
| paper / hardware implementation away from speed enough for their
| general propose use -\\_(tsu)_/-, very excited. :D
| jasonmorton wrote:
| Examples include the various zkEVM projects, risc0, and
| slightly more limited stuff like our effort to compile
| PyTorch/ONNX to a zk circuit
| (https://github.com/zkonduit/ezkl).
|
| Speed and memory usage is improving quickly.
| iregina wrote:
| zk was so popular at devcon!
| montenegrohugo wrote:
| Best blockchain specific writeup I've seen yet on zk
| rafale wrote:
| I didn't understand the part where the program can have secrets
| (closed source), non-deterministic (e.g. invokes random) or async
| (pulls data outside the blockchain).
|
| If the program is closed source, you can't trust it, so you can't
| trust its proofs even if you can validate them quickly.
|
| For the rest, the need to trust data is as important as trusting
| the code. But maybe there are applications where that's not
| important.
| Ar-Curunir wrote:
| Non-determinism in the context of zkSNARKs refers not to
| randomness, but rather to NP-style non-determinism. I.e.,
| zkSNARKs support statements of the form "There exists a witness
| w such that f(x, w) = true", where f is a predicate, and x is a
| publicly known value.
|
| This allows cool things. For example, if you wanted to use a
| zkSNARK to check if something was sorted, you don't have to
| implement a sorting algorithm in the zkSNARK language (this
| would take time nlogn). Instead, you can just implement an
| algorithm that takes as input a list, and checks that it is in
| ascending order (which takes time O(n)). In this case, the
| witness is the sorted list, and the actual sorting happens
| outside the zkSNARK. This enables the zkSNARK impl to be more
| efficient.
| dane-pgp wrote:
| > the program can have secrets (closed source)
|
| I didn't read it as suggesting that the source code itself
| would be secret, only that the code would act on secret data,
| like private keys.
|
| > non-deterministic (e.g. invokes random)
|
| I'm not sure how that works either, since there's no way to
| prove that the "random" number you generated off-chain really
| is random. It's possible to do random number generation among
| multiple mutually-untrusting parties already, though, just by
| getting them to each pick a random number, and publishing its
| hash, then (after receiving all the hashes), revealing the
| input random numbers and XORing them all together.
|
| > or async (pulls data outside the blockchain).
|
| I assume the data from outside the blockchain has to have
| signatures on, so that the smart contract on the blockchain can
| verify that this data is legitimate. Again I'm not sure why
| that needs zero-knowledge.
___________________________________________________________________
(page generated 2022-10-20 23:01 UTC)