Hi! Thanks for the feedback! Many valid points, I'm not really used to doing this, actually!
Thanks for getting back! I'm not used to it either.
About details, or lack thereof: I don't want to overcommit to one overly specific protocol proposal, since it might happen that better ideas emerge as the research progresses. Sorry, but it's likely I haven't yet found the "best ideas I will eventually find"... That's research...
The overcommitment part is legit. I'll give you that. As long as you have some way to prioritise which of five interesting things you will actually get done, it's fine.
And: No, implementation is not the only thing that matters here! Designing a protocol with good soundness does matter! Good implementation of a weak protocol would not help as much, in my opinion. Or, say, if the protocol was not actually zero-knowledge, it would be less likely to be accepted, and that property is not about implementation, you have to bake it into the design.
I don't know what a protocol is, I just assume you mean something like an IETF RFC or IEC standard, in which case the protocol is always under specified and the expected program behaviour is implementation dependent.
About the "flexing": I don't know exactly how things work here; in other places this kind of "flexing" is quite common, sorry if you found it inappropriate. And, I am indeed currently a postdoc at LIP6, working with people from GPAI Policy Lab.
This is literally a funding platform. If you're not flexing, you're not doing your job. I would only be offended if you refused to flex.
Floats are annoying, because they do not form a ring. This makes standard zero-knowledge proofs much more expensive, since you can't straightforwardly use standard stuff like the Goldwasser-Kalai-Rothblum protocol for arithmetic circuits, or Freivald for matrix multiplication.
So, you have to be clever, find workarounds. Some people have worked on related questions, e.g. an "approximate sumcheck" protocol.
I was not familiar with the standard stuff. I looked it up and read through these slides:
I mostly bounced off of them, because the only context I have on prover-verifier games was the legibility work by Kirchner et al , but I found the 2021 paper by Anil & Grosse to be a gentler introduction.
Also: matrix multiplication is "fine" (if we ignore the issue above), all the nonlinear stuff, less so...
I am currently investigating this, no definitive answer yet.
Please note that our preprint proposes sampling-based proofs to lower costs and get within the "acceptable overhead" range, but I think we can harden that further, if we combine it with other components. But it's ongoing research, I don't want to overclaim here!
I am actively eating dinner and waiting for my rate limits to reset as you carry out your investigation, I hope it goes well :)
Another question beyond verifying training FLOPs: figuring out inference verification protocols, to make sure declared computations are indeed inference, and not standard training [doesn't deal with distillation or synthetic data generation, I know]. If things go well, I can try and also tackle that!
You might enjoy this post by Jason: https://substack.com/@jasminexli/p-207237994
Endorsed because I am a sucker for all things AI verification and the name "Paul Wang" agrees with me spiritually. Okay, okay, jokes aside I was initially highly sceptical because of how sparse you were when talking about the project details, theory of impact, how money will be spent, etc etc like buddy you're asking for 30 grand and all you have to say for yourself is "the implementation team will produce prototypes" hello are you for real. And if I was going based on the quality of the proposal on its own, this would definitely be a rejection. 100%, like zero doubt about it, I would have stopped reading at "(who will take care of the implementation part)" What other part even is there? Genuine question.. A million people say "lean" yet you can kind of tell they are just vibing and have never been deep in the Zulip trenches and I almost pigeonholed you as one of those people. Buut I clicked through to your website, read through some of the stuff, and let me tell you, it is criminal that your postdoc isn't already funded by some other source. Academia is hell.
I kind of don't like how you just flex "GPAI Policy Lab" and "LIP6", like sure you can outsource the reputation laundering to institutional affiliation or whatever, orrr you can link to your actual F-ing work okay like that empty spot right next to "Ky Nguyen" should have had a link to https://arxiv.org/abs/2606.05433 with a note like "hey i actually do know this guy and coauthored with him" without which, my first thought was, "is it possible he is inventing the whole collaboration?" I'm not saying you're fake, but damn, learn how to write a proposal (Obviously said with love, xoxo Paul Wang).
Hi! Thanks for the feedback! Many valid points, I'm not really used to doing this, actually!
Thanks for taking the time to dig further!
About details, or lack thereof: I don't want to overcommit to one overly specific protocol proposal, since it might happen that better ideas emerge as the research progresses. Sorry, but it's likely I haven't yet found the "best ideas I will eventually find"... That's research...
And: No, implementation is not the only thing that matters here! Designing a protocol with good soundness does matter! Good implementation of a weak protocol would not help as much, in my opinion. Or, say, if the protocol was not actually zero-knowledge, it would be less likely to be accepted, and that property is not about implementation, you have to bake it into the design.
About the "flexing": I don't know exactly how things work here; in other places this kind of "flexing" is quite common, sorry if you found it inappropriate. And, I am indeed currently a postdoc at LIP6, working with people from GPAI Policy Lab.
So maybe I should say a bit more now:
Floats are annoying, because they do not form a ring. This makes standard zero-knowledge proofs much more expensive, since you can't straightforwardly use standard stuff like the Goldwasser-Kalai-Rothblum protocol for arithmetic circuits, or Freivald for matrix multiplication.
So, you have to be clever, find workarounds. Some people have worked on related questions, e.g. an "approximate sumcheck" protocol.
Also: matrix multiplication is "fine" (if we ignore the issue above), all the nonlinear stuff, less so...
I am currently investigating this, no definitive answer yet.
Please note that our preprint proposes sampling-based proofs to lower costs and get within the "acceptable overhead" range, but I think we can harden that further, if we combine it with other components. But it's ongoing research, I don't want to overclaim here!
Another question beyond verifying training FLOPs: figuring out inference verification protocols, to make sure declared computations are indeed inference, and not standard training [doesn't deal with distillation or synthetic data generation, I know]. If things go well, I can try and also tackle that!
Thanks for getting back! I'm not used to it either.
The overcommitment part is legit. I'll give you that. As long as you have some way to prioritise which of five interesting things you will actually get done, it's fine.
I don't know what a protocol is, I just assume you mean something like an IETF RFC or IEC standard, in which case the protocol is always under specified and the expected program behaviour is implementation dependent.
This is literally a funding platform. If you're not flexing, you're not doing your job. I would only be offended if you refused to flex.
I was not familiar with the standard stuff. I looked it up and read through these slides:
I mostly bounced off of them, because the only context I have on prover-verifier games was the legibility work by Kirchner et al , but I found the 2021 paper by Anil & Grosse to be a gentler introduction.
I am actively eating dinner and waiting for my rate limits to reset as you carry out your investigation, I hope it goes well :)
You might enjoy this post by Jason: https://substack.com/@jasminexli/p-207237994