VIMz: Privacy Preserving Verifiable Image Manipulation using Folding-based zkSNARKs

[lovely-necromancer]

No description provided.

[chiro-hiro]

Hi @lovely-necromancer,

There are some questions of mine:

1. Image manipulation is also include type conversion and image compression, the number of image formats and compression algorithms will decrease feasibility of this project. I hope you can specify what is in scope and out of scope for this proposal.

2. Folding scheme is useful as long as the step circuit is big enough, do you have any estimation for the circuit size of your implementation?.

[lovely-necromancer]

Hi @lovely-necromancer,

There are some questions of mine:

1. Image manipulation is also include type conversion and image compression, the number of image formats and compression algorithms will decrease feasibility of this project. I hope you can specify what is in scope and out of scope for this proposal.
2. Folding scheme is useful as long as the step circuit is big enough, do you have any estimation for the circuit size of your implementation?.

Thanks for your comment @chiro-hiro. Regarding your questions:

1. Our commitment scheme is regardless of the image type. Because as long in any image format, as long as you can retrieve the RGB values of each pixel, then you are good to go and can calculate the 'folding-friendly' hash of the image that we proposed. More precisely, we use RGB values of images in the commitment and in our ZK circuits, so, you can publush the transformed image in any format (PNG, BIT-MAP, JPG, . . .) as long as your format does not change the values of RGB in pixels. So, very lossy compressions that might be available in jpg formats is not supported, but if the format does not have lossy compression, then we support it.
2. yes indeed, depending on the transformation and the size of the input image, processing one row of the image can require from something around 150k to 1M constraints. All are big enough to benefit from folding. We have extensive performance analysis in our eprint. I've attached a few tables from the paper to this comment.

We measured our performance on both a laptop device and a server with better CPU

[chiro-hiro]

Hi @lovely-necromancer

Thanks for the clarification, I'd prefer to have (1) in the proposal to clarify the feasibility.

Regarding to (2), I'd love to check the result afterward. Don't hesitate to share with me 😁

Gonna check the paper as well, it sounds interesting.

[lovely-necromancer]

Hi @lovely-necromancer

Thanks for the clarification, I'd prefer to have (1) in the proposal to clarify the feasibility.

Regarding to (2), I'd love to check the result afterward. Don't hesitate to share with me 😁

Gonna check the paper as well, it sounds interesting.

Thanks @chiro-hiro ,
yes I'll add more clarifications on both (1) and (2) to the proposal.

Regarding (2), in our repo we have prepared automatic benchmarking scripts that support both single and parallel transformations. More details can be found here: https://github.com/zero-savvy/vimz?tab=readme-ov-file#benchmarks on our readme

[lovely-necromancer]

@chiro-hiro, All done 😃
Please let me know if you had further comments.
I would do my best to address them :)