Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An introduction to zero-knowledge machine learning

worldcoin.org

Post reply on HN
Print view View original

11–20 of 20 posts

Re: An introduction to zero-knowledge machine learning

#11

Post by MacsHeadroom »

reaperman wrote: post #7
lukeschlather wrote: post #6

I'm very confused by the use case here, and this doesn't make sense to me: > A good example of this would be applying a machine learning model on some sensitive data where a user would be able to know the result of model inference on their data without revealing their input to any third party (e.g., in the medical industry). I don't get why I would care that the answer was generated specifically by GPT4. It sounds li…

> make models that can run on consumer hardware. This will not be hard at all in 10-20 years given the pace of semiconductor FLOPS per watt improvement. https://en.wikipedia.org/wiki/Koomey%27s_law The neural engine in the A16 bionic on the latest iPhones can perform 17 TOPS. The A100 is about 1250 TOPS. Both these performance metrics are very subject to how you measure them, and I'm absolutely not sure I'm comparing…

You're assuming no algorithmic enhancements and missing the currently happening shift from 16bit to 4bit operations which will soon give ML hardware a 4x improvement on top of everything else.

We could be training GPT-4s in our pockets by the end of this decade.

Re: An introduction to zero-knowledge machine learning

#12

Post by ruuda »

lukeschlather wrote: post #6

I'm very confused by the use case here, and this doesn't make sense to me: > A good example of this would be applying a machine learning model on some sensitive data where a user would be able to know the result of model inference on their data without revealing their input to any third party (e.g., in the medical industry). I don't get why I would care that the answer was generated specifically by GPT4. It sounds li…

> but that doesn't really sound possible

It sounds almost too good to be true, but snarks enable a prover to convince a verifier in O(log n) time that a statement of size n is true. In fact many constructs enable this in O(1) verifier time (but the prover is quite slow). With zk-snarks, part of the statement can even be private: the proof reveals nothing about the input, yet it can convince a verifier.

All of this is probabilistic and making some assumptions about the complexity of an adversary, but that is very normal in cryptography. We consider eddsa signatures secure, even though one could in theory find the private key by brute force. Snarks “convince” a verifier in the same manner: generating a proof of a false statement is computationally infeasible, but in principle not impossible.

Re: An introduction to zero-knowledge machine learning

#13

Post by mxwsn »

lukeschlather wrote: post #6

I'm very confused by the use case here, and this doesn't make sense to me: > A good example of this would be applying a machine learning model on some sensitive data where a user would be able to know the result of model inference on their data without revealing their input to any third party (e.g., in the medical industry). I don't get why I would care that the answer was generated specifically by GPT4. It sounds li…

An important use-case is federated learning, which Google, and many healthcare / pharmaceutical companies are very interested in. In federated learning, multiple companies or groups with their own private data come together to train a model jointly on all the private data, while keeping the data private. You need more than zero-knowledge proofs to actually do federated learning securely, but to my limited knowledge they are one tool in the toolbox that can be useful.

Re: An introduction to zero-knowledge machine learning

#14

Post by rsrsrs86 »

mxwsn wrote: post #13
lukeschlather wrote: post #6

I'm very confused by the use case here, and this doesn't make sense to me: > A good example of this would be applying a machine learning model on some sensitive data where a user would be able to know the result of model inference on their data without revealing their input to any third party (e.g., in the medical industry). I don't get why I would care that the answer was generated specifically by GPT4. It sounds li…

An important use-case is federated learning, which Google, and many healthcare / pharmaceutical companies are very interested in. In federated learning, multiple companies or groups with their own private data come together to train a model jointly on all the private data, while keeping the data private. You need more than zero-knowledge proofs to actually do federated learning securely, but to my limited knowledge t…

Wow. This fed learning field is really, really cool.

Re: An introduction to zero-knowledge machine learning

#15

Post by carlosdp »

lukeschlather wrote: post #6

I'm very confused by the use case here, and this doesn't make sense to me: > A good example of this would be applying a machine learning model on some sensitive data where a user would be able to know the result of model inference on their data without revealing their input to any third party (e.g., in the medical industry). I don't get why I would care that the answer was generated specifically by GPT4. It sounds li…

I think you're misunderstanding the example use-case (it's understandable, it took me a decent amount of completely focused time to really understand zero knowledge cryptography).

The use-case with medical data described isn't like homomorphic encryption (where computation is done on an untrusted device, but with encrypted inputs/outputs). It would be more like: being able to prove you have some medical condition to an insurer, without your doctor having to provide them the lab results, but instead providing a ZK proof of an ML model that detects that condition, for example.

Using these kinds of proofs, you can start to silo your information off to just the parties that absolutely must have access to it, while also allowing parties that need to be able to verify certain narrow attributes (like an insurer needing proof you needed some procedure) to verify it without needing to invade your privacy.

Re: An introduction to zero-knowledge machine learning

#16

Post by vlovich123 »

MacsHeadroom wrote: post #11
reaperman wrote: post #7

Earlier quoted context omitted.

> make models that can run on consumer hardware. This will not be hard at all in 10-20 years given the pace of semiconductor FLOPS per watt improvement. https://en.wikipedia.org/wiki/Koomey%27s_law The neural engine in the A16 bionic on the latest iPhones can perform 17 TOPS. The A100 is about 1250 TOPS. Both these performance metrics are very subject to how you measure them, and I'm absolutely not sure I'm comparing…

