Commitment hashing in the DKG/threshold stack depends on how many bits of each polynomial limb get folded into the transcript. Right now those widths can drift between Noir configs and e3-zk-helpers, and between related circuits:
- C1 vs C5: pk-generation vs pk-aggregation paths should agree on PK / user-data bit sizing so downstream commitment checks stay meaningful.
- C2 vs C4 vs C6: share encryption, per-share share decryption, and aggregate share decryption need consistent per-share vs aggregate widths; the secure preset in particular had a share-decryption msg bit count inconsistent with share encryption.
Goal: align all of the above so Rust, Noir, and E2E tests use one coherent story for bit widths and CRT conversion, and add a canonical CrtPolynomial::to_fhe_polynomial (or equivalent) so tests do not reimplement RNS packing.
Commitment hashing in the DKG/threshold stack depends on how many bits of each polynomial limb get folded into the transcript. Right now those widths can drift between Noir configs and
e3-zk-helpers, and between related circuits:Goal: align all of the above so Rust, Noir, and E2E tests use one coherent story for bit widths and CRT conversion, and add a canonical
CrtPolynomial::to_fhe_polynomial(or equivalent) so tests do not reimplement RNS packing.