feat(groth16): validate data committed onchain before groth16-verify

[manishbista28]

Prover commits groth16 proof and public input(s) onchain. These need to be deserialized into appropriate data structure and validated.
For example, BigInteger needs to be a valid scalar field element, group element(s) need to lie in the correct group and subgroup(s), etc.
Existing implementation for groth16_verify* functions don't seem to validate these properties.

The suggested solution is as follows:

1. Specify a format for data committed on-chain e.g.
   | bits of G1 element(s) | bits of G2 element(s) | bits of public input |
2. GC Input wires assume input in this format
3. Validate that these inputs are correctly formed. If they don't proceed to slashing condition
4. After validation, we proceed as is being done right now with groth16_verify* functions.

[manishbista28]

@Hakkush-07 @cyphersnake Do you think this is a valid issue ?

[cyphersnake]

In general, within this issue we can think about how exactly the data is passed to onchain

The input parameter here is not args of gadgets::groth16_verify, but rather

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct EvaluatorCompressedInput {
    pub public: Vec<EvaluatedFrWires>,
    pub a: EvaluatedCompressedG1Wires,
    pub b: EvaluatedCompressedG2Wires,
    pub c: EvaluatedCompressedG1Wires,
    #[serde(with = "ark_canonical")]
    pub vk: VerifyingKey<Bn254>,
}

What is actually a nested structures of ordinary vector of

#[derive(Clone, Debug, PartialEq, Eq, Serialize, Deserialize)]
pub struct EvaluatedWire {
    pub active_label: S, // `S` is u128
    pub value: bool,
}

In this case, at the transaction generation stage, we only know sha256(S) for each wire.{label0, label1}.

I.e. here you just need to form a hash-lock on each of the Wires, given that there are two separate hashes. I remember that @Hakkush-07 had some ideas about this

[manishbista28]

within this issue we can think about how exactly the data is passed to onchain

Agree

To clarify, with regards to data-representation, I'm mostly asking for type of the underlying raw values and their order.

For example:

• whether group element is represented in compressed form (256 bits total) or as uncompressed affine representation (two 254 bits) or anything else
• order of different fields -- like which value goes first or should public input be at the tail end because this depends on the proving program, etc

Data-validation would mostly include validating field and group elements -- whether they are of correct bounds, were compressed correctly, agree to known properties, etc. Though validation in itself could have been discussed in a separate github issue on its own, I mentioned it here as it is also informed by data representation.

[manishbista28]

To add your answer on EvaluatorCompressedInput helps clear some of these questions on representation. Thanks for the pointer.

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct EvaluatedCompressedG1Wires {
    pub x: EvaluatedFrWires,
    pub y_flag: EvaluatedWire,
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct EvaluatedCompressedG2Wires {
    pub x: [EvaluatedFrWires; 2],
    pub y_flag: EvaluatedWire,
}

[AaronFeickert]

Any updates on this?

[cyphersnake]

I see the problem here as follows - we need to fuzzing what happens if we pass values to the schema that are not mathematically correct.

I.e. we can check in the off-circuit code that the values are correct, but if it is a circuit eval stage, we can't do anything about it. Only on-circuit calculations can save us from incorrect behavior of Garbler

What do you think? @manishbista28 @AaronFeickert

[AaronFeickert]

Unless I'm misunderstanding, the question here is whether in-circuit deserialization and initial parsing of inputs also ensures proper set/group/subgroup membership. If this is not done, then we cannot reason about subsequent handling of these values, and therefore cannot assert properties like soundness hold.

Why would fuzzing suffice for this, as opposed to simply ensuring that suitable membership checks are performed in circuit?