You're assuming no algorithmic enhancements and missing the currently happening shift from 16bit to 4bit operations which will soon give ML hardware a 4x improvement on top of everything else. We could be training GPT-4s in our pockets by the end of this decade.

To be fair, they’re also being extremely generous about HW scaling. There’s no way we’re going to see doublings every 18 months for the next 6+ years when we’ve already stopped doing that for the past 5-10.

Re: An introduction to zero-knowledge machine learning

#17

Post by webmaven »

ruuda wrote: post #12
lukeschlather wrote: post #6

I'm very confused by the use case here, and this doesn't make sense to me: > A good example of this would be applying a machine learning model on some sensitive data where a user would be able to know the result of model inference on their data without revealing their input to any third party (e.g., in the medical industry). I don't get why I would care that the answer was generated specifically by GPT4. It sounds li…

> but that doesn't really sound possible It sounds almost too good to be true, but snarks enable a prover to convince a verifier in O(log n) time that a statement of size n is true. In fact many constructs enable this in O(1) verifier time (but the prover is quite slow). With zk-snarks, part of the statement can even be private: the proof reveals nothing about the input, yet it can convince a verifier. All of this is…

All that can really be conveyed is the "truth" that the model produced the output in response to the input. Given the other vulnerabilities of neural networks (biases, opaqueness, etc.) this is a bit like worrying about a MITM attack when communicating with a sock puppet.

Re: An introduction to zero-knowledge machine learning

#18

Post by reaperman »

vlovich123 wrote: post #16
MacsHeadroom wrote: post #11

Earlier quoted context omitted.

You're assuming no algorithmic enhancements and missing the currently happening shift from 16bit to 4bit operations which will soon give ML hardware a 4x improvement on top of everything else. We could be training GPT-4s in our pockets by the end of this decade.

To be fair, they’re also being extremely generous about HW scaling. There’s no way we’re going to see doublings every 18 months for the next 6+ years when we’ve already stopped doing that for the past 5-10.

I haven't seen evidence in a slowdown of Koomey's Law. Would be very interested in those sources!

Re: An introduction to zero-knowledge machine learning

#19

Post by vlovich123 »

reaperman wrote: post #18
vlovich123 wrote: post #16

Earlier quoted context omitted.

To be fair, they’re also being extremely generous about HW scaling. There’s no way we’re going to see doublings every 18 months for the next 6+ years when we’ve already stopped doing that for the past 5-10.

I haven't seen evidence in a slowdown of Koomey's Law. Would be very interested in those sources!

Have you read the Wikipedia page? Moore’s law started ending ~23 years ago followed by Denmark Scaling ~18 years ago. It’s not necessarily fully stopped because there are other architectural improvements that have been delivered along the way, but we simply have reached nearly the end of the road for scaling this due to a combination of heat dissipation challenges and inability to shrink transistors further. 3D packaging might increase things further but it’s difficult and an area of active research (+ once you do that afaik you’ve unlocked the “last” major architectural improvement). I think the current estimates put the complete end to further HW improvements at ~2050 or so. You can still improve software or build dedicated ASICS/accelerators for expensive software algorithms, but that’s the world pre-Moore which saw most accelerators die off because the exponential growth of CPU compute obviated the need for most of them (except for GPUs). We’re coming back to it with things like Tensor cores. Reversible computing is the way forward after we hit the wall but no one knows how to do this yet.

> But in 2011, Koomey re-examined this data[2] and found that after 2000, the doubling slowed to about once every 2.6 years. This is related to the slowing[3] of Moore's law, the ability to build smaller transistors; and the end around 2005 of Dennard scaling, the ability to build smaller transistors with constant power density.

Re: An introduction to zero-knowledge machine learning

#20

Post by reaperman »

vlovich123 wrote: post #19
reaperman wrote: post #18

Earlier quoted context omitted.

I haven't seen evidence in a slowdown of Koomey's Law. Would be very interested in those sources!

Have you read the Wikipedia page? Moore’s law started ending ~23 years ago followed by Denmark Scaling ~18 years ago. It’s not necessarily fully stopped because there are other architectural improvements that have been delivered along the way, but we simply have reached nearly the end of the road for scaling this due to a combination of heat dissipation challenges and inability to shrink transistors further. 3D packa…

> But in 2011, Koomey re-examined this data[2] and found that after 2000, the doubling slowed to about once every 2.6 years.

Koomey's own actual post from 2011 still showed consumer systems matching the 1.57 slope up to that time, FWIW.

https://www.koomey.com/post/14466436072

Wikipedia mis-cited it in the text and should have said "But in 2016". However, the 2016 analysis misses the A11 Bionic through A16 Bionic and M1 and M2 processors -- which instantly blew way past their competitors, breaking the temporary slump around 2016 and reverting us back to the mean slope.

Mainly because now they're analyzing only "supercomputers" and honestly that arena has changed, where quite a bit of the HPC work has moved to the cloud [e.g. Graviton] (not all of it, but a lot), and I don't think they're analyzing TPU pods, which also probably have far better TOPS/watt than traditional supercomputers like the ones on top500.org.

Post reply on HN