This is not a constructive comment.
The URL suggests this is a final(?) project paper for MIT's 6.857: Computer and Network Security course. The paper seems appropriate in style and length for this kind of setting.
I stand by my comment that there doesn't appear to be anything particularly novel about this work. Especially with crypto it is important to stick with well-studied and well-understood primitives. There's a danger that someone looks at this and assumes it is being endorsed by MIT and implements it in their system.
Even supposing that there is a dangerous time to experiment with application with proof of concept work, this really isn't the case for zero-knowledge proof (or more specifically, zk-SNARK) systems right now. I have been in this field for many years and the chief complaint that I have heard many researchers have is that the tooling exists, yet people are not making heavy usage of it outside of ZCash. This, thankfully, has become less true within the last year or two. This work, even if it is written by students, is nice to see given this reality and can give researchers trying to optimize these development tools necessary feedback to improve them.
To put this into a larger research context, keep in mind that various funding agencies have probably spent at least $1 billion on FHE, ZKP, and similar novel crypto research in the last decade. Off the top of my head, this includes DARPA, ONR, NSF, and many more. The biggest barrier this area currently faces is fine tuning these tools to be performant and accessible to non-research level security engineers and developers. This includes determining which applications this technology may be useful for and where, if applied, it is surprisingly not useful. This is why there are continuing (multi-million $) programs to directly target these problems (DARPA SIEVE and IARPA HECTOR for example). This work by MIT students is, at least on the surface, a potentially useful datapoint that we can use to inform our decisions going forward (I personally would like to know more about their development experience using the tools).
But that said, we seem to be talking past each other at this point. I don't see why my criticism of the OP was unconstructive. This is not actually a research paper, it has not undergone any sort of academic peer review, and if the goal is to present it as one example of the kinds of things that are possible to build with zkSNARKs, then it ought to be presented in that context.
I do want to note that it is possible to compose zkSNARKs in an application in ways that result in the composition not being zero-knowledge. Not saying that has happened here, but implying there's no danger with incorrect usage of zkSNARKs seems sketchy to me.
ZKP's let you prove some fact without disclosing the details. "I know an input that makes this program return true".
While you could construct an unusual game that made use of them, they don't generally map into the framework of "play".
Then I think it could be easier to spend resources to prove just the winner (who got something).
It is an implementation detail and performance tuning. The whole thing is very interesting overall.
There is no statement involving just the winner that verifies the authenticity of the auction. You cannot say "the winner won", because "the winner" is a term that only makes sense in terms of all the auction losers. There must be proofs involving all the participants, because you at the very least need to show that all the losing bids were strictly worse than the winning bid.
"prov[ing] just the winner" doesn't make any sense, or really mean anything.
I was wondering about the possibility of another approach and my point was creating just the winner zkproof on the auction side (not bidder side), at the end of the auction. If all the bidders used some stealth method plus homomorphic encryption, the bids could be hidden and maybe they could receive the 'winner zkproof bid receipt' and check it against their very own bid. Then the winner could be able to prove it being the owner of the keys who delivered the stealth bid which won the auction.
I read the paper again and understood their approach. It is clear why they are doing the zkproof for every participant in that context.