Is this still in discussion? Or already dead?
1 Like
Yes still in discussions, if anything comes of this it will be a multi-year effort.
2 Likes
I thought this development, the cause, and the proposed solutions might interest people on this thread.
Blockchain ledgers that actually track a continuity of assets (state) rather than just general application data stored on the IC blockchain. This is critical to protect digital assets like ICP and SNS tokens and to provide a publicly verifiable audit trail of digital asset history. I was frankly shocked to find out that no such independent verification assurance is even possible today.
4 Likes
Given the volume and importance of the data, it would be difficult to apply this to all subnets. Can’t we make it so that only the ledger Canister is revalidated?
3 Likes
General conversation happening next week about the state-of-the-art ZKWasm → https://twitter.com/lastmjs/status/1633631931509121025?s=20
6 Likes
Not sure how relevant this is https://blockworks.co/news/polygon-developers-zk-proofs
4 Likes
Nice post. I have gone through all the contents here. Quick news, zCloak Network will deploy a zkVM as a canister in ICP in one or two months. We will use it as a power house for privacy-preserving applications for now (instead of validity proofs). We will show a demo here when the work is done.
10 Likes
Oh wow this is very exciting. If I can ask here, do you have a team/company with a business model for this? I’m always excited about projects that can be sustainable.
2 Likes
Thank you @lastmjs! We do have something in mind and would love to talk about the details. For now, we will first make it work 
4 Likes
Very cool! What proving scheme?
RE: zkWasm. The state of the art zkWasm right now is using Halo2 (slow), with centralized provers mostly focused on ‘scaling eth’. A full-fledged zkWasm implementation without those limitations is almost ready for public consumption 
Pass it a wasm file and it does the proving, blazing fast, + you can host your verifier anywhere.
p.s. Most proving system today need to compose their proofs into groth16 to get ‘on-chain’ …ETH. I think the IC is an obvious solution to this issue, as you can do the compute for the verifiers as-is, no wrapping.
3 Likes
We are targeting Polygon Miden VM atm. Will extend to other zkVMs once this approach works out.
2 Likes
How are host imports handled? Is Wasi supported? What are the limitations?
The core opcodes of wasm are supported out of the box. Other functions and also other special proving systems can be added as ‘ad-hoc’ opcodes. For special provers like those for zkML - we wrap the verifier into a circuit and use it as an opcode. If it works as R1CS it should work well with this system with the caveat that elliptic curved based proving systems will play better together, than those based on hashes.
Host functions are treated as untrusted inputs. So, they should be things you do not mind being public.
1 Like
Hello everyone! We are reporting back. The job is done. Now a Polygon Miden VM for zkSTARK proof verification is live in an ICP canister (beta). For you to easily access it, we have also made a mini maze game on top of it 
The idea is straightforward:
-
Users run a zk-Program locally in their browser. This can be a calculation of their credit score, an evaluation of their KYC status or, in this case, a proof that they have walked out of a maze. This locally generated ZKP will preserve the privacy of their local data while proving the user meet certain criteria or have some specific attributes.
-
Users send the STARK proof to the zCloak verifier canister to have the proof verified. We have been surprised by the speed and low cost to do this in ICP compared to do it directly in an EVM chain.
-
The verifier canister will sign the verification result with tECDSA and this result can be sent to any EVM chains or even Solana and Sui. As long as the target chain can verify the ECDSA signature, it can consume this ZKP result.
As such, we have a chain abstracted ZKP infrastructure built on ICP.
zCloak Network has only been experimenting building things in ICP for a few months and we are very happy with the results so far. Next up, we will polish the ZKP canister to make it robust and at the same time to use it for our privacy-preserving DID platform.
You can try the game here, and we’d appreciate it if you can like or repost our tweet 
20 Likes
This is awesome! Can you roughly compare the cost of verifying on Arbitrum against verifying on ICP + signing + sending + eval on Arbitrum?
6 Likes
Thank you @domwoe! We can do a quick breakdown of cost.
If you want to do STARK proof verification in Ethereum or any L2 chain, the main cost would be the call data of your transaction. The average STARK proof we use is around 200KB. You simply cannot send it to the verifier smart contract in one transaction because there is a size limit of call data (around 90KB) in EVM chains. One hack is to split the proof in several transactions and you can put them together later on. But still, you need to pay for the 200KB call data fee in ETH, even you do it in an L2 as they use Ethereum as the DA layer. So basically the cost for one STARK proof verification is several hundred to even a thousand USD, depending on the gas price.
In ICP, the verification itself costs almost nothing. And we just throw the STARK proof away after the verification as there is no need to store the proof data once it gets verified. The generation of the tECDSA will cost about 0.01 USD. Writing the proof result to e.g. Arbitrum will cost 0.02 - 0.2 USD depending on the gas price.
In conclusion, for a direct STARK proof verification, on average, the ICP approach costs like 10 cents. But if you do it using Ethereum/L2, it will cost hundreds of USD. So we can say that ICP gives us several thousand times fee reduction.
22 Likes
Wow. So what you seem to be telling us is that the Internet Computer is a thousand times more cost efficient as Zero Knowledge Proof execution platform than Ethereum and it’s L2 chains. More importantly, anyone could run a thousand more proofs per dollar on the IC with cross-chain or off-chain ZKP signature verification thrown in using http out calls and EVM integrations?
What about the runtime efficiency? How many orders of magnitude faster could an IC canister execute process ZKP verifications c.f. Ethereum?
2 Likes