Not sure. If the claim is that f(x)=2*x why wouldn’t just the proof of computation work? Why would I (as a verifier) need to see the inner workings (open source) if there is a witness to the computation?
You don’t need to see f, but you do need to see x.
In the case of building a canister, the compiler is f and the canister source code is x.
In order to verify a zk proof, I believe you need:
- the input x
- the output f(x)
- some hash of the program hash(f)
- the zk proof itself
The zero-knowledge part means that you don’t need to actually run f on x (or perhaps know what f is, just its hash).
Please correct me if I’m wrong here…
1 Like
Yes.
My thinking was around how to get verifiable builds around a closed source system; without “trusted members of community” vouching for the veracity of the build.
I was thinking about this too, but I’m not sure the word “verifiable” even makes sense for closed source canisters. What is there to verify if you don’t know the source code? By definition, “verifiable” usually means to verify that some binary came from some source, in this context.
But perhaps you could verify something else, for example privacy.
Another quote from that same article I linked:
Even if some canisters do not want to disclose their source code, there may be help on the way. For instance, there may be verifiably built canisters that offer privacy protection as a service and act as an intermediary between users and closed source canisters to guarantee your privacy. Internet Identity can be seen as an example of a privacy-protection service, offering access to other canisters via a pseudonymous principal.
This is really interesting because now you don’t need “trusted” human intermediaries but instead can rely on “trustless” canister intermediaries. Perhaps the closed source canister can somehow “prove” to the trustless canister intermediary that it makes certain privacy guarantees. Not clear on the details here.
1 Like
I wanted to add something I just learned about STARKs, which is that they appear to be post-quantum secure: https://eprint.iacr.org/2018/046.pdf
I wonder if part of an elegant solution to post-quantum security on the IC would be to implement the zkICVM.
4 Likes
Is this being worked on?
1 Like
Sorry, but I dont see any benefits.
If the majority of ethereum nodes are corrupted they can accept any transactions. Zero knowledge will not fix it if the source is corrupted. The majority of the nodes have to accept it.
ZkProofs shall help to speed up the consensus and it is required by ethereum.
Someone has to explain why zk shall help ic to become better / quicker with respect to scalability etc.
Consensus is general impossible if the number of tolerated faults are violated independent of what kind of security mechanism is used.
Not that I know of, I’m trying to find people interested and I’m happy to guide where I can
The main benefit I am hoping exists is that users of the IC would be able to verify that the replicas are executing transactions (state updates) correctly, without requiring users to run nodes themselves and perform all state transitions from the beginning (which is not possible given the current design, for scalability).
So it seems like having one validity proof served to you from one node would not be good enough, but perhaps the user could query all nodes in a subnet and compare proofs, or at some check point all nodes could threshold-sign a validity proof proving that the current epoch of state transitions was done correctly.
Consensus is still required, but validity proofs may make verification extremely cheap and decentralized. Hopefully it would become very easy to discover and prove fraud. But right now we just have to trust that 2/3 of the nodes are not malicious, there is no way to verify for ourselves that computations are being performed correctly.
5 Likes
When 2/3 of nodes are malicious and take over the subnet, how would NNS know about this immediately and take action? Does NNS slash nodes that are being malicious and have not taken over the subnet yet, and how?
The last paragraph of Shuffling node memberships of subnets: an exploratory conversation - #55 by Manu seems to be relative but not completely answer this specific question. @Manu Would you mind clarifying this?
2 Likes
Seems Polygon has released the first zkEVM with 1:1 feature parity to EVM:
1 Like
and they’re not alone:
Announcement from zkSync is also coming soon: https://twitter.com/zksync
2 Likes
A small group of us has formed (about 11 of us right now) to push forward an implementation of zkWasm. If you’re interested, please reach out and I can add you to the Telegram group.
Wasm VM is to EVM as zkWasm is to zkEVM.
14 Likes
Did they build it in motoko? Just kidding…seriously though, how realistic would it be to put it in a canister? Is it rust?
2 Likes
Seems like this week everybody is launching zkEVMs…
This was a really great overview of what a zkEVM is, the difficulties of implementing one, and why it matters. This part in particular is pertinent.
Most projects like Polygon, zkSync, and Scroll are building zkEVMs as part of a L2 rollup to scale Ethereum. Can the IC benefit from the same? If subnets are overloaded with transactions (i.e. update calls), can users submit transactions to some centralized off-chain zkWasm node, which then bundles those transactions into a single update call to the IC? This feature is insane to me… there doesn’t seem to be a theoretical limit to how low finality times could go… just add more zkWasm nodes?
But as mentioned in that article, perhaps zk VMs can directly scale L1s. Having users validate proofs themselves off-chain like @lastmjs suggested may be good for security (although it requires the users to maintain state, which means the IC might need to expose that state in a new API??), but I wonder if there are direct performance benefits of a zkWASM as well. Although it would probably require architectural changes to how subnets work.
7 Likes
Any new information or progress on this.
2 Likes
Would also be interesting in learning more about this.
1 Like
Hey everyone, I’ll give an update soon. There are some developments to speak of.
13 Likes
Did you Tweet about this?
1 Like
Maybe this ZK-WASM | Delphinus Lab
4 Likes