Enforce lengths of commitments in protocol

[mimoo]

Our implementation of PolyCom allows any commitment to be chunked/split. This is to commit to polynomials that are larger than the SRS.

To avoid collisions in the transcript, it is important that everything we absorb is unambiguous (and also cannot be the empty string). We do this in one place: we pad t with dummy points to absorb it in the sponge.

I suggest two things:

• we should enforce the length of every commitments. IIUC, their size should be known in advance (or at the very least the number of chunks).
• we should test the protocol with empty commitments, shorter commitments, longer commitments, unshifted commitments, etc.

From @imeckler , this is enforced in the circuit:

it's specified in the "typ" value for proofs inside the circuit (which allocates the corresponding number of field elements to represent that type) see e.g., in src/lib/pickles/wrap_proof.ml:

   (Dlog_plonk_types.Messages.typ ~bool:Boolean.typ
      ~dummy:Inner_curve.Params.one
      ~commitment_lengths:
        (Dlog_plonk_types.Evals.map
           ~f:(fun x -> Vector.[ x ])
           (Commitment_lengths.of_domains ~max_degree:Common.Max_degree.wrap
              Common.wrap_domains))
      Inner_curve.typ)

in general if you search for Commitment_lengths there's a few uses of it

[github-actions[bot]]

Stale issue message

[github-actions[bot]]

Stale issue message

[mimoo]

https://github.com/MinaProtocol/mina/blob/5d02731d3e441ffd4a8acbee4d69d8e55b6f01b5/src/lib/pickles/commitment_lengths.ml#L6 < here are the size of the commitments we expect

[github-actions[bot]]

Stale issue message

[querolita]

I am taking this using generic constants now available

[github-actions[bot]]

Stale issue message

[github-actions[bot]]

Stale issue message

[mimoo]

cc @jspada @querolita do you think this should get in before the hardfork?

[github-actions[bot]]

Stale issue message

[github-actions[bot]]

Stale issue message