test(chacha): NIVC full test with 40 word fold

[Autoparallel]

Tasks

• Create a an additional test for NIVC_FULL_2_CHACHA that uses a param of [40] (the other test uses [80]

This assures that we can fold multiple portions of plaintext/ciphertext together in a coherent way. We need to make sure this is doable so that, in the future, we can handle plaintext sizes >1KB.

Potentially:

• Test that this also handles padding appropriately (this would be a separate issue).

[0xJepsen]

I don't think it makes sense to fold chacha at all. It already is so much faster and will not be a bottle neck not folding it at all. If that for some reason changes i could see that being the case.

[0xJepsen]

In googles research they found average response sizes we between 500b to 2kb.
https://www.chromium.org/spdy/spdy-whitepaper/

[Autoparallel]

I don't think it makes sense to fold chacha at all. It already is so much faster and will not be a bottle neck not folding it at all. If that for some reason changes i could see that being the case.

We will likely want to fold it for the 2KB case that you mentioned is already an average.

Furthermore, if we want to handle 10+KB, we will certainly need to fold. It absolutely makes sense for ChaCha to be foldable. It is a requirement moving forward.

Just to be clear, we can't support something like a 10KB ChaCha circuit on a client device -- this would require too much onboard memory (with roughly 10M constraints)

[0xJepsen]

what is an example of a response that would be 10k, i feel like less 0.01% responses are that big. I don't dispute it's useful to fold it but i don't think it makes sense for it to be a launch requirement.

[devloper]

I don't see this as a launch blocker for us today, but I do think it'll be common to have API requests in the range of 1-10KB. In my mind where this becomes most impactful is when we start attempting to prove HTML content. Those pages are much bulkier and range be from hundreds of kilobytes to megabytes!!

For example, try:

curl -so /dev/null https://www.wsj.com -w '%{size_download}'

This is 500kb for the homepage of wsj

imo, we don't need to have this for launch but as a vision and goal larger proofs is definitely a priority to me.

[0xJepsen]

Nice yeah that makes sense to me.

[Autoparallel]

Part of the circuit roadmap is to allow >1KB proofs. Therefore, we will need to fold ChaCha. Hence, we need this done!

Not immediately, but roughly by v0.8. Go look at the circuits roadmap to see the plan moving forward

[Autoparallel]

E.g., prove authorship of a paper on arXiv:

❯ curl -H "Accept: application/xml" \
"https://export.arxiv.org/api/query?id_list=2401.03703" \
--silent --output /dev/null --write-out "Size: %{size_download} bytes\n"

Size: 3260 bytes

To be clear, this is XML. We also don't support that.

Here is a JSON example:

❯ curl "https://api.crossref.org/works/10.1145/1327452.1327492" \
--silent --output /dev/null --write-out "Size: %{size_download} bytes\n"

Size: 7905 bytes

Prove you have authorship of a paper found in DOI/crossref lookup and that paper was about... whatever.

[0xJepsen]

Chacha with 1kb data is already faster than folded aes for 1kb so i don't think it's needed for 1kb.

[Autoparallel]

Chacha with 1kb data is already faster than folded aes for 1kb so i don't think it's needed for 1kb.

Correct, but that's why both of us have said it isn't a blocker today