Objects such as G1_variable or r1cs_gg_ppzksnark_verification_key_variable are simply containers of logical groups of pb_variables and pb_linear_combinations. However, many of them still inherit from gadget (which in turn implies that they generate conditions), simply in order to maintain a reference to the protoboard.
These "variable" objects could inherit gadgets privately, since they only use the base class internally to access this->pb. Alternatively (preferably) we may wish to define a new interface for such objects, whereby they only have set (or generate_r1cs_witness) methods.
Potentially, we could also slim-down the variable objects by passing in the pb reference rather than redundantly storing it with every "variable" instance. e.g. the verification key variables hold the pb ref, as do each of their G1_variable and G2_variable members. (Note, a similar argument about the pb ref could also be made for regular gadgets).
Objects such as
G1_variableorr1cs_gg_ppzksnark_verification_key_variableare simply containers of logical groups of pb_variables and pb_linear_combinations. However, many of them still inherit fromgadget(which in turn implies that they generate conditions), simply in order to maintain a reference to the protoboard.These "variable" objects could inherit gadgets privately, since they only use the base class internally to access
this->pb. Alternatively (preferably) we may wish to define a new interface for such objects, whereby they only haveset(orgenerate_r1cs_witness) methods.Potentially, we could also slim-down the variable objects by passing in the pb reference rather than redundantly storing it with every "variable" instance. e.g. the verification key variables hold the pb ref, as do each of their
G1_variableandG2_variablemembers. (Note, a similar argument about the pb ref could also be made for regular gadgets).